From david.holmes at oracle.com  Mon Nov  2 01:12:42 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Nov 2015 11:12:42 +1000
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <5633EC31.6050103@oracle.com>
References: <5633E8C9.40709@oracle.com> <5633EC31.6050103@oracle.com>
Message-ID: <5636B88A.4080909@oracle.com>

Hi Coleen,

Just a superficial review as I'm not familiar with this code.

On 31/10/2015 8:16 AM, Coleen Phillimore wrote:
>
> On 10/30/15 6:01 PM, Coleen Phillimore wrote:
>> Summary: Save Throwable in a list which is a weak GC root for walking
>> during MetadataOnStackMark

I'm unclear on terminology here. At the Java level an object that is 
only weakly reachable can be gc'd. But here we seem to use a "weak" root 
to prevent something being gc'd - ???

>> This was the original implementation that I had for finding Method* in
>> backtraces but it was slow because I had used jweak to save the
>> Throwable object.   Using internal vm weak GC roots, this does not
>> cause a performance regression in refWorkload.  This fix is more
>> straightforward and does not rely on the constant pool index of the
>> merged constant pool during redefinition to find the method's name.
>> This is one fix that enables removing merged constant pools during
>> redefinition (work in progress).  It also is would be used as a model
>> for JEP 259: Stack Walking API
>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>
>> The code that registers MemberNames for replacing Method* during
>> redefinition may need to use the same mechanism for performance, if
>> MemberName arrays are used for the Stack Walking API.
>>
>> I assume this will generate comments from the GC group.
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/
> bug link https://bugs.openjdk.java.net/browse/JDK-8140685

Some minor comments:

src/share/vm/classfile/javaClasses.hpp

Typo:   // Mark methods as that are

src/share/vm/classfile/backtrace.hpp

_backtraces_head should be volatile as you update via CAS.

src/share/vm/classfile/backtrace.cpp

Minor nit: the "exchanged" variable in add should really be called "found".

Thanks,
David
-----

>>
>> Tested with RBT quick (former "quick" tests), jdk/java/lang/instrument
>> tests and the test that I wrote for handling backtraces with
>> redefinition in hotspot/test/runtime/RedefineTests.
>>
>> Thanks,
>> Coleen
>

From david.holmes at oracle.com  Mon Nov  2 06:40:39 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Nov 2015 16:40:39 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
Message-ID: <56370567.3090801@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8132510

Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/

A simple (in principle) but wide-ranging change which should appeal to 
our Code Deletion Engineer's. We implement Thread::current() using a 
compiler/language-based thread-local variable eg:


  static __thread Thread *_thr_current;

  inline Thread* Thread::current() {
    return _thr_current;
  }

with an appropriate setter of course. By doing this we can completely 
remove the platform-specific ThreadLocalStorage implementations, and the 
associated os::thread_local_storage* calls, plus all the uses of 
ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow(). 
This extends the previous work done on Solaris to implement 
ThreadLocalStorage::thread() using compiler-based thread-locals.

We can also consolidate nearly all the os_cpu versions of 
MacroAssembler::get_thread on x86 into one cpu specific one ( a special 
variant is still needed for 32-bit Windows).

As a result of this change we have further potential cleanups:
- all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely 
empty and could also be removed
- the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map 
"cache" on 32-bit) now has no affect and so could be completely removed 
from the build system

I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could 
add the removal of the "inline" files to this CR if people think it 
worth removing them.

I have one missing piece on Aarch64 - I need to change 
MacroAssembler::get_thread to simply call Thread::current() as on other 
platforms, but I don't know how to write that. I would appreciate it if 
someone could give me the right code for that.

I would also appreciate comments/testing by the AIX and PPC64 folk as well.

A concern about memory-leaks had previously been raised, but experiments 
using simple C code on linux 86 and Solaris showed no issues. Also note 
that Aarch64 already uses this kind of thread-local.

Thanks,
David

From per.liden at oracle.com  Mon Nov  2 07:41:03 2015
From: per.liden at oracle.com (Per Liden)
Date: Mon, 2 Nov 2015 08:41:03 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56370567.3090801@oracle.com>
References: <56370567.3090801@oracle.com>
Message-ID: <5637138F.8090800@oracle.com>

Hi David,

On 2015-11-02 07:40, David Holmes wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
> A simple (in principle) but wide-ranging change which should appeal to
> our Code Deletion Engineer's. We implement Thread::current() using a
> compiler/language-based thread-local variable eg:
>
>
>   static __thread Thread *_thr_current;
>
>   inline Thread* Thread::current() {
>     return _thr_current;
>   }

Do we expect the cost of calling Thread::current() to go down with this 
change or will it remain about the same?

Btw, this looks like a really nice cleanup/simplification!

cheers,
/Per

>
> with an appropriate setter of course. By doing this we can completely
> remove the platform-specific ThreadLocalStorage implementations, and the
> associated os::thread_local_storage* calls, plus all the uses of
> ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
> This extends the previous work done on Solaris to implement
> ThreadLocalStorage::thread() using compiler-based thread-locals.
>
> We can also consolidate nearly all the os_cpu versions of
> MacroAssembler::get_thread on x86 into one cpu specific one ( a special
> variant is still needed for 32-bit Windows).
>
> As a result of this change we have further potential cleanups:
> - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
> empty and could also be removed
> - the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
> "cache" on 32-bit) now has no affect and so could be completely removed
> from the build system
>
> I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
> add the removal of the "inline" files to this CR if people think it
> worth removing them.
>
> I have one missing piece on Aarch64 - I need to change
> MacroAssembler::get_thread to simply call Thread::current() as on other
> platforms, but I don't know how to write that. I would appreciate it if
> someone could give me the right code for that.
>
> I would also appreciate comments/testing by the AIX and PPC64 folk as well.
>
> A concern about memory-leaks had previously been raised, but experiments
> using simple C code on linux 86 and Solaris showed no issues. Also note
> that Aarch64 already uses this kind of thread-local.
>
> Thanks,
> David

From serguei.spitsyn at oracle.com  Mon Nov  2 08:43:42 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 2 Nov 2015 00:43:42 -0800
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <5633EC31.6050103@oracle.com>
References: <5633E8C9.40709@oracle.com> <5633EC31.6050103@oracle.com>
Message-ID: <5637223E.1090804@oracle.com>

Hi Coleen,


The fix looks good to me.
I like the simplifications!


A minor comment:

src/share/vm/classfile/backtrace.hpp

34 // doesn't get deallocatd.

   typo: deallocatd => deallocated


Thanks,
Serguei


On 10/30/15 15:16, Coleen Phillimore wrote:
>
> On 10/30/15 6:01 PM, Coleen Phillimore wrote:
>> Summary: Save Throwable in a list which is a weak GC root for walking 
>> during MetadataOnStackMark
>>
>> This was the original implementation that I had for finding Method* 
>> in backtraces but it was slow because I had used jweak to save the 
>> Throwable object.   Using internal vm weak GC roots, this does not 
>> cause a performance regression in refWorkload. This fix is more 
>> straightforward and does not rely on the constant pool index of the 
>> merged constant pool during redefinition to find the method's name.
>> This is one fix that enables removing merged constant pools during 
>> redefinition (work in progress).  It also is would be used as a model 
>> for JEP 259: Stack Walking API
>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>
>> The code that registers MemberNames for replacing Method* during 
>> redefinition may need to use the same mechanism for performance, if 
>> MemberName arrays are used for the Stack Walking API.
>>
>> I assume this will generate comments from the GC group.
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/
> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>
>>
>> Tested with RBT quick (former "quick" tests), 
>> jdk/java/lang/instrument tests and the test that I wrote for handling 
>> backtraces with redefinition in hotspot/test/runtime/RedefineTests.
>>
>> Thanks,
>> Coleen
>


From stefan.karlsson at oracle.com  Mon Nov  2 09:55:13 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 2 Nov 2015 10:55:13 +0100
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <5633E8C9.40709@oracle.com>
References: <5633E8C9.40709@oracle.com>
Message-ID: <56373301.4030907@oracle.com>

Hi Coleen,

I remember this from our earlier discussions about the Backtraces.

On 2015-10-30 23:01, Coleen Phillimore wrote:
> Summary: Save Throwable in a list which is a weak GC root for walking 
> during MetadataOnStackMark
>
> This was the original implementation that I had for finding Method* in 
> backtraces but it was slow because I had used jweak to save the 
> Throwable object.

It wasn't the jweak handles that made it slow for the GC. Maybe it made 
it slower for the runtime?

> Using internal vm weak GC roots, this does not cause a performance 
> regression in refWorkload.  This fix is more straightforward and does 
> not rely on the constant pool index of the merged constant pool during 
> redefinition to find the method's name.
> This is one fix that enables removing merged constant pools during 
> redefinition (work in progress).  It also is would be used as a model 
> for JEP 259: Stack Walking API
> https://bugs.openjdk.java.net/browse/JDK-8043814.
>
> The code that registers MemberNames for replacing Method* during 
> redefinition may need to use the same mechanism for performance, if 
> MemberName arrays are used for the Stack Walking API.
>
> I assume this will generate comments from the GC group.

If you run the following small test program, you'll see some of the 
problems this patch introduces for the GC. It's a contrived test case to 
make it obvious what the problems with this patch are, but I'd not be 
surprised if you would see effects from this patch if you looked at the 
GC pause times from test runs with larger tests.

public class BT {
   public static void main(String [] args) {
     while (true) {
       try {
         f0(10);
       } catch (RuntimeException e) {
         e.fillInStackTrace();
       }
     }
   }

   public static boolean f0(int v) {
     throw new RuntimeException();
   }
   public static boolean f1(int v) { return f0(v);}
   public static boolean f2(int v) { return f1(v);}
   public static boolean f3(int v) { return f2(v);}
   public static boolean f4(int v) { return f3(v);}
   public static boolean f5(int v) { return f4(v);}
   public static boolean f6(int v) { return f5(v);}
   public static boolean f7(int v) { return f6(v);}
   public static boolean f8(int v) { return f7(v);}
   public static boolean f9(int v) { return f8(v);}
   public static boolean fa(int v) { return f9(v);}
   public static boolean fb(int v) { return fa(v);}
   public static boolean fc(int v) { return fb(v);}
   public static boolean fd(int v) { return fc(v);}
   public static boolean fe(int v) { return fd(v);}
   public static boolean ff(int v) { return fe(v);}
}

Running without the patch:
$ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
#0: [GC pause (G1 Evacuation Pause) (young) 100M->352K(1024M), 0.0197192 
secs]
#1: [GC pause (G1 Evacuation Pause) (young) 99M->354K(1024M), 0.0096909 
secs]
#2: [GC pause (G1 Evacuation Pause) (young) 99M->366K(1024M), 0.0022548 
secs]
#3: [GC pause (G1 Evacuation Pause) (young) 99M->360K(1024M), 0.0141840 
secs]
#4: [GC pause (G1 Evacuation Pause) (young) 99M->355K(1024M), 0.0037668 
secs]
#5: [GC pause (G1 Evacuation Pause) (young) 99M->370K(1024M), 0.0027435 
secs]
#6: [GC pause (G1 Evacuation Pause) (young) 99M->358K(1024M), 0.0243332 
secs]
... and it continues like that ...

Running with the patch:
$ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
#0: [GC pause (G1 Evacuation Pause) (young) 100M->52M(1024M), 0.3144429 
secs]
#1: [GC pause (G1 Evacuation Pause) (young) 139M->98M(1024M), 0.2848108 
secs]
#2: [GC pause (G1 Evacuation Pause) (young) 185M->143M(1024M), 0.2894741 
secs]
#3: [GC pause (G1 Evacuation Pause) (young) 230M->188M(1024M), 0.2593455 
secs]
#4: [GC pause (G1 Evacuation Pause) (young) 275M->233M(1024M), 0.1987466 
secs]
#5: [GC pause (G1 Evacuation Pause) (young) 320M->279M(1024M), 0.1580889 
secs]
#6: [GC pause (G1 Evacuation Pause) (young) 366M->324M(1024M), 0.1370179 
secs]
#7: [GC pause (G1 Evacuation Pause) (young) 411M->369M(1024M), 0.1382296 
secs]
#8: [GC pause (G1 Evacuation Pause) (young) 456M->414M(1024M), 0.3050619 
secs]
#9: [GC pause (G1 Evacuation Pause) (young) 501M->459M(1024M), 0.1885095 
secs]
#10: [GC pause (G1 Evacuation Pause) (young) 546M->504M(1024M), 
0.1608086 secs]
#11: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 
591M->549M(1024M), 0.1846752 secs]
#12: [GC concurrent-root-region-scan-start]
#12: [GC concurrent-root-region-scan-end, 0.0051940 secs]
#12: [GC concurrent-mark-start]
#12: [GC concurrent-mark-end, 0.0175889 secs]
#12: [GC remark, 0.0800191 secs]
#12: [GC cleanup 564M->90M(1024M), 0.0024635 secs]
#12: [GC concurrent-cleanup-start]
#12: [GC concurrent-cleanup-end, 0.0019211 secs]
#13: [GC pause (G1 Evacuation Pause) (young) 162M->120M(1024M), 
0.2551443 secs]
#14: [GC pause (G1 Evacuation Pause) (young) 207M->165M(1024M), 
0.1553368 secs]
#15: [GC pause (G1 Evacuation Pause) (young) 252M->210M(1024M), 
0.2132882 secs]
#16: [GC pause (G1 Evacuation Pause) (young) 297M->255M(1024M), 
0.1187748 secs]
...

As can be seen, the young GC pause times increase drastically, and the 
memory isn't cleaned out until we do a full concurrent cycle (or trigger 
a Full GC).

StefanK

>
> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
> local webrev at http://javaweb.us.oracle.com/~cphillim/webrev/8140685.01
>
> Tested with RBT quick (former "quick" tests), jdk/java/lang/instrument 
> tests and the test that I wrote for handling backtraces with 
> redefinition in hotspot/test/runtime/RedefineTests.
>
> Thanks,
> Coleen


From stefan.karlsson at oracle.com  Mon Nov  2 10:10:32 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 2 Nov 2015 11:10:32 +0100
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <56373301.4030907@oracle.com>
References: <5633E8C9.40709@oracle.com> <56373301.4030907@oracle.com>
Message-ID: <56373698.407@oracle.com>

Hi,

The previous test case had some unnecessary code, here's a much simpler 
version:

public class BT {
   public static void main(String [] args) {
     while (true) {
       try {
         throw new RuntimeException();
       } catch (RuntimeException e) {
       }
     }
   }
}

StefanK

On 2015-11-02 10:55, Stefan Karlsson wrote:
> Hi Coleen,
>
> I remember this from our earlier discussions about the Backtraces.
>
> On 2015-10-30 23:01, Coleen Phillimore wrote:
>> Summary: Save Throwable in a list which is a weak GC root for walking 
>> during MetadataOnStackMark
>>
>> This was the original implementation that I had for finding Method* 
>> in backtraces but it was slow because I had used jweak to save the 
>> Throwable object.
>
> It wasn't the jweak handles that made it slow for the GC. Maybe it 
> made it slower for the runtime?
>
>> Using internal vm weak GC roots, this does not cause a performance 
>> regression in refWorkload.  This fix is more straightforward and does 
>> not rely on the constant pool index of the merged constant pool 
>> during redefinition to find the method's name.
>> This is one fix that enables removing merged constant pools during 
>> redefinition (work in progress).  It also is would be used as a model 
>> for JEP 259: Stack Walking API
>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>
>> The code that registers MemberNames for replacing Method* during 
>> redefinition may need to use the same mechanism for performance, if 
>> MemberName arrays are used for the Stack Walking API.
>>
>> I assume this will generate comments from the GC group.
>
> If you run the following small test program, you'll see some of the 
> problems this patch introduces for the GC. It's a contrived test case 
> to make it obvious what the problems with this patch are, but I'd not 
> be surprised if you would see effects from this patch if you looked at 
> the GC pause times from test runs with larger tests.
>
> public class BT {
>   public static void main(String [] args) {
>     while (true) {
>       try {
>         f0(10);
>       } catch (RuntimeException e) {
>         e.fillInStackTrace();
>       }
>     }
>   }
>
>   public static boolean f0(int v) {
>     throw new RuntimeException();
>   }
>   public static boolean f1(int v) { return f0(v);}
>   public static boolean f2(int v) { return f1(v);}
>   public static boolean f3(int v) { return f2(v);}
>   public static boolean f4(int v) { return f3(v);}
>   public static boolean f5(int v) { return f4(v);}
>   public static boolean f6(int v) { return f5(v);}
>   public static boolean f7(int v) { return f6(v);}
>   public static boolean f8(int v) { return f7(v);}
>   public static boolean f9(int v) { return f8(v);}
>   public static boolean fa(int v) { return f9(v);}
>   public static boolean fb(int v) { return fa(v);}
>   public static boolean fc(int v) { return fb(v);}
>   public static boolean fd(int v) { return fc(v);}
>   public static boolean fe(int v) { return fd(v);}
>   public static boolean ff(int v) { return fe(v);}
> }
>
> Running without the patch:
> $ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
> #0: [GC pause (G1 Evacuation Pause) (young) 100M->352K(1024M), 
> 0.0197192 secs]
> #1: [GC pause (G1 Evacuation Pause) (young) 99M->354K(1024M), 
> 0.0096909 secs]
> #2: [GC pause (G1 Evacuation Pause) (young) 99M->366K(1024M), 
> 0.0022548 secs]
> #3: [GC pause (G1 Evacuation Pause) (young) 99M->360K(1024M), 
> 0.0141840 secs]
> #4: [GC pause (G1 Evacuation Pause) (young) 99M->355K(1024M), 
> 0.0037668 secs]
> #5: [GC pause (G1 Evacuation Pause) (young) 99M->370K(1024M), 
> 0.0027435 secs]
> #6: [GC pause (G1 Evacuation Pause) (young) 99M->358K(1024M), 
> 0.0243332 secs]
> ... and it continues like that ...
>
> Running with the patch:
> $ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
> #0: [GC pause (G1 Evacuation Pause) (young) 100M->52M(1024M), 
> 0.3144429 secs]
> #1: [GC pause (G1 Evacuation Pause) (young) 139M->98M(1024M), 
> 0.2848108 secs]
> #2: [GC pause (G1 Evacuation Pause) (young) 185M->143M(1024M), 
> 0.2894741 secs]
> #3: [GC pause (G1 Evacuation Pause) (young) 230M->188M(1024M), 
> 0.2593455 secs]
> #4: [GC pause (G1 Evacuation Pause) (young) 275M->233M(1024M), 
> 0.1987466 secs]
> #5: [GC pause (G1 Evacuation Pause) (young) 320M->279M(1024M), 
> 0.1580889 secs]
> #6: [GC pause (G1 Evacuation Pause) (young) 366M->324M(1024M), 
> 0.1370179 secs]
> #7: [GC pause (G1 Evacuation Pause) (young) 411M->369M(1024M), 
> 0.1382296 secs]
> #8: [GC pause (G1 Evacuation Pause) (young) 456M->414M(1024M), 
> 0.3050619 secs]
> #9: [GC pause (G1 Evacuation Pause) (young) 501M->459M(1024M), 
> 0.1885095 secs]
> #10: [GC pause (G1 Evacuation Pause) (young) 546M->504M(1024M), 
> 0.1608086 secs]
> #11: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 
> 591M->549M(1024M), 0.1846752 secs]
> #12: [GC concurrent-root-region-scan-start]
> #12: [GC concurrent-root-region-scan-end, 0.0051940 secs]
> #12: [GC concurrent-mark-start]
> #12: [GC concurrent-mark-end, 0.0175889 secs]
> #12: [GC remark, 0.0800191 secs]
> #12: [GC cleanup 564M->90M(1024M), 0.0024635 secs]
> #12: [GC concurrent-cleanup-start]
> #12: [GC concurrent-cleanup-end, 0.0019211 secs]
> #13: [GC pause (G1 Evacuation Pause) (young) 162M->120M(1024M), 
> 0.2551443 secs]
> #14: [GC pause (G1 Evacuation Pause) (young) 207M->165M(1024M), 
> 0.1553368 secs]
> #15: [GC pause (G1 Evacuation Pause) (young) 252M->210M(1024M), 
> 0.2132882 secs]
> #16: [GC pause (G1 Evacuation Pause) (young) 297M->255M(1024M), 
> 0.1187748 secs]
> ...
>
> As can be seen, the young GC pause times increase drastically, and the 
> memory isn't cleaned out until we do a full concurrent cycle (or 
> trigger a Full GC).
>
> StefanK
>
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>> local webrev at http://javaweb.us.oracle.com/~cphillim/webrev/8140685.01
>>
>> Tested with RBT quick (former "quick" tests), 
>> jdk/java/lang/instrument tests and the test that I wrote for handling 
>> backtraces with redefinition in hotspot/test/runtime/RedefineTests.
>>
>> Thanks,
>> Coleen
>


From sgehwolf at redhat.com  Mon Nov  2 10:38:02 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 02 Nov 2015 11:38:02 +0100
Subject: RFR 6425769: jmx remote bind address
Message-ID: <1446460682.10865.20.camel@redhat.com>

Hi,

Here is a patch addressing JDK-6425769. The issue is that the JMX agent
binds to the wildcard address by default, preventing users to use
system properties for JMX agents on multi-homed hosts. Given a host
with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's
impossible to start two JMX agents binding to fixed ports but to
different network interfaces, 192.168.0.1:{9111,9112} and
192.168.0.2:{9111,9112} say.

The JDK would bind to all local interfaces by default. In the above
example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second
Java process would get a "Connection refused" error because another
process has already been bound to the specified JMX/RMI port pairs.

Bug:?https://bugs.openjdk.java.net/browse/JDK-6425769
webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/

Testing done:
jdk_jmx and jdk_management tests all pass after this change (no
regressions). There is also a new JTREG test which fails prior this
change and passes after. Updates to the diagnostic command have been
tested manually.

I understand that, if approved, the JDK and hotspot changes should get
pushed together? Hotspot changes are fairly trivial since it's only a
doc-update for the new JDK property in the relevant diagnostic command.

Could someone please review and sponsor this change? Please let me know
if there are questions.

Thanks,
Severin

From david.holmes at oracle.com  Mon Nov  2 11:14:09 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Nov 2015 21:14:09 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5637138F.8090800@oracle.com>
References: <56370567.3090801@oracle.com> <5637138F.8090800@oracle.com>
Message-ID: <56374581.7080601@oracle.com>

On 2/11/2015 5:41 PM, Per Liden wrote:
> Hi David,
>
> On 2015-11-02 07:40, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>> A simple (in principle) but wide-ranging change which should appeal to
>> our Code Deletion Engineer's. We implement Thread::current() using a
>> compiler/language-based thread-local variable eg:
>>
>>
>>   static __thread Thread *_thr_current;
>>
>>   inline Thread* Thread::current() {
>>     return _thr_current;
>>   }
>
> Do we expect the cost of calling Thread::current() to go down with this
> change or will it remain about the same?

Depends on the platform and the exact circumstances, given the varied 
caching and other "fast lookup" schemes previously employed (even though 
this is slow-path code). I do not expect it to be slower in general but 
we will be somewhat at the mercy of the particular platform 
implementation. The earlier Solaris change showed mildly positive 
results. I'll be starting some performance runs tomorrow.

> Btw, this looks like a really nice cleanup/simplification!

Thanks,
David

> cheers,
> /Per
>
>>
>> with an appropriate setter of course. By doing this we can completely
>> remove the platform-specific ThreadLocalStorage implementations, and the
>> associated os::thread_local_storage* calls, plus all the uses of
>> ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
>> This extends the previous work done on Solaris to implement
>> ThreadLocalStorage::thread() using compiler-based thread-locals.
>>
>> We can also consolidate nearly all the os_cpu versions of
>> MacroAssembler::get_thread on x86 into one cpu specific one ( a special
>> variant is still needed for 32-bit Windows).
>>
>> As a result of this change we have further potential cleanups:
>> - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
>> empty and could also be removed
>> - the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
>> "cache" on 32-bit) now has no affect and so could be completely removed
>> from the build system
>>
>> I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
>> add the removal of the "inline" files to this CR if people think it
>> worth removing them.
>>
>> I have one missing piece on Aarch64 - I need to change
>> MacroAssembler::get_thread to simply call Thread::current() as on other
>> platforms, but I don't know how to write that. I would appreciate it if
>> someone could give me the right code for that.
>>
>> I would also appreciate comments/testing by the AIX and PPC64 folk as
>> well.
>>
>> A concern about memory-leaks had previously been raised, but experiments
>> using simple C code on linux 86 and Solaris showed no issues. Also note
>> that Aarch64 already uses this kind of thread-local.
>>
>> Thanks,
>> David

From thomas.stuefe at gmail.com  Mon Nov  2 11:20:22 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 2 Nov 2015 12:20:22 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56370567.3090801@oracle.com>
References: <56370567.3090801@oracle.com>
Message-ID: <CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>

Hi David,

some small changes are needed to make this build and run on AIX. I attached
a patch file with the needed additions.

I did not run any extensive tests on AIX, so I cannot say for sure if this
is stable. We (SAP) also may face some problems later when we port this to
HP-UX, because there, shared libraries using __thread cannot be loaded
dynamically.

So, I admit to some small worries, beside the issue with memory leaks on
older glibc versions. For me, this feels like something which needs tight
compiler/thread library support from the OS, so it makes us vulnerable to
running on older systems (older glibc) or building with outdated compilers.
Therefore it would be nice to have a simple way to re-add the pthread-based
TLS implementation if needed.

Apart from that, I like the patch and think the simplification is good and
worth the effort.

Kind Regards, Thomas






On Mon, Nov 2, 2015 at 7:40 AM, David Holmes <david.holmes at oracle.com>
wrote:

> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
> A simple (in principle) but wide-ranging change which should appeal to our
> Code Deletion Engineer's. We implement Thread::current() using a
> compiler/language-based thread-local variable eg:
>
>
>  static __thread Thread *_thr_current;
>
>  inline Thread* Thread::current() {
>    return _thr_current;
>  }
>
> with an appropriate setter of course. By doing this we can completely
> remove the platform-specific ThreadLocalStorage implementations, and the
> associated os::thread_local_storage* calls, plus all the uses of
> ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
> This extends the previous work done on Solaris to implement
> ThreadLocalStorage::thread() using compiler-based thread-locals.
>
> We can also consolidate nearly all the os_cpu versions of
> MacroAssembler::get_thread on x86 into one cpu specific one ( a special
> variant is still needed for 32-bit Windows).
>
> As a result of this change we have further potential cleanups:
> - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
> empty and could also be removed
> - the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
> "cache" on 32-bit) now has no affect and so could be completely removed
> from the build system
>
> I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
> add the removal of the "inline" files to this CR if people think it worth
> removing them.
>
> I have one missing piece on Aarch64 - I need to change
> MacroAssembler::get_thread to simply call Thread::current() as on other
> platforms, but I don't know how to write that. I would appreciate it if
> someone could give me the right code for that.
>
> I would also appreciate comments/testing by the AIX and PPC64 folk as well.
>
> A concern about memory-leaks had previously been raised, but experiments
> using simple C code on linux 86 and Solaris showed no issues. Also note
> that Aarch64 already uses this kind of thread-local.
>
> Thanks,
> David
>

From aph at redhat.com  Mon Nov  2 11:25:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 2 Nov 2015 11:25:17 +0000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56374581.7080601@oracle.com>
References: <56370567.3090801@oracle.com> <5637138F.8090800@oracle.com>
	<56374581.7080601@oracle.com>
Message-ID: <5637481D.1040408@redhat.com>

On 02/11/15 11:14, David Holmes wrote:
> Depends on the platform and the exact circumstances, given the varied 
> caching and other "fast lookup" schemes previously employed (even though 
> this is slow-path code).

It's not just the slow path: from what I remember it's called tens of
thousands of times at startup, so this really is a worthwhile change.

Andrew.


From jaroslav.bachorik at oracle.com  Mon Nov  2 13:32:51 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 2 Nov 2015 14:32:51 +0100
Subject: RFR 6425769: jmx remote bind address
In-Reply-To: <1446460682.10865.20.camel@redhat.com>
References: <1446460682.10865.20.camel@redhat.com>
Message-ID: <56376603.5050902@oracle.com>

Adding core libs.

On 2.11.2015 11:38, Severin Gehwolf wrote:
> Hi,
>
> Here is a patch addressing JDK-6425769. The issue is that the JMX agent
> binds to the wildcard address by default, preventing users to use
> system properties for JMX agents on multi-homed hosts. Given a host
> with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's
> impossible to start two JMX agents binding to fixed ports but to
> different network interfaces, 192.168.0.1:{9111,9112} and
> 192.168.0.2:{9111,9112} say.
>
> The JDK would bind to all local interfaces by default. In the above
> example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second
> Java process would get a "Connection refused" error because another
> process has already been bound to the specified JMX/RMI port pairs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/
>
> Testing done:
> jdk_jmx and jdk_management tests all pass after this change (no
> regressions). There is also a new JTREG test which fails prior this
> change and passes after. Updates to the diagnostic command have been
> tested manually.
>
> I understand that, if approved, the JDK and hotspot changes should get
> pushed together? Hotspot changes are fairly trivial since it's only a
> doc-update for the new JDK property in the relevant diagnostic command.
>
> Could someone please review and sponsor this change? Please let me know
> if there are questions.
>
> Thanks,
> Severin
>


From jaroslav.bachorik at oracle.com  Mon Nov  2 15:54:03 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 2 Nov 2015 16:54:03 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <56377F17.4050006@oracle.com>
References: <1446460682.10865.20.camel@redhat.com>
	<56377F17.4050006@oracle.com>
Message-ID: <5637871B.30705@oracle.com>

Hi,

On 2.11.2015 16:19, Daniel Fuchs wrote:
> Hi Severin,
>
> Adding serviceability-dev at openjdk.java.net into the loop - that's
> a better alias than hotspot-dev for this kind of changes - maybe
> someone from serviceability-dev will offer to sponsor :-)
>
> I will let serviceability team members comment on the hotspot changes.
>
> ConnectorBootstrap.java
>
> I have one suggestion and one concern:
>
> Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) and
> ssf  (Server Socket Factory) variables rather than introduce the two
> new variables rmiServerSocketFactory and rmiClientSocketFactory.
> You might want to create a new boolean 'useSocketFactory' variable,
> if that makes the code more readable.
>
> Concern: If I understand correctly how RMI socket factories work,
> the client socket factory will be serialized and sent to the client
> side. This is problematic for interoperability, as the class may not
> present in the remote client - if the remote client is e.g. jdk 8.
>
> As far as I can see, your new DefaultClientSocketFactory doesn't do
> anything useful - so I would suggest to simply get rid of it, and only
> set the Server Socket Factory when SSL is not involved.
>
> Tests:
>
> Concerning the tests - we're trying to get rid of shell scripts
> rather than introducing new ones :-)
> Could the test be rewritten in pure java using the Process API?
>
> I believe there's even a test library that will let you do that
> easily jdk/test/lib/testlibrary/jdk/testlibrary/
> (see ProcessTools.java)
>
> Other:
>
> Also - I believe the new option should be documented in:
> src/java.management/share/conf/management.properties
I share Daniel's concerns. Also, the part of the changeset is related to javax.rmi.ssl - someone maintaining this library should also comment here.

Also, the change is introducing new API (system property) and changing the existing one (adding SslRmiServerSocketFactory public constructors) so compatibility review process will have to be involved.

-JB-
>
> best regards,
>
> -- daniel
>
> On 02/11/15 11:38, Severin Gehwolf wrote:
> > Hi,
> >
> > Here is a patch addressing JDK-6425769. The issue is that the JMX agent
> > binds to the wildcard address by default, preventing users to use
> > system properties for JMX agents on multi-homed hosts. Given a host
> > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's
> > impossible to start two JMX agents binding to fixed ports but to
> > different network interfaces, 192.168.0.1:{9111,9112} and
> > 192.168.0.2:{9111,9112} say.
> >
> > The JDK would bind to all local interfaces by default. In the above
> > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second
> > Java process would get a "Connection refused" error because another
> > process has already been bound to the specified JMX/RMI port pairs.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/
> >
> > Testing done:
> > jdk_jmx and jdk_management tests all pass after this change (no
> > regressions). There is also a new JTREG test which fails prior this
> > change and passes after. Updates to the diagnostic command have been
> > tested manually.
> >
> > I understand that, if approved, the JDK and hotspot changes should get
> > pushed together? Hotspot changes are fairly trivial since it's only a
> > doc-update for the new JDK property in the relevant diagnostic command.
> >
> > Could someone please review and sponsor this change? Please let me know
> > if there are questions.
> >
> > Thanks,
> > Severin
> >
>


From sgehwolf at redhat.com  Mon Nov  2 16:41:47 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 02 Nov 2015 17:41:47 +0100
Subject: [9] RFR(XS) 8141138: Zero fails to build
Message-ID: <1446482507.10865.32.camel@redhat.com>

Hi,

Could somebody please review and - if approved - sponsor this fairly
trivial change?

A recent checkout of the hs-rt tree fails to build the Zero variant[1]
for the following reasons:

 * JDK-8136421 (Java Level JVM Compiler Interface) did not update two
   files:?src/cpu/zero/vm/relocInfo_zero.cpp
   and?src/cpu/zero/vm/compiledIC_zero.cpp. The signature
   of?emit_to_interp_stub() has changed. This patch updates it for Zero
   too.?poll_return_Relocation::fix_relocation_after_move has been
   removed from header files. This patch removes the Zero stub as well.
 * JDK-8139163 (InstanceKlass::cast passes through NULL) removed the
   k_entry variable. I've updated the code to use the new "ik" variable
   instead.

Bug:?https://bugs.openjdk.java.net/browse/JDK-8141138
webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141138/webrev.00/

Thanks,
Severin

[1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/182/

From sgehwolf at redhat.com  Mon Nov  2 16:57:38 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 02 Nov 2015 17:57:38 +0100
Subject: [9] RFR(XS) 8141140: Zero JVM fails to initialize after JDK-8078554
Message-ID: <1446483458.10865.43.camel@redhat.com>

Hi,

Could somebody please review and sponsor this tiny change? It fixes a
Zero VM initialization problem happening after?JDK-8078554.

My understanding is that?AllocatePrefetchDistance received a new
constraint check with JDK-8078554 which now triggers for a Zero VM
since Zero didn't explicitly disable prefetching before.

Bug:?https://bugs.openjdk.java.net/browse/JDK-8141140
webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141140/webrev.01/

Please note that this change depends on the change in [1] since Zero
does not build for me without it.

Thanks,
Severin

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

From kirill.zhaldybin at oracle.com  Mon Nov  2 17:56:22 2015
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Mon, 02 Nov 2015 20:56:22 +0300
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
Message-ID: <5637A3C6.1000504@oracle.com>

Hi,

Could somebody please review this change?
It adds EnvironmentIssue and TestBug classes for environment issue and 
test bug correspondingly to the test library.
It is the first part of JDK-8065651: Enhance Asserts to throw different 
exceptions for different types of assertions.

CR: https://bugs.openjdk.java.net/browse/JDK-8141146
WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8141146/webrev.00/

Thank you.

Regards, Kirill

From coleen.phillimore at oracle.com  Mon Nov  2 18:05:51 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 02 Nov 2015 13:05:51 -0500
Subject: [9] RFR(XS) 8141138: Zero fails to build
In-Reply-To: <1446482507.10865.32.camel@redhat.com>
References: <1446482507.10865.32.camel@redhat.com>
Message-ID: <5637A5FF.3030304@oracle.com>


Hi,

This change looks fine.  I can't build Zero anymore because of some 
build change that doesn't work for me.  If I can get that figured out, 
I'll sponsor this and the other change for you.

The build tries to pass -lffi even though I gave it an explicit libffi 
directory.

Coleen

On 11/2/15 11:41 AM, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review and - if approved - sponsor this fairly
> trivial change?
>
> A recent checkout of the hs-rt tree fails to build the Zero variant[1]
> for the following reasons:
>
>   * JDK-8136421 (Java Level JVM Compiler Interface) did not update two
>     files: src/cpu/zero/vm/relocInfo_zero.cpp
>     and src/cpu/zero/vm/compiledIC_zero.cpp. The signature
>     of emit_to_interp_stub() has changed. This patch updates it for Zero
>     too. poll_return_Relocation::fix_relocation_after_move has been
>     removed from header files. This patch removes the Zero stub as well.
>   * JDK-8139163 (InstanceKlass::cast passes through NULL) removed the
>     k_entry variable. I've updated the code to use the new "ik" variable
>     instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141138
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141138/webrev.00/
>
> Thanks,
> Severin
>
> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/182/


From coleen.phillimore at oracle.com  Mon Nov  2 18:06:11 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 02 Nov 2015 13:06:11 -0500
Subject: [9] RFR(XS) 8141140: Zero JVM fails to initialize after
	JDK-8078554
In-Reply-To: <1446483458.10865.43.camel@redhat.com>
References: <1446483458.10865.43.camel@redhat.com>
Message-ID: <5637A613.7000505@oracle.com>


Thank you for fixing this also.
Coleen


On 11/2/15 11:57 AM, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review and sponsor this tiny change? It fixes a
> Zero VM initialization problem happening after JDK-8078554.
>
> My understanding is that AllocatePrefetchDistance received a new
> constraint check with JDK-8078554 which now triggers for a Zero VM
> since Zero didn't explicitly disable prefetching before.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141140
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141140/webrev.01/
>
> Please note that this change depends on the change in [1] since Zero
> does not build for me without it.
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020410.html


From sgehwolf at redhat.com  Mon Nov  2 18:06:55 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 02 Nov 2015 19:06:55 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <5637871B.30705@oracle.com>
References: <1446460682.10865.20.camel@redhat.com>
	<56377F17.4050006@oracle.com> <5637871B.30705@oracle.com>
Message-ID: <1446487615.10865.57.camel@redhat.com>

Hi,

Thanks Jaroslav and Daniel for the reviews! Comments inline.

On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> Hi,
> 
> On 2.11.2015 16:19, Daniel Fuchs wrote:
> > Hi Severin,
> > 
> > Adding serviceability-dev at openjdk.java.net into the loop - that's
> > a better alias than hotspot-dev for this kind of changes - maybe
> > someone from serviceability-dev will offer to sponsor :-)
> > 
> > I will let serviceability team members comment on the hotspot
> > changes.
> > 
> > ConnectorBootstrap.java
> > 
> > I have one suggestion and one concern:
> > 
> > Suggestion: I would suggest to reuse 'csf' (Client Socket Factory)
> > and
> > ssf??(Server Socket Factory) variables rather than introduce the
> > two
> > new variables rmiServerSocketFactory and rmiClientSocketFactory.
> > You might want to create a new boolean 'useSocketFactory' variable,
> > if that makes the code more readable.
> > 
> > Concern: If I understand correctly how RMI socket factories work,
> > the client socket factory will be serialized and sent to the client
> > side. This is problematic for interoperability, as the class may
> > not
> > present in the remote client - if the remote client is e.g. jdk 8.
> > 
> > As far as I can see, your new DefaultClientSocketFactory doesn't do
> > anything useful - so I would suggest to simply get rid of it, and
> > only
> > set the Server Socket Factory when SSL is not involved.

Thanks. Fixed in updated webrev.

> > Tests:
> > 
> > Concerning the tests - we're trying to get rid of shell scripts
> > rather than introducing new ones :-)
> > Could the test be rewritten in pure java using the Process API?
> > 
> > I believe there's even a test library that will let you do that
> > easily jdk/test/lib/testlibrary/jdk/testlibrary/
> > (see ProcessTools.java)

It'll take me a bit to rewrite the test in pure Java, but should be
fine. This is not yet fixed in the updated webrev.

> > Other:
> > 
> > Also - I believe the new option should be documented in:
> > src/java.management/share/conf/management.properties

Docs have been updated
in?src/java.management/share/conf/management.properties.

> I share Daniel's concerns. Also, the part of the changeset is related
> to javax.rmi.ssl - someone maintaining this library should also
> comment here.
> 
> Also, the change is introducing new API (system property) and
> changing the existing one (adding SslRmiServerSocketFactory public
> constructors) so compatibility review process will have to be
> involved.

OK. What exactly is there for me to do? I'm not familiar with this
process. Note that the intent would be to get this backported to JDK 8.

New webrev at:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/

Thanks,
Severin

> -JB-
> > 
> > best regards,
> > 
> > -- daniel
> > 
> > On 02/11/15 11:38, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Here is a patch addressing JDK-6425769. The issue is that the JMX
> > > agent
> > > binds to the wildcard address by default, preventing users to use
> > > system properties for JMX agents on multi-homed hosts. Given a
> > > host
> > > with local network interfaces, 192.168.0.1 and 192.168.0.2 say,
> > > it's
> > > impossible to start two JMX agents binding to fixed ports but to
> > > different network interfaces, 192.168.0.1:{9111,9112} and
> > > 192.168.0.2:{9111,9112} say.
> > > 
> > > The JDK would bind to all local interfaces by default. In the
> > > above
> > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the
> > > second
> > > Java process would get a "Connection refused" error because
> > > another
> > > process has already been bound to the specified JMX/RMI port
> > > pairs.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/
> > > 00/
> > > 
> > > Testing done:
> > > jdk_jmx and jdk_management tests all pass after this change (no
> > > regressions). There is also a new JTREG test which fails prior
> > > this
> > > change and passes after. Updates to the diagnostic command have
> > > been
> > > tested manually.
> > > 
> > > I understand that, if approved, the JDK and hotspot changes
> > > should get
> > > pushed together? Hotspot changes are fairly trivial since it's
> > > only a
> > > doc-update for the new JDK property in the relevant diagnostic
> > > command.
> > > 
> > > Could someone please review and sponsor this change? Please let
> > > me know
> > > if there are questions.
> > > 
> > > Thanks,
> > > Severin
> > > 
> > 
> 


From christian.tornqvist at oracle.com  Mon Nov  2 18:20:48 2015
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 2 Nov 2015 13:20:48 -0500
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
In-Reply-To: <5637A3C6.1000504@oracle.com>
References: <5637A3C6.1000504@oracle.com>
Message-ID: <108301d1159b$332b87a0$998296e0$@oracle.com>

Hi Kirill,

I'm still doubting how useful this would be, can you give some examples of where these different exceptions would be used and what the benefit would be? How would this be used with the current Assert class? 

Thanks,
Christian

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Kirill Zhaldybin
Sent: Monday, November 2, 2015 12:56 PM
To: hotspot-dev <hotspot-dev at openjdk.java.net>
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library

Hi,

Could somebody please review this change?
It adds EnvironmentIssue and TestBug classes for environment issue and test bug correspondingly to the test library.
It is the first part of JDK-8065651: Enhance Asserts to throw different exceptions for different types of assertions.

CR: https://bugs.openjdk.java.net/browse/JDK-8141146
WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8141146/webrev.00/

Thank you.

Regards, Kirill


From ioi.lam at oracle.com  Mon Nov  2 18:36:28 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 02 Nov 2015 10:36:28 -0800
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code
	for CDS
In-Reply-To: <5633C89E.5050503@oracle.com>
References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com>
Message-ID: <5637AD2C.5010001@oracle.com>

On 10/30/15 12:44 PM, Coleen Phillimore wrote:
>
> Hi Ioi,
> This is a manageable code change.
>
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html
>
> You forward declare Klass* but don't use it in this header file.
> Also can you add a comment to #endif  to say what it's endifing. ie. 
> // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP
>
Fixed.

I also changed ClassListParser to a StackObj as you suggested in another 
e-mail to me.

> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html
>    33   TempNewSymbol class_name_symbol = SymbolTable::new_permanent_symbol(parser->current_class_name(), THREAD);
> This doesn't make sense.   If you want a permanent symbol, it doesn't 
> need to get un-reference counted with the TempNewSymbol destructor.

I changed it to

   TempNewSymbol class_name_symbol = 
SymbolTable::new_symbol(parser->current_class_name(), THREAD);

>
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html
>
> +    // Make sure we have an entry in the SystemDictionary on success
I will actually remove this block of code in the next update to make 
things simpler.

> This assert code is a copy of some code elsewhere.  Can you make it a 
> function that they boh can call?
> Can you also comment the raw #endif's to what they're endifing?
>
Will do.

Thanks

> Otherwise, this looks okay.
>
> Coleen
>
>
> On 10/30/15 1:00 PM, Ioi Lam wrote:
>> Please review the following fix:
>>
>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>
>> Bug: Clean up and refactor of class loading code for CDS
>>
>> https://bugs.openjdk.java.net/browse/JDK-8140802
>>
>> Summary of fix:
>>
>>     We need to clean up and refactor the class loading code in order
>>     to support CDS in JDK9
>>
>>     [1] Remove code that has been made obsolete by the module changes
>>         (such as supporting code used for meta-index file)
>>     [2] Add new whitebox API to be used by CDS-related tests.
>>     [3] Refactor the parsing of classlist files for future enhancements.
>>     [4] Add new APIs in the class loading code to support Oracle CDS 
>> enhancements.
>>
>> Tests:
>>
>>     JPRT
>>     RBT - with same set of tests as hs-rt nightly
>>
>> Thanks
>> - Ioi
>


From ioi.lam at oracle.com  Mon Nov  2 18:50:38 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 02 Nov 2015 10:50:38 -0800
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code
	for CDS
In-Reply-To: <2DAFD29D-4F30-441E-934F-610F6D0A2C2E@oracle.com>
References: <5633A24A.9070800@oracle.com>
	<2DAFD29D-4F30-441E-934F-610F6D0A2C2E@oracle.com>
Message-ID: <5637B07E.4090509@oracle.com>

On 10/30/15 1:23 PM, Jiangli Zhou wrote:
> Hi Ioi,
>
> The change looks pretty clean. The new src/share/vm/classfile/systemDictionary_ext.hpp and src/share/vm/classfile/vmSymbols_ext.hpp do not have copyright header. Please add the copyright headers. Please also fix the copyright year for the modified files prior to pushing.
I added the missing heads and fixed the copyright year for all modified 
files.
> In src/share/vm/classfile/sharedPathsMiscInfo.hpp, is the new ?#include ?classify/classLoader.hpp? necessary?
Yes, it's necessary for this part of the file

   static void trace_class_path(const char* msg, const char* name = NULL) {
     ClassLoader::trace_class_path(msg, name);
   }

I am not sure why it wasn't detected by the C compiler before, but I did 
have a build failure when building without precompiled headers.

Thanks
- Ioi

> I agree with the comments from Colleen and Karen regarding the usage of new_permanent_symbol() and TempNewSymbol in classLoaderExt.cpp. It doesn?t seem to be consistent.
>
> Thanks,
> Jiangli
>
>> On Oct 30, 2015, at 10:00 AM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>
>> Please review the following fix:
>>
>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>
>> Bug: Clean up and refactor of class loading code for CDS
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8140802
>>
>> Summary of fix:
>>
>>     We need to clean up and refactor the class loading code in order
>>     to support CDS in JDK9
>>
>>     [1] Remove code that has been made obsolete by the module changes
>>         (such as supporting code used for meta-index file)
>>     [2] Add new whitebox API to be used by CDS-related tests.
>>     [3] Refactor the parsing of classlist files for future enhancements.
>>     [4] Add new APIs in the class loading code to support Oracle CDS enhancements.
>>
>> Tests:
>>
>>     JPRT
>>     RBT - with same set of tests as hs-rt nightly
>>
>> Thanks
>> - Ioi


From kirill.zhaldybin at oracle.com  Mon Nov  2 18:56:44 2015
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Mon, 02 Nov 2015 21:56:44 +0300
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
In-Reply-To: <108301d1159b$332b87a0$998296e0$@oracle.com>
References: <5637A3C6.1000504@oracle.com>
	<108301d1159b$332b87a0$998296e0$@oracle.com>
Message-ID: <5637B1EC.9000402@oracle.com>

Hi Christian,

We already have more than 2k statements like "throw new testbug" in 
hotspot/test.
I think it indicates that we need a separate error for test 
bug/environment issue. It will allow us to identify test/env issues 
easily and assign them directly to SQE avoiding spending any dev time.

I created a sub-task on new Asserts framework here - 
https://bugs.openjdk.java.net/browse/JDK-8141204
We are really appreciate your comments.

Thank you.

Regards, Kirill


On 02.11.2015 21:20, Christian Tornqvist wrote:
> Hi Kirill,
>
> I'm still doubting how useful this would be, can you give some examples of where these different exceptions would be used and what the benefit would be? How would this be used with the current Assert class?
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Kirill Zhaldybin
> Sent: Monday, November 2, 2015 12:56 PM
> To: hotspot-dev <hotspot-dev at openjdk.java.net>
> Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
>
> Hi,
>
> Could somebody please review this change?
> It adds EnvironmentIssue and TestBug classes for environment issue and test bug correspondingly to the test library.
> It is the first part of JDK-8065651: Enhance Asserts to throw different exceptions for different types of assertions.
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8141146
> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8141146/webrev.00/
>
> Thank you.
>
> Regards, Kirill
>


From ioi.lam at oracle.com  Mon Nov  2 18:57:43 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 02 Nov 2015 10:57:43 -0800
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code
	for CDS
In-Reply-To: <5633D3A2.6050809@oracle.com>
References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com>
	<AEAE2E8A-CD7F-4523-A221-D3640A9FBE98@oracle.com>
	<5633D3A2.6050809@oracle.com>
Message-ID: <5637B227.4050905@oracle.com>



On 10/30/15 1:31 PM, Coleen Phillimore wrote:
>
>
> On 10/30/15 4:18 PM, Karen Kinnear wrote:
>> Coleen,
>>
>> Question for you below please ...
>>> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>> Hi Ioi,
>>> This is a manageable code change.
>>>
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html 
>>>
>>>
>>> You forward declare Klass* but don't use it in this header file.
>>> Also can you add a comment to #endif  to say what it's endifing. ie. 
>>> // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP
>>>
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html 
>>>
>>>
>>>   33   TempNewSymbol class_name_symbol = 
>>> SymbolTable::new_permanent_symbol(parser->current_class_name(), 
>>> THREAD);
>>>
>>> This doesn't make sense.   If you want a permanent symbol, it 
>>> doesn't need to get un-reference counted with the TempNewSymbol 
>>> destructor.
>> Thank you for chiming in on this one - I wanted your opinion here. 
>> (this code used to be in MetaspaceShared::
>> preload_and_dump and I think was wrong there as well).
>> My understanding is that it is a TempNewSymbol that he wants, so he 
>> should call SymbolTable::new_symbol.
>> The code creates a (temporary) symbol for the name, and then calls 
>> SystemDictionary::resolve_or_null, which if it
>> succeeds will walk through the classFileParser which will create a 
>> permanent symbol for the class name,
>> via the symbol_alloc_batch handling. That would be consistent with 
>> the TempNewSymbol call in
>> SystemDictionary::resolve_or_null as well as in parse_stream - all 
>> places dealing with the class name
>> before doing classfile parsing.
>>
>> Does that make sense?
>
> Yes, this makes sense.  The symbol shouldn't be permanent.   Ioi can 
> test this by putting a strange long name in the classlist file and 
> make sure it doesn't make it out to the shared archive, since I think 
> -Xshare:dump cleans out the SymbolTable before dumping.
>
After changing to use new_symbol instead of new_permanent_symbol, I ran 
-Xshare:dump:

$ java -Xshare:dump
Preload Warning: Cannot find sun/text/normalizer/UnicodeMatcher
...
total   :  13063134 [100.0% of total] out of  27385856 bytes [47.7% used]

$ strings images/jdk/lib/i386/hotspot/classes.jsa | grep 
sun/text/normalizer/UnicodeMatcher
sun/text/normalizer/UnicodeMatcher

So the unused symbols are not removed. Anyway, I have filed a separate 
issue for this: https://bugs.openjdk.java.net/browse/JDK-8141207

Thanks
- Ioi


> Coleen
>>
>> thanks,
>> Karen
>>
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html 
>>>
>>>
>>> +    // Make sure we have an entry in the SystemDictionary on success
>>>
>>>
>>> This assert code is a copy of some code elsewhere.  Can you make it 
>>> a function that they boh can call?
>>> Can you also comment the raw #endif's to what they're endifing?
>>>
>>> Otherwise, this looks okay.
>>>
>>> Coleen
>>>
>>>
>>> On 10/30/15 1:00 PM, Ioi Lam wrote:
>>>> Please review the following fix:
>>>>
>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>>>
>>>> Bug: Clean up and refactor of class loading code for CDS
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8140802
>>>>
>>>> Summary of fix:
>>>>
>>>>     We need to clean up and refactor the class loading code in order
>>>>     to support CDS in JDK9
>>>>
>>>>     [1] Remove code that has been made obsolete by the module changes
>>>>         (such as supporting code used for meta-index file)
>>>>     [2] Add new whitebox API to be used by CDS-related tests.
>>>>     [3] Refactor the parsing of classlist files for future 
>>>> enhancements.
>>>>     [4] Add new APIs in the class loading code to support Oracle 
>>>> CDS enhancements.
>>>>
>>>> Tests:
>>>>
>>>>     JPRT
>>>>     RBT - with same set of tests as hs-rt nightly
>>>>
>>>> Thanks
>>>> - Ioi
>


From coleen.phillimore at oracle.com  Mon Nov  2 19:01:15 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 02 Nov 2015 14:01:15 -0500
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code
	for CDS
In-Reply-To: <5637B227.4050905@oracle.com>
References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com>
	<AEAE2E8A-CD7F-4523-A221-D3640A9FBE98@oracle.com>
	<5633D3A2.6050809@oracle.com> <5637B227.4050905@oracle.com>
Message-ID: <5637B2FB.9080301@oracle.com>



On 11/2/15 1:57 PM, Ioi Lam wrote:
>
>
> On 10/30/15 1:31 PM, Coleen Phillimore wrote:
>>
>>
>> On 10/30/15 4:18 PM, Karen Kinnear wrote:
>>> Coleen,
>>>
>>> Question for you below please ...
>>>> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore 
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>
>>>> Hi Ioi,
>>>> This is a manageable code change.
>>>>
>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html 
>>>>
>>>>
>>>> You forward declare Klass* but don't use it in this header file.
>>>> Also can you add a comment to #endif  to say what it's endifing. 
>>>> ie. // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP
>>>>
>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html 
>>>>
>>>>
>>>>   33   TempNewSymbol class_name_symbol = 
>>>> SymbolTable::new_permanent_symbol(parser->current_class_name(), 
>>>> THREAD);
>>>>
>>>> This doesn't make sense.   If you want a permanent symbol, it 
>>>> doesn't need to get un-reference counted with the TempNewSymbol 
>>>> destructor.
>>> Thank you for chiming in on this one - I wanted your opinion here. 
>>> (this code used to be in MetaspaceShared::
>>> preload_and_dump and I think was wrong there as well).
>>> My understanding is that it is a TempNewSymbol that he wants, so he 
>>> should call SymbolTable::new_symbol.
>>> The code creates a (temporary) symbol for the name, and then calls 
>>> SystemDictionary::resolve_or_null, which if it
>>> succeeds will walk through the classFileParser which will create a 
>>> permanent symbol for the class name,
>>> via the symbol_alloc_batch handling. That would be consistent with 
>>> the TempNewSymbol call in
>>> SystemDictionary::resolve_or_null as well as in parse_stream - all 
>>> places dealing with the class name
>>> before doing classfile parsing.
>>>
>>> Does that make sense?
>>
>> Yes, this makes sense.  The symbol shouldn't be permanent.   Ioi can 
>> test this by putting a strange long name in the classlist file and 
>> make sure it doesn't make it out to the shared archive, since I think 
>> -Xshare:dump cleans out the SymbolTable before dumping.
>>
> After changing to use new_symbol instead of new_permanent_symbol, I 
> ran -Xshare:dump:
>
> $ java -Xshare:dump
> Preload Warning: Cannot find sun/text/normalizer/UnicodeMatcher
> ...
> total   :  13063134 [100.0% of total] out of  27385856 bytes [47.7% used]
>
> $ strings images/jdk/lib/i386/hotspot/classes.jsa | grep 
> sun/text/normalizer/UnicodeMatcher
> sun/text/normalizer/UnicodeMatcher
>
> So the unused symbols are not removed. Anyway, I have filed a separate 
> issue for this: https://bugs.openjdk.java.net/browse/JDK-8141207

I just realized that the reason that it doesn't clean out unused symbols 
is that it would leave gaps in the Metaspace memory where they're 
stored, so there wouldn't be much point.

Coleen

>
> Thanks
> - Ioi
>
>
>> Coleen
>>>
>>> thanks,
>>> Karen
>>>
>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html 
>>>>
>>>>
>>>> +    // Make sure we have an entry in the SystemDictionary on success
>>>>
>>>>
>>>> This assert code is a copy of some code elsewhere.  Can you make it 
>>>> a function that they boh can call?
>>>> Can you also comment the raw #endif's to what they're endifing?
>>>>
>>>> Otherwise, this looks okay.
>>>>
>>>> Coleen
>>>>
>>>>
>>>> On 10/30/15 1:00 PM, Ioi Lam wrote:
>>>>> Please review the following fix:
>>>>>
>>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>>>>
>>>>> Bug: Clean up and refactor of class loading code for CDS
>>>>>
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8140802
>>>>>
>>>>> Summary of fix:
>>>>>
>>>>>     We need to clean up and refactor the class loading code in order
>>>>>     to support CDS in JDK9
>>>>>
>>>>>     [1] Remove code that has been made obsolete by the module changes
>>>>>         (such as supporting code used for meta-index file)
>>>>>     [2] Add new whitebox API to be used by CDS-related tests.
>>>>>     [3] Refactor the parsing of classlist files for future 
>>>>> enhancements.
>>>>>     [4] Add new APIs in the class loading code to support Oracle 
>>>>> CDS enhancements.
>>>>>
>>>>> Tests:
>>>>>
>>>>>     JPRT
>>>>>     RBT - with same set of tests as hs-rt nightly
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>
>


From christian.tornqvist at oracle.com  Mon Nov  2 19:09:37 2015
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 2 Nov 2015 14:09:37 -0500
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
In-Reply-To: <5637B1EC.9000402@oracle.com>
References: <5637A3C6.1000504@oracle.com>
	<108301d1159b$332b87a0$998296e0$@oracle.com>
	<5637B1EC.9000402@oracle.com>
Message-ID: <10d301d115a2$04ede5c0$0ec9b140$@oracle.com>

Hi Kirill,

>I think it indicates that we need a separate error for test bug/environment issue. It will allow us to identify test/env issues easily and assign them directly to SQE avoiding spending any dev time.

I'm still very sceptic how you'd reliably separate the issues into test/environment/product issues and what "SQE avoiding spending any dev time" means?

Again, I'd love to see some examples of why this would be a worthwhile addition. 

Thanks,
Christian

-----Original Message-----
From: Kirill Zhaldybin [mailto:kirill.zhaldybin at oracle.com] 
Sent: Monday, November 2, 2015 1:57 PM
To: Christian Tornqvist <christian.tornqvist at oracle.com>; 'hotspot-dev' <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(XXS): 8141146: Add Error hierarchy to test library

Hi Christian,

We already have more than 2k statements like "throw new testbug" in hotspot/test.
I think it indicates that we need a separate error for test bug/environment issue. It will allow us to identify test/env issues easily and assign them directly to SQE avoiding spending any dev time.

I created a sub-task on new Asserts framework here -
https://bugs.openjdk.java.net/browse/JDK-8141204
We are really appreciate your comments.

Thank you.

Regards, Kirill


On 02.11.2015 21:20, Christian Tornqvist wrote:
> Hi Kirill,
>
> I'm still doubting how useful this would be, can you give some examples of where these different exceptions would be used and what the benefit would be? How would this be used with the current Assert class?
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On 
> Behalf Of Kirill Zhaldybin
> Sent: Monday, November 2, 2015 12:56 PM
> To: hotspot-dev <hotspot-dev at openjdk.java.net>
> Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
>
> Hi,
>
> Could somebody please review this change?
> It adds EnvironmentIssue and TestBug classes for environment issue and test bug correspondingly to the test library.
> It is the first part of JDK-8065651: Enhance Asserts to throw different exceptions for different types of assertions.
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8141146
> WebRev: 
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8141146/webrev.00/
>
> Thank you.
>
> Regards, Kirill
>



From kirill.zhaldybin at oracle.com  Mon Nov  2 19:43:05 2015
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Mon, 02 Nov 2015 22:43:05 +0300
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
In-Reply-To: <10d301d115a2$04ede5c0$0ec9b140$@oracle.com>
References: <5637A3C6.1000504@oracle.com>
	<108301d1159b$332b87a0$998296e0$@oracle.com>
	<5637B1EC.9000402@oracle.com>
	<10d301d115a2$04ede5c0$0ec9b140$@oracle.com>
Message-ID: <5637BCC9.1000805@oracle.com>

Hi Christian,

On 02.11.2015 22:09, Christian Tornqvist wrote:
> Hi Kirill,
>
>> I think it indicates that we need a separate error for test bug/environment issue. It will allow us to identify test/env issues easily and assign them directly to SQE avoiding spending any dev time.
>
> I'm still very sceptic how you'd reliably separate the issues into test/environment/product issues and what "SQE avoiding spending any dev time" means?

I agree that not all issues could be reliably separated but for these 
type of issues no changes will be introduced. As before they will be 
considered as a product issue.

Nonetheless some issues, for example, missed methods in 
compiler/intrinsics/mathexact/sanity/MathIntrinsic.java are likely test 
bugs.
The another example is wrong generated classfile in 
compiler/c1/6932496/Test6932496.java.
gc/g1/humongousObjects/TestHumongousThreshold.java has assertion that 
checks internal test logic and the test would only benefit from separate 
test bug assert.

Environment issue could used in case of different I/O issues that are 
not connected with test logic, already occupied TCP/IP ports etc.

Shura could have more real life example for these cases.

Thank you.

Regards, Kirill

>
> Again, I'd love to see some examples of why this would be a worthwhile addition.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Kirill Zhaldybin [mailto:kirill.zhaldybin at oracle.com]
> Sent: Monday, November 2, 2015 1:57 PM
> To: Christian Tornqvist <christian.tornqvist at oracle.com>; 'hotspot-dev' <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR(XXS): 8141146: Add Error hierarchy to test library
>
> Hi Christian,
>
> We already have more than 2k statements like "throw new testbug" in hotspot/test.
> I think it indicates that we need a separate error for test bug/environment issue. It will allow us to identify test/env issues easily and assign them directly to SQE avoiding spending any dev time.
>
> I created a sub-task on new Asserts framework here -
> https://bugs.openjdk.java.net/browse/JDK-8141204
> We are really appreciate your comments.
>
> Thank you.
>
> Regards, Kirill
>
>
> On 02.11.2015 21:20, Christian Tornqvist wrote:
>> Hi Kirill,
>>
>> I'm still doubting how useful this would be, can you give some examples of where these different exceptions would be used and what the benefit would be? How would this be used with the current Assert class?
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Kirill Zhaldybin
>> Sent: Monday, November 2, 2015 12:56 PM
>> To: hotspot-dev <hotspot-dev at openjdk.java.net>
>> Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
>>
>> Hi,
>>
>> Could somebody please review this change?
>> It adds EnvironmentIssue and TestBug classes for environment issue and test bug correspondingly to the test library.
>> It is the first part of JDK-8065651: Enhance Asserts to throw different exceptions for different types of assertions.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8141146
>> WebRev:
>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8141146/webrev.00/
>>
>> Thank you.
>>
>> Regards, Kirill
>>
>
>


From david.holmes at oracle.com  Mon Nov  2 20:01:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Nov 2015 06:01:04 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
Message-ID: <5637C100.8040405@oracle.com>

Hi Thomas,

On 2/11/2015 9:20 PM, Thomas St?fe wrote:
> Hi David,
>
> some small changes are needed to make this build and run on AIX. I
> attached a patch file with the needed additions.

Thanks!

> I did not run any extensive tests on AIX, so I cannot say for sure if
> this is stable. We (SAP) also may face some problems later when we port
> this to HP-UX, because there, shared libraries using __thread cannot be
> loaded dynamically.

Ouch!

> So, I admit to some small worries, beside the issue with memory leaks on
> older glibc versions. For me, this feels like something which needs
> tight compiler/thread library support from the OS, so it makes us
> vulnerable to running on older systems (older glibc) or building with
> outdated compilers. Therefore it would be nice to have a simple way to
> re-add the pthread-based TLS implementation if needed.

I can't see how to do that without keeping all the existing layers of 
code - even though they would be no-ops on all the platforms that 
support the compiler-based TLS. Basically just extend what I did for 
Solaris to the other platforms.

> Apart from that, I like the patch and think the simplification is good
> and worth the effort.

Even if you can't easily add back the pthread-based TLS if needed?

It is unfortunate that hotspot may still be shackled to the past that 
way - we killed off hotspot-express (in part) to remove those shackles 
and allow us to modernize the codebase.

Thanks,
David

> Kind Regards, Thomas
>
>
>
>
>
>
> On Mon, Nov 2, 2015 at 7:40 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>     Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>     A simple (in principle) but wide-ranging change which should appeal
>     to our Code Deletion Engineer's. We implement Thread::current()
>     using a compiler/language-based thread-local variable eg:
>
>
>       static __thread Thread *_thr_current;
>
>       inline Thread* Thread::current() {
>         return _thr_current;
>       }
>
>     with an appropriate setter of course. By doing this we can
>     completely remove the platform-specific ThreadLocalStorage
>     implementations, and the associated os::thread_local_storage* calls,
>     plus all the uses of ThreadLocalStorage::thread() and
>     ThreadLocalStorage::get_thread_slow(). This extends the previous
>     work done on Solaris to implement ThreadLocalStorage::thread() using
>     compiler-based thread-locals.
>
>     We can also consolidate nearly all the os_cpu versions of
>     MacroAssembler::get_thread on x86 into one cpu specific one ( a
>     special variant is still needed for 32-bit Windows).
>
>     As a result of this change we have further potential cleanups:
>     - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>     completely empty and could also be removed
>     - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>     sp-map "cache" on 32-bit) now has no affect and so could be
>     completely removed from the build system
>
>     I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but
>     could add the removal of the "inline" files to this CR if people
>     think it worth removing them.
>
>     I have one missing piece on Aarch64 - I need to change
>     MacroAssembler::get_thread to simply call Thread::current() as on
>     other platforms, but I don't know how to write that. I would
>     appreciate it if someone could give me the right code for that.
>
>     I would also appreciate comments/testing by the AIX and PPC64 folk
>     as well.
>
>     A concern about memory-leaks had previously been raised, but
>     experiments using simple C code on linux 86 and Solaris showed no
>     issues. Also note that Aarch64 already uses this kind of thread-local.
>
>     Thanks,
>     David
>
>

From coleen.phillimore at oracle.com  Mon Nov  2 22:03:15 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 02 Nov 2015 17:03:15 -0500
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <5636B88A.4080909@oracle.com>
References: <5633E8C9.40709@oracle.com> <5633EC31.6050103@oracle.com>
	<5636B88A.4080909@oracle.com>
Message-ID: <5637DDA3.9020902@oracle.com>


David thank you for looking at this change.

On 11/1/15 8:12 PM, David Holmes wrote:
> Hi Coleen,
>
> Just a superficial review as I'm not familiar with this code.
>
> On 31/10/2015 8:16 AM, Coleen Phillimore wrote:
>>
>> On 10/30/15 6:01 PM, Coleen Phillimore wrote:
>>> Summary: Save Throwable in a list which is a weak GC root for walking
>>> during MetadataOnStackMark
>
> I'm unclear on terminology here. At the Java level an object that is 
> only weakly reachable can be gc'd. But here we seem to use a "weak" 
> root to prevent something being gc'd - ???
>
>>> This was the original implementation that I had for finding Method* in
>>> backtraces but it was slow because I had used jweak to save the
>>> Throwable object.   Using internal vm weak GC roots, this does not
>>> cause a performance regression in refWorkload.  This fix is more
>>> straightforward and does not rely on the constant pool index of the
>>> merged constant pool during redefinition to find the method's name.
>>> This is one fix that enables removing merged constant pools during
>>> redefinition (work in progress).  It also is would be used as a model
>>> for JEP 259: Stack Walking API
>>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>>
>>> The code that registers MemberNames for replacing Method* during
>>> redefinition may need to use the same mechanism for performance, if
>>> MemberName arrays are used for the Stack Walking API.
>>>
>>> I assume this will generate comments from the GC group.
>>>
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>
> Some minor comments:
>
> src/share/vm/classfile/javaClasses.hpp
>
> Typo:   // Mark methods as that are
>
> src/share/vm/classfile/backtrace.hpp
>
> _backtraces_head should be volatile as you update via CAS.
>
> src/share/vm/classfile/backtrace.cpp
>
> Minor nit: the "exchanged" variable in add should really be called 
> "found".

I fixed these issues.

thanks,
Coleen
>
> Thanks,
> David
> -----
>
>>>
>>> Tested with RBT quick (former "quick" tests), jdk/java/lang/instrument
>>> tests and the test that I wrote for handling backtraces with
>>> redefinition in hotspot/test/runtime/RedefineTests.
>>>
>>> Thanks,
>>> Coleen
>>


From coleen.phillimore at oracle.com  Mon Nov  2 22:04:27 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 02 Nov 2015 17:04:27 -0500
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <5637223E.1090804@oracle.com>
References: <5633E8C9.40709@oracle.com> <5633EC31.6050103@oracle.com>
	<5637223E.1090804@oracle.com>
Message-ID: <5637DDEB.5090203@oracle.com>



On 11/2/15 3:43 AM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
>
> The fix looks good to me.
> I like the simplifications!
>
>
> A minor comment:
>
> src/share/vm/classfile/backtrace.hpp
>
> 34 // doesn't get deallocatd.
>
>   typo: deallocatd => deallocated

Thank you Serguei for reviewing this.  I thought you'd like the 
simplification after all the work we've done on this.

I fixed the typo above.

Coleen
>
>
> Thanks,
> Serguei
>
>
> On 10/30/15 15:16, Coleen Phillimore wrote:
>>
>> On 10/30/15 6:01 PM, Coleen Phillimore wrote:
>>> Summary: Save Throwable in a list which is a weak GC root for 
>>> walking during MetadataOnStackMark
>>>
>>> This was the original implementation that I had for finding Method* 
>>> in backtraces but it was slow because I had used jweak to save the 
>>> Throwable object.   Using internal vm weak GC roots, this does not 
>>> cause a performance regression in refWorkload.  This fix is more 
>>> straightforward and does not rely on the constant pool index of the 
>>> merged constant pool during redefinition to find the method's name.
>>> This is one fix that enables removing merged constant pools during 
>>> redefinition (work in progress).  It also is would be used as a 
>>> model for JEP 259: Stack Walking API
>>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>>
>>> The code that registers MemberNames for replacing Method* during 
>>> redefinition may need to use the same mechanism for performance, if 
>>> MemberName arrays are used for the Stack Walking API.
>>>
>>> I assume this will generate comments from the GC group.
>>>
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>
>>>
>>> Tested with RBT quick (former "quick" tests), 
>>> jdk/java/lang/instrument tests and the test that I wrote for 
>>> handling backtraces with redefinition in 
>>> hotspot/test/runtime/RedefineTests.
>>>
>>> Thanks,
>>> Coleen
>>
>


From coleen.phillimore at oracle.com  Mon Nov  2 22:14:50 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 02 Nov 2015 17:14:50 -0500
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <56373301.4030907@oracle.com>
References: <5633E8C9.40709@oracle.com> <56373301.4030907@oracle.com>
Message-ID: <5637E05A.8090007@oracle.com>



On 11/2/15 4:55 AM, Stefan Karlsson wrote:
> Hi Coleen,
>
> I remember this from our earlier discussions about the Backtraces.

Stefan,
Yes, it's back again.   My original change for this was 2012.   All the 
complicated changes we made to avoid this were turning into something of 
a kludge tower and are preventing further improvements.
>
> On 2015-10-30 23:01, Coleen Phillimore wrote:
>> Summary: Save Throwable in a list which is a weak GC root for walking 
>> during MetadataOnStackMark
>>
>> This was the original implementation that I had for finding Method* 
>> in backtraces but it was slow because I had used jweak to save the 
>> Throwable object.
>
> It wasn't the jweak handles that made it slow for the GC. Maybe it 
> made it slower for the runtime?

Yes, it was jweak handles that made it slow for the runtime.  During the 
javac benchmark, the cost of creating these jni handles (taking out a 
lock and adding to a global data structure) was too expensive for all 
the backtraces that the benchmark created.  Most of the backtraces are 
unused but we don't know that when the exceptions are thrown of course.

We didn't measure jweak handling for the GC though.  I suspect that 
wasn't free for GC performance either.
>
>> Using internal vm weak GC roots, this does not cause a performance 
>> regression in refWorkload.  This fix is more straightforward and does 
>> not rely on the constant pool index of the merged constant pool 
>> during redefinition to find the method's name.
>> This is one fix that enables removing merged constant pools during 
>> redefinition (work in progress).  It also is would be used as a model 
>> for JEP 259: Stack Walking API
>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>
>> The code that registers MemberNames for replacing Method* during 
>> redefinition may need to use the same mechanism for performance, if 
>> MemberName arrays are used for the Stack Walking API.
>>
>> I assume this will generate comments from the GC group.
>
> If you run the following small test program, you'll see some of the 
> problems this patch introduces for the GC. It's a contrived test case 
> to make it obvious what the problems with this patch are, but I'd not 
> be surprised if you would see effects from this patch if you looked at 
> the GC pause times from test runs with larger tests.
>
> public class BT {
>   public static void main(String [] args) {
>     while (true) {
>       try {
>         f0(10);
>       } catch (RuntimeException e) {
>         e.fillInStackTrace();
>       }
>     }
>   }
>
>   public static boolean f0(int v) {
>     throw new RuntimeException();
>   }
>   public static boolean f1(int v) { return f0(v);}
>   public static boolean f2(int v) { return f1(v);}
>   public static boolean f3(int v) { return f2(v);}
>   public static boolean f4(int v) { return f3(v);}
>   public static boolean f5(int v) { return f4(v);}
>   public static boolean f6(int v) { return f5(v);}
>   public static boolean f7(int v) { return f6(v);}
>   public static boolean f8(int v) { return f7(v);}
>   public static boolean f9(int v) { return f8(v);}
>   public static boolean fa(int v) { return f9(v);}
>   public static boolean fb(int v) { return fa(v);}
>   public static boolean fc(int v) { return fb(v);}
>   public static boolean fd(int v) { return fc(v);}
>   public static boolean fe(int v) { return fd(v);}
>   public static boolean ff(int v) { return fe(v);}
> }
>
> Running without the patch:
> $ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
> #0: [GC pause (G1 Evacuation Pause) (young) 100M->352K(1024M), 
> 0.0197192 secs]
> #1: [GC pause (G1 Evacuation Pause) (young) 99M->354K(1024M), 
> 0.0096909 secs]
> #2: [GC pause (G1 Evacuation Pause) (young) 99M->366K(1024M), 
> 0.0022548 secs]
> #3: [GC pause (G1 Evacuation Pause) (young) 99M->360K(1024M), 
> 0.0141840 secs]
> #4: [GC pause (G1 Evacuation Pause) (young) 99M->355K(1024M), 
> 0.0037668 secs]
> #5: [GC pause (G1 Evacuation Pause) (young) 99M->370K(1024M), 
> 0.0027435 secs]
> #6: [GC pause (G1 Evacuation Pause) (young) 99M->358K(1024M), 
> 0.0243332 secs]
> ... and it continues like that ...
>
> Running with the patch:
> $ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
> #0: [GC pause (G1 Evacuation Pause) (young) 100M->52M(1024M), 
> 0.3144429 secs]
> #1: [GC pause (G1 Evacuation Pause) (young) 139M->98M(1024M), 
> 0.2848108 secs]
> #2: [GC pause (G1 Evacuation Pause) (young) 185M->143M(1024M), 
> 0.2894741 secs]
> #3: [GC pause (G1 Evacuation Pause) (young) 230M->188M(1024M), 
> 0.2593455 secs]
> #4: [GC pause (G1 Evacuation Pause) (young) 275M->233M(1024M), 
> 0.1987466 secs]
> #5: [GC pause (G1 Evacuation Pause) (young) 320M->279M(1024M), 
> 0.1580889 secs]
> #6: [GC pause (G1 Evacuation Pause) (young) 366M->324M(1024M), 
> 0.1370179 secs]
> #7: [GC pause (G1 Evacuation Pause) (young) 411M->369M(1024M), 
> 0.1382296 secs]
> #8: [GC pause (G1 Evacuation Pause) (young) 456M->414M(1024M), 
> 0.3050619 secs]
> #9: [GC pause (G1 Evacuation Pause) (young) 501M->459M(1024M), 
> 0.1885095 secs]
> #10: [GC pause (G1 Evacuation Pause) (young) 546M->504M(1024M), 
> 0.1608086 secs]
> #11: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 
> 591M->549M(1024M), 0.1846752 secs]
> #12: [GC concurrent-root-region-scan-start]
> #12: [GC concurrent-root-region-scan-end, 0.0051940 secs]
> #12: [GC concurrent-mark-start]
> #12: [GC concurrent-mark-end, 0.0175889 secs]
> #12: [GC remark, 0.0800191 secs]
> #12: [GC cleanup 564M->90M(1024M), 0.0024635 secs]
> #12: [GC concurrent-cleanup-start]
> #12: [GC concurrent-cleanup-end, 0.0019211 secs]
> #13: [GC pause (G1 Evacuation Pause) (young) 162M->120M(1024M), 
> 0.2551443 secs]
> #14: [GC pause (G1 Evacuation Pause) (young) 207M->165M(1024M), 
> 0.1553368 secs]
> #15: [GC pause (G1 Evacuation Pause) (young) 252M->210M(1024M), 
> 0.2132882 secs]
> #16: [GC pause (G1 Evacuation Pause) (young) 297M->255M(1024M), 
> 0.1187748 secs]
> ...
>
> As can be seen, the young GC pause times increase drastically, and the 
> memory isn't cleaned out until we do a full concurrent cycle (or 
> trigger a Full GC).
>

Good, thank you for the test case and what to look for.  I will run the 
simplified version of this test.  I believe you that the pause times 
would increase for the microbenchmark.  Although, I found that the 
average depth of these stack traces was about 6 in real cases and the 
max was 200.

The question I have, then, is can we process this list in parallel with 
other GC root scanning? It's independent of other things.  We will also 
need a strategy to scan MemberNameTable roots if we find that building 
these with jweaks is too expensive for the new StackWalk API.

In this change, I simply added the backtrace GC scanning to 
SystemDictionary because I didn't have a better idea.   Please help find 
a better place for this!

Thanks,
Coleen
> StefanK
>
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>> local webrev at http://javaweb.us.oracle.com/~cphillim/webrev/8140685.01
>>
>> Tested with RBT quick (former "quick" tests), 
>> jdk/java/lang/instrument tests and the test that I wrote for handling 
>> backtraces with redefinition in hotspot/test/runtime/RedefineTests.
>>
>> Thanks,
>> Coleen
>


From david.holmes at oracle.com  Tue Nov  3 02:37:37 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Nov 2015 12:37:37 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5637481D.1040408@redhat.com>
References: <56370567.3090801@oracle.com> <5637138F.8090800@oracle.com>
	<56374581.7080601@oracle.com> <5637481D.1040408@redhat.com>
Message-ID: <56381DF1.4090102@oracle.com>

On 2/11/2015 9:25 PM, Andrew Haley wrote:
> On 02/11/15 11:14, David Holmes wrote:
>> Depends on the platform and the exact circumstances, given the varied
>> caching and other "fast lookup" schemes previously employed (even though
>> this is slow-path code).
>
> It's not just the slow path: from what I remember it's called tens of
> thousands of times at startup, so this really is a worthwhile change.

I was wondering about the continuing validity of those old comments so I 
added in a counter to see how often it does get called during VM startup:

_thr_current_count = 171805, main thread = 162943, other = 8862

I confess to being a little surprised. Of course there is a huge amount 
of potential variance in the "other" part of the count.

David

> Andrew.
>

From ioi.lam at oracle.com  Tue Nov  3 03:40:56 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 02 Nov 2015 19:40:56 -0800
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code
	for CDS
In-Reply-To: <5633A24A.9070800@oracle.com>
References: <5633A24A.9070800@oracle.com>
Message-ID: <56382CC8.9070008@oracle.com>

Hi,

I have updated the webrev to include all the feedback from the past few 
days:

Delta from the previous webrev
http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/

Full changes
http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02/

Change Log:

     + Various formatting and copyright
     + Change in SystemDictionary::resolve_from_stream to support new
       requirement in closed sources.

Thanks
Ioi


On 10/30/15 10:00 AM, Ioi Lam wrote:
> Please review the following fix:
>
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>
> Bug: Clean up and refactor of class loading code for CDS
>
>     https://bugs.openjdk.java.net/browse/JDK-8140802
>
> Summary of fix:
>
>     We need to clean up and refactor the class loading code in order
>     to support CDS in JDK9
>
>     [1] Remove code that has been made obsolete by the module changes
>         (such as supporting code used for meta-index file)
>     [2] Add new whitebox API to be used by CDS-related tests.
>     [3] Refactor the parsing of classlist files for future enhancements.
>     [4] Add new APIs in the class loading code to support Oracle CDS 
> enhancements.
>
> Tests:
>
>     JPRT
>     RBT - with same set of tests as hs-rt nightly
>
> Thanks
> - Ioi


From mikael.gerdin at oracle.com  Tue Nov  3 13:23:37 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 3 Nov 2015 14:23:37 +0100
Subject: RFR (M) 8055283: Expand ResourceHashtable with C_HEAP allocation, 
	removal and some unit tests
In-Reply-To: <56307B89.9060109@oracle.com>
References: <5620B590.20607@oracle.com>
	<20151027114047.GQ15817@ehelin.jrpg.bea.com>
	<562F9043.9000004@oracle.com> <56307B89.9060109@oracle.com>
Message-ID: <5638B559.3070409@oracle.com>

Hi Coleen,
are you ok with the changes in webrev.2?

/Mikael

On 2015-10-28 08:38, Mikael Gerdin wrote:
> Hi Coleen,
>
> On 2015-10-27 15:54, Coleen Phillimore wrote:
>>
>> Hi Mikael,    This looks fine.
>
> Thanks.
>
>>
>> I think it's #ifndef PRODUCT that you should use to wrap the unit test
>> code.
>
> I see, I looked at the block in jni.cpp and you are right.
> It's a bit weird though since most of the actual tests use assert()
> which of course is ifdef ASSERT.
> Anyway, I've changed it as per your request.
>
>>
>> Could you also put some string above it that it's a unit test?  Like in
>> chunkedList.cpp?
>>
>> /////////////// Unit tests ///////////////
>
> Sure, no problem.
>
> Incremental webrev at:
> http://cr.openjdk.java.net/~mgerdin/8055283/webrev.1_to_2/
> Full webrev at:
> http://cr.openjdk.java.net/~mgerdin/8055283/webrev.2
>
> /Mikael
>
>
>>
>> thanks,
>> Coleen
>>
>>
>> On 10/27/15 7:40 AM, Erik Helin wrote:
>>> Hi Mikael,
>>>
>>> On 2015-10-16, Mikael Gerdin wrote:
>>>> Hi all,
>>>>
>>>> Here's an old favorite. I'm yet again in need of a simple-to-use hash
>>>> table
>>>> in a place where resource allocation is impossible to use.
>>> Thanks for taking care of this!
>>>
>>>> The idea is to add a ResourceObj::allocation_type template parameter to
>>>> ResourceHashtable to allow a user to specify C-heap allocation using
>>>> ResourceObj::C_Heap.
>>>>
>>>> Currently if one tries to do
>>>> {
>>>> ResourceMark rm;
>>>> ResourceHash* hash = new (ResourceObj::C_HEAP) ResourceHash();
>>>> hash->put(...)
>>>> }
>>>> hash->get(...)
>>>>
>>>> The get()-call will crash because the allocation of the hash table
>>>> nodes
>>>> does not respect the C_HEAP parameter.
>>>>
>>>> To sweeten the deal a little I add support for removing elements and
>>>> also a
>>>> small bunch of unit tests to verify that the operations work as
>>>> expected.
>>>>
>>>> I also discovered a small issue with the primitive_hash() function
>>>> which is
>>>> the default one:
>>>>    36 template<typename K> unsigned primitive_hash(const K& k) {
>>>>    37   unsigned hash = (unsigned)((uintptr_t)k);
>>>>    38   return hash ^ (hash > 3); // just in case we're dealing with
>>>> aligned
>>>> ptrs
>>>>    39 }
>>>>
>>>> It xors hash with the boolean expression (hash > 3) instead of what was
>>>> probably intended (hash >> 3) to deal with aligned pointers as the
>>>> comment
>>>> suggests.
>>>> It appears that the only user of ResourceHash which doesn't specify
>>>> its own
>>>> hash function is MethodFamily::_member_index so it would be nice if
>>>> someone
>>>> could point me at any default method tests to verify that a proper hash
>>>> function doesn't break anything.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055283
>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8055283/webrev.1/
>>> Please wrap all your test code in #ifdef ASSERT, we don't want it to be
>>> included in product builds. Then you can also get rid of the #ifdef
>>> ASSERT in the test.
>>>
>>> Modulo the above and Thomas's comments, the patch looks good to me. No
>>> need to re-review these changes.
>>>
>>> Thanks,
>>> Erik
>>>
>>>> Testing: JPRT
>>>> RBT (Kitchensnk, hotspot/test/:hotspot_all)
>>>>
>>>>
>>>> Thanks!
>>>> /Mikael
>>
>


From thomas.stuefe at gmail.com  Tue Nov  3 14:14:29 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 3 Nov 2015 15:14:29 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5637C100.8040405@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
Message-ID: <CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>

Hi David,

On Mon, Nov 2, 2015 at 9:01 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 2/11/2015 9:20 PM, Thomas St?fe wrote:
>
>> Hi David,
>>
>> some small changes are needed to make this build and run on AIX. I
>> attached a patch file with the needed additions.
>>
>
> Thanks!
>
>
I also checked Linux ppc64, seems to work fine.



> I did not run any extensive tests on AIX, so I cannot say for sure if
>> this is stable. We (SAP) also may face some problems later when we port
>> this to HP-UX, because there, shared libraries using __thread cannot be
>> loaded dynamically.
>>
>
> Ouch!
>
> So, I admit to some small worries, beside the issue with memory leaks on
>> older glibc versions. For me, this feels like something which needs
>> tight compiler/thread library support from the OS, so it makes us
>> vulnerable to running on older systems (older glibc) or building with
>> outdated compilers. Therefore it would be nice to have a simple way to
>> re-add the pthread-based TLS implementation if needed.
>>
>
> I can't see how to do that without keeping all the existing layers of code
> - even though they would be no-ops on all the platforms that support the
> compiler-based TLS. Basically just extend what I did for Solaris to the
> other platforms.


I took a closer look and I now I worry less. I am confident that in case
our old platforms experience problemswith __thread, we can reintroduce TLS
without too many changes.

Just as a test, I changed the AIX implementation from using __thread back
to pthread tls just by changing implementations for Thread::current(),
Thread::initialize_thread_current() and Thead::clear_thread_current() in
thread.cpp. Works fine as expected. Of course this was just a hack, but if
we need to go back to pthread tls for AIX or any platform, I think it can
be done in a simpler way than before and still be clean.

Not terribly important, but I would prefer if
Thread::initialize_thread_current() and Thead::clear_thread_current() were
not exposed from Thread at all or at least as private as possible.
Thread::initialize_thread_current() is called from the OS layer, but
Thead::clear_thread_current() is only called from within thread.cpp itself
and could be kept at file scope.


>
>
> Apart from that, I like the patch and think the simplification is good
>> and worth the effort.
>>
>
> Even if you can't easily add back the pthread-based TLS if needed?
>

I think we can, if needed.



> It is unfortunate that hotspot may still be shackled to the past that way
> - we killed off hotspot-express (in part) to remove those shackles and
> allow us to modernize the codebase.
>
> Thanks,
> David
>
>
One question about your changes:

Before, Thread::current() would assert instead of returning NULL if called
before Thread::initialize_thread_current() or after
Thead::clear_thread_current() . Now, we just return NULL. Is this intended?

Regards, Thomas



> Kind Regards, Thomas
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 2, 2015 at 7:40 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>     Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>>     A simple (in principle) but wide-ranging change which should appeal
>>     to our Code Deletion Engineer's. We implement Thread::current()
>>     using a compiler/language-based thread-local variable eg:
>>
>>
>>       static __thread Thread *_thr_current;
>>
>>       inline Thread* Thread::current() {
>>         return _thr_current;
>>       }
>>
>>     with an appropriate setter of course. By doing this we can
>>     completely remove the platform-specific ThreadLocalStorage
>>     implementations, and the associated os::thread_local_storage* calls,
>>     plus all the uses of ThreadLocalStorage::thread() and
>>     ThreadLocalStorage::get_thread_slow(). This extends the previous
>>     work done on Solaris to implement ThreadLocalStorage::thread() using
>>     compiler-based thread-locals.
>>
>>     We can also consolidate nearly all the os_cpu versions of
>>     MacroAssembler::get_thread on x86 into one cpu specific one ( a
>>     special variant is still needed for 32-bit Windows).
>>
>>     As a result of this change we have further potential cleanups:
>>     - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>>     completely empty and could also be removed
>>     - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>>     sp-map "cache" on 32-bit) now has no affect and so could be
>>     completely removed from the build system
>>
>>     I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but
>>     could add the removal of the "inline" files to this CR if people
>>     think it worth removing them.
>>
>>     I have one missing piece on Aarch64 - I need to change
>>     MacroAssembler::get_thread to simply call Thread::current() as on
>>     other platforms, but I don't know how to write that. I would
>>     appreciate it if someone could give me the right code for that.
>>
>>     I would also appreciate comments/testing by the AIX and PPC64 folk
>>     as well.
>>
>>     A concern about memory-leaks had previously been raised, but
>>     experiments using simple C code on linux 86 and Solaris showed no
>>     issues. Also note that Aarch64 already uses this kind of thread-local.
>>
>>     Thanks,
>>     David
>>
>>
>>

From coleen.phillimore at oracle.com  Tue Nov  3 14:26:34 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 03 Nov 2015 09:26:34 -0500
Subject: RFR (M) 8055283: Expand ResourceHashtable with C_HEAP allocation, 
	removal and some unit tests
In-Reply-To: <5638B559.3070409@oracle.com>
References: <5620B590.20607@oracle.com>
	<20151027114047.GQ15817@ehelin.jrpg.bea.com>
	<562F9043.9000004@oracle.com> <56307B89.9060109@oracle.com>
	<5638B559.3070409@oracle.com>
Message-ID: <5638C41A.9080003@oracle.com>


Yes, it looks good to me.
Thanks,
Coleen

On 11/3/15 8:23 AM, Mikael Gerdin wrote:
> Hi Coleen,
> are you ok with the changes in webrev.2?
>
> /Mikael
>
> On 2015-10-28 08:38, Mikael Gerdin wrote:
>> Hi Coleen,
>>
>> On 2015-10-27 15:54, Coleen Phillimore wrote:
>>>
>>> Hi Mikael,    This looks fine.
>>
>> Thanks.
>>
>>>
>>> I think it's #ifndef PRODUCT that you should use to wrap the unit test
>>> code.
>>
>> I see, I looked at the block in jni.cpp and you are right.
>> It's a bit weird though since most of the actual tests use assert()
>> which of course is ifdef ASSERT.
>> Anyway, I've changed it as per your request.
>>
>>>
>>> Could you also put some string above it that it's a unit test?  Like in
>>> chunkedList.cpp?
>>>
>>> /////////////// Unit tests ///////////////
>>
>> Sure, no problem.
>>
>> Incremental webrev at:
>> http://cr.openjdk.java.net/~mgerdin/8055283/webrev.1_to_2/
>> Full webrev at:
>> http://cr.openjdk.java.net/~mgerdin/8055283/webrev.2
>>
>> /Mikael
>>
>>
>>>
>>> thanks,
>>> Coleen
>>>
>>>
>>> On 10/27/15 7:40 AM, Erik Helin wrote:
>>>> Hi Mikael,
>>>>
>>>> On 2015-10-16, Mikael Gerdin wrote:
>>>>> Hi all,
>>>>>
>>>>> Here's an old favorite. I'm yet again in need of a simple-to-use hash
>>>>> table
>>>>> in a place where resource allocation is impossible to use.
>>>> Thanks for taking care of this!
>>>>
>>>>> The idea is to add a ResourceObj::allocation_type template 
>>>>> parameter to
>>>>> ResourceHashtable to allow a user to specify C-heap allocation using
>>>>> ResourceObj::C_Heap.
>>>>>
>>>>> Currently if one tries to do
>>>>> {
>>>>> ResourceMark rm;
>>>>> ResourceHash* hash = new (ResourceObj::C_HEAP) ResourceHash();
>>>>> hash->put(...)
>>>>> }
>>>>> hash->get(...)
>>>>>
>>>>> The get()-call will crash because the allocation of the hash table
>>>>> nodes
>>>>> does not respect the C_HEAP parameter.
>>>>>
>>>>> To sweeten the deal a little I add support for removing elements and
>>>>> also a
>>>>> small bunch of unit tests to verify that the operations work as
>>>>> expected.
>>>>>
>>>>> I also discovered a small issue with the primitive_hash() function
>>>>> which is
>>>>> the default one:
>>>>>    36 template<typename K> unsigned primitive_hash(const K& k) {
>>>>>    37   unsigned hash = (unsigned)((uintptr_t)k);
>>>>>    38   return hash ^ (hash > 3); // just in case we're dealing with
>>>>> aligned
>>>>> ptrs
>>>>>    39 }
>>>>>
>>>>> It xors hash with the boolean expression (hash > 3) instead of 
>>>>> what was
>>>>> probably intended (hash >> 3) to deal with aligned pointers as the
>>>>> comment
>>>>> suggests.
>>>>> It appears that the only user of ResourceHash which doesn't specify
>>>>> its own
>>>>> hash function is MethodFamily::_member_index so it would be nice if
>>>>> someone
>>>>> could point me at any default method tests to verify that a proper 
>>>>> hash
>>>>> function doesn't break anything.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055283
>>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8055283/webrev.1/
>>>> Please wrap all your test code in #ifdef ASSERT, we don't want it 
>>>> to be
>>>> included in product builds. Then you can also get rid of the #ifdef
>>>> ASSERT in the test.
>>>>
>>>> Modulo the above and Thomas's comments, the patch looks good to me. No
>>>> need to re-review these changes.
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>> Testing: JPRT
>>>>> RBT (Kitchensnk, hotspot/test/:hotspot_all)
>>>>>
>>>>>
>>>>> Thanks!
>>>>> /Mikael
>>>
>>
>


From jaroslav.bachorik at oracle.com  Tue Nov  3 14:45:51 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 3 Nov 2015 15:45:51 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <1446487615.10865.57.camel@redhat.com>
References: <1446460682.10865.20.camel@redhat.com>
	<56377F17.4050006@oracle.com> <5637871B.30705@oracle.com>
	<1446487615.10865.57.camel@redhat.com>
Message-ID: <5638C89F.2090406@oracle.com>

On 2.11.2015 19:06, Severin Gehwolf wrote:
> Hi,
>
> Thanks Jaroslav and Daniel for the reviews! Comments inline.
>
> On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> > Hi,
> >
> > On 2.11.2015 16:19, Daniel Fuchs wrote:
> >> Hi Severin,
> >>
> >> Adding serviceability-dev at openjdk.java.net into the loop - that's
> >> a better alias than hotspot-dev for this kind of changes - maybe
> >> someone from serviceability-dev will offer to sponsor :-)
> >>
> >> I will let serviceability team members comment on the hotspot
> >> changes.
> >>
> >> ConnectorBootstrap.java
> >>
> >> I have one suggestion and one concern:
> >>
> >> Suggestion: I would suggest to reuse 'csf' (Client Socket Factory)
> >> and
> >> ssf  (Server Socket Factory) variables rather than introduce the
> >> two
> >> new variables rmiServerSocketFactory and rmiClientSocketFactory.
> >> You might want to create a new boolean 'useSocketFactory' variable,
> >> if that makes the code more readable.
> >>
> >> Concern: If I understand correctly how RMI socket factories work,
> >> the client socket factory will be serialized and sent to the client
> >> side. This is problematic for interoperability, as the class may
> >> not
> >> present in the remote client - if the remote client is e.g. jdk 8.
> >>
> >> As far as I can see, your new DefaultClientSocketFactory doesn't do
> >> anything useful - so I would suggest to simply get rid of it, and
> >> only
> >> set the Server Socket Factory when SSL is not involved.
>
> Thanks. Fixed in updated webrev.
>
> >> Tests:
> >>
> >> Concerning the tests - we're trying to get rid of shell scripts
> >> rather than introducing new ones :-)
> >> Could the test be rewritten in pure java using the Process API?
> >>
> >> I believe there's even a test library that will let you do that
> >> easily jdk/test/lib/testlibrary/jdk/testlibrary/
> >> (see ProcessTools.java)
>
> It'll take me a bit to rewrite the test in pure Java, but should be
> fine. This is not yet fixed in the updated webrev.
>
> >> Other:
> >>
> >> Also - I believe the new option should be documented in:
> >> src/java.management/share/conf/management.properties
>
> Docs have been updated
> in src/java.management/share/conf/management.properties.
>
> > I share Daniel's concerns. Also, the part of the changeset is related
> > to javax.rmi.ssl - someone maintaining this library should also
> > comment here.
> >
> > Also, the change is introducing new API (system property) and
> > changing the existing one (adding SslRmiServerSocketFactory public
> > constructors) so compatibility review process will have to be
> > involved.
>
> OK. What exactly is there for me to do? I'm not familiar with this
> process. Note that the intent would be to get this backported to JDK 8.
Not much for you. But for the potential Oracle sponsor this means she will have to remember to go through some extra hoops before integrating your patch.

-JB-

>
> New webrev at:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/
>
> Thanks,
> Severin
>
> > -JB-
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >> On 02/11/15 11:38, Severin Gehwolf wrote:
> >>> Hi,
> >>>
> >>> Here is a patch addressing JDK-6425769. The issue is that the JMX
> >>> agent
> >>> binds to the wildcard address by default, preventing users to use
> >>> system properties for JMX agents on multi-homed hosts. Given a
> >>> host
> >>> with local network interfaces, 192.168.0.1 and 192.168.0.2 say,
> >>> it's
> >>> impossible to start two JMX agents binding to fixed ports but to
> >>> different network interfaces, 192.168.0.1:{9111,9112} and
> >>> 192.168.0.2:{9111,9112} say.
> >>>
> >>> The JDK would bind to all local interfaces by default. In the
> >>> above
> >>> example to 192.168.0.1 *and* 192.168.0.2. The effect is that the
> >>> second
> >>> Java process would get a "Connection refused" error because
> >>> another
> >>> process has already been bound to the specified JMX/RMI port
> >>> pairs.
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/
> >>> 00/
> >>>
> >>> Testing done:
> >>> jdk_jmx and jdk_management tests all pass after this change (no
> >>> regressions). There is also a new JTREG test which fails prior
> >>> this
> >>> change and passes after. Updates to the diagnostic command have
> >>> been
> >>> tested manually.
> >>>
> >>> I understand that, if approved, the JDK and hotspot changes
> >>> should get
> >>> pushed together? Hotspot changes are fairly trivial since it's
> >>> only a
> >>> doc-update for the new JDK property in the relevant diagnostic
> >>> command.
> >>>
> >>> Could someone please review and sponsor this change? Please let
> >>> me know
> >>> if there are questions.
> >>>
> >>> Thanks,
> >>> Severin
> >>>
> >>
> >
>


From coleen.phillimore at oracle.com  Tue Nov  3 15:18:02 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 03 Nov 2015 10:18:02 -0500
Subject: [9] RFR(XS) 8141140: Zero JVM fails to initialize after
	JDK-8078554
In-Reply-To: <1446483458.10865.43.camel@redhat.com>
References: <1446483458.10865.43.camel@redhat.com>
Message-ID: <5638D02A.1020607@oracle.com>


Hi Severin,

How do you build zero?  The build was changed and I can't find the right 
magical combinations of configure flags to give it.

Thanks,
Coleen

On 11/2/15 11:57 AM, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review and sponsor this tiny change? It fixes a
> Zero VM initialization problem happening after JDK-8078554.
>
> My understanding is that AllocatePrefetchDistance received a new
> constraint check with JDK-8078554 which now triggers for a Zero VM
> since Zero didn't explicitly disable prefetching before.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141140
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141140/webrev.01/
>
> Please note that this change depends on the change in [1] since Zero
> does not build for me without it.
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020410.html


From aleksey.shipilev at oracle.com  Tue Nov  3 15:20:50 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 3 Nov 2015 18:20:50 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and setters
	for all types
Message-ID: <5638D0D2.5090609@oracle.com>

Hi,

I would like to have a formal review for a minor nit in
Method::is_accessor. The definition for this method is inconsistent with
its intent: it should accept all accessors, but instead it only  accepts
the specific shapes of getters, and completely ignores setters. See:
   https://bugs.openjdk.java.net/browse/JDK-8140650

This makes compilers to ignore many trivial methods that we might
otherwise inline when all other inline hints have failed. It seems to be
a lingering issue left from interpreters that had the "fast accessors".
While it is an open question should inlining policy treat accessors
differently or not (I stand by "yes, it should"), this is a fix that
makes is_accessors proper:
   http://cr.openjdk.java.net/~shade/8140650/webrev.01/

The only usage for the "old" style is_accessor is Zero, and they would
like to update them after we commit the change:
   http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html

The patch passes JPRT, RBT (hotspot_all), and the new regression test.

It beats me whether this is a runtime, or compiler change -- JIRA bug
flip-flops on that -- so, sending to hotspot-dev at . I think it can be
pushed via hs-comp, given it impacts compilers mostly, and has the
compiler-specific test.

Thanks,
-Aleksey



From sgehwolf at redhat.com  Tue Nov  3 15:23:09 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 03 Nov 2015 16:23:09 +0100
Subject: [9] RFR(XS) 8141140: Zero JVM fails to initialize after
	JDK-8078554
In-Reply-To: <5638D02A.1020607@oracle.com>
References: <1446483458.10865.43.camel@redhat.com>
	<5638D02A.1020607@oracle.com>
Message-ID: <1446564189.3772.28.camel@redhat.com>

Hi Coleen,

On Tue, 2015-11-03 at 10:18 -0500, Coleen Phillimore wrote:
> Hi Severin,
> 
> How do you build zero???The build was changed and I can't find the
> right 
> magical combinations of configure flags to give it.

bash configure \
?--with-boot-jdk="\$JDK_TO_BUILD_WITH" \
?--with-debug-level="\$DEBUG" \
?--disable-zip-debug-info \
?--enable-unlimited-crypto \
?--with-stdc++lib=dynamic \
?--with-num-cores=8 \
?--disable-warnings-as-errors \
?--with-jvm-variants=zero

make \
?DEBUG_BINARIES=true \
?JAVAC_FLAGS=-g \
?STRIP_POLICY=no_strip \
?POST_STRIP_CMD="" \
?DISABLE_INTREE_EC=true \
?images

That's what I use here.

Cheers,
Severin


> Thanks,
> Coleen
> 
> On 11/2/15 11:57 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review and sponsor this tiny change? It fixes
> > a
> > Zero VM initialization problem happening after JDK-8078554.
> > 
> > My understanding is that AllocatePrefetchDistance received a new
> > constraint check with JDK-8078554 which now triggers for a Zero VM
> > since Zero didn't explicitly disable prefetching before.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8141140
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141140/we
> > brev.01/
> > 
> > Please note that this change depends on the change in [1] since
> > Zero
> > does not build for me without it.
> > 
> > Thanks,
> > Severin
> > 
> > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-Novembe
> > r/020410.html
> 


From sgehwolf at redhat.com  Tue Nov  3 15:29:41 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 03 Nov 2015 16:29:41 +0100
Subject: [9] RFR(XS) 8141138: Zero fails to build
In-Reply-To: <5637A5FF.3030304@oracle.com>
References: <1446482507.10865.32.camel@redhat.com>
	<5637A5FF.3030304@oracle.com>
Message-ID: <1446564581.3772.32.camel@redhat.com>

Hi Coleen,

On Mon, 2015-11-02 at 13:05 -0500, Coleen Phillimore wrote:
> Hi,
> 
> This change looks fine.

Thanks for the review.

> I can't build Zero anymore because of some 
> build change that doesn't work for me.??If I can get that figured
> out, 
> I'll sponsor this and the other change for you.

Oh that's unfortunate. Please let me know if there is something I can
do to fix it.

> The build tries to pass -lffi even though I gave it an explicit
> libffi 
> directory.

I see. Just to clarify: you've used "--with-libffi" or "--with-libffi-
include and?--with-libffi-lib", right? I have libffi in a well known
system location (package libffi on Fedora) which does not seem to need
this.

Cheers,
Severin

> Coleen
> 
> On 11/2/15 11:41 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review and - if approved - sponsor this
> > fairly
> > trivial change?
> > 
> > A recent checkout of the hs-rt tree fails to build the Zero
> > variant[1]
> > for the following reasons:
> > 
> > ? * JDK-8136421 (Java Level JVM Compiler Interface) did not update
> > two
> > ????files: src/cpu/zero/vm/relocInfo_zero.cpp
> > ????and src/cpu/zero/vm/compiledIC_zero.cpp. The signature
> > ????of emit_to_interp_stub() has changed. This patch updates it for
> > Zero
> > ????too. poll_return_Relocation::fix_relocation_after_move has been
> > ????removed from header files. This patch removes the Zero stub as
> > well.
> > ? * JDK-8139163 (InstanceKlass::cast passes through NULL) removed
> > the
> > ????k_entry variable. I've updated the code to use the new "ik"
> > variable
> > ????instead.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8141138
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141138/we
> > brev.00/
> > 
> > Thanks,
> > Severin
> > 
> > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/18
> > 2/
> 


From coleen.phillimore at oracle.com  Tue Nov  3 15:33:41 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 03 Nov 2015 10:33:41 -0500
Subject: [9] RFR(XS) 8141138: Zero fails to build
In-Reply-To: <1446564581.3772.32.camel@redhat.com>
References: <1446482507.10865.32.camel@redhat.com>	<5637A5FF.3030304@oracle.com>
	<1446564581.3772.32.camel@redhat.com>
Message-ID: <5638D3D5.5000705@oracle.com>



On 11/3/15 10:29 AM, Severin Gehwolf wrote:
> Hi Coleen,
>
> On Mon, 2015-11-02 at 13:05 -0500, Coleen Phillimore wrote:
>> Hi,
>>
>> This change looks fine.
> Thanks for the review.
>
>> I can't build Zero anymore because of some
>> build change that doesn't work for me.  If I can get that figured
>> out,
>> I'll sponsor this and the other change for you.
> Oh that's unfortunate. Please let me know if there is something I can
> do to fix it.
>
>> The build tries to pass -lffi even though I gave it an explicit
>> libffi
>> directory.
> I see. Just to clarify: you've used "--with-libffi" or "--with-libffi-
> include and --with-libffi-lib", right? I have libffi in a well known
> system location (package libffi on Fedora) which does not seem to need
> this.

I have ubuntu and sudo apt-get install puts libffi in these places 
(which I guess aren't standard).

--with-libffi-lib=/usr/lib/x86_64-linux-gnu 
--with-libffi-include=/usr/include/x86_64-linux-gnu

This gets further but I now have a compilation error

/usr/include/x86_64-linux-gnu/asm/param.h:1:31: fatal error: 
asm-generic/param.h: No such file or directory
  #include <asm-generic/param.h>
                                ^
compilation terminated.
In file included from 
/scratch/cphillim/gcc4.8.2-OEL5.5/x86_64-unknown-linux-gnu/sysroot/usr/include/linux/param.h:4:0,
                  from /usr/include/x86_64-linux-gnu/bits/param.h:28,
                  from /usr/include/x86_64-linux-gnu/sys/param.h:31,
                  from 
/home/cphillim/hg.local/jdk9.zero/hotspot/src/os/linux/vm/jvm_linux.h:45,

Which looks like it's caused by the --with-libffi-include settting.

Coleen
>
> Cheers,
> Severin
>
>> Coleen
>>
>> On 11/2/15 11:41 AM, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could somebody please review and - if approved - sponsor this
>>> fairly
>>> trivial change?
>>>
>>> A recent checkout of the hs-rt tree fails to build the Zero
>>> variant[1]
>>> for the following reasons:
>>>
>>>    * JDK-8136421 (Java Level JVM Compiler Interface) did not update
>>> two
>>>      files: src/cpu/zero/vm/relocInfo_zero.cpp
>>>      and src/cpu/zero/vm/compiledIC_zero.cpp. The signature
>>>      of emit_to_interp_stub() has changed. This patch updates it for
>>> Zero
>>>      too. poll_return_Relocation::fix_relocation_after_move has been
>>>      removed from header files. This patch removes the Zero stub as
>>> well.
>>>    * JDK-8139163 (InstanceKlass::cast passes through NULL) removed
>>> the
>>>      k_entry variable. I've updated the code to use the new "ik"
>>> variable
>>>      instead.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141138
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8141138/we
>>> brev.00/
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/18
>>> 2/


From alejandro.murillo at oracle.com  Tue Nov  3 17:45:31 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 03 Nov 2015 10:45:31 -0700
Subject: [verona.stage] RFR  8139986: Store debug level in java.vm.debug and
	conditionally print in "java -version"
Message-ID: <5638F2BB.8020203@oracle.com>

Please review these changes:

bug: https://bugs.openjdk.java.net/browse/JDK-8139986
Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/

Background:
These changes introduce a new system property named "jdk.debug" intended to
identify the type of the build. The build system has already been 
modified (see [1])
to provide the build type through the "--with-debug-level" configure option,
and  to remove that info from the (new) version string and
consequently from the "java.version" and "java.vm.version" system 
properties.

Here, the configure debug level is used to initialize the value of the 
"jdk.debug" system
property. There are also changes to adapt any code that relied on the 
value of those version
properties to determine the  build type. They were changed to use this 
new property.

The Launcher output was also modified to look as follows:

jdk.debug = (?*foo*? != ?release?)
             $java -version
             java version "9-ea"
             Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
            Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, 
mixed mode)

jdk.debug = ?release?: (no change)

$java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+88)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)


All this will be described and updated in the JEP-223 doc [2] shortly.

[1] https://bugs.openjdk.java.net/browse/JDK-8139951
[2] http://openjdk.java.net/jeps/223

Thanks

-- 
Alejandro


From paul.sandoz at oracle.com  Tue Nov  3 17:58:58 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Nov 2015 18:58:58 +0100
Subject: RFR: String Density/Compact String JEP 254 (update)
In-Reply-To: <5633E16F.8090904@oracle.com>
References: <56129786.1090402@oracle.com> <5633E16F.8090904@oracle.com>
Message-ID: <72CAA66E-6C3C-4CEA-85B6-AF1884688D72@oracle.com>

Hi,

This is a significant body of impressive work, well done all who worked on it.


String
?

 148      * The instance field value is generally opaque to optimizing JIT
 149      * compilers. Therefore, in performance-sensitive place, an explicit
 150      * check of the static boolean {@code COMPACT_STRINGS} is done first
 151      * before checking the {@code coder} field since the static boolean
 152      * {@code COMPACT_STRINGS} would be constant folded away by an
 153      * optimizing JIT compiler. The idioms for these cases are as follows.
...
 172      * @implNote
 173      * The actual value for this field is injected by JVM. The static
 174      * initialization block is used to set the value here to communicate
 175      * that this static final field is not statically foldable, and to
 176      * avoid any possible circular dependency during vm initialization.
 177      */
 178     static final boolean COMPACT_STRINGS;

For those not so knowledgeable on matters the impl note may appear to contradict what is stated previously on constant folding.

You might want to clarify that you don?t want the field to be directly initialized to a constant expression since usages are replaced at compile time with the value of the constant expression.



I notice in some cases for comparisons of this string with another string, such as String.startsWith, when the coders are not equal and this coder is LANTIN1 and the other coder is UTF16 you have a short cut on the assumption that the contents will be different, but in other cases like compareTo or regionMatches this is not the case. Why the difference?

  String a = ? // LATIN1 encoding
  String b = ? // UTF16 encoding, sharing a common prefix with a, and some additional UTF16 chars afterwards

  a.startsWith(b.substring(0, a.length()); // false
  b.startsWith(a); // true

?

Ah, I see that you are compressing in package private constructors, so in effect normalizing to LANTIN1 where possible:

3008      * Package private constructor. Trailing Void argument is there for
3009      * disambiguating it against other (public) constructors.
3010      *
3011      * Stores the char[] value into a byte[] that each byte represents
3012      * the8 low-order bits of the corresponding character, if the char[]
3013      * contains only latin1 character. Or a byte[] that stores all
3014      * characters in their byte sequences defined by the {@code StringUTF16}.
3015      */
3016     String(char[] value, int off, int len, Void sig) {

Thus i think my above example will actually work as expected, since the substring will result in a new string using a LATIN1 coder.

But does my point still apply that the coder checking logic is inconsistently applied?

I cannot quite tell if the normalization is consistently applied or only for certain operations. Perhaps there needs to be some asserts judiciously placed that verify the string content to better catch cases where normalization is unintentionally not applied?


For new tests that use Random you should add the following

 * @key randomness

I stopped there for now.

Paul.

P.S. I hope at some point in the future we can revisit the HotSpot intrinsics for byte[]/char[] equality and comparison with future array mismatch work.



> On 30 Oct 2015, at 22:30, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Thanks for the comments/suggestions. Here are the updated webrevs with minor changes here
> and there based on the feedback.
> 
> http://cr.openjdk.java.net/~sherman/8054307/jdk/
> http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot/
> 
> [closed, Oracle internal only]
> http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot/
> http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot_test_closed/
> 
> The code is ready for integration. The current plan is to integrate via the hotspot repo in coming
> week if it passes the PIT.
> 
> Thanks
> -Sherman
> 
> On 10/5/15 8:30 AM, Xueming Shen wrote:
>> (resent to hotspot-dev at openjdk.java.net)
>> 
>> Hi,
>> 
>> Please review the change for JEP 254/Compact String project.
>> 
>> JPE 254: http://openjdk.java.net/jeps/254
>> Issue:   https://bugs.openjdk.java.net/browse/JDK-8054307
>> Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/
>> http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot
>> 
>> Description:
>> 
>>  String Density project is to change the internal representation of the
>>  String class from a UTF-16 char array to a byte array plus an encoding
>>  flag field. The new String class stores characters encoded either as
>>  ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes
>>  per character), based upon the contents of the string. The encoding
>>  flag indicates which encoding is used. It offers reduced memory footprint
>>  while maintaining throughput performance. See JEP 254 for more additional
>>  information
>> 
>> Implementation repo/try out:
>>  http://hg.openjdk.java.net/jdk9/sandbox/  branch: JDK-8054307-branch
>> 
>>  $ hg clone http://hg.openjdk.java.net/jdk9/sandbox/
>>  $ cd sandbox
>>  $ sh ./get_source.sh
>>  $ sh ./common/bin/hgforest.sh up -r JDK-8054307-branch
>>  $ make configure
>>  $ make images
>> 
>> Implementation Notes:
>> 
>> - To change the internal representation of the String and the String
>>   builder classes (AbstractStringBuilder, StringBuilder and StringBuffer)
>>   from a UTF-16 char array to a byte array plus an encoding flag field.
>> 
>>   The new representation stores the String characters in a single byte
>>   format using the lower 8-bit of character's 16-bit UTF16 value, and
>>   sets the encoding flag as LATIN1, if all characters of the String
>>   object are Unicode Latin1 characters (with its UTF16 value < \u0100)
>> 
>>   It stores the String characters in 2-byte format with their UTF-16 value
>>   and sets the flag as UTF16, if any of the character inside the String
>>   object is NOT Unicode latin1 character.
>> 
>> - To change the method implementation of the String class and its builders
>>   to function on the new internal character storage, mainly to delegate to
>>   two implementation classes StringUTF16 and StringLatin1
>> 
>> - To update the StringCoding class to decoding/encoding the String between
>>   String.byte[]/coder(LATIN1/UTF16) <-> byte[](native encoding) instead
>>   of the original String.char[] <-> byte[] (native encoding)
>> 
>> - To update the hotSpot compiler (new and updated instrinsics), GC (String
>>   Deduplication mods) and Runtime to work with the new internal "byte[] +
>>   coder flag" representation.
>> 
>>   See Tobias's note for details of the hotspot changes:
>> http://cr.openjdk.java.net/~thartmann/compact_strings/hotspot-impl-note
>> 
>> - To add a vm option "CompactStrings" (default is true) to provide a
>>   switch-off mechanism to always store the String characters in UTF16
>>   encoding (always 2 bytes, but still in a byte[], instead of the
>>   original char[]).
>> 
>> 
>> Supporting performance artifacts:
>> 
>> - Report(s) on memory footprint impact
>> 
>> http://cr.openjdk.java.net/~shade/density/string-density-report.pdf
>> 
>>   Latest SPECjbb2005 footprint reduction and throughput numbers for both
>>   Intel (Linux) and SPARC, in which it shows the Compact String binaries
>>   use less memory and have higher throughput.
>> 
>>   latest:http://cr.openjdk.java.net/~sherman/8054307/specjbb2005
>>   old: http://cr.openjdk.java.net/~huntch/string-density/reports/String-Density-SPARC-jbb2005-Report.pdf
>> 
>> - Throughput performance impact via String API micro-benchmarks
>> 
>> http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Haswell_090915.pdf
>> http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/IvyBridge_090915.pdf
>> http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Sparc_090915.pdf
>>   http://cr.openjdk.java.net/~sherman/8054307/string-coding.txt
>> 
>> Thanks,
>> Sherman
> 


From alexandre.iline at oracle.com  Mon Nov  2 21:20:28 2015
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 3 Nov 2015 05:20:28 +0800
Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
In-Reply-To: <5637BCC9.1000805@oracle.com>
References: <5637A3C6.1000504@oracle.com>
	<108301d1159b$332b87a0$998296e0$@oracle.com>
	<5637B1EC.9000402@oracle.com>
	<10d301d115a2$04ede5c0$0ec9b140$@oracle.com>
	<5637BCC9.1000805@oracle.com>
Message-ID: <2633C334-1245-4FDC-9511-9FD9AA3854B0@oracle.com>

Hi,

Kirill, I have two comments:
1. I think that the enhancement description is not thorough enough. You told me more in person than it is in the description.
2. I do not see how the two exception types suggested in the diff are any useful without all the supporting code.

That all said, here is what I believe is a motivation for the enhancement ?

When, while writing an application code, one uses asserts in the code  to verify some assumptions about the state of the application data, etc. (I)

While writing tests, such as some unit or API tests with TestNG, one often uses the asserts to verify that the tested code behaves as expected. (II) 

I have no intention of giving strict definitions to the terms, but the purpose of using asserts is, clearly, different in I and II.

But then a test code could grow bigger, acquire libraries, and become needing assertion usage of the first type to verify state of the test system itself.

What the enhancements suggests therefore, is a way to easily distinguish the two types of usage of assertions: 
 * assertions for state of the test system
 * assertions that the tested code is doing what?s it?s supposed to
the distinctions would clearly be made both in the test source code and the logs, should a test like this fail.

There is also third kind of asserts usage which we happen to deal with often: verifying assumptions about the environment. This, I thought, would be a part of the enhancement.

I do not know if the above helps: this is how I heard guys sharing the idea with me.

I do not have any data to back this up. To get the data, one would have to do a thorough analysis of the assertions usage across a test set of a representative size. I am pretty sure that the asserts for the test system used way less often ? but the test libraries keep growing.

Shura

> On Nov 3, 2015, at 3:43 AM, Kirill Zhaldybin <Kirill.Zhaldybin at oracle.com> wrote:
> 
> Hi Christian,
> 
> On 02.11.2015 22:09, Christian Tornqvist wrote:
>> Hi Kirill,
>> 
>>> I think it indicates that we need a separate error for test bug/environment issue. It will allow us to identify test/env issues easily and assign them directly to SQE avoiding spending any dev time.
>> 
>> I'm still very sceptic how you'd reliably separate the issues into test/environment/product issues and what "SQE avoiding spending any dev time" means?
> 
> I agree that not all issues could be reliably separated but for these type of issues no changes will be introduced. As before they will be considered as a product issue.
> 
> Nonetheless some issues, for example, missed methods in compiler/intrinsics/mathexact/sanity/MathIntrinsic.java are likely test bugs.
> The another example is wrong generated classfile in compiler/c1/6932496/Test6932496.java.
> gc/g1/humongousObjects/TestHumongousThreshold.java has assertion that checks internal test logic and the test would only benefit from separate test bug assert.
> 
> Environment issue could used in case of different I/O issues that are not connected with test logic, already occupied TCP/IP ports etc.
> 
> Shura could have more real life example for these cases.
> 
> Thank you.
> 
> Regards, Kirill
> 
>> 
>> Again, I'd love to see some examples of why this would be a worthwhile addition.
>> 
>> Thanks,
>> Christian
>> 
>> -----Original Message-----
>> From: Kirill Zhaldybin [mailto:kirill.zhaldybin at oracle.com]
>> Sent: Monday, November 2, 2015 1:57 PM
>> To: Christian Tornqvist <christian.tornqvist at oracle.com>; 'hotspot-dev' <hotspot-dev at openjdk.java.net>
>> Subject: Re: RFR(XXS): 8141146: Add Error hierarchy to test library
>> 
>> Hi Christian,
>> 
>> We already have more than 2k statements like "throw new testbug" in hotspot/test.
>> I think it indicates that we need a separate error for test bug/environment issue. It will allow us to identify test/env issues easily and assign them directly to SQE avoiding spending any dev time.
>> 
>> I created a sub-task on new Asserts framework here -
>> https://bugs.openjdk.java.net/browse/JDK-8141204
>> We are really appreciate your comments.
>> 
>> Thank you.
>> 
>> Regards, Kirill
>> 
>> 
>> On 02.11.2015 21:20, Christian Tornqvist wrote:
>>> Hi Kirill,
>>> 
>>> I'm still doubting how useful this would be, can you give some examples of where these different exceptions would be used and what the benefit would be? How would this be used with the current Assert class?
>>> 
>>> Thanks,
>>> Christian
>>> 
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>>> Behalf Of Kirill Zhaldybin
>>> Sent: Monday, November 2, 2015 12:56 PM
>>> To: hotspot-dev <hotspot-dev at openjdk.java.net>
>>> Subject: RFR(XXS): 8141146: Add Error hierarchy to test library
>>> 
>>> Hi,
>>> 
>>> Could somebody please review this change?
>>> It adds EnvironmentIssue and TestBug classes for environment issue and test bug correspondingly to the test library.
>>> It is the first part of JDK-8065651: Enhance Asserts to throw different exceptions for different types of assertions.
>>> 
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8141146
>>> WebRev:
>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8141146/webrev.00/
>>> 
>>> Thank you.
>>> 
>>> Regards, Kirill
>>> 
>> 
>> 
> 


From vladimir.x.ivanov at oracle.com  Tue Nov  3 18:35:46 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 3 Nov 2015 21:35:46 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is not
	MT safe
Message-ID: <5638FE82.4060801@oracle.com>

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

(Thanks to Stefan Karlsson who found the root cause.)

Operations on nmethod dependency contexts (linked lists of 
nmethodBucket*) are either guarded by CodeCache lock or happen during 
safepoints.

Recent GC enhancements introduced parallel code cache processing during 
GC, so parallel GC threads started to concurrently iterate over nmethod 
dependency lists, and it became not safe to remove stale elements 
(count() == 0) anymore.

The initial fix was to delay stale element purging and do a serial pass, 
but it works only for contexts rooted at InstanceKlasses, GC does a 
serial pass over InstanceKlasses afterwards and deletes all stale 
entries. But it doesn't work for call_site_target dependencies which are 
part of contexts rooted at CallSiteContext Java objects.

The problem manifests itself as a crash during dependency list traversal.

The fix I propose is to avoid purging of CallSiteContext contexts at all 
during GC, but remove stale entries during dependency list updates which 
happen under CodeCache lock (see safe_to_purge() check in 
methodHandles.cpp). It happens outside of safepoints and it guarantees 
exclusive access to the list. It is performed during 
j.l.i.CallSite.target updates, CallSite.target inlining, j.l.Class 
unloading, etc. Such approach allows to avoid unbounded memory 
consumption growth, only some delay (till next dependency list update) 
in memory deallocation.

To reduce amount of work at runtime I introduced a dependency list flag, 
which signals there are stale entries. It allows to skip purging if 
there are no stale entries in the list.

As a cleanup I decided to refactor nmethod dependency management code.

I came up with a DependencyContext to encapsulate the logic and used 
CPSlot idea (thanks for the pointer, John) to pack pointer + bool into a 
pointer.

Here's the excerpt from the DependencyContext description:
"Utility class to manipulate nmethod dependency context. The context 
consists of nmethodBucket* (a head of a linked list) and a boolean flag 
(does the list contains stale entries). The structure is encoded as an 
intptr_t: lower bit is used for the flag. It is possible since 
nmethodBucket* is aligned - the structure is malloc'ed in C heap.
Dependency context can be attached either to an InstanceKlass 
(_dep_context field) or CallSiteContext oop for call_site_target 
dependencies (see javaClasses.hpp). DependencyContext class operates on 
some location which holds a intptr_t value."

DependencyContext operates either on InstanceKlass::_dep_context or 
j.l.i.MHN$CallSiteContext::vmdependencies fields.

It allows to remove bool field from InstanceKlass and avoid header 
allocation for CallSiteContext.

Also, I experimented with non-packed version: have 2 fields as is and 
embed DependencyContext into InstanceKlass, but allocate it for 
CallSiteContext. The downsides were: (1) InstanceKlass footprint 
increase in some cases; (2) additional code for CDS case, since 
_dep_context is not shareable; (3) slight native memory footprint 
increase when there are many CallSite instances.

So, I decided to proceed with packed version.

Testing: hotspot/test/compiler/jsr292/CallSiteDepContextTest.java, 
-XX:+ExecuteInternalVMTests, JPRT

Thanks!

Best regards,
Vladimir Ivanov

From daniel.fuchs at oracle.com  Mon Nov  2 15:19:51 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 2 Nov 2015 16:19:51 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <1446460682.10865.20.camel@redhat.com>
References: <1446460682.10865.20.camel@redhat.com>
Message-ID: <56377F17.4050006@oracle.com>

Hi Severin,

Adding serviceability-dev at openjdk.java.net into the loop - that's
a better alias than hotspot-dev for this kind of changes - maybe
someone from serviceability-dev will offer to sponsor :-)

I will let serviceability team members comment on the hotspot changes.

ConnectorBootstrap.java

I have one suggestion and one concern:

Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) and
ssf  (Server Socket Factory) variables rather than introduce the two
new variables rmiServerSocketFactory and rmiClientSocketFactory.
You might want to create a new boolean 'useSocketFactory' variable,
if that makes the code more readable.

Concern: If I understand correctly how RMI socket factories work,
the client socket factory will be serialized and sent to the client
side. This is problematic for interoperability, as the class may not
present in the remote client - if the remote client is e.g. jdk 8.

As far as I can see, your new DefaultClientSocketFactory doesn't do
anything useful - so I would suggest to simply get rid of it, and only
set the Server Socket Factory when SSL is not involved.

Tests:

Concerning the tests - we're trying to get rid of shell scripts
rather than introducing new ones :-)
Could the test be rewritten in pure java using the Process API?

I believe there's even a test library that will let you do that
easily jdk/test/lib/testlibrary/jdk/testlibrary/
(see ProcessTools.java)

Other:

Also - I believe the new option should be documented in:
src/java.management/share/conf/management.properties

best regards,

-- daniel

On 02/11/15 11:38, Severin Gehwolf wrote:
> Hi,
>
> Here is a patch addressing JDK-6425769. The issue is that the JMX agent
> binds to the wildcard address by default, preventing users to use
> system properties for JMX agents on multi-homed hosts. Given a host
> with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's
> impossible to start two JMX agents binding to fixed ports but to
> different network interfaces, 192.168.0.1:{9111,9112} and
> 192.168.0.2:{9111,9112} say.
>
> The JDK would bind to all local interfaces by default. In the above
> example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second
> Java process would get a "Connection refused" error because another
> process has already been bound to the specified JMX/RMI port pairs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/
>
> Testing done:
> jdk_jmx and jdk_management tests all pass after this change (no
> regressions). There is also a new JTREG test which fails prior this
> change and passes after. Updates to the diagnostic command have been
> tested manually.
>
> I understand that, if approved, the JDK and hotspot changes should get
> pushed together? Hotspot changes are fairly trivial since it's only a
> doc-update for the new JDK property in the relevant diagnostic command.
>
> Could someone please review and sponsor this change? Please let me know
> if there are questions.
>
> Thanks,
> Severin
>


From magnus.ihse.bursie at oracle.com  Tue Nov  3 19:24:07 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Nov 2015 20:24:07 +0100
Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug
	and conditionally print in "java -version"
In-Reply-To: <5638F2BB.8020203@oracle.com>
References: <5638F2BB.8020203@oracle.com>
Message-ID: <563909D7.3070907@oracle.com>

Hi Alejandro,

On 2015-11-03 18:45, Alejandro E Murillo wrote:
> Please review these changes:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8139986
> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/

Looks good to me.

/Magnus

>
> Background:
> These changes introduce a new system property named "jdk.debug" 
> intended to
> identify the type of the build. The build system has already been 
> modified (see [1])
> to provide the build type through the "--with-debug-level" configure 
> option,
> and  to remove that info from the (new) version string and
> consequently from the "java.version" and "java.vm.version" system 
> properties.
>
> Here, the configure debug level is used to initialize the value of the 
> "jdk.debug" system
> property. There are also changes to adapt any code that relied on the 
> value of those version
> properties to determine the  build type. They were changed to use this 
> new property.
>
> The Launcher output was also modified to look as follows:
>
> jdk.debug = (?*foo*? != ?release?)
>             $java -version
>             java version "9-ea"
>             Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
>            Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, 
> mixed mode)
>
> jdk.debug = ?release?: (no change)
>
> $java -version
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+88)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)
>
>
> All this will be described and updated in the JEP-223 doc [2] shortly.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8139951
> [2] http://openjdk.java.net/jeps/223
>
> Thanks
>


From alejandro.murillo at oracle.com  Tue Nov  3 19:45:12 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 03 Nov 2015 12:45:12 -0700
Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug
	and conditionally print in "java -version"
In-Reply-To: <563909D7.3070907@oracle.com>
References: <5638F2BB.8020203@oracle.com> <563909D7.3070907@oracle.com>
Message-ID: <56390EC8.4040305@oracle.com>


Thanks Magnus!
Alejandro
On 11/3/2015 12:24 PM, Magnus Ihse Bursie wrote:
> Hi Alejandro,
>
> On 2015-11-03 18:45, Alejandro E Murillo wrote:
>> Please review these changes:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8139986
>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
>
> Looks good to me.
>
> /Magnus
>
>>
>> Background:
>> These changes introduce a new system property named "jdk.debug" 
>> intended to
>> identify the type of the build. The build system has already been 
>> modified (see [1])
>> to provide the build type through the "--with-debug-level" configure 
>> option,
>> and  to remove that info from the (new) version string and
>> consequently from the "java.version" and "java.vm.version" system 
>> properties.
>>
>> Here, the configure debug level is used to initialize the value of 
>> the "jdk.debug" system
>> property. There are also changes to adapt any code that relied on the 
>> value of those version
>> properties to determine the  build type. They were changed to use 
>> this new property.
>>
>> The Launcher output was also modified to look as follows:
>>
>> jdk.debug = (?*foo*? != ?release?)
>>             $java -version
>>             java version "9-ea"
>>             Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
>>            Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, 
>> mixed mode)
>>
>> jdk.debug = ?release?: (no change)
>>
>> $java -version
>> java version "9-ea"
>> Java(TM) SE Runtime Environment (build 9-ea+88)
>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)
>>
>>
>> All this will be described and updated in the JEP-223 doc [2] shortly.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8139951
>> [2] http://openjdk.java.net/jeps/223
>>
>> Thanks
>>
>

-- 
Alejandro


From jborgers at jpinpoint.com  Tue Nov  3 22:21:40 2015
From: jborgers at jpinpoint.com (Jeroen Borgers)
Date: Tue, 3 Nov 2015 23:21:40 +0100
Subject: jdk 9 performance optimizations
Message-ID: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>

Hi,

One of the goals of Jigsaw that intrigue me, I read here: http://openjdk.
java
.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
is:
*Enable ahead-of-time, whole-program optimization techniques*  -
[..]
The optimization techniques envisioned here include, but are not limited
to: Fast lookup of both JDK and application classes; early bytecode
verification; aggressive inlining of, *e.g.*, lambda expressions, and other
standard compiler optimizations; construction of JVM-specific memory images
that can be loaded more efficiently than class files; ahead-of-time
compilation of method bodies to native code; and the removal of unused
fields, methods, and classes. These kinds of techniques tend to work best
when JDK and application code is analyzed together, prior to run time.
[..]

   -

   *Optimize existing code as-is* ? It must be possible to apply the
   optimizer tool to existing code already packaged in traditional jar files,
   without changing those files.
   -

   *Actual optimizations* ? As a proof of concept, provide at least two
   optimizations that deliver nontrivial performance benefits.

I am curious about the following:
* What is the current state of this? Which techniques/optimizations are
already implemented and available from the current ea JDK9 or will be?
* Are there any new insights/developments in this area?
* I noticed in my JMH microbenchmark with parallel stream and lambda's that
it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused by
more aggressive inlining of lambda's?
* It seems to me that some compilation and optimization work is moved from
runtime to link time /AOT time, yet, we don't have profiling information
there, so this will be limited, right? Are there obvious cases which work
well?
* I don't really see why aggressive inlining and std optimizations can now
be more effective. Because there will be less de-optimization events needed
because of better predictability? Can in-lining now take place in two ways,
between platform modules and application? Through interfaces?

Thanks!
Jeroen

From jborgers at jpinpoint.com  Tue Nov  3 22:26:37 2015
From: jborgers at jpinpoint.com (Jeroen Borgers)
Date: Tue, 3 Nov 2015 23:26:37 +0100
Subject: jdk 9 performance optimizations
In-Reply-To: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
Message-ID: <CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>

I posted in jigsaw-dev list before:

I found this interesting presentation "Java goes AOT" from JVM Language
Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc

As presented by Christiaan Thalinger from HS compiler team, AOT is used
with Graal to reduce startup time and quicker peakperformance (tiered).
Currently they don't do any inlining in AOT yet because compilation time
blows up by inlining everything since no profiling information is available
yet. I guess modules and knowing dependencies can help here to reduce this.
Besides test running to generate profiling data.

Regards, Jeroen
Bijlagen
Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
JVMLS 2015 - Java Goes AOT
Vitaly Davidovich
13:09 (10 uur geleden)
aan Jeroen, jigsaw-dev

Yes, I had seen Chris' presentation as well.  Certainly modularization will
help AOT in many ways.  But, I'm particularly interested on the JIT side.
What was meant by aggressive lambda inlining, for example? Can anyone point
at some additional info?

Thanks

sent from my phone
Paul Sandoz <paul.sandoz at oracle.com>
13:32 (9 uur geleden)
aan jigsaw-dev
Hi Vitaly,

Probably worth sending an email to the hotspot-dev at openjdk.java.net <mailto:
hotspot-dev at openjdk.java.net>

> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> Yes, I had seen Chris' presentation as well.  Certainly modularization
will
> help AOT in many ways.  But, I'm particularly interested on the JIT side.
> What was meant by aggressive lambda inlining, for example? Can anyone
point
> at some additional info?
>

I presume it in part might relate to cracking open the lambda ?box?
implementing the targeted functional interface to obtain the underlying
method containing the lambda body, generated by javac, that the box defers
to, then subsituting the indy call to an invocation of that underlying
method. Cue lots of hand waving?

Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at
JVMLS 2014:

  http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
--------

Thanks,

Jeroen

2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:

> Hi,
>
> One of the goals of Jigsaw that intrigue me, I read here: http://openjdk.
> java
> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
> is:
> *Enable ahead-of-time, whole-program optimization techniques*  -
> [..]
> The optimization techniques envisioned here include, but are not limited
> to: Fast lookup of both JDK and application classes; early bytecode
> verification; aggressive inlining of, *e.g.*, lambda expressions, and
> other standard compiler optimizations; construction of JVM-specific memory
> images that can be loaded more efficiently than class files; ahead-of-time
> compilation of method bodies to native code; and the removal of unused
> fields, methods, and classes. These kinds of techniques tend to work best
> when JDK and application code is analyzed together, prior to run time.
> [..]
>
>    -
>
>    *Optimize existing code as-is* ? It must be possible to apply the
>    optimizer tool to existing code already packaged in traditional jar files,
>    without changing those files.
>    -
>
>    *Actual optimizations* ? As a proof of concept, provide at least two
>    optimizations that deliver nontrivial performance benefits.
>
> I am curious about the following:
> * What is the current state of this? Which techniques/optimizations are
> already implemented and available from the current ea JDK9 or will be?
> * Are there any new insights/developments in this area?
> * I noticed in my JMH microbenchmark with parallel stream and lambda's
> that it runs slightly faster on 9_b85 compared to 8_u66. Could this be
> caused by more aggressive inlining of lambda's?
> * It seems to me that some compilation and optimization work is moved from
> runtime to link time /AOT time, yet, we don't have profiling information
> there, so this will be limited, right? Are there obvious cases which work
> well?
> * I don't really see why aggressive inlining and std optimizations can now
> be more effective. Because there will be less de-optimization events needed
> because of better predictability? Can in-lining now take place in two ways,
> between platform modules and application? Through interfaces?
>
> Thanks!
> Jeroen
>
>
>

From daniel.daugherty at oracle.com  Tue Nov  3 22:42:08 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 3 Nov 2015 15:42:08 -0700
Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug
	and conditionally print in "java -version"
In-Reply-To: <5638F2BB.8020203@oracle.com>
References: <5638F2BB.8020203@oracle.com>
Message-ID: <56393840.5040208@oracle.com>

On 11/3/15 10:45 AM, Alejandro E Murillo wrote:
> Please review these changes:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8139986
> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/

jdk/src/java.base/share/classes/sun/misc/Version.java.template
     nit: L103:         if (jdk_debug_level.startsWith("release") )
         Please delete extra space between right parens.

         Also, looks like other single line if-statements in
         this file uses this format:

             if (expr) {
                 statement;
             }

jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java
     No comments.

hotspot/make/aix/makefiles/vm.make
     No comments.

hotspot/make/bsd/makefiles/vm.make
     No comments.

hotspot/make/linux/makefiles/vm.make
     No comments.

hotspot/make/solaris/makefiles/vm.make
     No comments.

hotspot/make/windows/makefiles/defs.make
     No comments.

hotspot/make/windows/makefiles/vm.make
     No comments.

hotspot/make/windows/projectfiles/common/Makefile
     No comments.

hotspot/src/share/vm/runtime/arguments.cpp
     No comments.

hotspot/src/share/vm/runtime/statSampler.cpp
     No comments.

hotspot/src/share/vm/runtime/vm_version.cpp
     nit L68   #error DEBUG_LEVEL  must be defined
         Please delete the extra space before "must be..."

hotspot/src/share/vm/runtime/vm_version.hpp
     No comments.

hotspot/test/testlibrary/jdk/test/lib/Platform.java
     No comments.


Thumbs up. If you fix the minor style issues above,
I don't need to see another webrev.

Dan


>
> Background:
> These changes introduce a new system property named "jdk.debug" 
> intended to
> identify the type of the build. The build system has already been 
> modified (see [1])
> to provide the build type through the "--with-debug-level" configure 
> option,
> and  to remove that info from the (new) version string and
> consequently from the "java.version" and "java.vm.version" system 
> properties.
>
> Here, the configure debug level is used to initialize the value of the 
> "jdk.debug" system
> property. There are also changes to adapt any code that relied on the 
> value of those version
> properties to determine the  build type. They were changed to use this 
> new property.
>
> The Launcher output was also modified to look as follows:
>
> jdk.debug = (?*foo*? != ?release?)
>             $java -version
>             java version "9-ea"
>             Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
>            Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, 
> mixed mode)
>
> jdk.debug = ?release?: (no change)
>
> $java -version
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+88)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)
>
>
> All this will be described and updated in the JEP-223 doc [2] shortly.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8139951
> [2] http://openjdk.java.net/jeps/223
>
> Thanks
>


From coleen.phillimore at oracle.com  Tue Nov  3 23:23:21 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 03 Nov 2015 18:23:21 -0500
Subject: RFR 8140685: Fix backtrace building to not rely on constant pool
	merging
In-Reply-To: <56373301.4030907@oracle.com>
References: <5633E8C9.40709@oracle.com> <56373301.4030907@oracle.com>
Message-ID: <563941E9.9040007@oracle.com>


I withdraw this change.  Kim helped me find something better to do.

Also I didn't realize that the backtrace list would keep the backtraces 
alive through young collections.

Thanks,
Coleen

On 11/2/15 4:55 AM, Stefan Karlsson wrote:
> Hi Coleen,
>
> I remember this from our earlier discussions about the Backtraces.
>
> On 2015-10-30 23:01, Coleen Phillimore wrote:
>> Summary: Save Throwable in a list which is a weak GC root for walking 
>> during MetadataOnStackMark
>>
>> This was the original implementation that I had for finding Method* 
>> in backtraces but it was slow because I had used jweak to save the 
>> Throwable object.
>
> It wasn't the jweak handles that made it slow for the GC. Maybe it 
> made it slower for the runtime?
>
>> Using internal vm weak GC roots, this does not cause a performance 
>> regression in refWorkload.  This fix is more straightforward and does 
>> not rely on the constant pool index of the merged constant pool 
>> during redefinition to find the method's name.
>> This is one fix that enables removing merged constant pools during 
>> redefinition (work in progress).  It also is would be used as a model 
>> for JEP 259: Stack Walking API
>> https://bugs.openjdk.java.net/browse/JDK-8043814.
>>
>> The code that registers MemberNames for replacing Method* during 
>> redefinition may need to use the same mechanism for performance, if 
>> MemberName arrays are used for the Stack Walking API.
>>
>> I assume this will generate comments from the GC group.
>
> If you run the following small test program, you'll see some of the 
> problems this patch introduces for the GC. It's a contrived test case 
> to make it obvious what the problems with this patch are, but I'd not 
> be surprised if you would see effects from this patch if you looked at 
> the GC pause times from test runs with larger tests.
>
> public class BT {
>   public static void main(String [] args) {
>     while (true) {
>       try {
>         f0(10);
>       } catch (RuntimeException e) {
>         e.fillInStackTrace();
>       }
>     }
>   }
>
>   public static boolean f0(int v) {
>     throw new RuntimeException();
>   }
>   public static boolean f1(int v) { return f0(v);}
>   public static boolean f2(int v) { return f1(v);}
>   public static boolean f3(int v) { return f2(v);}
>   public static boolean f4(int v) { return f3(v);}
>   public static boolean f5(int v) { return f4(v);}
>   public static boolean f6(int v) { return f5(v);}
>   public static boolean f7(int v) { return f6(v);}
>   public static boolean f8(int v) { return f7(v);}
>   public static boolean f9(int v) { return f8(v);}
>   public static boolean fa(int v) { return f9(v);}
>   public static boolean fb(int v) { return fa(v);}
>   public static boolean fc(int v) { return fb(v);}
>   public static boolean fd(int v) { return fc(v);}
>   public static boolean fe(int v) { return fd(v);}
>   public static boolean ff(int v) { return fe(v);}
> }
>
> Running without the patch:
> $ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
> #0: [GC pause (G1 Evacuation Pause) (young) 100M->352K(1024M), 
> 0.0197192 secs]
> #1: [GC pause (G1 Evacuation Pause) (young) 99M->354K(1024M), 
> 0.0096909 secs]
> #2: [GC pause (G1 Evacuation Pause) (young) 99M->366K(1024M), 
> 0.0022548 secs]
> #3: [GC pause (G1 Evacuation Pause) (young) 99M->360K(1024M), 
> 0.0141840 secs]
> #4: [GC pause (G1 Evacuation Pause) (young) 99M->355K(1024M), 
> 0.0037668 secs]
> #5: [GC pause (G1 Evacuation Pause) (young) 99M->370K(1024M), 
> 0.0027435 secs]
> #6: [GC pause (G1 Evacuation Pause) (young) 99M->358K(1024M), 
> 0.0243332 secs]
> ... and it continues like that ...
>
> Running with the patch:
> $ java -Xmx1g -Xms1g -Xmn100m -XX:+PrintGC -cp . BT
> #0: [GC pause (G1 Evacuation Pause) (young) 100M->52M(1024M), 
> 0.3144429 secs]
> #1: [GC pause (G1 Evacuation Pause) (young) 139M->98M(1024M), 
> 0.2848108 secs]
> #2: [GC pause (G1 Evacuation Pause) (young) 185M->143M(1024M), 
> 0.2894741 secs]
> #3: [GC pause (G1 Evacuation Pause) (young) 230M->188M(1024M), 
> 0.2593455 secs]
> #4: [GC pause (G1 Evacuation Pause) (young) 275M->233M(1024M), 
> 0.1987466 secs]
> #5: [GC pause (G1 Evacuation Pause) (young) 320M->279M(1024M), 
> 0.1580889 secs]
> #6: [GC pause (G1 Evacuation Pause) (young) 366M->324M(1024M), 
> 0.1370179 secs]
> #7: [GC pause (G1 Evacuation Pause) (young) 411M->369M(1024M), 
> 0.1382296 secs]
> #8: [GC pause (G1 Evacuation Pause) (young) 456M->414M(1024M), 
> 0.3050619 secs]
> #9: [GC pause (G1 Evacuation Pause) (young) 501M->459M(1024M), 
> 0.1885095 secs]
> #10: [GC pause (G1 Evacuation Pause) (young) 546M->504M(1024M), 
> 0.1608086 secs]
> #11: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 
> 591M->549M(1024M), 0.1846752 secs]
> #12: [GC concurrent-root-region-scan-start]
> #12: [GC concurrent-root-region-scan-end, 0.0051940 secs]
> #12: [GC concurrent-mark-start]
> #12: [GC concurrent-mark-end, 0.0175889 secs]
> #12: [GC remark, 0.0800191 secs]
> #12: [GC cleanup 564M->90M(1024M), 0.0024635 secs]
> #12: [GC concurrent-cleanup-start]
> #12: [GC concurrent-cleanup-end, 0.0019211 secs]
> #13: [GC pause (G1 Evacuation Pause) (young) 162M->120M(1024M), 
> 0.2551443 secs]
> #14: [GC pause (G1 Evacuation Pause) (young) 207M->165M(1024M), 
> 0.1553368 secs]
> #15: [GC pause (G1 Evacuation Pause) (young) 252M->210M(1024M), 
> 0.2132882 secs]
> #16: [GC pause (G1 Evacuation Pause) (young) 297M->255M(1024M), 
> 0.1187748 secs]
> ...
>
> As can be seen, the young GC pause times increase drastically, and the 
> memory isn't cleaned out until we do a full concurrent cycle (or 
> trigger a Full GC).
>
> StefanK
>
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>> local webrev at http://javaweb.us.oracle.com/~cphillim/webrev/8140685.01
>>
>> Tested with RBT quick (former "quick" tests), 
>> jdk/java/lang/instrument tests and the test that I wrote for handling 
>> backtraces with redefinition in hotspot/test/runtime/RedefineTests.
>>
>> Thanks,
>> Coleen
>


From alejandro.murillo at oracle.com  Wed Nov  4 00:11:35 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 03 Nov 2015 17:11:35 -0700
Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug
	and conditionally print in "java -version"
In-Reply-To: <56393840.5040208@oracle.com>
References: <5638F2BB.8020203@oracle.com> <56393840.5040208@oracle.com>
Message-ID: <56394D37.5020000@oracle.com>


On 11/3/2015 3:42 PM, Daniel D. Daugherty wrote:
> On 11/3/15 10:45 AM, Alejandro E Murillo wrote:
>> Please review these changes:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8139986
>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
>
> jdk/src/java.base/share/classes/sun/misc/Version.java.template
>     nit: L103:         if (jdk_debug_level.startsWith("release") )
>         Please delete extra space between right parens.
>
will fix that
> Also, looks like other single line if-statements in
>         this file uses this format:
>
>             if (expr) {
>                 statement;
>             }
right, will also fix that
thanks Dan!
Alejandro
>
> jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java
>     No comments.
>
> hotspot/make/aix/makefiles/vm.make
>     No comments.
>
> hotspot/make/bsd/makefiles/vm.make
>     No comments.
>
> hotspot/make/linux/makefiles/vm.make
>     No comments.
>
> hotspot/make/solaris/makefiles/vm.make
>     No comments.
>
> hotspot/make/windows/makefiles/defs.make
>     No comments.
>
> hotspot/make/windows/makefiles/vm.make
>     No comments.
>
> hotspot/make/windows/projectfiles/common/Makefile
>     No comments.
>
> hotspot/src/share/vm/runtime/arguments.cpp
>     No comments.
>
> hotspot/src/share/vm/runtime/statSampler.cpp
>     No comments.
>
> hotspot/src/share/vm/runtime/vm_version.cpp
>     nit L68   #error DEBUG_LEVEL  must be defined
>         Please delete the extra space before "must be..."
>
> hotspot/src/share/vm/runtime/vm_version.hpp
>     No comments.
>
> hotspot/test/testlibrary/jdk/test/lib/Platform.java
>     No comments.
>
>
> Thumbs up. If you fix the minor style issues above,
> I don't need to see another webrev.
>
> Dan
>
>
>>
>> Background:
>> These changes introduce a new system property named "jdk.debug" 
>> intended to
>> identify the type of the build. The build system has already been 
>> modified (see [1])
>> to provide the build type through the "--with-debug-level" configure 
>> option,
>> and  to remove that info from the (new) version string and
>> consequently from the "java.version" and "java.vm.version" system 
>> properties.
>>
>> Here, the configure debug level is used to initialize the value of 
>> the "jdk.debug" system
>> property. There are also changes to adapt any code that relied on the 
>> value of those version
>> properties to determine the  build type. They were changed to use 
>> this new property.
>>
>> The Launcher output was also modified to look as follows:
>>
>> jdk.debug = (?*foo*? != ?release?)
>>             $java -version
>>             java version "9-ea"
>>             Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
>>            Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, 
>> mixed mode)
>>
>> jdk.debug = ?release?: (no change)
>>
>> $java -version
>> java version "9-ea"
>> Java(TM) SE Runtime Environment (build 9-ea+88)
>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)
>>
>>
>> All this will be described and updated in the JEP-223 doc [2] shortly.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8139951
>> [2] http://openjdk.java.net/jeps/223
>>
>> Thanks
>>
>

-- 
Alejandro


From david.holmes at oracle.com  Wed Nov  4 03:52:35 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Nov 2015 13:52:35 +1000
Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug
	and conditionally print in "java -version"
In-Reply-To: <5638F2BB.8020203@oracle.com>
References: <5638F2BB.8020203@oracle.com>
Message-ID: <56398103.3000105@oracle.com>

Looks good to me!

Thanks,
David

On 4/11/2015 3:45 AM, Alejandro E Murillo wrote:
> Please review these changes:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8139986
> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
>
> Background:
> These changes introduce a new system property named "jdk.debug" intended to
> identify the type of the build. The build system has already been
> modified (see [1])
> to provide the build type through the "--with-debug-level" configure
> option,
> and  to remove that info from the (new) version string and
> consequently from the "java.version" and "java.vm.version" system
> properties.
>
> Here, the configure debug level is used to initialize the value of the
> "jdk.debug" system
> property. There are also changes to adapt any code that relied on the
> value of those version
> properties to determine the  build type. They were changed to use this
> new property.
>
> The Launcher output was also modified to look as follows:
>
> jdk.debug = (?*foo*? != ?release?)
>              $java -version
>              java version "9-ea"
>              Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
>             Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88,
> mixed mode)
>
> jdk.debug = ?release?: (no change)
>
> $java -version
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+88)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)
>
>
> All this will be described and updated in the JEP-223 doc [2] shortly.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8139951
> [2] http://openjdk.java.net/jeps/223
>
> Thanks
>

From david.holmes at oracle.com  Wed Nov  4 04:08:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Nov 2015 14:08:48 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
Message-ID: <563984D0.8030501@oracle.com>

Hi Thomas,

On 4/11/2015 12:14 AM, Thomas St?fe wrote:
> On Mon, Nov 2, 2015 at 9:01 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>     On 2/11/2015 9:20 PM, Thomas St?fe wrote:
>         some small changes are needed to make this build and run on AIX. I
>         attached a patch file with the needed additions.
>
> I also checked Linux ppc64, seems to work fine.

Excellent! Thank you!

>         I did not run any extensive tests on AIX, so I cannot say for
>         sure if
>         this is stable. We (SAP) also may face some problems later when
>         we port
>         this to HP-UX, because there, shared libraries using __thread
>         cannot be loaded dynamically.
>
>     Ouch!
>
>         So, I admit to some small worries, beside the issue with memory
>         leaks on
>         older glibc versions. For me, this feels like something which needs
>         tight compiler/thread library support from the OS, so it makes us
>         vulnerable to running on older systems (older glibc) or building
>         with
>         outdated compilers. Therefore it would be nice to have a simple
>         way to re-add the pthread-based TLS implementation if needed.
>
>     I can't see how to do that without keeping all the existing layers
>     of code - even though they would be no-ops on all the platforms that
>     support the compiler-based TLS. Basically just extend what I did for
>     Solaris to the other platforms.
>
> I took a closer look and I now I worry less. I am confident that in case
> our old platforms experience problemswith __thread, we can reintroduce
> TLS without too many changes.
>
> Just as a test, I changed the AIX implementation from using __thread
> back to pthread tls just by changing implementations for
> Thread::current(), Thread::initialize_thread_current() and
> Thead::clear_thread_current() in thread.cpp. Works fine as expected. Of
> course this was just a hack, but if we need to go back to pthread tls
> for AIX or any platform, I think it can be done in a simpler way than
> before and still be clean.

Thanks for looking into this in detail! Yes I've been thinking about 
this too, and I think three of four simple hooks will allow the basic 
pthread-TLS mechanism to be reinstated, in shared code, but without any 
of the per-platform fancy caching schemes. There will be a single 
threadLocalStorage.cpp file in a platform specific directory; and of 
course MacroAssembler::get_thread may need to be os/cpu specific. I will 
look further into this, but may defer its implementation to a follow up 
issue.

> Not terribly important, but I would prefer if
> Thread::initialize_thread_current() and Thead::clear_thread_current()
> were not exposed from Thread at all or at least as private as possible.
> Thread::initialize_thread_current() is called from the OS layer, but
> Thead::clear_thread_current() is only called from within thread.cpp
> itself and could be kept at file scope.

As you note the initialize function has to be exposed as it is needed in 
the OS thread startup code. But I can make the clear function private.

>         Apart from that, I like the patch and think the simplification
>         is good and worth the effort.
>
>     Even if you can't easily add back the pthread-based TLS if needed?
>
> I think we can, if needed.

Ok.

>     It is unfortunate that hotspot may still be shackled to the past
>     that way - we killed off hotspot-express (in part) to remove those
>     shackles and allow us to modernize the codebase.
>
>     Thanks,
>     David
>
>
> One question about your changes:
>
> Before, Thread::current() would assert instead of returning NULL if
> called before Thread::initialize_thread_current() or after
> Thead::clear_thread_current() . Now, we just return NULL. Is this intended?

Ah great question ... so before we have a mix of calls to:

- Thread::current()  (asserts on NULL as does JavaThread::current)
- ThreadLocalStorage::thread() (can return NULL)
- ThreadLocalStorage::get_thread_slow() (can return NULL)

and now we only have Thread::current() which means we have to allow 
returning NULL because it can be intentionally called when a thread is 
not attached. That means we won't directly catch calls to 
Thread::current() from code that doesn't realize it is calling it "too 
soon" - though there do exist numerous assertions in the callers of 
Thread::current() that check the result is not NULL.

I could add the assert to Thread::current() and also add 
Thread::current_or_null() to be used by code that needs to use it to 
check for attachment (ie JNI code). I'd also have to examine all the 
changed ThreadLocalStorage::thread/get_thread_slow call-sites to see if 
any of those legitimately expect the thread may not be attached.

What do you think?

I also need to look at the location of Thread::current in the .hpp file 
rather than .inline.hpp and reconcile that with comments regarding the 
noinline version (which is only used in g1HotCardCache.hpp).

Thanks,
David


> Regards, Thomas
>
>         Kind Regards, Thomas
>
>
>
>
>
>
>         On Mon, Nov 2, 2015 at 7:40 AM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>              Open webrev:
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>              A simple (in principle) but wide-ranging change which
>         should appeal
>              to our Code Deletion Engineer's. We implement Thread::current()
>              using a compiler/language-based thread-local variable eg:
>
>
>                static __thread Thread *_thr_current;
>
>                inline Thread* Thread::current() {
>                  return _thr_current;
>                }
>
>              with an appropriate setter of course. By doing this we can
>              completely remove the platform-specific ThreadLocalStorage
>              implementations, and the associated
>         os::thread_local_storage* calls,
>              plus all the uses of ThreadLocalStorage::thread() and
>              ThreadLocalStorage::get_thread_slow(). This extends the
>         previous
>              work done on Solaris to implement
>         ThreadLocalStorage::thread() using
>              compiler-based thread-locals.
>
>              We can also consolidate nearly all the os_cpu versions of
>              MacroAssembler::get_thread on x86 into one cpu specific one ( a
>              special variant is still needed for 32-bit Windows).
>
>              As a result of this change we have further potential cleanups:
>              - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>              completely empty and could also be removed
>              - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>              sp-map "cache" on 32-bit) now has no affect and so could be
>              completely removed from the build system
>
>              I plan to do the MINIMIZE_RAM_USAGE removal as a follow up
>         CR, but
>              could add the removal of the "inline" files to this CR if
>         people
>              think it worth removing them.
>
>              I have one missing piece on Aarch64 - I need to change
>              MacroAssembler::get_thread to simply call Thread::current()
>         as on
>              other platforms, but I don't know how to write that. I would
>              appreciate it if someone could give me the right code for that.
>
>              I would also appreciate comments/testing by the AIX and
>         PPC64 folk
>              as well.
>
>              A concern about memory-leaks had previously been raised, but
>              experiments using simple C code on linux 86 and Solaris
>         showed no
>              issues. Also note that Aarch64 already uses this kind of
>         thread-local.
>
>              Thanks,
>              David
>
>
>

From alejandro.murillo at oracle.com  Wed Nov  4 06:13:12 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 03 Nov 2015 23:13:12 -0700
Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug
	and conditionally print in "java -version"
In-Reply-To: <56398103.3000105@oracle.com>
References: <5638F2BB.8020203@oracle.com> <56398103.3000105@oracle.com>
Message-ID: <5639A1F8.4010403@oracle.com>


Thanks David!
Alejandro

On 11/3/2015 8:52 PM, David Holmes wrote:
> Looks good to me!
>
> Thanks,
> David
>
> On 4/11/2015 3:45 AM, Alejandro E Murillo wrote:
>> Please review these changes:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8139986
>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/
>>
>> Background:
>> These changes introduce a new system property named "jdk.debug" 
>> intended to
>> identify the type of the build. The build system has already been
>> modified (see [1])
>> to provide the build type through the "--with-debug-level" configure
>> option,
>> and  to remove that info from the (new) version string and
>> consequently from the "java.version" and "java.vm.version" system
>> properties.
>>
>> Here, the configure debug level is used to initialize the value of the
>> "jdk.debug" system
>> property. There are also changes to adapt any code that relied on the
>> value of those version
>> properties to determine the  build type. They were changed to use this
>> new property.
>>
>> The Launcher output was also modified to look as follows:
>>
>> jdk.debug = (?*foo*? != ?release?)
>>              $java -version
>>              java version "9-ea"
>>              Java(TM) SE Runtime Environment (*foo *build 9-ea+88)
>>             Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88,
>> mixed mode)
>>
>> jdk.debug = ?release?: (no change)
>>
>> $java -version
>> java version "9-ea"
>> Java(TM) SE Runtime Environment (build 9-ea+88)
>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode)
>>
>>
>> All this will be described and updated in the JEP-223 doc [2] shortly.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8139951
>> [2] http://openjdk.java.net/jeps/223
>>
>> Thanks
>>

-- 
Alejandro


From thomas.stuefe at gmail.com  Wed Nov  4 08:17:29 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 4 Nov 2015 09:17:29 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563984D0.8030501@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
Message-ID: <CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>

Hi David,

On Wed, Nov 4, 2015 at 5:08 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
>
>> One question about your changes:
>>
>> Before, Thread::current() would assert instead of returning NULL if
>> called before Thread::initialize_thread_current() or after
>> Thead::clear_thread_current() . Now, we just return NULL. Is this
>> intended?
>>
>
> Ah great question ... so before we have a mix of calls to:
>
> - Thread::current()  (asserts on NULL as does JavaThread::current)
> - ThreadLocalStorage::thread() (can return NULL)
> - ThreadLocalStorage::get_thread_slow() (can return NULL)
>
> and now we only have Thread::current() which means we have to allow
> returning NULL because it can be intentionally called when a thread is not
> attached. That means we won't directly catch calls to Thread::current()
> from code that doesn't realize it is calling it "too soon" - though there
> do exist numerous assertions in the callers of Thread::current() that check
> the result is not NULL.
>
> I could add the assert to Thread::current() and also add
> Thread::current_or_null() to be used by code that needs to use it to check
> for attachment (ie JNI code). I'd also have to examine all the changed
> ThreadLocalStorage::thread/get_thread_slow call-sites to see if any of
> those legitimately expect the thread may not be attached.
>
> What do you think?
>
>
I would prefer having Thread::current() to assert and to have a
Thread::current_or_null() for cases where NULL could occurr. I tend to hit
that assert a lot in development, it is useful. And the non-asserting
version gets already used in a number of places, also in our (not OpenJDK)
coding.


> I also need to look at the location of Thread::current in the .hpp file
> rather than .inline.hpp and reconcile that with comments regarding the
> noinline version (which is only used in g1HotCardCache.hpp).
>
>
Could we leave just the inline version in thread.hpp and remove the
noinline version altogether? Now that Thread::current() is very simple, we
may just as well keep it in the class body like the other accessors.

Thanks, Thomas



>

From david.holmes at oracle.com  Wed Nov  4 09:26:16 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Nov 2015 19:26:16 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
Message-ID: <5639CF38.5060800@oracle.com>

On 4/11/2015 6:17 PM, Thomas St?fe wrote:
> Hi David,
>
> On Wed, Nov 4, 2015 at 5:08 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>
>         One question about your changes:
>
>         Before, Thread::current() would assert instead of returning NULL if
>         called before Thread::initialize_thread_current() or after
>         Thead::clear_thread_current() . Now, we just return NULL. Is
>         this intended?
>
>
>     Ah great question ... so before we have a mix of calls to:
>
>     - Thread::current()  (asserts on NULL as does JavaThread::current)
>     - ThreadLocalStorage::thread() (can return NULL)
>     - ThreadLocalStorage::get_thread_slow() (can return NULL)
>
>     and now we only have Thread::current() which means we have to allow
>     returning NULL because it can be intentionally called when a thread
>     is not attached. That means we won't directly catch calls to
>     Thread::current() from code that doesn't realize it is calling it
>     "too soon" - though there do exist numerous assertions in the
>     callers of Thread::current() that check the result is not NULL.
>
>     I could add the assert to Thread::current() and also add
>     Thread::current_or_null() to be used by code that needs to use it to
>     check for attachment (ie JNI code). I'd also have to examine all the
>     changed ThreadLocalStorage::thread/get_thread_slow call-sites to see
>     if any of those legitimately expect the thread may not be attached.
>
>     What do you think?
>
>
> I would prefer having Thread::current() to assert and to have a
> Thread::current_or_null() for cases where NULL could occurr. I tend to
> hit that assert a lot in development, it is useful. And the
> non-asserting version gets already used in a number of places, also in
> our (not OpenJDK) coding.

Yes I agree. Most of the TLS::thread() and TLS::get_thread_slow() should 
actually call Thread::current_or_null(). I also found a couple of 
existing Thread::current()'s that should be current_or_null(). :)

>     I also need to look at the location of Thread::current in the .hpp
>     file rather than .inline.hpp and reconcile that with comments
>     regarding the noinline version (which is only used in
>     g1HotCardCache.hpp).
>
>
> Could we leave just the inline version in thread.hpp and remove the
> noinline version altogether? Now that Thread::current() is very simple,
> we may just as well keep it in the class body like the other accessors.

I'll see if the g1 code can tolerate that.

I'll update a prepare a new webrev tomorrow.

Thanks,
David

> Thanks, Thomas
>
>

From sgehwolf at redhat.com  Wed Nov  4 10:54:36 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 04 Nov 2015 11:54:36 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <5638C89F.2090406@oracle.com>
References: <1446460682.10865.20.camel@redhat.com>
	<56377F17.4050006@oracle.com> <5637871B.30705@oracle.com>
	<1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com>
Message-ID: <1446634476.3554.8.camel@redhat.com>

Hi,

Updated webrev with jtreg test in Java:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
bug:?https://bugs.openjdk.java.net/browse/JDK-6425769

I believe this updated webrev addresses all concerns and incorporates
suggestions brought up by Jaroslav and Daniel.

I'm still looking for a sponsor and a hotspot/servicability-dev
reviewer. Could somebody maintaining javax.rmi.ssl have a look at this
as well? Thank you!

Cheers,
Severin

On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote:
> On 2.11.2015 19:06, Severin Gehwolf wrote:
> > Hi,
> > 
> > Thanks Jaroslav and Daniel for the reviews! Comments inline.
> > 
> > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> > > Hi,
> > > 
> > > On 2.11.2015 16:19, Daniel Fuchs wrote:
> > > > Hi Severin,
> > > > 
> > > > Adding serviceability-dev at openjdk.java.net into the loop -
> > > > that's
> > > > a better alias than hotspot-dev for this kind of changes -
> > > > maybe
> > > > someone from serviceability-dev will offer to sponsor :-)
> > > > 
> > > > I will let serviceability team members comment on the hotspot
> > > > changes.
> > > > 
> > > > ConnectorBootstrap.java
> > > > 
> > > > I have one suggestion and one concern:
> > > > 
> > > > Suggestion: I would suggest to reuse 'csf' (Client Socket
> > > > Factory)
> > > > and
> > > > ssf??(Server Socket Factory) variables rather than introduce
> > > > the
> > > > two
> > > > new variables rmiServerSocketFactory and
> > > > rmiClientSocketFactory.
> > > > You might want to create a new boolean 'useSocketFactory'
> > > > variable,
> > > > if that makes the code more readable.
> > > > 
> > > > Concern: If I understand correctly how RMI socket factories
> > > > work,
> > > > the client socket factory will be serialized and sent to the
> > > > client
> > > > side. This is problematic for interoperability, as the class
> > > > may
> > > > not
> > > > present in the remote client - if the remote client is e.g. jdk
> > > > 8.
> > > > 
> > > > As far as I can see, your new DefaultClientSocketFactory
> > > > doesn't do
> > > > anything useful - so I would suggest to simply get rid of it,
> > > > and
> > > > only
> > > > set the Server Socket Factory when SSL is not involved.
> > 
> > Thanks. Fixed in updated webrev.
> > 
> > > > Tests:
> > > > 
> > > > Concerning the tests - we're trying to get rid of shell scripts
> > > > rather than introducing new ones :-)
> > > > Could the test be rewritten in pure java using the Process API?
> > > > 
> > > > I believe there's even a test library that will let you do that
> > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/
> > > > (see ProcessTools.java)
> > 
> > It'll take me a bit to rewrite the test in pure Java, but should be
> > fine. This is not yet fixed in the updated webrev.
> > 
> > > > Other:
> > > > 
> > > > Also - I believe the new option should be documented in:
> > > > src/java.management/share/conf/management.properties
> > 
> > Docs have been updated
> > in src/java.management/share/conf/management.properties.
> > 
> > > I share Daniel's concerns. Also, the part of the changeset is
> > > related
> > > to javax.rmi.ssl - someone maintaining this library should also
> > > comment here.
> > > 
> > > Also, the change is introducing new API (system property) and
> > > changing the existing one (adding SslRmiServerSocketFactory
> > > public
> > > constructors) so compatibility review process will have to be
> > > involved.
> > 
> > OK. What exactly is there for me to do? I'm not familiar with this
> > process. Note that the intent would be to get this backported to
> > JDK 8.
> Not much for you. But for the potential Oracle sponsor this means she
> will have to remember to go through some extra hoops before
> integrating your patch.

I see. Thanks for clarifying it.

> -JB-
> 
> > 
> > New webrev at:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/
> > 
> > Thanks,
> > Severin
> > 
> > > -JB-
> > > > 
> > > > best regards,
> > > > 
> > > > -- daniel
> > > > 
> > > > On 02/11/15 11:38, Severin Gehwolf wrote:
> > > > > Hi,
> > > > > 
> > > > > Here is a patch addressing JDK-6425769. The issue is that the
> > > > > JMX
> > > > > agent
> > > > > binds to the wildcard address by default, preventing users to
> > > > > use
> > > > > system properties for JMX agents on multi-homed hosts. Given
> > > > > a
> > > > > host
> > > > > with local network interfaces, 192.168.0.1 and 192.168.0.2
> > > > > say,
> > > > > it's
> > > > > impossible to start two JMX agents binding to fixed ports but
> > > > > to
> > > > > different network interfaces, 192.168.0.1:{9111,9112} and
> > > > > 192.168.0.2:{9111,9112} say.
> > > > > 
> > > > > The JDK would bind to all local interfaces by default. In the
> > > > > above
> > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that
> > > > > the
> > > > > second
> > > > > Java process would get a "Connection refused" error because
> > > > > another
> > > > > process has already been bound to the specified JMX/RMI port
> > > > > pairs.
> > > > > 
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425
> > > > > 769/
> > > > > 00/
> > > > > 
> > > > > Testing done:
> > > > > jdk_jmx and jdk_management tests all pass after this change
> > > > > (no
> > > > > regressions). There is also a new JTREG test which fails
> > > > > prior
> > > > > this
> > > > > change and passes after. Updates to the diagnostic command
> > > > > have
> > > > > been
> > > > > tested manually.
> > > > > 
> > > > > I understand that, if approved, the JDK and hotspot changes
> > > > > should get
> > > > > pushed together? Hotspot changes are fairly trivial since
> > > > > it's
> > > > > only a
> > > > > doc-update for the new JDK property in the relevant
> > > > > diagnostic
> > > > > command.
> > > > > 
> > > > > Could someone please review and sponsor this change? Please
> > > > > let
> > > > > me know
> > > > > if there are questions.
> > > > > 
> > > > > Thanks,
> > > > > Severin
> > > > > 
> > > > 
> > > 
> > 
> 


From nils.eliasson at oracle.com  Wed Nov  4 14:44:32 2015
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 4 Nov 2015 15:44:32 +0100
Subject: RFR(S): 8141424: [Testbug] CompilerDirectivesDCMDTest.java
	testing flag that is missing in product builds
In-Reply-To: <563A0747.4030707@oracle.com>
References: <563A0747.4030707@oracle.com>
Message-ID: <563A19D0.5080907@oracle.com>

Including hotspot-dev. This patch will be pushed to jdk9/hotspot.

Regards,
Nils

On 2015-11-04 14:25, Nils Eliasson wrote:
> Hi,
>
> Please review.
>
> Problem:
> JDK-8140239 Made the IGVPrintLevel flag not_product but forgot to fix 
> the tests accordingly.
>
> Summary:
> Removing the IGVPrintLevel flag from the test and adding another flag 
> that tests int type flags.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8141424
> webrev: http://cr.openjdk.java.net/~neliasso/8141424/webrev.01/
>
> Regards,
> Nils
>
>


From roland.westrelin at oracle.com  Wed Nov  4 15:00:42 2015
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 4 Nov 2015 16:00:42 +0100
Subject: RFR(S): 8141424: [Testbug] CompilerDirectivesDCMDTest.java
	testing flag that is missing in product builds
In-Reply-To: <563A19D0.5080907@oracle.com>
References: <563A0747.4030707@oracle.com> <563A19D0.5080907@oracle.com>
Message-ID: <38D6771C-5E1F-4386-8E82-ECF19F73A1DB@oracle.com>

>> webrev: http://cr.openjdk.java.net/~neliasso/8141424/webrev.01/

That looks good to me.

Roland.

From volker.simonis at gmail.com  Wed Nov  4 18:21:11 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 4 Nov 2015 19:21:11 +0100
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
Message-ID: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>

Hi,

can somebody please review and sponsor the following tiny build fix:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
https://bugs.openjdk.java.net/browse/JDK-8141416

Building hotspot on certain systems results in a series of:
expr: syntax error
expr: syntax error
expr: syntax error
expr: syntax error

It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
-dumpversion" doesn't print a micro-version:

Ubuntu:
$ gcc -dumpversion
4.6

Any other Linux:
$ gcc -dumpversion
4.8.3

This "feature" is tracked under
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
been fixed for gcc 4.9 but won't be fixed for older versions of gcc.

In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
gcc and use it in the following way:

CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f3)

ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
$(CC_VER_MICRO) = 1), 1)
  $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
supported because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
endif

The shell expression results in a syntax error if $(CC_VER_MICRO)
because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"

Thank you and best regards,
Volker

From chris.plummer at oracle.com  Thu Nov  5 02:25:53 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 4 Nov 2015 18:25:53 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to
	updated to 4.1 b12
Message-ID: <563ABE31.8010807@oracle.com>

Please review the following changes:

http://cr.openjdk.java.net/~cjplummer/8141489/
https://bugs.openjdk.java.net/browse/JDK-8141489

The changes I did for 8140189 require that version 4.1 b12 of jtreg be 
used, so TEST.ROOT has been updated to reflect this.

Testing with JPRT right now. I also ran with b11 and confirmed that the 
following errors are produced for hotspot and jdk tests:

     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test 
requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.

     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test 
requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.

thanks,

Chris

From david.holmes at oracle.com  Thu Nov  5 03:27:30 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Nov 2015 13:27:30 +1000
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563ABE31.8010807@oracle.com>
References: <563ABE31.8010807@oracle.com>
Message-ID: <563ACCA2.1060000@oracle.com>

Looks good to me Chris!

Thanks,
David

On 5/11/2015 12:25 PM, Chris Plummer wrote:
> Please review the following changes:
>
> http://cr.openjdk.java.net/~cjplummer/8141489/
> https://bugs.openjdk.java.net/browse/JDK-8141489
>
> The changes I did for 8140189 require that version 4.1 b12 of jtreg be
> used, so TEST.ROOT has been updated to reflect this.
>
> Testing with JPRT right now. I also ran with b11 and confirmed that the
> following errors are produced for hotspot and jdk tests:
>
>      Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test
> requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.
>
>      Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test
> requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.
>
> thanks,
>
> Chris

From david.holmes at oracle.com  Thu Nov  5 04:36:32 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Nov 2015 14:36:32 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5639CF38.5060800@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com>
Message-ID: <563ADCD0.1070800@oracle.com>

Here's updated webrev:

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v3/

Changes since v2:

- include Thomas's AIX fixes
- Add assertion for not-NULL into Thread::current()
- Add Thread::current_or_null() for when NULL can be expected, or for 
where failing an assert would cause more problems (eg crash reporting). 
Most uses of ThreadLocalStorage::thread()/get_thread_slow() now call 
current_or_null().
- Removed Thread::current_noinline() (it was only used in an assert in 
some G1 code, so the inline-or-not seems irrelevant)
- Made Thread::clear_thread_current() private

I'm debating whether the get_thread implementations should call 
Thread::current() or Thread::current_or_null(). We should never get NULL 
but seems unnecessary overhead to check that with an assert in this 
code. Opinions welcomed.

I still need some assistance from Aarch64 folk to write their get_thread 
function please!

I still have footprint and performance measurements to make before 
proposing formal RFR.

I also am still to determine whether to include the ability to hook in a 
pthread_ based implementation instead.

Thanks,
David

On 4/11/2015 7:26 PM, David Holmes wrote:
> On 4/11/2015 6:17 PM, Thomas St?fe wrote:
>> Hi David,
>>
>> On Wed, Nov 4, 2015 at 5:08 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>
>>         One question about your changes:
>>
>>         Before, Thread::current() would assert instead of returning
>> NULL if
>>         called before Thread::initialize_thread_current() or after
>>         Thead::clear_thread_current() . Now, we just return NULL. Is
>>         this intended?
>>
>>
>>     Ah great question ... so before we have a mix of calls to:
>>
>>     - Thread::current()  (asserts on NULL as does JavaThread::current)
>>     - ThreadLocalStorage::thread() (can return NULL)
>>     - ThreadLocalStorage::get_thread_slow() (can return NULL)
>>
>>     and now we only have Thread::current() which means we have to allow
>>     returning NULL because it can be intentionally called when a thread
>>     is not attached. That means we won't directly catch calls to
>>     Thread::current() from code that doesn't realize it is calling it
>>     "too soon" - though there do exist numerous assertions in the
>>     callers of Thread::current() that check the result is not NULL.
>>
>>     I could add the assert to Thread::current() and also add
>>     Thread::current_or_null() to be used by code that needs to use it to
>>     check for attachment (ie JNI code). I'd also have to examine all the
>>     changed ThreadLocalStorage::thread/get_thread_slow call-sites to see
>>     if any of those legitimately expect the thread may not be attached.
>>
>>     What do you think?
>>
>>
>> I would prefer having Thread::current() to assert and to have a
>> Thread::current_or_null() for cases where NULL could occurr. I tend to
>> hit that assert a lot in development, it is useful. And the
>> non-asserting version gets already used in a number of places, also in
>> our (not OpenJDK) coding.
>
> Yes I agree. Most of the TLS::thread() and TLS::get_thread_slow() should
> actually call Thread::current_or_null(). I also found a couple of
> existing Thread::current()'s that should be current_or_null(). :)
>
>>     I also need to look at the location of Thread::current in the .hpp
>>     file rather than .inline.hpp and reconcile that with comments
>>     regarding the noinline version (which is only used in
>>     g1HotCardCache.hpp).
>>
>>
>> Could we leave just the inline version in thread.hpp and remove the
>> noinline version altogether? Now that Thread::current() is very simple,
>> we may just as well keep it in the class body like the other accessors.
>
> I'll see if the g1 code can tolerate that.
>
> I'll update a prepare a new webrev tomorrow.
>
> Thanks,
> David
>
>> Thanks, Thomas
>>
>>

From thomas.stuefe at gmail.com  Thu Nov  5 07:04:24 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 5 Nov 2015 08:04:24 +0100
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
Message-ID: <CAA-vtUz1PtAA2S=d3nSS-V=s+zCSCKYQ5cK3qmOQjbQTVgxjXg@mail.gmail.com>

Hi Volker,

looks fine and builds fine on Ubuntu 14.4.

...Thomas

On Wed, Nov 4, 2015 at 7:21 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi,
>
> can somebody please review and sponsor the following tiny build fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
> https://bugs.openjdk.java.net/browse/JDK-8141416
>
> Building hotspot on certain systems results in a series of:
> expr: syntax error
> expr: syntax error
> expr: syntax error
> expr: syntax error
>
> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
> -dumpversion" doesn't print a micro-version:
>
> Ubuntu:
> $ gcc -dumpversion
> 4.6
>
> Any other Linux:
> $ gcc -dumpversion
> 4.8.3
>
> This "feature" is tracked under
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
>
> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
> gcc and use it in the following way:
>
> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.'
> -f3)
>
> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
> $(CC_VER_MICRO) = 1), 1)
>   $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
> supported because of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
> endif
>
> The shell expression results in a syntax error if $(CC_VER_MICRO)
> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
>
> Thank you and best regards,
> Volker
>

From staffan.larsen at oracle.com  Thu Nov  5 07:25:58 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 5 Nov 2015 08:25:58 +0100
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563ABE31.8010807@oracle.com>
References: <563ABE31.8010807@oracle.com>
Message-ID: <D2E02FE8-C588-4DAE-9C01-93BCE0616A61@oracle.com>

Looks good!

Thanks,
/Staffan

> On 5 nov. 2015, at 03:25, Chris Plummer <chris.plummer at oracle.com> wrote:
> 
> Please review the following changes:
> 
> http://cr.openjdk.java.net/~cjplummer/8141489/
> https://bugs.openjdk.java.net/browse/JDK-8141489
> 
> The changes I did for 8140189 require that version 4.1 b12 of jtreg be used, so TEST.ROOT has been updated to reflect this.
> 
> Testing with JPRT right now. I also ran with b11 and confirmed that the following errors are produced for hotspot and jdk tests:
> 
>    Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.
> 
>    Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.
> 
> thanks,
> 
> Chris


From chris.plummer at oracle.com  Thu Nov  5 07:40:00 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 4 Nov 2015 23:40:00 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <D2E02FE8-C588-4DAE-9C01-93BCE0616A61@oracle.com>
References: <563ABE31.8010807@oracle.com>
	<D2E02FE8-C588-4DAE-9C01-93BCE0616A61@oracle.com>
Message-ID: <563B07D0.5060406@oracle.com>

Thanks David and Staffan!

Chris

On 11/4/15 11:25 PM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
>> On 5 nov. 2015, at 03:25, Chris Plummer <chris.plummer at oracle.com> wrote:
>>
>> Please review the following changes:
>>
>> http://cr.openjdk.java.net/~cjplummer/8141489/
>> https://bugs.openjdk.java.net/browse/JDK-8141489
>>
>> The changes I did for 8140189 require that version 4.1 b12 of jtreg be used, so TEST.ROOT has been updated to reflect this.
>>
>> Testing with JPRT right now. I also ran with b11 and confirmed that the following errors are produced for hotspot and jdk tests:
>>
>>     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.
>>
>>     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 b11.
>>
>> thanks,
>>
>> Chris


From vladimir.x.ivanov at oracle.com  Thu Nov  5 08:02:02 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 5 Nov 2015 11:02:02 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <5638FE82.4060801@oracle.com>
References: <5638FE82.4060801@oracle.com>
Message-ID: <563B0CFA.8070508@oracle.com>

Hey! Any Reviews, please? :-)

Let me know if the overall approach looks sane to you.

Best regards,
Vladimir Ivanov

On 11/3/15 9:35 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8139595
>
> (Thanks to Stefan Karlsson who found the root cause.)
>
> Operations on nmethod dependency contexts (linked lists of
> nmethodBucket*) are either guarded by CodeCache lock or happen during
> safepoints.
>
> Recent GC enhancements introduced parallel code cache processing during
> GC, so parallel GC threads started to concurrently iterate over nmethod
> dependency lists, and it became not safe to remove stale elements
> (count() == 0) anymore.
>
> The initial fix was to delay stale element purging and do a serial pass,
> but it works only for contexts rooted at InstanceKlasses, GC does a
> serial pass over InstanceKlasses afterwards and deletes all stale
> entries. But it doesn't work for call_site_target dependencies which are
> part of contexts rooted at CallSiteContext Java objects.
>
> The problem manifests itself as a crash during dependency list traversal.
>
> The fix I propose is to avoid purging of CallSiteContext contexts at all
> during GC, but remove stale entries during dependency list updates which
> happen under CodeCache lock (see safe_to_purge() check in
> methodHandles.cpp). It happens outside of safepoints and it guarantees
> exclusive access to the list. It is performed during
> j.l.i.CallSite.target updates, CallSite.target inlining, j.l.Class
> unloading, etc. Such approach allows to avoid unbounded memory
> consumption growth, only some delay (till next dependency list update)
> in memory deallocation.
>
> To reduce amount of work at runtime I introduced a dependency list flag,
> which signals there are stale entries. It allows to skip purging if
> there are no stale entries in the list.
>
> As a cleanup I decided to refactor nmethod dependency management code.
>
> I came up with a DependencyContext to encapsulate the logic and used
> CPSlot idea (thanks for the pointer, John) to pack pointer + bool into a
> pointer.
>
> Here's the excerpt from the DependencyContext description:
> "Utility class to manipulate nmethod dependency context. The context
> consists of nmethodBucket* (a head of a linked list) and a boolean flag
> (does the list contains stale entries). The structure is encoded as an
> intptr_t: lower bit is used for the flag. It is possible since
> nmethodBucket* is aligned - the structure is malloc'ed in C heap.
> Dependency context can be attached either to an InstanceKlass
> (_dep_context field) or CallSiteContext oop for call_site_target
> dependencies (see javaClasses.hpp). DependencyContext class operates on
> some location which holds a intptr_t value."
>
> DependencyContext operates either on InstanceKlass::_dep_context or
> j.l.i.MHN$CallSiteContext::vmdependencies fields.
>
> It allows to remove bool field from InstanceKlass and avoid header
> allocation for CallSiteContext.
>
> Also, I experimented with non-packed version: have 2 fields as is and
> embed DependencyContext into InstanceKlass, but allocate it for
> CallSiteContext. The downsides were: (1) InstanceKlass footprint
> increase in some cases; (2) additional code for CDS case, since
> _dep_context is not shareable; (3) slight native memory footprint
> increase when there are many CallSite instances.
>
> So, I decided to proceed with packed version.
>
> Testing: hotspot/test/compiler/jsr292/CallSiteDepContextTest.java,
> -XX:+ExecuteInternalVMTests, JPRT
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov

From erik.joelsson at oracle.com  Thu Nov  5 09:20:10 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Nov 2015 10:20:10 +0100
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
Message-ID: <563B1F4A.2020205@oracle.com>

Looks good to me.

/Erik

On 2015-11-04 19:21, Volker Simonis wrote:
> Hi,
>
> can somebody please review and sponsor the following tiny build fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
> https://bugs.openjdk.java.net/browse/JDK-8141416
>
> Building hotspot on certain systems results in a series of:
> expr: syntax error
> expr: syntax error
> expr: syntax error
> expr: syntax error
>
> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
> -dumpversion" doesn't print a micro-version:
>
> Ubuntu:
> $ gcc -dumpversion
> 4.6
>
> Any other Linux:
> $ gcc -dumpversion
> 4.8.3
>
> This "feature" is tracked under
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
>
> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
> gcc and use it in the following way:
>
> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f3)
>
> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
> $(CC_VER_MICRO) = 1), 1)
>    $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
> supported because of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
> endif
>
> The shell expression results in a syntax error if $(CC_VER_MICRO)
> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
>
> Thank you and best regards,
> Volker


From volker.simonis at gmail.com  Thu Nov  5 09:26:18 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 5 Nov 2015 10:26:18 +0100
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <563B1F4A.2020205@oracle.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
	<563B1F4A.2020205@oracle.com>
Message-ID: <CA+3eh10_ab9UtoSkt=kgeVGFVnDb04aa=xmh4Fp21JW=s1LBvA@mail.gmail.com>

Thanks everybody for the reviews, but I still need a sponsor because
unfortunately it is still impossible to push to the hotspot repo from
outside "The Firm" :)


On Thu, Nov 5, 2015 at 10:20 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Looks good to me.
>
> /Erik
>
>
> On 2015-11-04 19:21, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review and sponsor the following tiny build fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
>> https://bugs.openjdk.java.net/browse/JDK-8141416
>>
>> Building hotspot on certain systems results in a series of:
>> expr: syntax error
>> expr: syntax error
>> expr: syntax error
>> expr: syntax error
>>
>> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
>> -dumpversion" doesn't print a micro-version:
>>
>> Ubuntu:
>> $ gcc -dumpversion
>> 4.6
>>
>> Any other Linux:
>> $ gcc -dumpversion
>> 4.8.3
>>
>> This "feature" is tracked under
>> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
>> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
>>
>> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
>> gcc and use it in the following way:
>>
>> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.'
>> -f3)
>>
>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
>> $(CC_VER_MICRO) = 1), 1)
>>    $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
>> supported because of
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
>> endif
>>
>> The shell expression results in a syntax error if $(CC_VER_MICRO)
>> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
>>
>> Thank you and best regards,
>> Volker
>
>

From erik.joelsson at oracle.com  Thu Nov  5 09:41:29 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Nov 2015 10:41:29 +0100
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <CA+3eh10_ab9UtoSkt=kgeVGFVnDb04aa=xmh4Fp21JW=s1LBvA@mail.gmail.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
	<563B1F4A.2020205@oracle.com>
	<CA+3eh10_ab9UtoSkt=kgeVGFVnDb04aa=xmh4Fp21JW=s1LBvA@mail.gmail.com>
Message-ID: <563B2449.1070105@oracle.com>

Sure, I'll do it. :)

/Erik

On 2015-11-05 10:26, Volker Simonis wrote:
> Thanks everybody for the reviews, but I still need a sponsor because
> unfortunately it is still impossible to push to the hotspot repo from
> outside "The Firm" :)
>
>
> On Thu, Nov 5, 2015 at 10:20 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Looks good to me.
>>
>> /Erik
>>
>>
>> On 2015-11-04 19:21, Volker Simonis wrote:
>>> Hi,
>>>
>>> can somebody please review and sponsor the following tiny build fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
>>> https://bugs.openjdk.java.net/browse/JDK-8141416
>>>
>>> Building hotspot on certain systems results in a series of:
>>> expr: syntax error
>>> expr: syntax error
>>> expr: syntax error
>>> expr: syntax error
>>>
>>> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
>>> -dumpversion" doesn't print a micro-version:
>>>
>>> Ubuntu:
>>> $ gcc -dumpversion
>>> 4.6
>>>
>>> Any other Linux:
>>> $ gcc -dumpversion
>>> 4.8.3
>>>
>>> This "feature" is tracked under
>>> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
>>> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
>>>
>>> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
>>> gcc and use it in the following way:
>>>
>>> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.'
>>> -f3)
>>>
>>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
>>> $(CC_VER_MICRO) = 1), 1)
>>>     $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
>>> supported because of
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
>>> endif
>>>
>>> The shell expression results in a syntax error if $(CC_VER_MICRO)
>>> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
>>>
>>> Thank you and best regards,
>>> Volker
>>


From aleksey.shipilev at oracle.com  Thu Nov  5 09:50:16 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 12:50:16 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563B0CFA.8070508@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
Message-ID: <563B2658.4090505@oracle.com>

Hi Vladimir,

On 11/05/2015 11:02 AM, Vladimir Ivanov wrote:
> On 11/3/15 9:35 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8139595

Not a Reviewer. Piggybacking the cleanup on (locked) mutation is a
standard way to deal with racing issues like that, so I like it.

Some comments:

 * I am confused why the cleanup logic spread out to methodHandles.cpp:
it would seem a general functionality for DependencyContext, and as such
it should be handled internally by add_dependent_methods? I think you
can pass the "safe to purge" flag there.

 * DependencyContext now has three methods: purge(), clear(), wipe(). I
have trouble understanding which method does what!

 * Since there is a change in vmStructs, does this also need SA changes?

Thanks,
-Aleksey


From aleksey.shipilev at oracle.com  Thu Nov  5 09:55:56 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 12:55:56 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <5638D0D2.5090609@oracle.com>
References: <5638D0D2.5090609@oracle.com>
Message-ID: <563B27AC.1050409@oracle.com>

Friendly reminder :)

Cheers,
-Aleksey

On 11/03/2015 06:20 PM, Aleksey Shipilev wrote:
> Hi,
> 
> I would like to have a formal review for a minor nit in
> Method::is_accessor. The definition for this method is inconsistent with
> its intent: it should accept all accessors, but instead it only  accepts
> the specific shapes of getters, and completely ignores setters. See:
>    https://bugs.openjdk.java.net/browse/JDK-8140650
> 
> This makes compilers to ignore many trivial methods that we might
> otherwise inline when all other inline hints have failed. It seems to be
> a lingering issue left from interpreters that had the "fast accessors".
> While it is an open question should inlining policy treat accessors
> differently or not (I stand by "yes, it should"), this is a fix that
> makes is_accessors proper:
>    http://cr.openjdk.java.net/~shade/8140650/webrev.01/
> 
> The only usage for the "old" style is_accessor is Zero, and they would
> like to update them after we commit the change:
>    http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html
> 
> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
> 
> It beats me whether this is a runtime, or compiler change -- JIRA bug
> flip-flops on that -- so, sending to hotspot-dev at . I think it can be
> pushed via hs-comp, given it impacts compilers mostly, and has the
> compiler-specific test.
> 
> Thanks,
> -Aleksey
> 
> 



From thomas.stuefe at gmail.com  Thu Nov  5 10:18:00 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 5 Nov 2015 11:18:00 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563ADCD0.1070800@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
Message-ID: <CAA-vtUzDXo0AJnRR-N45annc13xS4aZ48O2X795GbNUZEFGU-A@mail.gmail.com>

Hi David,

looks good and works fine on AIX and Linux Power.

We could now get rid of the thread_<os>_inline.hpp files too, right?

Kind Regards, Thomas



On Thu, Nov 5, 2015 at 5:36 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Here's updated webrev:
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v3/
>
> Changes since v2:
>
> - include Thomas's AIX fixes
> - Add assertion for not-NULL into Thread::current()
> - Add Thread::current_or_null() for when NULL can be expected, or for
> where failing an assert would cause more problems (eg crash reporting).
> Most uses of ThreadLocalStorage::thread()/get_thread_slow() now call
> current_or_null().
> - Removed Thread::current_noinline() (it was only used in an assert in
> some G1 code, so the inline-or-not seems irrelevant)
> - Made Thread::clear_thread_current() private
>
> I'm debating whether the get_thread implementations should call
> Thread::current() or Thread::current_or_null(). We should never get NULL
> but seems unnecessary overhead to check that with an assert in this code.
> Opinions welcomed.
>
> I still need some assistance from Aarch64 folk to write their get_thread
> function please!
>
> I still have footprint and performance measurements to make before
> proposing formal RFR.
>
> I also am still to determine whether to include the ability to hook in a
> pthread_ based implementation instead.
>
> Thanks,
> David
>
>
> On 4/11/2015 7:26 PM, David Holmes wrote:
>
>> On 4/11/2015 6:17 PM, Thomas St?fe wrote:
>>
>>> Hi David,
>>>
>>> On Wed, Nov 4, 2015 at 5:08 AM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>     Hi Thomas,
>>>
>>>
>>>         One question about your changes:
>>>
>>>         Before, Thread::current() would assert instead of returning
>>> NULL if
>>>         called before Thread::initialize_thread_current() or after
>>>         Thead::clear_thread_current() . Now, we just return NULL. Is
>>>         this intended?
>>>
>>>
>>>     Ah great question ... so before we have a mix of calls to:
>>>
>>>     - Thread::current()  (asserts on NULL as does JavaThread::current)
>>>     - ThreadLocalStorage::thread() (can return NULL)
>>>     - ThreadLocalStorage::get_thread_slow() (can return NULL)
>>>
>>>     and now we only have Thread::current() which means we have to allow
>>>     returning NULL because it can be intentionally called when a thread
>>>     is not attached. That means we won't directly catch calls to
>>>     Thread::current() from code that doesn't realize it is calling it
>>>     "too soon" - though there do exist numerous assertions in the
>>>     callers of Thread::current() that check the result is not NULL.
>>>
>>>     I could add the assert to Thread::current() and also add
>>>     Thread::current_or_null() to be used by code that needs to use it to
>>>     check for attachment (ie JNI code). I'd also have to examine all the
>>>     changed ThreadLocalStorage::thread/get_thread_slow call-sites to see
>>>     if any of those legitimately expect the thread may not be attached.
>>>
>>>     What do you think?
>>>
>>>
>>> I would prefer having Thread::current() to assert and to have a
>>> Thread::current_or_null() for cases where NULL could occurr. I tend to
>>> hit that assert a lot in development, it is useful. And the
>>> non-asserting version gets already used in a number of places, also in
>>> our (not OpenJDK) coding.
>>>
>>
>> Yes I agree. Most of the TLS::thread() and TLS::get_thread_slow() should
>> actually call Thread::current_or_null(). I also found a couple of
>> existing Thread::current()'s that should be current_or_null(). :)
>>
>>     I also need to look at the location of Thread::current in the .hpp
>>>     file rather than .inline.hpp and reconcile that with comments
>>>     regarding the noinline version (which is only used in
>>>     g1HotCardCache.hpp).
>>>
>>>
>>> Could we leave just the inline version in thread.hpp and remove the
>>> noinline version altogether? Now that Thread::current() is very simple,
>>> we may just as well keep it in the class body like the other accessors.
>>>
>>
>> I'll see if the g1 code can tolerate that.
>>
>> I'll update a prepare a new webrev tomorrow.
>>
>> Thanks,
>> David
>>
>> Thanks, Thomas
>>>
>>>
>>>

From aph at redhat.com  Thu Nov  5 10:20:11 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 5 Nov 2015 10:20:11 +0000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563ADCD0.1070800@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
Message-ID: <563B2D5B.30706@redhat.com>

On 05/11/15 04:36, David Holmes wrote:
> I still need some assistance from Aarch64 folk to write their get_thread 
> function please!

Oh, OK.  I thought we'd leave it as is.  Will do.

Andrew.


From vladimir.x.ivanov at oracle.com  Thu Nov  5 13:54:38 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 5 Nov 2015 16:54:38 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563B2658.4090505@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com>
Message-ID: <563B5F9E.6050606@oracle.com>

Thanks, Aleksey!

>>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.00
>>> https://bugs.openjdk.java.net/browse/JDK-8139595
>
> Not a Reviewer. Piggybacking the cleanup on (locked) mutation is a
> standard way to deal with racing issues like that, so I like it.
>
> Some comments:
>
>   * I am confused why the cleanup logic spread out to methodHandles.cpp:
> it would seem a general functionality for DependencyContext, and as such
> it should be handled internally by add_dependent_methods? I think you
> can pass the "safe to purge" flag there.
Cleanup logic in methodHandles.cpp is special to j.l.i.CallSite's and 
call_site_target dependency type. GC doesn't remove stale entries in 
these contexts, so I decided to piggyback on regular operations to purge 
stale entries. That's the idea of the fix.

Regarding internal purging, add_dependent_methods doesn't iterate over 
the whole list, but looks for the relevant entry. It means that "purge" 
flag should force full iteration. I think that keeping them separately 
(add_dependent_methods() vs purge()) looks cleaner.

I could add "purge" flag and move the following code into 
add_dependent_methods:
void DependencyContext::add_dependent_nmethod(nmethod* nm, bool do_purge 
= false) {
    ...
    if (has_unloaded_dependent() && do_purge) {
      purge();
    }
}

Is it what you are suggesting?

>   * DependencyContext now has three methods: purge(), clear(), wipe(). I
> have trouble understanding which method does what!
I'll add comments describing the intended behavior. There are basically 
2 operations needed:
   * purge(): only remove stale entries; no additional work is performed;

   * clear(): invalidate all dependencies in the context: effectively 
removes all entries, deoptimizes and throws away all affected methods.

wipe() is only for unit-testing purposes (see TestNmethodBucket): it 
just deallocates all nmethodBucket entries without touching nmethods. It 
is necessary since nmethod pointers are faked by the test.

I could have added that code into TestNmethodBucket, but then I would 
need to declare TestNmethodBucket as a friend of DependencyContext to 
preserve incapsulation.

>   * Since there is a change in vmStructs, does this also need SA changes?
/agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java refers 
neither to _dependencies nor _has_unloaded_dependent fields. So, it 
seems no changes are needed there.

Best regards,
Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Thu Nov  5 14:07:56 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 5 Nov 2015 17:07:56 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <5638D0D2.5090609@oracle.com>
References: <5638D0D2.5090609@oracle.com>
Message-ID: <563B62BC.5090906@oracle.com>

Overall, looks good.

How much work is it required on Zero side to make it work? It would be 
good to avoid shared code pollution (even temporal) just for Zero 
purposes. My concern is that it will stay that way forever.

If it is too much work for you, I'd ask Zero maintainers for help and 
coordinate the changes.

Best regards,
Vladimir Ivanov

On 11/3/15 6:20 PM, Aleksey Shipilev wrote:
> Hi,
>
> I would like to have a formal review for a minor nit in
> Method::is_accessor. The definition for this method is inconsistent with
> its intent: it should accept all accessors, but instead it only  accepts
> the specific shapes of getters, and completely ignores setters. See:
>     https://bugs.openjdk.java.net/browse/JDK-8140650
>
> This makes compilers to ignore many trivial methods that we might
> otherwise inline when all other inline hints have failed. It seems to be
> a lingering issue left from interpreters that had the "fast accessors".
> While it is an open question should inlining policy treat accessors
> differently or not (I stand by "yes, it should"), this is a fix that
> makes is_accessors proper:
>     http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>
> The only usage for the "old" style is_accessor is Zero, and they would
> like to update them after we commit the change:
>     http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html
>
> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>
> It beats me whether this is a runtime, or compiler change -- JIRA bug
> flip-flops on that -- so, sending to hotspot-dev at . I think it can be
> pushed via hs-comp, given it impacts compilers mostly, and has the
> compiler-specific test.
>
> Thanks,
> -Aleksey
>
>

From frederic.parain at oracle.com  Thu Nov  5 14:17:19 2015
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 5 Nov 2015 15:17:19 +0100
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
Message-ID: <563B64EF.1000500@oracle.com>

Please review the changesets for JEP 270: Reserved Stack Areas for 
Critical Sections

CR: https://bugs.openjdk.java.net/browse/JDK-8046936

Webrevs:
   hotspot: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
   JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/

The CR contains a detailed description of the issue and the design
of the solution as well as implementation details.

Tests:

     JPRT - hotspot & core
     RBT - vm.quick

Thanks

Fred

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From aph at redhat.com  Thu Nov  5 16:01:14 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 5 Nov 2015 16:01:14 +0000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563B2D5B.30706@redhat.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<563B2D5B.30706@redhat.com>
Message-ID: <563B7D4A.9030401@redhat.com>

On 11/05/2015 10:20 AM, Andrew Haley wrote:
> On 05/11/15 04:36, David Holmes wrote:
>> I still need some assistance from Aarch64 folk to write their get_thread 
>> function please!

Here you are.

I found a bug in the existing AArch64 get_thread.

The specification of MacroAssembler::get_thread() is that it clobbers
no registers.  Most of the vector state is callee-clobbered, so if you
want to call a get_thread() method which is written in C you have to
save the entire vector state as well as all call-clobbered general
registers.  You have to do this because it is possible that GCC will
use a vector register for temporary storage.  (This is not just a
theoretical possibility: I have seen AArch64 bugs caused by this
actually happening.)  So, I wrote code to save all the general and
vector registers.  It was horrible.

I scrapped it and instead wrote a little assembly-language routine
which returns the contents of Thread::_thr_current.  This clobbers
only a couple of registers, and everything is much nicer.

I suppose it might have been possible to change the specification of
MacroAssembler::get_thread() so that it clobbered the vector state,
but never mind: it's done now.

Andrew.
-------------- next part --------------
diff --git a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
--- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
+++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
@@ -4651,23 +4651,22 @@
       sub(result, result, len); // Return index where we stopped
 }
 
-// get_thread can be called anywhere inside generated code so we need
-// to save whatever non-callee save context might get clobbered by the
-// call to Thread::current or, indeed, the call setup code. 
-// x86 appears to save C arg registers.
-
+// get_thread() can be called anywhere inside generated code so we
+// need to save whatever non-callee save context might get clobbered
+// by the call to JavaThread::aarch64_get_thread_helper() or, indeed,
+// the call setup code.
+//
+// aarch64_get_thread_helper() clobbers only r0, r1, and flags.
+//
 void MacroAssembler::get_thread(Register dst) {
-
-  // Save all call-clobbered regs except dst, plus r19 and r20.
-  RegSet saved_regs = RegSet::range(r0, r20) + lr - dst;
+  RegSet saved_regs = RegSet::range(r0, r1) + lr - dst;
   push(saved_regs, sp);
 
-  // FIX-ME: implement
-  // return Thread::current()
-
+  mov(lr, CAST_FROM_FN_PTR(address, JavaThread::aarch64_get_thread_helper));
+  blrt(lr, 1, 0, 1);
   if (dst != c_rarg0) {
     mov(dst, c_rarg0);
   }
-  // restore pushed registers
+
   pop(saved_regs, sp);
 }
diff --git a/src/os_cpu/linux_aarch64/vm/threadLS_linux_aarch64.s b/src/os_cpu/linux_aarch64/vm/threadLS_linux_aarch64.s
new file mode 100644
--- /dev/null
+++ b/src/os_cpu/linux_aarch64/vm/threadLS_linux_aarch64.s
@@ -0,0 +1,44 @@
+// Copyright (c) 2015, Red Hat Inc. All rights reserved.
+// DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+//
+// This code is free software; you can redistribute it and/or modify it
+// under the terms of the GNU General Public License version 2 only, as
+// published by the Free Software Foundation.
+//
+// This code is distributed in the hope that it will be useful, but WITHOUT
+// ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+// version 2 for more details (a copy is included in the LICENSE file that
+// accompanied this code).
+//
+// You should have received a copy of the GNU General Public License version
+// 2 along with this work; if not, write to the Free Software Foundation,
+// Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+//
+// Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+// or visit www.oracle.com if you need additional information or have any
+// questions.
+
+        // JavaThread::aarch64_get_thread_helper()
+        //
+        // Return the current thread pointer in x0.
+        // Clobber x1, flags.
+        // All other registers are preserved,
+
+	.global	_ZN10JavaThread25aarch64_get_thread_helperEv
+	.type	_ZN10JavaThread25aarch64_get_thread_helperEv, %function
+
+_ZN10JavaThread25aarch64_get_thread_helperEv:
+	stp x29, x30, [sp, -16]!
+	adrp x0, :tlsdesc:_ZN6Thread12_thr_currentE
+	ldr x1, [x0, #:tlsdesc_lo12:_ZN6Thread12_thr_currentE]
+	add x0, x0, :tlsdesc_lo12:_ZN6Thread12_thr_currentE
+	.tlsdesccall _ZN6Thread12_thr_currentE
+	blr x1
+	mrs x1, tpidr_el0
+	add x0, x1, x0
+	ldr x0, [x0]
+	ldp x29, x30, [sp], 16
+	ret
+
+	.size _ZN10JavaThread25aarch64_get_thread_helperEv, .-_ZN10JavaThread25aarch64_get_thread_helperEv
diff --git a/src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp b/src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp
--- a/src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp
+++ b/src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp
@@ -77,6 +77,8 @@
   bool pd_get_top_frame(frame* fr_addr, void* ucontext, bool isInJava);
 public:
 
+  static Thread *aarch64_get_thread_helper();
+
   // These routines are only used on cpu architectures that
   // have separate register stacks (Itanium).
   static bool register_stack_overflow() { return false; }

From magnus.ihse.bursie at oracle.com  Thu Nov  5 16:18:06 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Nov 2015 17:18:06 +0100
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
Message-ID: <563B813E.5010506@oracle.com>

Currently the /WX flag is hardcoded in the Hotspot windows make files. 
This makes it impossible to turn of warnings-as-errors for Windows 
without explicitely hacking the makefiles. This should be fixed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8141548-hotspot-windows-build-should-respect-warnings-as-errors/webrev.01

/Magnus

From erik.joelsson at oracle.com  Thu Nov  5 16:22:22 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Nov 2015 17:22:22 +0100
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
In-Reply-To: <563B813E.5010506@oracle.com>
References: <563B813E.5010506@oracle.com>
Message-ID: <563B823E.5030906@oracle.com>

Looks good to me.

/Erik

On 2015-11-05 17:18, Magnus Ihse Bursie wrote:
> Currently the /WX flag is hardcoded in the Hotspot windows make files. 
> This makes it impossible to turn of warnings-as-errors for Windows 
> without explicitely hacking the makefiles. This should be fixed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8141548-hotspot-windows-build-should-respect-warnings-as-errors/webrev.01
>
> /Magnus


From aleksey.shipilev at oracle.com  Thu Nov  5 16:22:58 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 19:22:58 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B62BC.5090906@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
Message-ID: <563B8262.1040004@oracle.com>

Isn't the incomplete (for the sake of Zero) M::is_accessor is a shared
code pollution already? With that interpretation, the patch tries to
contain the pollution in interpreter.cpp, with M::is_simple_accessor.

I have already asked zero-dev here, and linked a response below:
  http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html

The only way to produce a completely pure change is to have Zero changes
along with M::is_accessor changes (which seem to be small, but require
testing anyhow). Is that what you want? My concern is that we are
predicating the tech debt removal on a code which we don't build or
test. It seems that carefully containing the Zero-specific behavior, and
letting Zero maintainers know to sweep it up is the sane tactics here.

Thanks,
-Aleksey

On 11/05/2015 05:07 PM, Vladimir Ivanov wrote:
> Overall, looks good.
> 
> How much work is it required on Zero side to make it work? It would be
> good to avoid shared code pollution (even temporal) just for Zero
> purposes. My concern is that it will stay that way forever.
> 
> If it is too much work for you, I'd ask Zero maintainers for help and
> coordinate the changes.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 11/3/15 6:20 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> I would like to have a formal review for a minor nit in
>> Method::is_accessor. The definition for this method is inconsistent with
>> its intent: it should accept all accessors, but instead it only  accepts
>> the specific shapes of getters, and completely ignores setters. See:
>>     https://bugs.openjdk.java.net/browse/JDK-8140650
>>
>> This makes compilers to ignore many trivial methods that we might
>> otherwise inline when all other inline hints have failed. It seems to be
>> a lingering issue left from interpreters that had the "fast accessors".
>> While it is an open question should inlining policy treat accessors
>> differently or not (I stand by "yes, it should"), this is a fix that
>> makes is_accessors proper:
>>     http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>
>> The only usage for the "old" style is_accessor is Zero, and they would
>> like to update them after we commit the change:
>>    
>> http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html
>>
>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>
>> It beats me whether this is a runtime, or compiler change -- JIRA bug
>> flip-flops on that -- so, sending to hotspot-dev at . I think it can be
>> pushed via hs-comp, given it impacts compilers mostly, and has the
>> compiler-specific test.
>>
>> Thanks,
>> -Aleksey
>>
>>



From vladimir.x.ivanov at oracle.com  Thu Nov  5 16:46:38 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 5 Nov 2015 19:46:38 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B8262.1040004@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com>
Message-ID: <563B87EE.2030007@oracle.com>

My idea was to warn Zero maintainers about a change which breaks their 
code and give them some time to react accordingly (provide missing 
functionality). After that just push the change. If Zero support is 
missing, then just file a bug.

If there's an RFE filed and Zero maintainers promise to fix it in a 
prompt manner, I'm fine with what you proposed.

Also, I had an idea: why don't you move is_simple_accessor() from Method 
to some Zero-specific location? I don't see any value in keeping it in 
Method.

Best regards,
Vladimir Ivanov

On 11/5/15 7:22 PM, Aleksey Shipilev wrote:
> Isn't the incomplete (for the sake of Zero) M::is_accessor is a shared
> code pollution already? With that interpretation, the patch tries to
> contain the pollution in interpreter.cpp, with M::is_simple_accessor.
>
> I have already asked zero-dev here, and linked a response below:
>    http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html
>
> The only way to produce a completely pure change is to have Zero changes
> along with M::is_accessor changes (which seem to be small, but require
> testing anyhow). Is that what you want? My concern is that we are
> predicating the tech debt removal on a code which we don't build or
> test. It seems that carefully containing the Zero-specific behavior, and
> letting Zero maintainers know to sweep it up is the sane tactics here.
>
> Thanks,
> -Aleksey
>
> On 11/05/2015 05:07 PM, Vladimir Ivanov wrote:
>> Overall, looks good.
>>
>> How much work is it required on Zero side to make it work? It would be
>> good to avoid shared code pollution (even temporal) just for Zero
>> purposes. My concern is that it will stay that way forever.
>>
>> If it is too much work for you, I'd ask Zero maintainers for help and
>> coordinate the changes.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 11/3/15 6:20 PM, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> I would like to have a formal review for a minor nit in
>>> Method::is_accessor. The definition for this method is inconsistent with
>>> its intent: it should accept all accessors, but instead it only  accepts
>>> the specific shapes of getters, and completely ignores setters. See:
>>>      https://bugs.openjdk.java.net/browse/JDK-8140650
>>>
>>> This makes compilers to ignore many trivial methods that we might
>>> otherwise inline when all other inline hints have failed. It seems to be
>>> a lingering issue left from interpreters that had the "fast accessors".
>>> While it is an open question should inlining policy treat accessors
>>> differently or not (I stand by "yes, it should"), this is a fix that
>>> makes is_accessors proper:
>>>      http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>
>>> The only usage for the "old" style is_accessor is Zero, and they would
>>> like to update them after we commit the change:
>>>
>>> http://mail.openjdk.java.net/pipermail/zero-dev/2015-November/000551.html
>>>
>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>
>>> It beats me whether this is a runtime, or compiler change -- JIRA bug
>>> flip-flops on that -- so, sending to hotspot-dev at . I think it can be
>>> pushed via hs-comp, given it impacts compilers mostly, and has the
>>> compiler-specific test.
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>
>
>

From aleksey.shipilev at oracle.com  Thu Nov  5 16:46:26 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 19:46:26 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563B5F9E.6050606@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
Message-ID: <563B87E2.9010603@oracle.com>

On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
> Regarding internal purging, add_dependent_methods doesn't iterate over
> the whole list, but looks for the relevant entry. It means that "purge"
> flag should force full iteration. I think that keeping them separately
> (add_dependent_methods() vs purge()) looks cleaner.

I think it is better to encapsulate the "piggybacking" behavior within
the DependencyContext itself, because that seems to be a
general/expected feature of DependencyContext class. It is weird to ask
class users to spell it out specifically.


> I could add "purge" flag and move the following code into
> add_dependent_methods:
> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool do_purge
> = false) {
>    ...
>    if (has_unloaded_dependent() && do_purge) {
>      purge();
>    }
> }
> 
> Is it what you are suggesting?

Yes.


>>   * DependencyContext now has three methods: purge(), clear(), wipe(). I
>> have trouble understanding which method does what!

> There are basically 2 operations needed:
>   * purge(): only remove stale entries; no additional work is performed;

Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
 WeakHashMap.expungeStaleEntries()
 ThreadLocal.expungeStaleEntries()
 WeakCache.expungeStaleEntries()


> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
> just deallocates all nmethodBucket entries without touching nmethods. It
> is necessary since nmethod pointers are faked by the test.

Okay. Is there a convention how you should name the test-related methods
like these? I would expect something like debug_deallocate_buckets().

Thanks,
-Aleksey



From aleksey.shipilev at oracle.com  Thu Nov  5 16:53:55 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 19:53:55 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B87EE.2030007@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
Message-ID: <563B89A3.9000907@oracle.com>

On 11/05/2015 07:46 PM, Vladimir Ivanov wrote:
> My idea was to warn Zero maintainers about a change which breaks their
> code and give them some time to react accordingly (provide missing
> functionality). After that just push the change. If Zero support is
> missing, then just file a bug.
> 
> If there's an RFE filed and Zero maintainers promise to fix it in a
> prompt manner, I'm fine with what you proposed.

Yeah, that's the plan.

> Also, I had an idea: why don't you move is_simple_accessor() from Method
> to some Zero-specific location? I don't see any value in keeping it in
> Method.

That's an interesting trick, but I think it will cause more harm: shared
interpreter.cpp would have to know about that Zero-specific method, or
otherwise intercept "too wide" accessor shape and narrow it down before
it reaches Zero. Therefore, I believe is_simple_accessor is the lesser evil.

Thanks,
-Aleksey


From vladimir.x.ivanov at oracle.com  Thu Nov  5 16:59:27 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 5 Nov 2015 19:59:27 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B89A3.9000907@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com>
Message-ID: <563B8AEF.1090002@oracle.com>

>> If there's an RFE filed and Zero maintainers promise to fix it in a
>> prompt manner, I'm fine with what you proposed.
>
> Yeah, that's the plan.
>
>> Also, I had an idea: why don't you move is_simple_accessor() from Method
>> to some Zero-specific location? I don't see any value in keeping it in
>> Method.
>
> That's an interesting trick, but I think it will cause more harm: shared
> interpreter.cpp would have to know about that Zero-specific method, or
> otherwise intercept "too wide" accessor shape and narrow it down before
> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser evil.
Ok. Looks good then.

Best regards,
Vladimir Ivanov

From joe.darcy at oracle.com  Thu Nov  5 17:17:46 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 5 Nov 2015 09:17:46 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563ABE31.8010807@oracle.com>
References: <563ABE31.8010807@oracle.com>
Message-ID: <563B8F3A.3020706@oracle.com>

Hi Chris,

The langtools and jaxp repos also have TEST.ROOT files with a 
requiredVersion clause. I'd prefer if the files in those repos were 
updated at the same to b12.

Thanks,

-Joe

On 11/4/2015 6:25 PM, Chris Plummer wrote:
> Please review the following changes:
>
> http://cr.openjdk.java.net/~cjplummer/8141489/
> https://bugs.openjdk.java.net/browse/JDK-8141489
>
> The changes I did for 8140189 require that version 4.1 b12 of jtreg be 
> used, so TEST.ROOT has been updated to reflect this.
>
> Testing with JPRT right now. I also ran with b11 and confirmed that 
> the following errors are produced for hotspot and jdk tests:
>
>     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test 
> requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 
> b11.
>
>     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test 
> requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 
> b11.
>
> thanks,
>
> Chris


From aleksey.shipilev at oracle.com  Thu Nov  5 17:24:02 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 20:24:02 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B8AEF.1090002@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
Message-ID: <563B90B2.9010601@oracle.com>

On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>> prompt manner, I'm fine with what you proposed.
>>
>> Yeah, that's the plan.
>>
>>> Also, I had an idea: why don't you move is_simple_accessor() from Method
>>> to some Zero-specific location? I don't see any value in keeping it in
>>> Method.
>>
>> That's an interesting trick, but I think it will cause more harm: shared
>> interpreter.cpp would have to know about that Zero-specific method, or
>> otherwise intercept "too wide" accessor shape and narrow it down before
>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>> evil.
> Ok. Looks good then.

Thanks for taking time to review, Vladimir! I'll count that as the
review from the compiler side.

I think we still need a review from the runtime side. Folks? For the
record, we are discussing this change:
  http://cr.openjdk.java.net/~shade/8140650/webrev.01/

The patch passes JPRT, RBT (hotspot_all), and the new regression test.

Thanks,
-Aleksey



From chris.plummer at oracle.com  Thu Nov  5 17:26:58 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 5 Nov 2015 09:26:58 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563B8F3A.3020706@oracle.com>
References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com>
Message-ID: <563B9162.6020605@oracle.com>

Hi Joe,

Is there a reason to upgrade them if the tests don't actually require 
b12? BTW, there are more than just those two repos. The following all 
have TEST.ROOT:

bash-4.1$ find . -name TEST.ROOT
./hotspot/agent/test/jdi/TEST.ROOT
./hotspot/test/TEST.ROOT
./deploy/test/TEST.ROOT
./nashorn/test/TEST.ROOT
./jaxp/test/TEST.ROOT
./jdk/test/TEST.ROOT
./langtools/make/test/TEST.ROOT
./langtools/test/TEST.ROOT

But not all of the above specify requiredVersion

bash-4.1$ grep requiredVersion `find . -name TEST.ROOT`
./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12
./deploy/test/TEST.ROOT:requiredVersion=4.1 b11
./nashorn/test/TEST.ROOT:requiredVersion=4.1 b11
./jaxp/test/TEST.ROOT:requiredVersion=4.1 b11
./jdk/test/TEST.ROOT:requiredVersion=4.1 b12
./langtools/test/TEST.ROOT:requiredVersion=4.1 b11

(Note the ones with b12 are the ones I've already modified for this commit)

thanks,

Chris

On 11/5/15 9:17 AM, joe darcy wrote:
> Hi Chris,
>
> The langtools and jaxp repos also have TEST.ROOT files with a 
> requiredVersion clause. I'd prefer if the files in those repos were 
> updated at the same to b12.
>
> Thanks,
>
> -Joe
>
> On 11/4/2015 6:25 PM, Chris Plummer wrote:
>> Please review the following changes:
>>
>> http://cr.openjdk.java.net/~cjplummer/8141489/
>> https://bugs.openjdk.java.net/browse/JDK-8141489
>>
>> The changes I did for 8140189 require that version 4.1 b12 of jtreg 
>> be used, so TEST.ROOT has been updated to reflect this.
>>
>> Testing with JPRT right now. I also ran with b11 and confirmed that 
>> the following errors are produced for hotspot and jdk tests:
>>
>>     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test 
>> requires jtreg version 4.1 b12 or higher and this is jtreg version 
>> 4.1 b11.
>>
>>     Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test 
>> requires jtreg version 4.1 b12 or higher and this is jtreg version 
>> 4.1 b11.
>>
>> thanks,
>>
>> Chris
>


From coleen.phillimore at oracle.com  Thu Nov  5 17:34:35 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Nov 2015 12:34:35 -0500
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B90B2.9010601@oracle.com>
References: <5638D0D2.5090609@oracle.com>
	<563B62BC.5090906@oracle.com>	<563B8262.1040004@oracle.com>
	<563B87EE.2030007@oracle.com>	<563B89A3.9000907@oracle.com>
	<563B8AEF.1090002@oracle.com> <563B90B2.9010601@oracle.com>
Message-ID: <563B932B.70507@oracle.com>


Hi,

I am planning on reviewing this but I haven't had time.  And I'm trying 
to build Zero for a different reason.  I would be pretty unhappy if it 
broke Zero and would like it to not do that.  I haven't had a chance to 
read all of this yet.  I thought is_accessor was only for Zero so I 
guess I have to read more why this is getting changed.  I will try to 
get to it today.

Thanks,
Coleen

On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>> prompt manner, I'm fine with what you proposed.
>>> Yeah, that's the plan.
>>>
>>>> Also, I had an idea: why don't you move is_simple_accessor() from Method
>>>> to some Zero-specific location? I don't see any value in keeping it in
>>>> Method.
>>> That's an interesting trick, but I think it will cause more harm: shared
>>> interpreter.cpp would have to know about that Zero-specific method, or
>>> otherwise intercept "too wide" accessor shape and narrow it down before
>>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>>> evil.
>> Ok. Looks good then.
> Thanks for taking time to review, Vladimir! I'll count that as the
> review from the compiler side.
>
> I think we still need a review from the runtime side. Folks? For the
> record, we are discussing this change:
>    http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>
> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>
> Thanks,
> -Aleksey
>
>


From joe.darcy at oracle.com  Thu Nov  5 18:16:20 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 5 Nov 2015 10:16:20 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563B9162.6020605@oracle.com>
References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com>
	<563B9162.6020605@oracle.com>
Message-ID: <563B9CF4.20504@oracle.com>

Hi Chris,

On 11/5/2015 9:26 AM, Chris Plummer wrote:
> Hi Joe,
>
> Is there a reason to upgrade them if the tests don't actually require 
> b12? BTW, there are more than just those two repos. The following all 
> have TEST.ROOT:
>
> bash-4.1$ find . -name TEST.ROOT
> ./hotspot/agent/test/jdi/TEST.ROOT
> ./hotspot/test/TEST.ROOT
> ./deploy/test/TEST.ROOT
> ./nashorn/test/TEST.ROOT
> ./jaxp/test/TEST.ROOT
> ./jdk/test/TEST.ROOT
> ./langtools/make/test/TEST.ROOT
> ./langtools/test/TEST.ROOT

The jtreg configuration files in the $REPO/test directories were 
regularized earlier in JDK 9 with

     JDK-8075543: Add tiered testing definitions to the JDK 9 forest

For consistency across the JDK, this included adding a minimum jtreg 
version to 4.1 b11 even if the tests in those repos didn't actually use 
b11 specific features. I think these same TEST.ROOT files should be 
updated in unison to b12.

Thanks,

-Joe


From chris.plummer at oracle.com  Thu Nov  5 18:25:42 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 5 Nov 2015 10:25:42 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563B9CF4.20504@oracle.com>
References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com>
	<563B9162.6020605@oracle.com> <563B9CF4.20504@oracle.com>
Message-ID: <563B9F26.3050309@oracle.com>

On 11/5/15 10:16 AM, joe darcy wrote:
> Hi Chris,
>
> On 11/5/2015 9:26 AM, Chris Plummer wrote:
>> Hi Joe,
>>
>> Is there a reason to upgrade them if the tests don't actually require 
>> b12? BTW, there are more than just those two repos. The following all 
>> have TEST.ROOT:
>>
>> bash-4.1$ find . -name TEST.ROOT
>> ./hotspot/agent/test/jdi/TEST.ROOT
>> ./hotspot/test/TEST.ROOT
>> ./deploy/test/TEST.ROOT
>> ./nashorn/test/TEST.ROOT
>> ./jaxp/test/TEST.ROOT
>> ./jdk/test/TEST.ROOT
>> ./langtools/make/test/TEST.ROOT
>> ./langtools/test/TEST.ROOT
>
> The jtreg configuration files in the $REPO/test directories were 
> regularized earlier in JDK 9 with
>
>     JDK-8075543: Add tiered testing definitions to the JDK 9 forest
>
> For consistency across the JDK, this included adding a minimum jtreg 
> version to 4.1 b11 even if the tests in those repos didn't actually 
> use b11 specific features. I think these same TEST.ROOT files should 
> be updated in unison to b12.
Ok. I'll get started on it and send out a new webrev when ready.

Chris
>
> Thanks,
>
> -Joe
>


From vladimir.x.ivanov at oracle.com  Thu Nov  5 18:54:11 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 5 Nov 2015 21:54:11 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563B87E2.9010603@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com>
Message-ID: <563BA5D3.5060905@oracle.com>

Updated version:
http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/

In addition to name polishing and encapsulating purging logic in 
{add|remove}_dependent_nmethod methods, I got rid of 
DependencyContext::wipe() method and added "friend class 
TestDependencyContext" declaration (noticed such practice in other cases 
when tests need access to tested class internals).

Best regards,
Vladimir Ivanov

On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>> Regarding internal purging, add_dependent_methods doesn't iterate over
>> the whole list, but looks for the relevant entry. It means that "purge"
>> flag should force full iteration. I think that keeping them separately
>> (add_dependent_methods() vs purge()) looks cleaner.
>
> I think it is better to encapsulate the "piggybacking" behavior within
> the DependencyContext itself, because that seems to be a
> general/expected feature of DependencyContext class. It is weird to ask
> class users to spell it out specifically.
>
>
>> I could add "purge" flag and move the following code into
>> add_dependent_methods:
>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool do_purge
>> = false) {
>>     ...
>>     if (has_unloaded_dependent() && do_purge) {
>>       purge();
>>     }
>> }
>>
>> Is it what you are suggesting?
>
> Yes.
>
>
>>>    * DependencyContext now has three methods: purge(), clear(), wipe(). I
>>> have trouble understanding which method does what!
>
>> There are basically 2 operations needed:
>>    * purge(): only remove stale entries; no additional work is performed;
>
> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>   WeakHashMap.expungeStaleEntries()
>   ThreadLocal.expungeStaleEntries()
>   WeakCache.expungeStaleEntries()
>
>
>> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
>> just deallocates all nmethodBucket entries without touching nmethods. It
>> is necessary since nmethod pointers are faked by the test.
>
> Okay. Is there a convention how you should name the test-related methods
> like these? I would expect something like debug_deallocate_buckets().
>
> Thanks,
> -Aleksey
>
>

From aleksey.shipilev at oracle.com  Thu Nov  5 18:59:38 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 21:59:38 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563BA5D3.5060905@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
Message-ID: <563BA71A.4050106@oracle.com>

On 11/05/2015 09:54 PM, Vladimir Ivanov wrote:
> Updated version:
> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/

Looks good. Not a (R)eviewer.

-Aleksey


From chris.plummer at oracle.com  Thu Nov  5 19:12:19 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 5 Nov 2015 11:12:19 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563B9F26.3050309@oracle.com>
References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com>
	<563B9162.6020605@oracle.com> <563B9CF4.20504@oracle.com>
	<563B9F26.3050309@oracle.com>
Message-ID: <563BAA13.8060205@oracle.com>

Hi Joe,

Here's the updated webrev:

http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8141489

These are all the repos that have been updated:

 >$ grep requiredVersion `find . -name TEST.ROOT`
./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12
./deploy/test/TEST.ROOT:requiredVersion=4.1 b12
./nashorn/test/TEST.ROOT:requiredVersion=4.1 b12
./jaxp/test/TEST.ROOT:requiredVersion=4.1 b12
./jdk/test/TEST.ROOT:requiredVersion=4.1 b12
./langtools/test/TEST.ROOT:requiredVersion=4.1 b12

Test job has been submitted to JPRT.

thanks,

Chris

From joe.darcy at oracle.com  Thu Nov  5 19:19:54 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 5 Nov 2015 11:19:54 -0800
Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs
	to updated to 4.1 b12
In-Reply-To: <563BAA13.8060205@oracle.com>
References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com>
	<563B9162.6020605@oracle.com> <563B9CF4.20504@oracle.com>
	<563B9F26.3050309@oracle.com> <563BAA13.8060205@oracle.com>
Message-ID: <563BABDA.1030503@oracle.com>

Hi Chris,

Looks fine to me; thanks,

-Joe

On 11/5/2015 11:12 AM, Chris Plummer wrote:
> Hi Joe,
>
> Here's the updated webrev:
>
> http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8141489
>
> These are all the repos that have been updated:
>
> >$ grep requiredVersion `find . -name TEST.ROOT`
> ./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12
> ./deploy/test/TEST.ROOT:requiredVersion=4.1 b12
> ./nashorn/test/TEST.ROOT:requiredVersion=4.1 b12
> ./jaxp/test/TEST.ROOT:requiredVersion=4.1 b12
> ./jdk/test/TEST.ROOT:requiredVersion=4.1 b12
> ./langtools/test/TEST.ROOT:requiredVersion=4.1 b12
>
> Test job has been submitted to JPRT.
>
> thanks,
>
> Chris


From aleksey.shipilev at oracle.com  Thu Nov  5 19:45:59 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 22:45:59 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563B932B.70507@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
Message-ID: <563BB1F7.7050807@oracle.com>

Thanks, Coleen!

The tricky part is that compilers poll Method::is_accessor via:

 bool ciMethod::is_accessor    () const {
   FETCH_FLAG_FROM_VM(is_accessor);
 }

#define FETCH_FLAG_FROM_VM(flag_accessor) { \
  check_is_loaded(); \
  VM_ENTRY_MARK; \
  return get_Method()->flag_accessor(); \
}

...which may be opaque for IDEs, when you look for usages. I found that
a text search for "is_accessor" yields only positive matches.

*Actually*, now that I read the code again, there is a suspicious use in
CallNode::may_modify:

      if (meth->is_accessor()) {
        return false;
      }

This seems to break if is_accessor accepts setters. Let me split the
is_accessor into is_getter/is_setter and re-run tests. If you spot other
problems in the patch, let me know.

Thanks,
-Aleksey

On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
> I am planning on reviewing this but I haven't had time.  And I'm trying
> to build Zero for a different reason.  I would be pretty unhappy if it
> broke Zero and would like it to not do that.  I haven't had a chance to
> read all of this yet.  I thought is_accessor was only for Zero so I
> guess I have to read more why this is getting changed.  I will try to
> get to it today.
> 
> Thanks,
> Coleen
> 
> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>> prompt manner, I'm fine with what you proposed.
>>>> Yeah, that's the plan.
>>>>
>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>> Method
>>>>> to some Zero-specific location? I don't see any value in keeping it in
>>>>> Method.
>>>> That's an interesting trick, but I think it will cause more harm:
>>>> shared
>>>> interpreter.cpp would have to know about that Zero-specific method, or
>>>> otherwise intercept "too wide" accessor shape and narrow it down before
>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>>>> evil.
>>> Ok. Looks good then.
>> Thanks for taking time to review, Vladimir! I'll count that as the
>> review from the compiler side.
>>
>> I think we still need a review from the runtime side. Folks? For the
>> record, we are discussing this change:
>>    http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>
>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>
>> Thanks,
>> -Aleksey
>>
>>
> 



From christian.thalinger at oracle.com  Thu Nov  5 20:07:24 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 5 Nov 2015 10:07:24 -1000
Subject: Using IdealGraphVisualizer
In-Reply-To: <C3C75AA9-613E-4515-A0E2-BA316C360864@gmail.com>
References: <C3C75AA9-613E-4515-A0E2-BA316C360864@gmail.com>
Message-ID: <4ECC0213-8AD0-4E17-91E6-0F14ECE1258C@oracle.com>


> On Oct 27, 2015, at 4:03 AM, Manas Thakur <manasthakur17 at gmail.com> wrote:
> 
> Hello all
> 
> I want to use the IdealGraphVisualizer shipped with OpenJDK 8. Using ?-XX:PrintIdealGraphLevel=#? in the debug build simply dumps the graph on the screen; how should I use the tool to actually visualise the graph?

src/share/tools/IdealGraphVisualizer/README

> 
> Regards,
> Manas


From coleen.phillimore at oracle.com  Thu Nov  5 20:14:35 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Nov 2015 15:14:35 -0500
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BB1F7.7050807@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com>
Message-ID: <563BB8AB.9080604@oracle.com>


Thank you for telling me where this is.  I would have had to grep around 
for too long.

On 11/5/15 2:45 PM, Aleksey Shipilev wrote:
> Thanks, Coleen!
>
> The tricky part is that compilers poll Method::is_accessor via:
>
>   bool ciMethod::is_accessor    () const {
>     FETCH_FLAG_FROM_VM(is_accessor);
>   }
>
> #define FETCH_FLAG_FROM_VM(flag_accessor) { \
>    check_is_loaded(); \
>    VM_ENTRY_MARK; \
>    return get_Method()->flag_accessor(); \
> }
>
> ...which may be opaque for IDEs, when you look for usages. I found that
> a text search for "is_accessor" yields only positive matches.
>
> *Actually*, now that I read the code again, there is a suspicious use in
> CallNode::may_modify:
>
>        if (meth->is_accessor()) {
>          return false;
>        }
>
> This seems to break if is_accessor accepts setters. Let me split the
> is_accessor into is_getter/is_setter and re-run tests. If you spot other
> problems in the patch, let me know.

I can build Zero now, so I'll try this patch in the meantime.

Coleen
>
> Thanks,
> -Aleksey
>
> On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
>> I am planning on reviewing this but I haven't had time.  And I'm trying
>> to build Zero for a different reason.  I would be pretty unhappy if it
>> broke Zero and would like it to not do that.  I haven't had a chance to
>> read all of this yet.  I thought is_accessor was only for Zero so I
>> guess I have to read more why this is getting changed.  I will try to
>> get to it today.
>>
>> Thanks,
>> Coleen
>>
>> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>>> prompt manner, I'm fine with what you proposed.
>>>>> Yeah, that's the plan.
>>>>>
>>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>>> Method
>>>>>> to some Zero-specific location? I don't see any value in keeping it in
>>>>>> Method.
>>>>> That's an interesting trick, but I think it will cause more harm:
>>>>> shared
>>>>> interpreter.cpp would have to know about that Zero-specific method, or
>>>>> otherwise intercept "too wide" accessor shape and narrow it down before
>>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>>>>> evil.
>>>> Ok. Looks good then.
>>> Thanks for taking time to review, Vladimir! I'll count that as the
>>> review from the compiler side.
>>>
>>> I think we still need a review from the runtime side. Folks? For the
>>> record, we are discussing this change:
>>>     http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>
>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>
>


From aleksey.shipilev at oracle.com  Thu Nov  5 20:16:24 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 23:16:24 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BB1F7.7050807@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com>
Message-ID: <563BB918.9020509@oracle.com>

Ah, no, the CallNode::may_modify polls is_accessor only for boxed
instances, so there are no setters in Java code. Still, we should check
for getters there explicitly, and the getter/setter split is sensible in
Method API anyhow.

New webrev:
  http://cr.openjdk.java.net/~shade/8140650/webrev.02/

Re-spinning RBT for sanity.

Thanks,
-Aleksey

On 11/05/2015 10:45 PM, Aleksey Shipilev wrote:
> Thanks, Coleen!
> 
> The tricky part is that compilers poll Method::is_accessor via:
> 
>  bool ciMethod::is_accessor    () const {
>    FETCH_FLAG_FROM_VM(is_accessor);
>  }
> 
> #define FETCH_FLAG_FROM_VM(flag_accessor) { \
>   check_is_loaded(); \
>   VM_ENTRY_MARK; \
>   return get_Method()->flag_accessor(); \
> }
> 
> ...which may be opaque for IDEs, when you look for usages. I found that
> a text search for "is_accessor" yields only positive matches.
> 
> *Actually*, now that I read the code again, there is a suspicious use in
> CallNode::may_modify:
> 
>       if (meth->is_accessor()) {
>         return false;
>       }
> 
> This seems to break if is_accessor accepts setters. Let me split the
> is_accessor into is_getter/is_setter and re-run tests. If you spot other
> problems in the patch, let me know.
> 
> Thanks,
> -Aleksey
> 
> On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
>> I am planning on reviewing this but I haven't had time.  And I'm trying
>> to build Zero for a different reason.  I would be pretty unhappy if it
>> broke Zero and would like it to not do that.  I haven't had a chance to
>> read all of this yet.  I thought is_accessor was only for Zero so I
>> guess I have to read more why this is getting changed.  I will try to
>> get to it today.
>>
>> Thanks,
>> Coleen
>>
>> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>>> prompt manner, I'm fine with what you proposed.
>>>>> Yeah, that's the plan.
>>>>>
>>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>>> Method
>>>>>> to some Zero-specific location? I don't see any value in keeping it in
>>>>>> Method.
>>>>> That's an interesting trick, but I think it will cause more harm:
>>>>> shared
>>>>> interpreter.cpp would have to know about that Zero-specific method, or
>>>>> otherwise intercept "too wide" accessor shape and narrow it down before
>>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>>>>> evil.
>>>> Ok. Looks good then.
>>> Thanks for taking time to review, Vladimir! I'll count that as the
>>> review from the compiler side.
>>>
>>> I think we still need a review from the runtime side. Folks? For the
>>> record, we are discussing this change:
>>>    http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>
>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>
>>
> 
> 



From christian.thalinger at oracle.com  Thu Nov  5 20:27:16 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 5 Nov 2015 10:27:16 -1000
Subject: jdk 9 performance optimizations
In-Reply-To: <CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
Message-ID: <8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>


> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers <jborgers at jpinpoint.com> wrote:
> 
> I posted in jigsaw-dev list before:
> 
> I found this interesting presentation "Java goes AOT" from JVM Language
> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
> 
> As presented by Christiaan Thalinger from HS compiler team, AOT is used
> with Graal to reduce startup time and quicker peakperformance (tiered).
> Currently they don't do any inlining in AOT yet

That?s not accurate; we do inlining but very limited.

> because compilation time
> blows up by inlining everything since no profiling information is available
> yet. I guess modules and knowing dependencies can help here to reduce this.
> Besides test running to generate profiling data.
> 
> Regards, Jeroen
> Bijlagen
> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
> JVMLS 2015 - Java Goes AOT
> Vitaly Davidovich
> 13:09 (10 uur geleden)
> aan Jeroen, jigsaw-dev
> 
> Yes, I had seen Chris' presentation as well.  Certainly modularization will
> help AOT in many ways.  But, I'm particularly interested on the JIT side.
> What was meant by aggressive lambda inlining, for example? Can anyone point
> at some additional info?
> 
> Thanks
> 
> sent from my phone
> Paul Sandoz <paul.sandoz at oracle.com>
> 13:32 (9 uur geleden)
> aan jigsaw-dev
> Hi Vitaly,
> 
> Probably worth sending an email to the hotspot-dev at openjdk.java.net <mailto:
> hotspot-dev at openjdk.java.net>
> 
>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>> 
>> Yes, I had seen Chris' presentation as well.  Certainly modularization
> will
>> help AOT in many ways.  But, I'm particularly interested on the JIT side.
>> What was meant by aggressive lambda inlining, for example? Can anyone
> point
>> at some additional info?
>> 
> 
> I presume it in part might relate to cracking open the lambda ?box?
> implementing the targeted functional interface to obtain the underlying
> method containing the lambda body, generated by javac, that the box defers
> to, then subsituting the indy call to an invocation of that underlying
> method. Cue lots of hand waving?
> 
> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at
> JVMLS 2014:
> 
>  http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
> --------
> 
> Thanks,
> 
> Jeroen
> 
> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
> 
>> Hi,
>> 
>> One of the goals of Jigsaw that intrigue me, I read here: http://openjdk.
>> java
>> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>> is:
>> *Enable ahead-of-time, whole-program optimization techniques*  -
>> [..]
>> The optimization techniques envisioned here include, but are not limited
>> to: Fast lookup of both JDK and application classes; early bytecode
>> verification; aggressive inlining of, *e.g.*, lambda expressions, and
>> other standard compiler optimizations; construction of JVM-specific memory
>> images that can be loaded more efficiently than class files; ahead-of-time
>> compilation of method bodies to native code; and the removal of unused
>> fields, methods, and classes. These kinds of techniques tend to work best
>> when JDK and application code is analyzed together, prior to run time.
>> [..]
>> 
>>   -
>> 
>>   *Optimize existing code as-is* ? It must be possible to apply the
>>   optimizer tool to existing code already packaged in traditional jar files,
>>   without changing those files.
>>   -
>> 
>>   *Actual optimizations* ? As a proof of concept, provide at least two
>>   optimizations that deliver nontrivial performance benefits.
>> 
>> I am curious about the following:
>> * What is the current state of this? Which techniques/optimizations are
>> already implemented and available from the current ea JDK9 or will be?
>> * Are there any new insights/developments in this area?
>> * I noticed in my JMH microbenchmark with parallel stream and lambda's
>> that it runs slightly faster on 9_b85 compared to 8_u66. Could this be
>> caused by more aggressive inlining of lambda's?
>> * It seems to me that some compilation and optimization work is moved from
>> runtime to link time /AOT time, yet, we don't have profiling information
>> there, so this will be limited, right? Are there obvious cases which work
>> well?
>> * I don't really see why aggressive inlining and std optimizations can now
>> be more effective. Because there will be less de-optimization events needed
>> because of better predictability? Can in-lining now take place in two ways,
>> between platform modules and application? Through interfaces?
>> 
>> Thanks!
>> Jeroen
>> 
>> 
>> 


From coleen.phillimore at oracle.com  Thu Nov  5 20:38:56 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Nov 2015 15:38:56 -0500
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BB1F7.7050807@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com>
Message-ID: <563BBE60.5080002@oracle.com>


Yes, looking at the code, it would be better to have 
is_getter()/is_setter() and have is_accessor() be either, and change the 
interpreter to use is_getter() to mean accessor entry (it's fine that 
it's a little inconsistent, it's not really that confusing).

I'll wait and be more thorough with the next patch.  I didn't see 
anything else major here.

Coleen

On 11/5/15 2:45 PM, Aleksey Shipilev wrote:
> Thanks, Coleen!
>
> The tricky part is that compilers poll Method::is_accessor via:
>
>   bool ciMethod::is_accessor    () const {
>     FETCH_FLAG_FROM_VM(is_accessor);
>   }
>
> #define FETCH_FLAG_FROM_VM(flag_accessor) { \
>    check_is_loaded(); \
>    VM_ENTRY_MARK; \
>    return get_Method()->flag_accessor(); \
> }
>
> ...which may be opaque for IDEs, when you look for usages. I found that
> a text search for "is_accessor" yields only positive matches.
>
> *Actually*, now that I read the code again, there is a suspicious use in
> CallNode::may_modify:
>
>        if (meth->is_accessor()) {
>          return false;
>        }
>
> This seems to break if is_accessor accepts setters. Let me split the
> is_accessor into is_getter/is_setter and re-run tests. If you spot other
> problems in the patch, let me know.
>
> Thanks,
> -Aleksey
>
> On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
>> I am planning on reviewing this but I haven't had time.  And I'm trying
>> to build Zero for a different reason.  I would be pretty unhappy if it
>> broke Zero and would like it to not do that.  I haven't had a chance to
>> read all of this yet.  I thought is_accessor was only for Zero so I
>> guess I have to read more why this is getting changed.  I will try to
>> get to it today.
>>
>> Thanks,
>> Coleen
>>
>> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>>> prompt manner, I'm fine with what you proposed.
>>>>> Yeah, that's the plan.
>>>>>
>>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>>> Method
>>>>>> to some Zero-specific location? I don't see any value in keeping it in
>>>>>> Method.
>>>>> That's an interesting trick, but I think it will cause more harm:
>>>>> shared
>>>>> interpreter.cpp would have to know about that Zero-specific method, or
>>>>> otherwise intercept "too wide" accessor shape and narrow it down before
>>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>>>>> evil.
>>>> Ok. Looks good then.
>>> Thanks for taking time to review, Vladimir! I'll count that as the
>>> review from the compiler side.
>>>
>>> I think we still need a review from the runtime side. Folks? For the
>>> record, we are discussing this change:
>>>     http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>
>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>
>


From coleen.phillimore at oracle.com  Thu Nov  5 20:42:20 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Nov 2015 15:42:20 -0500
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BB918.9020509@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
Message-ID: <563BBF2C.1040301@oracle.com>


Our emails crossed.   This change looks good.  I don't know how 
necessary the Zero TODO is but the comment is fine.

Coleen

On 11/5/15 3:16 PM, Aleksey Shipilev wrote:
> Ah, no, the CallNode::may_modify polls is_accessor only for boxed
> instances, so there are no setters in Java code. Still, we should check
> for getters there explicitly, and the getter/setter split is sensible in
> Method API anyhow.
>
> New webrev:
>    http://cr.openjdk.java.net/~shade/8140650/webrev.02/
>
> Re-spinning RBT for sanity.
>
> Thanks,
> -Aleksey
>
> On 11/05/2015 10:45 PM, Aleksey Shipilev wrote:
>> Thanks, Coleen!
>>
>> The tricky part is that compilers poll Method::is_accessor via:
>>
>>   bool ciMethod::is_accessor    () const {
>>     FETCH_FLAG_FROM_VM(is_accessor);
>>   }
>>
>> #define FETCH_FLAG_FROM_VM(flag_accessor) { \
>>    check_is_loaded(); \
>>    VM_ENTRY_MARK; \
>>    return get_Method()->flag_accessor(); \
>> }
>>
>> ...which may be opaque for IDEs, when you look for usages. I found that
>> a text search for "is_accessor" yields only positive matches.
>>
>> *Actually*, now that I read the code again, there is a suspicious use in
>> CallNode::may_modify:
>>
>>        if (meth->is_accessor()) {
>>          return false;
>>        }
>>
>> This seems to break if is_accessor accepts setters. Let me split the
>> is_accessor into is_getter/is_setter and re-run tests. If you spot other
>> problems in the patch, let me know.
>>
>> Thanks,
>> -Aleksey
>>
>> On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
>>> I am planning on reviewing this but I haven't had time.  And I'm trying
>>> to build Zero for a different reason.  I would be pretty unhappy if it
>>> broke Zero and would like it to not do that.  I haven't had a chance to
>>> read all of this yet.  I thought is_accessor was only for Zero so I
>>> guess I have to read more why this is getting changed.  I will try to
>>> get to it today.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>>>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>>>> prompt manner, I'm fine with what you proposed.
>>>>>> Yeah, that's the plan.
>>>>>>
>>>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>>>> Method
>>>>>>> to some Zero-specific location? I don't see any value in keeping it in
>>>>>>> Method.
>>>>>> That's an interesting trick, but I think it will cause more harm:
>>>>>> shared
>>>>>> interpreter.cpp would have to know about that Zero-specific method, or
>>>>>> otherwise intercept "too wide" accessor shape and narrow it down before
>>>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the lesser
>>>>>> evil.
>>>>> Ok. Looks good then.
>>>> Thanks for taking time to review, Vladimir! I'll count that as the
>>>> review from the compiler side.
>>>>
>>>> I think we still need a review from the runtime side. Folks? For the
>>>> record, we are discussing this change:
>>>>     http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>>
>>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>>>
>>
>


From aleksey.shipilev at oracle.com  Thu Nov  5 20:52:01 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 5 Nov 2015 23:52:01 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BBF2C.1040301@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com>
Message-ID: <563BC171.7050703@oracle.com>

Thanks for the review, Coleen!

I'll wait for RBT results to come in, and if they are positive, I'll
push (I think through hs-comp, since it affects compilers mostly).

TODO in interpreter.cpp serves as the anchor for the upcoming Zero RFE.

Cheers,
-Aleksey

On 11/05/2015 11:42 PM, Coleen Phillimore wrote:
> 
> Our emails crossed.   This change looks good.  I don't know how
> necessary the Zero TODO is but the comment is fine.
> 
> Coleen
> 
> On 11/5/15 3:16 PM, Aleksey Shipilev wrote:
>> Ah, no, the CallNode::may_modify polls is_accessor only for boxed
>> instances, so there are no setters in Java code. Still, we should check
>> for getters there explicitly, and the getter/setter split is sensible in
>> Method API anyhow.
>>
>> New webrev:
>>    http://cr.openjdk.java.net/~shade/8140650/webrev.02/
>>
>> Re-spinning RBT for sanity.
>>
>> Thanks,
>> -Aleksey
>>
>> On 11/05/2015 10:45 PM, Aleksey Shipilev wrote:
>>> Thanks, Coleen!
>>>
>>> The tricky part is that compilers poll Method::is_accessor via:
>>>
>>>   bool ciMethod::is_accessor    () const {
>>>     FETCH_FLAG_FROM_VM(is_accessor);
>>>   }
>>>
>>> #define FETCH_FLAG_FROM_VM(flag_accessor) { \
>>>    check_is_loaded(); \
>>>    VM_ENTRY_MARK; \
>>>    return get_Method()->flag_accessor(); \
>>> }
>>>
>>> ...which may be opaque for IDEs, when you look for usages. I found that
>>> a text search for "is_accessor" yields only positive matches.
>>>
>>> *Actually*, now that I read the code again, there is a suspicious use in
>>> CallNode::may_modify:
>>>
>>>        if (meth->is_accessor()) {
>>>          return false;
>>>        }
>>>
>>> This seems to break if is_accessor accepts setters. Let me split the
>>> is_accessor into is_getter/is_setter and re-run tests. If you spot other
>>> problems in the patch, let me know.
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>> On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
>>>> I am planning on reviewing this but I haven't had time.  And I'm trying
>>>> to build Zero for a different reason.  I would be pretty unhappy if it
>>>> broke Zero and would like it to not do that.  I haven't had a chance to
>>>> read all of this yet.  I thought is_accessor was only for Zero so I
>>>> guess I have to read more why this is getting changed.  I will try to
>>>> get to it today.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>>>>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>>>>> prompt manner, I'm fine with what you proposed.
>>>>>>> Yeah, that's the plan.
>>>>>>>
>>>>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>>>>> Method
>>>>>>>> to some Zero-specific location? I don't see any value in keeping
>>>>>>>> it in
>>>>>>>> Method.
>>>>>>> That's an interesting trick, but I think it will cause more harm:
>>>>>>> shared
>>>>>>> interpreter.cpp would have to know about that Zero-specific
>>>>>>> method, or
>>>>>>> otherwise intercept "too wide" accessor shape and narrow it down
>>>>>>> before
>>>>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the
>>>>>>> lesser
>>>>>>> evil.
>>>>>> Ok. Looks good then.
>>>>> Thanks for taking time to review, Vladimir! I'll count that as the
>>>>> review from the compiler side.
>>>>>
>>>>> I think we still need a review from the runtime side. Folks? For the
>>>>> record, we are discussing this change:
>>>>>     http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>>>
>>>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>
>>>>>
>>>
>>
> 



From coleen.phillimore at oracle.com  Thu Nov  5 22:32:47 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Nov 2015 17:32:47 -0500
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod
	is not MT safe
In-Reply-To: <563BA5D3.5060905@oracle.com>
References: <5638FE82.4060801@oracle.com>
	<563B0CFA.8070508@oracle.com>	<563B2658.4090505@oracle.com>
	<563B5F9E.6050606@oracle.com>	<563B87E2.9010603@oracle.com>
	<563BA5D3.5060905@oracle.com>
Message-ID: <563BD90F.7010609@oracle.com>


Hi Vladimir,

I think DependencyContext is big enough to be a new file, and not be 
added to instanceKlass.hpp.  There are too many unrelated things in 
instanceKlass.  The hidden bit stuff is ok in InstanceKlass.  Does 
has_unloaded_dependent accessed concurrently like 
_is_marked_dependent?   It would be nice to move _is_marked_dependent 
field also to encapsulate it but that would ruin your bit packing.

Also, since you have changes to vmStructs, do you have duplicate changes 
to make to the serviceability agent code?  Are there duplicate changes 
for the jvmci code?

Thanks,
Coleen

On 11/5/15 1:54 PM, Vladimir Ivanov wrote:
> Updated version:
> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/
>
> In addition to name polishing and encapsulating purging logic in 
> {add|remove}_dependent_nmethod methods, I got rid of 
> DependencyContext::wipe() method and added "friend class 
> TestDependencyContext" declaration (noticed such practice in other 
> cases when tests need access to tested class internals).
>
> Best regards,
> Vladimir Ivanov
>
> On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
>> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>>> Regarding internal purging, add_dependent_methods doesn't iterate over
>>> the whole list, but looks for the relevant entry. It means that "purge"
>>> flag should force full iteration. I think that keeping them separately
>>> (add_dependent_methods() vs purge()) looks cleaner.
>>
>> I think it is better to encapsulate the "piggybacking" behavior within
>> the DependencyContext itself, because that seems to be a
>> general/expected feature of DependencyContext class. It is weird to ask
>> class users to spell it out specifically.
>>
>>
>>> I could add "purge" flag and move the following code into
>>> add_dependent_methods:
>>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool 
>>> do_purge
>>> = false) {
>>>     ...
>>>     if (has_unloaded_dependent() && do_purge) {
>>>       purge();
>>>     }
>>> }
>>>
>>> Is it what you are suggesting?
>>
>> Yes.
>>
>>
>>>>    * DependencyContext now has three methods: purge(), clear(), 
>>>> wipe(). I
>>>> have trouble understanding which method does what!
>>
>>> There are basically 2 operations needed:
>>>    * purge(): only remove stale entries; no additional work is 
>>> performed;
>>
>> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>>   WeakHashMap.expungeStaleEntries()
>>   ThreadLocal.expungeStaleEntries()
>>   WeakCache.expungeStaleEntries()
>>
>>
>>> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
>>> just deallocates all nmethodBucket entries without touching 
>>> nmethods. It
>>> is necessary since nmethod pointers are faked by the test.
>>
>> Okay. Is there a convention how you should name the test-related methods
>> like these? I would expect something like debug_deallocate_buckets().
>>
>> Thanks,
>> -Aleksey
>>
>>


From david.holmes at oracle.com  Thu Nov  5 22:54:47 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 08:54:47 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563B7D4A.9030401@redhat.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<563B2D5B.30706@redhat.com> <563B7D4A.9030401@redhat.com>
Message-ID: <563BDE37.4070207@oracle.com>

Hi Andrew,

On 6/11/2015 2:01 AM, Andrew Haley wrote:
> On 11/05/2015 10:20 AM, Andrew Haley wrote:
>> On 05/11/15 04:36, David Holmes wrote:
>>> I still need some assistance from Aarch64 folk to write their get_thread
>>> function please!
>
> Here you are.
>
> I found a bug in the existing AArch64 get_thread.
>
> The specification of MacroAssembler::get_thread() is that it clobbers
> no registers.  Most of the vector state is callee-clobbered, so if you
> want to call a get_thread() method which is written in C you have to
> save the entire vector state as well as all call-clobbered general
> registers.  You have to do this because it is possible that GCC will
> use a vector register for temporary storage.  (This is not just a
> theoretical possibility: I have seen AArch64 bugs caused by this
> actually happening.)  So, I wrote code to save all the general and
> vector registers.  It was horrible.
>
> I scrapped it and instead wrote a little assembly-language routine
> which returns the contents of Thread::_thr_current.  This clobbers
> only a couple of registers, and everything is much nicer.

Not sure why you had to inject the helper rather than just "call" 
Thread::current() ?? But it's your code :)

However all of the threadLS_<os>_<arch> files have been deleted but you 
have added a .s file using that now-defunct naming scheme. Would it be 
better named something else - that relates it back to the 
thread_linux_aarch64.hpp usage ie thread_linux_aarch64.s ?

Many thanks,
David

> I suppose it might have been possible to change the specification of
> MacroAssembler::get_thread() so that it clobbered the vector state,
> but never mind: it's done now.
>
> Andrew.
>

From david.holmes at oracle.com  Thu Nov  5 22:58:51 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 08:58:51 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUzDXo0AJnRR-N45annc13xS4aZ48O2X795GbNUZEFGU-A@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<CAA-vtUzDXo0AJnRR-N45annc13xS4aZ48O2X795GbNUZEFGU-A@mail.gmail.com>
Message-ID: <563BDF2B.1090506@oracle.com>

On 5/11/2015 8:18 PM, Thomas St?fe wrote:
> Hi David,
>
> looks good and works fine on AIX and Linux Power.
>
> We could now get rid of the thread_<os>_inline.hpp files too, right?

Right. I was waiting to see if anyone would comment on that ("leave them 
in just in case we need some os-specific thread stuff ..."). But I will 
go ahead and remove them before the official RFR.

Thanks,
David

> Kind Regards, Thomas
>
>
>
> On Thu, Nov 5, 2015 at 5:36 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Here's updated webrev:
>
>     http://cr.openjdk.java.net/~dholmes/8132510/webrev.v3/
>
>     Changes since v2:
>
>     - include Thomas's AIX fixes
>     - Add assertion for not-NULL into Thread::current()
>     - Add Thread::current_or_null() for when NULL can be expected, or
>     for where failing an assert would cause more problems (eg crash
>     reporting). Most uses of
>     ThreadLocalStorage::thread()/get_thread_slow() now call
>     current_or_null().
>     - Removed Thread::current_noinline() (it was only used in an assert
>     in some G1 code, so the inline-or-not seems irrelevant)
>     - Made Thread::clear_thread_current() private
>
>     I'm debating whether the get_thread implementations should call
>     Thread::current() or Thread::current_or_null(). We should never get
>     NULL but seems unnecessary overhead to check that with an assert in
>     this code. Opinions welcomed.
>
>     I still need some assistance from Aarch64 folk to write their
>     get_thread function please!
>
>     I still have footprint and performance measurements to make before
>     proposing formal RFR.
>
>     I also am still to determine whether to include the ability to hook
>     in a pthread_ based implementation instead.
>
>     Thanks,
>     David
>
>
>     On 4/11/2015 7:26 PM, David Holmes wrote:
>
>         On 4/11/2015 6:17 PM, Thomas St?fe wrote:
>
>             Hi David,
>
>             On Wed, Nov 4, 2015 at 5:08 AM, David Holmes
>             <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>             <mailto:david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>>> wrote:
>
>                  Hi Thomas,
>
>
>                      One question about your changes:
>
>                      Before, Thread::current() would assert instead of
>             returning
>             NULL if
>                      called before Thread::initialize_thread_current()
>             or after
>                      Thead::clear_thread_current() . Now, we just return
>             NULL. Is
>                      this intended?
>
>
>                  Ah great question ... so before we have a mix of calls to:
>
>                  - Thread::current()  (asserts on NULL as does
>             JavaThread::current)
>                  - ThreadLocalStorage::thread() (can return NULL)
>                  - ThreadLocalStorage::get_thread_slow() (can return NULL)
>
>                  and now we only have Thread::current() which means we
>             have to allow
>                  returning NULL because it can be intentionally called
>             when a thread
>                  is not attached. That means we won't directly catch
>             calls to
>                  Thread::current() from code that doesn't realize it is
>             calling it
>                  "too soon" - though there do exist numerous assertions
>             in the
>                  callers of Thread::current() that check the result is
>             not NULL.
>
>                  I could add the assert to Thread::current() and also add
>                  Thread::current_or_null() to be used by code that needs
>             to use it to
>                  check for attachment (ie JNI code). I'd also have to
>             examine all the
>                  changed ThreadLocalStorage::thread/get_thread_slow
>             call-sites to see
>                  if any of those legitimately expect the thread may not
>             be attached.
>
>                  What do you think?
>
>
>             I would prefer having Thread::current() to assert and to have a
>             Thread::current_or_null() for cases where NULL could occurr.
>             I tend to
>             hit that assert a lot in development, it is useful. And the
>             non-asserting version gets already used in a number of
>             places, also in
>             our (not OpenJDK) coding.
>
>
>         Yes I agree. Most of the TLS::thread() and
>         TLS::get_thread_slow() should
>         actually call Thread::current_or_null(). I also found a couple of
>         existing Thread::current()'s that should be current_or_null(). :)
>
>                  I also need to look at the location of Thread::current
>             in the .hpp
>                  file rather than .inline.hpp and reconcile that with
>             comments
>                  regarding the noinline version (which is only used in
>                  g1HotCardCache.hpp).
>
>
>             Could we leave just the inline version in thread.hpp and
>             remove the
>             noinline version altogether? Now that Thread::current() is
>             very simple,
>             we may just as well keep it in the class body like the other
>             accessors.
>
>
>         I'll see if the g1 code can tolerate that.
>
>         I'll update a prepare a new webrev tomorrow.
>
>         Thanks,
>         David
>
>             Thanks, Thomas
>
>
>

From mark.reinhold at oracle.com  Thu Nov  5 23:29:16 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  5 Nov 2015 15:29:16 -0800 (PST)
Subject: JEP 279: Improve Test-Failure Troubleshooting
Message-ID: <20151105232916.9BD737FC92@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/279

- Mark

From coleen.phillimore at oracle.com  Fri Nov  6 01:33:30 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Nov 2015 20:33:30 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
Message-ID: <563C036A.3050008@oracle.com>

With the RedHat compiler that I'm using g++ (GCC) 4.8.2 20140120 (Red 
Hat 4.8.2-16)
these additional includes are needed to compile without precompiled headers.

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

I'm not sure why allocation.inline.hpp is needed unless the virtual 
destructor in src/share/vm/gc/shared/plab.hpp PLABStats implicitly calls 
delete.

Tested with compiles of Zero plus plain linux debug/fastdebug/product.

Thanks,
Coleen

From jeremymanson at google.com  Fri Nov  6 01:58:28 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 5 Nov 2015 17:58:28 -0800
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56370567.3090801@oracle.com>
References: <56370567.3090801@oracle.com>
Message-ID: <CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>

Something that's bitten me with __thread: it isn't async-safe when called
from a shared object on Linux.  Have you vetted to make sure this doesn't
make HS less async-safe?

Jeremy

On Sun, Nov 1, 2015 at 10:40 PM, David Holmes <david.holmes at oracle.com>
wrote:

> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
> A simple (in principle) but wide-ranging change which should appeal to our
> Code Deletion Engineer's. We implement Thread::current() using a
> compiler/language-based thread-local variable eg:
>
>
>  static __thread Thread *_thr_current;
>
>  inline Thread* Thread::current() {
>    return _thr_current;
>  }
>
> with an appropriate setter of course. By doing this we can completely
> remove the platform-specific ThreadLocalStorage implementations, and the
> associated os::thread_local_storage* calls, plus all the uses of
> ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
> This extends the previous work done on Solaris to implement
> ThreadLocalStorage::thread() using compiler-based thread-locals.
>
> We can also consolidate nearly all the os_cpu versions of
> MacroAssembler::get_thread on x86 into one cpu specific one ( a special
> variant is still needed for 32-bit Windows).
>
> As a result of this change we have further potential cleanups:
> - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
> empty and could also be removed
> - the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
> "cache" on 32-bit) now has no affect and so could be completely removed
> from the build system
>
> I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
> add the removal of the "inline" files to this CR if people think it worth
> removing them.
>
> I have one missing piece on Aarch64 - I need to change
> MacroAssembler::get_thread to simply call Thread::current() as on other
> platforms, but I don't know how to write that. I would appreciate it if
> someone could give me the right code for that.
>
> I would also appreciate comments/testing by the AIX and PPC64 folk as well.
>
> A concern about memory-leaks had previously been raised, but experiments
> using simple C code on linux 86 and Solaris showed no issues. Also note
> that Aarch64 already uses this kind of thread-local.
>
> Thanks,
> David
>

From jeremymanson at google.com  Fri Nov  6 02:24:20 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 5 Nov 2015 18:24:20 -0800
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
Message-ID: <CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>

I should probably elaborate on this.  With glibc + ELF, the first time a
thread accesses a variable declared __thread, if that variable is in a
shared library (as opposed to the main executable), the system calls
malloc() to allocate the space for it.  If that happens in a signal that is
being delivered during a call to malloc(), then you usually get a crash.

This may bite you if AsyncGetCallTrace uses Thread::current(), and you use
system timers to do profiling.  If a thread doing a malloc() prior to the
first time it accesses Thread::current(), and it gets delivered a signal,
it might die.  This is especially likely for pure native threads started by
native code.

I believe that this is a use case you support, so you might want to make
sure it is okay.

Jeremy

On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson <jeremymanson at google.com>
wrote:

> Something that's bitten me with __thread: it isn't async-safe when called
> from a shared object on Linux.  Have you vetted to make sure this doesn't
> make HS less async-safe?
>
> Jeremy
>
> On Sun, Nov 1, 2015 at 10:40 PM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>> A simple (in principle) but wide-ranging change which should appeal to
>> our Code Deletion Engineer's. We implement Thread::current() using a
>> compiler/language-based thread-local variable eg:
>>
>>
>>  static __thread Thread *_thr_current;
>>
>>  inline Thread* Thread::current() {
>>    return _thr_current;
>>  }
>>
>> with an appropriate setter of course. By doing this we can completely
>> remove the platform-specific ThreadLocalStorage implementations, and the
>> associated os::thread_local_storage* calls, plus all the uses of
>> ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
>> This extends the previous work done on Solaris to implement
>> ThreadLocalStorage::thread() using compiler-based thread-locals.
>>
>> We can also consolidate nearly all the os_cpu versions of
>> MacroAssembler::get_thread on x86 into one cpu specific one ( a special
>> variant is still needed for 32-bit Windows).
>>
>> As a result of this change we have further potential cleanups:
>> - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
>> empty and could also be removed
>> - the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
>> "cache" on 32-bit) now has no affect and so could be completely removed
>> from the build system
>>
>> I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
>> add the removal of the "inline" files to this CR if people think it worth
>> removing them.
>>
>> I have one missing piece on Aarch64 - I need to change
>> MacroAssembler::get_thread to simply call Thread::current() as on other
>> platforms, but I don't know how to write that. I would appreciate it if
>> someone could give me the right code for that.
>>
>> I would also appreciate comments/testing by the AIX and PPC64 folk as
>> well.
>>
>> A concern about memory-leaks had previously been raised, but experiments
>> using simple C code on linux 86 and Solaris showed no issues. Also note
>> that Aarch64 already uses this kind of thread-local.
>>
>> Thanks,
>> David
>>
>
>

From david.holmes at oracle.com  Fri Nov  6 03:09:03 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 13:09:03 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
Message-ID: <563C19CF.30001@oracle.com>

Hi Jeremy,

I was going to ask you to elaborate :)

On 6/11/2015 12:24 PM, Jeremy Manson wrote:
> I should probably elaborate on this.  With glibc + ELF, the first time a
> thread accesses a variable declared __thread, if that variable is in a
> shared library (as opposed to the main executable), the system calls
> malloc() to allocate the space for it.  If that happens in a signal that
> is being delivered during a call to malloc(), then you usually get a crash.

My understanding of the ELF ABI for thread-locals - which I read about 
in the Solaris 11.1 Linkers and libraries guide - does require use of 
the dynamic TLS model for any dynamically loaded shared object which 
defines a thread-local, but that is what we use as I understand it. The 
docs state:

"A shared object containing only dynamic TLS can be loaded following 
process startup without limitations. The runtime linker extends the list 
of initialization records to include the initialization template of the 
new object. The new object is given an index of m = M + 1. The
counter M is incremented by 1. However, the allocation of new TLS blocks 
is deferred until the blocks are actually referenced."

Now I guess "extends the list" might be implemented using malloc ... but 
this will only occur in the main thread (the one started by the launcher 
to load the JVM and become the main thread), at the time libjvm is 
loaded - which will all be over before any agent etc can run and do 
anything. But "allocation ... is deferred" suggests we may have a 
problem until either the first call to Thread::current or the call to 
Thread::initialize_thread_current. If it is the former then that should 
occur well before any agent etc can be loaded. And I can easily inject 
an initial dummy call to initialize_thread_current(null) to force the 
TLS allocation.

> This may bite you if AsyncGetCallTrace uses Thread::current(), and you
> use system timers to do profiling.  If a thread doing a malloc() prior
> to the first time it accesses Thread::current(), and it gets delivered a
> signal, it might die.  This is especially likely for pure native threads
> started by native code.
>
> I believe that this is a use case you support, so you might want to make
> sure it is okay.

For a VM embedded in a process, which already contains native threads, 
that will later attach to the VM, this may indeed be a problem. One 
would have hoped however that the implementation of TLS would be 
completely robust, at least for something as simple as getting a signal 
whilst in the allocator.

I'm unclear how to test for or check for this kind of problem. Arguably 
there could be many things that are async-unsafe in this way.

Need to think more about this and do some more research. Would also 
appreciate any insight from any glibc and/or ELF gurus.

Thanks.
David

> Jeremy
>
> On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson <jeremymanson at google.com
> <mailto:jeremymanson at google.com>> wrote:
>
>     Something that's bitten me with __thread: it isn't async-safe when
>     called from a shared object on Linux.  Have you vetted to make sure
>     this doesn't make HS less async-safe?
>
>     Jeremy
>
>     On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>         Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>         A simple (in principle) but wide-ranging change which should
>         appeal to our Code Deletion Engineer's. We implement
>         Thread::current() using a compiler/language-based thread-local
>         variable eg:
>
>
>           static __thread Thread *_thr_current;
>
>           inline Thread* Thread::current() {
>             return _thr_current;
>           }
>
>         with an appropriate setter of course. By doing this we can
>         completely remove the platform-specific ThreadLocalStorage
>         implementations, and the associated os::thread_local_storage*
>         calls, plus all the uses of ThreadLocalStorage::thread() and
>         ThreadLocalStorage::get_thread_slow(). This extends the previous
>         work done on Solaris to implement ThreadLocalStorage::thread()
>         using compiler-based thread-locals.
>
>         We can also consolidate nearly all the os_cpu versions of
>         MacroAssembler::get_thread on x86 into one cpu specific one ( a
>         special variant is still needed for 32-bit Windows).
>
>         As a result of this change we have further potential cleanups:
>         - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>         completely empty and could also be removed
>         - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>         sp-map "cache" on 32-bit) now has no affect and so could be
>         completely removed from the build system
>
>         I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR,
>         but could add the removal of the "inline" files to this CR if
>         people think it worth removing them.
>
>         I have one missing piece on Aarch64 - I need to change
>         MacroAssembler::get_thread to simply call Thread::current() as
>         on other platforms, but I don't know how to write that. I would
>         appreciate it if someone could give me the right code for that.
>
>         I would also appreciate comments/testing by the AIX and PPC64
>         folk as well.
>
>         A concern about memory-leaks had previously been raised, but
>         experiments using simple C code on linux 86 and Solaris showed
>         no issues. Also note that Aarch64 already uses this kind of
>         thread-local.
>
>         Thanks,
>         David
>
>
>

From christian.thalinger at oracle.com  Fri Nov  6 06:22:51 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 5 Nov 2015 20:22:51 -1000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
Message-ID: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8140424 <https://bugs.openjdk.java.net/browse/JDK-8140424>
http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>

When working on JDK-8024545 I added code that prefixes developer and notproduct flags with CONST_. I think I did this to be able to access the address of these variables for the flag table. But this is not necessary because these flag cannot be written anyway. 

I am proposing to remove the CONST_ prefix and define the variables as const.

From david.holmes at oracle.com  Fri Nov  6 06:26:44 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 16:26:44 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C19CF.30001@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com>
Message-ID: <563C4824.7040300@oracle.com>

Hi Jeremy,

Okay I have read:

https://sourceware.org/glibc/wiki/TLSandSignals

and the tree of mail postings referenced therefrom - great reading! :)

So basic problem: access to __thread variables is not async-signal-safe

Exacerbator to problem: first attempt to even read a __thread variable 
can lead to allocation which is the real problem in relation to 
async-signal-safety

I mention the exacerbator because pthread_getspecific and 
pthread_setSpecific are also not async-signal-safe but we already use 
them. However, pthread_getspecific is in fact (per email threads linked 
above) effectively async-signal-safe, and further a call to 
pthread_getspecific never results in a call to pthread_setspecific or an 
allocation. Hence the pthread functions are almost, if not completely, 
safe in practice with reasonable uses (ie only read from signal 
handler). Which explain this code in existing Thread::current()

#ifdef PARANOID
   // Signal handler should call ThreadLocalStorage::get_thread_slow()
   Thread* t = ThreadLocalStorage::get_thread_slow();
   assert(t != NULL && !t->is_inside_signal_handler(),
          "Don't use Thread::current() inside signal handler");
#endif

So problem scenario is: use of __thread variable (that belongs to the 
shared-library) in a signal handler.

Solution 0: don't do that. Seriously - like any other 
async-signal-unsafe stuff we should not be using it in real signal 
handlers. The crash handler is a different matter - we try all sorts 
there because it might work and you can't die twice.

Otherwise: narrow the window of exposure.

1. We ensure we initialize thread_current (even with a dummy value) as 
early as possible in the thread that loads libjvm. As we have no signal 
handlers installed at that point that might use the same variable, we 
can not hit the problem scenario.

2. We ensure we initialize thread_current in a new thread with all 
signals blocked. This again avoids the problem scenario.

3. We initialize thread_current in an attaching thread as soon as 
possible and we again first block all signals.

That still leaves the problem of an unattached native thread taking a 
signal whilst in async-signal-unsafe code, and executing a signal 
handler which in turns tries to access thread_current for the first 
time. This signal handler need not be an actual JVM handler, but one 
attached by other native code eg an agent. I'm not clear in the latter 
case how reasonable it is for an agent's handler to try and do things 
from an unattached thread - and we don't claim any JNI interfaces can, 
or should, be called from a signal handler - but it is something you can 
probably get away with today.

Let me also point out that we already effectively have this code in 
Solaris already (at the ThreadLocalStorage class level). So if there is 
something here that will prevent the current proposal we already have a 
problem on Solaris. :(

Thoughts/comments/suggestions?

Thanks,
David

On 6/11/2015 1:09 PM, David Holmes wrote:
> Hi Jeremy,
>
> I was going to ask you to elaborate :)
>
> On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>> I should probably elaborate on this.  With glibc + ELF, the first time a
>> thread accesses a variable declared __thread, if that variable is in a
>> shared library (as opposed to the main executable), the system calls
>> malloc() to allocate the space for it.  If that happens in a signal that
>> is being delivered during a call to malloc(), then you usually get a
>> crash.
>
> My understanding of the ELF ABI for thread-locals - which I read about
> in the Solaris 11.1 Linkers and libraries guide - does require use of
> the dynamic TLS model for any dynamically loaded shared object which
> defines a thread-local, but that is what we use as I understand it. The
> docs state:
>
> "A shared object containing only dynamic TLS can be loaded following
> process startup without limitations. The runtime linker extends the list
> of initialization records to include the initialization template of the
> new object. The new object is given an index of m = M + 1. The
> counter M is incremented by 1. However, the allocation of new TLS blocks
> is deferred until the blocks are actually referenced."
>
> Now I guess "extends the list" might be implemented using malloc ... but
> this will only occur in the main thread (the one started by the launcher
> to load the JVM and become the main thread), at the time libjvm is
> loaded - which will all be over before any agent etc can run and do
> anything. But "allocation ... is deferred" suggests we may have a
> problem until either the first call to Thread::current or the call to
> Thread::initialize_thread_current. If it is the former then that should
> occur well before any agent etc can be loaded. And I can easily inject
> an initial dummy call to initialize_thread_current(null) to force the
> TLS allocation.
>
>> This may bite you if AsyncGetCallTrace uses Thread::current(), and you
>> use system timers to do profiling.  If a thread doing a malloc() prior
>> to the first time it accesses Thread::current(), and it gets delivered a
>> signal, it might die.  This is especially likely for pure native threads
>> started by native code.
>>
>> I believe that this is a use case you support, so you might want to make
>> sure it is okay.
>
> For a VM embedded in a process, which already contains native threads,
> that will later attach to the VM, this may indeed be a problem. One
> would have hoped however that the implementation of TLS would be
> completely robust, at least for something as simple as getting a signal
> whilst in the allocator.
>
> I'm unclear how to test for or check for this kind of problem. Arguably
> there could be many things that are async-unsafe in this way.
>
> Need to think more about this and do some more research. Would also
> appreciate any insight from any glibc and/or ELF gurus.
>
> Thanks.
> David
>
>> Jeremy
>>
>> On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson <jeremymanson at google.com
>> <mailto:jeremymanson at google.com>> wrote:
>>
>>     Something that's bitten me with __thread: it isn't async-safe when
>>     called from a shared object on Linux.  Have you vetted to make sure
>>     this doesn't make HS less async-safe?
>>
>>     Jeremy
>>
>>     On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>>         bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>         Open webrev:
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>>         A simple (in principle) but wide-ranging change which should
>>         appeal to our Code Deletion Engineer's. We implement
>>         Thread::current() using a compiler/language-based thread-local
>>         variable eg:
>>
>>
>>           static __thread Thread *_thr_current;
>>
>>           inline Thread* Thread::current() {
>>             return _thr_current;
>>           }
>>
>>         with an appropriate setter of course. By doing this we can
>>         completely remove the platform-specific ThreadLocalStorage
>>         implementations, and the associated os::thread_local_storage*
>>         calls, plus all the uses of ThreadLocalStorage::thread() and
>>         ThreadLocalStorage::get_thread_slow(). This extends the previous
>>         work done on Solaris to implement ThreadLocalStorage::thread()
>>         using compiler-based thread-locals.
>>
>>         We can also consolidate nearly all the os_cpu versions of
>>         MacroAssembler::get_thread on x86 into one cpu specific one ( a
>>         special variant is still needed for 32-bit Windows).
>>
>>         As a result of this change we have further potential cleanups:
>>         - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>>         completely empty and could also be removed
>>         - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>>         sp-map "cache" on 32-bit) now has no affect and so could be
>>         completely removed from the build system
>>
>>         I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR,
>>         but could add the removal of the "inline" files to this CR if
>>         people think it worth removing them.
>>
>>         I have one missing piece on Aarch64 - I need to change
>>         MacroAssembler::get_thread to simply call Thread::current() as
>>         on other platforms, but I don't know how to write that. I would
>>         appreciate it if someone could give me the right code for that.
>>
>>         I would also appreciate comments/testing by the AIX and PPC64
>>         folk as well.
>>
>>         A concern about memory-leaks had previously been raised, but
>>         experiments using simple C code on linux 86 and Solaris showed
>>         no issues. Also note that Aarch64 already uses this kind of
>>         thread-local.
>>
>>         Thanks,
>>         David
>>
>>
>>

From christian.thalinger at oracle.com  Fri Nov  6 06:27:35 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 5 Nov 2015 20:27:35 -1000
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
Message-ID: <54B6BAA1-C4FF-42F0-BB69-64C4558D7601@oracle.com>


> On Nov 4, 2015, at 8:21 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> can somebody please review and sponsor the following tiny build fix:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
> https://bugs.openjdk.java.net/browse/JDK-8141416
> 
> Building hotspot on certain systems results in a series of:
> expr: syntax error
> expr: syntax error
> expr: syntax error
> expr: syntax error
> 
> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
> -dumpversion" doesn't print a micro-version:
> 
> Ubuntu:
> $ gcc -dumpversion
> 4.6
> 
> Any other Linux:
> $ gcc -dumpversion
> 4.8.3
> 
> This "feature" is tracked under
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
> 
> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
> gcc and use it in the following way:
> 
> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f3)

I?ve added this.  Thanks for fixing it.

> 
> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
> $(CC_VER_MICRO) = 1), 1)
>  $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
> supported because of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
> endif
> 
> The shell expression results in a syntax error if $(CC_VER_MICRO)
> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
> 
> Thank you and best regards,
> Volker


From jeremymanson at google.com  Fri Nov  6 06:55:27 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 5 Nov 2015 22:55:27 -0800
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C4824.7040300@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
Message-ID: <CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>

FWIW, Google tried to convince the glibc maintainers to make this
async-safe, but they weren't biting:

https://sourceware.org/ml/libc-alpha/2014-01/msg00033.html

Most of the things you can do are going to be mitigation rather than a
fix.  I did what you suggest to mitigate, and no one complained, until
someone at Google started a sidecar C++ thread that did a boatload of
malloc'ing.

My workaround was far sneakier, and fixes the problem entirely, but you
probably won't want to do it for code hygiene reasons.  I declare the
__thread variable in the java launcher itself, and then export a function
that provides a pointer to it.  In practice, in glibc, if it is in the main
executable, ELF is smart enough to declare it as part of the stack, and is
therefore async-safe.

Fortunately, while this is a fun thing to think about, I don't think there
are any async paths in the JVM that use Thread::current() (although I could
be wrong - there is a comment in there saying not to call Thread::current()
in a signal handler...).  I would check the call paths in AsyncGetCallTrace
to make sure.

Jeremy

On Thu, Nov 5, 2015 at 10:26 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Jeremy,
>
> Okay I have read:
>
> https://sourceware.org/glibc/wiki/TLSandSignals
>
> and the tree of mail postings referenced therefrom - great reading! :)
>
> So basic problem: access to __thread variables is not async-signal-safe
>
> Exacerbator to problem: first attempt to even read a __thread variable can
> lead to allocation which is the real problem in relation to
> async-signal-safety
>
> I mention the exacerbator because pthread_getspecific and
> pthread_setSpecific are also not async-signal-safe but we already use them.
> However, pthread_getspecific is in fact (per email threads linked above)
> effectively async-signal-safe, and further a call to pthread_getspecific
> never results in a call to pthread_setspecific or an allocation. Hence the
> pthread functions are almost, if not completely, safe in practice with
> reasonable uses (ie only read from signal handler). Which explain this code
> in existing Thread::current()
>
> #ifdef PARANOID
>   // Signal handler should call ThreadLocalStorage::get_thread_slow()
>   Thread* t = ThreadLocalStorage::get_thread_slow();
>   assert(t != NULL && !t->is_inside_signal_handler(),
>          "Don't use Thread::current() inside signal handler");
> #endif
>
> So problem scenario is: use of __thread variable (that belongs to the
> shared-library) in a signal handler.
>
> Solution 0: don't do that. Seriously - like any other async-signal-unsafe
> stuff we should not be using it in real signal handlers. The crash handler
> is a different matter - we try all sorts there because it might work and
> you can't die twice.
>
> Otherwise: narrow the window of exposure.
>
> 1. We ensure we initialize thread_current (even with a dummy value) as
> early as possible in the thread that loads libjvm. As we have no signal
> handlers installed at that point that might use the same variable, we can
> not hit the problem scenario.
>
> 2. We ensure we initialize thread_current in a new thread with all signals
> blocked. This again avoids the problem scenario.
>
> 3. We initialize thread_current in an attaching thread as soon as possible
> and we again first block all signals.
>
> That still leaves the problem of an unattached native thread taking a
> signal whilst in async-signal-unsafe code, and executing a signal handler
> which in turns tries to access thread_current for the first time. This
> signal handler need not be an actual JVM handler, but one attached by other
> native code eg an agent. I'm not clear in the latter case how reasonable it
> is for an agent's handler to try and do things from an unattached thread -
> and we don't claim any JNI interfaces can, or should, be called from a
> signal handler - but it is something you can probably get away with today.
>
> Let me also point out that we already effectively have this code in
> Solaris already (at the ThreadLocalStorage class level). So if there is
> something here that will prevent the current proposal we already have a
> problem on Solaris. :(
>
> Thoughts/comments/suggestions?
>
> Thanks,
> David
>
>
> On 6/11/2015 1:09 PM, David Holmes wrote:
>
>> Hi Jeremy,
>>
>> I was going to ask you to elaborate :)
>>
>> On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>>
>>> I should probably elaborate on this.  With glibc + ELF, the first time a
>>> thread accesses a variable declared __thread, if that variable is in a
>>> shared library (as opposed to the main executable), the system calls
>>> malloc() to allocate the space for it.  If that happens in a signal that
>>> is being delivered during a call to malloc(), then you usually get a
>>> crash.
>>>
>>
>> My understanding of the ELF ABI for thread-locals - which I read about
>> in the Solaris 11.1 Linkers and libraries guide - does require use of
>> the dynamic TLS model for any dynamically loaded shared object which
>> defines a thread-local, but that is what we use as I understand it. The
>> docs state:
>>
>> "A shared object containing only dynamic TLS can be loaded following
>> process startup without limitations. The runtime linker extends the list
>> of initialization records to include the initialization template of the
>> new object. The new object is given an index of m = M + 1. The
>> counter M is incremented by 1. However, the allocation of new TLS blocks
>> is deferred until the blocks are actually referenced."
>>
>> Now I guess "extends the list" might be implemented using malloc ... but
>> this will only occur in the main thread (the one started by the launcher
>> to load the JVM and become the main thread), at the time libjvm is
>> loaded - which will all be over before any agent etc can run and do
>> anything. But "allocation ... is deferred" suggests we may have a
>> problem until either the first call to Thread::current or the call to
>> Thread::initialize_thread_current. If it is the former then that should
>> occur well before any agent etc can be loaded. And I can easily inject
>> an initial dummy call to initialize_thread_current(null) to force the
>> TLS allocation.
>>
>> This may bite you if AsyncGetCallTrace uses Thread::current(), and you
>>> use system timers to do profiling.  If a thread doing a malloc() prior
>>> to the first time it accesses Thread::current(), and it gets delivered a
>>> signal, it might die.  This is especially likely for pure native threads
>>> started by native code.
>>>
>>> I believe that this is a use case you support, so you might want to make
>>> sure it is okay.
>>>
>>
>> For a VM embedded in a process, which already contains native threads,
>> that will later attach to the VM, this may indeed be a problem. One
>> would have hoped however that the implementation of TLS would be
>> completely robust, at least for something as simple as getting a signal
>> whilst in the allocator.
>>
>> I'm unclear how to test for or check for this kind of problem. Arguably
>> there could be many things that are async-unsafe in this way.
>>
>> Need to think more about this and do some more research. Would also
>> appreciate any insight from any glibc and/or ELF gurus.
>>
>> Thanks.
>> David
>>
>> Jeremy
>>>
>>> On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson <jeremymanson at google.com
>>> <mailto:jeremymanson at google.com>> wrote:
>>>
>>>     Something that's bitten me with __thread: it isn't async-safe when
>>>     called from a shared object on Linux.  Have you vetted to make sure
>>>     this doesn't make HS less async-safe?
>>>
>>>     Jeremy
>>>
>>>     On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>>>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>         bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>
>>>         Open webrev:
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>>
>>>         A simple (in principle) but wide-ranging change which should
>>>         appeal to our Code Deletion Engineer's. We implement
>>>         Thread::current() using a compiler/language-based thread-local
>>>         variable eg:
>>>
>>>
>>>           static __thread Thread *_thr_current;
>>>
>>>           inline Thread* Thread::current() {
>>>             return _thr_current;
>>>           }
>>>
>>>         with an appropriate setter of course. By doing this we can
>>>         completely remove the platform-specific ThreadLocalStorage
>>>         implementations, and the associated os::thread_local_storage*
>>>         calls, plus all the uses of ThreadLocalStorage::thread() and
>>>         ThreadLocalStorage::get_thread_slow(). This extends the previous
>>>         work done on Solaris to implement ThreadLocalStorage::thread()
>>>         using compiler-based thread-locals.
>>>
>>>         We can also consolidate nearly all the os_cpu versions of
>>>         MacroAssembler::get_thread on x86 into one cpu specific one ( a
>>>         special variant is still needed for 32-bit Windows).
>>>
>>>         As a result of this change we have further potential cleanups:
>>>         - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>>>         completely empty and could also be removed
>>>         - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>>>         sp-map "cache" on 32-bit) now has no affect and so could be
>>>         completely removed from the build system
>>>
>>>         I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR,
>>>         but could add the removal of the "inline" files to this CR if
>>>         people think it worth removing them.
>>>
>>>         I have one missing piece on Aarch64 - I need to change
>>>         MacroAssembler::get_thread to simply call Thread::current() as
>>>         on other platforms, but I don't know how to write that. I would
>>>         appreciate it if someone could give me the right code for that.
>>>
>>>         I would also appreciate comments/testing by the AIX and PPC64
>>>         folk as well.
>>>
>>>         A concern about memory-leaks had previously been raised, but
>>>         experiments using simple C code on linux 86 and Solaris showed
>>>         no issues. Also note that Aarch64 already uses this kind of
>>>         thread-local.
>>>
>>>         Thanks,
>>>         David
>>>
>>>
>>>
>>>

From david.holmes at oracle.com  Fri Nov  6 07:18:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 17:18:00 +1000
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
In-Reply-To: <563B813E.5010506@oracle.com>
References: <563B813E.5010506@oracle.com>
Message-ID: <563C5428.5030300@oracle.com>

Looks okay to me.

Where do you propose to push this? Please submit via JPRT.

Thanks.

David

On 6/11/2015 2:18 AM, Magnus Ihse Bursie wrote:
> Currently the /WX flag is hardcoded in the Hotspot windows make files.
> This makes it impossible to turn of warnings-as-errors for Windows
> without explicitely hacking the makefiles. This should be fixed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8141548-hotspot-windows-build-should-respect-warnings-as-errors/webrev.01
>
>
> /Magnus

From david.holmes at oracle.com  Fri Nov  6 07:23:42 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 17:23:42 +1000
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <563B64EF.1000500@oracle.com>
References: <563B64EF.1000500@oracle.com>
Message-ID: <563C557E.3060505@oracle.com>

Hi Fred,

Before I look at the code, what is the status of the "Open Issues" 
referenced in the JEP?

Also the JDK changes need to be reviewed on core-libs-dev and in 
particular must be seen by the jsr166 maintainers (ie Doug Lea and 
Martin Buchholz)

Thanks,
David

On 6/11/2015 12:17 AM, Frederic Parain wrote:
> Please review the changesets for JEP 270: Reserved Stack Areas for
> Critical Sections
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8046936
>
> Webrevs:
>    hotspot: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
>    JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
>
> The CR contains a detailed description of the issue and the design
> of the solution as well as implementation details.
>
> Tests:
>
>      JPRT - hotspot & core
>      RBT - vm.quick
>
> Thanks
>
> Fred
>

From david.holmes at oracle.com  Fri Nov  6 07:36:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 17:36:49 +1000
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
In-Reply-To: <563C5428.5030300@oracle.com>
References: <563B813E.5010506@oracle.com> <563C5428.5030300@oracle.com>
Message-ID: <563C5891.2070401@oracle.com>

Just realized as per other RFR hotspot uses WARNINGS_ARE_ERRORS not AS

David

On 6/11/2015 5:18 PM, David Holmes wrote:
> Looks okay to me.
>
> Where do you propose to push this? Please submit via JPRT.
>
> Thanks.
>
> David
>
> On 6/11/2015 2:18 AM, Magnus Ihse Bursie wrote:
>> Currently the /WX flag is hardcoded in the Hotspot windows make files.
>> This makes it impossible to turn of warnings-as-errors for Windows
>> without explicitely hacking the makefiles. This should be fixed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8141548-hotspot-windows-build-should-respect-warnings-as-errors/webrev.01
>>
>>
>>
>> /Magnus

From david.holmes at oracle.com  Fri Nov  6 07:48:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 17:48:43 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
Message-ID: <563C5B5B.9060802@oracle.com>

On 6/11/2015 4:55 PM, Jeremy Manson wrote:
> FWIW, Google tried to convince the glibc maintainers to make this
> async-safe, but they weren't biting:
>
> https://sourceware.org/ml/libc-alpha/2014-01/msg00033.html

Yes I read all that. I wouldn't say they weren't biting, more of a 
disagreement on the right direction for the patch. glibc weren't 
prepared to take it directly as is, while google-folk didn't seem to 
think it worth their while to do whatever glibc folk wanted. The actual 
patch proposal just died out. :( Quite a pity.

> Most of the things you can do are going to be mitigation rather than a
> fix.  I did what you suggest to mitigate, and no one complained, until
> someone at Google started a sidecar C++ thread that did a boatload of
> malloc'ing.

Yes all mitigation. :(

> My workaround was far sneakier, and fixes the problem entirely, but you
> probably won't want to do it for code hygiene reasons.  I declare the
> __thread variable in the java launcher itself, and then export a
> function that provides a pointer to it.  In practice, in glibc, if it is
> in the main executable, ELF is smart enough to declare it as part of the
> stack, and is therefore async-safe.

But even that only works for our own launchers - not for embedded in the 
JVM. :(

> Fortunately, while this is a fun thing to think about, I don't think
> there are any async paths in the JVM that use Thread::current()
> (although I could be wrong - there is a comment in there saying not to
> call Thread::current() in a signal handler...).  I would check the call
> paths in AsyncGetCallTrace to make sure.

So two things ...

First, using Thread::current() in a signal context was disallowed, but 
the alternative was ThreadLocalStorage::get_thread_slow(). The former 
may not work in a signal context due to the caching mechanisms layered 
in on different platforms, while the latter used the platform TLS API 
which, even if not guaranteed, worked well enough in a signal context. 
With __thread we don't have even a pretend signal-safe alternative :(

Second, AsyncGetCallTrace violates the first rule by using 
JavaThread::current() in an assertion.

Also, the problem may not be limited to something like 
AsyncGetCallTrace. Though agents may get the current thread from the 
JNIEnv rather than invoking some JVM function that results in 
Thread::current() being used, I can't be sure of that.

Anyway more things to mull over on the weekedn. :)

Thanks,
David

> Jeremy
>
> On Thu, Nov 5, 2015 at 10:26 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Jeremy,
>
>     Okay I have read:
>
>     https://sourceware.org/glibc/wiki/TLSandSignals
>
>     and the tree of mail postings referenced therefrom - great reading! :)
>
>     So basic problem: access to __thread variables is not async-signal-safe
>
>     Exacerbator to problem: first attempt to even read a __thread
>     variable can lead to allocation which is the real problem in
>     relation to async-signal-safety
>
>     I mention the exacerbator because pthread_getspecific and
>     pthread_setSpecific are also not async-signal-safe but we already
>     use them. However, pthread_getspecific is in fact (per email threads
>     linked above) effectively async-signal-safe, and further a call to
>     pthread_getspecific never results in a call to pthread_setspecific
>     or an allocation. Hence the pthread functions are almost, if not
>     completely, safe in practice with reasonable uses (ie only read from
>     signal handler). Which explain this code in existing Thread::current()
>
>     #ifdef PARANOID
>        // Signal handler should call ThreadLocalStorage::get_thread_slow()
>        Thread* t = ThreadLocalStorage::get_thread_slow();
>        assert(t != NULL && !t->is_inside_signal_handler(),
>               "Don't use Thread::current() inside signal handler");
>     #endif
>
>     So problem scenario is: use of __thread variable (that belongs to
>     the shared-library) in a signal handler.
>
>     Solution 0: don't do that. Seriously - like any other
>     async-signal-unsafe stuff we should not be using it in real signal
>     handlers. The crash handler is a different matter - we try all sorts
>     there because it might work and you can't die twice.
>
>     Otherwise: narrow the window of exposure.
>
>     1. We ensure we initialize thread_current (even with a dummy value)
>     as early as possible in the thread that loads libjvm. As we have no
>     signal handlers installed at that point that might use the same
>     variable, we can not hit the problem scenario.
>
>     2. We ensure we initialize thread_current in a new thread with all
>     signals blocked. This again avoids the problem scenario.
>
>     3. We initialize thread_current in an attaching thread as soon as
>     possible and we again first block all signals.
>
>     That still leaves the problem of an unattached native thread taking
>     a signal whilst in async-signal-unsafe code, and executing a signal
>     handler which in turns tries to access thread_current for the first
>     time. This signal handler need not be an actual JVM handler, but one
>     attached by other native code eg an agent. I'm not clear in the
>     latter case how reasonable it is for an agent's handler to try and
>     do things from an unattached thread - and we don't claim any JNI
>     interfaces can, or should, be called from a signal handler - but it
>     is something you can probably get away with today.
>
>     Let me also point out that we already effectively have this code in
>     Solaris already (at the ThreadLocalStorage class level). So if there
>     is something here that will prevent the current proposal we already
>     have a problem on Solaris. :(
>
>     Thoughts/comments/suggestions?
>
>     Thanks,
>     David
>
>
>     On 6/11/2015 1:09 PM, David Holmes wrote:
>
>         Hi Jeremy,
>
>         I was going to ask you to elaborate :)
>
>         On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>
>             I should probably elaborate on this.  With glibc + ELF, the
>             first time a
>             thread accesses a variable declared __thread, if that
>             variable is in a
>             shared library (as opposed to the main executable), the
>             system calls
>             malloc() to allocate the space for it.  If that happens in a
>             signal that
>             is being delivered during a call to malloc(), then you
>             usually get a
>             crash.
>
>
>         My understanding of the ELF ABI for thread-locals - which I read
>         about
>         in the Solaris 11.1 Linkers and libraries guide - does require
>         use of
>         the dynamic TLS model for any dynamically loaded shared object which
>         defines a thread-local, but that is what we use as I understand
>         it. The
>         docs state:
>
>         "A shared object containing only dynamic TLS can be loaded following
>         process startup without limitations. The runtime linker extends
>         the list
>         of initialization records to include the initialization template
>         of the
>         new object. The new object is given an index of m = M + 1. The
>         counter M is incremented by 1. However, the allocation of new
>         TLS blocks
>         is deferred until the blocks are actually referenced."
>
>         Now I guess "extends the list" might be implemented using malloc
>         ... but
>         this will only occur in the main thread (the one started by the
>         launcher
>         to load the JVM and become the main thread), at the time libjvm is
>         loaded - which will all be over before any agent etc can run and do
>         anything. But "allocation ... is deferred" suggests we may have a
>         problem until either the first call to Thread::current or the
>         call to
>         Thread::initialize_thread_current. If it is the former then that
>         should
>         occur well before any agent etc can be loaded. And I can easily
>         inject
>         an initial dummy call to initialize_thread_current(null) to
>         force the
>         TLS allocation.
>
>             This may bite you if AsyncGetCallTrace uses
>             Thread::current(), and you
>             use system timers to do profiling.  If a thread doing a
>             malloc() prior
>             to the first time it accesses Thread::current(), and it gets
>             delivered a
>             signal, it might die.  This is especially likely for pure
>             native threads
>             started by native code.
>
>             I believe that this is a use case you support, so you might
>             want to make
>             sure it is okay.
>
>
>         For a VM embedded in a process, which already contains native
>         threads,
>         that will later attach to the VM, this may indeed be a problem. One
>         would have hoped however that the implementation of TLS would be
>         completely robust, at least for something as simple as getting a
>         signal
>         whilst in the allocator.
>
>         I'm unclear how to test for or check for this kind of problem.
>         Arguably
>         there could be many things that are async-unsafe in this way.
>
>         Need to think more about this and do some more research. Would also
>         appreciate any insight from any glibc and/or ELF gurus.
>
>         Thanks.
>         David
>
>             Jeremy
>
>             On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>             <jeremymanson at google.com <mailto:jeremymanson at google.com>
>             <mailto:jeremymanson at google.com
>             <mailto:jeremymanson at google.com>>> wrote:
>
>                  Something that's bitten me with __thread: it isn't
>             async-safe when
>                  called from a shared object on Linux.  Have you vetted
>             to make sure
>                  this doesn't make HS less async-safe?
>
>                  Jeremy
>
>                  On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>                  <david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>
>             <mailto:david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>>> wrote:
>
>                      bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                      Open webrev:
>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>                      A simple (in principle) but wide-ranging change
>             which should
>                      appeal to our Code Deletion Engineer's. We implement
>                      Thread::current() using a compiler/language-based
>             thread-local
>                      variable eg:
>
>
>                        static __thread Thread *_thr_current;
>
>                        inline Thread* Thread::current() {
>                          return _thr_current;
>                        }
>
>                      with an appropriate setter of course. By doing this
>             we can
>                      completely remove the platform-specific
>             ThreadLocalStorage
>                      implementations, and the associated
>             os::thread_local_storage*
>                      calls, plus all the uses of
>             ThreadLocalStorage::thread() and
>                      ThreadLocalStorage::get_thread_slow(). This extends
>             the previous
>                      work done on Solaris to implement
>             ThreadLocalStorage::thread()
>                      using compiler-based thread-locals.
>
>                      We can also consolidate nearly all the os_cpu
>             versions of
>                      MacroAssembler::get_thread on x86 into one cpu
>             specific one ( a
>                      special variant is still needed for 32-bit Windows).
>
>                      As a result of this change we have further
>             potential cleanups:
>                      - all the src/os/<os>/vm/thread_<os>.inline.hpp
>             files are now
>                      completely empty and could also be removed
>                      - the MINIMIZE_RAM_USAGE define (which avoids use
>             of the linux
>                      sp-map "cache" on 32-bit) now has no affect and so
>             could be
>                      completely removed from the build system
>
>                      I plan to do the MINIMIZE_RAM_USAGE removal as a
>             follow up CR,
>                      but could add the removal of the "inline" files to
>             this CR if
>                      people think it worth removing them.
>
>                      I have one missing piece on Aarch64 - I need to change
>                      MacroAssembler::get_thread to simply call
>             Thread::current() as
>                      on other platforms, but I don't know how to write
>             that. I would
>                      appreciate it if someone could give me the right
>             code for that.
>
>                      I would also appreciate comments/testing by the AIX
>             and PPC64
>                      folk as well.
>
>                      A concern about memory-leaks had previously been
>             raised, but
>                      experiments using simple C code on linux 86 and
>             Solaris showed
>                      no issues. Also note that Aarch64 already uses this
>             kind of
>                      thread-local.
>
>                      Thanks,
>                      David
>
>
>
>

From jborgers at jpinpoint.com  Fri Nov  6 08:58:00 2015
From: jborgers at jpinpoint.com (Jeroen Borgers)
Date: Fri, 6 Nov 2015 09:58:00 +0100
Subject: jdk 9 performance optimizations
In-Reply-To: <8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
Message-ID: <CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>

Hi Christian,

Thanks for the clarification, I over-simplified. Can you please shed some
light on my questions? How can jigsaw help with AOT, inlining lambda's?
I did my jug talk already yesterday, yet, I am curious.
Thanks!

Jeroen

2015-11-05 21:27 GMT+01:00 Christian Thalinger <
christian.thalinger at oracle.com>:

>
> > On Nov 3, 2015, at 12:26 PM, Jeroen Borgers <jborgers at jpinpoint.com>
> wrote:
> >
> > I posted in jigsaw-dev list before:
> >
> > I found this interesting presentation "Java goes AOT" from JVM Language
> > Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
> >
> > As presented by Christiaan Thalinger from HS compiler team, AOT is used
> > with Graal to reduce startup time and quicker peakperformance (tiered).
> > Currently they don't do any inlining in AOT yet
>
> That?s not accurate; we do inlining but very limited.
>
> > because compilation time
> > blows up by inlining everything since no profiling information is
> available
> > yet. I guess modules and knowing dependencies can help here to reduce
> this.
> > Besides test running to generate profiling data.
> >
> > Regards, Jeroen
> > Bijlagen
> > Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
> > JVMLS 2015 - Java Goes AOT
> > Vitaly Davidovich
> > 13:09 (10 uur geleden)
> > aan Jeroen, jigsaw-dev
> >
> > Yes, I had seen Chris' presentation as well.  Certainly modularization
> will
> > help AOT in many ways.  But, I'm particularly interested on the JIT side.
> > What was meant by aggressive lambda inlining, for example? Can anyone
> point
> > at some additional info?
> >
> > Thanks
> >
> > sent from my phone
> > Paul Sandoz <paul.sandoz at oracle.com>
> > 13:32 (9 uur geleden)
> > aan jigsaw-dev
> > Hi Vitaly,
> >
> > Probably worth sending an email to the hotspot-dev at openjdk.java.net
> <mailto:
> > hotspot-dev at openjdk.java.net>
> >
> >> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> >>
> >> Yes, I had seen Chris' presentation as well.  Certainly modularization
> > will
> >> help AOT in many ways.  But, I'm particularly interested on the JIT
> side.
> >> What was meant by aggressive lambda inlining, for example? Can anyone
> > point
> >> at some additional info?
> >>
> >
> > I presume it in part might relate to cracking open the lambda ?box?
> > implementing the targeted functional interface to obtain the underlying
> > method containing the lambda body, generated by javac, that the box
> defers
> > to, then subsituting the indy call to an invocation of that underlying
> > method. Cue lots of hand waving?
> >
> > Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at
> > JVMLS 2014:
> >
> >  http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
> > http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
> > --------
> >
> > Thanks,
> >
> > Jeroen
> >
> > 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
> >
> >> Hi,
> >>
> >> One of the goals of Jigsaw that intrigue me, I read here:
> http://openjdk.
> >> java
> >>
> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
> >> is:
> >> *Enable ahead-of-time, whole-program optimization techniques*  -
> >> [..]
> >> The optimization techniques envisioned here include, but are not limited
> >> to: Fast lookup of both JDK and application classes; early bytecode
> >> verification; aggressive inlining of, *e.g.*, lambda expressions, and
> >> other standard compiler optimizations; construction of JVM-specific
> memory
> >> images that can be loaded more efficiently than class files;
> ahead-of-time
> >> compilation of method bodies to native code; and the removal of unused
> >> fields, methods, and classes. These kinds of techniques tend to work
> best
> >> when JDK and application code is analyzed together, prior to run time.
> >> [..]
> >>
> >>   -
> >>
> >>   *Optimize existing code as-is* ? It must be possible to apply the
> >>   optimizer tool to existing code already packaged in traditional jar
> files,
> >>   without changing those files.
> >>   -
> >>
> >>   *Actual optimizations* ? As a proof of concept, provide at least two
> >>   optimizations that deliver nontrivial performance benefits.
> >>
> >> I am curious about the following:
> >> * What is the current state of this? Which techniques/optimizations are
> >> already implemented and available from the current ea JDK9 or will be?
> >> * Are there any new insights/developments in this area?
> >> * I noticed in my JMH microbenchmark with parallel stream and lambda's
> >> that it runs slightly faster on 9_b85 compared to 8_u66. Could this be
> >> caused by more aggressive inlining of lambda's?
> >> * It seems to me that some compilation and optimization work is moved
> from
> >> runtime to link time /AOT time, yet, we don't have profiling information
> >> there, so this will be limited, right? Are there obvious cases which
> work
> >> well?
> >> * I don't really see why aggressive inlining and std optimizations can
> now
> >> be more effective. Because there will be less de-optimization events
> needed
> >> because of better predictability? Can in-lining now take place in two
> ways,
> >> between platform modules and application? Through interfaces?
> >>
> >> Thanks!
> >> Jeroen
> >>
> >>
> >>
>
>

From sgehwolf at redhat.com  Fri Nov  6 09:48:21 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Nov 2015 10:48:21 +0100
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <563C036A.3050008@oracle.com>
References: <563C036A.3050008@oracle.com>
Message-ID: <1446803301.3479.2.camel@redhat.com>

Hi Coleen,

On Thu, 2015-11-05 at 20:33 -0500, Coleen Phillimore wrote:
> With the RedHat compiler that I'm using g++ (GCC) 4.8.2 20140120 (Red
> Hat 4.8.2-16)
> these additional includes are needed to compile without precompiled
> headers.

Reproduced on Zero fastdebug/slowdebug builds. Zero release builds
didn't have that problem. Just an FYI.

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

With the above patch the build problem on fastdebug/slowdebug without
precompiled headers goes away. Thanks for fixing it!

+1

Cheers,
Severin

> I'm not sure why allocation.inline.hpp is needed unless the virtual 
> destructor in src/share/vm/gc/shared/plab.hpp PLABStats implicitly
> calls 
> delete.
> 
> Tested with compiles of Zero plus plain linux
> debug/fastdebug/product.
> 
> Thanks,
> Coleen


From aph at redhat.com  Fri Nov  6 09:53:12 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 6 Nov 2015 09:53:12 +0000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563BDE37.4070207@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<563B2D5B.30706@redhat.com> <563B7D4A.9030401@redhat.com>
	<563BDE37.4070207@oracle.com>
Message-ID: <563C7888.8000700@redhat.com>

On 05/11/15 22:54, David Holmes wrote:
> Not sure why you had to inject the helper rather than just "call" 
> Thread::current()

Because Thread::current() might clobber vector state.  It's perfectly
well allowed to.

Andrew.


From david.holmes at oracle.com  Fri Nov  6 10:09:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 20:09:25 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C7888.8000700@redhat.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<563B2D5B.30706@redhat.com> <563B7D4A.9030401@redhat.com>
	<563BDE37.4070207@oracle.com> <563C7888.8000700@redhat.com>
Message-ID: <563C7C55.1050105@oracle.com>

On 6/11/2015 7:53 PM, Andrew Haley wrote:
> On 05/11/15 22:54, David Holmes wrote:
>> Not sure why you had to inject the helper rather than just "call"
>> Thread::current()
>
> Because Thread::current() might clobber vector state.  It's perfectly
> well allowed to.

Sorry I really don't understand. If Thread::current can clobber state 
then your helper will have to preserve it. So why can't the caller of 
the helper do the same preservation and skip the need for a helper??

David

> Andrew.
>

From magnus.ihse.bursie at oracle.com  Fri Nov  6 10:49:33 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Nov 2015 11:49:33 +0100
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
In-Reply-To: <563C5891.2070401@oracle.com>
References: <563B813E.5010506@oracle.com> <563C5428.5030300@oracle.com>
	<563C5891.2070401@oracle.com>
Message-ID: <563C85BD.2000103@oracle.com>

On 2015-11-06 08:36, David Holmes wrote:
> Just realized as per other RFR hotspot uses WARNINGS_ARE_ERRORS not AS
Yes and no. That value is only used in the unix make files, not in the 
Windows nmake. In there, there have been no support for disabling 
warnings as errors at all.

I actually started out trying to use a similar construct but nmake is 
horribly limited and I couldn't figure out a way to skip error 
processing by setting the value to empty and pass that along, the way it 
works for the unix make files. :-(

So instead this fix reads the value build-infra value, as set in 
spec.gmk. If the spec file is not present, then neither is this 
variable, and the behavior will be the same as without the fix (i.e. all 
warnings are errors). I don't intend to mess around any more with the 
old nmake files. If this is not acceptable, I'll drop it until the new 
hotspot build is done.

/Magnus


From aph at redhat.com  Fri Nov  6 10:57:30 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 6 Nov 2015 10:57:30 +0000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C7C55.1050105@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<563B2D5B.30706@redhat.com> <563B7D4A.9030401@redhat.com>
	<563BDE37.4070207@oracle.com> <563C7888.8000700@redhat.com>
	<563C7C55.1050105@oracle.com>
Message-ID: <563C879A.3060902@redhat.com>

On 06/11/15 10:09, David Holmes wrote:
> On 6/11/2015 7:53 PM, Andrew Haley wrote:
>> On 05/11/15 22:54, David Holmes wrote:
>>> Not sure why you had to inject the helper rather than just "call"
>>> Thread::current()
>>
>> Because Thread::current() might clobber vector state.  It's perfectly
>> well allowed to.
> 
> Sorry I really don't understand. If Thread::current can clobber state 
> then your helper will have to preserve it. So why can't the caller of 
> the helper do the same preservation and skip the need for a helper??

My helper is written in assembly language.  It is not written in C.
It does not call Thread::current().  It accesses the _thread variable
directly.  It does not clobber vector state.

Andrew.


From david.holmes at oracle.com  Fri Nov  6 11:20:13 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2015 21:20:13 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C879A.3060902@redhat.com>
References: <56370567.3090801@oracle.com>
	<CAA-vtUw2rgPA4EfEKUDbB390_q0P-uh9=GK-Hv1GGDffbBgZRg@mail.gmail.com>
	<5637C100.8040405@oracle.com>
	<CAA-vtUyKJpQZq70e5qi-bqj+XOd9-8cOknv1tQZ4Jn_JcAUFmw@mail.gmail.com>
	<563984D0.8030501@oracle.com>
	<CAA-vtUwdgBB-vkNFv2cB8C-AJCDT-H_LVWUoksnK+-+8wG2sdg@mail.gmail.com>
	<5639CF38.5060800@oracle.com> <563ADCD0.1070800@oracle.com>
	<563B2D5B.30706@redhat.com> <563B7D4A.9030401@redhat.com>
	<563BDE37.4070207@oracle.com> <563C7888.8000700@redhat.com>
	<563C7C55.1050105@oracle.com> <563C879A.3060902@redhat.com>
Message-ID: <563C8CED.40400@oracle.com>

On 6/11/2015 8:57 PM, Andrew Haley wrote:
> On 06/11/15 10:09, David Holmes wrote:
>> On 6/11/2015 7:53 PM, Andrew Haley wrote:
>>> On 05/11/15 22:54, David Holmes wrote:
>>>> Not sure why you had to inject the helper rather than just "call"
>>>> Thread::current()
>>>
>>> Because Thread::current() might clobber vector state.  It's perfectly
>>> well allowed to.
>>
>> Sorry I really don't understand. If Thread::current can clobber state
>> then your helper will have to preserve it. So why can't the caller of
>> the helper do the same preservation and skip the need for a helper??
>
> My helper is written in assembly language.  It is not written in C.
> It does not call Thread::current().  It accesses the _thread variable
> directly.  It does not clobber vector state.

Doh! Sorry.

David

> Andrew.
>

From goetz.lindenmaier at sap.com  Fri Nov  6 11:38:49 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Nov 2015 11:38:49 +0000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>

Hi Christian, 

thanks for doing this change.  It looks good.

It's good that now notproduct flags are also defined in the product build as constants, 
as it's already the case with debug flags.
This allows more cleanups in the style you did to compilerDirectives.hpp.

I had a look at these cleanups, quite a row you can find in this patch:
http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch

Does it make sense to commit these along with your change?

Best regards,
  Goetz.



> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Christian Thalinger
> Sent: Freitag, 6. November 2015 07:23
> To: hotspot-dev at openjdk.java.net
> Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
> variables with CONST_ in product builds
> 
> https://bugs.openjdk.java.net/browse/JDK-8140424
> <https://bugs.openjdk.java.net/browse/JDK-8140424>
> http://cr.openjdk.java.net/~twisti/8140424/webrev/
> <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
> 
> When working on JDK-8024545 I added code that prefixes developer and
> notproduct flags with CONST_. I think I did this to be able to access the
> address of these variables for the flag table. But this is not necessary because
> these flag cannot be written anyway.
> 
> I am proposing to remove the CONST_ prefix and define the variables as
> const.

From thomas.stuefe at gmail.com  Fri Nov  6 11:52:54 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 6 Nov 2015 12:52:54 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C4824.7040300@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
Message-ID: <CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>

Hi David,

On Fri, Nov 6, 2015 at 7:26 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Jeremy,
>
> Okay I have read:
>
> https://sourceware.org/glibc/wiki/TLSandSignals
>
> and the tree of mail postings referenced therefrom - great reading! :)
>
> So basic problem: access to __thread variables is not async-signal-safe
>
> Exacerbator to problem: first attempt to even read a __thread variable can
> lead to allocation which is the real problem in relation to
> async-signal-safety
>
> I mention the exacerbator because pthread_getspecific and
> pthread_setSpecific are also not async-signal-safe but we already use them.
> However, pthread_getspecific is in fact (per email threads linked above)
> effectively async-signal-safe, and further a call to pthread_getspecific
> never results in a call to pthread_setspecific or an allocation. Hence the
> pthread functions are almost, if not completely, safe in practice with
> reasonable uses (ie only read from signal handler). Which explain this code
> in existing Thread::current()
>
> #ifdef PARANOID
>   // Signal handler should call ThreadLocalStorage::get_thread_slow()
>   Thread* t = ThreadLocalStorage::get_thread_slow();
>   assert(t != NULL && !t->is_inside_signal_handler(),
>          "Don't use Thread::current() inside signal handler");
> #endif
>
> So problem scenario is: use of __thread variable (that belongs to the
> shared-library) in a signal handler.
>
> Solution 0: don't do that. Seriously - like any other async-signal-unsafe
> stuff we should not be using it in real signal handlers. The crash handler
> is a different matter - we try all sorts there because it might work and
> you can't die twice.
>
> Otherwise: narrow the window of exposure.
>
> 1. We ensure we initialize thread_current (even with a dummy value) as
> early as possible in the thread that loads libjvm. As we have no signal
> handlers installed at that point that might use the same variable, we can
> not hit the problem scenario.
>
> 2. We ensure we initialize thread_current in a new thread with all signals
> blocked. This again avoids the problem scenario.
>
> 3. We initialize thread_current in an attaching thread as soon as possible
> and we again first block all signals.
>
> That still leaves the problem of an unattached native thread taking a
> signal whilst in async-signal-unsafe code, and executing a signal handler
> which in turns tries to access thread_current for the first time. This
> signal handler need not be an actual JVM handler, but one attached by other
> native code eg an agent. I'm not clear in the latter case how reasonable it
> is for an agent's handler to try and do things from an unattached thread -
> and we don't claim any JNI interfaces can, or should, be called from a
> signal handler - but it is something you can probably get away with today.
>
> Let me also point out that we already effectively have this code in
> Solaris already (at the ThreadLocalStorage class level). So if there is
> something here that will prevent the current proposal we already have a
> problem on Solaris. :(
>
> Thoughts/comments/suggestions?
>
>
The first problem: thread initializes TLS variable, gets interrupted and
accesses the half-initialized variable from within the signal handler. This
could happen today too, or? but I think we never saw this.

In theory, it could be mitigated by some careful testing before using the
Thread::current() value in the signal handler. Like, put an eyecatcher at
the beginning of the Thread structure and check that using SafeFetch.

As for the second problem - recursive malloc() deadlocks - I am at a loss.
I do not fully understand though why pthread_getspecific is different -
does it not have to allocate place for the TLS variable too?

Regards, Thomas



> Thanks,
> David
>
>
> On 6/11/2015 1:09 PM, David Holmes wrote:
>
>> Hi Jeremy,
>>
>> I was going to ask you to elaborate :)
>>
>> On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>>
>>> I should probably elaborate on this.  With glibc + ELF, the first time a
>>> thread accesses a variable declared __thread, if that variable is in a
>>> shared library (as opposed to the main executable), the system calls
>>> malloc() to allocate the space for it.  If that happens in a signal that
>>> is being delivered during a call to malloc(), then you usually get a
>>> crash.
>>>
>>
>> My understanding of the ELF ABI for thread-locals - which I read about
>> in the Solaris 11.1 Linkers and libraries guide - does require use of
>> the dynamic TLS model for any dynamically loaded shared object which
>> defines a thread-local, but that is what we use as I understand it. The
>> docs state:
>>
>> "A shared object containing only dynamic TLS can be loaded following
>> process startup without limitations. The runtime linker extends the list
>> of initialization records to include the initialization template of the
>> new object. The new object is given an index of m = M + 1. The
>> counter M is incremented by 1. However, the allocation of new TLS blocks
>> is deferred until the blocks are actually referenced."
>>
>> Now I guess "extends the list" might be implemented using malloc ... but
>> this will only occur in the main thread (the one started by the launcher
>> to load the JVM and become the main thread), at the time libjvm is
>> loaded - which will all be over before any agent etc can run and do
>> anything. But "allocation ... is deferred" suggests we may have a
>> problem until either the first call to Thread::current or the call to
>> Thread::initialize_thread_current. If it is the former then that should
>> occur well before any agent etc can be loaded. And I can easily inject
>> an initial dummy call to initialize_thread_current(null) to force the
>> TLS allocation.
>>
>> This may bite you if AsyncGetCallTrace uses Thread::current(), and you
>>> use system timers to do profiling.  If a thread doing a malloc() prior
>>> to the first time it accesses Thread::current(), and it gets delivered a
>>> signal, it might die.  This is especially likely for pure native threads
>>> started by native code.
>>>
>>> I believe that this is a use case you support, so you might want to make
>>> sure it is okay.
>>>
>>
>> For a VM embedded in a process, which already contains native threads,
>> that will later attach to the VM, this may indeed be a problem. One
>> would have hoped however that the implementation of TLS would be
>> completely robust, at least for something as simple as getting a signal
>> whilst in the allocator.
>>
>> I'm unclear how to test for or check for this kind of problem. Arguably
>> there could be many things that are async-unsafe in this way.
>>
>> Need to think more about this and do some more research. Would also
>> appreciate any insight from any glibc and/or ELF gurus.
>>
>> Thanks.
>> David
>>
>> Jeremy
>>>
>>> On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson <jeremymanson at google.com
>>> <mailto:jeremymanson at google.com>> wrote:
>>>
>>>     Something that's bitten me with __thread: it isn't async-safe when
>>>     called from a shared object on Linux.  Have you vetted to make sure
>>>     this doesn't make HS less async-safe?
>>>
>>>     Jeremy
>>>
>>>     On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>>>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>         bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>
>>>         Open webrev:
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>>
>>>         A simple (in principle) but wide-ranging change which should
>>>         appeal to our Code Deletion Engineer's. We implement
>>>         Thread::current() using a compiler/language-based thread-local
>>>         variable eg:
>>>
>>>
>>>           static __thread Thread *_thr_current;
>>>
>>>           inline Thread* Thread::current() {
>>>             return _thr_current;
>>>           }
>>>
>>>         with an appropriate setter of course. By doing this we can
>>>         completely remove the platform-specific ThreadLocalStorage
>>>         implementations, and the associated os::thread_local_storage*
>>>         calls, plus all the uses of ThreadLocalStorage::thread() and
>>>         ThreadLocalStorage::get_thread_slow(). This extends the previous
>>>         work done on Solaris to implement ThreadLocalStorage::thread()
>>>         using compiler-based thread-locals.
>>>
>>>         We can also consolidate nearly all the os_cpu versions of
>>>         MacroAssembler::get_thread on x86 into one cpu specific one ( a
>>>         special variant is still needed for 32-bit Windows).
>>>
>>>         As a result of this change we have further potential cleanups:
>>>         - all the src/os/<os>/vm/thread_<os>.inline.hpp files are now
>>>         completely empty and could also be removed
>>>         - the MINIMIZE_RAM_USAGE define (which avoids use of the linux
>>>         sp-map "cache" on 32-bit) now has no affect and so could be
>>>         completely removed from the build system
>>>
>>>         I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR,
>>>         but could add the removal of the "inline" files to this CR if
>>>         people think it worth removing them.
>>>
>>>         I have one missing piece on Aarch64 - I need to change
>>>         MacroAssembler::get_thread to simply call Thread::current() as
>>>         on other platforms, but I don't know how to write that. I would
>>>         appreciate it if someone could give me the right code for that.
>>>
>>>         I would also appreciate comments/testing by the AIX and PPC64
>>>         folk as well.
>>>
>>>         A concern about memory-leaks had previously been raised, but
>>>         experiments using simple C code on linux 86 and Solaris showed
>>>         no issues. Also note that Aarch64 already uses this kind of
>>>         thread-local.
>>>
>>>         Thanks,
>>>         David
>>>
>>>
>>>
>>>

From magnus.ihse.bursie at oracle.com  Fri Nov  6 12:07:05 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Nov 2015 13:07:05 +0100
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
In-Reply-To: <563C5428.5030300@oracle.com>
References: <563B813E.5010506@oracle.com> <563C5428.5030300@oracle.com>
Message-ID: <563C97E9.5020007@oracle.com>

On 2015-11-06 08:18, David Holmes wrote:
> Looks okay to me.
>
> Where do you propose to push this? Please submit via JPRT.
I was planning to use hs-rt, but I have no opinion on that, really.

/Magnus

>
> Thanks.
>
> David
>
> On 6/11/2015 2:18 AM, Magnus Ihse Bursie wrote:
>> Currently the /WX flag is hardcoded in the Hotspot windows make files.
>> This makes it impossible to turn of warnings-as-errors for Windows
>> without explicitely hacking the makefiles. This should be fixed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8141548-hotspot-windows-build-should-respect-warnings-as-errors/webrev.01 
>>
>>
>>
>> /Magnus


From harold.seigel at oracle.com  Fri Nov  6 12:41:34 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 6 Nov 2015 07:41:34 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <563C036A.3050008@oracle.com>
References: <563C036A.3050008@oracle.com>
Message-ID: <563C9FFE.8070201@oracle.com>

Looks good.

Harold

On 11/5/2015 8:33 PM, Coleen Phillimore wrote:
> With the RedHat compiler that I'm using g++ (GCC) 4.8.2 20140120 (Red 
> Hat 4.8.2-16)
> these additional includes are needed to compile without precompiled 
> headers.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.01/
> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>
> I'm not sure why allocation.inline.hpp is needed unless the virtual 
> destructor in src/share/vm/gc/shared/plab.hpp PLABStats implicitly 
> calls delete.
>
> Tested with compiles of Zero plus plain linux debug/fastdebug/product.
>
> Thanks,
> Coleen


From vladimir.x.ivanov at oracle.com  Fri Nov  6 13:03:47 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 6 Nov 2015 16:03:47 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563BD90F.7010609@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com>
Message-ID: <563CA533.601@oracle.com>

Thanks, Coleen!

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.02/

> I think DependencyContext is big enough to be a new file, and not be
> added to instanceKlass.hpp.  There are too many unrelated things in
> instanceKlass.
Agree. Moved it to src/share/vm/code/dependencyContext.[ch]pp

> The hidden bit stuff is ok in InstanceKlass.  Does
> has_unloaded_dependent accessed concurrently like
> _is_marked_dependent?
Good point. DependencyContext::remove_dependent_nmethod should set 
has_stale_entries in a thread safe manner (added Atomic::xchg_ptr call).
It is not needed when the flag is cleared.

> It would be nice to move _is_marked_dependent
> field also to encapsulate it but that would ruin your bit packing.
There's a spare bit to use, but I think _is_marked_dependent is specific 
to InstanceKlass and should remain there. It doesn't have any meaning 
for CallSite dependencies.

> Also, since you have changes to vmStructs, do you have duplicate changes
> to make to the serviceability agent code?  Are there duplicate changes
> for the jvmci code?
I haven't found any mentions of _has_unloaded_dependent or _dependencies 
fields in SA or JVMCI code. Do you think it is an overlook on SA side 
and I should add it?

Best regards,
Vladimir Ivanov

>
> Thanks,
> Coleen
>
> On 11/5/15 1:54 PM, Vladimir Ivanov wrote:
>> Updated version:
>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/
>>
>> In addition to name polishing and encapsulating purging logic in
>> {add|remove}_dependent_nmethod methods, I got rid of
>> DependencyContext::wipe() method and added "friend class
>> TestDependencyContext" declaration (noticed such practice in other
>> cases when tests need access to tested class internals).
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
>>> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>>>> Regarding internal purging, add_dependent_methods doesn't iterate over
>>>> the whole list, but looks for the relevant entry. It means that "purge"
>>>> flag should force full iteration. I think that keeping them separately
>>>> (add_dependent_methods() vs purge()) looks cleaner.
>>>
>>> I think it is better to encapsulate the "piggybacking" behavior within
>>> the DependencyContext itself, because that seems to be a
>>> general/expected feature of DependencyContext class. It is weird to ask
>>> class users to spell it out specifically.
>>>
>>>
>>>> I could add "purge" flag and move the following code into
>>>> add_dependent_methods:
>>>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool
>>>> do_purge
>>>> = false) {
>>>>     ...
>>>>     if (has_unloaded_dependent() && do_purge) {
>>>>       purge();
>>>>     }
>>>> }
>>>>
>>>> Is it what you are suggesting?
>>>
>>> Yes.
>>>
>>>
>>>>>    * DependencyContext now has three methods: purge(), clear(),
>>>>> wipe(). I
>>>>> have trouble understanding which method does what!
>>>
>>>> There are basically 2 operations needed:
>>>>    * purge(): only remove stale entries; no additional work is
>>>> performed;
>>>
>>> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>>>   WeakHashMap.expungeStaleEntries()
>>>   ThreadLocal.expungeStaleEntries()
>>>   WeakCache.expungeStaleEntries()
>>>
>>>
>>>> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
>>>> just deallocates all nmethodBucket entries without touching
>>>> nmethods. It
>>>> is necessary since nmethod pointers are faked by the test.
>>>
>>> Okay. Is there a convention how you should name the test-related methods
>>> like these? I would expect something like debug_deallocate_buckets().
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>
>

From frederic.parain at oracle.com  Fri Nov  6 15:36:46 2015
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 6 Nov 2015 16:36:46 +0100
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <563C557E.3060505@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
Message-ID: <563CC90E.2080707@oracle.com>

Hi David,

The two "Open Issues" discussed in the JEP are:
   - Windows support
   - Reserved Stack Area sizing.

Regarding the Windows support, the full feature cannot be
implemented before JDK-8067946 is fixed. I've tried to fix the
Yellow Pages issues on Windows, but all my attempts have failed,
Windows ignoring or overriding my pages management instructions.
If a Windows expert fixes JDK-8067946, we can consider implementing
the full feature on Windows. Even if the Reserved Stack Area
mechanism is not implemented on Windows, the detection of stack
overflow in annotated code sections is supported, which improves
the current situation by making the problem easier to diagnose.

Regarding the sizing, determining the stack space required to
execute a sequence of bytecodes is an incredibly complex task,
due to the number of parameters to consider and the combinatorial
explosion of all the possible combinations. I used an empirical
approach to set the default size of the reserved area with respect
to the code sections currently annotated. I've also implemented
troubleshooting features to detect when stack overflows occur in
annotated sections, which can help determining cases where the
reserved area size is not sufficient.

Regarding the review of the JDK side of the fix, of course it
requires review from jsr166 maintainers. The feature only adds
annotations and doesn't change algorithms or APIs. Note that the
current changesets aim to fix the issue only for ReentrantLocks
but the pattern making the code brittle in case of stack overflow
exists in many other classes of the java.util.concurrent packages.
I'll let core-libs or jsr166 developers decide if more sections
need to be annotated.

Regards,

Fred

On 06/11/2015 08:23, David Holmes wrote:
> Hi Fred,
>
> Before I look at the code, what is the status of the "Open Issues"
> referenced in the JEP?
>
> Also the JDK changes need to be reviewed on core-libs-dev and in
> particular must be seen by the jsr166 maintainers (ie Doug Lea and
> Martin Buchholz)
>
> Thanks,
> David
>
> On 6/11/2015 12:17 AM, Frederic Parain wrote:
>> Please review the changesets for JEP 270: Reserved Stack Areas for
>> Critical Sections
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8046936
>>
>> Webrevs:
>>    hotspot:
>> http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
>>    JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
>>
>> The CR contains a detailed description of the issue and the design
>> of the solution as well as implementation details.
>>
>> Tests:
>>
>>      JPRT - hotspot & core
>>      RBT - vm.quick
>>
>> Thanks
>>
>> Fred
>>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From gerard.ziemski at oracle.com  Fri Nov  6 15:58:45 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 6 Nov 2015 09:58:45 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
Message-ID: <563CCE35.3000102@oracle.com>


hi all,

Please review this final fix for JEP-245

We implement the remaining runtime flags in the Shared* family.

Summary of changes:

#1 core fix - we factor out the constants to be used in the ranges

src/share/vm/classfile/compactHashtable.cpp
src/share/vm/memory/metaspace.cpp
src/share/vm/memory/metaspaceShared.hpp
src/share/vm/runtime/globals.hpp


#2 we increase default sizes of range and constraint tables to minimize mallocs

src/share/vm/runtime/commandLineFlagConstraintList.cpp
src/share/vm/runtime/commandLineFlagRangeList.cpp


#3 we fix a bug that I run into the OptionsValidation test framework while working

test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java


#4 we add functionality to OptionsValidation test framework that we later use

test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java


#5 we cleanup and extend the existing test to detect a case where we get out of range value

test/runtime/SharedArchiveFile/LimitSharedSizes.java


The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot" tests

References:

     bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
  open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0


hg_stat:

  src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
  src/share/vm/memory/metaspace.cpp                                                        |   30 --
  src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
  src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
  src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
  src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
  test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
  9 files changed, 242 insertions(+), 141 deletions(-)





From jaroslav.bachorik at oracle.com  Fri Nov  6 16:11:39 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 6 Nov 2015 17:11:39 +0100
Subject: RFR 8141526: Allow to collect stdout/stderr from the
	FinalizationRunner even before the process returns
Message-ID: <563CD13B.8040800@oracle.com>

[wider audience included]

Please, review the following test change

Issue : https://bugs.openjdk.java.net/browse/JDK-8141526
Webrev:
top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00
hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot
jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk

After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we 
are not able to get the debug info about the run of the launcher 
FinalizationRunner application in case it gets stuck and harness times 
out. This is because the stdout/err of the application started via 
ProcessTools.executeProcess() is collected only after the application 
has exited.

The solution is to use ProcessTools.startProcess() and consume the 
application stdout/err in a streaming mode. Because this method has only 
been available in the 'jdk' version of ProcessTools and not in the 
'hotspot' one I decided to merge both of those versions and place the 
merged version into the shared location 'test/lib/share/classes/'. 
During this I decided to change the package for the shared ProcessTools 
class to be 'jdk.test.lib.process' to be more in line with the way this 
shared library is structured. I had to move few other lib classes 
required by ProcessTools to the shared lib as well. All the moved lib 
classes have been marked as deprecated in their original location.


Thanks,

-JB-


From kim.barrett at oracle.com  Fri Nov  6 16:47:48 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Nov 2015 11:47:48 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <563C036A.3050008@oracle.com>
References: <563C036A.3050008@oracle.com>
Message-ID: <7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>

On Nov 5, 2015, at 8:33 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> With the RedHat compiler that I'm using g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16)
> these additional includes are needed to compile without precompiled headers.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.01/
> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
> 
> I'm not sure why allocation.inline.hpp is needed unless the virtual destructor in src/share/vm/gc/shared/plab.hpp PLABStats implicitly calls delete.
> 
> Tested with compiles of Zero plus plain linux debug/fastdebug/product.
> 
> Thanks,
> Coleen

src/share/vm/gc/g1/g1EvacStats.hpp
  29 #include "memory/allocation.inline.hpp"
  30 #include "runtime/atomic.inline.hpp"

xxx.inline.hpp files are not supposed to be included by xxx.hpp files.

The need for atomic.inline.hpp seems clear, and would seem to constitute a bug in
g1EvacStats.hpp - there should be a g1EvacStats.inline.hpp file.

I really don?t understand why allocation.inline.hpp is needed here at all.

And I?m really curious as to why these changes are needed for (some variants of)
zero builds but not other builds with disabled precompiled headers?

Without further explanation, I don?t like these changes.


From christian.thalinger at oracle.com  Fri Nov  6 17:13:21 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 6 Nov 2015 07:13:21 -1000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
Message-ID: <811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>


> On Nov 6, 2015, at 1:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Christian, 
> 
> thanks for doing this change.  It looks good.
> 
> It's good that now notproduct flags are also defined in the product build as constants, 
> as it's already the case with debug flags.
> This allows more cleanups in the style you did to compilerDirectives.hpp.
> 
> I had a look at these cleanups, quite a row you can find in this patch:
> http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch <http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch>

That is a very nice cleanup.

> 
> Does it make sense to commit these along with your change?

It does.  I?ve updated my webrev with your changes:

http://cr.openjdk.java.net/~twisti/8140424/webrev/

> 
> Best regards,
>  Goetz.
> 
> 
> 
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Christian Thalinger
>> Sent: Freitag, 6. November 2015 07:23
>> To: hotspot-dev at openjdk.java.net
>> Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
>> variables with CONST_ in product builds
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8140424
>> <https://bugs.openjdk.java.net/browse/JDK-8140424>
>> http://cr.openjdk.java.net/~twisti/8140424/webrev/
>> <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
>> 
>> When working on JDK-8024545 I added code that prefixes developer and
>> notproduct flags with CONST_. I think I did this to be able to access the
>> address of these variables for the flag table. But this is not necessary because
>> these flag cannot be written anyway.
>> 
>> I am proposing to remove the CONST_ prefix and define the variables as
>> const.


From dmitry.dmitriev at oracle.com  Fri Nov  6 20:36:44 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 6 Nov 2015 23:36:44 +0300
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563CCE35.3000102@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com>
Message-ID: <563D0F5C.5070503@oracle.com>

Hi Gerard,

Thank you for fixing bug in the framework.
Overall looks good to me, just few comments:
1) src/share/vm/runtime/globals.hpp

Line 536: typo - "metspace"

2) src/share/vm/memory/metaspace.cpp

Deleted code calls 'align_size_up' on lines 3247, 3252 to align minimal 
value for SharedMiscDataSize and SharedMiscCodeSize, but now low range 
for these flags is not aligned. Is it okay?

3) JVMOptionsUtils.java

Line 40: can you please put "import java.math.BigDecimal;" between 
"import java.io.Reader;" and "import java.util.ArrayList;"
Line 70: bad indentation
Lines 101, 104, 107: can you please add space between ";" and "//".

4) LimitSharedSizes.java

Lines 63-69(SharedSizeTestData constructor): can you please correct 
indentation to the 4 spaces.

Thank you,
Dmitry

On 06.11.2015 18:58, gerard ziemski wrote:
>
> hi all,
>
> Please review this final fix for JEP-245
>
> We implement the remaining runtime flags in the Shared* family.
>
> Summary of changes:
>
> #1 core fix - we factor out the constants to be used in the ranges
>
> src/share/vm/classfile/compactHashtable.cpp
> src/share/vm/memory/metaspace.cpp
> src/share/vm/memory/metaspaceShared.hpp
> src/share/vm/runtime/globals.hpp
>
>
> #2 we increase default sizes of range and constraint tables to 
> minimize mallocs
>
> src/share/vm/runtime/commandLineFlagConstraintList.cpp
> src/share/vm/runtime/commandLineFlagRangeList.cpp
>
>
> #3 we fix a bug that I run into the OptionsValidation test framework 
> while working
>
> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 
>
>
>
> #4 we add functionality to OptionsValidation test framework that we 
> later use
>
> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 
>
>
>
> #5 we cleanup and extend the existing test to detect a case where we 
> get out of range value
>
> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>
>
> The fix passes RBT 
> "hotspot/test/:hotspot_all,testlist,noncolo.testlist 
> --add-tonga-keyword quick? and JPRT ?hotspot" tests
>
> References:
>
>     bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>  open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>
>
> hg_stat:
>
>  src/share/vm/classfile/compactHashtable.cpp |    2 +-
>  src/share/vm/memory/metaspace.cpp |   30 --
>  src/share/vm/memory/metaspaceShared.hpp |   19 +-
>  src/share/vm/runtime/commandLineFlagConstraintList.cpp |    2 +-
>  src/share/vm/runtime/commandLineFlagRangeList.cpp |    2 +-
>  src/share/vm/runtime/globals.hpp |   63 +++++-
>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 
> |    4 +-
>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 
> |   81 +++++++
>  test/runtime/SharedArchiveFile/LimitSharedSizes.java |  180 
> +++++++++-------
>  9 files changed, 242 insertions(+), 141 deletions(-)
>
>
>
>


From gerard.ziemski at oracle.com  Fri Nov  6 21:23:19 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 6 Nov 2015 15:23:19 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563D0F5C.5070503@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D0F5C.5070503@oracle.com>
Message-ID: <563D1A47.5090904@oracle.com>

Thank you for the review!

On 11/06/2015 02:36 PM, Dmitry Dmitriev wrote:
> Hi Gerard,
>
> Thank you for fixing bug in the framework.
> Overall looks good to me, just few comments:
> 1) src/share/vm/runtime/globals.hpp
>
> Line 536: typo - "metspace"

Fixed.


> 2) src/share/vm/memory/metaspace.cpp
>
> Deleted code calls 'align_size_up' on lines 3247, 3252 to align minimal value for SharedMiscDataSize and
> SharedMiscCodeSize, but now low range for these flags is not aligned. Is it okay?

The range function compares the min with the value before any alignment takes place, so we're good (we're not mixing 
comparison of aligned vs unaligned values here), but good question.


> 3) JVMOptionsUtils.java
>
> Line 40: can you please put "import java.math.BigDecimal;" between "import java.io.Reader;" and "import
> java.util.ArrayList;"
> Line 70: bad indentation
> Lines 101, 104, 107: can you please add space between ";" and "//".

Fixed.


> 4) LimitSharedSizes.java
>
> Lines 63-69(SharedSizeTestData constructor): can you please correct indentation to the 4 spaces.

Fixed.

I will post rev1 up shortly.


cheers

>
> Thank you,
> Dmitry
>
> On 06.11.2015 18:58, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this final fix for JEP-245
>>
>> We implement the remaining runtime flags in the Shared* family.
>>
>> Summary of changes:
>>
>> #1 core fix - we factor out the constants to be used in the ranges
>>
>> src/share/vm/classfile/compactHashtable.cpp
>> src/share/vm/memory/metaspace.cpp
>> src/share/vm/memory/metaspaceShared.hpp
>> src/share/vm/runtime/globals.hpp
>>
>>
>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>
>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>
>>
>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>
>>
>> #4 we add functionality to OptionsValidation test framework that we later use
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>
>>
>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>
>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>
>>
>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>> tests
>>
>> References:
>>
>>     bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>  open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>
>>
>> hg_stat:
>>
>>  src/share/vm/classfile/compactHashtable.cpp |    2 +-
>>  src/share/vm/memory/metaspace.cpp |   30 --
>>  src/share/vm/memory/metaspaceShared.hpp |   19 +-
>>  src/share/vm/runtime/commandLineFlagConstraintList.cpp |    2 +-
>>  src/share/vm/runtime/commandLineFlagRangeList.cpp |    2 +-
>>  src/share/vm/runtime/globals.hpp |   63 +++++-
>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java |    4 +-
>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>  test/runtime/SharedArchiveFile/LimitSharedSizes.java |  180 +++++++++-------
>>  9 files changed, 242 insertions(+), 141 deletions(-)
>>
>>
>>
>>
>
>

From gerard.ziemski at oracle.com  Fri Nov  6 21:33:11 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 6 Nov 2015 15:33:11 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563CCE35.3000102@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com>
Message-ID: <563D1C97.4010702@oracle.com>

hi all,

I have updated the fix with rev1, incorporating feedback from Dmitry:

- Fix comments and indentation
- Add "-XShare:dump" while testing Shared* flags
- Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is 
allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650

http://cr.openjdk.java.net/~gziemski/8138983_rev1



cheers



On 11/06/2015 09:58 AM, gerard ziemski wrote:
>
> hi all,
>
> Please review this final fix for JEP-245
>
> We implement the remaining runtime flags in the Shared* family.
>
> Summary of changes:
>
> #1 core fix - we factor out the constants to be used in the ranges
>
> src/share/vm/classfile/compactHashtable.cpp
> src/share/vm/memory/metaspace.cpp
> src/share/vm/memory/metaspaceShared.hpp
> src/share/vm/runtime/globals.hpp
>
>
> #2 we increase default sizes of range and constraint tables to minimize mallocs
>
> src/share/vm/runtime/commandLineFlagConstraintList.cpp
> src/share/vm/runtime/commandLineFlagRangeList.cpp
>
>
> #3 we fix a bug that I run into the OptionsValidation test framework while working
>
> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>
>
> #4 we add functionality to OptionsValidation test framework that we later use
>
> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>
>
> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>
> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>
>
> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot" tests
>
> References:
>
>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>
>
> hg_stat:
>
>   src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>   src/share/vm/memory/metaspace.cpp                                                        |   30 --
>   src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>   src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>   src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>   src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>   test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>   9 files changed, 242 insertions(+), 141 deletions(-)

From dmitry.dmitriev at oracle.com  Fri Nov  6 21:41:43 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Sat, 7 Nov 2015 00:41:43 +0300
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563D1C97.4010702@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
Message-ID: <563D1E97.9040305@oracle.com>

Gerard,

Looks good to me!

Dmitry

On 07.11.2015 0:33, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating feedback from Dmitry:
>
> - Fix comments and indentation
> - Add "-XShare:dump" while testing Shared* flags
> - Temporarily disable testing of SharedMiscDataSize as with current 
> min default it exits the VM with code 2 (which is allowed by the JEP, 
> but not the test framework). This issue is tracked by JDK-8141650
>
> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>
>
>
> cheers
>
>
>
> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this final fix for JEP-245
>>
>> We implement the remaining runtime flags in the Shared* family.
>>
>> Summary of changes:
>>
>> #1 core fix - we factor out the constants to be used in the ranges
>>
>> src/share/vm/classfile/compactHashtable.cpp
>> src/share/vm/memory/metaspace.cpp
>> src/share/vm/memory/metaspaceShared.hpp
>> src/share/vm/runtime/globals.hpp
>>
>>
>> #2 we increase default sizes of range and constraint tables to 
>> minimize mallocs
>>
>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>
>>
>> #3 we fix a bug that I run into the OptionsValidation test framework 
>> while working
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 
>>
>>
>>
>> #4 we add functionality to OptionsValidation test framework that we 
>> later use
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 
>>
>>
>>
>> #5 we cleanup and extend the existing test to detect a case where we 
>> get out of range value
>>
>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>
>>
>> The fix passes RBT 
>> "hotspot/test/:hotspot_all,testlist,noncolo.testlist 
>> --add-tonga-keyword quick? and JPRT ?hotspot" tests
>>
>> References:
>>
>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>
>>
>> hg_stat:
>>
>> src/share/vm/classfile/compactHashtable.cpp |    2 +-
>> src/share/vm/memory/metaspace.cpp |   30 --
>> src/share/vm/memory/metaspaceShared.hpp |   19 +-
>> src/share/vm/runtime/commandLineFlagConstraintList.cpp |    2 +-
>> src/share/vm/runtime/commandLineFlagRangeList.cpp |    2 +-
>> src/share/vm/runtime/globals.hpp |   63 +++++-
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 
>> |    4 +-
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 
>> |   81 +++++++
>> test/runtime/SharedArchiveFile/LimitSharedSizes.java |  180 
>> +++++++++-------
>>   9 files changed, 242 insertions(+), 141 deletions(-)


From kim.barrett at oracle.com  Fri Nov  6 22:09:52 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Nov 2015 17:09:52 -0500
Subject: RFR: 8077571: ObjPtrQueue is poorly named
Message-ID: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>

[Sending to hotspot-dev because this touches runtime and compiler
files too. I'm particularly looking for a compiler person for the
change to HotSpotVMConfig.java.]

Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
cleanup is being done in preparation for some further changes that
will make the name more widely used.

Probably the satbQueue.[ch]pp files should be renamed to
satbMarkQueue.[ch]pp.  I've not made such a change because my
understanding is that mercurial mq doesn't really understand file
renames.

CR:
https://bugs.openjdk.java.net/browse/JDK-8077571

Webrev:
http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/

Testing:
JPRT


From david.holmes at oracle.com  Fri Nov  6 22:20:40 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 7 Nov 2015 08:20:40 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
Message-ID: <563D27B8.4040501@oracle.com>

On 6/11/2015 9:52 PM, Thomas St?fe wrote:
> Hi David,
>
> On Fri, Nov 6, 2015 at 7:26 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Jeremy,
>
>     Okay I have read:
>
>     https://sourceware.org/glibc/wiki/TLSandSignals
>
>     and the tree of mail postings referenced therefrom - great reading! :)
>
>     So basic problem: access to __thread variables is not async-signal-safe
>
>     Exacerbator to problem: first attempt to even read a __thread
>     variable can lead to allocation which is the real problem in
>     relation to async-signal-safety
>
>     I mention the exacerbator because pthread_getspecific and
>     pthread_setSpecific are also not async-signal-safe but we already
>     use them. However, pthread_getspecific is in fact (per email threads
>     linked above) effectively async-signal-safe, and further a call to
>     pthread_getspecific never results in a call to pthread_setspecific
>     or an allocation. Hence the pthread functions are almost, if not
>     completely, safe in practice with reasonable uses (ie only read from
>     signal handler). Which explain this code in existing Thread::current()
>
>     #ifdef PARANOID
>        // Signal handler should call ThreadLocalStorage::get_thread_slow()
>        Thread* t = ThreadLocalStorage::get_thread_slow();
>        assert(t != NULL && !t->is_inside_signal_handler(),
>               "Don't use Thread::current() inside signal handler");
>     #endif
>
>     So problem scenario is: use of __thread variable (that belongs to
>     the shared-library) in a signal handler.
>
>     Solution 0: don't do that. Seriously - like any other
>     async-signal-unsafe stuff we should not be using it in real signal
>     handlers. The crash handler is a different matter - we try all sorts
>     there because it might work and you can't die twice.
>
>     Otherwise: narrow the window of exposure.
>
>     1. We ensure we initialize thread_current (even with a dummy value)
>     as early as possible in the thread that loads libjvm. As we have no
>     signal handlers installed at that point that might use the same
>     variable, we can not hit the problem scenario.
>
>     2. We ensure we initialize thread_current in a new thread with all
>     signals blocked. This again avoids the problem scenario.
>
>     3. We initialize thread_current in an attaching thread as soon as
>     possible and we again first block all signals.
>
>     That still leaves the problem of an unattached native thread taking
>     a signal whilst in async-signal-unsafe code, and executing a signal
>     handler which in turns tries to access thread_current for the first
>     time. This signal handler need not be an actual JVM handler, but one
>     attached by other native code eg an agent. I'm not clear in the
>     latter case how reasonable it is for an agent's handler to try and
>     do things from an unattached thread - and we don't claim any JNI
>     interfaces can, or should, be called from a signal handler - but it
>     is something you can probably get away with today.
>
>     Let me also point out that we already effectively have this code in
>     Solaris already (at the ThreadLocalStorage class level). So if there
>     is something here that will prevent the current proposal we already
>     have a problem on Solaris. :(
>
>     Thoughts/comments/suggestions?
>
>
> The first problem: thread initializes TLS variable, gets interrupted and
> accesses the half-initialized variable from within the signal handler.
> This could happen today too, or? but I think we never saw this.

That depends on the state of signal masks at the time of the 
initialization. For threads created in the VM and for threads attached 
to the VM it is likely not an issue. Unattached threads could in theory 
try to access a TLS variable from a signal handler, but they will never 
be initializing that variable. Of course the unattached thread could be 
initializing a completely distinct TLS variable, but reading a different 
TLS variable from the signal handler does not seem to be an issue (in 
theory it may be but this is an extreme corner case).

> In theory, it could be mitigated by some careful testing before using
> the Thread::current() value in the signal handler. Like, put an
> eyecatcher at the beginning of the Thread structure and check that using
> SafeFetch.

There is no way to access the Thread structure before calling 
Thread::current(). And the potential problem is with unattached threads 
which have no Thread structure. For threads attached to the VM, or 
attaching, my three steps will deal with any potential problems.

> As for the second problem - recursive malloc() deadlocks - I am at a
> loss. I do not fully understand though why pthread_getspecific is
> different - does it not have to allocate place for the TLS variable too?

No, pthread_getspecific does not have to allocate. Presumably it is 
written in a way that attempting to index a TLS variable that has not 
been allocated just returns an error (EINVAL?). The problem with 
__thread is that even a read will attempt to do the allocation - 
arguably (as the Google folk did argue) this is wrong, or else should be 
done in an async-safe way.

This does leave me wondering exactly what affect the:

static __thread Thread* _thr_current = NULL;

has in terms of any per-thread allocation. ??

Anyway to reiterate the problem scenario:
- VM has been loaded in a process and signal handlers have been 
installed (maybe VM, maybe agent)
- unattached thread is doing a malloc when it takes a signal
- signal handler tries to read __thread variable and we get a malloc 
deadlock

As I said I need to determine what signal handlers in the VM might ever 
run on an unattached thread, and what they might do. For a "third-party" 
signal handler there's really nothing I can do - they should not be 
accessing the VM's __thread variables though (and they cal always 
introduce their own independent deadlocks by performing non-async-safe 
actions).

Thanks,
David

> Regards, Thomas
>
>
>     Thanks,
>     David
>
>
>     On 6/11/2015 1:09 PM, David Holmes wrote:
>
>         Hi Jeremy,
>
>         I was going to ask you to elaborate :)
>
>         On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>
>             I should probably elaborate on this.  With glibc + ELF, the
>             first time a
>             thread accesses a variable declared __thread, if that
>             variable is in a
>             shared library (as opposed to the main executable), the
>             system calls
>             malloc() to allocate the space for it.  If that happens in a
>             signal that
>             is being delivered during a call to malloc(), then you
>             usually get a
>             crash.
>
>
>         My understanding of the ELF ABI for thread-locals - which I read
>         about
>         in the Solaris 11.1 Linkers and libraries guide - does require
>         use of
>         the dynamic TLS model for any dynamically loaded shared object which
>         defines a thread-local, but that is what we use as I understand
>         it. The
>         docs state:
>
>         "A shared object containing only dynamic TLS can be loaded following
>         process startup without limitations. The runtime linker extends
>         the list
>         of initialization records to include the initialization template
>         of the
>         new object. The new object is given an index of m = M + 1. The
>         counter M is incremented by 1. However, the allocation of new
>         TLS blocks
>         is deferred until the blocks are actually referenced."
>
>         Now I guess "extends the list" might be implemented using malloc
>         ... but
>         this will only occur in the main thread (the one started by the
>         launcher
>         to load the JVM and become the main thread), at the time libjvm is
>         loaded - which will all be over before any agent etc can run and do
>         anything. But "allocation ... is deferred" suggests we may have a
>         problem until either the first call to Thread::current or the
>         call to
>         Thread::initialize_thread_current. If it is the former then that
>         should
>         occur well before any agent etc can be loaded. And I can easily
>         inject
>         an initial dummy call to initialize_thread_current(null) to
>         force the
>         TLS allocation.
>
>             This may bite you if AsyncGetCallTrace uses
>             Thread::current(), and you
>             use system timers to do profiling.  If a thread doing a
>             malloc() prior
>             to the first time it accesses Thread::current(), and it gets
>             delivered a
>             signal, it might die.  This is especially likely for pure
>             native threads
>             started by native code.
>
>             I believe that this is a use case you support, so you might
>             want to make
>             sure it is okay.
>
>
>         For a VM embedded in a process, which already contains native
>         threads,
>         that will later attach to the VM, this may indeed be a problem. One
>         would have hoped however that the implementation of TLS would be
>         completely robust, at least for something as simple as getting a
>         signal
>         whilst in the allocator.
>
>         I'm unclear how to test for or check for this kind of problem.
>         Arguably
>         there could be many things that are async-unsafe in this way.
>
>         Need to think more about this and do some more research. Would also
>         appreciate any insight from any glibc and/or ELF gurus.
>
>         Thanks.
>         David
>
>             Jeremy
>
>             On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>             <jeremymanson at google.com <mailto:jeremymanson at google.com>
>             <mailto:jeremymanson at google.com
>             <mailto:jeremymanson at google.com>>> wrote:
>
>                  Something that's bitten me with __thread: it isn't
>             async-safe when
>                  called from a shared object on Linux.  Have you vetted
>             to make sure
>                  this doesn't make HS less async-safe?
>
>                  Jeremy
>
>                  On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>                  <david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>
>             <mailto:david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>>> wrote:
>
>                      bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                      Open webrev:
>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>                      A simple (in principle) but wide-ranging change
>             which should
>                      appeal to our Code Deletion Engineer's. We implement
>                      Thread::current() using a compiler/language-based
>             thread-local
>                      variable eg:
>
>
>                        static __thread Thread *_thr_current;
>
>                        inline Thread* Thread::current() {
>                          return _thr_current;
>                        }
>
>                      with an appropriate setter of course. By doing this
>             we can
>                      completely remove the platform-specific
>             ThreadLocalStorage
>                      implementations, and the associated
>             os::thread_local_storage*
>                      calls, plus all the uses of
>             ThreadLocalStorage::thread() and
>                      ThreadLocalStorage::get_thread_slow(). This extends
>             the previous
>                      work done on Solaris to implement
>             ThreadLocalStorage::thread()
>                      using compiler-based thread-locals.
>
>                      We can also consolidate nearly all the os_cpu
>             versions of
>                      MacroAssembler::get_thread on x86 into one cpu
>             specific one ( a
>                      special variant is still needed for 32-bit Windows).
>
>                      As a result of this change we have further
>             potential cleanups:
>                      - all the src/os/<os>/vm/thread_<os>.inline.hpp
>             files are now
>                      completely empty and could also be removed
>                      - the MINIMIZE_RAM_USAGE define (which avoids use
>             of the linux
>                      sp-map "cache" on 32-bit) now has no affect and so
>             could be
>                      completely removed from the build system
>
>                      I plan to do the MINIMIZE_RAM_USAGE removal as a
>             follow up CR,
>                      but could add the removal of the "inline" files to
>             this CR if
>                      people think it worth removing them.
>
>                      I have one missing piece on Aarch64 - I need to change
>                      MacroAssembler::get_thread to simply call
>             Thread::current() as
>                      on other platforms, but I don't know how to write
>             that. I would
>                      appreciate it if someone could give me the right
>             code for that.
>
>                      I would also appreciate comments/testing by the AIX
>             and PPC64
>                      folk as well.
>
>                      A concern about memory-leaks had previously been
>             raised, but
>                      experiments using simple C code on linux 86 and
>             Solaris showed
>                      no issues. Also note that Aarch64 already uses this
>             kind of
>                      thread-local.
>
>                      Thanks,
>                      David
>
>
>
>

From christian.thalinger at oracle.com  Fri Nov  6 22:21:38 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 6 Nov 2015 12:21:38 -1000
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
Message-ID: <5E8086F9-871B-4C4F-B766-75EF1CB17D2B@oracle.com>


> On Nov 6, 2015, at 12:09 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> [Sending to hotspot-dev because this touches runtime and compiler
> files too. I'm particularly looking for a compiler person for the
> change to HotSpotVMConfig.java.]

Yes, that change looks good.

> 
> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
> cleanup is being done in preparation for some further changes that
> will make the name more widely used.
> 
> Probably the satbQueue.[ch]pp files should be renamed to
> satbMarkQueue.[ch]pp.  I've not made such a change because my
> understanding is that mercurial mq doesn't really understand file
> renames.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8077571
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
> 
> Testing:
> JPRT
> 


From jeremymanson at google.com  Sat Nov  7 01:22:24 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 6 Nov 2015 17:22:24 -0800
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563C5B5B.9060802@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
	<563C5B5B.9060802@oracle.com>
Message-ID: <CAPYFHW3OJ2rUMrHFY4CiCPpVMfhZ=TSMrBwDsxX9kgnMLnL00w@mail.gmail.com>

On Thu, Nov 5, 2015 at 11:48 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 6/11/2015 4:55 PM, Jeremy Manson wrote:
>
>> FWIW, Google tried to convince the glibc maintainers to make this
>> async-safe, but they weren't biting:
>>
>> https://sourceware.org/ml/libc-alpha/2014-01/msg00033.html
>>
>
> Yes I read all that. I wouldn't say they weren't biting, more of a
> disagreement on the right direction for the patch. glibc weren't prepared
> to take it directly as is, while google-folk didn't seem to think it worth
> their while to do whatever glibc folk wanted. The actual patch proposal
> just died out. :( Quite a pity.
>
> Most of the things you can do are going to be mitigation rather than a
>> fix.  I did what you suggest to mitigate, and no one complained, until
>> someone at Google started a sidecar C++ thread that did a boatload of
>> malloc'ing.
>>
>
> Yes all mitigation. :(
>
> My workaround was far sneakier, and fixes the problem entirely, but you
>> probably won't want to do it for code hygiene reasons.  I declare the
>> __thread variable in the java launcher itself, and then export a
>> function that provides a pointer to it.  In practice, in glibc, if it is
>> in the main executable, ELF is smart enough to declare it as part of the
>> stack, and is therefore async-safe.
>>
>
> But even that only works for our own launchers - not for embedded in the
> JVM. :(


Yup.  Fortunately, I can tell people at Google how to write launchers.


> Fortunately, while this is a fun thing to think about, I don't think
>> there are any async paths in the JVM that use Thread::current()
>> (although I could be wrong - there is a comment in there saying not to
>> call Thread::current() in a signal handler...).  I would check the call
>> paths in AsyncGetCallTrace to make sure.
>>
>
> So two things ...
>
> First, using Thread::current() in a signal context was disallowed, but the
> alternative was ThreadLocalStorage::get_thread_slow(). The former may not
> work in a signal context due to the caching mechanisms layered in on
> different platforms, while the latter used the platform TLS API which, even
> if not guaranteed, worked well enough in a signal context. With __thread we
> don't have even a pretend signal-safe alternative :(
>

Right.


> Second, AsyncGetCallTrace violates the first rule by using
> JavaThread::current() in an assertion.
>

While we're on the subject, the assertion in Method::bci_from is reachable
from AsyncGetCallTrace and calls err_msg, which can malloc().  I meant to
file a bug about that.

Also, the problem may not be limited to something like AsyncGetCallTrace.
> Though agents may get the current thread from the JNIEnv rather than
> invoking some JVM function that results in Thread::current() being used, I
> can't be sure of that.
>

Which JVM functions that get the thread are supposed to be async-safe?
There is no reason to think that any method that isn't explicitly marked
async-safe is async safe, and most JNI methods I've tried to use from
signal handlers die painfully if I try to use them from a signal handler.

Generally, I don't think it is reasonable for a user to expect async-safety
from an API that isn't expressly designed that way.  POSIX has a list of
async-safe methods (signal(7)).

FWIW, to use AsyncGetCallTrace, I get the JNIEnv in a ThreadStart hook from
JVMTI and stash it in a __thread (and pull the trick I mentioned).

Jeremy


> Anyway more things to mull over on the weekedn. :)
>
> Thanks,
> David
>
> Jeremy
>>
>> On Thu, Nov 5, 2015 at 10:26 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Jeremy,
>>
>>     Okay I have read:
>>
>>     https://sourceware.org/glibc/wiki/TLSandSignals
>>
>>     and the tree of mail postings referenced therefrom - great reading! :)
>>
>>     So basic problem: access to __thread variables is not
>> async-signal-safe
>>
>>     Exacerbator to problem: first attempt to even read a __thread
>>     variable can lead to allocation which is the real problem in
>>     relation to async-signal-safety
>>
>>     I mention the exacerbator because pthread_getspecific and
>>     pthread_setSpecific are also not async-signal-safe but we already
>>     use them. However, pthread_getspecific is in fact (per email threads
>>     linked above) effectively async-signal-safe, and further a call to
>>     pthread_getspecific never results in a call to pthread_setspecific
>>     or an allocation. Hence the pthread functions are almost, if not
>>     completely, safe in practice with reasonable uses (ie only read from
>>     signal handler). Which explain this code in existing Thread::current()
>>
>>     #ifdef PARANOID
>>        // Signal handler should call ThreadLocalStorage::get_thread_slow()
>>        Thread* t = ThreadLocalStorage::get_thread_slow();
>>        assert(t != NULL && !t->is_inside_signal_handler(),
>>               "Don't use Thread::current() inside signal handler");
>>     #endif
>>
>>     So problem scenario is: use of __thread variable (that belongs to
>>     the shared-library) in a signal handler.
>>
>>     Solution 0: don't do that. Seriously - like any other
>>     async-signal-unsafe stuff we should not be using it in real signal
>>     handlers. The crash handler is a different matter - we try all sorts
>>     there because it might work and you can't die twice.
>>
>>     Otherwise: narrow the window of exposure.
>>
>>     1. We ensure we initialize thread_current (even with a dummy value)
>>     as early as possible in the thread that loads libjvm. As we have no
>>     signal handlers installed at that point that might use the same
>>     variable, we can not hit the problem scenario.
>>
>>     2. We ensure we initialize thread_current in a new thread with all
>>     signals blocked. This again avoids the problem scenario.
>>
>>     3. We initialize thread_current in an attaching thread as soon as
>>     possible and we again first block all signals.
>>
>>     That still leaves the problem of an unattached native thread taking
>>     a signal whilst in async-signal-unsafe code, and executing a signal
>>     handler which in turns tries to access thread_current for the first
>>     time. This signal handler need not be an actual JVM handler, but one
>>     attached by other native code eg an agent. I'm not clear in the
>>     latter case how reasonable it is for an agent's handler to try and
>>     do things from an unattached thread - and we don't claim any JNI
>>     interfaces can, or should, be called from a signal handler - but it
>>     is something you can probably get away with today.
>>
>>     Let me also point out that we already effectively have this code in
>>     Solaris already (at the ThreadLocalStorage class level). So if there
>>     is something here that will prevent the current proposal we already
>>     have a problem on Solaris. :(
>>
>>     Thoughts/comments/suggestions?
>>
>>     Thanks,
>>     David
>>
>>
>>     On 6/11/2015 1:09 PM, David Holmes wrote:
>>
>>         Hi Jeremy,
>>
>>         I was going to ask you to elaborate :)
>>
>>         On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>>
>>             I should probably elaborate on this.  With glibc + ELF, the
>>             first time a
>>             thread accesses a variable declared __thread, if that
>>             variable is in a
>>             shared library (as opposed to the main executable), the
>>             system calls
>>             malloc() to allocate the space for it.  If that happens in a
>>             signal that
>>             is being delivered during a call to malloc(), then you
>>             usually get a
>>             crash.
>>
>>
>>         My understanding of the ELF ABI for thread-locals - which I read
>>         about
>>         in the Solaris 11.1 Linkers and libraries guide - does require
>>         use of
>>         the dynamic TLS model for any dynamically loaded shared object
>> which
>>         defines a thread-local, but that is what we use as I understand
>>         it. The
>>         docs state:
>>
>>         "A shared object containing only dynamic TLS can be loaded
>> following
>>         process startup without limitations. The runtime linker extends
>>         the list
>>         of initialization records to include the initialization template
>>         of the
>>         new object. The new object is given an index of m = M + 1. The
>>         counter M is incremented by 1. However, the allocation of new
>>         TLS blocks
>>         is deferred until the blocks are actually referenced."
>>
>>         Now I guess "extends the list" might be implemented using malloc
>>         ... but
>>         this will only occur in the main thread (the one started by the
>>         launcher
>>         to load the JVM and become the main thread), at the time libjvm is
>>         loaded - which will all be over before any agent etc can run and
>> do
>>         anything. But "allocation ... is deferred" suggests we may have a
>>         problem until either the first call to Thread::current or the
>>         call to
>>         Thread::initialize_thread_current. If it is the former then that
>>         should
>>         occur well before any agent etc can be loaded. And I can easily
>>         inject
>>         an initial dummy call to initialize_thread_current(null) to
>>         force the
>>         TLS allocation.
>>
>>             This may bite you if AsyncGetCallTrace uses
>>             Thread::current(), and you
>>             use system timers to do profiling.  If a thread doing a
>>             malloc() prior
>>             to the first time it accesses Thread::current(), and it gets
>>             delivered a
>>             signal, it might die.  This is especially likely for pure
>>             native threads
>>             started by native code.
>>
>>             I believe that this is a use case you support, so you might
>>             want to make
>>             sure it is okay.
>>
>>
>>         For a VM embedded in a process, which already contains native
>>         threads,
>>         that will later attach to the VM, this may indeed be a problem.
>> One
>>         would have hoped however that the implementation of TLS would be
>>         completely robust, at least for something as simple as getting a
>>         signal
>>         whilst in the allocator.
>>
>>         I'm unclear how to test for or check for this kind of problem.
>>         Arguably
>>         there could be many things that are async-unsafe in this way.
>>
>>         Need to think more about this and do some more research. Would
>> also
>>         appreciate any insight from any glibc and/or ELF gurus.
>>
>>         Thanks.
>>         David
>>
>>             Jeremy
>>
>>             On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>>             <jeremymanson at google.com <mailto:jeremymanson at google.com>
>>             <mailto:jeremymanson at google.com
>>             <mailto:jeremymanson at google.com>>> wrote:
>>
>>                  Something that's bitten me with __thread: it isn't
>>             async-safe when
>>                  called from a shared object on Linux.  Have you vetted
>>             to make sure
>>                  this doesn't make HS less async-safe?
>>
>>                  Jeremy
>>
>>                  On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>>                  <david.holmes at oracle.com
>>             <mailto:david.holmes at oracle.com>
>>             <mailto:david.holmes at oracle.com
>>
>>             <mailto:david.holmes at oracle.com>>> wrote:
>>
>>                      bug:
>> https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                      Open webrev:
>>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>>                      A simple (in principle) but wide-ranging change
>>             which should
>>                      appeal to our Code Deletion Engineer's. We implement
>>                      Thread::current() using a compiler/language-based
>>             thread-local
>>                      variable eg:
>>
>>
>>                        static __thread Thread *_thr_current;
>>
>>                        inline Thread* Thread::current() {
>>                          return _thr_current;
>>                        }
>>
>>                      with an appropriate setter of course. By doing this
>>             we can
>>                      completely remove the platform-specific
>>             ThreadLocalStorage
>>                      implementations, and the associated
>>             os::thread_local_storage*
>>                      calls, plus all the uses of
>>             ThreadLocalStorage::thread() and
>>                      ThreadLocalStorage::get_thread_slow(). This extends
>>             the previous
>>                      work done on Solaris to implement
>>             ThreadLocalStorage::thread()
>>                      using compiler-based thread-locals.
>>
>>                      We can also consolidate nearly all the os_cpu
>>             versions of
>>                      MacroAssembler::get_thread on x86 into one cpu
>>             specific one ( a
>>                      special variant is still needed for 32-bit Windows).
>>
>>                      As a result of this change we have further
>>             potential cleanups:
>>                      - all the src/os/<os>/vm/thread_<os>.inline.hpp
>>             files are now
>>                      completely empty and could also be removed
>>                      - the MINIMIZE_RAM_USAGE define (which avoids use
>>             of the linux
>>                      sp-map "cache" on 32-bit) now has no affect and so
>>             could be
>>                      completely removed from the build system
>>
>>                      I plan to do the MINIMIZE_RAM_USAGE removal as a
>>             follow up CR,
>>                      but could add the removal of the "inline" files to
>>             this CR if
>>                      people think it worth removing them.
>>
>>                      I have one missing piece on Aarch64 - I need to
>> change
>>                      MacroAssembler::get_thread to simply call
>>             Thread::current() as
>>                      on other platforms, but I don't know how to write
>>             that. I would
>>                      appreciate it if someone could give me the right
>>             code for that.
>>
>>                      I would also appreciate comments/testing by the AIX
>>             and PPC64
>>                      folk as well.
>>
>>                      A concern about memory-leaks had previously been
>>             raised, but
>>                      experiments using simple C code on linux 86 and
>>             Solaris showed
>>                      no issues. Also note that Aarch64 already uses this
>>             kind of
>>                      thread-local.
>>
>>                      Thanks,
>>                      David
>>
>>
>>
>>
>>

From kim.barrett at oracle.com  Sat Nov  7 20:58:34 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 7 Nov 2015 15:58:34 -0500
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <5E8086F9-871B-4C4F-B766-75EF1CB17D2B@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
	<5E8086F9-871B-4C4F-B766-75EF1CB17D2B@oracle.com>
Message-ID: <49E590F6-9253-428A-9BF0-DE168238C21F@oracle.com>

On Nov 6, 2015, at 5:21 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Nov 6, 2015, at 12:09 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> [Sending to hotspot-dev because this touches runtime and compiler
>> files too. I'm particularly looking for a compiler person for the
>> change to HotSpotVMConfig.java.]
> 
> Yes, that change looks good.

Thanks!  I wasn?t getting anywhere trying to figure out what might be impacted by that change.

>> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
>> cleanup is being done in preparation for some further changes that
>> will make the name more widely used.
>> 
>> Probably the satbQueue.[ch]pp files should be renamed to
>> satbMarkQueue.[ch]pp.  I've not made such a change because my
>> understanding is that mercurial mq doesn't really understand file
>> renames.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8077571
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
>> 
>> Testing:
>> JPRT



From bengt.rutisson at oracle.com  Sun Nov  8 12:23:25 2015
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Sun, 8 Nov 2015 13:23:25 +0100
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
Message-ID: <563F3EBD.9070707@oracle.com>


Hi Kim,

On 2015-11-06 23:09, Kim Barrett wrote:
> [Sending to hotspot-dev because this touches runtime and compiler
> files too. I'm particularly looking for a compiler person for the
> change to HotSpotVMConfig.java.]
>
> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
> cleanup is being done in preparation for some further changes that
> will make the name more widely used.
>
> Probably the satbQueue.[ch]pp files should be renamed to
> satbMarkQueue.[ch]pp.  I've not made such a change because my
> understanding is that mercurial mq doesn't really understand file
> renames.

I think you should rename the files too. Mercurial handles the history 
over renames, but you sometimes have to explicitly tell it to follow the 
renames.

You can try this with all the GC files that were renamed as part of the 
directory restructure in May. See for example:

$ hg log  src/share/vm/gc/g1/g1CollectedHeap.cpp  | wc
     381    1434   12851

$ hg log -f src/share/vm/gc/g1/g1CollectedHeap.cpp  | wc
    2611   10085   88115


>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8077571
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/

Except for the renaming of the files I think it looks good. I don't need 
to see an updated webrev for the file rename.

Reviewed.

Bengt

>
> Testing:
> JPRT
>


From david.holmes at oracle.com  Sun Nov  8 22:54:18 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Nov 2015 08:54:18 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAPYFHW3OJ2rUMrHFY4CiCPpVMfhZ=TSMrBwDsxX9kgnMLnL00w@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
	<563C5B5B.9060802@oracle.com>
	<CAPYFHW3OJ2rUMrHFY4CiCPpVMfhZ=TSMrBwDsxX9kgnMLnL00w@mail.gmail.com>
Message-ID: <563FD29A.3060103@oracle.com>

On 7/11/2015 11:22 AM, Jeremy Manson wrote:
>
>
> On Thu, Nov 5, 2015 at 11:48 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 6/11/2015 4:55 PM, Jeremy Manson wrote:
>
>         FWIW, Google tried to convince the glibc maintainers to make this
>         async-safe, but they weren't biting:
>
>         https://sourceware.org/ml/libc-alpha/2014-01/msg00033.html
>
>
>     Yes I read all that. I wouldn't say they weren't biting, more of a
>     disagreement on the right direction for the patch. glibc weren't
>     prepared to take it directly as is, while google-folk didn't seem to
>     think it worth their while to do whatever glibc folk wanted. The
>     actual patch proposal just died out. :( Quite a pity.
>
>         Most of the things you can do are going to be mitigation rather
>         than a
>         fix.  I did what you suggest to mitigate, and no one complained,
>         until
>         someone at Google started a sidecar C++ thread that did a
>         boatload of
>         malloc'ing.
>
>
>     Yes all mitigation. :(
>
>         My workaround was far sneakier, and fixes the problem entirely,
>         but you
>         probably won't want to do it for code hygiene reasons.  I
>         declare the
>         __thread variable in the java launcher itself, and then export a
>         function that provides a pointer to it.  In practice, in glibc,
>         if it is
>         in the main executable, ELF is smart enough to declare it as
>         part of the
>         stack, and is therefore async-safe.
>
>
>     But even that only works for our own launchers - not for embedded in
>     the JVM. :(
>
>
> Yup.  Fortunately, I can tell people at Google how to write launchers.
>
>         Fortunately, while this is a fun thing to think about, I don't think
>         there are any async paths in the JVM that use Thread::current()
>         (although I could be wrong - there is a comment in there saying
>         not to
>         call Thread::current() in a signal handler...).  I would check
>         the call
>         paths in AsyncGetCallTrace to make sure.
>
>
>     So two things ...
>
>     First, using Thread::current() in a signal context was disallowed,
>     but the alternative was ThreadLocalStorage::get_thread_slow(). The
>     former may not work in a signal context due to the caching
>     mechanisms layered in on different platforms, while the latter used
>     the platform TLS API which, even if not guaranteed, worked well
>     enough in a signal context. With __thread we don't have even a
>     pretend signal-safe alternative :(
>
>
> Right.
>
>     Second, AsyncGetCallTrace violates the first rule by using
>     JavaThread::current() in an assertion.
>
>
> While we're on the subject, the assertion in Method::bci_from is
> reachable from AsyncGetCallTrace and calls err_msg, which can malloc().
> I meant to file a bug about that.
>
>     Also, the problem may not be limited to something like
>     AsyncGetCallTrace. Though agents may get the current thread from the
>     JNIEnv rather than invoking some JVM function that results in
>     Thread::current() being used, I can't be sure of that.
>
>
> Which JVM functions that get the thread are supposed to be async-safe?
> There is no reason to think that any method that isn't explicitly marked
> async-safe is async safe, and most JNI methods I've tried to use from
> signal handlers die painfully if I try to use them from a signal handler.
>
> Generally, I don't think it is reasonable for a user to expect
> async-safety from an API that isn't expressly designed that way.  POSIX
> has a list of async-safe methods (signal(7)).

Right - no JNI or JVM TI functions are designated as async-signal-safe 
(the specs dont even mention signals).

Unfortunately my problem is more basic: pretty much the first thing the 
JVM signal handler does is get the current thread. So if the signal is 
handled on an unattached thread that happened to be doing a malloc then 
we're toast. :( Most of the signals the JVM expects to handle are not 
blocked by default, AFAICS, so any unattached thread could be selected.

David
-----


> FWIW, to use AsyncGetCallTrace, I get the JNIEnv in a ThreadStart hook
> from JVMTI and stash it in a __thread (and pull the trick I mentioned).
> Jeremy
>
>
>     Anyway more things to mull over on the weekedn. :)
>
>     Thanks,
>     David
>
>         Jeremy
>
>         On Thu, Nov 5, 2015 at 10:26 PM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              Hi Jeremy,
>
>              Okay I have read:
>
>         https://sourceware.org/glibc/wiki/TLSandSignals
>
>              and the tree of mail postings referenced therefrom - great
>         reading! :)
>
>              So basic problem: access to __thread variables is not
>         async-signal-safe
>
>              Exacerbator to problem: first attempt to even read a __thread
>              variable can lead to allocation which is the real problem in
>              relation to async-signal-safety
>
>              I mention the exacerbator because pthread_getspecific and
>              pthread_setSpecific are also not async-signal-safe but we
>         already
>              use them. However, pthread_getspecific is in fact (per
>         email threads
>              linked above) effectively async-signal-safe, and further a
>         call to
>              pthread_getspecific never results in a call to
>         pthread_setspecific
>              or an allocation. Hence the pthread functions are almost,
>         if not
>              completely, safe in practice with reasonable uses (ie only
>         read from
>              signal handler). Which explain this code in existing
>         Thread::current()
>
>              #ifdef PARANOID
>                 // Signal handler should call
>         ThreadLocalStorage::get_thread_slow()
>                 Thread* t = ThreadLocalStorage::get_thread_slow();
>                 assert(t != NULL && !t->is_inside_signal_handler(),
>                        "Don't use Thread::current() inside signal handler");
>              #endif
>
>              So problem scenario is: use of __thread variable (that
>         belongs to
>              the shared-library) in a signal handler.
>
>              Solution 0: don't do that. Seriously - like any other
>              async-signal-unsafe stuff we should not be using it in real
>         signal
>              handlers. The crash handler is a different matter - we try
>         all sorts
>              there because it might work and you can't die twice.
>
>              Otherwise: narrow the window of exposure.
>
>              1. We ensure we initialize thread_current (even with a
>         dummy value)
>              as early as possible in the thread that loads libjvm. As we
>         have no
>              signal handlers installed at that point that might use the same
>              variable, we can not hit the problem scenario.
>
>              2. We ensure we initialize thread_current in a new thread
>         with all
>              signals blocked. This again avoids the problem scenario.
>
>              3. We initialize thread_current in an attaching thread as
>         soon as
>              possible and we again first block all signals.
>
>              That still leaves the problem of an unattached native
>         thread taking
>              a signal whilst in async-signal-unsafe code, and executing
>         a signal
>              handler which in turns tries to access thread_current for
>         the first
>              time. This signal handler need not be an actual JVM
>         handler, but one
>              attached by other native code eg an agent. I'm not clear in the
>              latter case how reasonable it is for an agent's handler to
>         try and
>              do things from an unattached thread - and we don't claim
>         any JNI
>              interfaces can, or should, be called from a signal handler
>         - but it
>              is something you can probably get away with today.
>
>              Let me also point out that we already effectively have this
>         code in
>              Solaris already (at the ThreadLocalStorage class level). So
>         if there
>              is something here that will prevent the current proposal we
>         already
>              have a problem on Solaris. :(
>
>              Thoughts/comments/suggestions?
>
>              Thanks,
>              David
>
>
>              On 6/11/2015 1:09 PM, David Holmes wrote:
>
>                  Hi Jeremy,
>
>                  I was going to ask you to elaborate :)
>
>                  On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>
>                      I should probably elaborate on this.  With glibc +
>         ELF, the
>                      first time a
>                      thread accesses a variable declared __thread, if that
>                      variable is in a
>                      shared library (as opposed to the main executable), the
>                      system calls
>                      malloc() to allocate the space for it.  If that
>         happens in a
>                      signal that
>                      is being delivered during a call to malloc(), then you
>                      usually get a
>                      crash.
>
>
>                  My understanding of the ELF ABI for thread-locals -
>         which I read
>                  about
>                  in the Solaris 11.1 Linkers and libraries guide - does
>         require
>                  use of
>                  the dynamic TLS model for any dynamically loaded shared
>         object which
>                  defines a thread-local, but that is what we use as I
>         understand
>                  it. The
>                  docs state:
>
>                  "A shared object containing only dynamic TLS can be
>         loaded following
>                  process startup without limitations. The runtime linker
>         extends
>                  the list
>                  of initialization records to include the initialization
>         template
>                  of the
>                  new object. The new object is given an index of m = M +
>         1. The
>                  counter M is incremented by 1. However, the allocation
>         of new
>                  TLS blocks
>                  is deferred until the blocks are actually referenced."
>
>                  Now I guess "extends the list" might be implemented
>         using malloc
>                  ... but
>                  this will only occur in the main thread (the one
>         started by the
>                  launcher
>                  to load the JVM and become the main thread), at the
>         time libjvm is
>                  loaded - which will all be over before any agent etc
>         can run and do
>                  anything. But "allocation ... is deferred" suggests we
>         may have a
>                  problem until either the first call to Thread::current
>         or the
>                  call to
>                  Thread::initialize_thread_current. If it is the former
>         then that
>                  should
>                  occur well before any agent etc can be loaded. And I
>         can easily
>                  inject
>                  an initial dummy call to initialize_thread_current(null) to
>                  force the
>                  TLS allocation.
>
>                      This may bite you if AsyncGetCallTrace uses
>                      Thread::current(), and you
>                      use system timers to do profiling.  If a thread doing a
>                      malloc() prior
>                      to the first time it accesses Thread::current(),
>         and it gets
>                      delivered a
>                      signal, it might die.  This is especially likely
>         for pure
>                      native threads
>                      started by native code.
>
>                      I believe that this is a use case you support, so
>         you might
>                      want to make
>                      sure it is okay.
>
>
>                  For a VM embedded in a process, which already contains
>         native
>                  threads,
>                  that will later attach to the VM, this may indeed be a
>         problem. One
>                  would have hoped however that the implementation of TLS
>         would be
>                  completely robust, at least for something as simple as
>         getting a
>                  signal
>                  whilst in the allocator.
>
>                  I'm unclear how to test for or check for this kind of
>         problem.
>                  Arguably
>                  there could be many things that are async-unsafe in
>         this way.
>
>                  Need to think more about this and do some more
>         research. Would also
>                  appreciate any insight from any glibc and/or ELF gurus.
>
>                  Thanks.
>                  David
>
>                      Jeremy
>
>                      On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>                      <jeremymanson at google.com
>         <mailto:jeremymanson at google.com> <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>>
>                      <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>
>                      <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>>>> wrote:
>
>                           Something that's bitten me with __thread: it isn't
>                      async-safe when
>                           called from a shared object on Linux.  Have
>         you vetted
>                      to make sure
>                           this doesn't make HS less async-safe?
>
>                           Jeremy
>
>                           On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>                           <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>                      <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>
>                      <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>
>                      <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>>> wrote:
>
>                               bug:
>         https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                               Open webrev:
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>                               A simple (in principle) but wide-ranging
>         change
>                      which should
>                               appeal to our Code Deletion Engineer's. We
>         implement
>                               Thread::current() using a
>         compiler/language-based
>                      thread-local
>                               variable eg:
>
>
>                                 static __thread Thread *_thr_current;
>
>                                 inline Thread* Thread::current() {
>                                   return _thr_current;
>                                 }
>
>                               with an appropriate setter of course. By
>         doing this
>                      we can
>                               completely remove the platform-specific
>                      ThreadLocalStorage
>                               implementations, and the associated
>                      os::thread_local_storage*
>                               calls, plus all the uses of
>                      ThreadLocalStorage::thread() and
>                               ThreadLocalStorage::get_thread_slow().
>         This extends
>                      the previous
>                               work done on Solaris to implement
>                      ThreadLocalStorage::thread()
>                               using compiler-based thread-locals.
>
>                               We can also consolidate nearly all the os_cpu
>                      versions of
>                               MacroAssembler::get_thread on x86 into one cpu
>                      specific one ( a
>                               special variant is still needed for 32-bit
>         Windows).
>
>                               As a result of this change we have further
>                      potential cleanups:
>                               - all the
>         src/os/<os>/vm/thread_<os>.inline.hpp
>                      files are now
>                               completely empty and could also be removed
>                               - the MINIMIZE_RAM_USAGE define (which
>         avoids use
>                      of the linux
>                               sp-map "cache" on 32-bit) now has no
>         affect and so
>                      could be
>                               completely removed from the build system
>
>                               I plan to do the MINIMIZE_RAM_USAGE
>         removal as a
>                      follow up CR,
>                               but could add the removal of the "inline"
>         files to
>                      this CR if
>                               people think it worth removing them.
>
>                               I have one missing piece on Aarch64 - I
>         need to change
>                               MacroAssembler::get_thread to simply call
>                      Thread::current() as
>                               on other platforms, but I don't know how
>         to write
>                      that. I would
>                               appreciate it if someone could give me the
>         right
>                      code for that.
>
>                               I would also appreciate comments/testing
>         by the AIX
>                      and PPC64
>                               folk as well.
>
>                               A concern about memory-leaks had
>         previously been
>                      raised, but
>                               experiments using simple C code on linux
>         86 and
>                      Solaris showed
>                               no issues. Also note that Aarch64 already
>         uses this
>                      kind of
>                               thread-local.
>
>                               Thanks,
>                               David
>
>
>
>
>

From david.holmes at oracle.com  Sun Nov  8 23:26:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Nov 2015 09:26:49 +1000
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563D1C97.4010702@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
Message-ID: <563FDA39.5040206@oracle.com>

Hi Gerard,

Sorry, I don't like the way all the metaspaceshared internal logistical 
calculations are now exposed in globals.hpp. Can we not keep those 
calculations internal to the metaspace code and just export the 
resulting minimum and default values?

I'm also unclear where your max values are coming from.

On 7/11/2015 7:33 AM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating feedback from Dmitry:
>
> - Fix comments and indentation
> - Add "-XShare:dump" while testing Shared* flags

When dumping during testing you need to specify a specific shared 
archive file name (-XX:SharedArchiveFile=... IIRC) otherwise you will be 
creating the archive in the location of the JVM under test and 
potentially impact later tests.

Thanks,
David

> - Temporarily disable testing of SharedMiscDataSize as with current min
> default it exits the VM with code 2 (which is allowed by the JEP, but
> not the test framework). This issue is tracked by JDK-8141650
>
> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>
>
>
> cheers
>
>
>
> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this final fix for JEP-245
>>
>> We implement the remaining runtime flags in the Shared* family.
>>
>> Summary of changes:
>>
>> #1 core fix - we factor out the constants to be used in the ranges
>>
>> src/share/vm/classfile/compactHashtable.cpp
>> src/share/vm/memory/metaspace.cpp
>> src/share/vm/memory/metaspaceShared.hpp
>> src/share/vm/runtime/globals.hpp
>>
>>
>> #2 we increase default sizes of range and constraint tables to
>> minimize mallocs
>>
>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>
>>
>> #3 we fix a bug that I run into the OptionsValidation test framework
>> while working
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>
>>
>>
>> #4 we add functionality to OptionsValidation test framework that we
>> later use
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>
>>
>>
>> #5 we cleanup and extend the existing test to detect a case where we
>> get out of range value
>>
>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>
>>
>> The fix passes RBT
>> "hotspot/test/:hotspot_all,testlist,noncolo.testlist
>> --add-tonga-keyword quick? and JPRT ?hotspot" tests
>>
>> References:
>>
>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>
>>
>> hg_stat:
>>
>>
>> src/share/vm/classfile/compactHashtable.cpp
>> |    2 +-
>>
>> src/share/vm/memory/metaspace.cpp
>> |   30 --
>>
>> src/share/vm/memory/metaspaceShared.hpp
>> |   19 +-
>>
>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>> |    2 +-
>>
>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>> |    2 +-
>>
>> src/share/vm/runtime/globals.hpp
>> |   63 +++++-
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>> |    4 +-
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>> |   81 +++++++
>>
>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>> |  180 +++++++++-------
>>   9 files changed, 242 insertions(+), 141 deletions(-)

From dl at cs.oswego.edu  Sun Nov  8 23:31:08 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 8 Nov 2015 18:31:08 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <563C557E.3060505@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
Message-ID: <563FDB3C.5070702@cs.oswego.edu>

On 11/06/2015 02:23 AM, David Holmes wrote:

> Before I look at the code, what is the status of the "Open Issues" referenced in
> the JEP?
>
> Also the JDK changes need to be reviewed on core-libs-dev and in particular must
> be seen by the jsr166 maintainers (ie Doug Lea and Martin Buchholz)
>

Martin and I and others are aware of this work.

As has been said by everyone initially looking at JEP 270,
it is a disappointing effort. It requires that APIs/methods supporting
try/finally-like constructions (especially locks) include new annotations to
substantially reduce the likelihood of failing to perform the "finally" side
actions to release resources (like a lock) upon StackOverflowError.

Considering that no other readily implementable solution has
been proposed during the many years that this issue has been discussed,
a disappointing band-aid might not be so bad.
Assuming the hotspot mechanics are put into place, the main question
is when to use the  @ReservedStackAccess annotation.

The JEP singles out ReentrantLock. But there are also other locks
provided in JDK (StampedLock, ReentrantReadWriteLock), as well
as in other external packages, that should probably use this.
Plus there are other lock/resource APIs, for example Semaphore,
that are often used in try/finally constructions. And internal
before/after bookkeeping inside Executors. Plus, many cases of
try-with-resources constructions. Plus many transactional APIs.

And so on. It would be a never-ending effort to effectively use
@ReservedStackAccess.

I don't know of a good way to address this. One possibility is
for javac to automatically insert @ReservedStackAccess in any
method with a try-finally that involves at least one call?

-Doug

>
> On 6/11/2015 12:17 AM, Frederic Parain wrote:
>> Please review the changesets for JEP 270: Reserved Stack Areas for
>> Critical Sections
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8046936
>>
>> Webrevs:
>>    hotspot: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
>>    JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
>>
>> The CR contains a detailed description of the issue and the design
>> of the solution as well as implementation details.
>>
>> Tests:
>>
>>      JPRT - hotspot & core
>>      RBT - vm.quick
>>
>> Thanks
>>
>> Fred
>>
>


From david.holmes at oracle.com  Sun Nov  8 23:31:53 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Nov 2015 09:31:53 +1000
Subject: RFR (XS): JDK-8141548 Hotspot Windows build should respect
	WARNINGS_AS_ERRORS
In-Reply-To: <563C97E9.5020007@oracle.com>
References: <563B813E.5010506@oracle.com> <563C5428.5030300@oracle.com>
	<563C97E9.5020007@oracle.com>
Message-ID: <563FDB69.4010700@oracle.com>

On 6/11/2015 10:07 PM, Magnus Ihse Bursie wrote:
> On 2015-11-06 08:18, David Holmes wrote:
>> Looks okay to me.
>>
>> Where do you propose to push this? Please submit via JPRT.
> I was planning to use hs-rt, but I have no opinion on that, really.

hs-rt is good.

Thanks,
David

> /Magnus
>
>>
>> Thanks.
>>
>> David
>>
>> On 6/11/2015 2:18 AM, Magnus Ihse Bursie wrote:
>>> Currently the /WX flag is hardcoded in the Hotspot windows make files.
>>> This makes it impossible to turn of warnings-as-errors for Windows
>>> without explicitely hacking the makefiles. This should be fixed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141548
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8141548-hotspot-windows-build-should-respect-warnings-as-errors/webrev.01
>>>
>>>
>>>
>>> /Magnus
>

From david.holmes at oracle.com  Sun Nov  8 23:54:57 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Nov 2015 09:54:57 +1000
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
Message-ID: <563FE0D1.20308@oracle.com>

Hi Kim,

runtime changes look fine.

Thanks,
David

On 7/11/2015 8:09 AM, Kim Barrett wrote:
> [Sending to hotspot-dev because this touches runtime and compiler
> files too. I'm particularly looking for a compiler person for the
> change to HotSpotVMConfig.java.]
>
> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
> cleanup is being done in preparation for some further changes that
> will make the name more widely used.
>
> Probably the satbQueue.[ch]pp files should be renamed to
> satbMarkQueue.[ch]pp.  I've not made such a change because my
> understanding is that mercurial mq doesn't really understand file
> renames.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8077571
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
>
> Testing:
> JPRT
>

From david.holmes at oracle.com  Mon Nov  9 07:12:59 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Nov 2015 17:12:59 +1000
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <563FDB3C.5070702@cs.oswego.edu>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu>
Message-ID: <5640477B.3010302@oracle.com>

Hi Doug,

On 9/11/2015 9:31 AM, Doug Lea wrote:
> On 11/06/2015 02:23 AM, David Holmes wrote:
>
>> Before I look at the code, what is the status of the "Open Issues"
>> referenced in the JEP?
>>
>> Also the JDK changes need to be reviewed on core-libs-dev and in
>> particular must
>> be seen by the jsr166 maintainers (ie Doug Lea and Martin Buchholz)
>>
>
> Martin and I and others are aware of this work.
>
> As has been said by everyone initially looking at JEP 270, it is a
> disappointing effort. It requires that APIs/methods supporting
> try/finally-like constructions (especially locks) include new
> annotations to substantially reduce the likelihood of failing to
> perform the "finally" side actions to release resources (like a lock)
> upon StackOverflowError.
>
> Considering that no other readily implementable solution has
> been proposed during the many years that this issue has been discussed,
> a disappointing band-aid might not be so bad.

If I put on some extra-strength rose-coloured glasses I think I can 
almost read that as "something is better than nothing". ;-) As there are 
no practical general solutions to the problem (which surely says 
something fundamental about the language design!) an annotation-based 
point solution seems the only way to make some progress.

But note that it is not the finally part that need be at issue. If one 
considers ReentrantLock.lock() (in NonfairSync):

  210         final void lock() {
  211             if (compareAndSetState(0, 1))
  212                 setExclusiveOwnerThread(Thread.currentThread());
  213             else
  214                 acquire(1);
  215         }

if we throw after #211 the lock is half-locked: state says it is locked, 
but no owner set. So it can't be locked again, nor can it be unlocked. 
We would have to determine actual stack usage for each call path to know 
whether that is in fact possible

> Assuming the hotspot mechanics are put into place, the main question
> is when to use the  @ReservedStackAccess annotation.
>
> The JEP singles out ReentrantLock. But there are also other locks
> provided in JDK (StampedLock, ReentrantReadWriteLock), as well
> as in other external packages, that should probably use this.
> Plus there are other lock/resource APIs, for example Semaphore,
> that are often used in try/finally constructions. And internal
> before/after bookkeeping inside Executors. Plus, many cases of
> try-with-resources constructions. Plus many transactional APIs.
>
> And so on. It would be a never-ending effort to effectively use
> @ReservedStackAccess.

Which, to me, is just another way of saying that the general problem is 
intractable. The annotation at least gives the mechanism for a point 
solution as has been said. The pain point that drove this was the use of 
ReentrantLock in ConcurrentHashMap, which in turn was used in class 
loading. That particular pain point has been addressed by not using the 
problematic class - something we surely do not want to promote as the 
way to deal with this problem!

> I don't know of a good way to address this. One possibility is
> for javac to automatically insert @ReservedStackAccess in any
> method with a try-finally that involves at least one call?

I don't see how that would be at all viable as it brings back in the 
sizing problem - or greatly exacerbates the sizing problem. Plus as 
noted above the problem is not just with the finally part.

Perhaps we should simply start with j.u.c.locks as the initial candidate 
sets of classes and work out from there. The idiomatic Lock usage:

l.lock();
try {
  // ...
} finally {
   l.unlock();
}

epitomizes the critical-finally-block scenario (though the lock() 
problem is much more subtle). AQS is too low-level to flag any specific 
function I think; and the other synchronizers perhaps too high-level, 
with fewer idiomatic use-cases that obviously benefit from this.

In that regard I don't agree with where Fred has currently placed the 
annotation in ReentrantLock and AQS. The placements appear arbitrary at 
first glance - though no doubt they are the result of a deep and careful 
analysis. But it is far from obvious why the annotation is placed on 
NonfairSync.lock but FairSync.tryAcquire(), for example.

I would be tempted to place them on all the public lock/unlock methods 
of the Lock implementations, rather than on the internal AQS-derived 
functions, and AQS itself.

Cheers,
David

> -Doug
>
>>
>> On 6/11/2015 12:17 AM, Frederic Parain wrote:
>>> Please review the changesets for JEP 270: Reserved Stack Areas for
>>> Critical Sections
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8046936
>>>
>>> Webrevs:
>>>    hotspot:
>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
>>>    JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
>>>
>>> The CR contains a detailed description of the issue and the design
>>> of the solution as well as implementation details.
>>>
>>> Tests:
>>>
>>>      JPRT - hotspot & core
>>>      RBT - vm.quick
>>>
>>> Thanks
>>>
>>> Fred
>>>
>>
>

From goetz.lindenmaier at sap.com  Mon Nov  9 07:40:17 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Nov 2015 07:40:17 +0000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
	<811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>

Hi Christian,

thanks for incorporating these cleanups.
The change still looks good ?.

Best regards,
  Goetz.

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Freitag, 6. November 2015 18:13
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds


On Nov 6, 2015, at 1:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:

Hi Christian,

thanks for doing this change.  It looks good.

It's good that now notproduct flags are also defined in the product build as constants,
as it's already the case with debug flags.
This allows more cleanups in the style you did to compilerDirectives.hpp.

I had a look at these cleanups, quite a row you can find in this patch:
http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch

That is a very nice cleanup.



Does it make sense to commit these along with your change?

It does.  I?ve updated my webrev with your changes:

http://cr.openjdk.java.net/~twisti/8140424/webrev/



Best regards,
 Goetz.




-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
Behalf Of Christian Thalinger
Sent: Freitag, 6. November 2015 07:23
To: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
variables with CONST_ in product builds

https://bugs.openjdk.java.net/browse/JDK-8140424
<https://bugs.openjdk.java.net/browse/JDK-8140424>
http://cr.openjdk.java.net/~twisti/8140424/webrev/
<http://cr.openjdk.java.net/~twisti/8140424/webrev/>

When working on JDK-8024545 I added code that prefixes developer and
notproduct flags with CONST_. I think I did this to be able to access the
address of these variables for the flag table. But this is not necessary because
these flag cannot be written anyway.

I am proposing to remove the CONST_ prefix and define the variables as
const.


From sgehwolf at redhat.com  Mon Nov  9 09:32:05 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 09 Nov 2015 10:32:05 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <1446634476.3554.8.camel@redhat.com>
References: <1446460682.10865.20.camel@redhat.com>
	<56377F17.4050006@oracle.com> <5637871B.30705@oracle.com>
	<1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com>
	<1446634476.3554.8.camel@redhat.com>
Message-ID: <1447061525.3551.3.camel@redhat.com>

On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> Hi,
> 
> Updated webrev with jtreg test in Java:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
> bug:?https://bugs.openjdk.java.net/browse/JDK-6425769
> 
> I believe this updated webrev addresses all concerns and incorporates
> suggestions brought up by Jaroslav and Daniel.
> 
> I'm still looking for a sponsor and a hotspot/servicability-dev
> reviewer. Could somebody maintaining javax.rmi.ssl have a look at
> this
> as well? Thank you!

Ping? Friendly reminder that I still need reviewers and a sponsor for
this.

Thanks,
Severin

> Cheers,
> Severin
> 
> On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote:
> > On 2.11.2015 19:06, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Thanks Jaroslav and Daniel for the reviews! Comments inline.
> > > 
> > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> > > > Hi,
> > > > 
> > > > On 2.11.2015 16:19, Daniel Fuchs wrote:
> > > > > Hi Severin,
> > > > > 
> > > > > Adding serviceability-dev at openjdk.java.net into the loop -
> > > > > that's
> > > > > a better alias than hotspot-dev for this kind of changes -
> > > > > maybe
> > > > > someone from serviceability-dev will offer to sponsor :-)
> > > > > 
> > > > > I will let serviceability team members comment on the hotspot
> > > > > changes.
> > > > > 
> > > > > ConnectorBootstrap.java
> > > > > 
> > > > > I have one suggestion and one concern:
> > > > > 
> > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket
> > > > > Factory)
> > > > > and
> > > > > ssf??(Server Socket Factory) variables rather than introduce
> > > > > the
> > > > > two
> > > > > new variables rmiServerSocketFactory and
> > > > > rmiClientSocketFactory.
> > > > > You might want to create a new boolean 'useSocketFactory'
> > > > > variable,
> > > > > if that makes the code more readable.
> > > > > 
> > > > > Concern: If I understand correctly how RMI socket factories
> > > > > work,
> > > > > the client socket factory will be serialized and sent to the
> > > > > client
> > > > > side. This is problematic for interoperability, as the class
> > > > > may
> > > > > not
> > > > > present in the remote client - if the remote client is e.g.
> > > > > jdk
> > > > > 8.
> > > > > 
> > > > > As far as I can see, your new DefaultClientSocketFactory
> > > > > doesn't do
> > > > > anything useful - so I would suggest to simply get rid of it,
> > > > > and
> > > > > only
> > > > > set the Server Socket Factory when SSL is not involved.
> > > 
> > > Thanks. Fixed in updated webrev.
> > > 
> > > > > Tests:
> > > > > 
> > > > > Concerning the tests - we're trying to get rid of shell
> > > > > scripts
> > > > > rather than introducing new ones :-)
> > > > > Could the test be rewritten in pure java using the Process
> > > > > API?
> > > > > 
> > > > > I believe there's even a test library that will let you do
> > > > > that
> > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/
> > > > > (see ProcessTools.java)
> > > 
> > > It'll take me a bit to rewrite the test in pure Java, but should
> > > be
> > > fine. This is not yet fixed in the updated webrev.
> > > 
> > > > > Other:
> > > > > 
> > > > > Also - I believe the new option should be documented in:
> > > > > src/java.management/share/conf/management.properties
> > > 
> > > Docs have been updated
> > > in src/java.management/share/conf/management.properties.
> > > 
> > > > I share Daniel's concerns. Also, the part of the changeset is
> > > > related
> > > > to javax.rmi.ssl - someone maintaining this library should also
> > > > comment here.
> > > > 
> > > > Also, the change is introducing new API (system property) and
> > > > changing the existing one (adding SslRmiServerSocketFactory
> > > > public
> > > > constructors) so compatibility review process will have to be
> > > > involved.
> > > 
> > > OK. What exactly is there for me to do? I'm not familiar with
> > > this
> > > process. Note that the intent would be to get this backported to
> > > JDK 8.
> > Not much for you. But for the potential Oracle sponsor this means
> > she
> > will have to remember to go through some extra hoops before
> > integrating your patch.
> 
> I see. Thanks for clarifying it.
> 
> > -JB-
> > 
> > > 
> > > New webrev at:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/
> > > 
> > > Thanks,
> > > Severin
> > > 
> > > > -JB-
> > > > > 
> > > > > best regards,
> > > > > 
> > > > > -- daniel
> > > > > 
> > > > > On 02/11/15 11:38, Severin Gehwolf wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Here is a patch addressing JDK-6425769. The issue is that
> > > > > > the
> > > > > > JMX
> > > > > > agent
> > > > > > binds to the wildcard address by default, preventing users
> > > > > > to
> > > > > > use
> > > > > > system properties for JMX agents on multi-homed hosts.
> > > > > > Given
> > > > > > a
> > > > > > host
> > > > > > with local network interfaces, 192.168.0.1 and 192.168.0.2
> > > > > > say,
> > > > > > it's
> > > > > > impossible to start two JMX agents binding to fixed ports
> > > > > > but
> > > > > > to
> > > > > > different network interfaces, 192.168.0.1:{9111,9112} and
> > > > > > 192.168.0.2:{9111,9112} say.
> > > > > > 
> > > > > > The JDK would bind to all local interfaces by default. In
> > > > > > the
> > > > > > above
> > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is
> > > > > > that
> > > > > > the
> > > > > > second
> > > > > > Java process would get a "Connection refused" error because
> > > > > > another
> > > > > > process has already been bound to the specified JMX/RMI
> > > > > > port
> > > > > > pairs.
> > > > > > 
> > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-64
> > > > > > 25
> > > > > > 769/
> > > > > > 00/
> > > > > > 
> > > > > > Testing done:
> > > > > > jdk_jmx and jdk_management tests all pass after this change
> > > > > > (no
> > > > > > regressions). There is also a new JTREG test which fails
> > > > > > prior
> > > > > > this
> > > > > > change and passes after. Updates to the diagnostic command
> > > > > > have
> > > > > > been
> > > > > > tested manually.
> > > > > > 
> > > > > > I understand that, if approved, the JDK and hotspot changes
> > > > > > should get
> > > > > > pushed together? Hotspot changes are fairly trivial since
> > > > > > it's
> > > > > > only a
> > > > > > doc-update for the new JDK property in the relevant
> > > > > > diagnostic
> > > > > > command.
> > > > > > 
> > > > > > Could someone please review and sponsor this change? Please
> > > > > > let
> > > > > > me know
> > > > > > if there are questions.
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From stefan.karlsson at oracle.com  Mon Nov  9 09:34:31 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Nov 2015 10:34:31 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <56332DE8.8060904@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
Message-ID: <564068A7.802@oracle.com>

Hi Vladimir,

What do you think about this version:
  http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
  http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/

Thanks,
StefanK

On 2015-10-30 09:44, Vladimir Kozlov wrote:
> On 10/29/15 11:52 PM, Stefan Karlsson wrote:
>> Hi Vladimir,
>>
>> On 2015-10-27 16:22, Vladimir Kozlov wrote:
>>> CodeCache::verify_oops() also calls it unguarded.
>>>
>>> I think for complete solution nmethod::verify_oop_relocations() and
>>> called from it oop_Relocation::verify_oop_relocation(),
>>> verify_value(), const_verify_data_value() and pd_verify_data_value()
>>> should be declared and defined in debug build only.
>>
>> I see what you're saying, but I'm unsure that this is really what we
>> want to do.
>>
>> CodeCache::verify_oops is called from the Universe::verify, that can be
>> enabled in product builds by setting -XX:+UnlockDiagnosticVMOptions and
>> -XX:+VerifyBeforeGC and/or -XX:+VerifyAfterGC. Maybe we want to change
>> the relocation code to use guarantees instead of asserts? So that we can
>> get verification of the relocation code in product builds?
>
> Yes, I think it is good suggestion (asserts -> guarantees or fatals) 
> in addition to webrev.01.
>
> Thanks,
> Vladimir
>
>>
>> Thanks,
>> StefanK
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 10/27/15 7:44 PM, Stefan Karlsson wrote:
>>>> Hi,
>>>>
>>>> Please review this patch to remove some unnecessary verification code
>>>> from our product builds.
>>>>
>>>> Today, CodeCache::gc_epilogue() guards the call to
>>>> nmethod::verify_oop_relocations with DEBUG_ONLY, while
>>>> nmethod::oops_do_marking_epilogue doesn't. Since
>>>> nmethod::verify_oop_relocations uses asserts when verifying the
>>>> relocations, this is just wasted cycles in product builds. This patch
>>>> adds DEBUG_ONLY to nmethod::oops_do_marking_epilogue.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8140584/webrev.01/
>>>> https://bugs.openjdk.java.net/browse/JDK-8140584
>>>>
>>>> Thanks,
>>>> StefanK
>>


From thomas.schatzl at oracle.com  Mon Nov  9 09:39:15 2015
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Nov 2015 10:39:15 +0100
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
Message-ID: <1447061955.2280.5.camel@oracle.com>

Hi,

On Fri, 2015-11-06 at 17:09 -0500, Kim Barrett wrote:
> [Sending to hotspot-dev because this touches runtime and compiler
> files too. I'm particularly looking for a compiler person for the
> change to HotSpotVMConfig.java.]
> 
> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
> cleanup is being done in preparation for some further changes that
> will make the name more widely used.
> 
> Probably the satbQueue.[ch]pp files should be renamed to
> satbMarkQueue.[ch]pp.  I've not made such a change because my
> understanding is that mercurial mq doesn't really understand file
> renames.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8077571
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
> 
> Testing:
> JPRT
> 

  looks good to me. Just rename the files, mercurial understands
renames.

Thanks,
  Thomas



From sgehwolf at redhat.com  Mon Nov  9 12:51:24 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 09 Nov 2015 13:51:24 +0100
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
Message-ID: <1447073484.3551.30.camel@redhat.com>

On Fri, 2015-11-06 at 11:47 -0500, Kim Barrett wrote:
> On Nov 5, 2015, at 8:33 PM, Coleen Phillimore <coleen.phillimore at orac
> le.com> wrote:
> > 
> > With the RedHat compiler that I'm using g++ (GCC) 4.8.2 20140120
> > (Red Hat 4.8.2-16)
> > these additional includes are needed to compile without precompiled
> > headers.
> > 
> > open webrev at http://cr.openjdk.java.net/~coleenp/8141570.01/
> > bug link https://bugs.openjdk.java.net/browse/JDK-8141570
> > 
> > I'm not sure why allocation.inline.hpp is needed unless the virtual
> > destructor in src/share/vm/gc/shared/plab.hpp PLABStats implicitly
> > calls delete.
> > 
> > Tested with compiles of Zero plus plain linux
> > debug/fastdebug/product.
> > 
> > Thanks,
> > Coleen
> 
> src/share/vm/gc/g1/g1EvacStats.hpp
> ? 29 #include "memory/allocation.inline.hpp"
> ? 30 #include "runtime/atomic.inline.hpp"
> 
> xxx.inline.hpp files are not supposed to be included by xxx.hpp
> files.
> 
> The need for atomic.inline.hpp seems clear, and would seem to
> constitute a bug in
> g1EvacStats.hpp - there should be a g1EvacStats.inline.hpp file.
> 
> I really don?t understand why allocation.inline.hpp is needed here at
> all.

FWIW, the below hunk seems to be all that's necessary in order to fix
the --disable-precompiled-headers Zero build for me:

diff --git a/src/share/vm/runtime/java.cpp b/src/share/vm/runtime/java.cpp
--- a/src/share/vm/runtime/java.cpp
+++ b/src/share/vm/runtime/java.cpp
@@ -49,6 +49,7 @@
?#include "runtime/arguments.hpp"
?#include "runtime/biasedLocking.hpp"
?#include "runtime/compilationPolicy.hpp"
+#include "runtime/deoptimization.hpp"
?#include "runtime/fprofiler.hpp"
?#include "runtime/init.hpp"
?#include "runtime/interfaceSupport.hpp"

It does not seem the other change is required. Tested with fastdebug
build of Zero with --disable-precompiled-headers that failed to build
without and built fine with the fix.

Coleen, do you have details about the failure which gets supposedly
fixed by the other hunk?

Also the original build failure this patch is supposed to fix now got
picked up by our builders too:
http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero_no_pch/37

Cheers,
Severin

From maurizio.cimadamore at oracle.com  Mon Nov  9 13:54:08 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 9 Nov 2015 13:54:08 +0000
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <54B6BAA1-C4FF-42F0-BB69-64C4558D7601@oracle.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
	<54B6BAA1-C4FF-42F0-BB69-64C4558D7601@oracle.com>
Message-ID: <5640A580.3060305@oracle.com>

Hi,
I still see this on my Ubuntu 14.04 (x64) on a fresh jdk 9 repo. Was the 
fix pushed?

Thanks
Maurizio

On 06/11/15 06:27, Christian Thalinger wrote:
>> On Nov 4, 2015, at 8:21 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Hi,
>>
>> can somebody please review and sponsor the following tiny build fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
>> https://bugs.openjdk.java.net/browse/JDK-8141416
>>
>> Building hotspot on certain systems results in a series of:
>> expr: syntax error
>> expr: syntax error
>> expr: syntax error
>> expr: syntax error
>>
>> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
>> -dumpversion" doesn't print a micro-version:
>>
>> Ubuntu:
>> $ gcc -dumpversion
>> 4.6
>>
>> Any other Linux:
>> $ gcc -dumpversion
>> 4.8.3
>>
>> This "feature" is tracked under
>> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
>> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
>>
>> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
>> gcc and use it in the following way:
>>
>> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f3)
> I?ve added this.  Thanks for fixing it.
>
>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
>> $(CC_VER_MICRO) = 1), 1)
>>   $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
>> supported because of
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
>> endif
>>
>> The shell expression results in a syntax error if $(CC_VER_MICRO)
>> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
>>
>> Thank you and best regards,
>> Volker


From maurizio.cimadamore at oracle.com  Mon Nov  9 13:55:34 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 9 Nov 2015 13:55:34 +0000
Subject: RFR(XS): 8141416: "expr: syntax error" due to gcc -dumpversion
	excluding micro
In-Reply-To: <5640A580.3060305@oracle.com>
References: <CA+3eh12=yinN0KE6w_FwC-GDBWs8x-rR=RYCjo52P0Dp6V3pQg@mail.gmail.com>
	<54B6BAA1-C4FF-42F0-BB69-64C4558D7601@oracle.com>
	<5640A580.3060305@oracle.com>
Message-ID: <5640A5D6.1090303@oracle.com>



On 09/11/15 13:54, Maurizio Cimadamore wrote:
> Hi,
> I still see this on my Ubuntu 14.04 (x64) on a fresh jdk 9 repo. Was 
> the fix pushed?
Nvm - it has been pushed to the hs-comp repo - it will take few days to 
get to jdk9/dev (which is what I'm using).

Thanks
Maurizio
>
> Thanks
> Maurizio
>
> On 06/11/15 06:27, Christian Thalinger wrote:
>>> On Nov 4, 2015, at 8:21 AM, Volker Simonis 
>>> <volker.simonis at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> can somebody please review and sponsor the following tiny build fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8141416/
>>> https://bugs.openjdk.java.net/browse/JDK-8141416
>>>
>>> Building hotspot on certain systems results in a series of:
>>> expr: syntax error
>>> expr: syntax error
>>> expr: syntax error
>>> expr: syntax error
>>>
>>> It is caused by a peculiarity of the gcc version on Ubuntu where "gcc
>>> -dumpversion" doesn't print a micro-version:
>>>
>>> Ubuntu:
>>> $ gcc -dumpversion
>>> 4.6
>>>
>>> Any other Linux:
>>> $ gcc -dumpversion
>>> 4.8.3
>>>
>>> This "feature" is tracked under
>>> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1360404 and has
>>> been fixed for gcc 4.9 but won't be fixed for older versions of gcc.
>>>
>>> In hotspot/make/linux/makefiles/gcc.make we parse the micro-version of
>>> gcc and use it in the following way:
>>>
>>> CC_VER_MICRO := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut 
>>> -d'.' -f3)
>> I?ve added this.  Thanks for fixing it.
>>
>>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 1 \&
>>> $(CC_VER_MICRO) = 1), 1)
>>>   $(error "GCC $(CC_VER_MAJOR).$(CC_VER_MINOR).$(CC_VER_MICRO) not
>>> supported because of
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724")
>>> endif
>>>
>>> The shell expression results in a syntax error if $(CC_VER_MICRO)
>>> because it expands to something like "expr 4 = 4 & 3 = 1 & = 1"
>>>
>>> Thank you and best regards,
>>> Volker
>


From christian.thalinger at oracle.com  Mon Nov  9 17:06:28 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 9 Nov 2015 07:06:28 -1000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
	<811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>
Message-ID: <798CDB11-5DEA-40AF-8AEA-AC2001546A85@oracle.com>

I did verify that our compilers are in fact eliminating all code and Stefan Karlsson made sure some important GC functions still produce the same code.

> On Nov 8, 2015, at 9:40 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Christian,
>  
> thanks for incorporating these cleanups.
> The change still looks good J.
>  
> Best regards,
>   Goetz.
>  
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Freitag, 6. November 2015 18:13
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds
>  
>  
> On Nov 6, 2015, at 1:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com>> wrote:
>  
> Hi Christian, 
> 
> thanks for doing this change.  It looks good.
> 
> It's good that now notproduct flags are also defined in the product build as constants, 
> as it's already the case with debug flags.
> This allows more cleanups in the style you did to compilerDirectives.hpp.
> 
> I had a look at these cleanups, quite a row you can find in this patch:
> http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch <http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch>
>  
> That is a very nice cleanup.
> 
> 
> 
> Does it make sense to commit these along with your change?
>  
> It does.  I?ve updated my webrev with your changes:
>  
> http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
> 
> 
> 
> Best regards,
>  Goetz.
> 
> 
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net <mailto:hotspot-dev-bounces at openjdk.java.net>] On
> Behalf Of Christian Thalinger
> Sent: Freitag, 6. November 2015 07:23
> To: hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>
> Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
> variables with CONST_ in product builds
> 
> https://bugs.openjdk.java.net/browse/JDK-8140424 <https://bugs.openjdk.java.net/browse/JDK-8140424>
> <https://bugs.openjdk.java.net/browse/JDK-8140424 <https://bugs.openjdk.java.net/browse/JDK-8140424>>
> http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
> <http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>>
> 
> When working on JDK-8024545 I added code that prefixes developer and
> notproduct flags with CONST_. I think I did this to be able to access the
> address of these variables for the flag table. But this is not necessary because
> these flag cannot be written anyway.
> 
> I am proposing to remove the CONST_ prefix and define the variables as
> const.


From christian.thalinger at oracle.com  Mon Nov  9 17:27:32 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 9 Nov 2015 07:27:32 -1000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
	<811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>
Message-ID: <0EEB762C-1113-48D3-B7A1-9AE7B268D3CF@oracle.com>


> On Nov 8, 2015, at 9:40 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Christian,
>  
> thanks for incorporating these cleanups.
> The change still looks good J.

src/share/vm/prims/jni.cpp:

-void test_memset_with_concurrent_readers();
+void test_memset_with_concurrent_readers() NOT_DEBUG_RETURN;

Why is this change required?

>  
> Best regards,
>   Goetz.
>  
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Freitag, 6. November 2015 18:13
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds
>  
>  
> On Nov 6, 2015, at 1:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com>> wrote:
>  
> Hi Christian, 
> 
> thanks for doing this change.  It looks good.
> 
> It's good that now notproduct flags are also defined in the product build as constants, 
> as it's already the case with debug flags.
> This allows more cleanups in the style you did to compilerDirectives.hpp.
> 
> I had a look at these cleanups, quite a row you can find in this patch:
> http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch <http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch>
>  
> That is a very nice cleanup.
> 
> 
> 
> Does it make sense to commit these along with your change?
>  
> It does.  I?ve updated my webrev with your changes:
>  
> http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
> 
> 
> 
> Best regards,
>  Goetz.
> 
> 
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net <mailto:hotspot-dev-bounces at openjdk.java.net>] On
> Behalf Of Christian Thalinger
> Sent: Freitag, 6. November 2015 07:23
> To: hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>
> Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
> variables with CONST_ in product builds
> 
> https://bugs.openjdk.java.net/browse/JDK-8140424 <https://bugs.openjdk.java.net/browse/JDK-8140424>
> <https://bugs.openjdk.java.net/browse/JDK-8140424 <https://bugs.openjdk.java.net/browse/JDK-8140424>>
> http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
> <http://cr.openjdk.java.net/~twisti/8140424/webrev/ <http://cr.openjdk.java.net/~twisti/8140424/webrev/>>
> 
> When working on JDK-8024545 I added code that prefixes developer and
> notproduct flags with CONST_. I think I did this to be able to access the
> address of these variables for the flag table. But this is not necessary because
> these flag cannot be written anyway.
> 
> I am proposing to remove the CONST_ prefix and define the variables as
> const.


From christian.thalinger at oracle.com  Mon Nov  9 17:36:31 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 9 Nov 2015 07:36:31 -1000
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <49E590F6-9253-428A-9BF0-DE168238C21F@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
	<5E8086F9-871B-4C4F-B766-75EF1CB17D2B@oracle.com>
	<49E590F6-9253-428A-9BF0-DE168238C21F@oracle.com>
Message-ID: <572CF48F-AB96-4E64-8D94-62CC719D40E8@oracle.com>


> On Nov 7, 2015, at 10:58 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> On Nov 6, 2015, at 5:21 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> 
>>> On Nov 6, 2015, at 12:09 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> 
>>> [Sending to hotspot-dev because this touches runtime and compiler
>>> files too. I'm particularly looking for a compiler person for the
>>> change to HotSpotVMConfig.java.]
>> 
>> Yes, that change looks good.
> 
> Thanks!  I wasn?t getting anywhere trying to figure out what might be impacted by that change.

It?s really not that complicated.  A HotSpotVMField annotation reads a property specified by ?get? for a C++ field with the name ?name? with the type ?type?.  In this case:

+    @HotSpotVMField(name = "JavaThread::_satb_mark_queue", type = "SATBMarkQueue", get = HotSpotVMField.Type.OFFSET) @Stable public int javaThreadSatbMarkQueueOffset;

it is reading the offset of the field JavaThread::_satb_mark_queue.  The type is only used for verification.

> 
>>> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
>>> cleanup is being done in preparation for some further changes that
>>> will make the name more widely used.
>>> 
>>> Probably the satbQueue.[ch]pp files should be renamed to
>>> satbMarkQueue.[ch]pp.  I've not made such a change because my
>>> understanding is that mercurial mq doesn't really understand file
>>> renames.
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8077571
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
>>> 
>>> Testing:
>>> JPRT
> 
> 


From vladimir.kozlov at oracle.com  Mon Nov  9 17:54:46 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 9 Nov 2015 09:54:46 -0800
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <564068A7.802@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com>
Message-ID: <5640DDE6.1070406@oracle.com>

Very nice. You may need closed changes too.

Thanks,
Vladimir

On 11/9/15 1:34 AM, Stefan Karlsson wrote:
> Hi Vladimir,
>
> What do you think about this version:
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/
>
> Thanks,
> StefanK
>
> On 2015-10-30 09:44, Vladimir Kozlov wrote:
>> On 10/29/15 11:52 PM, Stefan Karlsson wrote:
>>> Hi Vladimir,
>>>
>>> On 2015-10-27 16:22, Vladimir Kozlov wrote:
>>>> CodeCache::verify_oops() also calls it unguarded.
>>>>
>>>> I think for complete solution nmethod::verify_oop_relocations() and
>>>> called from it oop_Relocation::verify_oop_relocation(),
>>>> verify_value(), const_verify_data_value() and pd_verify_data_value()
>>>> should be declared and defined in debug build only.
>>>
>>> I see what you're saying, but I'm unsure that this is really what we
>>> want to do.
>>>
>>> CodeCache::verify_oops is called from the Universe::verify, that can be
>>> enabled in product builds by setting -XX:+UnlockDiagnosticVMOptions and
>>> -XX:+VerifyBeforeGC and/or -XX:+VerifyAfterGC. Maybe we want to change
>>> the relocation code to use guarantees instead of asserts? So that we can
>>> get verification of the relocation code in product builds?
>>
>> Yes, I think it is good suggestion (asserts -> guarantees or fatals) in addition to webrev.01.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Thanks,
>>> StefanK
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 10/27/15 7:44 PM, Stefan Karlsson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this patch to remove some unnecessary verification code
>>>>> from our product builds.
>>>>>
>>>>> Today, CodeCache::gc_epilogue() guards the call to
>>>>> nmethod::verify_oop_relocations with DEBUG_ONLY, while
>>>>> nmethod::oops_do_marking_epilogue doesn't. Since
>>>>> nmethod::verify_oop_relocations uses asserts when verifying the
>>>>> relocations, this is just wasted cycles in product builds. This patch
>>>>> adds DEBUG_ONLY to nmethod::oops_do_marking_epilogue.
>>>>>
>>>>> http://cr.openjdk.java.net/~stefank/8140584/webrev.01/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8140584
>>>>>
>>>>> Thanks,
>>>>> StefanK
>>>
>

From sgehwolf at redhat.com  Mon Nov  9 17:57:32 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 09 Nov 2015 18:57:32 +0100
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BC171.7050703@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
Message-ID: <1447091852.3551.36.camel@redhat.com>

Hi Aleksey,

On Thu, 2015-11-05 at 23:52 +0300, Aleksey Shipilev wrote:
> Thanks for the review, Coleen!
> 
> I'll wait for RBT results to come in, and if they are positive, I'll
> push (I think through hs-comp, since it affects compilers mostly).
> 
> TODO in interpreter.cpp serves as the anchor for the upcoming Zero
> RFE.

Here is a partial implementation of the Zero bits. In fact, the code
was already there to handle other getters too. I don't know why it was
guarded with those asserts and with is_simple_accessor().

It does not yet implement the setter logic, but at least we don't have
to keep is_simple_accessor() around. The patch builds on top of your
latest 8140650/webrev.02/ webrev.

The patch I'm talking about is:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8140650/JDK-8140650-is_accessor_zero_cleanup.hotspot.patch

Feel free to incorporate it.

Cheers,
Severin

> Cheers,
> -Aleksey
> 
> On 11/05/2015 11:42 PM, Coleen Phillimore wrote:
> > 
> > Our emails crossed.???This change looks good.??I don't know how
> > necessary the Zero TODO is but the comment is fine.
> > 
> > Coleen
> > 
> > On 11/5/15 3:16 PM, Aleksey Shipilev wrote:
> > > Ah, no, the CallNode::may_modify polls is_accessor only for boxed
> > > instances, so there are no setters in Java code. Still, we should
> > > check
> > > for getters there explicitly, and the getter/setter split is
> > > sensible in
> > > Method API anyhow.
> > > 
> > > New webrev:
> > > ???http://cr.openjdk.java.net/~shade/8140650/webrev.02/
> > > 
> > > Re-spinning RBT for sanity.
> > > 
> > > Thanks,
> > > -Aleksey
> > > 
> > > On 11/05/2015 10:45 PM, Aleksey Shipilev wrote:
> > > > Thanks, Coleen!
> > > > 
> > > > The tricky part is that compilers poll Method::is_accessor via:
> > > > 
> > > > ? bool ciMethod::is_accessor????() const {
> > > > ????FETCH_FLAG_FROM_VM(is_accessor);
> > > > ? }
> > > > 
> > > > #define FETCH_FLAG_FROM_VM(flag_accessor) { \
> > > > ???check_is_loaded(); \
> > > > ???VM_ENTRY_MARK; \
> > > > ???return get_Method()->flag_accessor(); \
> > > > }
> > > > 
> > > > ...which may be opaque for IDEs, when you look for usages. I
> > > > found that
> > > > a text search for "is_accessor" yields only positive matches.
> > > > 
> > > > *Actually*, now that I read the code again, there is a
> > > > suspicious use in
> > > > CallNode::may_modify:
> > > > 
> > > > ???????if (meth->is_accessor()) {
> > > > ?????????return false;
> > > > ???????}
> > > > 
> > > > This seems to break if is_accessor accepts setters. Let me
> > > > split the
> > > > is_accessor into is_getter/is_setter and re-run tests. If you
> > > > spot other
> > > > problems in the patch, let me know.
> > > > 
> > > > Thanks,
> > > > -Aleksey
> > > > 
> > > > On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
> > > > > I am planning on reviewing this but I haven't had time.??And
> > > > > I'm trying
> > > > > to build Zero for a different reason.??I would be pretty
> > > > > unhappy if it
> > > > > broke Zero and would like it to not do that.??I haven't had a
> > > > > chance to
> > > > > read all of this yet.??I thought is_accessor was only for
> > > > > Zero so I
> > > > > guess I have to read more why this is getting changed.??I
> > > > > will try to
> > > > > get to it today.
> > > > > 
> > > > > Thanks,
> > > > > Coleen
> > > > > 
> > > > > On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
> > > > > > On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
> > > > > > > > > If there's an RFE filed and Zero maintainers promise
> > > > > > > > > to fix it in a
> > > > > > > > > prompt manner, I'm fine with what you proposed.
> > > > > > > > Yeah, that's the plan.
> > > > > > > > 
> > > > > > > > > Also, I had an idea: why don't you move
> > > > > > > > > is_simple_accessor() from
> > > > > > > > > Method
> > > > > > > > > to some Zero-specific location? I don't see any value
> > > > > > > > > in keeping
> > > > > > > > > it in
> > > > > > > > > Method.
> > > > > > > > That's an interesting trick, but I think it will cause
> > > > > > > > more harm:
> > > > > > > > shared
> > > > > > > > interpreter.cpp would have to know about that Zero-
> > > > > > > > specific
> > > > > > > > method, or
> > > > > > > > otherwise intercept "too wide" accessor shape and
> > > > > > > > narrow it down
> > > > > > > > before
> > > > > > > > it reaches Zero. Therefore, I believe
> > > > > > > > is_simple_accessor is the
> > > > > > > > lesser
> > > > > > > > evil.
> > > > > > > Ok. Looks good then.
> > > > > > Thanks for taking time to review, Vladimir! I'll count that
> > > > > > as the
> > > > > > review from the compiler side.
> > > > > > 
> > > > > > I think we still need a review from the runtime side.
> > > > > > Folks? For the
> > > > > > record, we are discussing this change:
> > > > > > ????http://cr.openjdk.java.net/~shade/8140650/webrev.01/
> > > > > > 
> > > > > > The patch passes JPRT, RBT (hotspot_all), and the new
> > > > > > regression test.
> > > > > > 
> > > > > > Thanks,
> > > > > > -Aleksey
> > > > > > 
> > > > > > 
> > > > 
> > > 
> > 
> 
> 


From aleksey.shipilev at oracle.com  Mon Nov  9 18:51:41 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 9 Nov 2015 21:51:41 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <1447091852.3551.36.camel@redhat.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
	<1447091852.3551.36.camel@redhat.com>
Message-ID: <5640EB3D.4010302@oracle.com>

Hi Severin,

On 11/09/2015 08:57 PM, Severin Gehwolf wrote:
> Here is a partial implementation of the Zero bits. In fact, the code
> was already there to handle other getters too. I don't know why it was
> guarded with those asserts and with is_simple_accessor().
> 
> It does not yet implement the setter logic, but at least we don't have
> to keep is_simple_accessor() around. The patch builds on top of your
> latest 8140650/webrev.02/ webrev.
> 
> The patch I'm talking about is:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8140650/JDK-8140650-is_accessor_zero_cleanup.hotspot.patch

Excellent, thanks! Incorporated:
  http://cr.openjdk.java.net/~shade/8140650/webrev.03/

Coleen, are you still good with these changes?

The RBT tests (hotspot_all, vm.{gc|regression|runtime}.testlist, and
some others) came clean for a previous version, and this version touches
only Zero code, so I am inclined to think this change does not need
re-testing.

Thanks,
-Aleksey


From gerard.ziemski at oracle.com  Mon Nov  9 18:59:34 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Mon, 9 Nov 2015 12:59:34 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563FDA39.5040206@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<563FDA39.5040206@oracle.com>
Message-ID: <5640ED16.6020402@oracle.com>

hi David,

Thank you for the review. Please see my answers in-line:

On 11/08/2015 05:26 PM, David Holmes wrote:
> Hi Gerard,
>
> Sorry, I don't like the way all the metaspaceshared internal logistical calculations are now exposed in globals.hpp. Can
> we not keep those calculations internal to the metaspace code and just export the resulting minimum and default values?

I was afraid I would make a circular dependency by putting those defaults in metaspace code, but I forgot that the range 
macros get expanded in commandLineFlagRangeList.cpp, and not in the globals.hpp, so this is in fact doable - fixed.


> I'm also unclear where your max values are coming from.

Ah, thank you very much for asking. I hope I got this right - the max values come from the following piece of code in 
compacthashtable.cpp, CompactHashtableWriter::dump_backets(), line 139:

assert(max_delta <= 0x7FFFFFFF)

where max_delta is "reserved space" size, which I read to be the max memory that can be reserved to hold ALL of
SharedMiscCode, SharedMiscData, SharedReadOnly and SharedReadWrite sections together. Which is why the individual sizes 
of each sections are 0x7FFFFFFF-(total default sizes of the other 3 sections)

Did I get this right?


> On 7/11/2015 7:33 AM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>
>> - Fix comments and indentation
>> - Add "-XShare:dump" while testing Shared* flags
>
> When dumping during testing you need to specify a specific shared archive file name (-XX:SharedArchiveFile=... IIRC)
> otherwise you will be creating the archive in the location of the JVM under test and potentially impact later tests.

Fixed.


I will work on rev2 after testing shortly.


cheers


> Thanks,
> David
>
>> - Temporarily disable testing of SharedMiscDataSize as with current min
>> default it exits the VM with code 2 (which is allowed by the JEP, but
>> not the test framework). This issue is tracked by JDK-8141650
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>
>>
>>
>> cheers
>>
>>
>>
>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this final fix for JEP-245
>>>
>>> We implement the remaining runtime flags in the Shared* family.
>>>
>>> Summary of changes:
>>>
>>> #1 core fix - we factor out the constants to be used in the ranges
>>>
>>> src/share/vm/classfile/compactHashtable.cpp
>>> src/share/vm/memory/metaspace.cpp
>>> src/share/vm/memory/metaspaceShared.hpp
>>> src/share/vm/runtime/globals.hpp
>>>
>>>
>>> #2 we increase default sizes of range and constraint tables to
>>> minimize mallocs
>>>
>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>
>>>
>>> #3 we fix a bug that I run into the OptionsValidation test framework
>>> while working
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>
>>>
>>>
>>> #4 we add functionality to OptionsValidation test framework that we
>>> later use
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>
>>>
>>>
>>> #5 we cleanup and extend the existing test to detect a case where we
>>> get out of range value
>>>
>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>
>>>
>>> The fix passes RBT
>>> "hotspot/test/:hotspot_all,testlist,noncolo.testlist
>>> --add-tonga-keyword quick? and JPRT ?hotspot" tests
>>>
>>> References:
>>>
>>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>
>>>
>>> hg_stat:
>>>
>>>
>>> src/share/vm/classfile/compactHashtable.cpp
>>> |    2 +-
>>>
>>> src/share/vm/memory/metaspace.cpp
>>> |   30 --
>>>
>>> src/share/vm/memory/metaspaceShared.hpp
>>> |   19 +-
>>>
>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>> |    2 +-
>>>
>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>> |    2 +-
>>>
>>> src/share/vm/runtime/globals.hpp
>>> |   63 +++++-
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>> |    4 +-
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>> |   81 +++++++
>>>
>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>> |  180 +++++++++-------
>>>   9 files changed, 242 insertions(+), 141 deletions(-)
>

From vladimir.x.ivanov at oracle.com  Mon Nov  9 19:16:35 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 9 Nov 2015 22:16:35 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <5640EB3D.4010302@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
	<1447091852.3551.36.camel@redhat.com> <5640EB3D.4010302@oracle.com>
Message-ID: <5640F113.6040101@oracle.com>

Still looks good.

Best regards,
Vladimir Ivanov

On 11/9/15 9:51 PM, Aleksey Shipilev wrote:
> Hi Severin,
>
> On 11/09/2015 08:57 PM, Severin Gehwolf wrote:
>> Here is a partial implementation of the Zero bits. In fact, the code
>> was already there to handle other getters too. I don't know why it was
>> guarded with those asserts and with is_simple_accessor().
>>
>> It does not yet implement the setter logic, but at least we don't have
>> to keep is_simple_accessor() around. The patch builds on top of your
>> latest 8140650/webrev.02/ webrev.
>>
>> The patch I'm talking about is:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8140650/JDK-8140650-is_accessor_zero_cleanup.hotspot.patch
>
> Excellent, thanks! Incorporated:
>    http://cr.openjdk.java.net/~shade/8140650/webrev.03/
>
> Coleen, are you still good with these changes?
>
> The RBT tests (hotspot_all, vm.{gc|regression|runtime}.testlist, and
> some others) came clean for a previous version, and this version touches
> only Zero code, so I am inclined to think this change does not need
> re-testing.
>
> Thanks,
> -Aleksey
>

From christian.thalinger at oracle.com  Mon Nov  9 19:46:38 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 9 Nov 2015 09:46:38 -1000
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <563BC171.7050703@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
Message-ID: <016FC905-BEFA-44B8-B610-938890D1F783@oracle.com>


> On Nov 5, 2015, at 10:52 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> Thanks for the review, Coleen!
> 
> I'll wait for RBT results to come in, and if they are positive, I'll
> push (I think through hs-comp, since it affects compilers mostly).
> 
> TODO in interpreter.cpp serves as the anchor for the upcoming Zero RFE.

Was one filed?

> 
> Cheers,
> -Aleksey
> 
> On 11/05/2015 11:42 PM, Coleen Phillimore wrote:
>> 
>> Our emails crossed.   This change looks good.  I don't know how
>> necessary the Zero TODO is but the comment is fine.
>> 
>> Coleen
>> 
>> On 11/5/15 3:16 PM, Aleksey Shipilev wrote:
>>> Ah, no, the CallNode::may_modify polls is_accessor only for boxed
>>> instances, so there are no setters in Java code. Still, we should check
>>> for getters there explicitly, and the getter/setter split is sensible in
>>> Method API anyhow.
>>> 
>>> New webrev:
>>>   http://cr.openjdk.java.net/~shade/8140650/webrev.02/
>>> 
>>> Re-spinning RBT for sanity.
>>> 
>>> Thanks,
>>> -Aleksey
>>> 
>>> On 11/05/2015 10:45 PM, Aleksey Shipilev wrote:
>>>> Thanks, Coleen!
>>>> 
>>>> The tricky part is that compilers poll Method::is_accessor via:
>>>> 
>>>>  bool ciMethod::is_accessor    () const {
>>>>    FETCH_FLAG_FROM_VM(is_accessor);
>>>>  }
>>>> 
>>>> #define FETCH_FLAG_FROM_VM(flag_accessor) { \
>>>>   check_is_loaded(); \
>>>>   VM_ENTRY_MARK; \
>>>>   return get_Method()->flag_accessor(); \
>>>> }
>>>> 
>>>> ...which may be opaque for IDEs, when you look for usages. I found that
>>>> a text search for "is_accessor" yields only positive matches.
>>>> 
>>>> *Actually*, now that I read the code again, there is a suspicious use in
>>>> CallNode::may_modify:
>>>> 
>>>>       if (meth->is_accessor()) {
>>>>         return false;
>>>>       }
>>>> 
>>>> This seems to break if is_accessor accepts setters. Let me split the
>>>> is_accessor into is_getter/is_setter and re-run tests. If you spot other
>>>> problems in the patch, let me know.
>>>> 
>>>> Thanks,
>>>> -Aleksey
>>>> 
>>>> On 11/05/2015 08:34 PM, Coleen Phillimore wrote:
>>>>> I am planning on reviewing this but I haven't had time.  And I'm trying
>>>>> to build Zero for a different reason.  I would be pretty unhappy if it
>>>>> broke Zero and would like it to not do that.  I haven't had a chance to
>>>>> read all of this yet.  I thought is_accessor was only for Zero so I
>>>>> guess I have to read more why this is getting changed.  I will try to
>>>>> get to it today.
>>>>> 
>>>>> Thanks,
>>>>> Coleen
>>>>> 
>>>>> On 11/5/15 12:24 PM, Aleksey Shipilev wrote:
>>>>>> On 11/05/2015 07:59 PM, Vladimir Ivanov wrote:
>>>>>>>>> If there's an RFE filed and Zero maintainers promise to fix it in a
>>>>>>>>> prompt manner, I'm fine with what you proposed.
>>>>>>>> Yeah, that's the plan.
>>>>>>>> 
>>>>>>>>> Also, I had an idea: why don't you move is_simple_accessor() from
>>>>>>>>> Method
>>>>>>>>> to some Zero-specific location? I don't see any value in keeping
>>>>>>>>> it in
>>>>>>>>> Method.
>>>>>>>> That's an interesting trick, but I think it will cause more harm:
>>>>>>>> shared
>>>>>>>> interpreter.cpp would have to know about that Zero-specific
>>>>>>>> method, or
>>>>>>>> otherwise intercept "too wide" accessor shape and narrow it down
>>>>>>>> before
>>>>>>>> it reaches Zero. Therefore, I believe is_simple_accessor is the
>>>>>>>> lesser
>>>>>>>> evil.
>>>>>>> Ok. Looks good then.
>>>>>> Thanks for taking time to review, Vladimir! I'll count that as the
>>>>>> review from the compiler side.
>>>>>> 
>>>>>> I think we still need a review from the runtime side. Folks? For the
>>>>>> record, we are discussing this change:
>>>>>>    http://cr.openjdk.java.net/~shade/8140650/webrev.01/
>>>>>> 
>>>>>> The patch passes JPRT, RBT (hotspot_all), and the new regression test.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Aleksey
>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
> 
> 


From aleksey.shipilev at oracle.com  Mon Nov  9 19:51:37 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 9 Nov 2015 22:51:37 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <016FC905-BEFA-44B8-B610-938890D1F783@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
	<016FC905-BEFA-44B8-B610-938890D1F783@oracle.com>
Message-ID: <5640F949.4020201@oracle.com>

On 11/09/2015 10:46 PM, Christian Thalinger wrote:
> 
>> On Nov 5, 2015, at 10:52 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>
>> Thanks for the review, Coleen!
>>
>> I'll wait for RBT results to come in, and if they are positive, I'll
>> push (I think through hs-comp, since it affects compilers mostly).
>>
>> TODO in interpreter.cpp serves as the anchor for the upcoming Zero RFE.
> 
> Was one filed?

One part of Zero work is already incorporated in webrev.03, which got
rid of is_simple_accessor, and used is_setter, which is already much
cleaner:
 http://cr.openjdk.java.net/~shade/8140650/webrev.03/

I'll submit a Zero RFE to support setters there, once webrev.03 lands.

Thanks,
-Aleksey


From coleen.phillimore at oracle.com  Mon Nov  9 20:28:24 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 09 Nov 2015 15:28:24 -0500
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <5640EB3D.4010302@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
	<1447091852.3551.36.camel@redhat.com> <5640EB3D.4010302@oracle.com>
Message-ID: <564101E8.8080403@oracle.com>



On 11/9/15 1:51 PM, Aleksey Shipilev wrote:
> Hi Severin,
>
> On 11/09/2015 08:57 PM, Severin Gehwolf wrote:
>> Here is a partial implementation of the Zero bits. In fact, the code
>> was already there to handle other getters too. I don't know why it was
>> guarded with those asserts and with is_simple_accessor().
>>
>> It does not yet implement the setter logic, but at least we don't have
>> to keep is_simple_accessor() around. The patch builds on top of your
>> latest 8140650/webrev.02/ webrev.
>>
>> The patch I'm talking about is:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8140650/JDK-8140650-is_accessor_zero_cleanup.hotspot.patch
> Excellent, thanks! Incorporated:
>    http://cr.openjdk.java.net/~shade/8140650/webrev.03/
>
> Coleen, are you still good with these changes?

Yes, this looks fine.

I can't see how there's any value performance-wise to implement the 
is_setter entry point in Zero, that would be worth writing the code for 
the setter entry point.

Coleen
>
> The RBT tests (hotspot_all, vm.{gc|regression|runtime}.testlist, and
> some others) came clean for a previous version, and this version touches
> only Zero code, so I am inclined to think this change does not need
> re-testing.
>
> Thanks,
> -Aleksey
>


From kim.barrett at oracle.com  Mon Nov  9 20:34:38 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Nov 2015 15:34:38 -0500
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <572CF48F-AB96-4E64-8D94-62CC719D40E8@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
	<5E8086F9-871B-4C4F-B766-75EF1CB17D2B@oracle.com>
	<49E590F6-9253-428A-9BF0-DE168238C21F@oracle.com>
	<572CF48F-AB96-4E64-8D94-62CC719D40E8@oracle.com>
Message-ID: <7F426FB7-7555-4572-8AD0-7EDBF9915EF6@oracle.com>

On Nov 9, 2015, at 12:36 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Nov 7, 2015, at 10:58 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> On Nov 6, 2015, at 5:21 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>> 
>>>> On Nov 6, 2015, at 12:09 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> 
>>>> [Sending to hotspot-dev because this touches runtime and compiler
>>>> files too. I'm particularly looking for a compiler person for the
>>>> change to HotSpotVMConfig.java.]
>>> 
>>> Yes, that change looks good.
>> 
>> Thanks!  I wasn?t getting anywhere trying to figure out what might be impacted by that change.
> 
> It?s really not that complicated.  A HotSpotVMField annotation reads a property specified by ?get? for a C++ field with the name ?name? with the type ?type?.  In this case:
> 
> +    @HotSpotVMField(name = "JavaThread::_satb_mark_queue", type = "SATBMarkQueue", get = HotSpotVMField.Type.OFFSET) @Stable public int javaThreadSatbMarkQueueOffset;
> 
> it is reading the offset of the field JavaThread::_satb_mark_queue.  The type is only used for verification.

Thanks for the explanation.  I only occasionally pretend to be a Java programmer, and haven?t studied up on annotations yet.


From coleen.phillimore at oracle.com  Mon Nov  9 20:35:31 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 09 Nov 2015 15:35:31 -0500
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod
	is not MT safe
In-Reply-To: <563CA533.601@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
Message-ID: <56410393.6050400@oracle.com>



On 11/6/15 8:03 AM, Vladimir Ivanov wrote:
> Thanks, Coleen!
>
> Updated version:
>   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.02/
>
>> I think DependencyContext is big enough to be a new file, and not be
>> added to instanceKlass.hpp.  There are too many unrelated things in
>> instanceKlass.
> Agree. Moved it to src/share/vm/code/dependencyContext.[ch]pp

I like this!!
>
>> The hidden bit stuff is ok in InstanceKlass.  Does
>> has_unloaded_dependent accessed concurrently like
>> _is_marked_dependent?
> Good point. DependencyContext::remove_dependent_nmethod should set 
> has_stale_entries in a thread safe manner (added Atomic::xchg_ptr call).
> It is not needed when the flag is cleared.
>
>> It would be nice to move _is_marked_dependent
>> field also to encapsulate it but that would ruin your bit packing.
> There's a spare bit to use, but I think _is_marked_dependent is 
> specific to InstanceKlass and should remain there. It doesn't have any 
> meaning for CallSite dependencies.
>
>> Also, since you have changes to vmStructs, do you have duplicate changes
>> to make to the serviceability agent code?  Are there duplicate changes
>> for the jvmci code?
> I haven't found any mentions of _has_unloaded_dependent or 
> _dependencies fields in SA or JVMCI code. Do you think it is an 
> overlook on SA side and I should add it?

If it's not int he SA or JVMCI code, I think it can just be removed from 
vmStructs.cpp (or not added).   There used to be some nsk.sajdi.testlist 
tests that are quarantined but you can run them to make sure.

http://cr.openjdk.java.net/~vlivanov/8139595/webrev.02/src/share/vm/code/dependencyContext.hpp.html

This file uses CHeapObj<mtClass> but doesn't include allocation.hpp.   
Does it compile without precompiled headers?

Thanks,
Coleen

>
> Best regards,
> Vladimir Ivanov
>
>>
>> Thanks,
>> Coleen
>>
>> On 11/5/15 1:54 PM, Vladimir Ivanov wrote:
>>> Updated version:
>>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/
>>>
>>> In addition to name polishing and encapsulating purging logic in
>>> {add|remove}_dependent_nmethod methods, I got rid of
>>> DependencyContext::wipe() method and added "friend class
>>> TestDependencyContext" declaration (noticed such practice in other
>>> cases when tests need access to tested class internals).
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
>>>> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>>>>> Regarding internal purging, add_dependent_methods doesn't iterate 
>>>>> over
>>>>> the whole list, but looks for the relevant entry. It means that 
>>>>> "purge"
>>>>> flag should force full iteration. I think that keeping them 
>>>>> separately
>>>>> (add_dependent_methods() vs purge()) looks cleaner.
>>>>
>>>> I think it is better to encapsulate the "piggybacking" behavior within
>>>> the DependencyContext itself, because that seems to be a
>>>> general/expected feature of DependencyContext class. It is weird to 
>>>> ask
>>>> class users to spell it out specifically.
>>>>
>>>>
>>>>> I could add "purge" flag and move the following code into
>>>>> add_dependent_methods:
>>>>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool
>>>>> do_purge
>>>>> = false) {
>>>>>     ...
>>>>>     if (has_unloaded_dependent() && do_purge) {
>>>>>       purge();
>>>>>     }
>>>>> }
>>>>>
>>>>> Is it what you are suggesting?
>>>>
>>>> Yes.
>>>>
>>>>
>>>>>>    * DependencyContext now has three methods: purge(), clear(),
>>>>>> wipe(). I
>>>>>> have trouble understanding which method does what!
>>>>
>>>>> There are basically 2 operations needed:
>>>>>    * purge(): only remove stale entries; no additional work is
>>>>> performed;
>>>>
>>>> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>>>>   WeakHashMap.expungeStaleEntries()
>>>>   ThreadLocal.expungeStaleEntries()
>>>>   WeakCache.expungeStaleEntries()
>>>>
>>>>
>>>>> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
>>>>> just deallocates all nmethodBucket entries without touching
>>>>> nmethods. It
>>>>> is necessary since nmethod pointers are faked by the test.
>>>>
>>>> Okay. Is there a convention how you should name the test-related 
>>>> methods
>>>> like these? I would expect something like debug_deallocate_buckets().
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>>>
>>


From kim.barrett at oracle.com  Mon Nov  9 20:36:06 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Nov 2015 15:36:06 -0500
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <1447061955.2280.5.camel@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
	<1447061955.2280.5.camel@oracle.com>
Message-ID: <7047BD95-2496-4BE2-B551-95E22EE441E5@oracle.com>

On Nov 9, 2015, at 4:39 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> On Fri, 2015-11-06 at 17:09 -0500, Kim Barrett wrote:
>> [Sending to hotspot-dev because this touches runtime and compiler
>> files too. I'm particularly looking for a compiler person for the
>> change to HotSpotVMConfig.java.]
>> 
>> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
>> cleanup is being done in preparation for some further changes that
>> will make the name more widely used.
>> 
>> Probably the satbQueue.[ch]pp files should be renamed to
>> satbMarkQueue.[ch]pp.  I've not made such a change because my
>> understanding is that mercurial mq doesn't really understand file
>> renames.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8077571
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
>> 
>> Testing:
>> JPRT
>> 
> 
>  looks good to me. Just rename the files, mercurial understands
> renames.

Thanks, Thomas.

Yes, more reading about mq and I understand now?

I?ll take care of the rename too, as you and Bengt requested.


From kim.barrett at oracle.com  Mon Nov  9 20:37:07 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Nov 2015 15:37:07 -0500
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <563F3EBD.9070707@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
	<563F3EBD.9070707@oracle.com>
Message-ID: <E5F64440-76A7-4C0C-9CE9-D9FCCDD183F5@oracle.com>

On Nov 8, 2015, at 7:23 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8077571
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
> 
> Except for the renaming of the files I think it looks good. I don't need to see an updated webrev for the file rename.
> 
> Reviewed.

Thanks Bengt.  I?ll do the file rename.


From kim.barrett at oracle.com  Mon Nov  9 20:37:30 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Nov 2015 15:37:30 -0500
Subject: RFR: 8077571: ObjPtrQueue is poorly named
In-Reply-To: <563FE0D1.20308@oracle.com>
References: <6BDFF86B-8D36-475D-A7D0-D38673640462@oracle.com>
	<563FE0D1.20308@oracle.com>
Message-ID: <443B0E09-06A1-420F-8B2D-17039E5CC4CD@oracle.com>

On Nov 8, 2015, at 6:54 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,
> 
> runtime changes look fine.

Thanks, David.

> 
> Thanks,
> David
> 
> On 7/11/2015 8:09 AM, Kim Barrett wrote:
>> [Sending to hotspot-dev because this touches runtime and compiler
>> files too. I'm particularly looking for a compiler person for the
>> change to HotSpotVMConfig.java.]
>> 
>> Please review this rename of ObjPtrQueue to SATBMarkQueue.  This
>> cleanup is being done in preparation for some further changes that
>> will make the name more widely used.
>> 
>> Probably the satbQueue.[ch]pp files should be renamed to
>> satbMarkQueue.[ch]pp.  I've not made such a change because my
>> understanding is that mercurial mq doesn't really understand file
>> renames.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8077571
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8077571/webrev.00/
>> 
>> Testing:
>> JPRT



From goetz.lindenmaier at sap.com  Mon Nov  9 20:41:14 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Nov 2015 20:41:14 +0000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <798CDB11-5DEA-40AF-8AEA-AC2001546A85@oracle.com>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
	<811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>
	<798CDB11-5DEA-40AF-8AEA-AC2001546A85@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41EB6207@DEWDFEMB12A.global.corp.sap>

Hi Christian,

The function implementation is protected by #ifdef ASSERT, and the call is protected by #ifndef PRODUCT.
Without this NOT_DEBUG_RETURN it would not compile in the optimized build.
Another possibility to fix this is checking for #ifndef PRODUCT in memset_with_concurrent_readers.cpp.
Looking at it now, it must have been broken before.

Best regards,
  Goetz.



From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Monday, November 09, 2015 6:06 PM
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: hotspot-dev at openjdk.java.net; Stefan Karlsson <stefan.karlsson at oracle.com>
Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds

I did verify that our compilers are in fact eliminating all code and Stefan Karlsson made sure some important GC functions still produce the same code.

On Nov 8, 2015, at 9:40 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:

Hi Christian,

thanks for incorporating these cleanups.
The change still looks good ?.

Best regards,
  Goetz.

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Freitag, 6. November 2015 18:13
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds


On Nov 6, 2015, at 1:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:

Hi Christian,

thanks for doing this change.  It looks good.

It's good that now notproduct flags are also defined in the product build as constants,
as it's already the case with debug flags.
This allows more cleanups in the style you did to compilerDirectives.hpp.

I had a look at these cleanups, quite a row you can find in this patch:
http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch

That is a very nice cleanup.




Does it make sense to commit these along with your change?

It does.  I?ve updated my webrev with your changes:

http://cr.openjdk.java.net/~twisti/8140424/webrev/




Best regards,
 Goetz.





-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
Behalf Of Christian Thalinger
Sent: Freitag, 6. November 2015 07:23
To: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
variables with CONST_ in product builds

https://bugs.openjdk.java.net/browse/JDK-8140424
<https://bugs.openjdk.java.net/browse/JDK-8140424>
http://cr.openjdk.java.net/~twisti/8140424/webrev/
<http://cr.openjdk.java.net/~twisti/8140424/webrev/>

When working on JDK-8024545 I added code that prefixes developer and
notproduct flags with CONST_. I think I did this to be able to access the
address of these variables for the flag table. But this is not necessary because
these flag cannot be written anyway.

I am proposing to remove the CONST_ prefix and define the variables as
const.


From christian.thalinger at oracle.com  Mon Nov  9 21:31:30 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 9 Nov 2015 11:31:30 -1000
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <5640F949.4020201@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
	<016FC905-BEFA-44B8-B610-938890D1F783@oracle.com>
	<5640F949.4020201@oracle.com>
Message-ID: <A7E042CD-035D-462B-A3F2-2A6B5F217EA4@oracle.com>


> On Nov 9, 2015, at 9:51 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> On 11/09/2015 10:46 PM, Christian Thalinger wrote:
>> 
>>> On Nov 5, 2015, at 10:52 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>> 
>>> Thanks for the review, Coleen!
>>> 
>>> I'll wait for RBT results to come in, and if they are positive, I'll
>>> push (I think through hs-comp, since it affects compilers mostly).
>>> 
>>> TODO in interpreter.cpp serves as the anchor for the upcoming Zero RFE.
>> 
>> Was one filed?
> 
> One part of Zero work is already incorporated in webrev.03, which got
> rid of is_simple_accessor, and used is_setter, which is already much
> cleaner:
> http://cr.openjdk.java.net/~shade/8140650/webrev.03/
> 
> I'll submit a Zero RFE to support setters there, once webrev.03 lands.

Thanks.

> 
> Thanks,
> -Aleksey
> 


From coleen.phillimore at oracle.com  Mon Nov  9 22:24:42 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 09 Nov 2015 17:24:42 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <1447073484.3551.30.camel@redhat.com>
References: <563C036A.3050008@oracle.com>	
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com>
Message-ID: <56411D2A.3030701@oracle.com>


Thanks for looking at this.  I had a lot of trouble getting an 
environment where I could get zero to build, and it these happened to be 
the things I needed to do to compile it.  I use 
--disable-precompiled-headers by default.

On 11/9/15 7:51 AM, Severin Gehwolf wrote:
> On Fri, 2015-11-06 at 11:47 -0500, Kim Barrett wrote:
>> On Nov 5, 2015, at 8:33 PM, Coleen Phillimore <coleen.phillimore at orac
>> le.com> wrote:
>>> With the RedHat compiler that I'm using g++ (GCC) 4.8.2 20140120
>>> (Red Hat 4.8.2-16)
>>> these additional includes are needed to compile without precompiled
>>> headers.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.01/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>>
>>> I'm not sure why allocation.inline.hpp is needed unless the virtual
>>> destructor in src/share/vm/gc/shared/plab.hpp PLABStats implicitly
>>> calls delete.
>>>
>>> Tested with compiles of Zero plus plain linux
>>> debug/fastdebug/product.
>>>
>>> Thanks,
>>> Coleen
>> src/share/vm/gc/g1/g1EvacStats.hpp
>>    29 #include "memory/allocation.inline.hpp"
>>    30 #include "runtime/atomic.inline.hpp"
>>
>> xxx.inline.hpp files are not supposed to be included by xxx.hpp
>> files.
>>
>> The need for atomic.inline.hpp seems clear, and would seem to
>> constitute a bug in
>> g1EvacStats.hpp - there should be a g1EvacStats.inline.hpp file.

I filed bug

https://bugs.openjdk.java.net/browse/JDK-8142354
>>
>> I really don?t understand why allocation.inline.hpp is needed here at
>> all.
> FWIW, the below hunk seems to be all that's necessary in order to fix
> the --disable-precompiled-headers Zero build for me:
>
> diff --git a/src/share/vm/runtime/java.cpp b/src/share/vm/runtime/java.cpp
> --- a/src/share/vm/runtime/java.cpp
> +++ b/src/share/vm/runtime/java.cpp
> @@ -49,6 +49,7 @@
>   #include "runtime/arguments.hpp"
>   #include "runtime/biasedLocking.hpp"
>   #include "runtime/compilationPolicy.hpp"
> +#include "runtime/deoptimization.hpp"
>   #include "runtime/fprofiler.hpp"
>   #include "runtime/init.hpp"
>   #include "runtime/interfaceSupport.hpp"
>
> It does not seem the other change is required. Tested with fastdebug
> build of Zero with --disable-precompiled-headers that failed to build
> without and built fine with the fix.

I could check in just the deoptimization.hpp change and build only 
fastdebug until the other bug is fixed.

>
> Coleen, do you have details about the failure which gets supposedly
> fixed by the other hunk?

The only thing I have is the g++ compilation failures without these 
changes.  The one that was fixed by including allocation.inline.hpp was:

Building target 'images' in configuration 'linux-x86_64-normal-zero-release'
g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
/home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacStats.hpp:32: 
undefined reference to `CHeapObj<(MemoryType)5>::operator delete(void*)'
collect2: error: ld returned 1 exit status

Since the destructor is complaining about the missing delete operator, I 
assume this compiler has the sort of destructor that implicitly can also 
call delete.  I don't have any other information or ideas really why 
this fails to compile.

Coleen


>
> Also the original build failure this patch is supposed to fix now got
> picked up by our builders too:
> http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero_no_pch/37
>
> Cheers,
> Severin


From david.holmes at oracle.com  Mon Nov  9 23:55:19 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Nov 2015 09:55:19 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563FD29A.3060103@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
	<563C5B5B.9060802@oracle.com>
	<CAPYFHW3OJ2rUMrHFY4CiCPpVMfhZ=TSMrBwDsxX9kgnMLnL00w@mail.gmail.com>
	<563FD29A.3060103@oracle.com>
Message-ID: <56413267.6000001@oracle.com>

On 9/11/2015 8:54 AM, David Holmes wrote:
> On 7/11/2015 11:22 AM, Jeremy Manson wrote:
>>
>>
>> On Thu, Nov 5, 2015 at 11:48 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 6/11/2015 4:55 PM, Jeremy Manson wrote:
>>
>>         FWIW, Google tried to convince the glibc maintainers to make this
>>         async-safe, but they weren't biting:
>>
>>         https://sourceware.org/ml/libc-alpha/2014-01/msg00033.html
>>
>>
>>     Yes I read all that. I wouldn't say they weren't biting, more of a
>>     disagreement on the right direction for the patch. glibc weren't
>>     prepared to take it directly as is, while google-folk didn't seem to
>>     think it worth their while to do whatever glibc folk wanted. The
>>     actual patch proposal just died out. :( Quite a pity.
>>
>>         Most of the things you can do are going to be mitigation rather
>>         than a
>>         fix.  I did what you suggest to mitigate, and no one complained,
>>         until
>>         someone at Google started a sidecar C++ thread that did a
>>         boatload of
>>         malloc'ing.
>>
>>
>>     Yes all mitigation. :(
>>
>>         My workaround was far sneakier, and fixes the problem entirely,
>>         but you
>>         probably won't want to do it for code hygiene reasons.  I
>>         declare the
>>         __thread variable in the java launcher itself, and then export a
>>         function that provides a pointer to it.  In practice, in glibc,
>>         if it is
>>         in the main executable, ELF is smart enough to declare it as
>>         part of the
>>         stack, and is therefore async-safe.
>>
>>
>>     But even that only works for our own launchers - not for embedded in
>>     the JVM. :(
>>
>>
>> Yup.  Fortunately, I can tell people at Google how to write launchers.
>>
>>         Fortunately, while this is a fun thing to think about, I don't
>> think
>>         there are any async paths in the JVM that use Thread::current()
>>         (although I could be wrong - there is a comment in there saying
>>         not to
>>         call Thread::current() in a signal handler...).  I would check
>>         the call
>>         paths in AsyncGetCallTrace to make sure.
>>
>>
>>     So two things ...
>>
>>     First, using Thread::current() in a signal context was disallowed,
>>     but the alternative was ThreadLocalStorage::get_thread_slow(). The
>>     former may not work in a signal context due to the caching
>>     mechanisms layered in on different platforms, while the latter used
>>     the platform TLS API which, even if not guaranteed, worked well
>>     enough in a signal context. With __thread we don't have even a
>>     pretend signal-safe alternative :(
>>
>>
>> Right.
>>
>>     Second, AsyncGetCallTrace violates the first rule by using
>>     JavaThread::current() in an assertion.
>>
>>
>> While we're on the subject, the assertion in Method::bci_from is
>> reachable from AsyncGetCallTrace and calls err_msg, which can malloc().
>> I meant to file a bug about that.
>>
>>     Also, the problem may not be limited to something like
>>     AsyncGetCallTrace. Though agents may get the current thread from the
>>     JNIEnv rather than invoking some JVM function that results in
>>     Thread::current() being used, I can't be sure of that.
>>
>>
>> Which JVM functions that get the thread are supposed to be async-safe?
>> There is no reason to think that any method that isn't explicitly marked
>> async-safe is async safe, and most JNI methods I've tried to use from
>> signal handlers die painfully if I try to use them from a signal handler.
>>
>> Generally, I don't think it is reasonable for a user to expect
>> async-safety from an API that isn't expressly designed that way.  POSIX
>> has a list of async-safe methods (signal(7)).
>
> Right - no JNI or JVM TI functions are designated as async-signal-safe
> (the specs dont even mention signals).
>
> Unfortunately my problem is more basic: pretty much the first thing the
> JVM signal handler does is get the current thread. So if the signal is
> handled on an unattached thread that happened to be doing a malloc then
> we're toast. :( Most of the signals the JVM expects to handle are not
> blocked by default, AFAICS, so any unattached thread could be selected.

Just to keep my thinking straight on this, the problem only exists for 
threads that existed before the JVM was loaded. All threads allocated 
after that will have space for all the TLS variables allocated directly. 
So the problem scenario is:

- external process with existing threads loads the JVM
- existing thread is executing critical library function eg malloc, when 
it takes a process-directed signal.
- JVM signal handler runs and accesses _thr_current which triggers 
dynamic TLS allocation

David
-----

> David
> -----
>
>
>> FWIW, to use AsyncGetCallTrace, I get the JNIEnv in a ThreadStart hook
>> from JVMTI and stash it in a __thread (and pull the trick I mentioned).
>> Jeremy
>>
>>
>>     Anyway more things to mull over on the weekedn. :)
>>
>>     Thanks,
>>     David
>>
>>         Jeremy
>>
>>         On Thu, Nov 5, 2015 at 10:26 PM, David Holmes
>>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>         <mailto:david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>>> wrote:
>>
>>              Hi Jeremy,
>>
>>              Okay I have read:
>>
>>         https://sourceware.org/glibc/wiki/TLSandSignals
>>
>>              and the tree of mail postings referenced therefrom - great
>>         reading! :)
>>
>>              So basic problem: access to __thread variables is not
>>         async-signal-safe
>>
>>              Exacerbator to problem: first attempt to even read a
>> __thread
>>              variable can lead to allocation which is the real problem in
>>              relation to async-signal-safety
>>
>>              I mention the exacerbator because pthread_getspecific and
>>              pthread_setSpecific are also not async-signal-safe but we
>>         already
>>              use them. However, pthread_getspecific is in fact (per
>>         email threads
>>              linked above) effectively async-signal-safe, and further a
>>         call to
>>              pthread_getspecific never results in a call to
>>         pthread_setspecific
>>              or an allocation. Hence the pthread functions are almost,
>>         if not
>>              completely, safe in practice with reasonable uses (ie only
>>         read from
>>              signal handler). Which explain this code in existing
>>         Thread::current()
>>
>>              #ifdef PARANOID
>>                 // Signal handler should call
>>         ThreadLocalStorage::get_thread_slow()
>>                 Thread* t = ThreadLocalStorage::get_thread_slow();
>>                 assert(t != NULL && !t->is_inside_signal_handler(),
>>                        "Don't use Thread::current() inside signal
>> handler");
>>              #endif
>>
>>              So problem scenario is: use of __thread variable (that
>>         belongs to
>>              the shared-library) in a signal handler.
>>
>>              Solution 0: don't do that. Seriously - like any other
>>              async-signal-unsafe stuff we should not be using it in real
>>         signal
>>              handlers. The crash handler is a different matter - we try
>>         all sorts
>>              there because it might work and you can't die twice.
>>
>>              Otherwise: narrow the window of exposure.
>>
>>              1. We ensure we initialize thread_current (even with a
>>         dummy value)
>>              as early as possible in the thread that loads libjvm. As we
>>         have no
>>              signal handlers installed at that point that might use
>> the same
>>              variable, we can not hit the problem scenario.
>>
>>              2. We ensure we initialize thread_current in a new thread
>>         with all
>>              signals blocked. This again avoids the problem scenario.
>>
>>              3. We initialize thread_current in an attaching thread as
>>         soon as
>>              possible and we again first block all signals.
>>
>>              That still leaves the problem of an unattached native
>>         thread taking
>>              a signal whilst in async-signal-unsafe code, and executing
>>         a signal
>>              handler which in turns tries to access thread_current for
>>         the first
>>              time. This signal handler need not be an actual JVM
>>         handler, but one
>>              attached by other native code eg an agent. I'm not clear
>> in the
>>              latter case how reasonable it is for an agent's handler to
>>         try and
>>              do things from an unattached thread - and we don't claim
>>         any JNI
>>              interfaces can, or should, be called from a signal handler
>>         - but it
>>              is something you can probably get away with today.
>>
>>              Let me also point out that we already effectively have this
>>         code in
>>              Solaris already (at the ThreadLocalStorage class level). So
>>         if there
>>              is something here that will prevent the current proposal we
>>         already
>>              have a problem on Solaris. :(
>>
>>              Thoughts/comments/suggestions?
>>
>>              Thanks,
>>              David
>>
>>
>>              On 6/11/2015 1:09 PM, David Holmes wrote:
>>
>>                  Hi Jeremy,
>>
>>                  I was going to ask you to elaborate :)
>>
>>                  On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>>
>>                      I should probably elaborate on this.  With glibc +
>>         ELF, the
>>                      first time a
>>                      thread accesses a variable declared __thread, if
>> that
>>                      variable is in a
>>                      shared library (as opposed to the main
>> executable), the
>>                      system calls
>>                      malloc() to allocate the space for it.  If that
>>         happens in a
>>                      signal that
>>                      is being delivered during a call to malloc(),
>> then you
>>                      usually get a
>>                      crash.
>>
>>
>>                  My understanding of the ELF ABI for thread-locals -
>>         which I read
>>                  about
>>                  in the Solaris 11.1 Linkers and libraries guide - does
>>         require
>>                  use of
>>                  the dynamic TLS model for any dynamically loaded shared
>>         object which
>>                  defines a thread-local, but that is what we use as I
>>         understand
>>                  it. The
>>                  docs state:
>>
>>                  "A shared object containing only dynamic TLS can be
>>         loaded following
>>                  process startup without limitations. The runtime linker
>>         extends
>>                  the list
>>                  of initialization records to include the initialization
>>         template
>>                  of the
>>                  new object. The new object is given an index of m = M +
>>         1. The
>>                  counter M is incremented by 1. However, the allocation
>>         of new
>>                  TLS blocks
>>                  is deferred until the blocks are actually referenced."
>>
>>                  Now I guess "extends the list" might be implemented
>>         using malloc
>>                  ... but
>>                  this will only occur in the main thread (the one
>>         started by the
>>                  launcher
>>                  to load the JVM and become the main thread), at the
>>         time libjvm is
>>                  loaded - which will all be over before any agent etc
>>         can run and do
>>                  anything. But "allocation ... is deferred" suggests we
>>         may have a
>>                  problem until either the first call to Thread::current
>>         or the
>>                  call to
>>                  Thread::initialize_thread_current. If it is the former
>>         then that
>>                  should
>>                  occur well before any agent etc can be loaded. And I
>>         can easily
>>                  inject
>>                  an initial dummy call to
>> initialize_thread_current(null) to
>>                  force the
>>                  TLS allocation.
>>
>>                      This may bite you if AsyncGetCallTrace uses
>>                      Thread::current(), and you
>>                      use system timers to do profiling.  If a thread
>> doing a
>>                      malloc() prior
>>                      to the first time it accesses Thread::current(),
>>         and it gets
>>                      delivered a
>>                      signal, it might die.  This is especially likely
>>         for pure
>>                      native threads
>>                      started by native code.
>>
>>                      I believe that this is a use case you support, so
>>         you might
>>                      want to make
>>                      sure it is okay.
>>
>>
>>                  For a VM embedded in a process, which already contains
>>         native
>>                  threads,
>>                  that will later attach to the VM, this may indeed be a
>>         problem. One
>>                  would have hoped however that the implementation of TLS
>>         would be
>>                  completely robust, at least for something as simple as
>>         getting a
>>                  signal
>>                  whilst in the allocator.
>>
>>                  I'm unclear how to test for or check for this kind of
>>         problem.
>>                  Arguably
>>                  there could be many things that are async-unsafe in
>>         this way.
>>
>>                  Need to think more about this and do some more
>>         research. Would also
>>                  appreciate any insight from any glibc and/or ELF gurus.
>>
>>                  Thanks.
>>                  David
>>
>>                      Jeremy
>>
>>                      On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>>                      <jeremymanson at google.com
>>         <mailto:jeremymanson at google.com> <mailto:jeremymanson at google.com
>>         <mailto:jeremymanson at google.com>>
>>                      <mailto:jeremymanson at google.com
>>         <mailto:jeremymanson at google.com>
>>                      <mailto:jeremymanson at google.com
>>         <mailto:jeremymanson at google.com>>>> wrote:
>>
>>                           Something that's bitten me with __thread: it
>> isn't
>>                      async-safe when
>>                           called from a shared object on Linux.  Have
>>         you vetted
>>                      to make sure
>>                           this doesn't make HS less async-safe?
>>
>>                           Jeremy
>>
>>                           On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>>                           <david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>
>>                      <mailto:david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>>
>>                      <mailto:david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>
>>
>>                      <mailto:david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>>>> wrote:
>>
>>                               bug:
>>         https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                               Open webrev:
>>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>>                               A simple (in principle) but wide-ranging
>>         change
>>                      which should
>>                               appeal to our Code Deletion Engineer's. We
>>         implement
>>                               Thread::current() using a
>>         compiler/language-based
>>                      thread-local
>>                               variable eg:
>>
>>
>>                                 static __thread Thread *_thr_current;
>>
>>                                 inline Thread* Thread::current() {
>>                                   return _thr_current;
>>                                 }
>>
>>                               with an appropriate setter of course. By
>>         doing this
>>                      we can
>>                               completely remove the platform-specific
>>                      ThreadLocalStorage
>>                               implementations, and the associated
>>                      os::thread_local_storage*
>>                               calls, plus all the uses of
>>                      ThreadLocalStorage::thread() and
>>                               ThreadLocalStorage::get_thread_slow().
>>         This extends
>>                      the previous
>>                               work done on Solaris to implement
>>                      ThreadLocalStorage::thread()
>>                               using compiler-based thread-locals.
>>
>>                               We can also consolidate nearly all the
>> os_cpu
>>                      versions of
>>                               MacroAssembler::get_thread on x86 into
>> one cpu
>>                      specific one ( a
>>                               special variant is still needed for 32-bit
>>         Windows).
>>
>>                               As a result of this change we have further
>>                      potential cleanups:
>>                               - all the
>>         src/os/<os>/vm/thread_<os>.inline.hpp
>>                      files are now
>>                               completely empty and could also be removed
>>                               - the MINIMIZE_RAM_USAGE define (which
>>         avoids use
>>                      of the linux
>>                               sp-map "cache" on 32-bit) now has no
>>         affect and so
>>                      could be
>>                               completely removed from the build system
>>
>>                               I plan to do the MINIMIZE_RAM_USAGE
>>         removal as a
>>                      follow up CR,
>>                               but could add the removal of the "inline"
>>         files to
>>                      this CR if
>>                               people think it worth removing them.
>>
>>                               I have one missing piece on Aarch64 - I
>>         need to change
>>                               MacroAssembler::get_thread to simply call
>>                      Thread::current() as
>>                               on other platforms, but I don't know how
>>         to write
>>                      that. I would
>>                               appreciate it if someone could give me the
>>         right
>>                      code for that.
>>
>>                               I would also appreciate comments/testing
>>         by the AIX
>>                      and PPC64
>>                               folk as well.
>>
>>                               A concern about memory-leaks had
>>         previously been
>>                      raised, but
>>                               experiments using simple C code on linux
>>         86 and
>>                      Solaris showed
>>                               no issues. Also note that Aarch64 already
>>         uses this
>>                      kind of
>>                               thread-local.
>>
>>                               Thanks,
>>                               David
>>
>>
>>
>>
>>

From john.r.rose at oracle.com  Tue Nov 10 02:37:18 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 9 Nov 2015 18:37:18 -0800
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <563CA533.601@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
Message-ID: <FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>

I think this expression occurs too many times:
  DependencyContext dep_context(&_dep_context);

It would look better if factored into an access method:
  inline DependencyContext InstanceKlass::dependencies() {
    DependencyContext dep_context(&_dep_context);
    return dep_context;
  }

That way the raw machine word InstanceKlass::_dep_context can be isolated.
CallSiteContext::vmdependencies already does the corresponding move for CallSite.
(I understand that you don't want to make ik.hpp depend on dc.hpp.
Just put forward declarations of Deps and IK::deps in ik.hpp.)

Mild suggestion:  Add a constructor parameter to capture the base oop (of the callsite, or null for the IK).
Use it only in debug mode to check for GC changes.  Or sample a global GC or safepoint count.
The point is that the lifetime of the Deps object should not extend beyond the next safepoint.

I agree with Coleen:  This is a good refactor.

Reviewed.

? John

On Nov 6, 2015, at 5:03 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Thanks, Coleen!
> 
> Updated version:
>  http://cr.openjdk.java.net/~vlivanov/8139595/webrev.02/
> 
>> I think DependencyContext is big enough to be a new file, and not be
>> added to instanceKlass.hpp.  There are too many unrelated things in
>> instanceKlass.
> Agree. Moved it to src/share/vm/code/dependencyContext.[ch]pp
> 
>> The hidden bit stuff is ok in InstanceKlass.  Does
>> has_unloaded_dependent accessed concurrently like
>> _is_marked_dependent?
> Good point. DependencyContext::remove_dependent_nmethod should set has_stale_entries in a thread safe manner (added Atomic::xchg_ptr call).
> It is not needed when the flag is cleared.
> 
>> It would be nice to move _is_marked_dependent
>> field also to encapsulate it but that would ruin your bit packing.
> There's a spare bit to use, but I think _is_marked_dependent is specific to InstanceKlass and should remain there. It doesn't have any meaning for CallSite dependencies.
> 
>> Also, since you have changes to vmStructs, do you have duplicate changes
>> to make to the serviceability agent code?  Are there duplicate changes
>> for the jvmci code?
> I haven't found any mentions of _has_unloaded_dependent or _dependencies fields in SA or JVMCI code. Do you think it is an overlook on SA side and I should add it?
> 
> Best regards,
> Vladimir Ivanov
> 
>> 
>> Thanks,
>> Coleen
>> 
>> On 11/5/15 1:54 PM, Vladimir Ivanov wrote:
>>> Updated version:
>>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/
>>> 
>>> In addition to name polishing and encapsulating purging logic in
>>> {add|remove}_dependent_nmethod methods, I got rid of
>>> DependencyContext::wipe() method and added "friend class
>>> TestDependencyContext" declaration (noticed such practice in other
>>> cases when tests need access to tested class internals).
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
>>>> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>>>>> Regarding internal purging, add_dependent_methods doesn't iterate over
>>>>> the whole list, but looks for the relevant entry. It means that "purge"
>>>>> flag should force full iteration. I think that keeping them separately
>>>>> (add_dependent_methods() vs purge()) looks cleaner.
>>>> 
>>>> I think it is better to encapsulate the "piggybacking" behavior within
>>>> the DependencyContext itself, because that seems to be a
>>>> general/expected feature of DependencyContext class. It is weird to ask
>>>> class users to spell it out specifically.
>>>> 
>>>> 
>>>>> I could add "purge" flag and move the following code into
>>>>> add_dependent_methods:
>>>>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool
>>>>> do_purge
>>>>> = false) {
>>>>>    ...
>>>>>    if (has_unloaded_dependent() && do_purge) {
>>>>>      purge();
>>>>>    }
>>>>> }
>>>>> 
>>>>> Is it what you are suggesting?
>>>> 
>>>> Yes.
>>>> 
>>>> 
>>>>>>   * DependencyContext now has three methods: purge(), clear(),
>>>>>> wipe(). I
>>>>>> have trouble understanding which method does what!
>>>> 
>>>>> There are basically 2 operations needed:
>>>>>   * purge(): only remove stale entries; no additional work is
>>>>> performed;
>>>> 
>>>> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>>>>  WeakHashMap.expungeStaleEntries()
>>>>  ThreadLocal.expungeStaleEntries()
>>>>  WeakCache.expungeStaleEntries()
>>>> 
>>>> 
>>>>> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
>>>>> just deallocates all nmethodBucket entries without touching
>>>>> nmethods. It
>>>>> is necessary since nmethod pointers are faked by the test.
>>>> 
>>>> Okay. Is there a convention how you should name the test-related methods
>>>> like these? I would expect something like debug_deallocate_buckets().
>>>> 
>>>> Thanks,
>>>> -Aleksey
>>>> 
>>>> 
>> 


From stefan.karlsson at oracle.com  Tue Nov 10 08:39:03 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Nov 2015 09:39:03 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <5640DDE6.1070406@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com> <5640DDE6.1070406@oracle.com>
Message-ID: <5641AD27.6090701@oracle.com>

On 2015-11-09 18:54, Vladimir Kozlov wrote:
> Very nice.

Thanks.

> You may need closed changes too.

You're right.

Thanks.
StefanK

>
> Thanks,
> Vladimir
>
> On 11/9/15 1:34 AM, Stefan Karlsson wrote:
>> Hi Vladimir,
>>
>> What do you think about this version:
>>   http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
>>   http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/
>>
>> Thanks,
>> StefanK
>>
>> On 2015-10-30 09:44, Vladimir Kozlov wrote:
>>> On 10/29/15 11:52 PM, Stefan Karlsson wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 2015-10-27 16:22, Vladimir Kozlov wrote:
>>>>> CodeCache::verify_oops() also calls it unguarded.
>>>>>
>>>>> I think for complete solution nmethod::verify_oop_relocations() and
>>>>> called from it oop_Relocation::verify_oop_relocation(),
>>>>> verify_value(), const_verify_data_value() and pd_verify_data_value()
>>>>> should be declared and defined in debug build only.
>>>>
>>>> I see what you're saying, but I'm unsure that this is really what we
>>>> want to do.
>>>>
>>>> CodeCache::verify_oops is called from the Universe::verify, that 
>>>> can be
>>>> enabled in product builds by setting -XX:+UnlockDiagnosticVMOptions 
>>>> and
>>>> -XX:+VerifyBeforeGC and/or -XX:+VerifyAfterGC. Maybe we want to change
>>>> the relocation code to use guarantees instead of asserts? So that 
>>>> we can
>>>> get verification of the relocation code in product builds?
>>>
>>> Yes, I think it is good suggestion (asserts -> guarantees or fatals) 
>>> in addition to webrev.01.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Thanks,
>>>> StefanK
>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 10/27/15 7:44 PM, Stefan Karlsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this patch to remove some unnecessary verification 
>>>>>> code
>>>>>> from our product builds.
>>>>>>
>>>>>> Today, CodeCache::gc_epilogue() guards the call to
>>>>>> nmethod::verify_oop_relocations with DEBUG_ONLY, while
>>>>>> nmethod::oops_do_marking_epilogue doesn't. Since
>>>>>> nmethod::verify_oop_relocations uses asserts when verifying the
>>>>>> relocations, this is just wasted cycles in product builds. This 
>>>>>> patch
>>>>>> adds DEBUG_ONLY to nmethod::oops_do_marking_epilogue.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~stefank/8140584/webrev.01/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140584
>>>>>>
>>>>>> Thanks,
>>>>>> StefanK
>>>>
>>


From thomas.stuefe at gmail.com  Tue Nov 10 10:20:26 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 10 Nov 2015 11:20:26 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <563D27B8.4040501@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
Message-ID: <CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>

Hi David,

On Fri, Nov 6, 2015 at 11:20 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 6/11/2015 9:52 PM, Thomas St?fe wrote:
>
>> Hi David,
>>
>> On Fri, Nov 6, 2015 at 7:26 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Jeremy,
>>
>>     Okay I have read:
>>
>>     https://sourceware.org/glibc/wiki/TLSandSignals
>>
>>     and the tree of mail postings referenced therefrom - great reading! :)
>>
>>     So basic problem: access to __thread variables is not
>> async-signal-safe
>>
>>     Exacerbator to problem: first attempt to even read a __thread
>>     variable can lead to allocation which is the real problem in
>>     relation to async-signal-safety
>>
>>     I mention the exacerbator because pthread_getspecific and
>>     pthread_setSpecific are also not async-signal-safe but we already
>>     use them. However, pthread_getspecific is in fact (per email threads
>>     linked above) effectively async-signal-safe, and further a call to
>>     pthread_getspecific never results in a call to pthread_setspecific
>>     or an allocation. Hence the pthread functions are almost, if not
>>     completely, safe in practice with reasonable uses (ie only read from
>>     signal handler). Which explain this code in existing Thread::current()
>>
>>     #ifdef PARANOID
>>        // Signal handler should call ThreadLocalStorage::get_thread_slow()
>>        Thread* t = ThreadLocalStorage::get_thread_slow();
>>        assert(t != NULL && !t->is_inside_signal_handler(),
>>               "Don't use Thread::current() inside signal handler");
>>     #endif
>>
>>     So problem scenario is: use of __thread variable (that belongs to
>>     the shared-library) in a signal handler.
>>
>>     Solution 0: don't do that. Seriously - like any other
>>     async-signal-unsafe stuff we should not be using it in real signal
>>     handlers. The crash handler is a different matter - we try all sorts
>>     there because it might work and you can't die twice.
>>
>>     Otherwise: narrow the window of exposure.
>>
>>     1. We ensure we initialize thread_current (even with a dummy value)
>>     as early as possible in the thread that loads libjvm. As we have no
>>     signal handlers installed at that point that might use the same
>>     variable, we can not hit the problem scenario.
>>
>>     2. We ensure we initialize thread_current in a new thread with all
>>     signals blocked. This again avoids the problem scenario.
>>
>>     3. We initialize thread_current in an attaching thread as soon as
>>     possible and we again first block all signals.
>>
>>     That still leaves the problem of an unattached native thread taking
>>     a signal whilst in async-signal-unsafe code, and executing a signal
>>     handler which in turns tries to access thread_current for the first
>>     time. This signal handler need not be an actual JVM handler, but one
>>     attached by other native code eg an agent. I'm not clear in the
>>     latter case how reasonable it is for an agent's handler to try and
>>     do things from an unattached thread - and we don't claim any JNI
>>     interfaces can, or should, be called from a signal handler - but it
>>     is something you can probably get away with today.
>>
>>     Let me also point out that we already effectively have this code in
>>     Solaris already (at the ThreadLocalStorage class level). So if there
>>     is something here that will prevent the current proposal we already
>>     have a problem on Solaris. :(
>>
>>     Thoughts/comments/suggestions?
>>
>>
>> The first problem: thread initializes TLS variable, gets interrupted and
>> accesses the half-initialized variable from within the signal handler.
>> This could happen today too, or? but I think we never saw this.
>>
>
> That depends on the state of signal masks at the time of the
> initialization. For threads created in the VM and for threads attached to
> the VM it is likely not an issue. Unattached threads could in theory try to
> access a TLS variable from a signal handler, but they will never be
> initializing that variable. Of course the unattached thread could be
> initializing a completely distinct TLS variable, but reading a different
> TLS variable from the signal handler does not seem to be an issue (in
> theory it may be but this is an extreme corner case).
>
> In theory, it could be mitigated by some careful testing before using
>> the Thread::current() value in the signal handler. Like, put an
>> eyecatcher at the beginning of the Thread structure and check that using
>> SafeFetch.
>>
>
> There is no way to access the Thread structure before calling
> Thread::current(). And the potential problem is with unattached threads
> which have no Thread structure. For threads attached to the VM, or
> attaching, my three steps will deal with any potential problems.
>
> As for the second problem - recursive malloc() deadlocks - I am at a
>> loss. I do not fully understand though why pthread_getspecific is
>> different - does it not have to allocate place for the TLS variable too?
>>
>
> No, pthread_getspecific does not have to allocate. Presumably it is
> written in a way that attempting to index a TLS variable that has not been
> allocated just returns an error (EINVAL?).


It would return NULL.


> The problem with __thread is that even a read will attempt to do the
> allocation - arguably (as the Google folk did argue) this is wrong, or else
> should be done in an async-safe way.
>

I looked up the implementation of pthread_getspecific and
pthread_setspecific in the glibc and now understand better why pthread tls
is considered safe here.

glibc allows for 1024 tls slots which are organized as a 32x32 sparse
array, whose second level arrays are only allocated if the first slot in it
is used by pthread_setspecific. So, only when writing the slot. It also
means that the number of allocation calls is smaller than with __thread -
instead of (presumably) calling malloc() for every instance of __thread, it
only calls at the maximum 32 times. And the first 32 slots are already
allocated in the pthread structure, so they are free. This means that even
if one were to write to a TLS slot in the signal handler, chances of it
mallocing are quite small.


>
> This does leave me wondering exactly what affect the:
>
> static __thread Thread* _thr_current = NULL;
>
> has in terms of any per-thread allocation. ??
>
> Anyway to reiterate the problem scenario:
> - VM has been loaded in a process and signal handlers have been installed
> (maybe VM, maybe agent)
> - unattached thread is doing a malloc when it takes a signal
> - signal handler tries to read __thread variable and we get a malloc
> deadlock
>
> As I said I need to determine what signal handlers in the VM might ever
> run on an unattached thread, and what they might do.


I don't understand - our signal handler is globally active, no? So any
unattached thread may execute our signal handler at any time, and the first
thing our signal handler does is Thread::current(). If there was a third
party signal handler, it is getting called as chained handler, but only
after our signal handler ran.

Thanks, Thomas

(My current feeling is that I'd prefer to keep the pthread TLS solution but
I like your simplifications to the code and would like to keep that too...)


> For a "third-party" signal handler there's really nothing I can do - they
> should not be accessing the VM's __thread variables though (and they cal
> always introduce their own independent deadlocks by performing
> non-async-safe actions).
>
> Thanks,
> David
>
> Regards, Thomas
>>
>>
>>     Thanks,
>>     David
>>
>>
>>     On 6/11/2015 1:09 PM, David Holmes wrote:
>>
>>         Hi Jeremy,
>>
>>         I was going to ask you to elaborate :)
>>
>>         On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>>
>>             I should probably elaborate on this.  With glibc + ELF, the
>>             first time a
>>             thread accesses a variable declared __thread, if that
>>             variable is in a
>>             shared library (as opposed to the main executable), the
>>             system calls
>>             malloc() to allocate the space for it.  If that happens in a
>>             signal that
>>             is being delivered during a call to malloc(), then you
>>             usually get a
>>             crash.
>>
>>
>>         My understanding of the ELF ABI for thread-locals - which I read
>>         about
>>         in the Solaris 11.1 Linkers and libraries guide - does require
>>         use of
>>         the dynamic TLS model for any dynamically loaded shared object
>> which
>>         defines a thread-local, but that is what we use as I understand
>>         it. The
>>         docs state:
>>
>>         "A shared object containing only dynamic TLS can be loaded
>> following
>>         process startup without limitations. The runtime linker extends
>>         the list
>>         of initialization records to include the initialization template
>>         of the
>>         new object. The new object is given an index of m = M + 1. The
>>         counter M is incremented by 1. However, the allocation of new
>>         TLS blocks
>>         is deferred until the blocks are actually referenced."
>>
>>         Now I guess "extends the list" might be implemented using malloc
>>         ... but
>>         this will only occur in the main thread (the one started by the
>>         launcher
>>         to load the JVM and become the main thread), at the time libjvm is
>>         loaded - which will all be over before any agent etc can run and
>> do
>>         anything. But "allocation ... is deferred" suggests we may have a
>>         problem until either the first call to Thread::current or the
>>         call to
>>         Thread::initialize_thread_current. If it is the former then that
>>         should
>>         occur well before any agent etc can be loaded. And I can easily
>>         inject
>>         an initial dummy call to initialize_thread_current(null) to
>>         force the
>>         TLS allocation.
>>
>>             This may bite you if AsyncGetCallTrace uses
>>             Thread::current(), and you
>>             use system timers to do profiling.  If a thread doing a
>>             malloc() prior
>>             to the first time it accesses Thread::current(), and it gets
>>             delivered a
>>             signal, it might die.  This is especially likely for pure
>>             native threads
>>             started by native code.
>>
>>             I believe that this is a use case you support, so you might
>>             want to make
>>             sure it is okay.
>>
>>
>>         For a VM embedded in a process, which already contains native
>>         threads,
>>         that will later attach to the VM, this may indeed be a problem.
>> One
>>         would have hoped however that the implementation of TLS would be
>>         completely robust, at least for something as simple as getting a
>>         signal
>>         whilst in the allocator.
>>
>>         I'm unclear how to test for or check for this kind of problem.
>>         Arguably
>>         there could be many things that are async-unsafe in this way.
>>
>>         Need to think more about this and do some more research. Would
>> also
>>         appreciate any insight from any glibc and/or ELF gurus.
>>
>>         Thanks.
>>         David
>>
>>             Jeremy
>>
>>             On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>>             <jeremymanson at google.com <mailto:jeremymanson at google.com>
>>             <mailto:jeremymanson at google.com
>>             <mailto:jeremymanson at google.com>>> wrote:
>>
>>                  Something that's bitten me with __thread: it isn't
>>             async-safe when
>>                  called from a shared object on Linux.  Have you vetted
>>             to make sure
>>                  this doesn't make HS less async-safe?
>>
>>                  Jeremy
>>
>>                  On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>>                  <david.holmes at oracle.com
>>             <mailto:david.holmes at oracle.com>
>>             <mailto:david.holmes at oracle.com
>>
>>             <mailto:david.holmes at oracle.com>>> wrote:
>>
>>                      bug:
>> https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                      Open webrev:
>>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>>
>>                      A simple (in principle) but wide-ranging change
>>             which should
>>                      appeal to our Code Deletion Engineer's. We implement
>>                      Thread::current() using a compiler/language-based
>>             thread-local
>>                      variable eg:
>>
>>
>>                        static __thread Thread *_thr_current;
>>
>>                        inline Thread* Thread::current() {
>>                          return _thr_current;
>>                        }
>>
>>                      with an appropriate setter of course. By doing this
>>             we can
>>                      completely remove the platform-specific
>>             ThreadLocalStorage
>>                      implementations, and the associated
>>             os::thread_local_storage*
>>                      calls, plus all the uses of
>>             ThreadLocalStorage::thread() and
>>                      ThreadLocalStorage::get_thread_slow(). This extends
>>             the previous
>>                      work done on Solaris to implement
>>             ThreadLocalStorage::thread()
>>                      using compiler-based thread-locals.
>>
>>                      We can also consolidate nearly all the os_cpu
>>             versions of
>>                      MacroAssembler::get_thread on x86 into one cpu
>>             specific one ( a
>>                      special variant is still needed for 32-bit Windows).
>>
>>                      As a result of this change we have further
>>             potential cleanups:
>>                      - all the src/os/<os>/vm/thread_<os>.inline.hpp
>>             files are now
>>                      completely empty and could also be removed
>>                      - the MINIMIZE_RAM_USAGE define (which avoids use
>>             of the linux
>>                      sp-map "cache" on 32-bit) now has no affect and so
>>             could be
>>                      completely removed from the build system
>>
>>                      I plan to do the MINIMIZE_RAM_USAGE removal as a
>>             follow up CR,
>>                      but could add the removal of the "inline" files to
>>             this CR if
>>                      people think it worth removing them.
>>
>>                      I have one missing piece on Aarch64 - I need to
>> change
>>                      MacroAssembler::get_thread to simply call
>>             Thread::current() as
>>                      on other platforms, but I don't know how to write
>>             that. I would
>>                      appreciate it if someone could give me the right
>>             code for that.
>>
>>                      I would also appreciate comments/testing by the AIX
>>             and PPC64
>>                      folk as well.
>>
>>                      A concern about memory-leaks had previously been
>>             raised, but
>>                      experiments using simple C code on linux 86 and
>>             Solaris showed
>>                      no issues. Also note that Aarch64 already uses this
>>             kind of
>>                      thread-local.
>>
>>                      Thanks,
>>                      David
>>
>>
>>
>>
>>

From thomas.schatzl at oracle.com  Tue Nov 10 10:29:48 2015
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 10 Nov 2015 11:29:48 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <564068A7.802@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com>
Message-ID: <1447151388.2371.24.camel@oracle.com>

On Mon, 2015-11-09 at 10:34 +0100, Stefan Karlsson wrote:
> Hi Vladimir,
> 
> What do you think about this version:
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/
> 
> Thanks,
> StefanK

 in relocInfo_x86.cpp, line 70 and 77: shouldn't these asserts be
guarantees too?

Also, the assert in NativeInstruction::verify_data64_sethi() in
relocInfo_sparc.cpp needs to be a guarantee, as it is called by
Relocation::pd_set_data_value().

I also grepped the code for more "verify_only" parameters, and they also
use asserts instead of guarantees.
Like Relocation::pd_set_data_value() in relocInfo_aarch64.cpp,
relocInfo_ppc.cpp, in PhaseIdealLoop::build_and_optimize() in
loopnode.cpp.

Although I think the one in PhaseIdealLoop::build_and_optimize() is not
executed via nmethod::oops_do_marking_epilogue().

Thanks,
  Thomas



From sgehwolf at redhat.com  Tue Nov 10 11:00:03 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 10 Nov 2015 12:00:03 +0100
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <56411D2A.3030701@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
Message-ID: <1447153203.3700.15.camel@redhat.com>

On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
> > FWIW, the below hunk seems to be all that's necessary in order to
> > fix
> > the --disable-precompiled-headers Zero build for me:
> > 
> > diff --git a/src/share/vm/runtime/java.cpp
> > b/src/share/vm/runtime/java.cpp
> > --- a/src/share/vm/runtime/java.cpp
> > +++ b/src/share/vm/runtime/java.cpp
> > @@ -49,6 +49,7 @@
> > ? #include "runtime/arguments.hpp"
> > ? #include "runtime/biasedLocking.hpp"
> > ? #include "runtime/compilationPolicy.hpp"
> > +#include "runtime/deoptimization.hpp"
> > ? #include "runtime/fprofiler.hpp"
> > ? #include "runtime/init.hpp"
> > ? #include "runtime/interfaceSupport.hpp"
> > 
> > It does not seem the other change is required. Tested with
> > fastdebug
> > build of Zero with --disable-precompiled-headers that failed to
> > build
> > without and built fine with the fix.
> 
> I could check in just the deoptimization.hpp change and build only 
> fastdebug until the other bug is fixed.

This sounds good to me.

> > 
> > Coleen, do you have details about the failure which gets supposedly
> > fixed by the other hunk?
> 
> The only thing I have is the g++ compilation failures without these 
> changes.??The one that was fixed by including allocation.inline.hpp
> was:
> 
> Building target 'images' in configuration 'linux-x86_64-normal-zero-
> release'
> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
> ats.hpp:32: 
> undefined reference to `CHeapObj<(MemoryType)5>::operator
> delete(void*)'
> collect2: error: ld returned 1 exit status
> 
> Since the destructor is complaining about the missing delete
> operator, I 
> assume this compiler has the sort of destructor that implicitly can
> also 
> call delete.??I don't have any other information or ideas really why 
> this fails to compile.

Thanks!

FWIW, I don't reproduce the?g1EvacStats.o linking problem. With the
deoptimization.hpp change a Zero JVM builds fine here in all variants:
release/fastdebug/slowdebug.

$ gcc --version
gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.??There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks,
Severin

From stefan.karlsson at oracle.com  Tue Nov 10 11:14:52 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Nov 2015 12:14:52 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <1447151388.2371.24.camel@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com> <1447151388.2371.24.camel@oracle.com>
Message-ID: <5641D1AC.9010803@oracle.com>

Hi Thomas,

Thanks for reviewing. Here's the updated patches:
  http://cr.openjdk.java.net/~stefank/8140584/webrev.03
  http://cr.openjdk.java.net/~stefank/8140584/webrev.03.delta

Thanks,
StefanK

On 2015-11-10 11:29, Thomas Schatzl wrote:
> On Mon, 2015-11-09 at 10:34 +0100, Stefan Karlsson wrote:
>> Hi Vladimir,
>>
>> What do you think about this version:
>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/
>>
>> Thanks,
>> StefanK
>   in relocInfo_x86.cpp, line 70 and 77: shouldn't these asserts be
> guarantees too?
>
> Also, the assert in NativeInstruction::verify_data64_sethi() in
> relocInfo_sparc.cpp needs to be a guarantee, as it is called by
> Relocation::pd_set_data_value().
>
> I also grepped the code for more "verify_only" parameters, and they also
> use asserts instead of guarantees.
> Like Relocation::pd_set_data_value() in relocInfo_aarch64.cpp,
> relocInfo_ppc.cpp, in PhaseIdealLoop::build_and_optimize() in
> loopnode.cpp.
>
> Although I think the one in PhaseIdealLoop::build_and_optimize() is not
> executed via nmethod::oops_do_marking_epilogue().
>
> Thanks,
>    Thomas
>
>


From david.holmes at oracle.com  Tue Nov 10 11:26:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Nov 2015 21:26:10 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
Message-ID: <5641D452.6040503@oracle.com>

Sorry the formatting of the replies is getting totally screwed up now :(

On 10/11/2015 8:20 PM, Thomas St?fe wrote:
> Hi David,
>
> On Fri, Nov 6, 2015 at 11:20 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 6/11/2015 9:52 PM, Thomas St?fe wrote:
>
>         Hi David,
>
>         On Fri, Nov 6, 2015 at 7:26 AM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              Hi Jeremy,
>
>              Okay I have read:
>
>         https://sourceware.org/glibc/wiki/TLSandSignals
>
>              and the tree of mail postings referenced therefrom - great
>         reading! :)
>
>              So basic problem: access to __thread variables is not
>         async-signal-safe
>
>              Exacerbator to problem: first attempt to even read a __thread
>              variable can lead to allocation which is the real problem in
>              relation to async-signal-safety
>
>              I mention the exacerbator because pthread_getspecific and
>              pthread_setSpecific are also not async-signal-safe but we
>         already
>              use them. However, pthread_getspecific is in fact (per
>         email threads
>              linked above) effectively async-signal-safe, and further a
>         call to
>              pthread_getspecific never results in a call to
>         pthread_setspecific
>              or an allocation. Hence the pthread functions are almost,
>         if not
>              completely, safe in practice with reasonable uses (ie only
>         read from
>              signal handler). Which explain this code in existing
>         Thread::current()
>
>              #ifdef PARANOID
>                 // Signal handler should call
>         ThreadLocalStorage::get_thread_slow()
>                 Thread* t = ThreadLocalStorage::get_thread_slow();
>                 assert(t != NULL && !t->is_inside_signal_handler(),
>                        "Don't use Thread::current() inside signal handler");
>              #endif
>
>              So problem scenario is: use of __thread variable (that
>         belongs to
>              the shared-library) in a signal handler.
>
>              Solution 0: don't do that. Seriously - like any other
>              async-signal-unsafe stuff we should not be using it in real
>         signal
>              handlers. The crash handler is a different matter - we try
>         all sorts
>              there because it might work and you can't die twice.
>
>              Otherwise: narrow the window of exposure.
>
>              1. We ensure we initialize thread_current (even with a
>         dummy value)
>              as early as possible in the thread that loads libjvm. As we
>         have no
>              signal handlers installed at that point that might use the same
>              variable, we can not hit the problem scenario.
>
>              2. We ensure we initialize thread_current in a new thread
>         with all
>              signals blocked. This again avoids the problem scenario.
>
>              3. We initialize thread_current in an attaching thread as
>         soon as
>              possible and we again first block all signals.
>
>              That still leaves the problem of an unattached native
>         thread taking
>              a signal whilst in async-signal-unsafe code, and executing
>         a signal
>              handler which in turns tries to access thread_current for
>         the first
>              time. This signal handler need not be an actual JVM
>         handler, but one
>              attached by other native code eg an agent. I'm not clear in the
>              latter case how reasonable it is for an agent's handler to
>         try and
>              do things from an unattached thread - and we don't claim
>         any JNI
>              interfaces can, or should, be called from a signal handler
>         - but it
>              is something you can probably get away with today.
>
>              Let me also point out that we already effectively have this
>         code in
>              Solaris already (at the ThreadLocalStorage class level). So
>         if there
>              is something here that will prevent the current proposal we
>         already
>              have a problem on Solaris. :(
>
>              Thoughts/comments/suggestions?
>
>
>         The first problem: thread initializes TLS variable, gets
>         interrupted and
>         accesses the half-initialized variable from within the signal
>         handler.
>         This could happen today too, or? but I think we never saw this.
>
>
>     That depends on the state of signal masks at the time of the
>     initialization. For threads created in the VM and for threads
>     attached to the VM it is likely not an issue. Unattached threads
>     could in theory try to access a TLS variable from a signal handler,
>     but they will never be initializing that variable. Of course the
>     unattached thread could be initializing a completely distinct TLS
>     variable, but reading a different TLS variable from the signal
>     handler does not seem to be an issue (in theory it may be but this
>     is an extreme corner case).
>
>         In theory, it could be mitigated by some careful testing before
>         using
>         the Thread::current() value in the signal handler. Like, put an
>         eyecatcher at the beginning of the Thread structure and check
>         that using
>         SafeFetch.
>
>
>     There is no way to access the Thread structure before calling
>     Thread::current(). And the potential problem is with unattached
>     threads which have no Thread structure. For threads attached to the
>     VM, or attaching, my three steps will deal with any potential problems.
>
>         As for the second problem - recursive malloc() deadlocks - I am at a
>         loss. I do not fully understand though why pthread_getspecific is
>         different - does it not have to allocate place for the TLS
>         variable too?
>
>
>     No, pthread_getspecific does not have to allocate. Presumably it is
>     written in a way that attempting to index a TLS variable that has
>     not been allocated just returns an error (EINVAL?).
>
>
> It would return NULL.
>
>     The problem with __thread is that even a read will attempt to do the
>     allocation - arguably (as the Google folk did argue) this is wrong,
>     or else should be done in an async-safe way.
>
>
> I looked up the implementation of pthread_getspecific and
> pthread_setspecific in the glibc and now understand better why pthread
> tls is considered safe here.
>
> glibc allows for 1024 tls slots which are organized as a 32x32 sparse
> array, whose second level arrays are only allocated if the first slot in
> it is used by pthread_setspecific. So, only when writing the slot. It
> also means that the number of allocation calls is smaller than with
> __thread - instead of (presumably) calling malloc() for every instance
> of __thread, it only calls at the maximum 32 times. And the first 32
> slots are already allocated in the pthread structure, so they are free.
> This means that even if one were to write to a TLS slot in the signal
> handler, chances of it mallocing are quite small.

__thread will only need to malloc (in the context we are discussing) 
when a pre-existing thread first references a TLS variable from a lazily 
loaded DSO. Otherwise the space for the DSO's TLS variables are 
allocated "statically" when the thread control structures are created.

>
>     This does leave me wondering exactly what affect the:
>
>     static __thread Thread* _thr_current = NULL;
>
>     has in terms of any per-thread allocation. ??
>
>     Anyway to reiterate the problem scenario:
>     - VM has been loaded in a process and signal handlers have been
>     installed (maybe VM, maybe agent)
>     - unattached thread is doing a malloc when it takes a signal
>     - signal handler tries to read __thread variable and we get a malloc
>     deadlock
>
>     As I said I need to determine what signal handlers in the VM might
>     ever run on an unattached thread, and what they might do.
>
>
> I don't understand - our signal handler is globally active, no? So any
> unattached thread may execute our signal handler at any time, and the
> first thing our signal handler does is Thread::current(). If there was a
> third party signal handler, it is getting called as chained handler, but
> only after our signal handler ran.

The current code uses ThreadLocalStorage::get_thread_slow() in the 
signal handler, which uses pthread_getspecific, which is "safe". The new 
code would access the __thread variable and have to malloc - which is 
unsafe.

Using the JDK launchers there are no unattached threads created before 
libjvm is loaded - so the problem would never arise.

I have been looking hard at our signal handlers though and found they 
don't seem to match how they are described in various parts of the code 
that set the signal masks. My main concern is with process-directed 
signals (SIGQUIT, SIGTERM) that trigger specific actions (thread dump, 
orderly shutdown). Synchronous signals are not an issue - if the 
unattached thread triggers a segv while in malloc then the process is 
doomed anyway and a deadlock is less problematic (not great but hardly 
in the same league as deadlocking an active fully working VM). But I'm 
still having trouble joining all the dots in this code and figuring out 
how an unattached thread might react today. I'll continue untangling 
this tomorrow.


> Thanks, Thomas
>
> (My current feeling is that I'd prefer to keep the pthread TLS solution
> but I like your simplifications to the code and would like to keep that
> too...)

It was all the complex, inconsistent caching mechanisms employed over 
the top of the library based TLS that motivated the cleanup - especially 
as the cache on Solaris was shown to be broken. If it was just a simple 
library based TLS layer, there would be less motivation to try the 
__thread approach - but __thread had the appeal of removing a lot of 
duplicated code. A simple library based scheme might be an alternative 
if it is performant enough - but not sure I have the time to go back to 
square one on this.

Thanks,
David

>     For a "third-party" signal handler there's really nothing I can do -
>     they should not be accessing the VM's __thread variables though (and
>     they cal always introduce their own independent deadlocks by
>     performing non-async-safe actions).
>
>     Thanks,
>     David
>
>         Regards, Thomas
>
>
>              Thanks,
>              David
>
>
>              On 6/11/2015 1:09 PM, David Holmes wrote:
>
>                  Hi Jeremy,
>
>                  I was going to ask you to elaborate :)
>
>                  On 6/11/2015 12:24 PM, Jeremy Manson wrote:
>
>                      I should probably elaborate on this.  With glibc +
>         ELF, the
>                      first time a
>                      thread accesses a variable declared __thread, if that
>                      variable is in a
>                      shared library (as opposed to the main executable), the
>                      system calls
>                      malloc() to allocate the space for it.  If that
>         happens in a
>                      signal that
>                      is being delivered during a call to malloc(), then you
>                      usually get a
>                      crash.
>
>
>                  My understanding of the ELF ABI for thread-locals -
>         which I read
>                  about
>                  in the Solaris 11.1 Linkers and libraries guide - does
>         require
>                  use of
>                  the dynamic TLS model for any dynamically loaded shared
>         object which
>                  defines a thread-local, but that is what we use as I
>         understand
>                  it. The
>                  docs state:
>
>                  "A shared object containing only dynamic TLS can be
>         loaded following
>                  process startup without limitations. The runtime linker
>         extends
>                  the list
>                  of initialization records to include the initialization
>         template
>                  of the
>                  new object. The new object is given an index of m = M +
>         1. The
>                  counter M is incremented by 1. However, the allocation
>         of new
>                  TLS blocks
>                  is deferred until the blocks are actually referenced."
>
>                  Now I guess "extends the list" might be implemented
>         using malloc
>                  ... but
>                  this will only occur in the main thread (the one
>         started by the
>                  launcher
>                  to load the JVM and become the main thread), at the
>         time libjvm is
>                  loaded - which will all be over before any agent etc
>         can run and do
>                  anything. But "allocation ... is deferred" suggests we
>         may have a
>                  problem until either the first call to Thread::current
>         or the
>                  call to
>                  Thread::initialize_thread_current. If it is the former
>         then that
>                  should
>                  occur well before any agent etc can be loaded. And I
>         can easily
>                  inject
>                  an initial dummy call to initialize_thread_current(null) to
>                  force the
>                  TLS allocation.
>
>                      This may bite you if AsyncGetCallTrace uses
>                      Thread::current(), and you
>                      use system timers to do profiling.  If a thread doing a
>                      malloc() prior
>                      to the first time it accesses Thread::current(),
>         and it gets
>                      delivered a
>                      signal, it might die.  This is especially likely
>         for pure
>                      native threads
>                      started by native code.
>
>                      I believe that this is a use case you support, so
>         you might
>                      want to make
>                      sure it is okay.
>
>
>                  For a VM embedded in a process, which already contains
>         native
>                  threads,
>                  that will later attach to the VM, this may indeed be a
>         problem. One
>                  would have hoped however that the implementation of TLS
>         would be
>                  completely robust, at least for something as simple as
>         getting a
>                  signal
>                  whilst in the allocator.
>
>                  I'm unclear how to test for or check for this kind of
>         problem.
>                  Arguably
>                  there could be many things that are async-unsafe in
>         this way.
>
>                  Need to think more about this and do some more
>         research. Would also
>                  appreciate any insight from any glibc and/or ELF gurus.
>
>                  Thanks.
>                  David
>
>                      Jeremy
>
>                      On Thu, Nov 5, 2015 at 5:58 PM, Jeremy Manson
>                      <jeremymanson at google.com
>         <mailto:jeremymanson at google.com> <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>>
>                      <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>
>                      <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>>>> wrote:
>
>                           Something that's bitten me with __thread: it isn't
>                      async-safe when
>                           called from a shared object on Linux.  Have
>         you vetted
>                      to make sure
>                           this doesn't make HS less async-safe?
>
>                           Jeremy
>
>                           On Sun, Nov 1, 2015 at 10:40 PM, David Holmes
>                           <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>                      <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>
>                      <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>
>                      <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>>> wrote:
>
>                               bug:
>         https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                               Open webrev:
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
>
>                               A simple (in principle) but wide-ranging
>         change
>                      which should
>                               appeal to our Code Deletion Engineer's. We
>         implement
>                               Thread::current() using a
>         compiler/language-based
>                      thread-local
>                               variable eg:
>
>
>                                 static __thread Thread *_thr_current;
>
>                                 inline Thread* Thread::current() {
>                                   return _thr_current;
>                                 }
>
>                               with an appropriate setter of course. By
>         doing this
>                      we can
>                               completely remove the platform-specific
>                      ThreadLocalStorage
>                               implementations, and the associated
>                      os::thread_local_storage*
>                               calls, plus all the uses of
>                      ThreadLocalStorage::thread() and
>                               ThreadLocalStorage::get_thread_slow().
>         This extends
>                      the previous
>                               work done on Solaris to implement
>                      ThreadLocalStorage::thread()
>                               using compiler-based thread-locals.
>
>                               We can also consolidate nearly all the os_cpu
>                      versions of
>                               MacroAssembler::get_thread on x86 into one cpu
>                      specific one ( a
>                               special variant is still needed for 32-bit
>         Windows).
>
>                               As a result of this change we have further
>                      potential cleanups:
>                               - all the
>         src/os/<os>/vm/thread_<os>.inline.hpp
>                      files are now
>                               completely empty and could also be removed
>                               - the MINIMIZE_RAM_USAGE define (which
>         avoids use
>                      of the linux
>                               sp-map "cache" on 32-bit) now has no
>         affect and so
>                      could be
>                               completely removed from the build system
>
>                               I plan to do the MINIMIZE_RAM_USAGE
>         removal as a
>                      follow up CR,
>                               but could add the removal of the "inline"
>         files to
>                      this CR if
>                               people think it worth removing them.
>
>                               I have one missing piece on Aarch64 - I
>         need to change
>                               MacroAssembler::get_thread to simply call
>                      Thread::current() as
>                               on other platforms, but I don't know how
>         to write
>                      that. I would
>                               appreciate it if someone could give me the
>         right
>                      code for that.
>
>                               I would also appreciate comments/testing
>         by the AIX
>                      and PPC64
>                               folk as well.
>
>                               A concern about memory-leaks had
>         previously been
>                      raised, but
>                               experiments using simple C code on linux
>         86 and
>                      Solaris showed
>                               no issues. Also note that Aarch64 already
>         uses this
>                      kind of
>                               thread-local.
>
>                               Thanks,
>                               David
>
>
>
>
>

From thomas.schatzl at oracle.com  Tue Nov 10 14:29:57 2015
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 10 Nov 2015 15:29:57 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <5641D1AC.9010803@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com> <1447151388.2371.24.camel@oracle.com>
	<5641D1AC.9010803@oracle.com>
Message-ID: <1447165797.2371.46.camel@oracle.com>

Hi,

On Tue, 2015-11-10 at 12:14 +0100, Stefan Karlsson wrote:
> Hi Thomas,
> 
> Thanks for reviewing. Here's the updated patches:
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.03
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.03.delta
> 

  looks good.

Thomas



From stefan.karlsson at oracle.com  Tue Nov 10 14:30:48 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Nov 2015 15:30:48 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <1447165797.2371.46.camel@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com> <1447151388.2371.24.camel@oracle.com>
	<5641D1AC.9010803@oracle.com> <1447165797.2371.46.camel@oracle.com>
Message-ID: <5641FF98.9050409@oracle.com>

Thanks, Thomas.

StefanK

On 2015-11-10 15:29, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2015-11-10 at 12:14 +0100, Stefan Karlsson wrote:
>> Hi Thomas,
>>
>> Thanks for reviewing. Here's the updated patches:
>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.03
>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.03.delta
>>
>    looks good.
>
> Thomas
>
>


From gerard.ziemski at oracle.com  Tue Nov 10 17:31:13 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Tue, 10 Nov 2015 11:31:13 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <563D1C97.4010702@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
Message-ID: <564229E1.1070500@oracle.com>

hi all,

I have updated the fix with rev2, incorporating feedback from David:

- Move the metaspace constants back into metaspace code
- Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests

http://cr.openjdk.java.net/~gziemski/8138983_rev2


cheers


On 11/06/2015 03:33 PM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating feedback from Dmitry:
>
> - Fix comments and indentation
> - Add "-XShare:dump" while testing Shared* flags
> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>
> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>
>
>
> cheers
>
>
>
> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this final fix for JEP-245
>>
>> We implement the remaining runtime flags in the Shared* family.
>>
>> Summary of changes:
>>
>> #1 core fix - we factor out the constants to be used in the ranges
>>
>> src/share/vm/classfile/compactHashtable.cpp
>> src/share/vm/memory/metaspace.cpp
>> src/share/vm/memory/metaspaceShared.hpp
>> src/share/vm/runtime/globals.hpp
>>
>>
>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>
>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>
>>
>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>
>>
>> #4 we add functionality to OptionsValidation test framework that we later use
>>
>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>
>>
>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>
>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>
>>
>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>> tests
>>
>> References:
>>
>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>
>>
>> hg_stat:
>>
>>   src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>   src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>   src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>   src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>   src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>   src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>   test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>   9 files changed, 242 insertions(+), 141 deletions(-)
>

From frederic.parain at oracle.com  Tue Nov 10 17:38:13 2015
From: frederic.parain at oracle.com (frederic parain)
Date: Tue, 10 Nov 2015 18:38:13 +0100
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <5640477B.3010302@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
Message-ID: <56422B85.9080000@oracle.com>

Hi David and Doug,

Thank you for your feedback.

I put some comments below.

On 09/11/2015 08:12, David Holmes wrote:
> Hi Doug,
>
> On 9/11/2015 9:31 AM, Doug Lea wrote:
>> On 11/06/2015 02:23 AM, David Holmes wrote:
>>
>>> Before I look at the code, what is the status of the "Open Issues"
>>> referenced in the JEP?
>>>
>>> Also the JDK changes need to be reviewed on core-libs-dev and in
>>> particular must
>>> be seen by the jsr166 maintainers (ie Doug Lea and Martin Buchholz)
>>>
>>
>> Martin and I and others are aware of this work.
>>
>> As has been said by everyone initially looking at JEP 270, it is a
>> disappointing effort. It requires that APIs/methods supporting
>> try/finally-like constructions (especially locks) include new
>> annotations to substantially reduce the likelihood of failing to
>> perform the "finally" side actions to release resources (like a lock)
>> upon StackOverflowError.
>>
>> Considering that no other readily implementable solution has
>> been proposed during the many years that this issue has been discussed,
>> a disappointing band-aid might not be so bad.
>
> If I put on some extra-strength rose-coloured glasses I think I can
> almost read that as "something is better than nothing". ;-) As there are
> no practical general solutions to the problem (which surely says
> something fundamental about the language design!) an annotation-based
> point solution seems the only way to make some progress.
>
> But note that it is not the finally part that need be at issue. If one
> considers ReentrantLock.lock() (in NonfairSync):
>
>   210         final void lock() {
>   211             if (compareAndSetState(0, 1))
>   212                 setExclusiveOwnerThread(Thread.currentThread());
>   213             else
>   214                 acquire(1);
>   215         }
>
> if we throw after #211 the lock is half-locked: state says it is locked,
> but no owner set. So it can't be locked again, nor can it be unlocked.
> We would have to determine actual stack usage for each call path to know
> whether that is in fact possible
>
>> Assuming the hotspot mechanics are put into place, the main question
>> is when to use the  @ReservedStackAccess annotation.
>>
>> The JEP singles out ReentrantLock. But there are also other locks
>> provided in JDK (StampedLock, ReentrantReadWriteLock), as well
>> as in other external packages, that should probably use this.
>> Plus there are other lock/resource APIs, for example Semaphore,
>> that are often used in try/finally constructions. And internal
>> before/after bookkeeping inside Executors. Plus, many cases of
>> try-with-resources constructions. Plus many transactional APIs.
>>
>> And so on. It would be a never-ending effort to effectively use
>> @ReservedStackAccess.
>
> Which, to me, is just another way of saying that the general problem is
> intractable. The annotation at least gives the mechanism for a point
> solution as has been said. The pain point that drove this was the use of
> ReentrantLock in ConcurrentHashMap, which in turn was used in class
> loading. That particular pain point has been addressed by not using the
> problematic class - something we surely do not want to promote as the
> way to deal with this problem!
>
>> I don't know of a good way to address this. One possibility is
>> for javac to automatically insert @ReservedStackAccess in any
>> method with a try-finally that involves at least one call?
>
> I don't see how that would be at all viable as it brings back in the
> sizing problem - or greatly exacerbates the sizing problem. Plus as
> noted above the problem is not just with the finally part.

Another issue is that writing a rule for javac that is not
overpessimistic is also an intractable problem. The pattern
"atomic operation followed by method invocation to complete
status update" is too general to be the trigger of the annotation.
1) It would lead to an excessive number of methods being annotated,
and by consequence an over-sizing of the reserved area.
2) Another condition to hit the bug is that the stack space of
the callee method must be bigger than the caller method with
the atomic operation. This information depends heavily on runtime
information like HW, compilation policies (inlining) and execution
profile (to know which methods are going to be compiled first).
javac won't have access to these information to annotated methods.

> Perhaps we should simply start with j.u.c.locks as the initial candidate
> sets of classes and work out from there. The idiomatic Lock usage:
>
> l.lock();
> try {
>   // ...
> } finally {
>    l.unlock();
> }
>
> epitomizes the critical-finally-block scenario (though the lock()
> problem is much more subtle). AQS is too low-level to flag any specific
> function I think; and the other synchronizers perhaps too high-level,
> with fewer idiomatic use-cases that obviously benefit from this.
>
> In that regard I don't agree with where Fred has currently placed the
> annotation in ReentrantLock and AQS. The placements appear arbitrary at
> first glance - though no doubt they are the result of a deep and careful
> analysis. But it is far from obvious why the annotation is placed on
> NonfairSync.lock but FairSync.tryAcquire(), for example.

The annotation is used on methods with the problematic pattern
"atomic operation followed by method invocation".
Their execution could lead to data corruption if atomic operation
is executed successfully but the following method invocation
fails because of SOE.

In the NonFairSync class, this pattern is in the lock() method,
while the tryAcquire() is only a method invocation. So lock()
is annotated and tryAcquire() is not. Note that the method
invoked by try acquire is nonfairTryAcquire() which has the
problematic pattern and is annotated.

In the FairSync class, the situation is reversed: lock() is
just an method invocation and it is not annotated, and
tryAcquire() has the problematic pattern and is annotated.

I tried to put the annotation as close as possible to the
critical sections in order to minimize the size requirement
for the reserved area.

> I would be tempted to place them on all the public lock/unlock methods
> of the Lock implementations, rather than on the internal AQS-derived
> functions, and AQS itself.

I've tried that :-) The amount of code being executed with
the ReservedStackAccess privilege tends to increase very
quickly and I was concerned about keeping the size of the
reserved area small.

Fred

>>> On 6/11/2015 12:17 AM, Frederic Parain wrote:
>>>> Please review the changesets for JEP 270: Reserved Stack Areas for
>>>> Critical Sections
>>>>
>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8046936
>>>>
>>>> Webrevs:
>>>>    hotspot:
>>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
>>>>    JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
>>>>
>>>> The CR contains a detailed description of the issue and the design
>>>> of the solution as well as implementation details.
>>>>
>>>> Tests:
>>>>
>>>>      JPRT - hotspot & core
>>>>      RBT - vm.quick
>>>>
>>>> Thanks
>>>>
>>>> Fred
>>>>
>>>
>>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From gerard.ziemski at oracle.com  Tue Nov 10 19:34:21 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Tue, 10 Nov 2015 13:34:21 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
Message-ID: <564246BD.90203@oracle.com>


hi all,

Please review this small fix for JEP-245, which implements range for the last new runtime flag.

     bug: https://bugs.openjdk.java.net/browse/JDK-8141641
  webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0


Thank you.



From christian.thalinger at oracle.com  Tue Nov 10 20:44:48 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 10 Nov 2015 10:44:48 -1000
Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
	variables with CONST_ in product builds
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EB6207@DEWDFEMB12A.global.corp.sap>
References: <16DE31BF-B8B0-44F4-AB0D-E55FFF8EBBEF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5848@DEWDFEMB12A.global.corp.sap>
	<811D98D3-B297-4449-B2F9-7933400EFBBF@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB5D8B@DEWDFEMB12A.global.corp.sap>
	<798CDB11-5DEA-40AF-8AEA-AC2001546A85@oracle.com>
	<4295855A5C1DE049A61835A1887419CC41EB6207@DEWDFEMB12A.global.corp.sap>
Message-ID: <F75AFB0D-2FD0-4C63-ACBA-026A41F65D70@oracle.com>


> On Nov 9, 2015, at 10:41 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Christian,
> 
> The function implementation is protected by #ifdef ASSERT, and the call is protected by #ifndef PRODUCT.
> Without this NOT_DEBUG_RETURN it would not compile in the optimized build.
> Another possibility to fix this is checking for #ifndef PRODUCT in memset_with_concurrent_readers.cpp.
> Looking at it now, it must have been broken before.

Thanks for verifying.  I will push this as is.

> 
> Best regards,
>  Goetz.
> 
> 
> 
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> Sent: Monday, November 09, 2015 6:06 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: hotspot-dev at openjdk.java.net; Stefan Karlsson <stefan.karlsson at oracle.com>
> Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds
> 
> I did verify that our compilers are in fact eliminating all code and Stefan Karlsson made sure some important GC functions still produce the same code.
> 
> On Nov 8, 2015, at 9:40 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:
> 
> Hi Christian,
> 
> thanks for incorporating these cleanups.
> The change still looks good ?.
> 
> Best regards,
>  Goetz.
> 
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> Sent: Freitag, 6. November 2015 18:13
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
> Subject: Re: RFR (S): 8140424: don't prefix developer and notproduct flag variables with CONST_ in product builds
> 
> 
> On Nov 6, 2015, at 1:38 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:
> 
> Hi Christian,
> 
> thanks for doing this change.  It looks good.
> 
> It's good that now notproduct flags are also defined in the product build as constants,
> as it's already the case with debug flags.
> This allows more cleanups in the style you did to compilerDirectives.hpp.
> 
> I had a look at these cleanups, quite a row you can find in this patch:
> http://cr.openjdk.java.net/~goetz/webrevs/8140424-notProd/not_product_cleanups.patch
> 
> That is a very nice cleanup.
> 
> 
> 
> 
> Does it make sense to commit these along with your change?
> 
> It does.  I?ve updated my webrev with your changes:
> 
> http://cr.openjdk.java.net/~twisti/8140424/webrev/
> 
> 
> 
> 
> Best regards,
> Goetz.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Christian Thalinger
> Sent: Freitag, 6. November 2015 07:23
> To: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
> Subject: RFR (S): 8140424: don't prefix developer and notproduct flag
> variables with CONST_ in product builds
> 
> https://bugs.openjdk.java.net/browse/JDK-8140424
> <https://bugs.openjdk.java.net/browse/JDK-8140424>
> http://cr.openjdk.java.net/~twisti/8140424/webrev/
> <http://cr.openjdk.java.net/~twisti/8140424/webrev/>
> 
> When working on JDK-8024545 I added code that prefixes developer and
> notproduct flags with CONST_. I think I did this to be able to access the
> address of these variables for the flag table. But this is not necessary because
> these flag cannot be written anyway.
> 
> I am proposing to remove the CONST_ prefix and define the variables as
> const.
> 


From coleen.phillimore at oracle.com  Tue Nov 10 21:22:55 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 10 Nov 2015 16:22:55 -0500
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564246BD.90203@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com>
Message-ID: <5642602F.50606@oracle.com>


I think the upper range should be much higher.   This sleep is also 
something that keeps the jvm alive if you are debugging and have 
multiple places that crash, and haven't set ShowMessageBoxOnError. 
Setting this flag to something very high will prevent the debugger from 
timing out with:

           err.print_raw_cr("# [ timer expired, abort... ]");

which is really annoying.   I'd almost suggest MAX_INT as the upper 
range, but maybe 60*60*60   60 hours would do.

Thanks,
Coleen

On 11/10/15 2:34 PM, gerard ziemski wrote:
>
> hi all,
>
> Please review this small fix for JEP-245, which implements range for 
> the last new runtime flag.
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>  webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>
>
> Thank you.
>
>


From aleksey.shipilev at oracle.com  Tue Nov 10 22:26:14 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 11 Nov 2015 01:26:14 +0300
Subject: RFR (S) 8140650: Method::is_accessor should cover getters and
	setters for all types
In-Reply-To: <564101E8.8080403@oracle.com>
References: <5638D0D2.5090609@oracle.com> <563B62BC.5090906@oracle.com>
	<563B8262.1040004@oracle.com> <563B87EE.2030007@oracle.com>
	<563B89A3.9000907@oracle.com> <563B8AEF.1090002@oracle.com>
	<563B90B2.9010601@oracle.com> <563B932B.70507@oracle.com>
	<563BB1F7.7050807@oracle.com> <563BB918.9020509@oracle.com>
	<563BBF2C.1040301@oracle.com> <563BC171.7050703@oracle.com>
	<1447091852.3551.36.camel@redhat.com> <5640EB3D.4010302@oracle.com>
	<564101E8.8080403@oracle.com>
Message-ID: <56426F06.20400@oracle.com>

Thanks for re-reviews, Coleen, Vladimir and Severin!

Pushing this through hs-comp now.

-Aleksey

On 11/09/2015 11:28 PM, Coleen Phillimore wrote:
> 
> 
> On 11/9/15 1:51 PM, Aleksey Shipilev wrote:
>> Hi Severin,
>>
>> On 11/09/2015 08:57 PM, Severin Gehwolf wrote:
>>> Here is a partial implementation of the Zero bits. In fact, the code
>>> was already there to handle other getters too. I don't know why it was
>>> guarded with those asserts and with is_simple_accessor().
>>>
>>> It does not yet implement the setter logic, but at least we don't have
>>> to keep is_simple_accessor() around. The patch builds on top of your
>>> latest 8140650/webrev.02/ webrev.
>>>
>>> The patch I'm talking about is:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8140650/JDK-8140650-is_accessor_zero_cleanup.hotspot.patch
>>>
>> Excellent, thanks! Incorporated:
>>    http://cr.openjdk.java.net/~shade/8140650/webrev.03/
>>
>> Coleen, are you still good with these changes?
> 
> Yes, this looks fine.
> 
> I can't see how there's any value performance-wise to implement the
> is_setter entry point in Zero, that would be worth writing the code for
> the setter entry point.
> 
> Coleen
>>
>> The RBT tests (hotspot_all, vm.{gc|regression|runtime}.testlist, and
>> some others) came clean for a previous version, and this version touches
>> only Zero code, so I am inclined to think this change does not need
>> re-testing.
>>
>> Thanks,
>> -Aleksey
>>
> 



From christian.thalinger at oracle.com  Tue Nov 10 23:30:14 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 10 Nov 2015 13:30:14 -1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5642602F.50606@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5642602F.50606@oracle.com>
Message-ID: <2B615442-B9FD-41AF-A5CE-A51E57A18DC7@oracle.com>


> On Nov 10, 2015, at 11:22 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> I think the upper range should be much higher.   This sleep is also something that keeps the jvm alive if you are debugging and have multiple places that crash, and haven't set ShowMessageBoxOnError. Setting this flag to something very high will prevent the debugger from timing out with:
> 
>          err.print_raw_cr("# [ timer expired, abort... ]");
> 
> which is really annoying.

It is!  Since we are talking about this, why do we have that?

>   I'd almost suggest MAX_INT as the upper range, but maybe 60*60*60   60 hours would do.
> 
> Thanks,
> Coleen
> 
> On 11/10/15 2:34 PM, gerard ziemski wrote:
>> 
>> hi all,
>> 
>> Please review this small fix for JEP-245, which implements range for the last new runtime flag.
>> 
>>    bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>> webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>> 
>> 
>> Thank you.
>> 
>> 
> 


From coleen.phillimore at oracle.com  Tue Nov 10 23:42:53 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 10 Nov 2015 18:42:53 -0500
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <2B615442-B9FD-41AF-A5CE-A51E57A18DC7@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5642602F.50606@oracle.com>
	<2B615442-B9FD-41AF-A5CE-A51E57A18DC7@oracle.com>
Message-ID: <564280FD.7090300@oracle.com>



On 11/10/15 6:30 PM, Christian Thalinger wrote:
>> On Nov 10, 2015, at 11:22 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>
>> I think the upper range should be much higher.   This sleep is also something that keeps the jvm alive if you are debugging and have multiple places that crash, and haven't set ShowMessageBoxOnError. Setting this flag to something very high will prevent the debugger from timing out with:
>>
>>           err.print_raw_cr("# [ timer expired, abort... ]");
>>
>> which is really annoying.
> It is!  Since we are talking about this, why do we have that?

There's a comment that this sleeps 2 minutes to allow the hs_err_pid 
file to get printed before exit, which might be necessary, so we 
wouldn't want it to sleep indefinitely in that case.

I #if0 out this code whenever I'm debugging but specifying 
ErrorLogTimeout = very large would be a good workaround.

Coleen
>
>>    I'd almost suggest MAX_INT as the upper range, but maybe 60*60*60   60 hours would do.
>>
>> Thanks,
>> Coleen
>>
>> On 11/10/15 2:34 PM, gerard ziemski wrote:
>>> hi all,
>>>
>>> Please review this small fix for JEP-245, which implements range for the last new runtime flag.
>>>
>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>> webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>
>>>
>>> Thank you.
>>>
>>>


From ioi.lam at oracle.com  Wed Nov 11 00:31:37 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 10 Nov 2015 16:31:37 -0800
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code
	for CDS
In-Reply-To: <56382CC8.9070008@oracle.com>
References: <5633A24A.9070800@oracle.com> <56382CC8.9070008@oracle.com>
Message-ID: <56428C69.1010306@oracle.com>

A "final" webrev (before I go on vacation :-)

      http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v03/

There's a single line changed from the previous webrev:

http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v03/root/modules.xml.sdiff.html

The reason is to allow the use of @CallerSensitive in the jdk.vm.cds module.

Thanks
- Ioi

On 11/2/15 7:40 PM, Ioi Lam wrote:
> Hi,
>
> I have updated the webrev to include all the feedback from the past 
> few days:
>
> Delta from the previous webrev
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/
>
> Full changes
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02/
>
> Change Log:
>
>     + Various formatting and copyright
>     + Change in SystemDictionary::resolve_from_stream to support new
>       requirement in closed sources.
>
> Thanks
> Ioi
>
>
> On 10/30/15 10:00 AM, Ioi Lam wrote:
>> Please review the following fix:
>>
>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>
>> Bug: Clean up and refactor of class loading code for CDS
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8140802
>>
>> Summary of fix:
>>
>>     We need to clean up and refactor the class loading code in order
>>     to support CDS in JDK9
>>
>>     [1] Remove code that has been made obsolete by the module changes
>>         (such as supporting code used for meta-index file)
>>     [2] Add new whitebox API to be used by CDS-related tests.
>>     [3] Refactor the parsing of classlist files for future enhancements.
>>     [4] Add new APIs in the class loading code to support Oracle CDS 
>> enhancements.
>>
>> Tests:
>>
>>     JPRT
>>     RBT - with same set of tests as hs-rt nightly
>>
>> Thanks
>> - Ioi
>


From jiangli.zhou at Oracle.COM  Wed Nov 11 01:19:33 2015
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Tue, 10 Nov 2015 17:19:33 -0800
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <564229E1.1070500@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com>
Message-ID: <53494D86-7466-4D88-9C49-22A3D443E672@oracle.com>

Hi Gerard,

The changes looks good. Thank you for moving all Shared*** flags' values in one place! I have a few comments below.

For the MIN_SHARED_MISC_DATA_SIZE & MIN_SHARED_MISC_CODE_SIZE, the original check in metaspace.cpp align the computed values to os::vm_allocation_granularity(). Any reason why the alignment requirement is removed for the new values defined in metaspaceShared.hpp?

For the following MAX values, it seems they should be calculated using the MIN_SHARED_READ_WRITE_SIZE, MIN_SHARED_READ_ONLY_SIZE, MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE instead of the DEFAULT values since the runtime flags? setting can be smaller than the default values? Does that sound reasonable?

  71 #define MAX_SHARED_READ_WRITE_SIZE      (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
  72 #define MAX_SHARED_READ_ONLY_SIZE       (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
  73 #define MAX_SHARED_MISC_DATA_SIZE       (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
  74 #define MAX_SHARED_MISC_CODE_SIZE       (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE)-SHARED_PAGE)
You probably have already done it, it would be good to verify the changes pass all the test in hotspot/test/runtime/SharedArchiveFile on all platforms.

Thanks,

Jiangli

> On Nov 10, 2015, at 9:31 AM, gerard ziemski <gerard.ziemski at oracle.com> wrote:
> 
> hi all,
> 
> I have updated the fix with rev2, incorporating feedback from David:
> 
> - Move the metaspace constants back into metaspace code
> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
> 
> http://cr.openjdk.java.net/~gziemski/8138983_rev2
> 
> 
> cheers
> 
> 
> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>> hi all,
>> 
>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>> 
>> - Fix comments and indentation
>> - Add "-XShare:dump" while testing Shared* flags
>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>> 
>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>> 
>> 
>> 
>> cheers
>> 
>> 
>> 
>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>> 
>>> hi all,
>>> 
>>> Please review this final fix for JEP-245
>>> 
>>> We implement the remaining runtime flags in the Shared* family.
>>> 
>>> Summary of changes:
>>> 
>>> #1 core fix - we factor out the constants to be used in the ranges
>>> 
>>> src/share/vm/classfile/compactHashtable.cpp
>>> src/share/vm/memory/metaspace.cpp
>>> src/share/vm/memory/metaspaceShared.hpp
>>> src/share/vm/runtime/globals.hpp
>>> 
>>> 
>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>> 
>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>> 
>>> 
>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>> 
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>> 
>>> 
>>> #4 we add functionality to OptionsValidation test framework that we later use
>>> 
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>> 
>>> 
>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>> 
>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>> 
>>> 
>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>> tests
>>> 
>>> References:
>>> 
>>>     bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>  open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>> 
>>> 
>>> hg_stat:
>>> 
>>>  src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>>  src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>>  src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>>  src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>>  src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>>  src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>  test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>>  9 files changed, 242 insertions(+), 141 deletions(-)
>> 


From vladimir.kozlov at oracle.com  Wed Nov 11 01:26:54 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 10 Nov 2015 17:26:54 -0800
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <5641D1AC.9010803@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com> <1447151388.2371.24.camel@oracle.com>
	<5641D1AC.9010803@oracle.com>
Message-ID: <5642995E.7020105@oracle.com>

Good.

Thanks,
Vladimir

On 11/10/15 3:14 AM, Stefan Karlsson wrote:
> Hi Thomas,
>
> Thanks for reviewing. Here's the updated patches:
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.03
>   http://cr.openjdk.java.net/~stefank/8140584/webrev.03.delta
>
> Thanks,
> StefanK
>
> On 2015-11-10 11:29, Thomas Schatzl wrote:
>> On Mon, 2015-11-09 at 10:34 +0100, Stefan Karlsson wrote:
>>> Hi Vladimir,
>>>
>>> What do you think about this version:
>>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
>>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/
>>>
>>> Thanks,
>>> StefanK
>>   in relocInfo_x86.cpp, line 70 and 77: shouldn't these asserts be
>> guarantees too?
>>
>> Also, the assert in NativeInstruction::verify_data64_sethi() in
>> relocInfo_sparc.cpp needs to be a guarantee, as it is called by
>> Relocation::pd_set_data_value().
>>
>> I also grepped the code for more "verify_only" parameters, and they also
>> use asserts instead of guarantees.
>> Like Relocation::pd_set_data_value() in relocInfo_aarch64.cpp,
>> relocInfo_ppc.cpp, in PhaseIdealLoop::build_and_optimize() in
>> loopnode.cpp.
>>
>> Although I think the one in PhaseIdealLoop::build_and_optimize() is not
>> executed via nmethod::oops_do_marking_epilogue().
>>
>> Thanks,
>>    Thomas
>>
>>
>

From jiangli.zhou at Oracle.COM  Wed Nov 11 01:26:57 2015
From: jiangli.zhou at Oracle.COM (Jiangli Zhou)
Date: Tue, 10 Nov 2015 17:26:57 -0800
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for
	CDS
In-Reply-To: <56428C69.1010306@oracle.com>
References: <5633A24A.9070800@oracle.com> <56382CC8.9070008@oracle.com>
	<56428C69.1010306@oracle.com>
Message-ID: <6DA40342-8A8D-445A-B5C9-C26C4337105A@oracle.com>

Hi Ioi,

No further comment for the hotspot changes. They look good to me.

Thanks,
Jiangli

> On Nov 10, 2015, at 4:31 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> A "final" webrev (before I go on vacation :-)
> 
>     http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v03/
> 
> There's a single line changed from the previous webrev:
> 
> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v03/root/modules.xml.sdiff.html
> 
> The reason is to allow the use of @CallerSensitive in the jdk.vm.cds module.
> 
> Thanks
> - Ioi
> 
> On 11/2/15 7:40 PM, Ioi Lam wrote:
>> Hi,
>> 
>> I have updated the webrev to include all the feedback from the past few days:
>> 
>> Delta from the previous webrev
>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/
>> 
>> Full changes
>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02/
>> 
>> Change Log:
>> 
>>    + Various formatting and copyright
>>    + Change in SystemDictionary::resolve_from_stream to support new
>>      requirement in closed sources.
>> 
>> Thanks
>> Ioi
>> 
>> 
>> On 10/30/15 10:00 AM, Ioi Lam wrote:
>>> Please review the following fix:
>>> 
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>> 
>>> Bug: Clean up and refactor of class loading code for CDS
>>> 
>>>    https://bugs.openjdk.java.net/browse/JDK-8140802
>>> 
>>> Summary of fix:
>>> 
>>>    We need to clean up and refactor the class loading code in order
>>>    to support CDS in JDK9
>>> 
>>>    [1] Remove code that has been made obsolete by the module changes
>>>        (such as supporting code used for meta-index file)
>>>    [2] Add new whitebox API to be used by CDS-related tests.
>>>    [3] Refactor the parsing of classlist files for future enhancements.
>>>    [4] Add new APIs in the class loading code to support Oracle CDS enhancements.
>>> 
>>> Tests:
>>> 
>>>    JPRT
>>>    RBT - with same set of tests as hs-rt nightly
>>> 
>>> Thanks
>>> - Ioi
>> 
> 


From david.holmes at oracle.com  Wed Nov 11 02:43:50 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Nov 2015 12:43:50 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564246BD.90203@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com>
Message-ID: <5642AB66.9000705@oracle.com>

On 11/11/2015 5:34 AM, gerard ziemski wrote:
>
> hi all,
>
> Please review this small fix for JEP-245, which implements range for the
> last new runtime flag.
>
>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0

This seems an artificial constraint. Why should I not be able to specify 
0 or UINT_MAX? A range check is for validity not sensibility, and all 
values are valid here.

David

>
> Thank you.
>
>

From stefan.karlsson at oracle.com  Wed Nov 11 07:42:11 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 11 Nov 2015 08:42:11 +0100
Subject: RFR: 8140584: nmethod::oops_do_marking_epilogue always runs
	verification code
In-Reply-To: <5642995E.7020105@oracle.com>
References: <562F6383.4090707@oracle.com> <562F96A1.7020409@oracle.com>
	<563240C6.4030402@oracle.com> <56332DE8.8060904@oracle.com>
	<564068A7.802@oracle.com> <1447151388.2371.24.camel@oracle.com>
	<5641D1AC.9010803@oracle.com> <5642995E.7020105@oracle.com>
Message-ID: <5642F153.4030201@oracle.com>

Thanks, Vladimir.

StefanK

On 2015-11-11 02:26, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 11/10/15 3:14 AM, Stefan Karlsson wrote:
>> Hi Thomas,
>>
>> Thanks for reviewing. Here's the updated patches:
>>   http://cr.openjdk.java.net/~stefank/8140584/webrev.03
>>   http://cr.openjdk.java.net/~stefank/8140584/webrev.03.delta
>>
>> Thanks,
>> StefanK
>>
>> On 2015-11-10 11:29, Thomas Schatzl wrote:
>>> On Mon, 2015-11-09 at 10:34 +0100, Stefan Karlsson wrote:
>>>> Hi Vladimir,
>>>>
>>>> What do you think about this version:
>>>>    http://cr.openjdk.java.net/~stefank/8140584/webrev.02/
>>>> http://cr.openjdk.java.net/~stefank/8140584/webrev.02.delta/
>>>>
>>>> Thanks,
>>>> StefanK
>>>   in relocInfo_x86.cpp, line 70 and 77: shouldn't these asserts be
>>> guarantees too?
>>>
>>> Also, the assert in NativeInstruction::verify_data64_sethi() in
>>> relocInfo_sparc.cpp needs to be a guarantee, as it is called by
>>> Relocation::pd_set_data_value().
>>>
>>> I also grepped the code for more "verify_only" parameters, and they 
>>> also
>>> use asserts instead of guarantees.
>>> Like Relocation::pd_set_data_value() in relocInfo_aarch64.cpp,
>>> relocInfo_ppc.cpp, in PhaseIdealLoop::build_and_optimize() in
>>> loopnode.cpp.
>>>
>>> Although I think the one in PhaseIdealLoop::build_and_optimize() is not
>>> executed via nmethod::oops_do_marking_epilogue().
>>>
>>> Thanks,
>>>    Thomas
>>>
>>>
>>


From david.holmes at oracle.com  Wed Nov 11 08:19:19 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Nov 2015 18:19:19 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5641D452.6040503@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
	<5641D452.6040503@oracle.com>
Message-ID: <5642FA07.8050309@oracle.com>

Hi Thomas,

Okay here's the next revision:

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v5/

I've reinstated a basic ThreadLocalStorage class which will only need 
two implementations: a POSIX one, and a Windows one (still TBD). This 
class is always initialized and ThreadLocalStorage::thread() is used 
from the signal handlers (as today).

For platforms that don't have __thread support they can define 
USE_LIBRARY_BASED_TLS_ONLY at build time to only use the 
ThreadLocalStorage implementation.

Obviously still need to get some performance numbers.

I'd appreciate it if you could retest AIX, though as all platforms 
currently use pthread_get/setspecific I'm confident there will be no 
platform issues.

Thanks,
David

From dmitry.dmitriev at oracle.com  Wed Nov 11 08:27:45 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 11 Nov 2015 00:27:45 -0800 (PST)
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
Message-ID: <c2f4cc3f-f0b2-4e55-ba46-5f0cc325f1ea@default>

Hello David,

I think that UINT_MAX upper range is not quite correct, because ErrorLogTimeout value is multiplied on 1000 and we can get overflow. Thus, more accurate is UINT_MAX / 1000. 
>From the other hand, os::sleep second argument have type 'jlong'. And very big ErrorLogTimeout values can become negative after converting to the 'jlong'. In this case I think that upper range should be something like that: 'max_jlong / 1000'

Thanks,
Dmitry


----- Original Message -----
From: david.holmes at oracle.com
To: gerard.ziemski at oracle.com, hotspot-dev at openjdk.java.net
Sent: Wednesday, November 11, 2015 5:44:17 AM GMT +03:00 Iraq
Subject: Re: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout

On 11/11/2015 5:34 AM, gerard ziemski wrote:
>
> hi all,
>
> Please review this small fix for JEP-245, which implements range for the
> last new runtime flag.
>
>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0

This seems an artificial constraint. Why should I not be able to specify 
0 or UINT_MAX? A range check is for validity not sensibility, and all 
values are valid here.

David

>
> Thank you.
>
>

From marcus at lagergren.net  Wed Nov 11 08:35:53 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Wed, 11 Nov 2015 09:35:53 +0100
Subject: JFokus VM Tech Day 2016
Message-ID: <809E0327-271A-4985-B7E1-F02004500F34@lagergren.net>

Greetings community members!

I am coordinator for the JFokus VM Tech Day at the JFokus conference in February 2016. This is the second year running we have this event, and it was a great success last year. This year we have received significantly more contributions, and the hardest part was sifting through all quality material that we were given.

We are in the process of finalizing the speaker list, but 5 out of 6 slots are now filled and the current agenda looks like this: https://www.jfokus.se/jfokus/jvmtech.jsp

This year, Brian Goetz, Java Language Architect from Oracle opens the tech day, and talks about project Valhalla and how the OpenJDK is getting there.

Brian is followed by Charlie Gracie, IBM, who will cover what is some of the most exciting news in the runtime world for a very long time: The open sourcing of the J9 JVM and its APIs, and example applications in the dynamic language space.

We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, performance czar extraordinare, always balancing on the fine line between brilliant and crazy. Aleksey's presentation is about String compaction, and String optimisations with invokedynamic in Java 9. Hopefully we have room for him at the ordinary JFokus conference as well, as the man spouts excellent tech presentations like a fountain.

Charlie Nutter also joins us to discuss JRuby 9000, which was released this summer, and about using the JVM as a platform for multi language development.

Paul Sandoz, a man who can do anything from REST services down to bare silicone magic in his job, will tell us about how VarHandles are implemented in the JVM, performance aspects and why no one should miss sun.misc.Unsafe.

Our sixth and final speaker slot is being allocated real soon now. Watch this space.

As usual there is time allocated for breakout sessions, improvised unscheduled lightning talks and discussions / Q&A.

Join the best VM internals conference initiative since JVMLS, and the first of its kind in the old world.

Regards
Marcus Lagergren


From david.holmes at oracle.com  Wed Nov 11 08:36:12 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Nov 2015 18:36:12 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <c2f4cc3f-f0b2-4e55-ba46-5f0cc325f1ea@default>
References: <c2f4cc3f-f0b2-4e55-ba46-5f0cc325f1ea@default>
Message-ID: <5642FDFC.4000501@oracle.com>

Hi Dmitry,

On 11/11/2015 6:27 PM, Dmitry Dmitriev wrote:
> Hello David,
>
> I think that UINT_MAX upper range is not quite correct, because ErrorLogTimeout value is multiplied on 1000 and we can get overflow. Thus, more accurate is UINT_MAX / 1000.
>  From the other hand, os::sleep second argument have type 'jlong'. And very big ErrorLogTimeout values can become negative after converting to the 'jlong'. In this case I think that upper range should be something like that: 'max_jlong / 1000'

Not sure how a 32-bit UINT can overflow a 64-bit jlong? But this:

    os::sleep(this, ErrorLogTimeout * 1000, false); // in seconds

should be:

    os::sleep(this, ErrorLogTimeout * CONST_64(1000), false); // in seconds

to avoid the negative values.

Thanks,
David

> Thanks,
> Dmitry
>
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: gerard.ziemski at oracle.com, hotspot-dev at openjdk.java.net
> Sent: Wednesday, November 11, 2015 5:44:17 AM GMT +03:00 Iraq
> Subject: Re: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
>
> On 11/11/2015 5:34 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for the
>> last new runtime flag.
>>
>>       bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>    webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>
> This seems an artificial constraint. Why should I not be able to specify
> 0 or UINT_MAX? A range check is for validity not sensibility, and all
> values are valid here.
>
> David
>
>>
>> Thank you.
>>
>>

From dmitry.dmitriev at oracle.com  Wed Nov 11 08:44:26 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 11 Nov 2015 00:44:26 -0800 (PST)
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
Message-ID: <81cfc3d9-5d4b-4e3e-aaaa-642e30be546d@default>

David,

You are right! I read "UINT_MAX" as "UINTX_MAX".

Thanks,
Dmitry

----- Original Message -----
From: david.holmes at oracle.com
To: dmitry.dmitriev at oracle.com
Cc: gerard.ziemski at oracle.com, hotspot-dev at openjdk.java.net
Sent: Wednesday, November 11, 2015 11:36:23 AM GMT +03:00 Iraq
Subject: Re: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout

Hi Dmitry,

On 11/11/2015 6:27 PM, Dmitry Dmitriev wrote:
> Hello David,
>
> I think that UINT_MAX upper range is not quite correct, because ErrorLogTimeout value is multiplied on 1000 and we can get overflow. Thus, more accurate is UINT_MAX / 1000.
>  From the other hand, os::sleep second argument have type 'jlong'. And very big ErrorLogTimeout values can become negative after converting to the 'jlong'. In this case I think that upper range should be something like that: 'max_jlong / 1000'

Not sure how a 32-bit UINT can overflow a 64-bit jlong? But this:

    os::sleep(this, ErrorLogTimeout * 1000, false); // in seconds

should be:

    os::sleep(this, ErrorLogTimeout * CONST_64(1000), false); // in seconds

to avoid the negative values.

Thanks,
David

> Thanks,
> Dmitry
>
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: gerard.ziemski at oracle.com, hotspot-dev at openjdk.java.net
> Sent: Wednesday, November 11, 2015 5:44:17 AM GMT +03:00 Iraq
> Subject: Re: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
>
> On 11/11/2015 5:34 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for the
>> last new runtime flag.
>>
>>       bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>    webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>
> This seems an artificial constraint. Why should I not be able to specify
> 0 or UINT_MAX? A range check is for validity not sensibility, and all
> values are valid here.
>
> David
>
>>
>> Thank you.
>>
>>

From aph at redhat.com  Wed Nov 11 10:56:43 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Nov 2015 10:56:43 +0000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56413267.6000001@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
	<563C5B5B.9060802@oracle.com>
	<CAPYFHW3OJ2rUMrHFY4CiCPpVMfhZ=TSMrBwDsxX9kgnMLnL00w@mail.gmail.com>
	<563FD29A.3060103@oracle.com> <56413267.6000001@oracle.com>
Message-ID: <56431EEB.7090705@redhat.com>

On 09/11/15 23:55, David Holmes wrote:
> On 9/11/2015 8:54 AM, David Holmes wrote:
>
> Just to keep my thinking straight on this, the problem only exists for 
> threads that existed before the JVM was loaded. All threads allocated 
> after that will have space for all the TLS variables allocated directly. 
> So the problem scenario is:
> 
> - external process with existing threads loads the JVM
> - existing thread is executing critical library function eg malloc, when 
> it takes a process-directed signal.
> - JVM signal handler runs and accesses _thr_current which triggers 
> dynamic TLS allocation

Why not simply use pthread_* thread-local storage, but only in the
signal handler?  That would avoid the (fairly unlikely) race
condition, at very little cost.  Sure, we'd have to use
pthread_setspecific() when attaching a thread, but that's no big deal.

Andrew.

From thomas.stuefe at gmail.com  Wed Nov 11 15:03:44 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Nov 2015 16:03:44 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56431EEB.7090705@redhat.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAPYFHW3mE2zApSCVAohz9nt3SWOqA9MBLGBUk2jk52bFkkg4qw@mail.gmail.com>
	<563C5B5B.9060802@oracle.com>
	<CAPYFHW3OJ2rUMrHFY4CiCPpVMfhZ=TSMrBwDsxX9kgnMLnL00w@mail.gmail.com>
	<563FD29A.3060103@oracle.com> <56413267.6000001@oracle.com>
	<56431EEB.7090705@redhat.com>
Message-ID: <CAA-vtUzW1MagC5maATuco=ntMP7SPD-aZaBzRTEXoumjjBQ9kQ@mail.gmail.com>

On Wed, Nov 11, 2015 at 11:56 AM, Andrew Haley <aph at redhat.com> wrote:

> On 09/11/15 23:55, David Holmes wrote:
> > On 9/11/2015 8:54 AM, David Holmes wrote:
> >
> > Just to keep my thinking straight on this, the problem only exists for
> > threads that existed before the JVM was loaded. All threads allocated
> > after that will have space for all the TLS variables allocated directly.
> > So the problem scenario is:
> >
> > - external process with existing threads loads the JVM
> > - existing thread is executing critical library function eg malloc, when
> > it takes a process-directed signal.
> > - JVM signal handler runs and accesses _thr_current which triggers
> > dynamic TLS allocation
>
> Why not simply use pthread_* thread-local storage, but only in the
> signal handler?  That would avoid the (fairly unlikely) race
> condition, at very little cost.  Sure, we'd have to use
> pthread_setspecific() when attaching a thread, but that's no big deal.
>
>
This could work. So, initialize both the pthread TLS slot and the __thread
variable on thread creation. We could name them Thread::current and
Thread::current_safe or similar.

However, we still do not know how big the performance advantage is in using
__thread over pthread_getspecific(). May not even worth all the trouble of
using __thread.

Thomas


> Andrew.
>

From keithgchapman at gmail.com  Wed Nov 11 15:08:49 2015
From: keithgchapman at gmail.com (Keith Chapman)
Date: Wed, 11 Nov 2015 10:08:49 -0500
Subject: [7u] Any options in the hotspot compiler to force recompilation?
Message-ID: <CAKVtN-7-8kYt2u+bqVP+8NfLxVKJsUG1qFnDerpJBk4etdNWhQ@mail.gmail.com>

Hi,

I'm working on a project that uses  openjdk-7u40 where I want to run
everything compiled and calling into compiled methods directly. I attemt
this by running the program with -XX:-UseInterpreter (I've also tried
-Xcomp -Xbatch). Assume I have the following code

public static void main(String[] args) {
    A();
}

public static void A() {
    B();
}

public static void B() {

}

As A gets compiled before B in the above case, the compiled code of A does
not have a direct call to the compiled code of B. It goes through a stub.
If I modify the main method slightly as follows,

public static void main(String[] args) {
    B();
    A();
}

then A directly calls the compiled version of the method of B (As B gets
compiled before A). Are there any options in the compiler that I could turn
on so that it always jumps into the compiled code rather than the stub?
Some option to force recompilation may be?

Thanks,
keith.

From vladimir.x.ivanov at oracle.com  Wed Nov 11 15:43:26 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 11 Nov 2015 18:43:26 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
Message-ID: <5643621E.9060206@oracle.com>

Coleen, John, thanks for the feedback!

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.03/

* Added InstanceKlass::dependencies()

* Removed the fields from vmStructs since they aren't used in SA 
(tmtools tests passed).

* Added missing includes in dependencyContext.hpp. Previous version 
built fine (even w/o precompiled headers), but I think it worked due to 
header inclusion order.

* Added verification of CallSite oop validity across DependencyContext 
lifetime.

Though previous comments were focused on dependency management code 
refactoring, I'd like to hear opinions about the fix itself - dependency 
management changes for j.l.i.CallSites to avoid modifications during 
concurrent traversals by GC threads.

Quote from the original request:
  "The fix I propose is to avoid purging of CallSiteContext contexts at 
all during GC, but remove stale entries during dependency list updates 
which happen under CodeCache lock (see safe_to_purge() check in 
methodHandles.cpp). It happens outside of safepoints and it guarantees 
exclusive access to the list. It is performed during 
j.l.i.CallSite.target updates, CallSite.target inlining, j.l.Class 
unloading, etc. Such approach allows to avoid unbounded memory 
consumption growth, only some delay (till next dependency list update) 
in memory deallocation."

Best regards,
Vladimir Ivanov

On 11/10/15 5:37 AM, John Rose wrote:
> I think this expression occurs too many times:
>    DependencyContext dep_context(&_dep_context);
>
> It would look better if factored into an access method:
>    inline DependencyContext InstanceKlass::dependencies() {
>      DependencyContext dep_context(&_dep_context);
>      return dep_context;
>    }
>
> That way the raw machine word InstanceKlass::_dep_context can be isolated.
> CallSiteContext::vmdependencies already does the corresponding move for CallSite.
> (I understand that you don't want to make ik.hpp depend on dc.hpp.
> Just put forward declarations of Deps and IK::deps in ik.hpp.)
>
> Mild suggestion:  Add a constructor parameter to capture the base oop (of the callsite, or null for the IK).
> Use it only in debug mode to check for GC changes.  Or sample a global GC or safepoint count.
> The point is that the lifetime of the Deps object should not extend beyond the next safepoint.
>
> I agree with Coleen:  This is a good refactor.
>
> Reviewed.
>
> ? John
>
> On Nov 6, 2015, at 5:03 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> Thanks, Coleen!
>>
>> Updated version:
>>   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.02/
>>
>>> I think DependencyContext is big enough to be a new file, and not be
>>> added to instanceKlass.hpp.  There are too many unrelated things in
>>> instanceKlass.
>> Agree. Moved it to src/share/vm/code/dependencyContext.[ch]pp
>>
>>> The hidden bit stuff is ok in InstanceKlass.  Does
>>> has_unloaded_dependent accessed concurrently like
>>> _is_marked_dependent?
>> Good point. DependencyContext::remove_dependent_nmethod should set has_stale_entries in a thread safe manner (added Atomic::xchg_ptr call).
>> It is not needed when the flag is cleared.
>>
>>> It would be nice to move _is_marked_dependent
>>> field also to encapsulate it but that would ruin your bit packing.
>> There's a spare bit to use, but I think _is_marked_dependent is specific to InstanceKlass and should remain there. It doesn't have any meaning for CallSite dependencies.
>>
>>> Also, since you have changes to vmStructs, do you have duplicate changes
>>> to make to the serviceability agent code?  Are there duplicate changes
>>> for the jvmci code?
>> I haven't found any mentions of _has_unloaded_dependent or _dependencies fields in SA or JVMCI code. Do you think it is an overlook on SA side and I should add it?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/5/15 1:54 PM, Vladimir Ivanov wrote:
>>>> Updated version:
>>>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/
>>>>
>>>> In addition to name polishing and encapsulating purging logic in
>>>> {add|remove}_dependent_nmethod methods, I got rid of
>>>> DependencyContext::wipe() method and added "friend class
>>>> TestDependencyContext" declaration (noticed such practice in other
>>>> cases when tests need access to tested class internals).
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
>>>>> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>>>>>> Regarding internal purging, add_dependent_methods doesn't iterate over
>>>>>> the whole list, but looks for the relevant entry. It means that "purge"
>>>>>> flag should force full iteration. I think that keeping them separately
>>>>>> (add_dependent_methods() vs purge()) looks cleaner.
>>>>>
>>>>> I think it is better to encapsulate the "piggybacking" behavior within
>>>>> the DependencyContext itself, because that seems to be a
>>>>> general/expected feature of DependencyContext class. It is weird to ask
>>>>> class users to spell it out specifically.
>>>>>
>>>>>
>>>>>> I could add "purge" flag and move the following code into
>>>>>> add_dependent_methods:
>>>>>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool
>>>>>> do_purge
>>>>>> = false) {
>>>>>>     ...
>>>>>>     if (has_unloaded_dependent() && do_purge) {
>>>>>>       purge();
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> Is it what you are suggesting?
>>>>>
>>>>> Yes.
>>>>>
>>>>>
>>>>>>>    * DependencyContext now has three methods: purge(), clear(),
>>>>>>> wipe(). I
>>>>>>> have trouble understanding which method does what!
>>>>>
>>>>>> There are basically 2 operations needed:
>>>>>>    * purge(): only remove stale entries; no additional work is
>>>>>> performed;
>>>>>
>>>>> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>>>>>   WeakHashMap.expungeStaleEntries()
>>>>>   ThreadLocal.expungeStaleEntries()
>>>>>   WeakCache.expungeStaleEntries()
>>>>>
>>>>>
>>>>>> wipe() is only for unit-testing purposes (see TestNmethodBucket): it
>>>>>> just deallocates all nmethodBucket entries without touching
>>>>>> nmethods. It
>>>>>> is necessary since nmethod pointers are faked by the test.
>>>>>
>>>>> Okay. Is there a convention how you should name the test-related methods
>>>>> like these? I would expect something like debug_deallocate_buckets().
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>
>>>>>
>>>
>

From thomas.stuefe at gmail.com  Wed Nov 11 16:36:50 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Nov 2015 17:36:50 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5642FA07.8050309@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
	<5641D452.6040503@oracle.com> <5642FA07.8050309@oracle.com>
Message-ID: <CAA-vtUzHSqTN-SW_Ew98pWJH3uqpty=RzUC+0ws2Y87ePxP3Fw@mail.gmail.com>

Hi David,

I get build errors on all my platforms.

I think the change misses #include "runtime/threadLocalStorage.hpp" in a
couple of places, at least thread.cpp and possible also the os_xx_yy.cpp
files.

Will take another look tomorrow.

Thanks, Thomas

On Wed, Nov 11, 2015 at 9:19 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> Okay here's the next revision:
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v5/
>
> I've reinstated a basic ThreadLocalStorage class which will only need two
> implementations: a POSIX one, and a Windows one (still TBD). This class is
> always initialized and ThreadLocalStorage::thread() is used from the signal
> handlers (as today).
>
> For platforms that don't have __thread support they can define
> USE_LIBRARY_BASED_TLS_ONLY at build time to only use the ThreadLocalStorage
> implementation.
>
> Obviously still need to get some performance numbers.
>
> I'd appreciate it if you could retest AIX, though as all platforms
> currently use pthread_get/setspecific I'm confident there will be no
> platform issues.
>
> Thanks,
> David
>

From thomas.stuefe at gmail.com  Wed Nov 11 16:47:00 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Nov 2015 17:47:00 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUzHSqTN-SW_Ew98pWJH3uqpty=RzUC+0ws2Y87ePxP3Fw@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
	<5641D452.6040503@oracle.com> <5642FA07.8050309@oracle.com>
	<CAA-vtUzHSqTN-SW_Ew98pWJH3uqpty=RzUC+0ws2Y87ePxP3Fw@mail.gmail.com>
Message-ID: <CAA-vtUxORNG_FLjP_bF7E5m9v=mSnMEOajo6e-XUeea5JgE0cQ@mail.gmail.com>

On Wed, Nov 11, 2015 at 5:36 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> I get build errors on all my platforms.
>
> I think the change misses #include "runtime/threadLocalStorage.hpp" in a
> couple of places, at least thread.cpp and possible also the os_xx_yy.cpp
> files.
>
>
Sorry, I have to correct myself. It is a linker error, I do not find the
implementations for the ThreadLocalStorage class methods anywhere. I
applied your patch atop a freshly synced hs-rt repo:

- .../hotspot $ hg log -l 3
changeset:   9317:3b23f69bc887 8132510__thread_davids_change qbase qtip tip
user:        stuefe
date:        Wed Nov 11 16:12:14 2015 +0100
summary:     imported patch 8132510__thread_davids_change

changeset:   9316:f17e5edbe761 qparent
user:        tschatzl
date:        Tue Nov 10 11:07:15 2015 +0100
summary:     8140689: Skip last young-only gc if nothing to do in the mixed
gc phase
Reviewed-by: mgerdin, drwhite

on AIX I get:

ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::thread()
ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::is_initialized()
ld: 0711-317 ERROR: Undefined symbol:
.ThreadLocalStorage::set_thread(Thread*)
ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::init()

Am I building wrong?

Regards, Thomas



> Will take another look tomorrow.
>
> Thanks, Thomas
>
> On Wed, Nov 11, 2015 at 9:19 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> Okay here's the next revision:
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v5/
>>
>> I've reinstated a basic ThreadLocalStorage class which will only need two
>> implementations: a POSIX one, and a Windows one (still TBD). This class is
>> always initialized and ThreadLocalStorage::thread() is used from the signal
>> handlers (as today).
>>
>> For platforms that don't have __thread support they can define
>> USE_LIBRARY_BASED_TLS_ONLY at build time to only use the ThreadLocalStorage
>> implementation.
>>
>> Obviously still need to get some performance numbers.
>>
>> I'd appreciate it if you could retest AIX, though as all platforms
>> currently use pthread_get/setspecific I'm confident there will be no
>> platform issues.
>>
>> Thanks,
>> David
>>
>
>

From karen.kinnear at oracle.com  Wed Nov 11 16:51:36 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 11 Nov 2015 11:51:36 -0500
Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for
	CDS
In-Reply-To: <6DA40342-8A8D-445A-B5C9-C26C4337105A@oracle.com>
References: <5633A24A.9070800@oracle.com> <56382CC8.9070008@oracle.com>
	<56428C69.1010306@oracle.com>
	<6DA40342-8A8D-445A-B5C9-C26C4337105A@oracle.com>
Message-ID: <E02FAF8D-0181-4747-85CC-D18CA2BBF83B@oracle.com>

They all look good to me.

thanks,
Karen

> On Nov 10, 2015, at 8:26 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
> 
> Hi Ioi,
> 
> No further comment for the hotspot changes. They look good to me.
> 
> Thanks,
> Jiangli
> 
>> On Nov 10, 2015, at 4:31 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>> 
>> A "final" webrev (before I go on vacation :-)
>> 
>>    http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v03/
>> 
>> There's a single line changed from the previous webrev:
>> 
>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v03/root/modules.xml.sdiff.html
>> 
>> The reason is to allow the use of @CallerSensitive in the jdk.vm.cds module.
>> 
>> Thanks
>> - Ioi
>> 
>> On 11/2/15 7:40 PM, Ioi Lam wrote:
>>> Hi,
>>> 
>>> I have updated the webrev to include all the feedback from the past few days:
>>> 
>>> Delta from the previous webrev
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/
>>> 
>>> Full changes
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02/
>>> 
>>> Change Log:
>>> 
>>>   + Various formatting and copyright
>>>   + Change in SystemDictionary::resolve_from_stream to support new
>>>     requirement in closed sources.
>>> 
>>> Thanks
>>> Ioi
>>> 
>>> 
>>> On 10/30/15 10:00 AM, Ioi Lam wrote:
>>>> Please review the following fix:
>>>> 
>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>>> 
>>>> Bug: Clean up and refactor of class loading code for CDS
>>>> 
>>>>   https://bugs.openjdk.java.net/browse/JDK-8140802
>>>> 
>>>> Summary of fix:
>>>> 
>>>>   We need to clean up and refactor the class loading code in order
>>>>   to support CDS in JDK9
>>>> 
>>>>   [1] Remove code that has been made obsolete by the module changes
>>>>       (such as supporting code used for meta-index file)
>>>>   [2] Add new whitebox API to be used by CDS-related tests.
>>>>   [3] Refactor the parsing of classlist files for future enhancements.
>>>>   [4] Add new APIs in the class loading code to support Oracle CDS enhancements.
>>>> 
>>>> Tests:
>>>> 
>>>>   JPRT
>>>>   RBT - with same set of tests as hs-rt nightly
>>>> 
>>>> Thanks
>>>> - Ioi
>>> 
>> 
> 


From gerard.ziemski at oracle.com  Wed Nov 11 16:56:37 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 11 Nov 2015 10:56:37 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5642AB66.9000705@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5642AB66.9000705@oracle.com>
Message-ID: <56437345.40702@oracle.com>

Good point - the goal of the feature is not to allow a crash, and in this case range of 0..UINT_MAX works.

Thank you for the review.


cheers

On 11/10/2015 08:43 PM, David Holmes wrote:
> On 11/11/2015 5:34 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for the
>> last new runtime flag.
>>
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>
> This seems an artificial constraint. Why should I not be able to specify 0 or UINT_MAX? A range check is for validity
> not sensibility, and all values are valid here.
>
> David

From gerard.ziemski at oracle.com  Wed Nov 11 17:22:11 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 11 Nov 2015 11:22:11 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <53494D86-7466-4D88-9C49-22A3D443E672@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com>
	<53494D86-7466-4D88-9C49-22A3D443E672@oracle.com>
Message-ID: <56437943.4060103@oracle.com>

hi Jiangli,

Thank you very much for the review. Please see my answers in-line:

On 11/10/2015 07:19 PM, Jiangli Zhou wrote:
> Hi Gerard,
>
> The changes looks good. Thank you for moving all Shared*** flags' values in one place! I have a few comments below.
>
> For the MIN_SHARED_MISC_DATA_SIZE & MIN_SHARED_MISC_CODE_SIZE, the original check in metaspace.cpp align the computed
> values to os::vm_allocation_granularity(). Any reason why the alignment requirement is removed for the new values
> defined in metaspaceShared.hpp?

The range function compares the min with the value before any alignment takes place, so we're good (we're not mixing 
comparison of aligned vs unaligned values here), but good question. The values later do get aligned when assigned locally.


>
> For the following MAX values, it seems they should be calculated using
> the MIN_SHARED_READ_WRITE_SIZE, MIN_SHARED_READ_ONLY_SIZE, MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE
> instead of the DEFAULT values since the runtime flags? setting can be smaller than the default values? Does that sound
> reasonable?
>
> 71 #define MAX_SHARED_READ_WRITE_SIZE
> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
> 72 #define MAX_SHARED_READ_ONLY_SIZE
> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
> 73 #define MAX_SHARED_MISC_DATA_SIZE
> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
> 74 #define MAX_SHARED_MISC_CODE_SIZE
> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE)-SHARED_PAGE)

I have to think about this for a bit, but I think that we can do this using constraints, but then we will have to 
disable these flags in Dmitry's testing framework, because it will be possible to create an arrangement where the range 
(with MAX needing to be set to 0x7FFFFFFF) will pass, but not the constraint. Such arrangement will make VM exit with 
code 2 (ie. not crash), which would be reported as failure by the testing framework.


>
> You probably have already done it, it would be good to verify the changes pass all the test in
> hotspot/test/runtime/SharedArchiveFile on all platforms.

Oh yes, I did verify with all hotspot tests run on all platforms.


cheers

>
> Thanks,
>
> Jiangli
>
>> On Nov 10, 2015, at 9:31 AM, gerard ziemski <gerard.ziemski at oracle.com <mailto:gerard.ziemski at oracle.com>> wrote:
>>
>> hi all,
>>
>> I have updated the fix with rev2, incorporating feedback from David:
>>
>> - Move the metaspace constants back into metaspace code
>> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>>
>>
>> cheers
>>
>>
>> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>>> hi all,
>>>
>>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>>
>>> - Fix comments and indentation
>>> - Add "-XShare:dump" while testing Shared* flags
>>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>>>
>>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>>
>>>
>>>
>>> cheers
>>>
>>>
>>>
>>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>>
>>>> hi all,
>>>>
>>>> Please review this final fix for JEP-245
>>>>
>>>> We implement the remaining runtime flags in the Shared* family.
>>>>
>>>> Summary of changes:
>>>>
>>>> #1 core fix - we factor out the constants to be used in the ranges
>>>>
>>>> src/share/vm/classfile/compactHashtable.cpp
>>>> src/share/vm/memory/metaspace.cpp
>>>> src/share/vm/memory/metaspaceShared.hpp
>>>> src/share/vm/runtime/globals.hpp
>>>>
>>>>
>>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>>>
>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>>
>>>>
>>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>>>
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>>
>>>>
>>>> #4 we add functionality to OptionsValidation test framework that we later use
>>>>
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>>
>>>>
>>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>>>
>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>>
>>>>
>>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>>> tests
>>>>
>>>> References:
>>>>
>>>>     bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>>  open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>>
>>>>
>>>> hg_stat:
>>>>
>>>>  src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>>>  src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>>>  src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>>>  src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>>>  src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>>>  src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>>  test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>>>  9 files changed, 242 insertions(+), 141 deletions(-)
>>>
>

From christian.thalinger at oracle.com  Wed Nov 11 18:58:30 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 08:58:30 -1000
Subject: jdk 9 performance optimizations
In-Reply-To: <CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
Message-ID: <DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>


> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com> wrote:
> 
> Hi Christian,
> 
> Thanks for the clarification, I over-simplified. Can you please shed some
> light on my questions? How can jigsaw help with AOT, inlining lambda?s?

I think the text you are quoting is more a blanket statement of what could be done.  Some of the listed optimizations might even be done on a class file level.

One area where JDK 9 can help is if all classes (JDK and application) are bundled together AOT compilation can optimize more optimistically.  Of course dynamic class loading can break all assumptions but that?s another story.

> I did my jug talk already yesterday, yet, I am curious.
> Thanks!
> 
> Jeroen
> 
> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
> christian.thalinger at oracle.com>:
> 
>> 
>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers <jborgers at jpinpoint.com>
>> wrote:
>>> 
>>> I posted in jigsaw-dev list before:
>>> 
>>> I found this interesting presentation "Java goes AOT" from JVM Language
>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
>>> 
>>> As presented by Christiaan Thalinger from HS compiler team, AOT is used
>>> with Graal to reduce startup time and quicker peakperformance (tiered).
>>> Currently they don't do any inlining in AOT yet
>> 
>> That?s not accurate; we do inlining but very limited.
>> 
>>> because compilation time
>>> blows up by inlining everything since no profiling information is
>> available
>>> yet. I guess modules and knowing dependencies can help here to reduce
>> this.
>>> Besides test running to generate profiling data.
>>> 
>>> Regards, Jeroen
>>> Bijlagen
>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
>>> JVMLS 2015 - Java Goes AOT
>>> Vitaly Davidovich
>>> 13:09 (10 uur geleden)
>>> aan Jeroen, jigsaw-dev
>>> 
>>> Yes, I had seen Chris' presentation as well.  Certainly modularization
>> will
>>> help AOT in many ways.  But, I'm particularly interested on the JIT side.
>>> What was meant by aggressive lambda inlining, for example? Can anyone
>> point
>>> at some additional info?
>>> 
>>> Thanks
>>> 
>>> sent from my phone
>>> Paul Sandoz <paul.sandoz at oracle.com>
>>> 13:32 (9 uur geleden)
>>> aan jigsaw-dev
>>> Hi Vitaly,
>>> 
>>> Probably worth sending an email to the hotspot-dev at openjdk.java.net
>> <mailto:
>>> hotspot-dev at openjdk.java.net>
>>> 
>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>>> 
>>>> Yes, I had seen Chris' presentation as well.  Certainly modularization
>>> will
>>>> help AOT in many ways.  But, I'm particularly interested on the JIT
>> side.
>>>> What was meant by aggressive lambda inlining, for example? Can anyone
>>> point
>>>> at some additional info?
>>>> 
>>> 
>>> I presume it in part might relate to cracking open the lambda ?box?
>>> implementing the targeted functional interface to obtain the underlying
>>> method containing the lambda body, generated by javac, that the box
>> defers
>>> to, then subsituting the indy call to an invocation of that underlying
>>> method. Cue lots of hand waving?
>>> 
>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at
>>> JVMLS 2014:
>>> 
>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
>>> --------
>>> 
>>> Thanks,
>>> 
>>> Jeroen
>>> 
>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
>>> 
>>>> Hi,
>>>> 
>>>> One of the goals of Jigsaw that intrigue me, I read here:
>> http://openjdk.
>>>> java
>>>> 
>> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>>>> is:
>>>> *Enable ahead-of-time, whole-program optimization techniques*  -
>>>> [..]
>>>> The optimization techniques envisioned here include, but are not limited
>>>> to: Fast lookup of both JDK and application classes; early bytecode
>>>> verification; aggressive inlining of, *e.g.*, lambda expressions, and
>>>> other standard compiler optimizations; construction of JVM-specific
>> memory
>>>> images that can be loaded more efficiently than class files;
>> ahead-of-time
>>>> compilation of method bodies to native code; and the removal of unused
>>>> fields, methods, and classes. These kinds of techniques tend to work
>> best
>>>> when JDK and application code is analyzed together, prior to run time.
>>>> [..]
>>>> 
>>>>  -
>>>> 
>>>>  *Optimize existing code as-is* ? It must be possible to apply the
>>>>  optimizer tool to existing code already packaged in traditional jar
>> files,
>>>>  without changing those files.
>>>>  -
>>>> 
>>>>  *Actual optimizations* ? As a proof of concept, provide at least two
>>>>  optimizations that deliver nontrivial performance benefits.
>>>> 
>>>> I am curious about the following:
>>>> * What is the current state of this? Which techniques/optimizations are
>>>> already implemented and available from the current ea JDK9 or will be?
>>>> * Are there any new insights/developments in this area?
>>>> * I noticed in my JMH microbenchmark with parallel stream and lambda's
>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could this be
>>>> caused by more aggressive inlining of lambda's?
>>>> * It seems to me that some compilation and optimization work is moved
>> from
>>>> runtime to link time /AOT time, yet, we don't have profiling information
>>>> there, so this will be limited, right? Are there obvious cases which
>> work
>>>> well?
>>>> * I don't really see why aggressive inlining and std optimizations can
>> now
>>>> be more effective. Because there will be less de-optimization events
>> needed
>>>> because of better predictability? Can in-lining now take place in two
>> ways,
>>>> between platform modules and application? Through interfaces?
>>>> 
>>>> Thanks!
>>>> Jeroen
>>>> 
>>>> 
>>>> 
>> 
>> 


From christian.thalinger at oracle.com  Wed Nov 11 00:42:22 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 10 Nov 2015 14:42:22 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot IDE
	configuration generation
Message-ID: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>

[This is kind of a long email but contains pictures :-)]

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

In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.

The mx support files will be under a dot-directory: 

$ hg st --all .mx.jvmci/ 
C .mx.jvmci/.project 
C .mx.jvmci/.pydevproject 
C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
C .mx.jvmci/hotspot/templates/eclipse/cproject 
C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
C .mx.jvmci/mx_jvmci.py 
C .mx.jvmci/suite.py 

mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 

https://wiki.openjdk.java.net/display/Graal/Instructions 
https://wiki.openjdk.java.net/display/Graal/Eclipse 

It basically boils down to: 

$ mx ideinit 

and importing the configuration into your favorite IDE. 

This would give every developer the same view of the source code and we can also enforce code-style guidelines. 

Here is how the imported projects look like in Eclipse:



This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.

Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:



This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:



and here is the release one:



mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.

findbugs runs FindBugs (doh!) on all Java projects that mx knows about:

cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
Scanning archives (15 / 30)
2 analysis passes to perform
Pass 1: Analyzing classes (524 / 524) - 100% complete
Pass 2: Analyzing classes (305 / 305) - 100% complete
Done with analysis
Calculating exit code...
Exit code set to: 0

checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:

cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
/Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.

or:

cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
/Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.

That?s all, folks!

From jiangli.zhou at oracle.com  Wed Nov 11 19:30:36 2015
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 11 Nov 2015 11:30:36 -0800
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <56437943.4060103@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com>
	<53494D86-7466-4D88-9C49-22A3D443E672@oracle.com>
	<56437943.4060103@oracle.com>
Message-ID: <7C6B2BF2-B639-422F-A747-6FEA8FA33886@oracle.com>

Hi Gerard,

> On Nov 11, 2015, at 9:22 AM, gerard ziemski <gerard.ziemski at oracle.com> wrote:
> 
> hi Jiangli,
> 
> Thank you very much for the review. Please see my answers in-line:
> 
> On 11/10/2015 07:19 PM, Jiangli Zhou wrote:
>> Hi Gerard,
>> 
>> The changes looks good. Thank you for moving all Shared*** flags' values in one place! I have a few comments below.
>> 
>> For the MIN_SHARED_MISC_DATA_SIZE & MIN_SHARED_MISC_CODE_SIZE, the original check in metaspace.cpp align the computed
>> values to os::vm_allocation_granularity(). Any reason why the alignment requirement is removed for the new values
>> defined in metaspaceShared.hpp?
> 
> The range function compares the min with the value before any alignment takes place, so we're good (we're not mixing comparison of aligned vs unaligned values here), but good question. The values later do get aligned when assigned locally.

Ok. That make sense.

> 
> 
>> 
>> For the following MAX values, it seems they should be calculated using
>> the MIN_SHARED_READ_WRITE_SIZE, MIN_SHARED_READ_ONLY_SIZE, MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE
>> instead of the DEFAULT values since the runtime flags? setting can be smaller than the default values? Does that sound
>> reasonable?
>> 
>> 71 #define MAX_SHARED_READ_WRITE_SIZE
>> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
>> 72 #define MAX_SHARED_READ_ONLY_SIZE
>> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
>> 73 #define MAX_SHARED_MISC_DATA_SIZE
>> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_CODE_SIZE)-SHARED_PAGE)
>> 74 #define MAX_SHARED_MISC_CODE_SIZE
>> (MAX_SHARED_DELTA-(DEFAULT_SHARED_READ_WRITE_SIZE+DEFAULT_SHARED_READ_ONLY_SIZE+DEFAULT_SHARED_MISC_DATA_SIZE)-SHARED_PAGE)
> 
> I have to think about this for a bit, but I think that we can do this using constraints, but then we will have to disable these flags in Dmitry's testing framework, because it will be possible to create an arrangement where the range (with MAX needing to be set to 0x7FFFFFFF) will pass, but not the constraint. Such arrangement will make VM exit with code 2 (ie. not crash), which would be reported as failure by the testing framework.

If we want to make the max range check accurate, I think we need to use the actual value of each flag. However, when it?s checking the SharedReadWriteSize, the other three values are not yet defined. So the check is an estimate. Then maybe it is okay to use the default values in above computation. 

> 
> 
>> 
>> You probably have already done it, it would be good to verify the changes pass all the test in
>> hotspot/test/runtime/SharedArchiveFile on all platforms.
> 
> Oh yes, I did verify with all hotspot tests run on all platforms.


Great.

Thanks,
Jiangli

> 
> 
> cheers
> 
>> 
>> Thanks,
>> 
>> Jiangli
>> 
>>> On Nov 10, 2015, at 9:31 AM, gerard ziemski <gerard.ziemski at oracle.com <mailto:gerard.ziemski at oracle.com> <mailto:gerard.ziemski at oracle.com <mailto:gerard.ziemski at oracle.com>>> wrote:
>>> 
>>> hi all,
>>> 
>>> I have updated the fix with rev2, incorporating feedback from David:
>>> 
>>> - Move the metaspace constants back into metaspace code
>>> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
>>> 
>>> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>>> 
>>> 
>>> cheers
>>> 
>>> 
>>> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>>>> hi all,
>>>> 
>>>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>>> 
>>>> - Fix comments and indentation
>>>> - Add "-XShare:dump" while testing Shared* flags
>>>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>>>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>>>> 
>>>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>>> 
>>>> 
>>>> 
>>>> cheers
>>>> 
>>>> 
>>>> 
>>>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>>> 
>>>>> hi all,
>>>>> 
>>>>> Please review this final fix for JEP-245
>>>>> 
>>>>> We implement the remaining runtime flags in the Shared* family.
>>>>> 
>>>>> Summary of changes:
>>>>> 
>>>>> #1 core fix - we factor out the constants to be used in the ranges
>>>>> 
>>>>> src/share/vm/classfile/compactHashtable.cpp
>>>>> src/share/vm/memory/metaspace.cpp
>>>>> src/share/vm/memory/metaspaceShared.hpp
>>>>> src/share/vm/runtime/globals.hpp
>>>>> 
>>>>> 
>>>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>>>> 
>>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>>> 
>>>>> 
>>>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>>>> 
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>>> 
>>>>> 
>>>>> #4 we add functionality to OptionsValidation test framework that we later use
>>>>> 
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>>> 
>>>>> 
>>>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>>>> 
>>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>>> 
>>>>> 
>>>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>>>> tests
>>>>> 
>>>>> References:
>>>>> 
>>>>>    bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>>> open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>>> 
>>>>> 
>>>>> hg_stat:
>>>>> 
>>>>> src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>>>> src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>>>> src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>>>> src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>>>> 9 files changed, 242 insertions(+), 141 deletions(-)


From christian.thalinger at oracle.com  Wed Nov 11 19:54:10 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 09:54:10 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
Message-ID: <D7053681-2AAF-491D-B783-65D37D3955FF@oracle.com>


> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> [This is kind of a long email but contains pictures :-)]

?not!  Somehow all my attachments were stripped.  Let me see what I can do about this...

> 
> https://bugs.openjdk.java.net/browse/JDK-8139921
> http://cr.openjdk.java.net/~twisti/8139921/webrev/
> 
> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
> 
> The mx support files will be under a dot-directory: 
> 
> $ hg st --all .mx.jvmci/ 
> C .mx.jvmci/.project 
> C .mx.jvmci/.pydevproject 
> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/cproject 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
> C .mx.jvmci/mx_jvmci.py 
> C .mx.jvmci/suite.py 
> 
> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
> 
> https://wiki.openjdk.java.net/display/Graal/Instructions 
> https://wiki.openjdk.java.net/display/Graal/Eclipse 
> 
> It basically boils down to: 
> 
> $ mx ideinit 
> 
> and importing the configuration into your favorite IDE. 
> 
> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
> 
> Here is how the imported projects look like in Eclipse:
> 
> 
> 
> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
> 
> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
> 
> 
> 
> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
> 
> 
> 
> and here is the release one:
> 
> 
> 
> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
> 
> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
> Scanning archives (15 / 30)
> 2 analysis passes to perform
> Pass 1: Analyzing classes (524 / 524) - 100% complete
> Pass 2: Analyzing classes (305 / 305) - 100% complete
> Done with analysis
> Calculating exit code...
> Exit code set to: 0
> 
> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
> 
> or:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
> 
> That?s all, folks!


From coleen.phillimore at oracle.com  Wed Nov 11 20:20:34 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 11 Nov 2015 15:20:34 -0500
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod
	is not MT safe
In-Reply-To: <5643621E.9060206@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
	<5643621E.9060206@oracle.com>
Message-ID: <5643A312.5030707@oracle.com>


I still like the refactoring.  I  don't have further comments but I 
didn't study what the DependencyContext does, so hopefully your other 
reviewers looked at that.

Coleen

On 11/11/15 10:43 AM, Vladimir Ivanov wrote:
> Coleen, John, thanks for the feedback!
>
> Updated version:
>   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.03/
>
> * Added InstanceKlass::dependencies()
>
> * Removed the fields from vmStructs since they aren't used in SA 
> (tmtools tests passed).
>
> * Added missing includes in dependencyContext.hpp. Previous version 
> built fine (even w/o precompiled headers), but I think it worked due 
> to header inclusion order.
>
> * Added verification of CallSite oop validity across DependencyContext 
> lifetime.
>
> Though previous comments were focused on dependency management code 
> refactoring, I'd like to hear opinions about the fix itself - 
> dependency management changes for j.l.i.CallSites to avoid 
> modifications during concurrent traversals by GC threads.
>
> Quote from the original request:
>  "The fix I propose is to avoid purging of CallSiteContext contexts at 
> all during GC, but remove stale entries during dependency list updates 
> which happen under CodeCache lock (see safe_to_purge() check in 
> methodHandles.cpp). It happens outside of safepoints and it guarantees 
> exclusive access to the list. It is performed during 
> j.l.i.CallSite.target updates, CallSite.target inlining, j.l.Class 
> unloading, etc. Such approach allows to avoid unbounded memory 
> consumption growth, only some delay (till next dependency list update) 
> in memory deallocation."
>
> Best regards,
> Vladimir Ivanov
>
> On 11/10/15 5:37 AM, John Rose wrote:
>> I think this expression occurs too many times:
>>    DependencyContext dep_context(&_dep_context);
>>
>> It would look better if factored into an access method:
>>    inline DependencyContext InstanceKlass::dependencies() {
>>      DependencyContext dep_context(&_dep_context);
>>      return dep_context;
>>    }
>>
>> That way the raw machine word InstanceKlass::_dep_context can be 
>> isolated.
>> CallSiteContext::vmdependencies already does the corresponding move 
>> for CallSite.
>> (I understand that you don't want to make ik.hpp depend on dc.hpp.
>> Just put forward declarations of Deps and IK::deps in ik.hpp.)
>>
>> Mild suggestion:  Add a constructor parameter to capture the base oop 
>> (of the callsite, or null for the IK).
>> Use it only in debug mode to check for GC changes.  Or sample a 
>> global GC or safepoint count.
>> The point is that the lifetime of the Deps object should not extend 
>> beyond the next safepoint.
>>
>> I agree with Coleen:  This is a good refactor.
>>
>> Reviewed.
>>
>> ? John
>>
>> On Nov 6, 2015, at 5:03 AM, Vladimir Ivanov 
>> <vladimir.x.ivanov at oracle.com> wrote:
>>>
>>> Thanks, Coleen!
>>>
>>> Updated version:
>>>   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.02/
>>>
>>>> I think DependencyContext is big enough to be a new file, and not be
>>>> added to instanceKlass.hpp.  There are too many unrelated things in
>>>> instanceKlass.
>>> Agree. Moved it to src/share/vm/code/dependencyContext.[ch]pp
>>>
>>>> The hidden bit stuff is ok in InstanceKlass.  Does
>>>> has_unloaded_dependent accessed concurrently like
>>>> _is_marked_dependent?
>>> Good point. DependencyContext::remove_dependent_nmethod should set 
>>> has_stale_entries in a thread safe manner (added Atomic::xchg_ptr 
>>> call).
>>> It is not needed when the flag is cleared.
>>>
>>>> It would be nice to move _is_marked_dependent
>>>> field also to encapsulate it but that would ruin your bit packing.
>>> There's a spare bit to use, but I think _is_marked_dependent is 
>>> specific to InstanceKlass and should remain there. It doesn't have 
>>> any meaning for CallSite dependencies.
>>>
>>>> Also, since you have changes to vmStructs, do you have duplicate 
>>>> changes
>>>> to make to the serviceability agent code?  Are there duplicate changes
>>>> for the jvmci code?
>>> I haven't found any mentions of _has_unloaded_dependent or 
>>> _dependencies fields in SA or JVMCI code. Do you think it is an 
>>> overlook on SA side and I should add it?
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 11/5/15 1:54 PM, Vladimir Ivanov wrote:
>>>>> Updated version:
>>>>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.01/
>>>>>
>>>>> In addition to name polishing and encapsulating purging logic in
>>>>> {add|remove}_dependent_nmethod methods, I got rid of
>>>>> DependencyContext::wipe() method and added "friend class
>>>>> TestDependencyContext" declaration (noticed such practice in other
>>>>> cases when tests need access to tested class internals).
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 11/5/15 7:46 PM, Aleksey Shipilev wrote:
>>>>>> On 11/05/2015 04:54 PM, Vladimir Ivanov wrote:
>>>>>>> Regarding internal purging, add_dependent_methods doesn't 
>>>>>>> iterate over
>>>>>>> the whole list, but looks for the relevant entry. It means that 
>>>>>>> "purge"
>>>>>>> flag should force full iteration. I think that keeping them 
>>>>>>> separately
>>>>>>> (add_dependent_methods() vs purge()) looks cleaner.
>>>>>>
>>>>>> I think it is better to encapsulate the "piggybacking" behavior 
>>>>>> within
>>>>>> the DependencyContext itself, because that seems to be a
>>>>>> general/expected feature of DependencyContext class. It is weird 
>>>>>> to ask
>>>>>> class users to spell it out specifically.
>>>>>>
>>>>>>
>>>>>>> I could add "purge" flag and move the following code into
>>>>>>> add_dependent_methods:
>>>>>>> void DependencyContext::add_dependent_nmethod(nmethod* nm, bool
>>>>>>> do_purge
>>>>>>> = false) {
>>>>>>>     ...
>>>>>>>     if (has_unloaded_dependent() && do_purge) {
>>>>>>>       purge();
>>>>>>>     }
>>>>>>> }
>>>>>>>
>>>>>>> Is it what you are suggesting?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>
>>>>>>>>    * DependencyContext now has three methods: purge(), clear(),
>>>>>>>> wipe(). I
>>>>>>>> have trouble understanding which method does what!
>>>>>>
>>>>>>> There are basically 2 operations needed:
>>>>>>>    * purge(): only remove stale entries; no additional work is
>>>>>>> performed;
>>>>>>
>>>>>> Oh. Should probably mention "stale" in the name. See e.g. Java-ish:
>>>>>>   WeakHashMap.expungeStaleEntries()
>>>>>>   ThreadLocal.expungeStaleEntries()
>>>>>>   WeakCache.expungeStaleEntries()
>>>>>>
>>>>>>
>>>>>>> wipe() is only for unit-testing purposes (see 
>>>>>>> TestNmethodBucket): it
>>>>>>> just deallocates all nmethodBucket entries without touching
>>>>>>> nmethods. It
>>>>>>> is necessary since nmethod pointers are faked by the test.
>>>>>>
>>>>>> Okay. Is there a convention how you should name the test-related 
>>>>>> methods
>>>>>> like these? I would expect something like 
>>>>>> debug_deallocate_buckets().
>>>>>>
>>>>>> Thanks,
>>>>>> -Aleksey
>>>>>>
>>>>>>
>>>>
>>


From david.holmes at oracle.com  Wed Nov 11 20:23:32 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Nov 2015 06:23:32 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUxORNG_FLjP_bF7E5m9v=mSnMEOajo6e-XUeea5JgE0cQ@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
	<5641D452.6040503@oracle.com> <5642FA07.8050309@oracle.com>
	<CAA-vtUzHSqTN-SW_Ew98pWJH3uqpty=RzUC+0ws2Y87ePxP3Fw@mail.gmail.com>
	<CAA-vtUxORNG_FLjP_bF7E5m9v=mSnMEOajo6e-XUeea5JgE0cQ@mail.gmail.com>
Message-ID: <5643A3C4.3050803@oracle.com>

Sorry Thomas the all important:

src/os/posix/vm/threadLocalStorage_posix.cpp

was missing from the webrev. Now adding.

David
-----

On 12/11/2015 2:47 AM, Thomas St?fe wrote:
>
> On Wed, Nov 11, 2015 at 5:36 PM, Thomas St?fe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David,
>
>     I get build errors on all my platforms.
>
>     I think the change misses #include "runtime/threadLocalStorage.hpp"
>     in a couple of places, at least thread.cpp and possible also the
>     os_xx_yy.cpp files.
>
>
> Sorry, I have to correct myself. It is a linker error, I do not find the
> implementations for the ThreadLocalStorage class methods anywhere. I
> applied your patch atop a freshly synced hs-rt repo:
>
> - .../hotspot $ hg log -l 3
> changeset:   9317:3b23f69bc887 8132510__thread_davids_change qbase qtip tip
> user:        stuefe
> date:        Wed Nov 11 16:12:14 2015 +0100
> summary:     imported patch 8132510__thread_davids_change
>
> changeset:   9316:f17e5edbe761 qparent
> user:        tschatzl
> date:        Tue Nov 10 11:07:15 2015 +0100
> summary:     8140689: Skip last young-only gc if nothing to do in the
> mixed gc phase
> Reviewed-by: mgerdin, drwhite
>
> on AIX I get:
>
> ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::thread()
> ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::is_initialized()
> ld: 0711-317 ERROR: Undefined symbol:
> .ThreadLocalStorage::set_thread(Thread*)
> ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::init()
>
> Am I building wrong?
>
> Regards, Thomas
>
>
>     Will take another look tomorrow.
>
>     Thanks, Thomas
>
>     On Wed, Nov 11, 2015 at 9:19 AM, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         Hi Thomas,
>
>         Okay here's the next revision:
>
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v5/
>
>         I've reinstated a basic ThreadLocalStorage class which will only
>         need two implementations: a POSIX one, and a Windows one (still
>         TBD). This class is always initialized and
>         ThreadLocalStorage::thread() is used from the signal handlers
>         (as today).
>
>         For platforms that don't have __thread support they can define
>         USE_LIBRARY_BASED_TLS_ONLY at build time to only use the
>         ThreadLocalStorage implementation.
>
>         Obviously still need to get some performance numbers.
>
>         I'd appreciate it if you could retest AIX, though as all
>         platforms currently use pthread_get/setspecific I'm confident
>         there will be no platform issues.
>
>         Thanks,
>         David
>
>
>

From christian.thalinger at oracle.com  Wed Nov 11 20:51:33 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 10:51:33 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <D7053681-2AAF-491D-B783-65D37D3955FF@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
	<D7053681-2AAF-491D-B783-65D37D3955FF@oracle.com>
Message-ID: <791BB631-CE44-4CD0-8835-643F79D962AF@oracle.com>


> On Nov 11, 2015, at 9:54 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> [This is kind of a long email but contains pictures :-)]
> 
> ?not!  Somehow all my attachments were stripped.  Let me see what I can do about this?

I guess I have to send them one by one.

> 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8139921
>> http://cr.openjdk.java.net/~twisti/8139921/webrev/
>> 
>> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
>> 
>> The mx support files will be under a dot-directory: 
>> 
>> $ hg st --all .mx.jvmci/ 
>> C .mx.jvmci/.project 
>> C .mx.jvmci/.pydevproject 
>> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
>> C .mx.jvmci/hotspot/templates/eclipse/cproject 
>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
>> C .mx.jvmci/mx_jvmci.py 
>> C .mx.jvmci/suite.py 
>> 
>> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
>> 
>> https://wiki.openjdk.java.net/display/Graal/Instructions 
>> https://wiki.openjdk.java.net/display/Graal/Eclipse 
>> 
>> It basically boils down to: 
>> 
>> $ mx ideinit 
>> 
>> and importing the configuration into your favorite IDE. 
>> 
>> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
>> 
>> Here is how the imported projects look like in Eclipse:
>> 
>> 
>> 
>> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
>> 
>> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
>> 
>> 
>> 
>> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
>> 
>> 
>> 
>> and here is the release one:
>> 
>> 
>> 
>> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
>> 
>> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
>> 
>> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
>> Scanning archives (15 / 30)
>> 2 analysis passes to perform
>> Pass 1: Analyzing classes (524 / 524) - 100% complete
>> Pass 2: Analyzing classes (305 / 305) - 100% complete
>> Done with analysis
>> Calculating exit code...
>> Exit code set to: 0
>> 
>> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
>> 
>> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
>> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
>> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
>> 
>> or:
>> 
>> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
>> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
>> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
>> 
>> That?s all, folks!
> 


From christian.thalinger at oracle.com  Wed Nov 11 20:52:29 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 10:52:29 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
Message-ID: <A7FD4DBC-26CC-41A5-8C8E-9B58905DEEC1@oracle.com>


> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> [This is kind of a long email but contains pictures :-)]
> 
> https://bugs.openjdk.java.net/browse/JDK-8139921
> http://cr.openjdk.java.net/~twisti/8139921/webrev/
> 
> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
> 
> The mx support files will be under a dot-directory: 
> 
> $ hg st --all .mx.jvmci/ 
> C .mx.jvmci/.project 
> C .mx.jvmci/.pydevproject 
> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/cproject 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
> C .mx.jvmci/mx_jvmci.py 
> C .mx.jvmci/suite.py 
> 
> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
> 
> https://wiki.openjdk.java.net/display/Graal/Instructions 
> https://wiki.openjdk.java.net/display/Graal/Eclipse 
> 
> It basically boils down to: 
> 
> $ mx ideinit 
> 
> and importing the configuration into your favorite IDE. 
> 
> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
> 
> Here is how the imported projects look like in Eclipse:
> 

> 
> 
> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
> 
> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
> 
> 
> 
> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
> 
> 
> 
> and here is the release one:
> 
> 
> 
> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
> 
> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
> Scanning archives (15 / 30)
> 2 analysis passes to perform
> Pass 1: Analyzing classes (524 / 524) - 100% complete
> Pass 2: Analyzing classes (305 / 305) - 100% complete
> Done with analysis
> Calculating exit code...
> Exit code set to: 0
> 
> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
> 
> or:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
> 
> That?s all, folks!


From christian.thalinger at oracle.com  Wed Nov 11 21:46:27 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 11:46:27 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
Message-ID: <32DA8A41-0280-4B38-ACC6-4EF4BE3B3B17@oracle.com>


> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> [This is kind of a long email but contains pictures :-)]
> 
> https://bugs.openjdk.java.net/browse/JDK-8139921
> http://cr.openjdk.java.net/~twisti/8139921/webrev/
> 
> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
> 
> The mx support files will be under a dot-directory: 
> 
> $ hg st --all .mx.jvmci/ 
> C .mx.jvmci/.project 
> C .mx.jvmci/.pydevproject 
> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/cproject 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
> C .mx.jvmci/mx_jvmci.py 
> C .mx.jvmci/suite.py 
> 
> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
> 
> https://wiki.openjdk.java.net/display/Graal/Instructions 
> https://wiki.openjdk.java.net/display/Graal/Eclipse 
> 
> It basically boils down to: 
> 
> $ mx ideinit 
> 
> and importing the configuration into your favorite IDE. 
> 
> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
> 
> Here is how the imported projects look like in Eclipse:
> 
> 
> 
> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
> 
> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
> 

> 
> 
> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
> 
> 
> 
> and here is the release one:
> 
> 
> 
> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
> 
> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
> Scanning archives (15 / 30)
> 2 analysis passes to perform
> Pass 1: Analyzing classes (524 / 524) - 100% complete
> Pass 2: Analyzing classes (305 / 305) - 100% complete
> Done with analysis
> Calculating exit code...
> Exit code set to: 0
> 
> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
> 
> or:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
> 
> That?s all, folks!


From christian.thalinger at oracle.com  Wed Nov 11 22:08:12 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 12:08:12 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
Message-ID: <E8E7035D-A0AF-4201-B222-1A02A0B564D6@oracle.com>


> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> [This is kind of a long email but contains pictures :-)]
> 
> https://bugs.openjdk.java.net/browse/JDK-8139921
> http://cr.openjdk.java.net/~twisti/8139921/webrev/
> 
> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
> 
> The mx support files will be under a dot-directory: 
> 
> $ hg st --all .mx.jvmci/ 
> C .mx.jvmci/.project 
> C .mx.jvmci/.pydevproject 
> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/cproject 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
> C .mx.jvmci/mx_jvmci.py 
> C .mx.jvmci/suite.py 
> 
> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
> 
> https://wiki.openjdk.java.net/display/Graal/Instructions 
> https://wiki.openjdk.java.net/display/Graal/Eclipse 
> 
> It basically boils down to: 
> 
> $ mx ideinit 
> 
> and importing the configuration into your favorite IDE. 
> 
> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
> 
> Here is how the imported projects look like in Eclipse:

> 
> 
> 
> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
> 
> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
> 
> 
> 
> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
> 
> 
> 
> and here is the release one:
> 
> 
> 
> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
> 
> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
> Scanning archives (15 / 30)
> 2 analysis passes to perform
> Pass 1: Analyzing classes (524 / 524) - 100% complete
> Pass 2: Analyzing classes (305 / 305) - 100% complete
> Done with analysis
> Calculating exit code...
> Exit code set to: 0
> 
> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
> 
> or:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
> 
> That?s all, folks!


From christian.thalinger at oracle.com  Wed Nov 11 23:45:15 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 13:45:15 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
Message-ID: <3AC97B82-2C99-4CD9-AC32-E83167827972@oracle.com>


> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> [This is kind of a long email but contains pictures :-)]
> 
> https://bugs.openjdk.java.net/browse/JDK-8139921
> http://cr.openjdk.java.net/~twisti/8139921/webrev/
> 
> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
> 
> The mx support files will be under a dot-directory: 
> 
> $ hg st --all .mx.jvmci/ 
> C .mx.jvmci/.project 
> C .mx.jvmci/.pydevproject 
> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/cproject 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
> C .mx.jvmci/mx_jvmci.py 
> C .mx.jvmci/suite.py 
> 
> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
> 
> https://wiki.openjdk.java.net/display/Graal/Instructions 
> https://wiki.openjdk.java.net/display/Graal/Eclipse 
> 
> It basically boils down to: 
> 
> $ mx ideinit 
> 
> and importing the configuration into your favorite IDE. 
> 
> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
> 
> Here is how the imported projects look like in Eclipse:
> 

http://cr.openjdk.java.net/~twisti/8139921/Screen%20Shot%202015-11-10%20at%202.13.28%20PM.png

> 
> 
> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
> 
> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:

http://cr.openjdk.java.net/~twisti/8139921/Screen%20Shot%202015-11-10%20at%202.18.20%20PM.png

> 
> 
> 
> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:

http://cr.openjdk.java.net/~twisti/8139921/Screen%20Shot%202015-11-10%20at%202.23.23%20PM.png

> 
> 
> 
> and here is the release one:

http://cr.openjdk.java.net/~twisti/8139921/Screen%20Shot%202015-11-10%20at%202.23.04%20PM.png

> 
> 
> 
> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
> 
> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
> Scanning archives (15 / 30)
> 2 analysis passes to perform
> Pass 1: Analyzing classes (524 / 524) - 100% complete
> Pass 2: Analyzing classes (305 / 305) - 100% complete
> Done with analysis
> Calculating exit code...
> Exit code set to: 0
> 
> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
> 
> or:
> 
> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
> 
> That?s all, folks!


From christian.thalinger at oracle.com  Wed Nov 11 23:46:19 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Nov 2015 13:46:19 -1000
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <791BB631-CE44-4CD0-8835-643F79D962AF@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
	<D7053681-2AAF-491D-B783-65D37D3955FF@oracle.com>
	<791BB631-CE44-4CD0-8835-643F79D962AF@oracle.com>
Message-ID: <6F98B3EC-6C74-4145-8F44-A317035BDD95@oracle.com>


> On Nov 11, 2015, at 10:51 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Nov 11, 2015, at 9:54 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> 
>>> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>> [This is kind of a long email but contains pictures :-)]
>> 
>> ?not!  Somehow all my attachments were stripped.  Let me see what I can do about this?
> 
> I guess I have to send them one by one.

Image attachments are stripped.  Although I thought I?ve seen emails with images on other lists.  Anyway, I sent a reply with links.  Sorry.

> 
>> 
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8139921
>>> http://cr.openjdk.java.net/~twisti/8139921/webrev/
>>> 
>>> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
>>> 
>>> The mx support files will be under a dot-directory: 
>>> 
>>> $ hg st --all .mx.jvmci/ 
>>> C .mx.jvmci/.project 
>>> C .mx.jvmci/.pydevproject 
>>> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
>>> C .mx.jvmci/hotspot/templates/eclipse/cproject 
>>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
>>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
>>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
>>> C .mx.jvmci/mx_jvmci.py 
>>> C .mx.jvmci/suite.py 
>>> 
>>> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
>>> 
>>> https://wiki.openjdk.java.net/display/Graal/Instructions 
>>> https://wiki.openjdk.java.net/display/Graal/Eclipse 
>>> 
>>> It basically boils down to: 
>>> 
>>> $ mx ideinit 
>>> 
>>> and importing the configuration into your favorite IDE. 
>>> 
>>> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
>>> 
>>> Here is how the imported projects look like in Eclipse:
>>> 
>>> 
>>> 
>>> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
>>> 
>>> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
>>> 
>>> 
>>> 
>>> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
>>> 
>>> 
>>> 
>>> and here is the release one:
>>> 
>>> 
>>> 
>>> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
>>> 
>>> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
>>> 
>>> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
>>> Scanning archives (15 / 30)
>>> 2 analysis passes to perform
>>> Pass 1: Analyzing classes (524 / 524) - 100% complete
>>> Pass 2: Analyzing classes (305 / 305) - 100% complete
>>> Done with analysis
>>> Calculating exit code...
>>> Exit code set to: 0
>>> 
>>> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
>>> 
>>> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
>>> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
>>> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
>>> 
>>> or:
>>> 
>>> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
>>> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
>>> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
>>> 
>>> That?s all, folks!
>> 
> 


From dl at cs.oswego.edu  Thu Nov 12 01:09:00 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 11 Nov 2015 20:09:00 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <56422B85.9080000@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com>
Message-ID: <5643E6AC.2050702@cs.oswego.edu>

On 11/10/2015 12:38 PM, frederic parain wrote:

>> If I put on some extra-strength rose-coloured glasses I think I can
>> almost read that as "something is better than nothing". ;-)

Yeah, that's what I meant :-) It is good to at least have the
@ReservedStackAccess annotation and mechanism in place. Finding
the best way to use it will take more thought and empirical evaluation.

So I suggest that the hotspot support part of the webrev be put into place,
and that we incorporate j.u.c updates using it after further exploration
and evaluation -- we do have a lot of tests using locks etc, so are in
a better position to make better decisions about alternative placement
strategies after trying them.

>> But note that it is not the finally part that need be at issue.

Right. But given the existence of @ReservedStackAccess, we might be
able to rework some code so as to use it more sparingly.

-Doug



From david.holmes at oracle.com  Thu Nov 12 07:01:15 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Nov 2015 17:01:15 +1000
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <564229E1.1070500@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com>
Message-ID: <5644393B.9060000@oracle.com>

Thanks Gerard!

I'm still unsure about the various max values but if Jiangli is okay 
with things so am I.

David

On 11/11/2015 3:31 AM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev2, incorporating feedback from David:
>
> - Move the metaspace constants back into metaspace code
> - Fix test framework that specifies jsa file to be used by the
> "-Xshare:dump" flag tests
>
> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>
>
> cheers
>
>
> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>
>> - Fix comments and indentation
>> - Add "-XShare:dump" while testing Shared* flags
>> - Temporarily disable testing of SharedMiscDataSize as with current
>> min default it exits the VM with code 2 (which is
>> allowed by the JEP, but not the test framework). This issue is tracked
>> by JDK-8141650
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>
>>
>>
>> cheers
>>
>>
>>
>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this final fix for JEP-245
>>>
>>> We implement the remaining runtime flags in the Shared* family.
>>>
>>> Summary of changes:
>>>
>>> #1 core fix - we factor out the constants to be used in the ranges
>>>
>>> src/share/vm/classfile/compactHashtable.cpp
>>> src/share/vm/memory/metaspace.cpp
>>> src/share/vm/memory/metaspaceShared.hpp
>>> src/share/vm/runtime/globals.hpp
>>>
>>>
>>> #2 we increase default sizes of range and constraint tables to
>>> minimize mallocs
>>>
>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>
>>>
>>> #3 we fix a bug that I run into the OptionsValidation test framework
>>> while working
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>
>>>
>>>
>>> #4 we add functionality to OptionsValidation test framework that we
>>> later use
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>
>>>
>>>
>>> #5 we cleanup and extend the existing test to detect a case where we
>>> get out of range value
>>>
>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>
>>>
>>> The fix passes RBT
>>> "hotspot/test/:hotspot_all,testlist,noncolo.testlist
>>> --add-tonga-keyword quick? and JPRT ?hotspot"
>>> tests
>>>
>>> References:
>>>
>>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>
>>>
>>> hg_stat:
>>>
>>>
>>> src/share/vm/classfile/compactHashtable.cpp
>>> |    2 +-
>>>
>>> src/share/vm/memory/metaspace.cpp
>>> |   30 --
>>>
>>> src/share/vm/memory/metaspaceShared.hpp
>>> |   19 +-
>>>
>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>> |    2 +-
>>>
>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>> |    2 +-
>>>
>>> src/share/vm/runtime/globals.hpp
>>> |   63 +++++-
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>> |    4 +-
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>> |   81 +++++++
>>>
>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>> |  180 +++++++++-------
>>>   9 files changed, 242 insertions(+), 141 deletions(-)
>>

From forax at univ-mlv.fr  Thu Nov 12 08:20:23 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 12 Nov 2015 08:20:23 +0000
Subject: jdk 9 performance optimizations
In-Reply-To: <DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
Message-ID: <94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>

Hi Christian, 

Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <christian.thalinger at oracle.com> a ?crit :
>
>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com>
>wrote:
>> 
>> Hi Christian,
>> 
>> Thanks for the clarification, I over-simplified. Can you please shed
>some
>> light on my questions? How can jigsaw help with AOT, inlining
>lambda?s?
>
>I think the text you are quoting is more a blanket statement of what
>could be done.  Some of the listed optimizations might even be done on
>a class file level.
>
>One area where JDK 9 can help is if all classes (JDK and application)
>are bundled together AOT compilation can optimize more optimistically. 
>Of course dynamic class loading can break all assumptions but that?s
>another story.

If your application is a trading application you don't want your application to dynamically load an unknown class.

My opinion is that the AOT should come with a flag les say 'closed world'  that throw an exception if an unknown class force the runtime to go to a deopt.

cheers,
R?mi

>
>> I did my jug talk already yesterday, yet, I am curious.
>> Thanks!
>> 
>> Jeroen
>> 
>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
>> christian.thalinger at oracle.com>:
>> 
>>> 
>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
><jborgers at jpinpoint.com>
>>> wrote:
>>>> 
>>>> I posted in jigsaw-dev list before:
>>>> 
>>>> I found this interesting presentation "Java goes AOT" from JVM
>Language
>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
>>>> 
>>>> As presented by Christiaan Thalinger from HS compiler team, AOT is
>used
>>>> with Graal to reduce startup time and quicker peakperformance
>(tiered).
>>>> Currently they don't do any inlining in AOT yet
>>> 
>>> That?s not accurate; we do inlining but very limited.
>>> 
>>>> because compilation time
>>>> blows up by inlining everything since no profiling information is
>>> available
>>>> yet. I guess modules and knowing dependencies can help here to
>reduce
>>> this.
>>>> Besides test running to generate profiling data.
>>>> 
>>>> Regards, Jeroen
>>>> Bijlagen
>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
>>>> JVMLS 2015 - Java Goes AOT
>>>> Vitaly Davidovich
>>>> 13:09 (10 uur geleden)
>>>> aan Jeroen, jigsaw-dev
>>>> 
>>>> Yes, I had seen Chris' presentation as well.  Certainly
>modularization
>>> will
>>>> help AOT in many ways.  But, I'm particularly interested on the JIT
>side.
>>>> What was meant by aggressive lambda inlining, for example? Can
>anyone
>>> point
>>>> at some additional info?
>>>> 
>>>> Thanks
>>>> 
>>>> sent from my phone
>>>> Paul Sandoz <paul.sandoz at oracle.com>
>>>> 13:32 (9 uur geleden)
>>>> aan jigsaw-dev
>>>> Hi Vitaly,
>>>> 
>>>> Probably worth sending an email to the hotspot-dev at openjdk.java.net
>>> <mailto:
>>>> hotspot-dev at openjdk.java.net>
>>>> 
>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com>
>wrote:
>>>>> 
>>>>> Yes, I had seen Chris' presentation as well.  Certainly
>modularization
>>>> will
>>>>> help AOT in many ways.  But, I'm particularly interested on the
>JIT
>>> side.
>>>>> What was meant by aggressive lambda inlining, for example? Can
>anyone
>>>> point
>>>>> at some additional info?
>>>>> 
>>>> 
>>>> I presume it in part might relate to cracking open the lambda ?box?
>>>> implementing the targeted functional interface to obtain the
>underlying
>>>> method containing the lambda body, generated by javac, that the box
>>> defers
>>>> to, then subsituting the indy call to an invocation of that
>underlying
>>>> method. Cue lots of hand waving?
>>>> 
>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
>presentation at
>>>> JVMLS 2014:
>>>> 
>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
>>>> --------
>>>> 
>>>> Thanks,
>>>> 
>>>> Jeroen
>>>> 
>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> One of the goals of Jigsaw that intrigue me, I read here:
>>> http://openjdk.
>>>>> java
>>>>> 
>>>
>.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>>>>> is:
>>>>> *Enable ahead-of-time, whole-program optimization techniques*  -
>>>>> [..]
>>>>> The optimization techniques envisioned here include, but are not
>limited
>>>>> to: Fast lookup of both JDK and application classes; early
>bytecode
>>>>> verification; aggressive inlining of, *e.g.*, lambda expressions,
>and
>>>>> other standard compiler optimizations; construction of
>JVM-specific
>>> memory
>>>>> images that can be loaded more efficiently than class files;
>>> ahead-of-time
>>>>> compilation of method bodies to native code; and the removal of
>unused
>>>>> fields, methods, and classes. These kinds of techniques tend to
>work
>>> best
>>>>> when JDK and application code is analyzed together, prior to run
>time.
>>>>> [..]
>>>>> 
>>>>>  -
>>>>> 
>>>>>  *Optimize existing code as-is* ? It must be possible to apply the
>>>>>  optimizer tool to existing code already packaged in traditional
>jar
>>> files,
>>>>>  without changing those files.
>>>>>  -
>>>>> 
>>>>>  *Actual optimizations* ? As a proof of concept, provide at least
>two
>>>>>  optimizations that deliver nontrivial performance benefits.
>>>>> 
>>>>> I am curious about the following:
>>>>> * What is the current state of this? Which
>techniques/optimizations are
>>>>> already implemented and available from the current ea JDK9 or will
>be?
>>>>> * Are there any new insights/developments in this area?
>>>>> * I noticed in my JMH microbenchmark with parallel stream and
>lambda's
>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
>this be
>>>>> caused by more aggressive inlining of lambda's?
>>>>> * It seems to me that some compilation and optimization work is
>moved
>>> from
>>>>> runtime to link time /AOT time, yet, we don't have profiling
>information
>>>>> there, so this will be limited, right? Are there obvious cases
>which
>>> work
>>>>> well?
>>>>> * I don't really see why aggressive inlining and std optimizations
>can
>>> now
>>>>> be more effective. Because there will be less de-optimization
>events
>>> needed
>>>>> because of better predictability? Can in-lining now take place in
>two
>>> ways,
>>>>> between platform modules and application? Through interfaces?
>>>>> 
>>>>> Thanks!
>>>>> Jeroen
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 


From stefan.karlsson at oracle.com  Thu Nov 12 09:46:05 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 12 Nov 2015 10:46:05 +0100
Subject: [8u] RFR: 8058563: InstanceKlass::_dependencies list isn't cleared
	from empty nmethodBucket entries
Message-ID: <56445FDD.3040401@oracle.com>

Hi all,

Please review this backport of 8058563 from JDK 9 to JDK 8u.

JBS:
  https://bugs.openjdk.java.net/browse/JDK-8058563

JDK 8u patch:
  http://cr.openjdk.java.net/~stefank/backports/8u/8058563/webrev.01/

JDK 9 patch:
  http://cr.openjdk.java.net/~stefank/8058563/webrev.01/

The description of the fix can be found at:
  http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-October/020253.html

The nmethod code was refactored in JDK 9, which made it possible to 
easily write unit tests for theses changes. Since I don't want to do 
this refactoring for JDK 8u, the patch is slightly different and the 
unit tests are not included.

Thanks,
StefanK

From thomas.stuefe at gmail.com  Thu Nov 12 13:51:12 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Nov 2015 14:51:12 +0100
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5643A3C4.3050803@oracle.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
	<5641D452.6040503@oracle.com> <5642FA07.8050309@oracle.com>
	<CAA-vtUzHSqTN-SW_Ew98pWJH3uqpty=RzUC+0ws2Y87ePxP3Fw@mail.gmail.com>
	<CAA-vtUxORNG_FLjP_bF7E5m9v=mSnMEOajo6e-XUeea5JgE0cQ@mail.gmail.com>
	<5643A3C4.3050803@oracle.com>
Message-ID: <CAA-vtUyxEBHiSHvxGSj9_bxrF4ibp9zkp_k4V3fLAB1q04ni+A@mail.gmail.com>

Hi David,

builds and works on both variants (with and without USE_LIBRARY_BASED_TLS_ONLY)
on AIX and Linux ppc.

Small nitpicks:

- I probably would have implemented Thread::current() using
Thread::current_or_null().
- Also, instead of using the "raw" ThreadLocalStorage::thread(), I would
have liked a Thread::current_safe() or similar.

Kind Regards, Thomas


On Wed, Nov 11, 2015 at 9:23 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Sorry Thomas the all important:
>
> src/os/posix/vm/threadLocalStorage_posix.cpp
>
> was missing from the webrev. Now adding.
>
> David
> -----
>
> On 12/11/2015 2:47 AM, Thomas St?fe wrote:
>
>>
>> On Wed, Nov 11, 2015 at 5:36 PM, Thomas St?fe <thomas.stuefe at gmail.com
>> <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>     Hi David,
>>
>>     I get build errors on all my platforms.
>>
>>     I think the change misses #include "runtime/threadLocalStorage.hpp"
>>     in a couple of places, at least thread.cpp and possible also the
>>     os_xx_yy.cpp files.
>>
>>
>> Sorry, I have to correct myself. It is a linker error, I do not find the
>> implementations for the ThreadLocalStorage class methods anywhere. I
>> applied your patch atop a freshly synced hs-rt repo:
>>
>> - .../hotspot $ hg log -l 3
>> changeset:   9317:3b23f69bc887 8132510__thread_davids_change qbase qtip
>> tip
>> user:        stuefe
>> date:        Wed Nov 11 16:12:14 2015 +0100
>> summary:     imported patch 8132510__thread_davids_change
>>
>> changeset:   9316:f17e5edbe761 qparent
>> user:        tschatzl
>> date:        Tue Nov 10 11:07:15 2015 +0100
>> summary:     8140689: Skip last young-only gc if nothing to do in the
>> mixed gc phase
>> Reviewed-by: mgerdin, drwhite
>>
>> on AIX I get:
>>
>> ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::thread()
>> ld: 0711-317 ERROR: Undefined symbol:
>> .ThreadLocalStorage::is_initialized()
>> ld: 0711-317 ERROR: Undefined symbol:
>> .ThreadLocalStorage::set_thread(Thread*)
>> ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::init()
>>
>> Am I building wrong?
>>
>> Regards, Thomas
>>
>>
>>     Will take another look tomorrow.
>>
>>     Thanks, Thomas
>>
>>     On Wed, Nov 11, 2015 at 9:19 AM, David Holmes
>>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>>         Hi Thomas,
>>
>>         Okay here's the next revision:
>>
>>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v5/
>>
>>         I've reinstated a basic ThreadLocalStorage class which will only
>>         need two implementations: a POSIX one, and a Windows one (still
>>         TBD). This class is always initialized and
>>         ThreadLocalStorage::thread() is used from the signal handlers
>>         (as today).
>>
>>         For platforms that don't have __thread support they can define
>>         USE_LIBRARY_BASED_TLS_ONLY at build time to only use the
>>         ThreadLocalStorage implementation.
>>
>>         Obviously still need to get some performance numbers.
>>
>>         I'd appreciate it if you could retest AIX, though as all
>>         platforms currently use pthread_get/setspecific I'm confident
>>         there will be no platform issues.
>>
>>         Thanks,
>>         David
>>
>>
>>
>>

From gerard.ziemski at oracle.com  Thu Nov 12 18:21:13 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 12 Nov 2015 12:21:13 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <564229E1.1070500@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com>
Message-ID: <5644D899.7040300@oracle.com>

hi all,

I have updated the fix with rev3, incorporating the feedback from Jiangli:

- After considering the choices I decided to use MIN when calculating the range's MAX values. This seems to be the most 
correct, however, the SQE testing framework will need to have those flags disabled for now. I filed issue JDK-8142874 to 
track an enhancement that would allow Shared* (and all other flags that cause the VM to exit with code other than 0) 
flags to be tested.

http://cr.openjdk.java.net/~gziemski/8138983_rev3


cheers

On 11/10/2015 11:31 AM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev2, incorporating feedback from David:
>
> - Move the metaspace constants back into metaspace code
> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
>
> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>
>
> cheers
>
>
> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>
>> - Fix comments and indentation
>> - Add "-XShare:dump" while testing Shared* flags
>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>
>>
>>
>> cheers
>>
>>
>>
>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this final fix for JEP-245
>>>
>>> We implement the remaining runtime flags in the Shared* family.
>>>
>>> Summary of changes:
>>>
>>> #1 core fix - we factor out the constants to be used in the ranges
>>>
>>> src/share/vm/classfile/compactHashtable.cpp
>>> src/share/vm/memory/metaspace.cpp
>>> src/share/vm/memory/metaspaceShared.hpp
>>> src/share/vm/runtime/globals.hpp
>>>
>>>
>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>>
>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>
>>>
>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>
>>>
>>> #4 we add functionality to OptionsValidation test framework that we later use
>>>
>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>
>>>
>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>>
>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>
>>>
>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>> tests
>>>
>>> References:
>>>
>>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>
>>>
>>> hg_stat:
>>>
>>>   src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>>   src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>>   src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>>   src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>>   src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>>   src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>   test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>>   9 files changed, 242 insertions(+), 141 deletions(-)
>>
>

From gerard.ziemski at oracle.com  Thu Nov 12 18:26:51 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 12 Nov 2015 12:26:51 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564246BD.90203@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com>
Message-ID: <5644D9EB.8070704@oracle.com>

hi all,

I have updated the fix with rev1, incorporating the feedback from David:

- Use trivial range


http://cr.openjdk.java.net/~gziemski/8141641_rev1


cheers

On 11/10/2015 01:34 PM, gerard ziemski wrote:
>
> hi all,
>
> Please review this small fix for JEP-245, which implements range for the last new runtime flag.
>
>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>
>
> Thank you.

From coleen.phillimore at oracle.com  Thu Nov 12 18:30:26 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 12 Nov 2015 13:30:26 -0500
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5644D9EB.8070704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>	<564246BD.90203@oracle.com>
	<5644D9EB.8070704@oracle.com>
Message-ID: <5644DAC2.4060501@oracle.com>


Looks good.

What is

*!  #define INITIAL_RANGES_SIZE_205_*


Do you have to update this whenever you add a range?

Thanks,
Coleen

On 11/12/15 1:26 PM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating the feedback from David:
>
> - Use trivial range
>
>
> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>
>
> cheers
>
> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for 
>> the last new runtime flag.
>>
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>
>>
>> Thank you.


From igor.veresov at oracle.com  Thu Nov 12 18:34:16 2015
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 12 Nov 2015 10:34:16 -0800
Subject: RFR (S): 8139921: add mx configuration files to support HotSpot
	IDE configuration generation
In-Reply-To: <6F98B3EC-6C74-4145-8F44-A317035BDD95@oracle.com>
References: <31F6B9E0-D7C2-4B73-8114-8616F82AE5B5@oracle.com>
	<D7053681-2AAF-491D-B783-65D37D3955FF@oracle.com>
	<791BB631-CE44-4CD0-8835-643F79D962AF@oracle.com>
	<6F98B3EC-6C74-4145-8F44-A317035BDD95@oracle.com>
Message-ID: <62CA847C-1EB6-4ABF-A6AD-B467A26688C1@oracle.com>

Looks good to me.

igor

> On Nov 11, 2015, at 3:46 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Nov 11, 2015, at 10:51 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> 
>>> On Nov 11, 2015, at 9:54 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>> 
>>>> On Nov 10, 2015, at 2:42 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>> [This is kind of a long email but contains pictures :-)]
>>> 
>>> ?not!  Somehow all my attachments were stripped.  Let me see what I can do about this?
>> 
>> I guess I have to send them one by one.
> 
> Image attachments are stripped.  Although I thought I?ve seen emails with images on other lists.  Anyway, I sent a reply with links.  Sorry.
> 
>> 
>>> 
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8139921
>>>> http://cr.openjdk.java.net/~twisti/8139921/webrev/
>>>> 
>>>> In order to make the IDE experience more pleasant now that JEP 243 is integrated we would like to use mx (https://bitbucket.org/allr/mx) for IDE configuration generation.  For this we have to integrate a few mx support files into the hotspot repository.
>>>> 
>>>> The mx support files will be under a dot-directory: 
>>>> 
>>>> $ hg st --all .mx.jvmci/ 
>>>> C .mx.jvmci/.project 
>>>> C .mx.jvmci/.pydevproject 
>>>> C .mx.jvmci/eclipse-settings/org.eclipse.jdt.core.prefs 
>>>> C .mx.jvmci/hotspot/templates/eclipse/cproject 
>>>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.core.prefs 
>>>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.cdt.ui.prefs 
>>>> C .mx.jvmci/hotspot/templates/eclipse/settings/org.eclipse.core.runtime.prefs 
>>>> C .mx.jvmci/mx_jvmci.py 
>>>> C .mx.jvmci/suite.py 
>>>> 
>>>> mx itself is and will stay an external tool.  Some documentation on how to use it can be found here: 
>>>> 
>>>> https://wiki.openjdk.java.net/display/Graal/Instructions 
>>>> https://wiki.openjdk.java.net/display/Graal/Eclipse 
>>>> 
>>>> It basically boils down to: 
>>>> 
>>>> $ mx ideinit 
>>>> 
>>>> and importing the configuration into your favorite IDE. 
>>>> 
>>>> This would give every developer the same view of the source code and we can also enforce code-style guidelines. 
>>>> 
>>>> Here is how the imported projects look like in Eclipse:
>>>> 
>>>> 
>>>> 
>>>> This is most helpful for Compiler engineers who work on the JVMCI but there is value for others too.
>>>> 
>>>> Notice the ?hotspot:*? projects at the top?  These are projects for different HotSpot configurations.  The main advantage here is that these include the generated files directory (if the configuration exists and the files are built).  I only configured and built ?release? so these can been seen, fastdebug is empty:
>>>> 
>>>> 
>>>> 
>>>> This makes it possible for Eclipse to find generated source code.  Very helpful.  For example, JVMTI.  First, jvmtiUtils.hpp from the fastdebug configuration:
>>>> 
>>>> 
>>>> 
>>>> and here is the release one:
>>>> 
>>>> 
>>>> 
>>>> mx has lots of other commands but most of them are not really useful for us.  The only ones worth mentioning besides ideinit are findbugs and checkstyle.
>>>> 
>>>> findbugs runs FindBugs (doh!) on all Java projects that mx knows about:
>>>> 
>>>> cthaling at macbook:~/ws/8139921/hotspot$ mx findbugs
>>>> Scanning archives (15 / 30)
>>>> 2 analysis passes to perform
>>>> Pass 1: Analyzing classes (524 / 524) - 100% complete
>>>> Pass 2: Analyzing classes (305 / 305) - 100% complete
>>>> Done with analysis
>>>> Calculating exit code...
>>>> Exit code set to: 0
>>>> 
>>>> checkstyle checks the Java projects against some predefined style.  This is particularly helpful for people who don?t use an IDE or to make sure everything matches the style after applying an external patch:
>>>> 
>>>> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
>>>> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
>>>> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:33: 'static' modifier out of order with the JLS suggestions.
>>>> 
>>>> or:
>>>> 
>>>> cthaling at macbook:~/ws/8139921/hotspot$ mx checkstyle
>>>> Running Checkstyle on /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src using /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml...
>>>> /Users/cthaling/ws/8139921/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java:43: Name 'FOO' must match pattern '^[a-z][a-zA-Z0-9]*$'.
>>>> 
>>>> That?s all, folks!
>>> 
>> 
> 


From gerard.ziemski at oracle.com  Thu Nov 12 19:10:01 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 12 Nov 2015 13:10:01 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5644DAC2.4060501@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5644DAC2.4060501@oracle.com>
Message-ID: <5644E409.1010008@oracle.com>

Thank you Coleen for the review.

On 11/12/2015 12:30 PM, Coleen Phillimore wrote:
>
> Looks good.
>
> What is
>
> *!  #define INITIAL_RANGES_SIZE_205_*

We don't have to adjust that size - the table is dynamic and will adjust as needed, but chanhging this constants when 
adding new ranges will make sure we don't have to realloc, which should impact startup time.


cheers


>
>
> Do you have to update this whenever you add a range?
>
> Thanks,
> Coleen
>
> On 11/12/15 1:26 PM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating the feedback from David:
>>
>> - Use trivial range
>>
>>
>> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>>
>>
>> cheers
>>
>> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this small fix for JEP-245, which implements range for the last new runtime flag.
>>>
>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>
>>>
>>> Thank you.
>
>

From david.holmes at oracle.com  Thu Nov 12 20:35:01 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Nov 2015 06:35:01 +1000
Subject: (L) Prelim RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUyxEBHiSHvxGSj9_bxrF4ibp9zkp_k4V3fLAB1q04ni+A@mail.gmail.com>
References: <56370567.3090801@oracle.com>
	<CAPYFHW25iUpHwegK9NbYrB5B37q0T1=n=dneB6W6gwrs3eeoCg@mail.gmail.com>
	<CAPYFHW1-Vh6oxtd78reAyZ39_C5UtUSF+LBCTpdjC0txhumokA@mail.gmail.com>
	<563C19CF.30001@oracle.com> <563C4824.7040300@oracle.com>
	<CAA-vtUyTmHDJqAGD0rJi67srMdoiMnQjVe6VbCbfnjhkDQ=3cw@mail.gmail.com>
	<563D27B8.4040501@oracle.com>
	<CAA-vtUx1bj8CYw8YRs+PUL-Bag0a1fLj7yFyPtwVwnMybjYFTQ@mail.gmail.com>
	<5641D452.6040503@oracle.com> <5642FA07.8050309@oracle.com>
	<CAA-vtUzHSqTN-SW_Ew98pWJH3uqpty=RzUC+0ws2Y87ePxP3Fw@mail.gmail.com>
	<CAA-vtUxORNG_FLjP_bF7E5m9v=mSnMEOajo6e-XUeea5JgE0cQ@mail.gmail.com>
	<5643A3C4.3050803@oracle.com>
	<CAA-vtUyxEBHiSHvxGSj9_bxrF4ibp9zkp_k4V3fLAB1q04ni+A@mail.gmail.com>
Message-ID: <5644F7F5.9060202@oracle.com>

On 12/11/2015 11:51 PM, Thomas St?fe wrote:
> Hi David,
>
> builds and works on both variants (with and without
> USE_LIBRARY_BASED_TLS_ONLY) on AIX and Linux ppc.

Great - thanks!

> Small nitpicks:
>
> - I probably would have implemented Thread::current() using
> Thread::current_or_null().

I can do that. I presume the compiler will be smart enough. :)

> - Also, instead of using the "raw" ThreadLocalStorage::thread(), I would
> have liked a Thread::current_safe() or similar.

That's a reasonable suggestion too - I was influenced by existing usage, 
but could change it.

I'll send out the formal RFR once I have checked performance and done 
more testing.

Thanks,
David

> Kind Regards, Thomas
>
>
> On Wed, Nov 11, 2015 at 9:23 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Sorry Thomas the all important:
>
>     src/os/posix/vm/threadLocalStorage_posix.cpp
>
>     was missing from the webrev. Now adding.
>
>     David
>     -----
>
>     On 12/11/2015 2:47 AM, Thomas St?fe wrote:
>
>
>         On Wed, Nov 11, 2015 at 5:36 PM, Thomas St?fe
>         <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>
>         <mailto:thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>>> wrote:
>
>              Hi David,
>
>              I get build errors on all my platforms.
>
>              I think the change misses #include
>         "runtime/threadLocalStorage.hpp"
>              in a couple of places, at least thread.cpp and possible
>         also the
>              os_xx_yy.cpp files.
>
>
>         Sorry, I have to correct myself. It is a linker error, I do not
>         find the
>         implementations for the ThreadLocalStorage class methods anywhere. I
>         applied your patch atop a freshly synced hs-rt repo:
>
>         - .../hotspot $ hg log -l 3
>         changeset:   9317:3b23f69bc887 8132510__thread_davids_change
>         qbase qtip tip
>         user:        stuefe
>         date:        Wed Nov 11 16:12:14 2015 +0100
>         summary:     imported patch 8132510__thread_davids_change
>
>         changeset:   9316:f17e5edbe761 qparent
>         user:        tschatzl
>         date:        Tue Nov 10 11:07:15 2015 +0100
>         summary:     8140689: Skip last young-only gc if nothing to do
>         in the
>         mixed gc phase
>         Reviewed-by: mgerdin, drwhite
>
>         on AIX I get:
>
>         ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::thread()
>         ld: 0711-317 ERROR: Undefined symbol:
>         .ThreadLocalStorage::is_initialized()
>         ld: 0711-317 ERROR: Undefined symbol:
>         .ThreadLocalStorage::set_thread(Thread*)
>         ld: 0711-317 ERROR: Undefined symbol: .ThreadLocalStorage::init()
>
>         Am I building wrong?
>
>         Regards, Thomas
>
>
>              Will take another look tomorrow.
>
>              Thanks, Thomas
>
>              On Wed, Nov 11, 2015 at 9:19 AM, David Holmes
>              <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>                  Hi Thomas,
>
>                  Okay here's the next revision:
>
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v5/
>
>                  I've reinstated a basic ThreadLocalStorage class which
>         will only
>                  need two implementations: a POSIX one, and a Windows
>         one (still
>                  TBD). This class is always initialized and
>                  ThreadLocalStorage::thread() is used from the signal
>         handlers
>                  (as today).
>
>                  For platforms that don't have __thread support they can
>         define
>                  USE_LIBRARY_BASED_TLS_ONLY at build time to only use the
>                  ThreadLocalStorage implementation.
>
>                  Obviously still need to get some performance numbers.
>
>                  I'd appreciate it if you could retest AIX, though as all
>                  platforms currently use pthread_get/setspecific I'm
>         confident
>                  there will be no platform issues.
>
>                  Thanks,
>                  David
>
>
>
>

From john.r.rose at oracle.com  Thu Nov 12 20:53:33 2015
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Nov 2015 12:53:33 -0800
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <5643621E.9060206@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
	<5643621E.9060206@oracle.com>
Message-ID: <BBF03C9E-BDBA-4E8B-B0D4-12F68E802CBB@oracle.com>

On Nov 11, 2015, at 7:43 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Though previous comments were focused on dependency management code refactoring, I'd like to hear opinions about the fix itself - dependency management changes for j.l.i.CallSites to avoid modifications during concurrent traversals by GC threads.

Indeed, that's the tough part.

I'd like to ask a favor:  Since the refactoring moves a large block of code, could you please split out the simple textual move into a separate, prior webrev?  That way I can see exactly what tweaks were made during the move to the new file (instKlass => new depCon).

(This is a general feature of move-refactorings:  The webrev reports a large deletion in one place and a large, similar insertion in another place.  The reviewer asks, "What changed during the move?", but the webrev doesn't help.  The only way to view any small textual changes is to first discount all of the effects of the block move, and *then* look at the changes to the text block as if they were post-move tweaks.  The block move is a trivial change, but it should be isolated in another webrev to avoid interfering with the main review.)

? John

From john.r.rose at oracle.com  Thu Nov 12 23:16:56 2015
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Nov 2015 15:16:56 -0800
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <BBF03C9E-BDBA-4E8B-B0D4-12F68E802CBB@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
	<5643621E.9060206@oracle.com>
	<BBF03C9E-BDBA-4E8B-B0D4-12F68E802CBB@oracle.com>
Message-ID: <E14B1D8A-93C4-4903-83EE-CAF0A04144BE@oracle.com>

On Nov 12, 2015, at 12:53 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Nov 11, 2015, at 7:43 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> wrote:
>> 
>> Though previous comments were focused on dependency management code refactoring, I'd like to hear opinions about the fix itself - dependency management changes for j.l.i.CallSites to avoid modifications during concurrent traversals by GC threads.
> 
> Indeed, that's the tough part.

Pending the updated webrev, I have to say that it looks pretty good.

The nmethod bucket links stay around for a while, but we hope they don't build up too badly.  Can you describe how the worst case scenario occurs?  (Lots of nmethod compilation inlining a CS, but then a large number of calls to nmethod::flush_dependencies during a safepoint.)

Suggestion:   Maybe put in counters to track track (a) total number of bucket links and (b) number of stale ones.  (Is there a family of counters like this that we can add to?  Something in NMT?  A debug-only counter pair would be helpful, but even better would be something that would be more routinely tracked and dumped.)

What happens if we make a zillion nmethods using the same CS, and then they all go away at once during class unloading, so that the CS has *only* stale entries?  Who will clean up its bucket list?  When the GC frees the CS node from the managed heap, what will happen to the bucket list?will it be leaked onto the C heap?  Same question if the CS has one long-lived nmethod:  Will we hold onto the stale buckets?  If this turns out to be a problem (see counter suggestion above) maybe we need a sweeper task.  The nmethod sweeper might visit nmethods periodically and expunge their CS dependencies.

Another small point:  Are you sure Atomic::xchg_ptr does the job?  You don't check the return value, which is odd.  I think the code you wrote is the same as a store/release (volatile store).  Did you mean to use a CAS?  Or:
  intptr_t w = Atomic::xchg_ptr(v, ...):
  assert(((v ^ w) & ~_has_stale_entries_mask) == 0);

? John

From asmundak at google.com  Thu Nov 12 23:37:24 2015
From: asmundak at google.com (Alexander Smundak)
Date: Thu, 12 Nov 2015 15:37:24 -0800
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15
	floats in native call
Message-ID: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>

Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8139258.
I have tested in on Linux running on ppc64le.
I need a sponsor.

http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.00

Sasha

From david.holmes at oracle.com  Fri Nov 13 01:56:14 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Nov 2015 11:56:14 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5644D9EB.8070704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
Message-ID: <5645433E.3010702@oracle.com>

Looks fine.

Thanks,
David

On 13/11/2015 4:26 AM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating the feedback from David:
>
> - Use trivial range
>
>
> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>
>
> cheers
>
> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for
>> the last new runtime flag.
>>
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>
>>
>> Thank you.

From magnus.ihse.bursie at oracle.com  Fri Nov 13 02:34:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 13 Nov 2015 03:34:09 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the build-infra
	project
Message-ID: <56454C21.4010005@oracle.com>

In the new hotspot build project, we have made a few changes to the 
existing build. In preparation for the new build, I'd like to integrate 
these into mainline.

These changes are:
* When overriding optimization, do not lose current debug (-g) setting (!)
* Make adlc actually quiet in quiet mode
* Make g1EvacStats.cpp compile in all cases without precompiled headers
* Sort saproc object files when linking (facilitates comparison to new 
build)

Unless someone suggests otherwise, I intend to push this (using JPRT) to 
hs-rt.

Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01

/Magnus

From erik.joelsson at oracle.com  Fri Nov 13 08:13:21 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Nov 2015 09:13:21 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <56454C21.4010005@oracle.com>
References: <56454C21.4010005@oracle.com>
Message-ID: <56459BA1.1060604@oracle.com>

Hello,

make/bsd/makefiles/amd64.make:
make/bsd/makefiles/gcc.make:
Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))" 
should be reversed to guarantee that NOOPT is the one used in case 
BUILDARCH contains something that conflicts? The solaris file does it 
this way.

Otherwise looks good.

/Erik

On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
> In the new hotspot build project, we have made a few changes to the 
> existing build. In preparation for the new build, I'd like to 
> integrate these into mainline.
>
> These changes are:
> * When overriding optimization, do not lose current debug (-g) setting 
> (!)
> * Make adlc actually quiet in quiet mode
> * Make g1EvacStats.cpp compile in all cases without precompiled headers
> * Sort saproc object files when linking (facilitates comparison to new 
> build)
>
> Unless someone suggests otherwise, I intend to push this (using JPRT) 
> to hs-rt.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>
> /Magnus


From erik.joelsson at oracle.com  Fri Nov 13 10:39:21 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Nov 2015 11:39:21 +0100
Subject: RFR: JDK-8142336: Convert the SA agent build to modular
	build-infra makefiles
In-Reply-To: <56437025.4070504@oracle.com>
References: <5640E6E2.6090906@oracle.com> <5641C95D.8040103@oracle.com>
	<5641F5D3.1000105@oracle.com> <56430AF1.2050109@oracle.com>
	<56437025.4070504@oracle.com>
Message-ID: <5645BDD9.8070008@oracle.com>

Widening the distribution in the hopes of finding another reviewer.

I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make 
locally. Merge tool error.

/Erik

On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
> On 2015-11-11 10:31, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.02/
>>
>> Fixed the issues listed below. Reverted the faulty attempt at fixing 
>> a warning. Did a more thorough attempt at clearing out all references 
>> to SA in the old makefiles.
>
> Looks great. There was a few lines in 
> hotspot/make/bsd/makefiles/defs.make where you seem to have 
> accidentally broken the indentation. Apart from this it looks good. If 
> you just restore the indentation I'm okay (you don't need to respin 
> the webrev for that).
>
> /Magnus
>
>>
>> /Erik
>>
>> On 2015-11-10 14:49, Magnus Ihse Bursie wrote:
>>> On 2015-11-10 11:39, Magnus Ihse Bursie wrote:
>>>> On 2015-11-09 19:33, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> As a stepping stone in the hotspot makefile conversion, I have 
>>>>> broken out the serviceability agent separately and converted it 
>>>>> into proper modular build-infra makefiles. Doing this conversion 
>>>>> separately has some value on its own by reducing the special cases 
>>>>> currently needed for building the jdk.hotspot.agent module.
>>>>>
>>>>> The current SA java build compiles with the boot jdk javac with 
>>>>> -source/-target JDK N-1. The proposed change instead builds SA 
>>>>> with the interim-langtools javac for JDK N, like all the rest of 
>>>>> the JDK classes.
>>>>>
>>>>> There is already a bug filed for reorganizing the source of the SA 
>>>>> agent to conform to the Jigsaw style modular source layout: 
>>>>> JDK-8067194, so I have left the source in its current location.
>>>>>
>>>>> The native compilation and linking has been changed to base the 
>>>>> flags used on what configure sets up for the other JDK libraries. 
>>>>> This has caused some changes in flag usage. From what I can tell, 
>>>>> nothing important is different however. I have run the relevant 
>>>>> jtreg tests on all OSes to verify that it still works. Some of the 
>>>>> differences include:
>>>>>
>>>>> * Linux: "-Xlinker z -Xlinker defs" was added to LDFLAGS, which 
>>>>> causes link failure unless "-ldl" was also added to LIBS.
>>>>> * Solaris: More warnings activated through "+w" caused need for 
>>>>> disabling some warnings. I fixed one warning instance which was 
>>>>> trivial (int->size_t), but couldn't figure out the rest. I will 
>>>>> file a followup bug for fixing those if this patch is accepted.
>>>>>
>>>>> I tried to mimic the current behavior of excluding SA on linux-ppc 
>>>>> and zero that Volker added a while back. Now it's excluded on the 
>>>>> module level instead so that jdk.hotspot.agent isn't even built in 
>>>>> that case. It would be good if this could be tested.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>>>>
>>>> A few remarks:
>>>>
>>>> * Could you please document the new DISABLED_WARNINGS_CXX and 
>>>> DISABLED_WARNINGS_C in the function header?
>>>>
>>>> * I believe the use of {} here was to signify a set. When only jsig 
>>>> remains, it just looks strange:
>>>> -# SYMFLAG is used by {jsig,saproc}.make
>>>> +# SYMFLAG is used by {jsig}.make
>>>>
>>>> * The logic of setting up "--hash-style=both" is already done in 
>>>> configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if 
>>>> you include the LDFLAGS_JDKLIB variable.
>>>
>>> Also, SA_WINDOWS_LDFLAGS is read but never defined.
>>>
>>> /Magnus
>>
>


From thomas.stuefe at gmail.com  Fri Nov 13 11:04:03 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 13 Nov 2015 12:04:03 +0100
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564280FD.7090300@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5642602F.50606@oracle.com>
	<2B615442-B9FD-41AF-A5CE-A51E57A18DC7@oracle.com>
	<564280FD.7090300@oracle.com>
Message-ID: <CAA-vtUxVXgnXXrWuXjBpTocOW8H5pJ37LxN+ZRmvURorPFRuRw@mail.gmail.com>

Hi Colleen, Christian,

On Wed, Nov 11, 2015 at 12:42 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
>
> On 11/10/15 6:30 PM, Christian Thalinger wrote:
>
>> On Nov 10, 2015, at 11:22 AM, Coleen Phillimore <
>>> coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>> I think the upper range should be much higher.   This sleep is also
>>> something that keeps the jvm alive if you are debugging and have multiple
>>> places that crash, and haven't set ShowMessageBoxOnError. Setting this flag
>>> to something very high will prevent the debugger from timing out with:
>>>
>>>           err.print_raw_cr("# [ timer expired, abort... ]");
>>>
>>> which is really annoying.
>>>
>> It is!  Since we are talking about this, why do we have that?
>>
>
> There's a comment that this sleeps 2 minutes to allow the hs_err_pid file
> to get printed before exit, which might be necessary, so we wouldn't want
> it to sleep indefinitely in that case.
>


The log timeout is very useful in our server scenarios, when a server node
shall come up after a crash in a defined time. But the 2 minutes hardwired
timeout was too small or too large depending on what you do, so we
introduced this parameter.



>
> I #if0 out this code whenever I'm debugging but specifying ErrorLogTimeout
> = very large would be a good workaround.
>
>
I would be fine with setting the default to max. The default now is 2
minutes because that was what was hard-coded before.

Regards, Thomas.

Coleen
>
>
>>    I'd almost suggest MAX_INT as the upper range, but maybe 60*60*60   60
>>> hours would do.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/10/15 2:34 PM, gerard ziemski wrote:
>>>
>>>> hi all,
>>>>
>>>> Please review this small fix for JEP-245, which implements range for
>>>> the last new runtime flag.
>>>>
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>>> webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>>
>>>>
>>>> Thank you.
>>>>
>>>>
>>>>
>

From magnus.ihse.bursie at oracle.com  Fri Nov 13 11:33:50 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 13 Nov 2015 12:33:50 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <56459BA1.1060604@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
Message-ID: <5645CA9E.4060205@oracle.com>

On 2015-11-13 09:13, Erik Joelsson wrote:
> Hello,
>
> make/bsd/makefiles/amd64.make:
> make/bsd/makefiles/gcc.make:
> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))" 
> should be reversed to guarantee that NOOPT is the one used in case 
> BUILDARCH contains something that conflicts? The solaris file does it 
> this way.
You know you wrote that code originally? ;-)

Yeah, I agree, it's more reasonable. Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02

/Magnus

>
> Otherwise looks good.
>
> /Erik
>
> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>> In the new hotspot build project, we have made a few changes to the 
>> existing build. In preparation for the new build, I'd like to 
>> integrate these into mainline.
>>
>> These changes are:
>> * When overriding optimization, do not lose current debug (-g) 
>> setting (!)
>> * Make adlc actually quiet in quiet mode
>> * Make g1EvacStats.cpp compile in all cases without precompiled headers
>> * Sort saproc object files when linking (facilitates comparison to 
>> new build)
>>
>> Unless someone suggests otherwise, I intend to push this (using JPRT) 
>> to hs-rt.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>>
>> /Magnus
>


From coleen.phillimore at oracle.com  Fri Nov 13 14:40:10 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 13 Nov 2015 09:40:10 -0500
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <56454C21.4010005@oracle.com>
References: <56454C21.4010005@oracle.com>
Message-ID: <5645F64A.4020004@oracle.com>


The change to g1EvacStats.hpp file to include atomic.inline.hpp breaks 
the rule that we shouldn't include .inline files to .hpp files.  I have 
a different change for this same thing but I can make that change after 
yours.   Kim finally found out why I couldn't build Zero so that's 
coming too.

Thanks,
Coleen

On 11/12/15 9:34 PM, Magnus Ihse Bursie wrote:
> In the new hotspot build project, we have made a few changes to the 
> existing build. In preparation for the new build, I'd like to 
> integrate these into mainline.
>
> These changes are:
> * When overriding optimization, do not lose current debug (-g) setting 
> (!)
> * Make adlc actually quiet in quiet mode
> * Make g1EvacStats.cpp compile in all cases without precompiled headers
> * Sort saproc object files when linking (facilitates comparison to new 
> build)
>
> Unless someone suggests otherwise, I intend to push this (using JPRT) 
> to hs-rt.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>
> /Magnus


From konstantin.shefov at oracle.com  Fri Nov 13 14:55:02 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 13 Nov 2015 17:55:02 +0300
Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool
Message-ID: <5645F9C6.2070802@oracle.com>

Hello

Please review an enhancement to add three new methods to 
sun.reflect.ConstantPool class.
The following methods are suggested:

public String[] getNameAndTypeRefInfoAt(int index) - returns string 
representation of name and type from a NameAndType constant pool entry 
with the specified index

public String[] getInvokedynamicRefInfoAt(int index) - returns string 
representation of name and type from an InvokeDynamic constant pool 
entry with the specified index

public Tag getTagAt(int index) - returns a Tag enum instance of a 
constant pool entry with the specified index

These three methods could be used for testing API working with constant 
pool, e.g. JVMCI.

JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
Webrev hotspot: 
http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00

Thanks
-Konstantin

From martin.doerr at sap.com  Fri Nov 13 14:57:28 2015
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 13 Nov 2015 14:57:28 +0000
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15	floats in native call
In-Reply-To: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>

Hi Sasha,

thank you very much for debugging the interpreter. The test passes as long as the method gets interpreted, now.
However, I didn't get the right result when running with -Xcomp.
I guess there's still something wrong with the native wrapper (generate_native_wrapper / float_move etc.) for PPC64LE.

Btw. I think the defined(VM_LITTLE_ENDIAN) should be used. I'd simply change the code to
#if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
  __ stfs(floatSlot, 4, arg_c);
#else
  __ stfs(floatSlot, 0, arg_c);
#endif

Best regards and thanks again,
  Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak
Sent: Freitag, 13. November 2015 00:37
To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15 floats in native call

Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8139258.
I have tested in on Linux running on ppc64le.
I need a sponsor.

http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.00

Sasha

From erik.joelsson at oracle.com  Fri Nov 13 16:42:30 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Nov 2015 17:42:30 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <5645CA9E.4060205@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com>
Message-ID: <564612F6.8060507@oracle.com>

Looks good!

/Erik

On 2015-11-13 12:33, Magnus Ihse Bursie wrote:
> On 2015-11-13 09:13, Erik Joelsson wrote:
>> Hello,
>>
>> make/bsd/makefiles/amd64.make:
>> make/bsd/makefiles/gcc.make:
>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))" 
>> should be reversed to guarantee that NOOPT is the one used in case 
>> BUILDARCH contains something that conflicts? The solaris file does it 
>> this way.
> You know you wrote that code originally? ;-)
>
> Yeah, I agree, it's more reasonable. Updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02
>
> /Magnus
>
>>
>> Otherwise looks good.
>>
>> /Erik
>>
>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>> In the new hotspot build project, we have made a few changes to the 
>>> existing build. In preparation for the new build, I'd like to 
>>> integrate these into mainline.
>>>
>>> These changes are:
>>> * When overriding optimization, do not lose current debug (-g) 
>>> setting (!)
>>> * Make adlc actually quiet in quiet mode
>>> * Make g1EvacStats.cpp compile in all cases without precompiled headers
>>> * Sort saproc object files when linking (facilitates comparison to 
>>> new build)
>>>
>>> Unless someone suggests otherwise, I intend to push this (using 
>>> JPRT) to hs-rt.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>>>
>>> /Magnus
>>
>


From volker.simonis at gmail.com  Fri Nov 13 17:24:29 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Nov 2015 18:24:29 +0100
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15 floats in native call
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
Message-ID: <CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>

On Fri, Nov 13, 2015 at 3:57 PM, Doerr, Martin <martin.doerr at sap.com> wrote:
> Hi Sasha,
>
> thank you very much for debugging the interpreter. The test passes as long as the method gets interpreted, now.
> However, I didn't get the right result when running with -Xcomp.
> I guess there's still something wrong with the native wrapper (generate_native_wrapper / float_move etc.) for PPC64LE.
>
> Btw. I think the defined(VM_LITTLE_ENDIAN) should be used. I'd simply change the code to
> #if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
>   __ stfs(floatSlot, 4, arg_c);
> #else
>   __ stfs(floatSlot, 0, arg_c);
> #endif
>

That's good, but I'd add comment like:

#if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
  __ stfs(floatSlot, 4, arg_c);
#else
  // This handles Linux/little-endian and AIX which is big-endian but
stores the floats in the
  // most-significant bytes of a double while the Linux ABI places
them in the least-significant bytes.
  __ stfs(floatSlot, 0, arg_c);
#endif

> Best regards and thanks again,
>   Martin
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak
> Sent: Freitag, 13. November 2015 00:37
> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
> Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15 floats in native call
>
> Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8139258.
> I have tested in on Linux running on ppc64le.
> I need a sponsor.
>
> http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.00
>
> Sasha

From asmundak at google.com  Sat Nov 14 00:18:27 2015
From: asmundak at google.com (Alexander Smundak)
Date: Fri, 13 Nov 2015 16:18:27 -0800
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15 floats in native call
In-Reply-To: <CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
	<CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>
Message-ID: <CAHQ51u4qPZTZ0xATvKSXt1sayEah5bUWv2yrqaYmpz19P2TfBg@mail.gmail.com>

Please find the updated patch at
http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.01

I have added the changes for the compiled case, and added comments.
I have kept AIX and Linux cases separate, though -- IMHO mixing them
would make the situation logically less clear.

Note that I wasn't able to run JDK9 with -Xcomp on the Power8 machine
I have (I am investigating the reason currently), so have I modified
the test case to invoke the JNI method sufficiently large number of
times for the JIT to kick in. I have also tested in on JDK8u40 we are
currently using where -Xcomp works.

On Fri, Nov 13, 2015 at 9:24 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Fri, Nov 13, 2015 at 3:57 PM, Doerr, Martin <martin.doerr at sap.com> wrote:
>> Hi Sasha,
>>
>> thank you very much for debugging the interpreter. The test passes as long as the method gets interpreted, now.
>> However, I didn't get the right result when running with -Xcomp.
>> I guess there's still something wrong with the native wrapper (generate_native_wrapper / float_move etc.) for PPC64LE.
>>
>> Btw. I think the defined(VM_LITTLE_ENDIAN) should be used. I'd simply change the code to
>> #if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
>>   __ stfs(floatSlot, 4, arg_c);
>> #else
>>   __ stfs(floatSlot, 0, arg_c);
>> #endif
>>
>
> That's good, but I'd add comment like:
>
> #if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
>   __ stfs(floatSlot, 4, arg_c);
> #else
>   // This handles Linux/little-endian and AIX which is big-endian but
> stores the floats in the
>   // most-significant bytes of a double while the Linux ABI places
> them in the least-significant bytes.
>   __ stfs(floatSlot, 0, arg_c);
> #endif
>
>> Best regards and thanks again,
>>   Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak
>> Sent: Freitag, 13. November 2015 00:37
>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15 floats in native call
>>
>> Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8139258.
>> I have tested in on Linux running on ppc64le.
>> I need a sponsor.
>>
>> http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.00
>>
>> Sasha

From kirk at kodewerk.com  Sun Nov 15 08:25:34 2015
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Sun, 15 Nov 2015 09:25:34 +0100
Subject: jdk 9 performance optimizations
In-Reply-To: <94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
	<94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
Message-ID: <E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>

Hi Remi,

In general I think that it?s not well known that dynamically loading a class often results in a de-optimization storm.

Regards,
Kirk

> On Nov 12, 2015, at 9:20 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Christian,
> 
> Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <christian.thalinger at oracle.com> a ?crit :
>> 
>>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com>
>> wrote:
>>> 
>>> Hi Christian,
>>> 
>>> Thanks for the clarification, I over-simplified. Can you please shed
>> some
>>> light on my questions? How can jigsaw help with AOT, inlining
>> lambda?s?
>> 
>> I think the text you are quoting is more a blanket statement of what
>> could be done.  Some of the listed optimizations might even be done on
>> a class file level.
>> 
>> One area where JDK 9 can help is if all classes (JDK and application)
>> are bundled together AOT compilation can optimize more optimistically.
>> Of course dynamic class loading can break all assumptions but that?s
>> another story.
> 
> If your application is a trading application you don't want your application to dynamically load an unknown class.
> 
> My opinion is that the AOT should come with a flag les say 'closed world'  that throw an exception if an unknown class force the runtime to go to a deopt.
> 
> cheers,
> R?mi
> 
>> 
>>> I did my jug talk already yesterday, yet, I am curious.
>>> Thanks!
>>> 
>>> Jeroen
>>> 
>>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
>>> christian.thalinger at oracle.com>:
>>> 
>>>> 
>>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
>> <jborgers at jpinpoint.com>
>>>> wrote:
>>>>> 
>>>>> I posted in jigsaw-dev list before:
>>>>> 
>>>>> I found this interesting presentation "Java goes AOT" from JVM
>> Language
>>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
>>>>> 
>>>>> As presented by Christiaan Thalinger from HS compiler team, AOT is
>> used
>>>>> with Graal to reduce startup time and quicker peakperformance
>> (tiered).
>>>>> Currently they don't do any inlining in AOT yet
>>>> 
>>>> That?s not accurate; we do inlining but very limited.
>>>> 
>>>>> because compilation time
>>>>> blows up by inlining everything since no profiling information is
>>>> available
>>>>> yet. I guess modules and knowing dependencies can help here to
>> reduce
>>>> this.
>>>>> Besides test running to generate profiling data.
>>>>> 
>>>>> Regards, Jeroen
>>>>> Bijlagen
>>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
>>>>> JVMLS 2015 - Java Goes AOT
>>>>> Vitaly Davidovich
>>>>> 13:09 (10 uur geleden)
>>>>> aan Jeroen, jigsaw-dev
>>>>> 
>>>>> Yes, I had seen Chris' presentation as well.  Certainly
>> modularization
>>>> will
>>>>> help AOT in many ways.  But, I'm particularly interested on the JIT
>> side.
>>>>> What was meant by aggressive lambda inlining, for example? Can
>> anyone
>>>> point
>>>>> at some additional info?
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> sent from my phone
>>>>> Paul Sandoz <paul.sandoz at oracle.com>
>>>>> 13:32 (9 uur geleden)
>>>>> aan jigsaw-dev
>>>>> Hi Vitaly,
>>>>> 
>>>>> Probably worth sending an email to the hotspot-dev at openjdk.java.net
>>>> <mailto:
>>>>> hotspot-dev at openjdk.java.net>
>>>>> 
>>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com>
>> wrote:
>>>>>> 
>>>>>> Yes, I had seen Chris' presentation as well.  Certainly
>> modularization
>>>>> will
>>>>>> help AOT in many ways.  But, I'm particularly interested on the
>> JIT
>>>> side.
>>>>>> What was meant by aggressive lambda inlining, for example? Can
>> anyone
>>>>> point
>>>>>> at some additional info?
>>>>>> 
>>>>> 
>>>>> I presume it in part might relate to cracking open the lambda ?box?
>>>>> implementing the targeted functional interface to obtain the
>> underlying
>>>>> method containing the lambda body, generated by javac, that the box
>>>> defers
>>>>> to, then subsituting the indy call to an invocation of that
>> underlying
>>>>> method. Cue lots of hand waving?
>>>>> 
>>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
>> presentation at
>>>>> JVMLS 2014:
>>>>> 
>>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
>>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
>>>>> --------
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Jeroen
>>>>> 
>>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> One of the goals of Jigsaw that intrigue me, I read here:
>>>> http://openjdk.
>>>>>> java
>>>>>> 
>>>> 
>> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>>>>>> is:
>>>>>> *Enable ahead-of-time, whole-program optimization techniques*  -
>>>>>> [..]
>>>>>> The optimization techniques envisioned here include, but are not
>> limited
>>>>>> to: Fast lookup of both JDK and application classes; early
>> bytecode
>>>>>> verification; aggressive inlining of, *e.g.*, lambda expressions,
>> and
>>>>>> other standard compiler optimizations; construction of
>> JVM-specific
>>>> memory
>>>>>> images that can be loaded more efficiently than class files;
>>>> ahead-of-time
>>>>>> compilation of method bodies to native code; and the removal of
>> unused
>>>>>> fields, methods, and classes. These kinds of techniques tend to
>> work
>>>> best
>>>>>> when JDK and application code is analyzed together, prior to run
>> time.
>>>>>> [..]
>>>>>> 
>>>>>> -
>>>>>> 
>>>>>> *Optimize existing code as-is* ? It must be possible to apply the
>>>>>> optimizer tool to existing code already packaged in traditional
>> jar
>>>> files,
>>>>>> without changing those files.
>>>>>> -
>>>>>> 
>>>>>> *Actual optimizations* ? As a proof of concept, provide at least
>> two
>>>>>> optimizations that deliver nontrivial performance benefits.
>>>>>> 
>>>>>> I am curious about the following:
>>>>>> * What is the current state of this? Which
>> techniques/optimizations are
>>>>>> already implemented and available from the current ea JDK9 or will
>> be?
>>>>>> * Are there any new insights/developments in this area?
>>>>>> * I noticed in my JMH microbenchmark with parallel stream and
>> lambda's
>>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
>> this be
>>>>>> caused by more aggressive inlining of lambda's?
>>>>>> * It seems to me that some compilation and optimization work is
>> moved
>>>> from
>>>>>> runtime to link time /AOT time, yet, we don't have profiling
>> information
>>>>>> there, so this will be limited, right? Are there obvious cases
>> which
>>>> work
>>>>>> well?
>>>>>> * I don't really see why aggressive inlining and std optimizations
>> can
>>>> now
>>>>>> be more effective. Because there will be less de-optimization
>> events
>>>> needed
>>>>>> because of better predictability? Can in-lining now take place in
>> two
>>>> ways,
>>>>>> between platform modules and application? Through interfaces?
>>>>>> 
>>>>>> Thanks!
>>>>>> Jeroen
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
> 


From vitalyd at gmail.com  Sun Nov 15 16:41:42 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Sun, 15 Nov 2015 11:41:42 -0500
Subject: jdk 9 performance optimizations
In-Reply-To: <E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
	<94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
	<E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>
Message-ID: <CAHjP37F_1nEFW50JUn_p6b8iXGh=54C2KBhrZLiaqZuxdJTxAw@mail.gmail.com>

It's not even just class loading invalidating speculative optimizations, it
can be as pedestrian as a branch becoming reachable.  I'd say class loading
is more known than the latter; I've personally been surprised how some
"simple" branches were pruned and cause deopt when reached.  This is
particularly a problem in daemons running with a low compile threshold.  I
understand the motivation for doing that, but sometimes it's very/overly
aggressive.

sent from my phone
On Nov 15, 2015 3:26 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

> Hi Remi,
>
> In general I think that it?s not well known that dynamically loading a
> class often results in a de-optimization storm.
>
> Regards,
> Kirk
>
> > On Nov 12, 2015, at 9:20 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
> >
> > Hi Christian,
> >
> > Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <
> christian.thalinger at oracle.com> a ?crit :
> >>
> >>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com>
> >> wrote:
> >>>
> >>> Hi Christian,
> >>>
> >>> Thanks for the clarification, I over-simplified. Can you please shed
> >> some
> >>> light on my questions? How can jigsaw help with AOT, inlining
> >> lambda?s?
> >>
> >> I think the text you are quoting is more a blanket statement of what
> >> could be done.  Some of the listed optimizations might even be done on
> >> a class file level.
> >>
> >> One area where JDK 9 can help is if all classes (JDK and application)
> >> are bundled together AOT compilation can optimize more optimistically.
> >> Of course dynamic class loading can break all assumptions but that?s
> >> another story.
> >
> > If your application is a trading application you don't want your
> application to dynamically load an unknown class.
> >
> > My opinion is that the AOT should come with a flag les say 'closed
> world'  that throw an exception if an unknown class force the runtime to go
> to a deopt.
> >
> > cheers,
> > R?mi
> >
> >>
> >>> I did my jug talk already yesterday, yet, I am curious.
> >>> Thanks!
> >>>
> >>> Jeroen
> >>>
> >>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
> >>> christian.thalinger at oracle.com>:
> >>>
> >>>>
> >>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
> >> <jborgers at jpinpoint.com>
> >>>> wrote:
> >>>>>
> >>>>> I posted in jigsaw-dev list before:
> >>>>>
> >>>>> I found this interesting presentation "Java goes AOT" from JVM
> >> Language
> >>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
> >>>>>
> >>>>> As presented by Christiaan Thalinger from HS compiler team, AOT is
> >> used
> >>>>> with Graal to reduce startup time and quicker peakperformance
> >> (tiered).
> >>>>> Currently they don't do any inlining in AOT yet
> >>>>
> >>>> That?s not accurate; we do inlining but very limited.
> >>>>
> >>>>> because compilation time
> >>>>> blows up by inlining everything since no profiling information is
> >>>> available
> >>>>> yet. I guess modules and knowing dependencies can help here to
> >> reduce
> >>>> this.
> >>>>> Besides test running to generate profiling data.
> >>>>>
> >>>>> Regards, Jeroen
> >>>>> Bijlagen
> >>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
> >>>>> JVMLS 2015 - Java Goes AOT
> >>>>> Vitaly Davidovich
> >>>>> 13:09 (10 uur geleden)
> >>>>> aan Jeroen, jigsaw-dev
> >>>>>
> >>>>> Yes, I had seen Chris' presentation as well.  Certainly
> >> modularization
> >>>> will
> >>>>> help AOT in many ways.  But, I'm particularly interested on the JIT
> >> side.
> >>>>> What was meant by aggressive lambda inlining, for example? Can
> >> anyone
> >>>> point
> >>>>> at some additional info?
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> sent from my phone
> >>>>> Paul Sandoz <paul.sandoz at oracle.com>
> >>>>> 13:32 (9 uur geleden)
> >>>>> aan jigsaw-dev
> >>>>> Hi Vitaly,
> >>>>>
> >>>>> Probably worth sending an email to the hotspot-dev at openjdk.java.net
> >>>> <mailto:
> >>>>> hotspot-dev at openjdk.java.net>
> >>>>>
> >>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com>
> >> wrote:
> >>>>>>
> >>>>>> Yes, I had seen Chris' presentation as well.  Certainly
> >> modularization
> >>>>> will
> >>>>>> help AOT in many ways.  But, I'm particularly interested on the
> >> JIT
> >>>> side.
> >>>>>> What was meant by aggressive lambda inlining, for example? Can
> >> anyone
> >>>>> point
> >>>>>> at some additional info?
> >>>>>>
> >>>>>
> >>>>> I presume it in part might relate to cracking open the lambda ?box?
> >>>>> implementing the targeted functional interface to obtain the
> >> underlying
> >>>>> method containing the lambda body, generated by javac, that the box
> >>>> defers
> >>>>> to, then subsituting the indy call to an invocation of that
> >> underlying
> >>>>> method. Cue lots of hand waving?
> >>>>>
> >>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
> >> presentation at
> >>>>> JVMLS 2014:
> >>>>>
> >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
> >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
> >>>>> --------
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Jeroen
> >>>>>
> >>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> One of the goals of Jigsaw that intrigue me, I read here:
> >>>> http://openjdk.
> >>>>>> java
> >>>>>>
> >>>>
> >>
> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
> >>>>>> is:
> >>>>>> *Enable ahead-of-time, whole-program optimization techniques*  -
> >>>>>> [..]
> >>>>>> The optimization techniques envisioned here include, but are not
> >> limited
> >>>>>> to: Fast lookup of both JDK and application classes; early
> >> bytecode
> >>>>>> verification; aggressive inlining of, *e.g.*, lambda expressions,
> >> and
> >>>>>> other standard compiler optimizations; construction of
> >> JVM-specific
> >>>> memory
> >>>>>> images that can be loaded more efficiently than class files;
> >>>> ahead-of-time
> >>>>>> compilation of method bodies to native code; and the removal of
> >> unused
> >>>>>> fields, methods, and classes. These kinds of techniques tend to
> >> work
> >>>> best
> >>>>>> when JDK and application code is analyzed together, prior to run
> >> time.
> >>>>>> [..]
> >>>>>>
> >>>>>> -
> >>>>>>
> >>>>>> *Optimize existing code as-is* ? It must be possible to apply the
> >>>>>> optimizer tool to existing code already packaged in traditional
> >> jar
> >>>> files,
> >>>>>> without changing those files.
> >>>>>> -
> >>>>>>
> >>>>>> *Actual optimizations* ? As a proof of concept, provide at least
> >> two
> >>>>>> optimizations that deliver nontrivial performance benefits.
> >>>>>>
> >>>>>> I am curious about the following:
> >>>>>> * What is the current state of this? Which
> >> techniques/optimizations are
> >>>>>> already implemented and available from the current ea JDK9 or will
> >> be?
> >>>>>> * Are there any new insights/developments in this area?
> >>>>>> * I noticed in my JMH microbenchmark with parallel stream and
> >> lambda's
> >>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
> >> this be
> >>>>>> caused by more aggressive inlining of lambda's?
> >>>>>> * It seems to me that some compilation and optimization work is
> >> moved
> >>>> from
> >>>>>> runtime to link time /AOT time, yet, we don't have profiling
> >> information
> >>>>>> there, so this will be limited, right? Are there obvious cases
> >> which
> >>>> work
> >>>>>> well?
> >>>>>> * I don't really see why aggressive inlining and std optimizations
> >> can
> >>>> now
> >>>>>> be more effective. Because there will be less de-optimization
> >> events
> >>>> needed
> >>>>>> because of better predictability? Can in-lining now take place in
> >> two
> >>>> ways,
> >>>>>> between platform modules and application? Through interfaces?
> >>>>>>
> >>>>>> Thanks!
> >>>>>> Jeroen
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >
>
>

From forax at univ-mlv.fr  Sun Nov 15 17:32:03 2015
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 15 Nov 2015 18:32:03 +0100 (CET)
Subject: jdk 9 performance optimizations
In-Reply-To: <CAHjP37F_1nEFW50JUn_p6b8iXGh=54C2KBhrZLiaqZuxdJTxAw@mail.gmail.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
	<94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
	<E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>
	<CAHjP37F_1nEFW50JUn_p6b8iXGh=54C2KBhrZLiaqZuxdJTxAw@mail.gmail.com>
Message-ID: <1420247731.3418004.1447608723671.JavaMail.zimbra@u-pem.fr>

Vitaly, Kirk, 
there are several modes of ahead of time compilation. 

One, the one you are talking about, is to AOT the modules with a jlink backend and then at runtime to use the JIT to get the best of both world, 
in that case you can have a deopt when a branch was never taken or a class is loaded. 
I was talking about another mode, AOT with no JIT, like when you want to create an application on iOS, in that case i don't think that trying to go to the interpreter makes sense. 

regards, 
R?mi 

----- Mail original -----

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> ?: "Kirk Pepperdine" <kirk at kodewerk.com>
> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "R?mi Forax"
> <forax at univ-mlv.fr>
> Envoy?: Dimanche 15 Novembre 2015 17:41:42
> Objet: Re: jdk 9 performance optimizations

> It's not even just class loading invalidating speculative optimizations, it
> can be as pedestrian as a branch becoming reachable. I'd say class loading
> is more known than the latter; I've personally been surprised how some
> "simple" branches were pruned and cause deopt when reached. This is
> particularly a problem in daemons running with a low compile threshold. I
> understand the motivation for doing that, but sometimes it's very/overly
> aggressive.

> sent from my phone
> On Nov 15, 2015 3:26 AM, "Kirk Pepperdine" < kirk at kodewerk.com > wrote:

> > Hi Remi,
> 

> > In general I think that it?s not well known that dynamically loading a
> > class
> > often results in a de-optimization storm.
> 

> > Regards,
> 
> > Kirk
> 

> > > On Nov 12, 2015, at 9:20 AM, R?mi Forax < forax at univ-mlv.fr > wrote:
> 
> > >
> 
> > > Hi Christian,
> 
> > >
> 
> > > Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <
> > > christian.thalinger at oracle.com > a ?crit :
> 
> > >>
> 
> > >>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers < jborgers at jpinpoint.com >
> 
> > >> wrote:
> 
> > >>>
> 
> > >>> Hi Christian,
> 
> > >>>
> 
> > >>> Thanks for the clarification, I over-simplified. Can you please shed
> 
> > >> some
> 
> > >>> light on my questions? How can jigsaw help with AOT, inlining
> 
> > >> lambda?s?
> 
> > >>
> 
> > >> I think the text you are quoting is more a blanket statement of what
> 
> > >> could be done. Some of the listed optimizations might even be done on
> 
> > >> a class file level.
> 
> > >>
> 
> > >> One area where JDK 9 can help is if all classes (JDK and application)
> 
> > >> are bundled together AOT compilation can optimize more optimistically.
> 
> > >> Of course dynamic class loading can break all assumptions but that?s
> 
> > >> another story.
> 
> > >
> 
> > > If your application is a trading application you don't want your
> > > application to dynamically load an unknown class.
> 
> > >
> 
> > > My opinion is that the AOT should come with a flag les say 'closed world'
> > > that throw an exception if an unknown class force the runtime to go to a
> > > deopt.
> 
> > >
> 
> > > cheers,
> 
> > > R?mi
> 
> > >
> 
> > >>
> 
> > >>> I did my jug talk already yesterday, yet, I am curious.
> 
> > >>> Thanks!
> 
> > >>>
> 
> > >>> Jeroen
> 
> > >>>
> 
> > >>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
> 
> > >>> christian.thalinger at oracle.com >:
> 
> > >>>
> 
> > >>>>
> 
> > >>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
> 
> > >> < jborgers at jpinpoint.com >
> 
> > >>>> wrote:
> 
> > >>>>>
> 
> > >>>>> I posted in jigsaw-dev list before:
> 
> > >>>>>
> 
> > >>>>> I found this interesting presentation "Java goes AOT" from JVM
> 
> > >> Language
> 
> > >>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
> 
> > >>>>>
> 
> > >>>>> As presented by Christiaan Thalinger from HS compiler team, AOT is
> 
> > >> used
> 
> > >>>>> with Graal to reduce startup time and quicker peakperformance
> 
> > >> (tiered).
> 
> > >>>>> Currently they don't do any inlining in AOT yet
> 
> > >>>>
> 
> > >>>> That?s not accurate; we do inlining but very limited.
> 
> > >>>>
> 
> > >>>>> because compilation time
> 
> > >>>>> blows up by inlining everything since no profiling information is
> 
> > >>>> available
> 
> > >>>>> yet. I guess modules and knowing dependencies can help here to
> 
> > >> reduce
> 
> > >>>> this.
> 
> > >>>>> Besides test running to generate profiling data.
> 
> > >>>>>
> 
> > >>>>> Regards, Jeroen
> 
> > >>>>> Bijlagen
> 
> > >>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
> 
> > >>>>> JVMLS 2015 - Java Goes AOT
> 
> > >>>>> Vitaly Davidovich
> 
> > >>>>> 13:09 (10 uur geleden)
> 
> > >>>>> aan Jeroen, jigsaw-dev
> 
> > >>>>>
> 
> > >>>>> Yes, I had seen Chris' presentation as well. Certainly
> 
> > >> modularization
> 
> > >>>> will
> 
> > >>>>> help AOT in many ways. But, I'm particularly interested on the JIT
> 
> > >> side.
> 
> > >>>>> What was meant by aggressive lambda inlining, for example? Can
> 
> > >> anyone
> 
> > >>>> point
> 
> > >>>>> at some additional info?
> 
> > >>>>>
> 
> > >>>>> Thanks
> 
> > >>>>>
> 
> > >>>>> sent from my phone
> 
> > >>>>> Paul Sandoz < paul.sandoz at oracle.com >
> 
> > >>>>> 13:32 (9 uur geleden)
> 
> > >>>>> aan jigsaw-dev
> 
> > >>>>> Hi Vitaly,
> 
> > >>>>>
> 
> > >>>>> Probably worth sending an email to the hotspot-dev at openjdk.java.net
> 
> > >>>> <mailto:
> 
> > >>>>> hotspot-dev at openjdk.java.net >
> 
> > >>>>>
> 
> > >>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich < vitalyd at gmail.com >
> 
> > >> wrote:
> 
> > >>>>>>
> 
> > >>>>>> Yes, I had seen Chris' presentation as well. Certainly
> 
> > >> modularization
> 
> > >>>>> will
> 
> > >>>>>> help AOT in many ways. But, I'm particularly interested on the
> 
> > >> JIT
> 
> > >>>> side.
> 
> > >>>>>> What was meant by aggressive lambda inlining, for example? Can
> 
> > >> anyone
> 
> > >>>>> point
> 
> > >>>>>> at some additional info?
> 
> > >>>>>>
> 
> > >>>>>
> 
> > >>>>> I presume it in part might relate to cracking open the lambda ?box?
> 
> > >>>>> implementing the targeted functional interface to obtain the
> 
> > >> underlying
> 
> > >>>>> method containing the lambda body, generated by javac, that the box
> 
> > >>>> defers
> 
> > >>>>> to, then subsituting the indy call to an invocation of that
> 
> > >> underlying
> 
> > >>>>> method. Cue lots of hand waving?
> 
> > >>>>>
> 
> > >>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
> 
> > >> presentation at
> 
> > >>>>> JVMLS 2014:
> 
> > >>>>>
> 
> > >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
> 
> > >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf >
> 
> > >>>>> --------
> 
> > >>>>>
> 
> > >>>>> Thanks,
> 
> > >>>>>
> 
> > >>>>> Jeroen
> 
> > >>>>>
> 
> > >>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers < jborgers at jpinpoint.com >:
> 
> > >>>>>
> 
> > >>>>>> Hi,
> 
> > >>>>>>
> 
> > >>>>>> One of the goals of Jigsaw that intrigue me, I read here:
> 
> > >>>> http://openjdk .
> 
> > >>>>>> java
> 
> > >>>>>>
> 
> > >>>>
> 
> > >> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
> 
> > >>>>>> is:
> 
> > >>>>>> *Enable ahead-of-time, whole-program optimization techniques* -
> 
> > >>>>>> [..]
> 
> > >>>>>> The optimization techniques envisioned here include, but are not
> 
> > >> limited
> 
> > >>>>>> to: Fast lookup of both JDK and application classes; early
> 
> > >> bytecode
> 
> > >>>>>> verification; aggressive inlining of, *e.g.*, lambda expressions,
> 
> > >> and
> 
> > >>>>>> other standard compiler optimizations; construction of
> 
> > >> JVM-specific
> 
> > >>>> memory
> 
> > >>>>>> images that can be loaded more efficiently than class files;
> 
> > >>>> ahead-of-time
> 
> > >>>>>> compilation of method bodies to native code; and the removal of
> 
> > >> unused
> 
> > >>>>>> fields, methods, and classes. These kinds of techniques tend to
> 
> > >> work
> 
> > >>>> best
> 
> > >>>>>> when JDK and application code is analyzed together, prior to run
> 
> > >> time.
> 
> > >>>>>> [..]
> 
> > >>>>>>
> 
> > >>>>>> -
> 
> > >>>>>>
> 
> > >>>>>> *Optimize existing code as-is* ? It must be possible to apply the
> 
> > >>>>>> optimizer tool to existing code already packaged in traditional
> 
> > >> jar
> 
> > >>>> files,
> 
> > >>>>>> without changing those files.
> 
> > >>>>>> -
> 
> > >>>>>>
> 
> > >>>>>> *Actual optimizations* ? As a proof of concept, provide at least
> 
> > >> two
> 
> > >>>>>> optimizations that deliver nontrivial performance benefits.
> 
> > >>>>>>
> 
> > >>>>>> I am curious about the following:
> 
> > >>>>>> * What is the current state of this? Which
> 
> > >> techniques/optimizations are
> 
> > >>>>>> already implemented and available from the current ea JDK9 or will
> 
> > >> be?
> 
> > >>>>>> * Are there any new insights/developments in this area?
> 
> > >>>>>> * I noticed in my JMH microbenchmark with parallel stream and
> 
> > >> lambda's
> 
> > >>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
> 
> > >> this be
> 
> > >>>>>> caused by more aggressive inlining of lambda's?
> 
> > >>>>>> * It seems to me that some compilation and optimization work is
> 
> > >> moved
> 
> > >>>> from
> 
> > >>>>>> runtime to link time /AOT time, yet, we don't have profiling
> 
> > >> information
> 
> > >>>>>> there, so this will be limited, right? Are there obvious cases
> 
> > >> which
> 
> > >>>> work
> 
> > >>>>>> well?
> 
> > >>>>>> * I don't really see why aggressive inlining and std optimizations
> 
> > >> can
> 
> > >>>> now
> 
> > >>>>>> be more effective. Because there will be less de-optimization
> 
> > >> events
> 
> > >>>> needed
> 
> > >>>>>> because of better predictability? Can in-lining now take place in
> 
> > >> two
> 
> > >>>> ways,
> 
> > >>>>>> between platform modules and application? Through interfaces?
> 
> > >>>>>>
> 
> > >>>>>> Thanks!
> 
> > >>>>>> Jeroen
> 
> > >>>>>>
> 
> > >>>>>>
> 
> > >>>>>>
> 
> > >>>>
> 
> > >>>>
> 
> > >
> 

From vitalyd at gmail.com  Sun Nov 15 20:05:33 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Sun, 15 Nov 2015 15:05:33 -0500
Subject: jdk 9 performance optimizations
In-Reply-To: <1420247731.3418004.1447608723671.JavaMail.zimbra@u-pem.fr>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEnUBv-WdMpUcDu7eM2m0w02CPkWZPFG2Hmhc_mPY4fRSw@mail.gmail.com>
	<8D5484F3-633A-4080-9B25-016BA7BDF382@oracle.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
	<94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
	<E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>
	<CAHjP37F_1nEFW50JUn_p6b8iXGh=54C2KBhrZLiaqZuxdJTxAw@mail.gmail.com>
	<1420247731.3418004.1447608723671.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAHjP37Hd0mv1PphCNqBqCenm-bBNKKejyj2eDn1e-WXqwYbRdg@mail.gmail.com>

Hi Remi,

What would the performance be of 100% AOT? Java pretty much requires
profile guided optimization to be performant, the language itself has a
very poor performance model.

sent from my phone
On Nov 15, 2015 12:32 PM, <forax at univ-mlv.fr> wrote:

> Vitaly, Kirk,
> there are several modes of ahead of time compilation.
>
> One, the one you are talking about, is to AOT the modules with a jlink
> backend and then at runtime to use the JIT to get the best of both world,
> in that case you can have a deopt when a branch was never taken or a class
> is loaded.
> I was talking about another mode, AOT with no JIT, like when you want to
> create an application on iOS, in that case i don't think that trying to go
> to the interpreter makes sense.
>
> regards,
> R?mi
>
> ------------------------------
>
> *De: *"Vitaly Davidovich" <vitalyd at gmail.com>
> *?: *"Kirk Pepperdine" <kirk at kodewerk.com>
> *Cc: *"hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "R?mi
> Forax" <forax at univ-mlv.fr>
> *Envoy?: *Dimanche 15 Novembre 2015 17:41:42
> *Objet: *Re: jdk 9 performance optimizations
>
> It's not even just class loading invalidating speculative optimizations,
> it can be as pedestrian as a branch becoming reachable.  I'd say class
> loading is more known than the latter; I've personally been surprised how
> some "simple" branches were pruned and cause deopt when reached.  This is
> particularly a problem in daemons running with a low compile threshold.  I
> understand the motivation for doing that, but sometimes it's very/overly
> aggressive.
>
> sent from my phone
> On Nov 15, 2015 3:26 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
>
>> Hi Remi,
>>
>> In general I think that it?s not well known that dynamically loading a
>> class often results in a de-optimization storm.
>>
>> Regards,
>> Kirk
>>
>> > On Nov 12, 2015, at 9:20 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
>> >
>> > Hi Christian,
>> >
>> > Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <
>> christian.thalinger at oracle.com> a ?crit :
>> >>
>> >>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com>
>> >> wrote:
>> >>>
>> >>> Hi Christian,
>> >>>
>> >>> Thanks for the clarification, I over-simplified. Can you please shed
>> >> some
>> >>> light on my questions? How can jigsaw help with AOT, inlining
>> >> lambda?s?
>> >>
>> >> I think the text you are quoting is more a blanket statement of what
>> >> could be done.  Some of the listed optimizations might even be done on
>> >> a class file level.
>> >>
>> >> One area where JDK 9 can help is if all classes (JDK and application)
>> >> are bundled together AOT compilation can optimize more optimistically.
>> >> Of course dynamic class loading can break all assumptions but that?s
>> >> another story.
>> >
>> > If your application is a trading application you don't want your
>> application to dynamically load an unknown class.
>> >
>> > My opinion is that the AOT should come with a flag les say 'closed
>> world'  that throw an exception if an unknown class force the runtime to go
>> to a deopt.
>> >
>> > cheers,
>> > R?mi
>> >
>> >>
>> >>> I did my jug talk already yesterday, yet, I am curious.
>> >>> Thanks!
>> >>>
>> >>> Jeroen
>> >>>
>> >>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
>> >>> christian.thalinger at oracle.com>:
>> >>>
>> >>>>
>> >>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
>> >> <jborgers at jpinpoint.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> I posted in jigsaw-dev list before:
>> >>>>>
>> >>>>> I found this interesting presentation "Java goes AOT" from JVM
>> >> Language
>> >>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
>> >>>>>
>> >>>>> As presented by Christiaan Thalinger from HS compiler team, AOT is
>> >> used
>> >>>>> with Graal to reduce startup time and quicker peakperformance
>> >> (tiered).
>> >>>>> Currently they don't do any inlining in AOT yet
>> >>>>
>> >>>> That?s not accurate; we do inlining but very limited.
>> >>>>
>> >>>>> because compilation time
>> >>>>> blows up by inlining everything since no profiling information is
>> >>>> available
>> >>>>> yet. I guess modules and knowing dependencies can help here to
>> >> reduce
>> >>>> this.
>> >>>>> Besides test running to generate profiling data.
>> >>>>>
>> >>>>> Regards, Jeroen
>> >>>>> Bijlagen
>> >>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
>> >>>>> JVMLS 2015 - Java Goes AOT
>> >>>>> Vitaly Davidovich
>> >>>>> 13:09 (10 uur geleden)
>> >>>>> aan Jeroen, jigsaw-dev
>> >>>>>
>> >>>>> Yes, I had seen Chris' presentation as well.  Certainly
>> >> modularization
>> >>>> will
>> >>>>> help AOT in many ways.  But, I'm particularly interested on the JIT
>> >> side.
>> >>>>> What was meant by aggressive lambda inlining, for example? Can
>> >> anyone
>> >>>> point
>> >>>>> at some additional info?
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> sent from my phone
>> >>>>> Paul Sandoz <paul.sandoz at oracle.com>
>> >>>>> 13:32 (9 uur geleden)
>> >>>>> aan jigsaw-dev
>> >>>>> Hi Vitaly,
>> >>>>>
>> >>>>> Probably worth sending an email to the hotspot-dev at openjdk.java.net
>> >>>> <mailto:
>> >>>>> hotspot-dev at openjdk.java.net>
>> >>>>>
>> >>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com>
>> >> wrote:
>> >>>>>>
>> >>>>>> Yes, I had seen Chris' presentation as well.  Certainly
>> >> modularization
>> >>>>> will
>> >>>>>> help AOT in many ways.  But, I'm particularly interested on the
>> >> JIT
>> >>>> side.
>> >>>>>> What was meant by aggressive lambda inlining, for example? Can
>> >> anyone
>> >>>>> point
>> >>>>>> at some additional info?
>> >>>>>>
>> >>>>>
>> >>>>> I presume it in part might relate to cracking open the lambda ?box?
>> >>>>> implementing the targeted functional interface to obtain the
>> >> underlying
>> >>>>> method containing the lambda body, generated by javac, that the box
>> >>>> defers
>> >>>>> to, then subsituting the indy call to an invocation of that
>> >> underlying
>> >>>>> method. Cue lots of hand waving?
>> >>>>>
>> >>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
>> >> presentation at
>> >>>>> JVMLS 2014:
>> >>>>>
>> >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf <
>> >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
>> >>>>> --------
>> >>>>>
>> >>>>> Thanks,
>> >>>>>
>> >>>>> Jeroen
>> >>>>>
>> >>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com>:
>> >>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> One of the goals of Jigsaw that intrigue me, I read here:
>> >>>> http://openjdk.
>> >>>>>> java
>> >>>>>>
>> >>>>
>> >>
>> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>> >>>>>> is:
>> >>>>>> *Enable ahead-of-time, whole-program optimization techniques*  -
>> >>>>>> [..]
>> >>>>>> The optimization techniques envisioned here include, but are not
>> >> limited
>> >>>>>> to: Fast lookup of both JDK and application classes; early
>> >> bytecode
>> >>>>>> verification; aggressive inlining of, *e.g.*, lambda expressions,
>> >> and
>> >>>>>> other standard compiler optimizations; construction of
>> >> JVM-specific
>> >>>> memory
>> >>>>>> images that can be loaded more efficiently than class files;
>> >>>> ahead-of-time
>> >>>>>> compilation of method bodies to native code; and the removal of
>> >> unused
>> >>>>>> fields, methods, and classes. These kinds of techniques tend to
>> >> work
>> >>>> best
>> >>>>>> when JDK and application code is analyzed together, prior to run
>> >> time.
>> >>>>>> [..]
>> >>>>>>
>> >>>>>> -
>> >>>>>>
>> >>>>>> *Optimize existing code as-is* ? It must be possible to apply the
>> >>>>>> optimizer tool to existing code already packaged in traditional
>> >> jar
>> >>>> files,
>> >>>>>> without changing those files.
>> >>>>>> -
>> >>>>>>
>> >>>>>> *Actual optimizations* ? As a proof of concept, provide at least
>> >> two
>> >>>>>> optimizations that deliver nontrivial performance benefits.
>> >>>>>>
>> >>>>>> I am curious about the following:
>> >>>>>> * What is the current state of this? Which
>> >> techniques/optimizations are
>> >>>>>> already implemented and available from the current ea JDK9 or will
>> >> be?
>> >>>>>> * Are there any new insights/developments in this area?
>> >>>>>> * I noticed in my JMH microbenchmark with parallel stream and
>> >> lambda's
>> >>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
>> >> this be
>> >>>>>> caused by more aggressive inlining of lambda's?
>> >>>>>> * It seems to me that some compilation and optimization work is
>> >> moved
>> >>>> from
>> >>>>>> runtime to link time /AOT time, yet, we don't have profiling
>> >> information
>> >>>>>> there, so this will be limited, right? Are there obvious cases
>> >> which
>> >>>> work
>> >>>>>> well?
>> >>>>>> * I don't really see why aggressive inlining and std optimizations
>> >> can
>> >>>> now
>> >>>>>> be more effective. Because there will be less de-optimization
>> >> events
>> >>>> needed
>> >>>>>> because of better predictability? Can in-lining now take place in
>> >> two
>> >>>> ways,
>> >>>>>> between platform modules and application? Through interfaces?
>> >>>>>>
>> >>>>>> Thanks!
>> >>>>>> Jeroen
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >
>>
>>
>

From forax at univ-mlv.fr  Sun Nov 15 20:23:07 2015
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 15 Nov 2015 21:23:07 +0100 (CET)
Subject: jdk 9 performance optimizations
In-Reply-To: <CAHjP37Hd0mv1PphCNqBqCenm-bBNKKejyj2eDn1e-WXqwYbRdg@mail.gmail.com>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
	<94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
	<E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>
	<CAHjP37F_1nEFW50JUn_p6b8iXGh=54C2KBhrZLiaqZuxdJTxAw@mail.gmail.com>
	<1420247731.3418004.1447608723671.JavaMail.zimbra@u-pem.fr>
	<CAHjP37Hd0mv1PphCNqBqCenm-bBNKKejyj2eDn1e-WXqwYbRdg@mail.gmail.com>
Message-ID: <1624076800.3474406.1447618987248.JavaMail.zimbra@u-pem.fr>

Android Runtime (ART) or Swift performance are not that bad on mobile. 

R?mi 

----- Mail original -----

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> ?: "R?mi Forax" <forax at univ-mlv.fr>
> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "Kirk
> Pepperdine" <kirk at kodewerk.com>
> Envoy?: Dimanche 15 Novembre 2015 21:05:33
> Objet: Re: jdk 9 performance optimizations

> Hi Remi,

> What would the performance be of 100% AOT? Java pretty much requires profile
> guided optimization to be performant, the language itself has a very poor
> performance model.

> sent from my phone
> On Nov 15, 2015 12:32 PM, < forax at univ-mlv.fr > wrote:

> > Vitaly, Kirk,
> 
> > there are several modes of ahead of time compilation.
> 

> > One, the one you are talking about, is to AOT the modules with a jlink
> > backend and then at runtime to use the JIT to get the best of both world,
> 
> > in that case you can have a deopt when a branch was never taken or a class
> > is
> > loaded.
> 
> > I was talking about another mode, AOT with no JIT, like when you want to
> > create an application on iOS, in that case i don't think that trying to go
> > to the interpreter makes sense.
> 

> > regards,
> 
> > R?mi
> 

> > > De: "Vitaly Davidovich" < vitalyd at gmail.com >
> > 
> 
> > > ?: "Kirk Pepperdine" < kirk at kodewerk.com >
> > 
> 
> > > Cc: "hotspot-dev developers" < hotspot-dev at openjdk.java.net >, "R?mi
> > > Forax"
> > > <
> > > forax at univ-mlv.fr >
> > 
> 
> > > Envoy?: Dimanche 15 Novembre 2015 17:41:42
> > 
> 
> > > Objet: Re: jdk 9 performance optimizations
> > 
> 

> > > It's not even just class loading invalidating speculative optimizations,
> > > it
> > > can be as pedestrian as a branch becoming reachable. I'd say class
> > > loading
> > > is more known than the latter; I've personally been surprised how some
> > > "simple" branches were pruned and cause deopt when reached. This is
> > > particularly a problem in daemons running with a low compile threshold. I
> > > understand the motivation for doing that, but sometimes it's very/overly
> > > aggressive.
> > 
> 

> > > sent from my phone
> > 
> 
> > > On Nov 15, 2015 3:26 AM, "Kirk Pepperdine" < kirk at kodewerk.com > wrote:
> > 
> 

> > > > Hi Remi,
> > > 
> > 
> 

> > > > In general I think that it?s not well known that dynamically loading a
> > > > class
> > > > often results in a de-optimization storm.
> > > 
> > 
> 

> > > > Regards,
> > > 
> > 
> 
> > > > Kirk
> > > 
> > 
> 

> > > > > On Nov 12, 2015, at 9:20 AM, R?mi Forax < forax at univ-mlv.fr > wrote:
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > Hi Christian,
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <
> > > > > christian.thalinger at oracle.com > a ?crit :
> > > 
> > 
> 
> > > > >>
> > > 
> > 
> 
> > > > >>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <
> > > > >>> jborgers at jpinpoint.com
> > > > >>> >
> > > 
> > 
> 
> > > > >> wrote:
> > > 
> > 
> 
> > > > >>>
> > > 
> > 
> 
> > > > >>> Hi Christian,
> > > 
> > 
> 
> > > > >>>
> > > 
> > 
> 
> > > > >>> Thanks for the clarification, I over-simplified. Can you please
> > > > >>> shed
> > > 
> > 
> 
> > > > >> some
> > > 
> > 
> 
> > > > >>> light on my questions? How can jigsaw help with AOT, inlining
> > > 
> > 
> 
> > > > >> lambda?s?
> > > 
> > 
> 
> > > > >>
> > > 
> > 
> 
> > > > >> I think the text you are quoting is more a blanket statement of what
> > > 
> > 
> 
> > > > >> could be done. Some of the listed optimizations might even be done
> > > > >> on
> > > 
> > 
> 
> > > > >> a class file level.
> > > 
> > 
> 
> > > > >>
> > > 
> > 
> 
> > > > >> One area where JDK 9 can help is if all classes (JDK and
> > > > >> application)
> > > 
> > 
> 
> > > > >> are bundled together AOT compilation can optimize more
> > > > >> optimistically.
> > > 
> > 
> 
> > > > >> Of course dynamic class loading can break all assumptions but that?s
> > > 
> > 
> 
> > > > >> another story.
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > If your application is a trading application you don't want your
> > > > > application to dynamically load an unknown class.
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > My opinion is that the AOT should come with a flag les say 'closed
> > > > > world'
> > > > > that throw an exception if an unknown class force the runtime to go
> > > > > to
> > > > > a
> > > > > deopt.
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > cheers,
> > > 
> > 
> 
> > > > > R?mi
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > >>
> > > 
> > 
> 
> > > > >>> I did my jug talk already yesterday, yet, I am curious.
> > > 
> > 
> 
> > > > >>> Thanks!
> > > 
> > 
> 
> > > > >>>
> > > 
> > 
> 
> > > > >>> Jeroen
> > > 
> > 
> 
> > > > >>>
> > > 
> > 
> 
> > > > >>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
> > > 
> > 
> 
> > > > >>> christian.thalinger at oracle.com >:
> > > 
> > 
> 
> > > > >>>
> > > 
> > 
> 
> > > > >>>>
> > > 
> > 
> 
> > > > >>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
> > > 
> > 
> 
> > > > >> < jborgers at jpinpoint.com >
> > > 
> > 
> 
> > > > >>>> wrote:
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> I posted in jigsaw-dev list before:
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> I found this interesting presentation "Java goes AOT" from JVM
> > > 
> > 
> 
> > > > >> Language
> > > 
> > 
> 
> > > > >>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> As presented by Christiaan Thalinger from HS compiler team, AOT
> > > > >>>>> is
> > > 
> > 
> 
> > > > >> used
> > > 
> > 
> 
> > > > >>>>> with Graal to reduce startup time and quicker peakperformance
> > > 
> > 
> 
> > > > >> (tiered).
> > > 
> > 
> 
> > > > >>>>> Currently they don't do any inlining in AOT yet
> > > 
> > 
> 
> > > > >>>>
> > > 
> > 
> 
> > > > >>>> That?s not accurate; we do inlining but very limited.
> > > 
> > 
> 
> > > > >>>>
> > > 
> > 
> 
> > > > >>>>> because compilation time
> > > 
> > 
> 
> > > > >>>>> blows up by inlining everything since no profiling information is
> > > 
> > 
> 
> > > > >>>> available
> > > 
> > 
> 
> > > > >>>>> yet. I guess modules and knowing dependencies can help here to
> > > 
> > 
> 
> > > > >> reduce
> > > 
> > 
> 
> > > > >>>> this.
> > > 
> > 
> 
> > > > >>>>> Besides test running to generate profiling data.
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Regards, Jeroen
> > > 
> > 
> 
> > > > >>>>> Bijlagen
> > > 
> > 
> 
> > > > >>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
> > > 
> > 
> 
> > > > >>>>> JVMLS 2015 - Java Goes AOT
> > > 
> > 
> 
> > > > >>>>> Vitaly Davidovich
> > > 
> > 
> 
> > > > >>>>> 13:09 (10 uur geleden)
> > > 
> > 
> 
> > > > >>>>> aan Jeroen, jigsaw-dev
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Yes, I had seen Chris' presentation as well. Certainly
> > > 
> > 
> 
> > > > >> modularization
> > > 
> > 
> 
> > > > >>>> will
> > > 
> > 
> 
> > > > >>>>> help AOT in many ways. But, I'm particularly interested on the
> > > > >>>>> JIT
> > > 
> > 
> 
> > > > >> side.
> > > 
> > 
> 
> > > > >>>>> What was meant by aggressive lambda inlining, for example? Can
> > > 
> > 
> 
> > > > >> anyone
> > > 
> > 
> 
> > > > >>>> point
> > > 
> > 
> 
> > > > >>>>> at some additional info?
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Thanks
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> sent from my phone
> > > 
> > 
> 
> > > > >>>>> Paul Sandoz < paul.sandoz at oracle.com >
> > > 
> > 
> 
> > > > >>>>> 13:32 (9 uur geleden)
> > > 
> > 
> 
> > > > >>>>> aan jigsaw-dev
> > > 
> > 
> 
> > > > >>>>> Hi Vitaly,
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Probably worth sending an email to the
> > > > >>>>> hotspot-dev at openjdk.java.net
> > > 
> > 
> 
> > > > >>>> <mailto:
> > > 
> > 
> 
> > > > >>>>> hotspot-dev at openjdk.java.net >
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich < vitalyd at gmail.com >
> > > 
> > 
> 
> > > > >> wrote:
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> Yes, I had seen Chris' presentation as well. Certainly
> > > 
> > 
> 
> > > > >> modularization
> > > 
> > 
> 
> > > > >>>>> will
> > > 
> > 
> 
> > > > >>>>>> help AOT in many ways. But, I'm particularly interested on the
> > > 
> > 
> 
> > > > >> JIT
> > > 
> > 
> 
> > > > >>>> side.
> > > 
> > 
> 
> > > > >>>>>> What was meant by aggressive lambda inlining, for example? Can
> > > 
> > 
> 
> > > > >> anyone
> > > 
> > 
> 
> > > > >>>>> point
> > > 
> > 
> 
> > > > >>>>>> at some additional info?
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> I presume it in part might relate to cracking open the lambda
> > > > >>>>> ?box?
> > > 
> > 
> 
> > > > >>>>> implementing the targeted functional interface to obtain the
> > > 
> > 
> 
> > > > >> underlying
> > > 
> > 
> 
> > > > >>>>> method containing the lambda body, generated by javac, that the
> > > > >>>>> box
> > > 
> > 
> 
> > > > >>>> defers
> > > 
> > 
> 
> > > > >>>>> to, then subsituting the indy call to an invocation of that
> > > 
> > 
> 
> > > > >> underlying
> > > 
> > 
> 
> > > > >>>>> method. Cue lots of hand waving?
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
> > > 
> > 
> 
> > > > >> presentation at
> > > 
> > 
> 
> > > > >>>>> JVMLS 2014:
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf
> > > > >>>>> <
> > > 
> > 
> 
> > > > >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf
> > > > >>>>> >
> > > 
> > 
> 
> > > > >>>>> --------
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Thanks,
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> Jeroen
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <
> > > > >>>>> jborgers at jpinpoint.com
> > > > >>>>> >:
> > > 
> > 
> 
> > > > >>>>>
> > > 
> > 
> 
> > > > >>>>>> Hi,
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> One of the goals of Jigsaw that intrigue me, I read here:
> > > 
> > 
> 
> > > > >>>> http://openjdk .
> > > 
> > 
> 
> > > > >>>>>> java
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>
> > > 
> > 
> 
> > > > >> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
> > > 
> > 
> 
> > > > >>>>>> is:
> > > 
> > 
> 
> > > > >>>>>> *Enable ahead-of-time, whole-program optimization techniques* -
> > > 
> > 
> 
> > > > >>>>>> [..]
> > > 
> > 
> 
> > > > >>>>>> The optimization techniques envisioned here include, but are not
> > > 
> > 
> 
> > > > >> limited
> > > 
> > 
> 
> > > > >>>>>> to: Fast lookup of both JDK and application classes; early
> > > 
> > 
> 
> > > > >> bytecode
> > > 
> > 
> 
> > > > >>>>>> verification; aggressive inlining of, *e.g.*, lambda
> > > > >>>>>> expressions,
> > > 
> > 
> 
> > > > >> and
> > > 
> > 
> 
> > > > >>>>>> other standard compiler optimizations; construction of
> > > 
> > 
> 
> > > > >> JVM-specific
> > > 
> > 
> 
> > > > >>>> memory
> > > 
> > 
> 
> > > > >>>>>> images that can be loaded more efficiently than class files;
> > > 
> > 
> 
> > > > >>>> ahead-of-time
> > > 
> > 
> 
> > > > >>>>>> compilation of method bodies to native code; and the removal of
> > > 
> > 
> 
> > > > >> unused
> > > 
> > 
> 
> > > > >>>>>> fields, methods, and classes. These kinds of techniques tend to
> > > 
> > 
> 
> > > > >> work
> > > 
> > 
> 
> > > > >>>> best
> > > 
> > 
> 
> > > > >>>>>> when JDK and application code is analyzed together, prior to run
> > > 
> > 
> 
> > > > >> time.
> > > 
> > 
> 
> > > > >>>>>> [..]
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> -
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> *Optimize existing code as-is* ? It must be possible to apply
> > > > >>>>>> the
> > > 
> > 
> 
> > > > >>>>>> optimizer tool to existing code already packaged in traditional
> > > 
> > 
> 
> > > > >> jar
> > > 
> > 
> 
> > > > >>>> files,
> > > 
> > 
> 
> > > > >>>>>> without changing those files.
> > > 
> > 
> 
> > > > >>>>>> -
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> *Actual optimizations* ? As a proof of concept, provide at least
> > > 
> > 
> 
> > > > >> two
> > > 
> > 
> 
> > > > >>>>>> optimizations that deliver nontrivial performance benefits.
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> I am curious about the following:
> > > 
> > 
> 
> > > > >>>>>> * What is the current state of this? Which
> > > 
> > 
> 
> > > > >> techniques/optimizations are
> > > 
> > 
> 
> > > > >>>>>> already implemented and available from the current ea JDK9 or
> > > > >>>>>> will
> > > 
> > 
> 
> > > > >> be?
> > > 
> > 
> 
> > > > >>>>>> * Are there any new insights/developments in this area?
> > > 
> > 
> 
> > > > >>>>>> * I noticed in my JMH microbenchmark with parallel stream and
> > > 
> > 
> 
> > > > >> lambda's
> > > 
> > 
> 
> > > > >>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
> > > 
> > 
> 
> > > > >> this be
> > > 
> > 
> 
> > > > >>>>>> caused by more aggressive inlining of lambda's?
> > > 
> > 
> 
> > > > >>>>>> * It seems to me that some compilation and optimization work is
> > > 
> > 
> 
> > > > >> moved
> > > 
> > 
> 
> > > > >>>> from
> > > 
> > 
> 
> > > > >>>>>> runtime to link time /AOT time, yet, we don't have profiling
> > > 
> > 
> 
> > > > >> information
> > > 
> > 
> 
> > > > >>>>>> there, so this will be limited, right? Are there obvious cases
> > > 
> > 
> 
> > > > >> which
> > > 
> > 
> 
> > > > >>>> work
> > > 
> > 
> 
> > > > >>>>>> well?
> > > 
> > 
> 
> > > > >>>>>> * I don't really see why aggressive inlining and std
> > > > >>>>>> optimizations
> > > 
> > 
> 
> > > > >> can
> > > 
> > 
> 
> > > > >>>> now
> > > 
> > 
> 
> > > > >>>>>> be more effective. Because there will be less de-optimization
> > > 
> > 
> 
> > > > >> events
> > > 
> > 
> 
> > > > >>>> needed
> > > 
> > 
> 
> > > > >>>>>> because of better predictability? Can in-lining now take place
> > > > >>>>>> in
> > > 
> > 
> 
> > > > >> two
> > > 
> > 
> 
> > > > >>>> ways,
> > > 
> > 
> 
> > > > >>>>>> between platform modules and application? Through interfaces?
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>> Thanks!
> > > 
> > 
> 
> > > > >>>>>> Jeroen
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>>>
> > > 
> > 
> 
> > > > >>>>
> > > 
> > 
> 
> > > > >>>>
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 

From vitalyd at gmail.com  Sun Nov 15 20:59:47 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Sun, 15 Nov 2015 15:59:47 -0500
Subject: jdk 9 performance optimizations
In-Reply-To: <1624076800.3474406.1447618987248.JavaMail.zimbra@u-pem.fr>
References: <CAP3hAEkWvbTORxhwWRyK4R6LODN=+oT6Tu1gmhY6kyvaE4PjOA@mail.gmail.com>
	<CAP3hAEmeJiqNujN3=7GdvrN66Z30-s1Bj=JBD5waYbzTbsJ6bw@mail.gmail.com>
	<DF864F19-85F3-4BBA-85AD-F01DFE9559E1@oracle.com>
	<94BB42CC-1A6E-4D08-A9CF-672002754B1E@univ-mlv.fr>
	<E0E75EAF-DBE7-466F-BE56-3D611988A15B@kodewerk.com>
	<CAHjP37F_1nEFW50JUn_p6b8iXGh=54C2KBhrZLiaqZuxdJTxAw@mail.gmail.com>
	<1420247731.3418004.1447608723671.JavaMail.zimbra@u-pem.fr>
	<CAHjP37Hd0mv1PphCNqBqCenm-bBNKKejyj2eDn1e-WXqwYbRdg@mail.gmail.com>
	<1624076800.3474406.1447618987248.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAHjP37EWGFUSery=tH8cskQu88mrurvPDj0=evaKP7fsg9ihfA@mail.gmail.com>

I'm not overly familiar with Swift, but from the little I do know it seems
to have a better perf model; reified generics with specialization at use
site, struct/value types, etc.  It's also written to target a mature and
highly optimizing backend (LLVM) right from the start.

sent from my phone
On Nov 15, 2015 3:23 PM, <forax at univ-mlv.fr> wrote:

> Android Runtime (ART) or Swift performance are not that bad on mobile.
>
> R?mi
>
> ------------------------------
>
> *De: *"Vitaly Davidovich" <vitalyd at gmail.com>
> *?: *"R?mi Forax" <forax at univ-mlv.fr>
> *Cc: *"hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "Kirk
> Pepperdine" <kirk at kodewerk.com>
> *Envoy?: *Dimanche 15 Novembre 2015 21:05:33
> *Objet: *Re: jdk 9 performance optimizations
>
> Hi Remi,
>
> What would the performance be of 100% AOT? Java pretty much requires
> profile guided optimization to be performant, the language itself has a
> very poor performance model.
>
> sent from my phone
> On Nov 15, 2015 12:32 PM, <forax at univ-mlv.fr> wrote:
>
>> Vitaly, Kirk,
>> there are several modes of ahead of time compilation.
>>
>> One, the one you are talking about, is to AOT the modules with a jlink
>> backend and then at runtime to use the JIT to get the best of both world,
>> in that case you can have a deopt when a branch was never taken or a
>> class is loaded.
>> I was talking about another mode, AOT with no JIT, like when you want to
>> create an application on iOS, in that case i don't think that trying to go
>> to the interpreter makes sense.
>>
>> regards,
>> R?mi
>>
>> ------------------------------
>>
>> *De: *"Vitaly Davidovich" <vitalyd at gmail.com>
>> *?: *"Kirk Pepperdine" <kirk at kodewerk.com>
>> *Cc: *"hotspot-dev developers" <hotspot-dev at openjdk.java.net>, "R?mi
>> Forax" <forax at univ-mlv.fr>
>> *Envoy?: *Dimanche 15 Novembre 2015 17:41:42
>> *Objet: *Re: jdk 9 performance optimizations
>>
>> It's not even just class loading invalidating speculative optimizations,
>> it can be as pedestrian as a branch becoming reachable.  I'd say class
>> loading is more known than the latter; I've personally been surprised how
>> some "simple" branches were pruned and cause deopt when reached.  This is
>> particularly a problem in daemons running with a low compile threshold.  I
>> understand the motivation for doing that, but sometimes it's very/overly
>> aggressive.
>>
>> sent from my phone
>> On Nov 15, 2015 3:26 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
>>
>>> Hi Remi,
>>>
>>> In general I think that it?s not well known that dynamically loading a
>>> class often results in a de-optimization storm.
>>>
>>> Regards,
>>> Kirk
>>>
>>> > On Nov 12, 2015, at 9:20 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
>>> >
>>> > Hi Christian,
>>> >
>>> > Le 11 novembre 2015 19:58:30 CET, Christian Thalinger <
>>> christian.thalinger at oracle.com> a ?crit :
>>> >>
>>> >>> On Nov 5, 2015, at 10:58 PM, Jeroen Borgers <jborgers at jpinpoint.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi Christian,
>>> >>>
>>> >>> Thanks for the clarification, I over-simplified. Can you please shed
>>> >> some
>>> >>> light on my questions? How can jigsaw help with AOT, inlining
>>> >> lambda?s?
>>> >>
>>> >> I think the text you are quoting is more a blanket statement of what
>>> >> could be done.  Some of the listed optimizations might even be done on
>>> >> a class file level.
>>> >>
>>> >> One area where JDK 9 can help is if all classes (JDK and application)
>>> >> are bundled together AOT compilation can optimize more optimistically.
>>> >> Of course dynamic class loading can break all assumptions but that?s
>>> >> another story.
>>> >
>>> > If your application is a trading application you don't want your
>>> application to dynamically load an unknown class.
>>> >
>>> > My opinion is that the AOT should come with a flag les say 'closed
>>> world'  that throw an exception if an unknown class force the runtime to go
>>> to a deopt.
>>> >
>>> > cheers,
>>> > R?mi
>>> >
>>> >>
>>> >>> I did my jug talk already yesterday, yet, I am curious.
>>> >>> Thanks!
>>> >>>
>>> >>> Jeroen
>>> >>>
>>> >>> 2015-11-05 21:27 GMT+01:00 Christian Thalinger <
>>> >>> christian.thalinger at oracle.com>:
>>> >>>
>>> >>>>
>>> >>>>> On Nov 3, 2015, at 12:26 PM, Jeroen Borgers
>>> >> <jborgers at jpinpoint.com>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> I posted in jigsaw-dev list before:
>>> >>>>>
>>> >>>>> I found this interesting presentation "Java goes AOT" from JVM
>>> >> Language
>>> >>>>> Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc
>>> >>>>>
>>> >>>>> As presented by Christiaan Thalinger from HS compiler team, AOT is
>>> >> used
>>> >>>>> with Graal to reduce startup time and quicker peakperformance
>>> >> (tiered).
>>> >>>>> Currently they don't do any inlining in AOT yet
>>> >>>>
>>> >>>> That?s not accurate; we do inlining but very limited.
>>> >>>>
>>> >>>>> because compilation time
>>> >>>>> blows up by inlining everything since no profiling information is
>>> >>>> available
>>> >>>>> yet. I guess modules and knowing dependencies can help here to
>>> >> reduce
>>> >>>> this.
>>> >>>>> Besides test running to generate profiling data.
>>> >>>>>
>>> >>>>> Regards, Jeroen
>>> >>>>> Bijlagen
>>> >>>>> Voorbeeld van YouTube-video JVMLS 2015 - Java Goes AOT weergeven
>>> >>>>> JVMLS 2015 - Java Goes AOT
>>> >>>>> Vitaly Davidovich
>>> >>>>> 13:09 (10 uur geleden)
>>> >>>>> aan Jeroen, jigsaw-dev
>>> >>>>>
>>> >>>>> Yes, I had seen Chris' presentation as well.  Certainly
>>> >> modularization
>>> >>>> will
>>> >>>>> help AOT in many ways.  But, I'm particularly interested on the JIT
>>> >> side.
>>> >>>>> What was meant by aggressive lambda inlining, for example? Can
>>> >> anyone
>>> >>>> point
>>> >>>>> at some additional info?
>>> >>>>>
>>> >>>>> Thanks
>>> >>>>>
>>> >>>>> sent from my phone
>>> >>>>> Paul Sandoz <paul.sandoz at oracle.com>
>>> >>>>> 13:32 (9 uur geleden)
>>> >>>>> aan jigsaw-dev
>>> >>>>> Hi Vitaly,
>>> >>>>>
>>> >>>>> Probably worth sending an email to the
>>> hotspot-dev at openjdk.java.net
>>> >>>> <mailto:
>>> >>>>> hotspot-dev at openjdk.java.net>
>>> >>>>>
>>> >>>>>> On 3 Nov 2015, at 13:09, Vitaly Davidovich <vitalyd at gmail.com>
>>> >> wrote:
>>> >>>>>>
>>> >>>>>> Yes, I had seen Chris' presentation as well.  Certainly
>>> >> modularization
>>> >>>>> will
>>> >>>>>> help AOT in many ways.  But, I'm particularly interested on the
>>> >> JIT
>>> >>>> side.
>>> >>>>>> What was meant by aggressive lambda inlining, for example? Can
>>> >> anyone
>>> >>>>> point
>>> >>>>>> at some additional info?
>>> >>>>>>
>>> >>>>>
>>> >>>>> I presume it in part might relate to cracking open the lambda ?box?
>>> >>>>> implementing the targeted functional interface to obtain the
>>> >> underlying
>>> >>>>> method containing the lambda body, generated by javac, that the box
>>> >>>> defers
>>> >>>>> to, then subsituting the indy call to an invocation of that
>>> >> underlying
>>> >>>>> method. Cue lots of hand waving?
>>> >>>>>
>>> >>>>> Maybe more clues in Oleg Pliss?s Closures on Embedded JVM
>>> >> presentation at
>>> >>>>> JVMLS 2014:
>>> >>>>>
>>> >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf
>>> <
>>> >>>>> http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf>
>>> >>>>> --------
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>>
>>> >>>>> Jeroen
>>> >>>>>
>>> >>>>> 2015-11-03 23:21 GMT+01:00 Jeroen Borgers <jborgers at jpinpoint.com
>>> >:
>>> >>>>>
>>> >>>>>> Hi,
>>> >>>>>>
>>> >>>>>> One of the goals of Jigsaw that intrigue me, I read here:
>>> >>>> http://openjdk.
>>> >>>>>> java
>>> >>>>>>
>>> >>>>
>>> >>
>>> .net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques
>>> >>>>>> is:
>>> >>>>>> *Enable ahead-of-time, whole-program optimization techniques*  -
>>> >>>>>> [..]
>>> >>>>>> The optimization techniques envisioned here include, but are not
>>> >> limited
>>> >>>>>> to: Fast lookup of both JDK and application classes; early
>>> >> bytecode
>>> >>>>>> verification; aggressive inlining of, *e.g.*, lambda expressions,
>>> >> and
>>> >>>>>> other standard compiler optimizations; construction of
>>> >> JVM-specific
>>> >>>> memory
>>> >>>>>> images that can be loaded more efficiently than class files;
>>> >>>> ahead-of-time
>>> >>>>>> compilation of method bodies to native code; and the removal of
>>> >> unused
>>> >>>>>> fields, methods, and classes. These kinds of techniques tend to
>>> >> work
>>> >>>> best
>>> >>>>>> when JDK and application code is analyzed together, prior to run
>>> >> time.
>>> >>>>>> [..]
>>> >>>>>>
>>> >>>>>> -
>>> >>>>>>
>>> >>>>>> *Optimize existing code as-is* ? It must be possible to apply the
>>> >>>>>> optimizer tool to existing code already packaged in traditional
>>> >> jar
>>> >>>> files,
>>> >>>>>> without changing those files.
>>> >>>>>> -
>>> >>>>>>
>>> >>>>>> *Actual optimizations* ? As a proof of concept, provide at least
>>> >> two
>>> >>>>>> optimizations that deliver nontrivial performance benefits.
>>> >>>>>>
>>> >>>>>> I am curious about the following:
>>> >>>>>> * What is the current state of this? Which
>>> >> techniques/optimizations are
>>> >>>>>> already implemented and available from the current ea JDK9 or will
>>> >> be?
>>> >>>>>> * Are there any new insights/developments in this area?
>>> >>>>>> * I noticed in my JMH microbenchmark with parallel stream and
>>> >> lambda's
>>> >>>>>> that it runs slightly faster on 9_b85 compared to 8_u66. Could
>>> >> this be
>>> >>>>>> caused by more aggressive inlining of lambda's?
>>> >>>>>> * It seems to me that some compilation and optimization work is
>>> >> moved
>>> >>>> from
>>> >>>>>> runtime to link time /AOT time, yet, we don't have profiling
>>> >> information
>>> >>>>>> there, so this will be limited, right? Are there obvious cases
>>> >> which
>>> >>>> work
>>> >>>>>> well?
>>> >>>>>> * I don't really see why aggressive inlining and std optimizations
>>> >> can
>>> >>>> now
>>> >>>>>> be more effective. Because there will be less de-optimization
>>> >> events
>>> >>>> needed
>>> >>>>>> because of better predictability? Can in-lining now take place in
>>> >> two
>>> >>>> ways,
>>> >>>>>> between platform modules and application? Through interfaces?
>>> >>>>>>
>>> >>>>>> Thanks!
>>> >>>>>> Jeroen
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>
>>> >>>>
>>> >
>>>
>>>
>>
>

From dmitry.dmitriev at oracle.com  Sun Nov 15 21:38:04 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Mon, 16 Nov 2015 00:38:04 +0300
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5644D9EB.8070704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
Message-ID: <5648FB3C.70204@oracle.com>

Hi Gerard,

Several comments:
1) I beleive that David mean UINT_MAX, i.e. without "x", because it 
always 32-bit and can avoid overflow of resulting value. Thus, I think 
that upper range should be "max_juint".

2) Also, in revision 0 you correct using of ErrorLogTimeout to match 
definition by removing "60" from call to the "os::sleep" in 
src/share/vm/runtime/thread.cpp. Did something changed between rev0 and 
rev1?

3) Also, David suggested to wrap constants in multiplication in 
src/share/vm/runtime/thread.cpp into CONST64 to avoid possible 
overflows, i.e.:
os::sleep(this, ErrorLogTimeout * CONST64(1000), false);

Thanks,
Dmitry

On 12.11.2015 21:26, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating the feedback from David:
>
> - Use trivial range
>
>
> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>
>
> cheers
>
> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for 
>> the last new runtime flag.
>>
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>
>>
>> Thank you.


From david.holmes at oracle.com  Mon Nov 16 02:10:24 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Nov 2015 12:10:24 +1000
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <5645CA9E.4060205@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com>
Message-ID: <56493B10.6040207@oracle.com>

Hi Magnus,

On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
> On 2015-11-13 09:13, Erik Joelsson wrote:
>> Hello,
>>
>> make/bsd/makefiles/amd64.make:
>> make/bsd/makefiles/gcc.make:
>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
>> should be reversed to guarantee that NOOPT is the one used in case
>> BUILDARCH contains something that conflicts? The solaris file does it
>> this way.
> You know you wrote that code originally? ;-)
>
> Yeah, I agree, it's more reasonable. Updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02

I don't like this particular change as it is too generic. It gives the 
appearance of being apply to apply whatever the BUILDARCH specific 
optflags are, which makes no sense if the whole point here is to not 
optimize these files. If all this is intended to do is include -g then I 
think that should be done explicitly.

---

make/bsd/makefiles/saproc.make

! # Order src files alfabetically

That would be "alphabetically". But that list doesn't seem alphabetic 
anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and 
$(AGENTDIR) should come first. I really see no point in forcing such 
lists to be in alphabetic order.

make/linux/makefiles/saproc.make doesn't have the comment that was added 
for bsd.

----

make/solaris/makefiles/amd64.make

Similar issue with bsd amd64.make. Not sure what you are trying to 
achieve here - is it some kind of last option wins situation ?

---

make/windows/create_obj_files.sh

Harmless I guess but not sure about relevance of sort order here.

----

  src/share/vm/adlc/adlparse.cpp

So that's where that comes from! :)

---

src/share/vm/gc/g1/g1EvacStats.cpp

I don't see anything in the cpp files that uses anything from the atomic 
class ???


Thanks,
David


>
> /Magnus
>
>>
>> Otherwise looks good.
>>
>> /Erik
>>
>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>> In the new hotspot build project, we have made a few changes to the
>>> existing build. In preparation for the new build, I'd like to
>>> integrate these into mainline.
>>>
>>> These changes are:
>>> * When overriding optimization, do not lose current debug (-g)
>>> setting (!)
>>> * Make adlc actually quiet in quiet mode
>>> * Make g1EvacStats.cpp compile in all cases without precompiled headers
>>> * Sort saproc object files when linking (facilitates comparison to
>>> new build)
>>>
>>> Unless someone suggests otherwise, I intend to push this (using JPRT)
>>> to hs-rt.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>>>
>>>
>>> /Magnus
>>
>

From david.holmes at oracle.com  Mon Nov 16 03:29:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Nov 2015 13:29:25 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5648FB3C.70204@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com>
Message-ID: <56494D95.5040209@oracle.com>

On 16/11/2015 7:38 AM, Dmitry Dmitriev wrote:
> Hi Gerard,
>
> Several comments:
> 1) I beleive that David mean UINT_MAX, i.e. without "x", because it
> always 32-bit and can avoid overflow of resulting value. Thus, I think
> that upper range should be "max_juint".

<sigh> I missed the 'x' on the flag type. When I said UINT_MAX I was 
thinking the flag was a UINT. UINTX_MAX can lead to overflow as you 
pointed out much earlier - sorry.

> 2) Also, in revision 0 you correct using of ErrorLogTimeout to match
> definition by removing "60" from call to the "os::sleep" in
> src/share/vm/runtime/thread.cpp. Did something changed between rev0 and
> rev1?
>
> 3) Also, David suggested to wrap constants in multiplication in
> src/share/vm/runtime/thread.cpp into CONST64 to avoid possible
> overflows, i.e.:
> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);

I'm making a bit of a hash of this review - sorry.

I agree with Dmitry that the os::sleep call should be changed as above:

os::sleep(this, ErrorLogTimeout * CONST64(1000), false);

but as the sleep arg is a jlong we need to limit ErrorLogTimeout to 
(MAX_JLONG/1000) _but_ that's too big for uintx on 32-bit. Which means 
the true range is different on 32-bit versus 64-bit. So if I finally get 
this right we should have the range as:

range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))

Not sure we have MAX_JLONG defined as a constant. I don't agree with 
just selecting the 32-bit range as that again becomes an arbitrary 
constraint on 64-bit.

David
-----

> Thanks,
> Dmitry
>
> On 12.11.2015 21:26, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating the feedback from David:
>>
>> - Use trivial range
>>
>>
>> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>>
>>
>> cheers
>>
>> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this small fix for JEP-245, which implements range for
>>> the last new runtime flag.
>>>
>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>
>>>
>>> Thank you.
>

From erik.joelsson at oracle.com  Mon Nov 16 08:22:22 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 16 Nov 2015 09:22:22 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <56493B10.6040207@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
Message-ID: <5649923E.8010707@oracle.com>



On 2015-11-16 03:10, David Holmes wrote:
> Hi Magnus,
>
> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>> Hello,
>>>
>>> make/bsd/makefiles/amd64.make:
>>> make/bsd/makefiles/gcc.make:
>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
>>> should be reversed to guarantee that NOOPT is the one used in case
>>> BUILDARCH contains something that conflicts? The solaris file does it
>>> this way.
>> You know you wrote that code originally? ;-)
>>
>> Yeah, I agree, it's more reasonable. Updated webrev:
>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 
>>
>
> I don't like this particular change as it is too generic. It gives the 
> appearance of being apply to apply whatever the BUILDARCH specific 
> optflags are, which makes no sense if the whole point here is to not 
> optimize these files. If all this is intended to do is include -g then 
> I think that should be done explicitly.
>
The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume 
the intention was to have it added to all compilation command lines. 
However, the OPT_CFLAGS/<filename> variable overrides 
CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files 
where we explicitly change the optimization level. The patch intends to 
make sure -g is used on those files too.

A cleaner solution would be to not have -g be part of the OPT flags at 
all but its own set of DEBUG_CFLAGS.
> ---
>
> make/bsd/makefiles/saproc.make
>
> ! # Order src files alfabetically
>
> That would be "alphabetically". But that list doesn't seem alphabetic 
> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and 
> $(AGENTDIR) should come first. I really see no point in forcing such 
> lists to be in alphabetic order.
>
This is to make comparison of binaries between the old hotspot build and 
the new hotspot build easier. In build-infra, we $(sort ) the object 
files before linking to get a reproducible order. The linker output is 
affected by the order of the object files. By making sure the old and 
the new build sorts them the same way, we get cleaner comparisons and 
can more easily detect other types of differences through those 
comparisons. The sort order isn't strictly alphabetical, it's on byte 
order so upper case goes before lower case.

/Erik
> make/linux/makefiles/saproc.make doesn't have the comment that was 
> added for bsd.
>
> ----
>
> make/solaris/makefiles/amd64.make
>
> Similar issue with bsd amd64.make. Not sure what you are trying to 
> achieve here - is it some kind of last option wins situation ?
>
> ---
>
> make/windows/create_obj_files.sh
>
> Harmless I guess but not sure about relevance of sort order here.
>
> ----
>
>  src/share/vm/adlc/adlparse.cpp
>
> So that's where that comes from! :)
>
> ---
>
> src/share/vm/gc/g1/g1EvacStats.cpp
>
> I don't see anything in the cpp files that uses anything from the 
> atomic class ???
>
>
> Thanks,
> David
>
>
>>
>> /Magnus
>>
>>>
>>> Otherwise looks good.
>>>
>>> /Erik
>>>
>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>> In the new hotspot build project, we have made a few changes to the
>>>> existing build. In preparation for the new build, I'd like to
>>>> integrate these into mainline.
>>>>
>>>> These changes are:
>>>> * When overriding optimization, do not lose current debug (-g)
>>>> setting (!)
>>>> * Make adlc actually quiet in quiet mode
>>>> * Make g1EvacStats.cpp compile in all cases without precompiled 
>>>> headers
>>>> * Sort saproc object files when linking (facilitates comparison to
>>>> new build)
>>>>
>>>> Unless someone suggests otherwise, I intend to push this (using JPRT)
>>>> to hs-rt.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 
>>>>
>>>>
>>>>
>>>> /Magnus
>>>
>>


From martin.doerr at sap.com  Mon Nov 16 10:11:15 2015
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 16 Nov 2015 10:11:15 +0000
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15 floats in native call
In-Reply-To: <CAHQ51u4qPZTZ0xATvKSXt1sayEah5bUWv2yrqaYmpz19P2TfBg@mail.gmail.com>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
	<CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>
	<CAHQ51u4qPZTZ0xATvKSXt1sayEah5bUWv2yrqaYmpz19P2TfBg@mail.gmail.com>
Message-ID: <7C9B87B351A4BA4AA9EC95BB41811656722762AF@DEWDFEMB19C.global.corp.sap>

Hi Sasha,

the fix for the compiler looks good, too. The test passes in interpreted and compiled mode, now.
I'm ok with keeping the 3 cases separate.
However, I still wonder why you use _LITTLE_ENDIAN. We use VM_LITTLE_ENDIAN at all other places.

Thanks and best regards,
  Martin


-----Original Message-----
From: Alexander Smundak [mailto:asmundak at google.com] 
Sent: Samstag, 14. November 2015 01:18
To: Volker Simonis <volker.simonis at gmail.com>
Cc: Doerr, Martin <martin.doerr at sap.com>; HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15 floats in native call

Please find the updated patch at
http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.01

I have added the changes for the compiled case, and added comments.
I have kept AIX and Linux cases separate, though -- IMHO mixing them
would make the situation logically less clear.

Note that I wasn't able to run JDK9 with -Xcomp on the Power8 machine
I have (I am investigating the reason currently), so have I modified
the test case to invoke the JNI method sufficiently large number of
times for the JIT to kick in. I have also tested in on JDK8u40 we are
currently using where -Xcomp works.

On Fri, Nov 13, 2015 at 9:24 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Fri, Nov 13, 2015 at 3:57 PM, Doerr, Martin <martin.doerr at sap.com> wrote:
>> Hi Sasha,
>>
>> thank you very much for debugging the interpreter. The test passes as long as the method gets interpreted, now.
>> However, I didn't get the right result when running with -Xcomp.
>> I guess there's still something wrong with the native wrapper (generate_native_wrapper / float_move etc.) for PPC64LE.
>>
>> Btw. I think the defined(VM_LITTLE_ENDIAN) should be used. I'd simply change the code to
>> #if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
>>   __ stfs(floatSlot, 4, arg_c);
>> #else
>>   __ stfs(floatSlot, 0, arg_c);
>> #endif
>>
>
> That's good, but I'd add comment like:
>
> #if defined(LINUX) && !defined(VM_LITTLE_ENDIAN)
>   __ stfs(floatSlot, 4, arg_c);
> #else
>   // This handles Linux/little-endian and AIX which is big-endian but
> stores the floats in the
>   // most-significant bytes of a double while the Linux ABI places
> them in the least-significant bytes.
>   __ stfs(floatSlot, 0, arg_c);
> #endif
>
>> Best regards and thanks again,
>>   Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak
>> Sent: Freitag, 13. November 2015 00:37
>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15 floats in native call
>>
>> Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8139258.
>> I have tested in on Linux running on ppc64le.
>> I need a sponsor.
>>
>> http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.00
>>
>> Sasha

From david.holmes at oracle.com  Mon Nov 16 11:11:23 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Nov 2015 21:11:23 +1000
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <5649923E.8010707@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
	<5649923E.8010707@oracle.com>
Message-ID: <5649B9DB.2030507@oracle.com>

On 16/11/2015 6:22 PM, Erik Joelsson wrote:
>
>
> On 2015-11-16 03:10, David Holmes wrote:
>> Hi Magnus,
>>
>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> make/bsd/makefiles/amd64.make:
>>>> make/bsd/makefiles/gcc.make:
>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
>>>> should be reversed to guarantee that NOOPT is the one used in case
>>>> BUILDARCH contains something that conflicts? The solaris file does it
>>>> this way.
>>> You know you wrote that code originally? ;-)
>>>
>>> Yeah, I agree, it's more reasonable. Updated webrev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02
>>>
>>
>> I don't like this particular change as it is too generic. It gives the
>> appearance of being apply to apply whatever the BUILDARCH specific
>> optflags are, which makes no sense if the whole point here is to not
>> optimize these files. If all this is intended to do is include -g then
>> I think that should be done explicitly.
>>
> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume
> the intention was to have it added to all compilation command lines.
> However, the OPT_CFLAGS/<filename> variable overrides
> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files
> where we explicitly change the optimization level. The patch intends to
> make sure -g is used on those files too.

I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH 
means -g (why???), or that putting other things in that variable might 
break files that should not be optimized.

> A cleaner solution would be to not have -g be part of the OPT flags at
> all but its own set of DEBUG_CFLAGS.

I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway 
if all we are interested in is adding -g then I agree it should have its 
own variable.

>> ---
>>
>> make/bsd/makefiles/saproc.make
>>
>> ! # Order src files alfabetically
>>
>> That would be "alphabetically". But that list doesn't seem alphabetic
>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and
>> $(AGENTDIR) should come first. I really see no point in forcing such
>> lists to be in alphabetic order.
>>
> This is to make comparison of binaries between the old hotspot build and
> the new hotspot build easier. In build-infra, we $(sort ) the object
> files before linking to get a reproducible order. The linker output is
> affected by the order of the object files. By making sure the old and
> the new build sorts them the same way, we get cleaner comparisons and
> can more easily detect other types of differences through those
> comparisons. The sort order isn't strictly alphabetical, it's on byte
> order so upper case goes before lower case.

I saw the change for the ordered object files on Windows, but this 
simply orders source files in a list. Not sure how that has any affect 
on the linking ??

Cheers,
David

> /Erik
>> make/linux/makefiles/saproc.make doesn't have the comment that was
>> added for bsd.
>>
>> ----
>>
>> make/solaris/makefiles/amd64.make
>>
>> Similar issue with bsd amd64.make. Not sure what you are trying to
>> achieve here - is it some kind of last option wins situation ?
>>
>> ---
>>
>> make/windows/create_obj_files.sh
>>
>> Harmless I guess but not sure about relevance of sort order here.
>>
>> ----
>>
>>  src/share/vm/adlc/adlparse.cpp
>>
>> So that's where that comes from! :)
>>
>> ---
>>
>> src/share/vm/gc/g1/g1EvacStats.cpp
>>
>> I don't see anything in the cpp files that uses anything from the
>> atomic class ???
>>
>>
>> Thanks,
>> David
>>
>>
>>>
>>> /Magnus
>>>
>>>>
>>>> Otherwise looks good.
>>>>
>>>> /Erik
>>>>
>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>>> In the new hotspot build project, we have made a few changes to the
>>>>> existing build. In preparation for the new build, I'd like to
>>>>> integrate these into mainline.
>>>>>
>>>>> These changes are:
>>>>> * When overriding optimization, do not lose current debug (-g)
>>>>> setting (!)
>>>>> * Make adlc actually quiet in quiet mode
>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled
>>>>> headers
>>>>> * Sort saproc object files when linking (facilitates comparison to
>>>>> new build)
>>>>>
>>>>> Unless someone suggests otherwise, I intend to push this (using JPRT)
>>>>> to hs-rt.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>>> WebRev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>>>>>
>>>>>
>>>>>
>>>>> /Magnus
>>>>
>>>
>

From erik.joelsson at oracle.com  Mon Nov 16 12:14:48 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 16 Nov 2015 13:14:48 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <5649B9DB.2030507@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
	<5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com>
Message-ID: <5649C8B8.2000707@oracle.com>



On 2015-11-16 12:11, David Holmes wrote:
> On 16/11/2015 6:22 PM, Erik Joelsson wrote:
>>
>>
>> On 2015-11-16 03:10, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>>>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> make/bsd/makefiles/amd64.make:
>>>>> make/bsd/makefiles/gcc.make:
>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
>>>>> should be reversed to guarantee that NOOPT is the one used in case
>>>>> BUILDARCH contains something that conflicts? The solaris file does it
>>>>> this way.
>>>> You know you wrote that code originally? ;-)
>>>>
>>>> Yeah, I agree, it's more reasonable. Updated webrev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 
>>>>
>>>>
>>>
>>> I don't like this particular change as it is too generic. It gives the
>>> appearance of being apply to apply whatever the BUILDARCH specific
>>> optflags are, which makes no sense if the whole point here is to not
>>> optimize these files. If all this is intended to do is include -g then
>>> I think that should be done explicitly.
>>>
>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume
>> the intention was to have it added to all compilation command lines.
>> However, the OPT_CFLAGS/<filename> variable overrides
>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files
>> where we explicitly change the optimization level. The patch intends to
>> make sure -g is used on those files too.
>
> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH 
> means -g (why???), or that putting other things in that variable might 
> break files that should not be optimized.
>
>> A cleaner solution would be to not have -g be part of the OPT flags at
>> all but its own set of DEBUG_CFLAGS.
>
> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway 
> if all we are interested in is adding -g then I agree it should have 
> its own variable.
>
I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS 
and OPT_CFLAGS. These get picked depending on the debug level of the 
build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to 
CFLAGS.

I can't really see a better way of making sure the -g does not fall off 
for some files than what is proposed here. At least not without 
completely reworking the flags handling in the current hotspot 
makefiles, something I'm very uninterested in doing.
>>> ---
>>>
>>> make/bsd/makefiles/saproc.make
>>>
>>> ! # Order src files alfabetically
>>>
>>> That would be "alphabetically". But that list doesn't seem alphabetic
>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and
>>> $(AGENTDIR) should come first. I really see no point in forcing such
>>> lists to be in alphabetic order.
>>>
>> This is to make comparison of binaries between the old hotspot build and
>> the new hotspot build easier. In build-infra, we $(sort ) the object
>> files before linking to get a reproducible order. The linker output is
>> affected by the order of the object files. By making sure the old and
>> the new build sorts them the same way, we get cleaner comparisons and
>> can more easily detect other types of differences through those
>> comparisons. The sort order isn't strictly alphabetical, it's on byte
>> order so upper case goes before lower case.
>
> I saw the change for the ordered object files on Windows, but this 
> simply orders source files in a list. Not sure how that has any affect 
> on the linking ??
>
It has an effect on the linking because that list is used verbatim on 
the combined compile/link command line.

/Erik
> Cheers,
> David
>
>> /Erik
>>> make/linux/makefiles/saproc.make doesn't have the comment that was
>>> added for bsd.
>>>
>>> ----
>>>
>>> make/solaris/makefiles/amd64.make
>>>
>>> Similar issue with bsd amd64.make. Not sure what you are trying to
>>> achieve here - is it some kind of last option wins situation ?
>>>
>>> ---
>>>
>>> make/windows/create_obj_files.sh
>>>
>>> Harmless I guess but not sure about relevance of sort order here.
>>>
>>> ----
>>>
>>>  src/share/vm/adlc/adlparse.cpp
>>>
>>> So that's where that comes from! :)
>>>
>>> ---
>>>
>>> src/share/vm/gc/g1/g1EvacStats.cpp
>>>
>>> I don't see anything in the cpp files that uses anything from the
>>> atomic class ???
>>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> Otherwise looks good.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>>>> In the new hotspot build project, we have made a few changes to the
>>>>>> existing build. In preparation for the new build, I'd like to
>>>>>> integrate these into mainline.
>>>>>>
>>>>>> These changes are:
>>>>>> * When overriding optimization, do not lose current debug (-g)
>>>>>> setting (!)
>>>>>> * Make adlc actually quiet in quiet mode
>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled
>>>>>> headers
>>>>>> * Sort saproc object files when linking (facilitates comparison to
>>>>>> new build)
>>>>>>
>>>>>> Unless someone suggests otherwise, I intend to push this (using 
>>>>>> JPRT)
>>>>>> to hs-rt.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>>>> WebRev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>
>>>>
>>


From dmitry.dmitriev at oracle.com  Mon Nov 16 13:09:14 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Mon, 16 Nov 2015 16:09:14 +0300
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <5644D899.7040300@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com> <5644D899.7040300@oracle.com>
Message-ID: <5649D57A.1020006@oracle.com>

Hi Gerard,

Revision 3 looks good to me!

Thanks,
Dmitry

On 12.11.2015 21:21, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev3, incorporating the feedback from 
> Jiangli:
>
> - After considering the choices I decided to use MIN when calculating 
> the range's MAX values. This seems to be the most correct, however, 
> the SQE testing framework will need to have those flags disabled for 
> now. I filed issue JDK-8142874 to track an enhancement that would 
> allow Shared* (and all other flags that cause the VM to exit with code 
> other than 0) flags to be tested.
>
> http://cr.openjdk.java.net/~gziemski/8138983_rev3
>
>
> cheers
>
> On 11/10/2015 11:31 AM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev2, incorporating feedback from David:
>>
>> - Move the metaspace constants back into metaspace code
>> - Fix test framework that specifies jsa file to be used by the 
>> "-Xshare:dump" flag tests
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>>
>>
>> cheers
>>
>>
>> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>>> hi all,
>>>
>>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>>
>>> - Fix comments and indentation
>>> - Add "-XShare:dump" while testing Shared* flags
>>> - Temporarily disable testing of SharedMiscDataSize as with current 
>>> min default it exits the VM with code 2 (which is
>>> allowed by the JEP, but not the test framework). This issue is 
>>> tracked by JDK-8141650
>>>
>>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>>
>>>
>>>
>>> cheers
>>>
>>>
>>>
>>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>>
>>>> hi all,
>>>>
>>>> Please review this final fix for JEP-245
>>>>
>>>> We implement the remaining runtime flags in the Shared* family.
>>>>
>>>> Summary of changes:
>>>>
>>>> #1 core fix - we factor out the constants to be used in the ranges
>>>>
>>>> src/share/vm/classfile/compactHashtable.cpp
>>>> src/share/vm/memory/metaspace.cpp
>>>> src/share/vm/memory/metaspaceShared.hpp
>>>> src/share/vm/runtime/globals.hpp
>>>>
>>>>
>>>> #2 we increase default sizes of range and constraint tables to 
>>>> minimize mallocs
>>>>
>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>>
>>>>
>>>> #3 we fix a bug that I run into the OptionsValidation test 
>>>> framework while working
>>>>
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 
>>>>
>>>>
>>>>
>>>> #4 we add functionality to OptionsValidation test framework that we 
>>>> later use
>>>>
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 
>>>>
>>>>
>>>>
>>>> #5 we cleanup and extend the existing test to detect a case where 
>>>> we get out of range value
>>>>
>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>>
>>>>
>>>> The fix passes RBT 
>>>> "hotspot/test/:hotspot_all,testlist,noncolo.testlist 
>>>> --add-tonga-keyword quick? and JPRT ?hotspot"
>>>> tests
>>>>
>>>> References:
>>>>
>>>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>>
>>>>
>>>> hg_stat:
>>>>
>>>> src/share/vm/classfile/compactHashtable.cpp |    2 +-
>>>> src/share/vm/memory/metaspace.cpp |   30 --
>>>> src/share/vm/memory/metaspaceShared.hpp |   19 +-
>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp |    2 +-
>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp |    2 +-
>>>> src/share/vm/runtime/globals.hpp |   63 +++++-
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 
>>>> |    4 +-
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 
>>>> |   81 +++++++
>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java |  180 
>>>> +++++++++-------
>>>>   9 files changed, 242 insertions(+), 141 deletions(-)
>>>
>>


From gerard.ziemski at oracle.com  Mon Nov 16 15:59:52 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Mon, 16 Nov 2015 09:59:52 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <56494D95.5040209@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
Message-ID: <5649FD78.1020504@oracle.com>

Thank you David and Dmitry for reviews. Please see my response in-line:


>> 3) Also, David suggested to wrap constants in multiplication in
>> src/share/vm/runtime/thread.cpp into CONST64 to avoid possible
>> overflows, i.e.:
>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);

I must have missed something - where/when did David suggest doing this?


> I'm making a bit of a hash of this review - sorry.
>
> I agree with Dmitry that the os::sleep call should be changed as above:
>
> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>
> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to (MAX_JLONG/1000) _but_ that's too big for uintx on
> 32-bit. Which means the true range is different on 32-bit versus 64-bit. So if I finally get this right we should have
> the range as:
>
> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>
> Not sure we have MAX_JLONG defined as a constant. I don't agree with just selecting the 32-bit range as that again
> becomes an arbitrary constraint on 64-bit.

Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), them it would appear that the most straightforward 
solution is to change ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes on both 32 and 64 bit) and then we 
can have the range simply defined as:

range(0, max_jlong/1000)

And then we can have:

os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds

Do we agree?


cheers

From gerard.ziemski at oracle.com  Mon Nov 16 16:02:09 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Mon, 16 Nov 2015 10:02:09 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <5649D57A.1020006@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com> <5644D899.7040300@oracle.com>
	<5649D57A.1020006@oracle.com>
Message-ID: <5649FE01.7010209@oracle.com>

Thank you Dmitry!


On 11/16/2015 07:09 AM, Dmitry Dmitriev wrote:
> Hi Gerard,
>
> Revision 3 looks good to me!
>
> Thanks,
> Dmitry
>
> On 12.11.2015 21:21, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev3, incorporating the feedback from Jiangli:
>>
>> - After considering the choices I decided to use MIN when calculating the range's MAX values. This seems to be the
>> most correct, however, the SQE testing framework will need to have those flags disabled for now. I filed issue
>> JDK-8142874 to track an enhancement that would allow Shared* (and all other flags that cause the VM to exit with code
>> other than 0) flags to be tested.
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev3
>>
>>
>> cheers
>>
>> On 11/10/2015 11:31 AM, gerard ziemski wrote:
>>> hi all,
>>>
>>> I have updated the fix with rev2, incorporating feedback from David:
>>>
>>> - Move the metaspace constants back into metaspace code
>>> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
>>>
>>> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>>>
>>>
>>> cheers
>>>
>>>
>>> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>>>> hi all,
>>>>
>>>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>>>
>>>> - Fix comments and indentation
>>>> - Add "-XShare:dump" while testing Shared* flags
>>>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>>>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>>>>
>>>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>>>
>>>>
>>>>
>>>> cheers
>>>>
>>>>
>>>>
>>>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>>>
>>>>> hi all,
>>>>>
>>>>> Please review this final fix for JEP-245
>>>>>
>>>>> We implement the remaining runtime flags in the Shared* family.
>>>>>
>>>>> Summary of changes:
>>>>>
>>>>> #1 core fix - we factor out the constants to be used in the ranges
>>>>>
>>>>> src/share/vm/classfile/compactHashtable.cpp
>>>>> src/share/vm/memory/metaspace.cpp
>>>>> src/share/vm/memory/metaspaceShared.hpp
>>>>> src/share/vm/runtime/globals.hpp
>>>>>
>>>>>
>>>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>>>>
>>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>>>
>>>>>
>>>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>>>>
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>>>
>>>>>
>>>>> #4 we add functionality to OptionsValidation test framework that we later use
>>>>>
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>>>
>>>>>
>>>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>>>>
>>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>>>
>>>>>
>>>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>>>> tests
>>>>>
>>>>> References:
>>>>>
>>>>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>>>
>>>>>
>>>>> hg_stat:
>>>>>
>>>>> src/share/vm/classfile/compactHashtable.cpp |    2 +-
>>>>> src/share/vm/memory/metaspace.cpp |   30 --
>>>>> src/share/vm/memory/metaspaceShared.hpp |   19 +-
>>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp |    2 +-
>>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp |    2 +-
>>>>> src/share/vm/runtime/globals.hpp |   63 +++++-
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java |    4 +-
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java |  180 +++++++++-------
>>>>>   9 files changed, 242 insertions(+), 141 deletions(-)
>>>>
>>>
>
>

From dmitry.dmitriev at oracle.com  Mon Nov 16 17:23:43 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Mon, 16 Nov 2015 20:23:43 +0300
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5649FD78.1020504@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
	<5649FD78.1020504@oracle.com>
Message-ID: <564A111F.5080705@oracle.com>

Hi Gerard,

See my response in-line:

On 16.11.2015 18:59, gerard ziemski wrote:
> Thank you David and Dmitry for reviews. Please see my response in-line:
>
>
>>> 3) Also, David suggested to wrap constants in multiplication in
>>> src/share/vm/runtime/thread.cpp into CONST64 to avoid possible
>>> overflows, i.e.:
>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>
> I must have missed something - where/when did David suggest doing this?
Probably, you missed these e-mail's... I reply on David e-mail at 11 
November an he replied to me with this suggestion.
My e-mail: 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020603.html
David answer: 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-November/020605.html
>
>
>> I'm making a bit of a hash of this review - sorry.
>>
>> I agree with Dmitry that the os::sleep call should be changed as above:
>>
>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>>
>> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to 
>> (MAX_JLONG/1000) _but_ that's too big for uintx on
>> 32-bit. Which means the true range is different on 32-bit versus 
>> 64-bit. So if I finally get this right we should have
>> the range as:
>>
>> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>>
>> Not sure we have MAX_JLONG defined as a constant. I don't agree with 
>> just selecting the 32-bit range as that again
>> becomes an arbitrary constraint on 64-bit.
>
> Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), 
> them it would appear that the most straightforward solution is to 
> change ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes 
> on both 32 and 64 bit) and then we can have the range simply defined as:
>
> range(0, max_jlong/1000)
Yes, this seems as alternative aproach!
>
> And then we can have:
>
> os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds
>
> Do we agree?
>
>
> cheers

Thanks,
Dmitry

From asmundak at google.com  Mon Nov 16 17:50:16 2015
From: asmundak at google.com (Alexander Smundak)
Date: Mon, 16 Nov 2015 09:50:16 -0800
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15 floats in native call
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB41811656722762AF@DEWDFEMB19C.global.corp.sap>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
	<CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>
	<CAHQ51u4qPZTZ0xATvKSXt1sayEah5bUWv2yrqaYmpz19P2TfBg@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB41811656722762AF@DEWDFEMB19C.global.corp.sap>
Message-ID: <CAHQ51u5cpOkEnp6WASQPX-dhf=akAr6kry5gkPcLhApDP7EXkA@mail.gmail.com>

On Mon, Nov 16, 2015 at 2:11 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> However, I still wonder why you use _LITTLE_ENDIAN. We use VM_LITTLE_ENDIAN at all other places.
Right. Fixed that. Please take another look:
http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.02

From vladimir.x.ivanov at oracle.com  Mon Nov 16 18:17:02 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Nov 2015 21:17:02 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <E14B1D8A-93C4-4903-83EE-CAF0A04144BE@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
	<5643621E.9060206@oracle.com>
	<BBF03C9E-BDBA-4E8B-B0D4-12F68E802CBB@oracle.com>
	<E14B1D8A-93C4-4903-83EE-CAF0A04144BE@oracle.com>
Message-ID: <564A1D9E.3090207@oracle.com>

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04/

Changes related to bug fix:
  http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04.fix/

> The nmethod bucket links stay around for a while, but we hope they don't
> build up too badly.  Can you describe how the worst case scenario
> occurs?  (Lots of nmethod compilation inlining a CS, but then a large
> number of calls to nmethod::flush_dependencies during a safepoint.)
Worst case scenario is when all CallSiteContext buckets are marked stale 
(e.g. during GC when it is not safe to remove them), but CallSite 
remains alive and it is not inlined in any other nmethod. In that case, 
the context will never be cleaned up and native memory consumption will 
stay the same.

If a CallSite object becomes unreachable, dedicated sun.misc.Cleaner 
will wipe corresponding dependency context by calling 
MHN_clearCallSiteContext.

If CallSite is inlined in any nmethod (new bucket is added into the 
list), all stale entries from corresponding dependency context are 
removed.

> Suggestion:   Maybe put in counters to track track (a) total number of
> bucket links and (b) number of stale ones.  (Is there a family of
> counters like this that we can add to?  Something in NMT?  A debug-only
> counter pair would be helpful, but even better would be something that
> would be more routinely tracked and dumped.)
I added 4 jvmstat counters.

> What happens if we make a zillion nmethods using the same CS, and then
> they all go away at once during class unloading, so that the CS has
> *only* stale entries?  Who will clean up its bucket list?  When the GC
> frees the CS node from the managed heap, what will happen to the bucket
> list?will it be leaked onto the C heap?  Same question if the CS has one
> long-lived nmethod:  Will we hold onto the stale buckets?  If this turns
> out to be a problem (see counter suggestion above) maybe we need a
> sweeper task.  The nmethod sweeper might visit nmethods periodically and
> expunge their CS dependencies.
Doing some work in nmethod sweeper sounds interesting. The only drawback 
I see is that it has to do that while holding CodeCache lock.

> Another small point:  Are you sure Atomic::xchg_ptr does the job?  You
> don't check the return value, which is odd.  I think the code you wrote
> is the same as a store/release (volatile store).  Did you mean to use a
> CAS?  Or:
>    intptr_t w = Atomic::xchg_ptr(v, ...):
>    assert(((v ^ w) & ~_has_stale_entries_mask) == 0);
All parallel workers write the same value into the memory - first bucket 
address w/ _has_stale_entires bit set. What I wanted to achieve is 
guarantee that GC cleaners will see it. So, it is a StoreLoad barrier.

But on the second thought, I don't think it is necessary. Not much can 
be encapsulated into DependencyContext class. There should be external 
(w.r.t. dependency context) synchronization between removal tasks and 
cleaning tasks (cleaning starts after removal phase is over) to ensure 
cleaners don't see invalid state when some entry is dead (count == 0), 
but the context isn't marked as having stale entries. In this case, 
assertion in DependencyContext::expunge_stale_entries() fires.

Best regards,
Vladimir Ivanov

From martin.doerr at sap.com  Mon Nov 16 18:29:40 2015
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 16 Nov 2015 18:29:40 +0000
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15 floats in native call
In-Reply-To: <CAHQ51u5cpOkEnp6WASQPX-dhf=akAr6kry5gkPcLhApDP7EXkA@mail.gmail.com>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
	<CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>
	<CAHQ51u4qPZTZ0xATvKSXt1sayEah5bUWv2yrqaYmpz19P2TfBg@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB41811656722762AF@DEWDFEMB19C.global.corp.sap>
	<CAHQ51u5cpOkEnp6WASQPX-dhf=akAr6kry5gkPcLhApDP7EXkA@mail.gmail.com>
Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672276428@DEWDFEMB19C.global.corp.sap>

Thanks for the update. It's good.

-----Original Message-----
From: Alexander Smundak [mailto:asmundak at google.com] 
Sent: Montag, 16. November 2015 18:50
To: Doerr, Martin <martin.doerr at sap.com>
Cc: Volker Simonis <volker.simonis at gmail.com>; HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(M): 8139258: PPC64LE: argument passing problem when passing 15 floats in native call

On Mon, Nov 16, 2015 at 2:11 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> However, I still wonder why you use _LITTLE_ENDIAN. We use VM_LITTLE_ENDIAN at all other places.
Right. Fixed that. Please take another look:
http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.02

From john.r.rose at oracle.com  Mon Nov 16 20:24:46 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Nov 2015 12:24:46 -0800
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <564A1D9E.3090207@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
	<5643621E.9060206@oracle.com>
	<BBF03C9E-BDBA-4E8B-B0D4-12F68E802CBB@oracle.com>
	<E14B1D8A-93C4-4903-83EE-CAF0A04144BE@oracle.com>
	<564A1D9E.3090207@oracle.com>
Message-ID: <D4AF699B-9C4D-456E-86A4-C27D8EB3ECB3@oracle.com>

On Nov 16, 2015, at 10:17 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Updated version:
>  http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04/ <http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04/>
> 
> Changes related to bug fix:
> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04.fix/ <http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04.fix/>

Good answers.  Reviewed.  ? John

From david.holmes at oracle.com  Mon Nov 16 21:45:31 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Nov 2015 07:45:31 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5649FD78.1020504@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
	<5649FD78.1020504@oracle.com>
Message-ID: <564A4E7B.1000704@oracle.com>

On 17/11/2015 1:59 AM, gerard ziemski wrote:
> Thank you David and Dmitry for reviews. Please see my response in-line:
>
>
>>> 3) Also, David suggested to wrap constants in multiplication in
>>> src/share/vm/runtime/thread.cpp into CONST64 to avoid possible
>>> overflows, i.e.:
>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>
> I must have missed something - where/when did David suggest doing this?
>
>
>> I'm making a bit of a hash of this review - sorry.
>>
>> I agree with Dmitry that the os::sleep call should be changed as above:
>>
>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>>
>> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to
>> (MAX_JLONG/1000) _but_ that's too big for uintx on
>> 32-bit. Which means the true range is different on 32-bit versus
>> 64-bit. So if I finally get this right we should have
>> the range as:
>>
>> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>>
>> Not sure we have MAX_JLONG defined as a constant. I don't agree with
>> just selecting the 32-bit range as that again
>> becomes an arbitrary constraint on 64-bit.
>
> Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), them
> it would appear that the most straightforward solution is to change
> ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes on both 32
> and 64 bit) and then we can have the range simply defined as:
>
> range(0, max_jlong/1000)
 >
> And then we can have:
>
> os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds
>
> Do we agree?

Not quite. First if ErrorLogTimeout is 64-bit then we don't need to 
apply CONST64 to 1000 as integer promotion will take care of it. But we 
then pass an unsigned 64-bit value where a signed 64-bit value is 
expected and that will need a cast to avoid a conversion warning.

So perhaps ErrorLogTimeout should be int64_t instead - even though only 
positive values are valid?

Thanks,
David

>
> cheers

From gerard.ziemski at oracle.com  Mon Nov 16 22:34:36 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Mon, 16 Nov 2015 16:34:36 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564A4E7B.1000704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
	<5649FD78.1020504@oracle.com> <564A4E7B.1000704@oracle.com>
Message-ID: <564A59FC.4070200@oracle.com>



On 11/16/2015 03:45 PM, David Holmes wrote:
>>> I'm making a bit of a hash of this review - sorry.
>>>
>>> I agree with Dmitry that the os::sleep call should be changed as above:
>>>
>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>>>
>>> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to
>>> (MAX_JLONG/1000) _but_ that's too big for uintx on
>>> 32-bit. Which means the true range is different on 32-bit versus
>>> 64-bit. So if I finally get this right we should have
>>> the range as:
>>>
>>> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>>>
>>> Not sure we have MAX_JLONG defined as a constant. I don't agree with
>>> just selecting the 32-bit range as that again
>>> becomes an arbitrary constraint on 64-bit.
>>
>> Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), them
>> it would appear that the most straightforward solution is to change
>> ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes on both 32
>> and 64 bit) and then we can have the range simply defined as:
>>
>> range(0, max_jlong/1000)
>>
>> And then we can have:
>>
>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds
>>
>> Do we agree?
>
> Not quite. First if ErrorLogTimeout is 64-bit then we don't need to apply CONST64 to 1000 as integer promotion will take
> care of it. But we then pass an unsigned 64-bit value where a signed 64-bit value is expected and that will need a cast
> to avoid a conversion warning.
>
> So perhaps ErrorLogTimeout should be int64_t instead - even though only positive values are valid?

There is no int64_t allowed in the globals's macro definition - uint64_t seems like the best type we have available here 
for jlong.

So perhaps:

os::sleep(this, (jlong)ErrorLogTimeout * 1000, false); // in seconds

is the closest/best we can do?


cheers

From christian.thalinger at oracle.com  Mon Nov 16 22:41:45 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 16 Nov 2015 12:41:45 -1000
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <5645F9C6.2070802@oracle.com>
References: <5645F9C6.2070802@oracle.com>
Message-ID: <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>

[CC'ing core-libs-dev]

> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov <konstantin.shefov at oracle.com> wrote:
> 
> Hello
> 
> Please review an enhancement to add three new methods to sun.reflect.ConstantPool class.
> The following methods are suggested:
> 
> public String[] getNameAndTypeRefInfoAt(int index) - returns string representation of name and type from a NameAndType constant pool entry with the specified index
> 
> public String[] getInvokedynamicRefInfoAt(int index) - returns string representation of name and type from an InvokeDynamic constant pool entry with the specified index
> 
> public Tag getTagAt(int index) - returns a Tag enum instance of a constant pool entry with the specified index
> 
> These three methods could be used for testing API working with constant pool, e.g. JVMCI.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
> 
> Thanks
> -Konstantin


From david.holmes at oracle.com  Mon Nov 16 22:52:06 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Nov 2015 08:52:06 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564A59FC.4070200@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
	<5649FD78.1020504@oracle.com> <564A4E7B.1000704@oracle.com>
	<564A59FC.4070200@oracle.com>
Message-ID: <564A5E16.9030604@oracle.com>

On 17/11/2015 8:34 AM, gerard ziemski wrote:
>
>
> On 11/16/2015 03:45 PM, David Holmes wrote:
>>>> I'm making a bit of a hash of this review - sorry.
>>>>
>>>> I agree with Dmitry that the os::sleep call should be changed as above:
>>>>
>>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>>>>
>>>> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to
>>>> (MAX_JLONG/1000) _but_ that's too big for uintx on
>>>> 32-bit. Which means the true range is different on 32-bit versus
>>>> 64-bit. So if I finally get this right we should have
>>>> the range as:
>>>>
>>>> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>>>>
>>>> Not sure we have MAX_JLONG defined as a constant. I don't agree with
>>>> just selecting the 32-bit range as that again
>>>> becomes an arbitrary constraint on 64-bit.
>>>
>>> Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), them
>>> it would appear that the most straightforward solution is to change
>>> ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes on both 32
>>> and 64 bit) and then we can have the range simply defined as:
>>>
>>> range(0, max_jlong/1000)
>>>
>>> And then we can have:
>>>
>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds
>>>
>>> Do we agree?
>>
>> Not quite. First if ErrorLogTimeout is 64-bit then we don't need to
>> apply CONST64 to 1000 as integer promotion will take
>> care of it. But we then pass an unsigned 64-bit value where a signed
>> 64-bit value is expected and that will need a cast
>> to avoid a conversion warning.
>>
>> So perhaps ErrorLogTimeout should be int64_t instead - even though
>> only positive values are valid?
>
> There is no int64_t allowed in the globals's macro definition - uint64_t
> seems like the best type we have available here for jlong.
>
> So perhaps:
>
> os::sleep(this, (jlong)ErrorLogTimeout * 1000, false); // in seconds
>
> is the closest/best we can do?

So be it.

Thanks,
David

>
> cheers

From coleen.phillimore at oracle.com  Tue Nov 17 00:56:26 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Nov 2015 19:56:26 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <1447153203.3700.15.camel@redhat.com>
References: <563C036A.3050008@oracle.com>		
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>	
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
Message-ID: <564A7B3A.1070005@oracle.com>


After much discussion between Kim and I, I have a new change which 
doesn't include .inline.hpp into a .hpp file.  This also fixes the Zero 
build on my Ubuntu system.

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

Thanks,
Coleen

On 11/10/15 6:00 AM, Severin Gehwolf wrote:
> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>> FWIW, the below hunk seems to be all that's necessary in order to
>>> fix
>>> the --disable-precompiled-headers Zero build for me:
>>>
>>> diff --git a/src/share/vm/runtime/java.cpp
>>> b/src/share/vm/runtime/java.cpp
>>> --- a/src/share/vm/runtime/java.cpp
>>> +++ b/src/share/vm/runtime/java.cpp
>>> @@ -49,6 +49,7 @@
>>>    #include "runtime/arguments.hpp"
>>>    #include "runtime/biasedLocking.hpp"
>>>    #include "runtime/compilationPolicy.hpp"
>>> +#include "runtime/deoptimization.hpp"
>>>    #include "runtime/fprofiler.hpp"
>>>    #include "runtime/init.hpp"
>>>    #include "runtime/interfaceSupport.hpp"
>>>
>>> It does not seem the other change is required. Tested with
>>> fastdebug
>>> build of Zero with --disable-precompiled-headers that failed to
>>> build
>>> without and built fine with the fix.
>> I could check in just the deoptimization.hpp change and build only
>> fastdebug until the other bug is fixed.
> This sounds good to me.
>
>>> Coleen, do you have details about the failure which gets supposedly
>>> fixed by the other hunk?
>> The only thing I have is the g++ compilation failures without these
>> changes.  The one that was fixed by including allocation.inline.hpp
>> was:
>>
>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>> release'
>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>> ats.hpp:32:
>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>> delete(void*)'
>> collect2: error: ld returned 1 exit status
>>
>> Since the destructor is complaining about the missing delete
>> operator, I
>> assume this compiler has the sort of destructor that implicitly can
>> also
>> call delete.  I don't have any other information or ideas really why
>> this fails to compile.
> Thanks!
>
> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
> deoptimization.hpp change a Zero JVM builds fine here in all variants:
> release/fastdebug/slowdebug.
>
> $ gcc --version
> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Thanks,
> Severin


From david.holmes at oracle.com  Tue Nov 17 01:00:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Nov 2015 11:00:49 +1000
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <56422B85.9080000@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com>
Message-ID: <564A7C41.7020708@oracle.com>

Hi Fred,

On 11/11/2015 3:38 AM, frederic parain wrote:
> Hi David and Doug,
>
> Thank you for your feedback.
>
> I put some comments below.
>
> On 09/11/2015 08:12, David Holmes wrote:
>> Hi Doug,
>>
>> On 9/11/2015 9:31 AM, Doug Lea wrote:
>>> On 11/06/2015 02:23 AM, David Holmes wrote:
>>>
>>>> Before I look at the code, what is the status of the "Open Issues"
>>>> referenced in the JEP?
>>>>
>>>> Also the JDK changes need to be reviewed on core-libs-dev and in
>>>> particular must
>>>> be seen by the jsr166 maintainers (ie Doug Lea and Martin Buchholz)
>>>>
>>>
>>> Martin and I and others are aware of this work.
>>>
>>> As has been said by everyone initially looking at JEP 270, it is a
>>> disappointing effort. It requires that APIs/methods supporting
>>> try/finally-like constructions (especially locks) include new
>>> annotations to substantially reduce the likelihood of failing to
>>> perform the "finally" side actions to release resources (like a lock)
>>> upon StackOverflowError.
>>>
>>> Considering that no other readily implementable solution has
>>> been proposed during the many years that this issue has been discussed,
>>> a disappointing band-aid might not be so bad.
>>
>> If I put on some extra-strength rose-coloured glasses I think I can
>> almost read that as "something is better than nothing". ;-) As there are
>> no practical general solutions to the problem (which surely says
>> something fundamental about the language design!) an annotation-based
>> point solution seems the only way to make some progress.
>>
>> But note that it is not the finally part that need be at issue. If one
>> considers ReentrantLock.lock() (in NonfairSync):
>>
>>   210         final void lock() {
>>   211             if (compareAndSetState(0, 1))
>>   212                 setExclusiveOwnerThread(Thread.currentThread());
>>   213             else
>>   214                 acquire(1);
>>   215         }
>>
>> if we throw after #211 the lock is half-locked: state says it is locked,
>> but no owner set. So it can't be locked again, nor can it be unlocked.
>> We would have to determine actual stack usage for each call path to know
>> whether that is in fact possible
>>
>>> Assuming the hotspot mechanics are put into place, the main question
>>> is when to use the  @ReservedStackAccess annotation.
>>>
>>> The JEP singles out ReentrantLock. But there are also other locks
>>> provided in JDK (StampedLock, ReentrantReadWriteLock), as well
>>> as in other external packages, that should probably use this.
>>> Plus there are other lock/resource APIs, for example Semaphore,
>>> that are often used in try/finally constructions. And internal
>>> before/after bookkeeping inside Executors. Plus, many cases of
>>> try-with-resources constructions. Plus many transactional APIs.
>>>
>>> And so on. It would be a never-ending effort to effectively use
>>> @ReservedStackAccess.
>>
>> Which, to me, is just another way of saying that the general problem is
>> intractable. The annotation at least gives the mechanism for a point
>> solution as has been said. The pain point that drove this was the use of
>> ReentrantLock in ConcurrentHashMap, which in turn was used in class
>> loading. That particular pain point has been addressed by not using the
>> problematic class - something we surely do not want to promote as the
>> way to deal with this problem!
>>
>>> I don't know of a good way to address this. One possibility is
>>> for javac to automatically insert @ReservedStackAccess in any
>>> method with a try-finally that involves at least one call?
>>
>> I don't see how that would be at all viable as it brings back in the
>> sizing problem - or greatly exacerbates the sizing problem. Plus as
>> noted above the problem is not just with the finally part.
>
> Another issue is that writing a rule for javac that is not
> overpessimistic is also an intractable problem. The pattern
> "atomic operation followed by method invocation to complete
> status update" is too general to be the trigger of the annotation.
> 1) It would lead to an excessive number of methods being annotated,
> and by consequence an over-sizing of the reserved area.
> 2) Another condition to hit the bug is that the stack space of
> the callee method must be bigger than the caller method with
> the atomic operation. This information depends heavily on runtime
> information like HW, compilation policies (inlining) and execution
> profile (to know which methods are going to be compiled first).
> javac won't have access to these information to annotated methods.

Right - there is no way to know that the atomic operation followed by 
the call should really be a single atomic operation that we can't 
implement that way. Given many atomic operations have subsequent code 
actions, the pattern would degenerate to simply involve the atomic 
operation, and that wouldn't work well at all.

Further, it isn't always that pattern. Consider for example 
ReentrantReadWriteLock.sync.tryRelease():

             int nextc = getState() - releases;
             boolean free = exclusiveCount(nextc) == 0;
             if (free)
                 setExclusiveOwnerThread(null);
             setState(nextc);

here we clear the owner first, but then may fail to set the new state. 
Actually detecting where a stackoverflow can lead to inconsistent state 
requires detailed scrutiny of the code. I would like to be able to 
reason that setState requires no more stack than 
setExclusiveOwnerThread, but I can't do that simply by code inspection.

>> Perhaps we should simply start with j.u.c.locks as the initial candidate
>> sets of classes and work out from there. The idiomatic Lock usage:
>>
>> l.lock();
>> try {
>>   // ...
>> } finally {
>>    l.unlock();
>> }
>>
>> epitomizes the critical-finally-block scenario (though the lock()
>> problem is much more subtle). AQS is too low-level to flag any specific
>> function I think; and the other synchronizers perhaps too high-level,
>> with fewer idiomatic use-cases that obviously benefit from this.
>>
>> In that regard I don't agree with where Fred has currently placed the
>> annotation in ReentrantLock and AQS. The placements appear arbitrary at
>> first glance - though no doubt they are the result of a deep and careful
>> analysis. But it is far from obvious why the annotation is placed on
>> NonfairSync.lock but FairSync.tryAcquire(), for example.
>
> The annotation is used on methods with the problematic pattern
> "atomic operation followed by method invocation".
> Their execution could lead to data corruption if atomic operation
> is executed successfully but the following method invocation
> fails because of SOE.
>
> In the NonFairSync class, this pattern is in the lock() method,
> while the tryAcquire() is only a method invocation. So lock()
> is annotated and tryAcquire() is not. Note that the method
> invoked by try acquire is nonfairTryAcquire() which has the
> problematic pattern and is annotated.
>
> In the FairSync class, the situation is reversed: lock() is
> just an method invocation and it is not annotated, and
> tryAcquire() has the problematic pattern and is annotated.
>
> I tried to put the annotation as close as possible to the
> critical sections in order to minimize the size requirement
> for the reserved area.

Okay I now understand the rule you were applying. But it isn't obvious 
from the code. Further, there seem to be other places which could also 
suffer serious problems. In AQS doReleaseShared() we have:

  720                     if (!h.compareAndSetWaitStatus(Node.SIGNAL, 0))
  721                         continue;            // loop to recheck cases
  722                     unparkSuccessor(h);

which could seemingly throw SOE without unparking the successor.

Any compound action that logically forms a "transaction" would need to 
be immune to SOE.

>> I would be tempted to place them on all the public lock/unlock methods
>> of the Lock implementations, rather than on the internal AQS-derived
>> functions, and AQS itself.
>
> I've tried that :-) The amount of code being executed with
> the ReservedStackAccess privilege tends to increase very
> quickly and I was concerned about keeping the size of the
> reserved area small.

How much space does each level of calling need? I know that is hard to 
answer but are we talking a few bytes, few kb, many kb?

I'd be looking at expanding the current application of the annotation to 
cover all affected areas of AQS, AQLS, ReentrantLock and 
ReeentrantReadWriteLock. StampedLock is a bit more problematic - there 
it seems we do need to annotate the public API - but if we do it then 
j.u.c.locks is at least covered.

Thanks,
David

> Fred
>
>>>> On 6/11/2015 12:17 AM, Frederic Parain wrote:
>>>>> Please review the changesets for JEP 270: Reserved Stack Areas for
>>>>> Critical Sections
>>>>>
>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8046936
>>>>>
>>>>> Webrevs:
>>>>>    hotspot:
>>>>> http://cr.openjdk.java.net/~fparain/8046936/webrev.00/hotspot/
>>>>>    JDK: http://cr.openjdk.java.net/~fparain/8046936/webrev.00/jdk/
>>>>>
>>>>> The CR contains a detailed description of the issue and the design
>>>>> of the solution as well as implementation details.
>>>>>
>>>>> Tests:
>>>>>
>>>>>      JPRT - hotspot & core
>>>>>      RBT - vm.quick
>>>>>
>>>>> Thanks
>>>>>
>>>>> Fred
>>>>>
>>>>
>>>
>

From coleen.phillimore at oracle.com  Tue Nov 17 01:36:22 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Nov 2015 20:36:22 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A7B3A.1070005@oracle.com>
References: <563C036A.3050008@oracle.com>			<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>		<1447073484.3551.30.camel@redhat.com>
	<56411D2A.3030701@oracle.com>	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com>
Message-ID: <564A8496.4090605@oracle.com>


Sorry that was the wrong webrev:

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

Thanks,
Coleen

On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>
> After much discussion between Kim and I, I have a new change which 
> doesn't include .inline.hpp into a .hpp file.  This also fixes the 
> Zero build on my Ubuntu system.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>
> Thanks,
> Coleen
>
> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>> fix
>>>> the --disable-precompiled-headers Zero build for me:
>>>>
>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>> b/src/share/vm/runtime/java.cpp
>>>> --- a/src/share/vm/runtime/java.cpp
>>>> +++ b/src/share/vm/runtime/java.cpp
>>>> @@ -49,6 +49,7 @@
>>>>    #include "runtime/arguments.hpp"
>>>>    #include "runtime/biasedLocking.hpp"
>>>>    #include "runtime/compilationPolicy.hpp"
>>>> +#include "runtime/deoptimization.hpp"
>>>>    #include "runtime/fprofiler.hpp"
>>>>    #include "runtime/init.hpp"
>>>>    #include "runtime/interfaceSupport.hpp"
>>>>
>>>> It does not seem the other change is required. Tested with
>>>> fastdebug
>>>> build of Zero with --disable-precompiled-headers that failed to
>>>> build
>>>> without and built fine with the fix.
>>> I could check in just the deoptimization.hpp change and build only
>>> fastdebug until the other bug is fixed.
>> This sounds good to me.
>>
>>>> Coleen, do you have details about the failure which gets supposedly
>>>> fixed by the other hunk?
>>> The only thing I have is the g++ compilation failures without these
>>> changes.  The one that was fixed by including allocation.inline.hpp
>>> was:
>>>
>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>> release'
>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>> ats.hpp:32:
>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>> delete(void*)'
>>> collect2: error: ld returned 1 exit status
>>>
>>> Since the destructor is complaining about the missing delete
>>> operator, I
>>> assume this compiler has the sort of destructor that implicitly can
>>> also
>>> call delete.  I don't have any other information or ideas really why
>>> this fails to compile.
>> Thanks!
>>
>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>> release/fastdebug/slowdebug.
>>
>> $ gcc --version
>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There 
>> is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>> PURPOSE.
>>
>> Thanks,
>> Severin
>


From david.holmes at oracle.com  Tue Nov 17 01:57:17 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Nov 2015 11:57:17 +1000
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <5649C8B8.2000707@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
	<5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com>
	<5649C8B8.2000707@oracle.com>
Message-ID: <564A897D.7010707@oracle.com>

On 16/11/2015 10:14 PM, Erik Joelsson wrote:
> On 2015-11-16 12:11, David Holmes wrote:
>> On 16/11/2015 6:22 PM, Erik Joelsson wrote:
>>> On 2015-11-16 03:10, David Holmes wrote:
>>>> Hi Magnus,
>>>>
>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>>>>> Hello,
>>>>>>
>>>>>> make/bsd/makefiles/amd64.make:
>>>>>> make/bsd/makefiles/gcc.make:
>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
>>>>>> should be reversed to guarantee that NOOPT is the one used in case
>>>>>> BUILDARCH contains something that conflicts? The solaris file does it
>>>>>> this way.
>>>>> You know you wrote that code originally? ;-)
>>>>>
>>>>> Yeah, I agree, it's more reasonable. Updated webrev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02
>>>>>
>>>>>
>>>>
>>>> I don't like this particular change as it is too generic. It gives the
>>>> appearance of being apply to apply whatever the BUILDARCH specific
>>>> optflags are, which makes no sense if the whole point here is to not
>>>> optimize these files. If all this is intended to do is include -g then
>>>> I think that should be done explicitly.
>>>>
>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume
>>> the intention was to have it added to all compilation command lines.
>>> However, the OPT_CFLAGS/<filename> variable overrides
>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files
>>> where we explicitly change the optimization level. The patch intends to
>>> make sure -g is used on those files too.
>>
>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH
>> means -g (why???), or that putting other things in that variable might
>> break files that should not be optimized.
>>
>>> A cleaner solution would be to not have -g be part of the OPT flags at
>>> all but its own set of DEBUG_CFLAGS.
>>
>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway
>> if all we are interested in is adding -g then I agree it should have
>> its own variable.
>>
> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS
> and OPT_CFLAGS. These get picked depending on the debug level of the
> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to
> CFLAGS.
>
> I can't really see a better way of making sure the -g does not fall off
> for some files than what is proposed here. At least not without
> completely reworking the flags handling in the current hotspot
> makefiles, something I'm very uninterested in doing.

In the -g case what we are handling is the addition of -g to product 
builds (it is already on fastdebug, debug) when 
ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures. As 
a convenience we define it thus (BSD version):

OPT_CFLAGS/ia64 = -g
OPT_CFLAGS/amd64 = -g
OPT_CFLAGS/arm = -g
OPT_CFLAGS/ppc = -g
OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH))

so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy if 
the above were changed to:

FDS_CFLAGS/ia64 = -g
FDS_CFLAGS/amd64 = -g
FDS_CFLAGS/arm = -g
FDS_CFLAGS/ppc = -g
OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH))

and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file" 
definitions, where it would be much clearer what kind of flag is 
actually being applied. However this needs to be done everywhere, and I 
don't see this fix attempting to do that. We set OPT_CFLAGS/<filename> 
in numerous places (open and closed) to regain control over the "opt" 
flags applied to that file. Sometimes we use predefined opt flags, like 
NOOPT or SPEED, and sometimes we don't eg:

linux/makefiles/amd64.make

OPT_CFLAGS/compactingPermGenGen.o = -O1

This would need to be applied to every occurrence of the "byfile" 
definitions in all the makefiles. Or else ascertained on a case-by-case 
basis that we don't want -g for a specific file.

Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set you 
still have to somehow handle the rest of the above logic:

  507     ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
  508       ifeq ($(USE_CLANG), true)
  509         # Clang doesn't understand -gstabs
  510         OPT_CFLAGS += -g
  511       else
  512         OPT_CFLAGS += -gstabs
  513       endif
  514     endif

else you again fail to set -g or -gstabs on the "by-file" definitions.

Also looking at the change in make/solaris/makefiles/amd64.make you have 
taken the file specific flags:

  OPT_CFLAGS/generateOptoStub.o = -xO2

and added the generic OPT_CFLAGS value:

OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2

which seems extremely dubious from a correctness perspective.

Thanks,
David
-----

>>>> ---
>>>>
>>>> make/bsd/makefiles/saproc.make
>>>>
>>>> ! # Order src files alfabetically
>>>>
>>>> That would be "alphabetically". But that list doesn't seem alphabetic
>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and
>>>> $(AGENTDIR) should come first. I really see no point in forcing such
>>>> lists to be in alphabetic order.
>>>>
>>> This is to make comparison of binaries between the old hotspot build and
>>> the new hotspot build easier. In build-infra, we $(sort ) the object
>>> files before linking to get a reproducible order. The linker output is
>>> affected by the order of the object files. By making sure the old and
>>> the new build sorts them the same way, we get cleaner comparisons and
>>> can more easily detect other types of differences through those
>>> comparisons. The sort order isn't strictly alphabetical, it's on byte
>>> order so upper case goes before lower case.
>>
>> I saw the change for the ordered object files on Windows, but this
>> simply orders source files in a list. Not sure how that has any affect
>> on the linking ??
>>
> It has an effect on the linking because that list is used verbatim on
> the combined compile/link command line.
>
> /Erik
>> Cheers,
>> David
>>
>>> /Erik
>>>> make/linux/makefiles/saproc.make doesn't have the comment that was
>>>> added for bsd.
>>>>
>>>> ----
>>>>
>>>> make/solaris/makefiles/amd64.make
>>>>
>>>> Similar issue with bsd amd64.make. Not sure what you are trying to
>>>> achieve here - is it some kind of last option wins situation ?
>>>>
>>>> ---
>>>>
>>>> make/windows/create_obj_files.sh
>>>>
>>>> Harmless I guess but not sure about relevance of sort order here.
>>>>
>>>> ----
>>>>
>>>>  src/share/vm/adlc/adlparse.cpp
>>>>
>>>> So that's where that comes from! :)
>>>>
>>>> ---
>>>>
>>>> src/share/vm/gc/g1/g1EvacStats.cpp
>>>>
>>>> I don't see anything in the cpp files that uses anything from the
>>>> atomic class ???
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> Otherwise looks good.
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>>>>> In the new hotspot build project, we have made a few changes to the
>>>>>>> existing build. In preparation for the new build, I'd like to
>>>>>>> integrate these into mainline.
>>>>>>>
>>>>>>> These changes are:
>>>>>>> * When overriding optimization, do not lose current debug (-g)
>>>>>>> setting (!)
>>>>>>> * Make adlc actually quiet in quiet mode
>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled
>>>>>>> headers
>>>>>>> * Sort saproc object files when linking (facilitates comparison to
>>>>>>> new build)
>>>>>>>
>>>>>>> Unless someone suggests otherwise, I intend to push this (using
>>>>>>> JPRT)
>>>>>>> to hs-rt.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>>>>> WebRev:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>
>>>>>
>>>
>

From david.holmes at oracle.com  Tue Nov 17 02:11:45 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Nov 2015 12:11:45 +1000
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A8496.4090605@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com>
Message-ID: <564A8CE1.6010405@oracle.com>

Hi Coleen,

On 17/11/2015 11:36 AM, Coleen Phillimore wrote:
>
> Sorry that was the wrong webrev:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
> bug link https://bugs.openjdk.java.net/browse/JDK-8141570

I may be missing something but in:

make/linux/makefiles/zeroshark.make

isn't the whole point of the original:

! # override this from the main file because some version of llvm do not 
like -Wundef
! WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-function 
-Wunused-value

to avoid using the value set in gcc.make:

WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function 
-Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual

because the latter included -Wundef. Your new code simply adds new 
warnings to the existing value of WARNING_FLAGS

David
-----


> Thanks,
> Coleen
>
> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>
>> After much discussion between Kim and I, I have a new change which
>> doesn't include .inline.hpp into a .hpp file.  This also fixes the
>> Zero build on my Ubuntu system.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>
>> Thanks,
>> Coleen
>>
>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>> fix
>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>
>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>> b/src/share/vm/runtime/java.cpp
>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>> @@ -49,6 +49,7 @@
>>>>>    #include "runtime/arguments.hpp"
>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>> +#include "runtime/deoptimization.hpp"
>>>>>    #include "runtime/fprofiler.hpp"
>>>>>    #include "runtime/init.hpp"
>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>
>>>>> It does not seem the other change is required. Tested with
>>>>> fastdebug
>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>> build
>>>>> without and built fine with the fix.
>>>> I could check in just the deoptimization.hpp change and build only
>>>> fastdebug until the other bug is fixed.
>>> This sounds good to me.
>>>
>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>> fixed by the other hunk?
>>>> The only thing I have is the g++ compilation failures without these
>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>> was:
>>>>
>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>> release'
>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>> ats.hpp:32:
>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>> delete(void*)'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> Since the destructor is complaining about the missing delete
>>>> operator, I
>>>> assume this compiler has the sort of destructor that implicitly can
>>>> also
>>>> call delete.  I don't have any other information or ideas really why
>>>> this fails to compile.
>>> Thanks!
>>>
>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>> release/fastdebug/slowdebug.
>>>
>>> $ gcc --version
>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There
>>> is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
>>> Thanks,
>>> Severin
>>
>

From coleen.phillimore at oracle.com  Tue Nov 17 02:47:04 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Nov 2015 21:47:04 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A8CE1.6010405@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com>
Message-ID: <564A9528.80106@oracle.com>



On 11/16/15 9:11 PM, David Holmes wrote:
> Hi Coleen,
>
> On 17/11/2015 11:36 AM, Coleen Phillimore wrote:
>>
>> Sorry that was the wrong webrev:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>
> I may be missing something but in:
>
> make/linux/makefiles/zeroshark.make
>
> isn't the whole point of the original:
>
> ! # override this from the main file because some version of llvm do 
> not like -Wundef
> ! WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-function 
> -Wunused-value
>
> to avoid using the value set in gcc.make:
>
> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef 
> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type 
> -Woverloaded-virtual
>
> because the latter included -Wundef. Your new code simply adds new 
> warnings to the existing value of WARNING_FLAGS

I don't think the code wants to ignore the warning flags passed in from 
gcc.make.  I think -Wformat=2 was the one that caused my build to fail 
(or maybe others).   For zero we just want to add more warning flags or 
disable them after the gcc flags.   Kim might be able to provide more 
detail because he found this.  In general I don't see why Zero would 
ever want to ignore the warnings we enable/disable for the rest of the jvm.

Coleen


>
> David
> -----
>
>
>> Thanks,
>> Coleen
>>
>> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>>
>>> After much discussion between Kim and I, I have a new change which
>>> doesn't include .inline.hpp into a .hpp file.  This also fixes the
>>> Zero build on my Ubuntu system.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>>> fix
>>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>>
>>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>>> b/src/share/vm/runtime/java.cpp
>>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>>> @@ -49,6 +49,7 @@
>>>>>>    #include "runtime/arguments.hpp"
>>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>>> +#include "runtime/deoptimization.hpp"
>>>>>>    #include "runtime/fprofiler.hpp"
>>>>>>    #include "runtime/init.hpp"
>>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>>
>>>>>> It does not seem the other change is required. Tested with
>>>>>> fastdebug
>>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>>> build
>>>>>> without and built fine with the fix.
>>>>> I could check in just the deoptimization.hpp change and build only
>>>>> fastdebug until the other bug is fixed.
>>>> This sounds good to me.
>>>>
>>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>>> fixed by the other hunk?
>>>>> The only thing I have is the g++ compilation failures without these
>>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>>> was:
>>>>>
>>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>>> release'
>>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>>> ats.hpp:32:
>>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>>> delete(void*)'
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>>> Since the destructor is complaining about the missing delete
>>>>> operator, I
>>>>> assume this compiler has the sort of destructor that implicitly can
>>>>> also
>>>>> call delete.  I don't have any other information or ideas really why
>>>>> this fails to compile.
>>>> Thanks!
>>>>
>>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>>> release/fastdebug/slowdebug.
>>>>
>>>> $ gcc --version
>>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>> This is free software; see the source for copying conditions. There
>>>> is NO
>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>>> PURPOSE.
>>>>
>>>> Thanks,
>>>> Severin
>>>
>>


From david.holmes at oracle.com  Tue Nov 17 03:02:13 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Nov 2015 13:02:13 +1000
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A9528.80106@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com> <564A8CE1.6010405@oracle.com>
	<564A9528.80106@oracle.com>
Message-ID: <564A98B5.8030600@oracle.com>

On 17/11/2015 12:47 PM, Coleen Phillimore wrote:
>
>
> On 11/16/15 9:11 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> On 17/11/2015 11:36 AM, Coleen Phillimore wrote:
>>>
>>> Sorry that was the wrong webrev:
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>
>> I may be missing something but in:
>>
>> make/linux/makefiles/zeroshark.make
>>
>> isn't the whole point of the original:
>>
>> ! # override this from the main file because some version of llvm do
>> not like -Wundef
>> ! WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-function
>> -Wunused-value
>>
>> to avoid using the value set in gcc.make:
>>
>> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef
>> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type
>> -Woverloaded-virtual
>>
>> because the latter included -Wundef. Your new code simply adds new
>> warnings to the existing value of WARNING_FLAGS
>
> I don't think the code wants to ignore the warning flags passed in from
> gcc.make.  I think -Wformat=2 was the one that caused my build to fail
> (or maybe others).   For zero we just want to add more warning flags or
> disable them after the gcc flags.   Kim might be able to provide more
> detail because he found this.  In general I don't see why Zero would
> ever want to ignore the warnings we enable/disable for the rest of the jvm.

Presumably the -Wundef not working on some llvm is the reason :) And 
your changes now ensure -Wundef is set always.

David


> Coleen
>
>
>>
>> David
>> -----
>>
>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>>>
>>>> After much discussion between Kim and I, I have a new change which
>>>> doesn't include .inline.hpp into a .hpp file.  This also fixes the
>>>> Zero build on my Ubuntu system.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>>>> fix
>>>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>>>
>>>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>>>> b/src/share/vm/runtime/java.cpp
>>>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>>>> @@ -49,6 +49,7 @@
>>>>>>>    #include "runtime/arguments.hpp"
>>>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>>>> +#include "runtime/deoptimization.hpp"
>>>>>>>    #include "runtime/fprofiler.hpp"
>>>>>>>    #include "runtime/init.hpp"
>>>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>>>
>>>>>>> It does not seem the other change is required. Tested with
>>>>>>> fastdebug
>>>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>>>> build
>>>>>>> without and built fine with the fix.
>>>>>> I could check in just the deoptimization.hpp change and build only
>>>>>> fastdebug until the other bug is fixed.
>>>>> This sounds good to me.
>>>>>
>>>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>>>> fixed by the other hunk?
>>>>>> The only thing I have is the g++ compilation failures without these
>>>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>>>> was:
>>>>>>
>>>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>>>> release'
>>>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>>>> ats.hpp:32:
>>>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>>>> delete(void*)'
>>>>>> collect2: error: ld returned 1 exit status
>>>>>>
>>>>>> Since the destructor is complaining about the missing delete
>>>>>> operator, I
>>>>>> assume this compiler has the sort of destructor that implicitly can
>>>>>> also
>>>>>> call delete.  I don't have any other information or ideas really why
>>>>>> this fails to compile.
>>>>> Thanks!
>>>>>
>>>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>>>> release/fastdebug/slowdebug.
>>>>>
>>>>> $ gcc --version
>>>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>>> This is free software; see the source for copying conditions. There
>>>>> is NO
>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>>>> PURPOSE.
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>
>>>
>

From kim.barrett at oracle.com  Tue Nov 17 03:14:03 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 16 Nov 2015 22:14:03 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A9528.80106@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com> <564A9528.80106@oracle.com>
Message-ID: <FAD33CD6-DD9E-45E1-A65E-E0B3F1CACD25@oracle.com>

On Nov 16, 2015, at 9:47 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> On 11/16/15 9:11 PM, David Holmes wrote:
>> Hi Coleen,
>> 
>> On 17/11/2015 11:36 AM, Coleen Phillimore wrote:
>>> 
>>> Sorry that was the wrong webrev:
>>> 
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>> 
>> I may be missing something but in:
>> 
>> make/linux/makefiles/zeroshark.make
>> 
>> isn't the whole point of the original:
>> 
>> ! # override this from the main file because some version of llvm do not like -Wundef
>> ! WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-function -Wunused-value
>> 
>> to avoid using the value set in gcc.make:
>> 
>> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual
>> 
>> because the latter included -Wundef. Your new code simply adds new warnings to the existing value of WARNING_FLAGS
> 
> I don't think the code wants to ignore the warning flags passed in from gcc.make.  I think -Wformat=2 was the one that caused my build to fail (or maybe others).   For zero we just want to add more warning flags or disable them after the gcc flags.   Kim might be able to provide more detail because he found this.  In general I don't see why Zero would ever want to ignore the warnings we enable/disable for the rest of the jvm.

As Coleen said, it was me who suggested that change.

I took the comment at its word, that the purpose of the replacement
was (just) to avoid -Wundef.  The better way to accomplish that is to
append -Wno-undef later.  And make it conditional on clang/llvm, since
that's where the trouble seems to be.  (It would be better to limit
the version if possible, but I don't have the information to do so.)

Then we needed to *disable* some other warnings, because Hotspot
builds ignore the configuration option --disable-warnings-as-error
(JDK-8141543), and the zero-specific code trips some warnings that the
rest of the Hotspot code doesn't (anymore).

Just using the replacement doesn't work for building on Ubuntu 14.04,
which is what both Coleen and I were using.  I re-did the experiment,
and it looks like adding just the following

WARNING_FLAGS += -Wno-format-zero-length
WARNING_FLAGS += -Wno-format-security

to the origninal code that bashes the WARNING_FLAGS value will
successfully build on that platform.  I don't know if these would be
needed for Oracle Linux; I know Ubuntu configures their gcc with some
non-standard defaults.

But I agree with Coleen that it would be better if the zero-specific
code conformed to the same warning requirements as the rest of
Hotspot, with the proposed extra warning suppression being a temporary
measure until the zero community has addressed those issues.


From kim.barrett at oracle.com  Tue Nov 17 03:19:09 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 16 Nov 2015 22:19:09 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A98B5.8030600@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com> <564A9528.80106@oracle.com>
	<564A98B5.8030600@oracle.com>
Message-ID: <214BD4A0-7455-48D2-98C4-2F1C49A2F090@oracle.com>

On Nov 16, 2015, at 10:02 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Presumably the -Wundef not working on some llvm is the reason :) And your changes now ensure -Wundef is set always.

No, the changes ensure -Wundef is *not* set when using clang/llvm, by appending -Wno-undef to the end of the list, making use of gcc?s last value wins option processing behavior.


From coleen.phillimore at oracle.com  Tue Nov 17 03:23:43 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Nov 2015 22:23:43 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <FAD33CD6-DD9E-45E1-A65E-E0B3F1CACD25@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com> <564A9528.80106@oracle.com>
	<FAD33CD6-DD9E-45E1-A65E-E0B3F1CACD25@oracle.com>
Message-ID: <564A9DBF.5040804@oracle.com>



On 11/16/15 10:14 PM, Kim Barrett wrote:
> On Nov 16, 2015, at 9:47 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> On 11/16/15 9:11 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> On 17/11/2015 11:36 AM, Coleen Phillimore wrote:
>>>> Sorry that was the wrong webrev:
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>> I may be missing something but in:
>>>
>>> make/linux/makefiles/zeroshark.make
>>>
>>> isn't the whole point of the original:
>>>
>>> ! # override this from the main file because some version of llvm do not like -Wundef
>>> ! WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-function -Wunused-value
>>>
>>> to avoid using the value set in gcc.make:
>>>
>>> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual
>>>
>>> because the latter included -Wundef. Your new code simply adds new warnings to the existing value of WARNING_FLAGS
>> I don't think the code wants to ignore the warning flags passed in from gcc.make.  I think -Wformat=2 was the one that caused my build to fail (or maybe others).   For zero we just want to add more warning flags or disable them after the gcc flags.   Kim might be able to provide more detail because he found this.  In general I don't see why Zero would ever want to ignore the warnings we enable/disable for the rest of the jvm.
> As Coleen said, it was me who suggested that change.
>
> I took the comment at its word, that the purpose of the replacement
> was (just) to avoid -Wundef.  The better way to accomplish that is to
> append -Wno-undef later.  And make it conditional on clang/llvm, since
> that's where the trouble seems to be.  (It would be better to limit
> the version if possible, but I don't have the information to do so.)
>
> Then we needed to *disable* some other warnings, because Hotspot
> builds ignore the configuration option --disable-warnings-as-error
> (JDK-8141543), and the zero-specific code trips some warnings that the
> rest of the Hotspot code doesn't (anymore).
>
> Just using the replacement doesn't work for building on Ubuntu 14.04,
> which is what both Coleen and I were using.  I re-did the experiment,
> and it looks like adding just the following
>
> WARNING_FLAGS += -Wno-format-zero-length
> WARNING_FLAGS += -Wno-format-security
>
> to the origninal code that bashes the WARNING_FLAGS value will
> successfully build on that platform.  I don't know if these would be
> needed for Oracle Linux; I know Ubuntu configures their gcc with some
> non-standard defaults.
>
> But I agree with Coleen that it would be better if the zero-specific
> code conformed to the same warning requirements as the rest of
> Hotspot, with the proposed extra warning suppression being a temporary
> measure until the zero community has addressed those issues.
>

I was trying to find if -Wundef wasn't an option supported in CLANG but 
undef is a hard thing to google for.

The change came from this changeset:

changeset:   6090:81ccf2c854c7
user:        neugens
date:        Tue Mar 04 18:52:06 2014 -0800
summary:     8036619: Shark: add LLVM 3.4 support


But it could be that the Shark compiler based on LLVM had warnings with 
-Xundef ?  It's not that old of a change though.  I thought Shark hasn't 
compiled in years.

Coleen

From kim.barrett at oracle.com  Tue Nov 17 07:26:45 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Nov 2015 02:26:45 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A9DBF.5040804@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com> <564A9528.80106@oracle.com>
	<FAD33CD6-DD9E-45E1-A65E-E0B3F1CACD25@oracle.com>
	<564A9DBF.5040804@oracle.com>
Message-ID: <8A4609C7-8B46-4246-8C95-3EDA7C3F204D@oracle.com>

On Nov 16, 2015, at 10:23 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> I was trying to find if -Wundef wasn't an option supported in CLANG but undef is a hard thing to google for.

Oh, right, the problem might be that -W[no-]undef causes llvm to complain.

That is more difficult to deal with.  Not completely ideal, but something like

ifneq (,$(filter -Wundef, $(WARNING_FLAGS))
INCOMING_WARNING_FLAGS := $(WARNING_FLAGS)
WARNING_FLAGS = $(filter-out -Wundef, $(INCOMING_WARNING_FLAGS))
endif

Or alternatively, clobber WARNING_FLAGS as before only if using clang, and use the proposed new code if not, and let someone who cares about the combination of zero / linux / clang improve that part.


From goetz.lindenmaier at sap.com  Tue Nov 17 07:35:28 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 17 Nov 2015 07:35:28 +0000
Subject: RFR(M): 8139258: PPC64LE: argument passing problem when passing
	15 floats in native call
In-Reply-To: <CAHQ51u5cpOkEnp6WASQPX-dhf=akAr6kry5gkPcLhApDP7EXkA@mail.gmail.com>
References: <CAHQ51u7S5vGQQYHgW2XOty3wqfbrBqT5crbuzgJTacbXHC6G6g@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB4181165672276015@DEWDFEMB19C.global.corp.sap>
	<CA+3eh10_UOC4hOuvjXPvDJyNc5sWrGr2dEdLaEoaK2ZNqVmA1Q@mail.gmail.com>
	<CAHQ51u4qPZTZ0xATvKSXt1sayEah5bUWv2yrqaYmpz19P2TfBg@mail.gmail.com>
	<7C9B87B351A4BA4AA9EC95BB41811656722762AF@DEWDFEMB19C.global.corp.sap>
	<CAHQ51u5cpOkEnp6WASQPX-dhf=akAr6kry5gkPcLhApDP7EXkA@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41EB93C2@DEWDFEMB12A.global.corp.sap>

Hi Alexander, 

the change looks good, I'll sponsor it!
Thanks for fixing this.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Alexander Smundak
> Sent: Montag, 16. November 2015 18:50
> To: Doerr, Martin
> Cc: HotSpot Open Source Developers
> Subject: Re: RFR(M): 8139258: PPC64LE: argument passing problem when
> passing 15 floats in native call
> 
> On Mon, Nov 16, 2015 at 2:11 AM, Doerr, Martin <martin.doerr at sap.com>
> wrote:
> > However, I still wonder why you use _LITTLE_ENDIAN. We use
> VM_LITTLE_ENDIAN at all other places.
> Right. Fixed that. Please take another look:
> http://cr.openjdk.java.net/~asmundak/8139258/hotspot/webrev.02

From kim.barrett at oracle.com  Tue Nov 17 07:44:15 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Nov 2015 02:44:15 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <8A4609C7-8B46-4246-8C95-3EDA7C3F204D@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com> <564A9528.80106@oracle.com>
	<FAD33CD6-DD9E-45E1-A65E-E0B3F1CACD25@oracle.com>
	<564A9DBF.5040804@oracle.com>
	<8A4609C7-8B46-4246-8C95-3EDA7C3F204D@oracle.com>
Message-ID: <CE06F50A-B058-4863-A3AC-6ECCEF16E211@oracle.com>

On Nov 17, 2015, at 2:26 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> On Nov 16, 2015, at 10:23 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> 
>> I was trying to find if -Wundef wasn't an option supported in CLANG but undef is a hard thing to google for.
> 
> Oh, right, the problem might be that -W[no-]undef causes llvm to complain.

BTW, I couldn?t find any sign of such a problem in the llvm bug database.  Lots of quoted invocations with -Wundef, but nothing about that option causing problems.  I could have missed it in the noise though?



From erik.joelsson at oracle.com  Tue Nov 17 09:47:23 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 17 Nov 2015 10:47:23 +0100
Subject: RFR: JDK-8142336: Convert the SA agent build to modular
	build-infra makefiles
In-Reply-To: <5645BDD9.8070008@oracle.com>
References: <5640E6E2.6090906@oracle.com> <5641C95D.8040103@oracle.com>
	<5641F5D3.1000105@oracle.com> <56430AF1.2050109@oracle.com>
	<56437025.4070504@oracle.com> <5645BDD9.8070008@oracle.com>
Message-ID: <564AF7AB.8080509@oracle.com>

Hello,

I realized that there already was a mechanism for controlling the 
inclusion of SA from configure. Unfortunately, this variable is not 
picked up by any makefile currently. I changed the explicit checks for 
aix-ppc and zero to instead use the variable INCLUDE_SA which configure 
sets up based on at least these conditions.

I also removed another lingering special case instance of the 
jdk.hotspot.agent module in Main.gmk.

New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.03/

/Erik

On 2015-11-13 11:39, Erik Joelsson wrote:
> Widening the distribution in the hopes of finding another reviewer.
>
> I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make 
> locally. Merge tool error.
>
> /Erik
>
> On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
>> On 2015-11-11 10:31, Erik Joelsson wrote:
>>> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.02/
>>>
>>> Fixed the issues listed below. Reverted the faulty attempt at fixing 
>>> a warning. Did a more thorough attempt at clearing out all 
>>> references to SA in the old makefiles.
>>
>> Looks great. There was a few lines in 
>> hotspot/make/bsd/makefiles/defs.make where you seem to have 
>> accidentally broken the indentation. Apart from this it looks good. 
>> If you just restore the indentation I'm okay (you don't need to 
>> respin the webrev for that).
>>
>> /Magnus
>>
>>>
>>> /Erik
>>>
>>> On 2015-11-10 14:49, Magnus Ihse Bursie wrote:
>>>> On 2015-11-10 11:39, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-09 19:33, Erik Joelsson wrote:
>>>>>> Hello,
>>>>>>
>>>>>> As a stepping stone in the hotspot makefile conversion, I have 
>>>>>> broken out the serviceability agent separately and converted it 
>>>>>> into proper modular build-infra makefiles. Doing this conversion 
>>>>>> separately has some value on its own by reducing the special 
>>>>>> cases currently needed for building the jdk.hotspot.agent module.
>>>>>>
>>>>>> The current SA java build compiles with the boot jdk javac with 
>>>>>> -source/-target JDK N-1. The proposed change instead builds SA 
>>>>>> with the interim-langtools javac for JDK N, like all the rest of 
>>>>>> the JDK classes.
>>>>>>
>>>>>> There is already a bug filed for reorganizing the source of the 
>>>>>> SA agent to conform to the Jigsaw style modular source layout: 
>>>>>> JDK-8067194, so I have left the source in its current location.
>>>>>>
>>>>>> The native compilation and linking has been changed to base the 
>>>>>> flags used on what configure sets up for the other JDK libraries. 
>>>>>> This has caused some changes in flag usage. From what I can tell, 
>>>>>> nothing important is different however. I have run the relevant 
>>>>>> jtreg tests on all OSes to verify that it still works. Some of 
>>>>>> the differences include:
>>>>>>
>>>>>> * Linux: "-Xlinker z -Xlinker defs" was added to LDFLAGS, which 
>>>>>> causes link failure unless "-ldl" was also added to LIBS.
>>>>>> * Solaris: More warnings activated through "+w" caused need for 
>>>>>> disabling some warnings. I fixed one warning instance which was 
>>>>>> trivial (int->size_t), but couldn't figure out the rest. I will 
>>>>>> file a followup bug for fixing those if this patch is accepted.
>>>>>>
>>>>>> I tried to mimic the current behavior of excluding SA on 
>>>>>> linux-ppc and zero that Volker added a while back. Now it's 
>>>>>> excluded on the module level instead so that jdk.hotspot.agent 
>>>>>> isn't even built in that case. It would be good if this could be 
>>>>>> tested.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>>>>>
>>>>> A few remarks:
>>>>>
>>>>> * Could you please document the new DISABLED_WARNINGS_CXX and 
>>>>> DISABLED_WARNINGS_C in the function header?
>>>>>
>>>>> * I believe the use of {} here was to signify a set. When only 
>>>>> jsig remains, it just looks strange:
>>>>> -# SYMFLAG is used by {jsig,saproc}.make
>>>>> +# SYMFLAG is used by {jsig}.make
>>>>>
>>>>> * The logic of setting up "--hash-style=both" is already done in 
>>>>> configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if 
>>>>> you include the LDFLAGS_JDKLIB variable.
>>>>
>>>> Also, SA_WINDOWS_LDFLAGS is read but never defined.
>>>>
>>>> /Magnus
>>>
>>
>


From sgehwolf at redhat.com  Tue Nov 17 10:12:02 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 17 Nov 2015 11:12:02 +0100
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A8496.4090605@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com>
Message-ID: <1447755122.3778.5.camel@redhat.com>

Hi,

On Mon, 2015-11-16 at 20:36 -0500, Coleen Phillimore wrote:
> Sorry that was the wrong webrev:
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
> bug link https://bugs.openjdk.java.net/browse/JDK-8141570

Patch looks fine to me and builds Zero in all variants,
release/fastdebug/slowdebug, with precompiled headers disabled.

+1

Aside: I've added a todo item for taking a closer look at WARNING_FLAGS
for Zero. Hopefully, I'll get to look at it soon.

Thanks,
Severin

From dmitry.dmitriev at oracle.com  Tue Nov 17 12:10:20 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 17 Nov 2015 15:10:20 +0300
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564A59FC.4070200@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
	<5649FD78.1020504@oracle.com> <564A4E7B.1000704@oracle.com>
	<564A59FC.4070200@oracle.com>
Message-ID: <564B192C.7060600@oracle.com>

Hi Gerard,

On 17.11.2015 1:34, gerard ziemski wrote:
>
>
> On 11/16/2015 03:45 PM, David Holmes wrote:
>>>> I'm making a bit of a hash of this review - sorry.
>>>>
>>>> I agree with Dmitry that the os::sleep call should be changed as 
>>>> above:
>>>>
>>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>>>>
>>>> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to
>>>> (MAX_JLONG/1000) _but_ that's too big for uintx on
>>>> 32-bit. Which means the true range is different on 32-bit versus
>>>> 64-bit. So if I finally get this right we should have
>>>> the range as:
>>>>
>>>> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>>>>
>>>> Not sure we have MAX_JLONG defined as a constant. I don't agree with
>>>> just selecting the 32-bit range as that again
>>>> becomes an arbitrary constraint on 64-bit.
>>>
>>> Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), them
>>> it would appear that the most straightforward solution is to change
>>> ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes on 
>>> both 32
>>> and 64 bit) and then we can have the range simply defined as:
>>>
>>> range(0, max_jlong/1000)
>>>
>>> And then we can have:
>>>
>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds
>>>
>>> Do we agree?
>>
>> Not quite. First if ErrorLogTimeout is 64-bit then we don't need to 
>> apply CONST64 to 1000 as integer promotion will take
>> care of it. But we then pass an unsigned 64-bit value where a signed 
>> 64-bit value is expected and that will need a cast
>> to avoid a conversion warning.
>>
>> So perhaps ErrorLogTimeout should be int64_t instead - even though 
>> only positive values are valid?
>
> There is no int64_t allowed in the globals's macro definition - 
> uint64_t seems like the best type we have available here for jlong.
>
> So perhaps:
>
> os::sleep(this, (jlong)ErrorLogTimeout * 1000, false); // in seconds
>
> is the closest/best we can do?
Yes, looks good to me.
Should we convert upper range to uint64_t? I.e.: range(0, (uint64_t) 
max_jlong/1000)

Thanks,
Dmitry
>
>
> cheers


From vladimir.x.ivanov at oracle.com  Tue Nov 17 12:40:51 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 17 Nov 2015 15:40:51 +0300
Subject: [8u] RFR: 8058563: InstanceKlass::_dependencies list isn't
	cleared from empty nmethodBucket entries
In-Reply-To: <56445FDD.3040401@oracle.com>
References: <56445FDD.3040401@oracle.com>
Message-ID: <564B2053.4070501@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 11/12/15 12:46 PM, Stefan Karlsson wrote:
> Hi all,
>
> Please review this backport of 8058563 from JDK 9 to JDK 8u.
>
> JBS:
>   https://bugs.openjdk.java.net/browse/JDK-8058563
>
> JDK 8u patch:
>   http://cr.openjdk.java.net/~stefank/backports/8u/8058563/webrev.01/
>
> JDK 9 patch:
>   http://cr.openjdk.java.net/~stefank/8058563/webrev.01/
>
> The description of the fix can be found at:
>   http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-October/020253.html
>
> The nmethod code was refactored in JDK 9, which made it possible to
> easily write unit tests for theses changes. Since I don't want to do
> this refactoring for JDK 8u, the patch is slightly different and the
> unit tests are not included.
>
> Thanks,
> StefanK

From stefan.karlsson at oracle.com  Tue Nov 17 12:48:36 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Nov 2015 13:48:36 +0100
Subject: [8u] RFR: 8058563: InstanceKlass::_dependencies list isn't
	cleared from empty nmethodBucket entries
In-Reply-To: <564B2053.4070501@oracle.com>
References: <56445FDD.3040401@oracle.com> <564B2053.4070501@oracle.com>
Message-ID: <564B2224.2060204@oracle.com>

Thanks, Vladimir!

StefanK

On 2015-11-17 13:40, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 11/12/15 12:46 PM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this backport of 8058563 from JDK 9 to JDK 8u.
>>
>> JBS:
>>   https://bugs.openjdk.java.net/browse/JDK-8058563
>>
>> JDK 8u patch:
>> http://cr.openjdk.java.net/~stefank/backports/8u/8058563/webrev.01/
>>
>> JDK 9 patch:
>>   http://cr.openjdk.java.net/~stefank/8058563/webrev.01/
>>
>> The description of the fix can be found at:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-October/020253.html
>>
>> The nmethod code was refactored in JDK 9, which made it possible to
>> easily write unit tests for theses changes. Since I don't want to do
>> this refactoring for JDK 8u, the patch is slightly different and the
>> unit tests are not included.
>>
>> Thanks,
>> StefanK


From mikael.gerdin at oracle.com  Tue Nov 17 14:24:45 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 17 Nov 2015 15:24:45 +0100
Subject: [8u] RFR: 8058563: InstanceKlass::_dependencies list isn't
	cleared from empty nmethodBucket entries
In-Reply-To: <564B2224.2060204@oracle.com>
References: <56445FDD.3040401@oracle.com> <564B2053.4070501@oracle.com>
	<564B2224.2060204@oracle.com>
Message-ID: <564B38AD.8070306@oracle.com>

Stefan,

On 2015-11-17 13:48, Stefan Karlsson wrote:
> Thanks, Vladimir!

Looks good to me as well.
/Mikael
>
> StefanK
>
> On 2015-11-17 13:40, Vladimir Ivanov wrote:
>> Looks good.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 11/12/15 12:46 PM, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this backport of 8058563 from JDK 9 to JDK 8u.
>>>
>>> JBS:
>>>   https://bugs.openjdk.java.net/browse/JDK-8058563
>>>
>>> JDK 8u patch:
>>> http://cr.openjdk.java.net/~stefank/backports/8u/8058563/webrev.01/
>>>
>>> JDK 9 patch:
>>>   http://cr.openjdk.java.net/~stefank/8058563/webrev.01/
>>>
>>> The description of the fix can be found at:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-October/020253.html
>>>
>>>
>>> The nmethod code was refactored in JDK 9, which made it possible to
>>> easily write unit tests for theses changes. Since I don't want to do
>>> this refactoring for JDK 8u, the patch is slightly different and the
>>> unit tests are not included.
>>>
>>> Thanks,
>>> StefanK
>


From stefan.karlsson at oracle.com  Tue Nov 17 14:34:30 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Nov 2015 15:34:30 +0100
Subject: [8u] RFR: 8058563: InstanceKlass::_dependencies list isn't
	cleared from empty nmethodBucket entries
In-Reply-To: <564B38AD.8070306@oracle.com>
References: <56445FDD.3040401@oracle.com> <564B2053.4070501@oracle.com>
	<564B2224.2060204@oracle.com> <564B38AD.8070306@oracle.com>
Message-ID: <564B3AF6.20008@oracle.com>

On 2015-11-17 15:24, Mikael Gerdin wrote:
> Stefan,
>
> On 2015-11-17 13:48, Stefan Karlsson wrote:
>> Thanks, Vladimir!
>
> Looks good to me as well.

Thanks, Mikael.

StefanK

> /Mikael
>>
>> StefanK
>>
>> On 2015-11-17 13:40, Vladimir Ivanov wrote:
>>> Looks good.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 11/12/15 12:46 PM, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please review this backport of 8058563 from JDK 9 to JDK 8u.
>>>>
>>>> JBS:
>>>>   https://bugs.openjdk.java.net/browse/JDK-8058563
>>>>
>>>> JDK 8u patch:
>>>> http://cr.openjdk.java.net/~stefank/backports/8u/8058563/webrev.01/
>>>>
>>>> JDK 9 patch:
>>>>   http://cr.openjdk.java.net/~stefank/8058563/webrev.01/
>>>>
>>>> The description of the fix can be found at:
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-October/020253.html 
>>>>
>>>>
>>>>
>>>> The nmethod code was refactored in JDK 9, which made it possible to
>>>> easily write unit tests for theses changes. Since I don't want to do
>>>> this refactoring for JDK 8u, the patch is slightly different and the
>>>> unit tests are not included.
>>>>
>>>> Thanks,
>>>> StefanK
>>
>


From coleen.phillimore at oracle.com  Tue Nov 17 14:36:34 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Nov 2015 09:36:34 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <CE06F50A-B058-4863-A3AC-6ECCEF16E211@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564A8CE1.6010405@oracle.com> <564A9528.80106@oracle.com>
	<FAD33CD6-DD9E-45E1-A65E-E0B3F1CACD25@oracle.com>
	<564A9DBF.5040804@oracle.com>
	<8A4609C7-8B46-4246-8C95-3EDA7C3F204D@oracle.com>
	<CE06F50A-B058-4863-A3AC-6ECCEF16E211@oracle.com>
Message-ID: <564B3B72.6010909@oracle.com>



On 11/17/15 2:44 AM, Kim Barrett wrote:
> On Nov 17, 2015, at 2:26 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Nov 16, 2015, at 10:23 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> I was trying to find if -Wundef wasn't an option supported in CLANG but undef is a hard thing to google for.
>> Oh, right, the problem might be that -W[no-]undef causes llvm to complain.
> BTW, I couldn?t find any sign of such a problem in the llvm bug database.  Lots of quoted invocations with -Wundef, but nothing about that option causing problems.  I could have missed it in the noise though?

I think we should go ahead with the "right thing" and append the warning 
arguments and if the clang LLVM problem reappears for someone, they'll 
have the configuration to make and verify Kim's other fix in his n-1 email.

thanks,
Coleen

>
>


From gerard.ziemski at oracle.com  Tue Nov 17 15:34:51 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Tue, 17 Nov 2015 09:34:51 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564B192C.7060600@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<5648FB3C.70204@oracle.com> <56494D95.5040209@oracle.com>
	<5649FD78.1020504@oracle.com> <564A4E7B.1000704@oracle.com>
	<564A59FC.4070200@oracle.com> <564B192C.7060600@oracle.com>
Message-ID: <564B491B.80002@oracle.com>



On 11/17/2015 06:10 AM, Dmitry Dmitriev wrote:
> Hi Gerard,
>
> On 17.11.2015 1:34, gerard ziemski wrote:
>>
>>
>> On 11/16/2015 03:45 PM, David Holmes wrote:
>>>>> I'm making a bit of a hash of this review - sorry.
>>>>>
>>>>> I agree with Dmitry that the os::sleep call should be changed as above:
>>>>>
>>>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false);
>>>>>
>>>>> but as the sleep arg is a jlong we need to limit ErrorLogTimeout to
>>>>> (MAX_JLONG/1000) _but_ that's too big for uintx on
>>>>> 32-bit. Which means the true range is different on 32-bit versus
>>>>> 64-bit. So if I finally get this right we should have
>>>>> the range as:
>>>>>
>>>>> range(0, LP64_ONLY(MAX_JLONG/1000) NOT_LP64(UINTX_MAX))
>>>>>
>>>>> Not sure we have MAX_JLONG defined as a constant. I don't agree with
>>>>> just selecting the 32-bit range as that again
>>>>> becomes an arbitrary constraint on 64-bit.
>>>>
>>>> Since os:sleep() takes jlong (8 bytes long on both 32 and 64 bit), them
>>>> it would appear that the most straightforward solution is to change
>>>> ErrorLogTimeout type from "uintx" to "uint64_t" (also 8 bytes on both 32
>>>> and 64 bit) and then we can have the range simply defined as:
>>>>
>>>> range(0, max_jlong/1000)
>>>>
>>>> And then we can have:
>>>>
>>>> os::sleep(this, ErrorLogTimeout * CONST64(1000), false); // in seconds
>>>>
>>>> Do we agree?
>>>
>>> Not quite. First if ErrorLogTimeout is 64-bit then we don't need to apply CONST64 to 1000 as integer promotion will take
>>> care of it. But we then pass an unsigned 64-bit value where a signed 64-bit value is expected and that will need a cast
>>> to avoid a conversion warning.
>>>
>>> So perhaps ErrorLogTimeout should be int64_t instead - even though only positive values are valid?
>>
>> There is no int64_t allowed in the globals's macro definition - uint64_t seems like the best type we have available
>> here for jlong.
>>
>> So perhaps:
>>
>> os::sleep(this, (jlong)ErrorLogTimeout * 1000, false); // in seconds
>>
>> is the closest/best we can do?
> Yes, looks good to me.
> Should we convert upper range to uint64_t? I.e.: range(0, (uint64_t) max_jlong/1000)

Yes, I think we should in case compiler complains.

Thank you for the review.


cheers

From gerard.ziemski at oracle.com  Tue Nov 17 15:41:18 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Tue, 17 Nov 2015 09:41:18 -0600
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <5644D9EB.8070704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
Message-ID: <564B4A9E.5020704@oracle.com>

hi all,

I have updated the fix with rev2, incorporating feedback from David and Dimitry as per the discussion on this list:

- changed the type to uint64_t (the closest type we can use to 8byte long)
- max range is divided by 1000 to avoid overflow
- os:sleep() uses seconds as per flag's comments

http://cr.openjdk.java.net/~gziemski/8141641_rev2


cheers

On 11/12/2015 12:26 PM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev1, incorporating the feedback from David:
>
> - Use trivial range
>
>
> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>
>
> cheers
>
> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for the last new runtime flag.
>>
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>
>>
>> Thank you.
>

From dmitry.dmitriev at oracle.com  Tue Nov 17 17:21:57 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 17 Nov 2015 20:21:57 +0300
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564B4A9E.5020704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<564B4A9E.5020704@oracle.com>
Message-ID: <564B6235.7020105@oracle.com>

Hi Gerard,

Looks good to me!

Thanks,
Dmitry

On 17.11.2015 18:41, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev2, incorporating feedback from David 
> and Dimitry as per the discussion on this list:
>
> - changed the type to uint64_t (the closest type we can use to 8byte 
> long)
> - max range is divided by 1000 to avoid overflow
> - os:sleep() uses seconds as per flag's comments
>
> http://cr.openjdk.java.net/~gziemski/8141641_rev2
>
>
> cheers
>
> On 11/12/2015 12:26 PM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating the feedback from David:
>>
>> - Use trivial range
>>
>>
>> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>>
>>
>> cheers
>>
>> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this small fix for JEP-245, which implements range for 
>>> the last new runtime flag.
>>>
>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>
>>>
>>> Thank you.
>>


From kim.barrett at oracle.com  Tue Nov 17 19:18:56 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Nov 2015 14:18:56 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A8496.4090605@oracle.com>
References: <563C036A.3050008@oracle.com>			<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>		<1447073484.3551.30.camel@redhat.com>
	<56411D2A.3030701@oracle.com>	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
Message-ID: <DBC9802D-A97F-49D3-9C97-A3986CA0EA97@oracle.com>

On Nov 16, 2015, at 8:36 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> Sorry that was the wrong webrev:
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
> bug link https://bugs.openjdk.java.net/browse/JDK-8141570

Code changes look good.

Not surprisingly, I like the makefile changes, though after the discussion and Severin?s results I?d be
tempted to remove any special -Wundef handling for llvm and wait for someone with a complaint to
supply llvm version information.


From joel.borggren.franck at gmail.com  Tue Nov 17 18:59:21 2015
From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=)
Date: Tue, 17 Nov 2015 19:59:21 +0100
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
Message-ID: <CAFG0kMbQF3-Mx=qDoHyCb084vncpzE2zcL=WG8YGHzxqqRLk6Q@mail.gmail.com>

Looks good to me.

In an unmodularized world I would think twice before adding the
hotspot specific tags.

(I'm not a HotSpot Reviewer).

cheers
/Joel

On Mon, Nov 16, 2015 at 11:41 PM, Christian Thalinger
<christian.thalinger at oracle.com> wrote:
> [CC'ing core-libs-dev]
>
>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov <konstantin.shefov at oracle.com> wrote:
>>
>> Hello
>>
>> Please review an enhancement to add three new methods to sun.reflect.ConstantPool class.
>> The following methods are suggested:
>>
>> public String[] getNameAndTypeRefInfoAt(int index) - returns string representation of name and type from a NameAndType constant pool entry with the specified index
>>
>> public String[] getInvokedynamicRefInfoAt(int index) - returns string representation of name and type from an InvokeDynamic constant pool entry with the specified index
>>
>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant pool entry with the specified index
>>
>> These three methods could be used for testing API working with constant pool, e.g. JVMCI.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
>> Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
>>
>> Thanks
>> -Konstantin
>

From david.holmes at oracle.com  Tue Nov 17 20:09:59 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Nov 2015 06:09:59 +1000
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <214BD4A0-7455-48D2-98C4-2F1C49A2F090@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com> <564A8CE1.6010405@oracle.com>
	<564A9528.80106@oracle.com> <564A98B5.8030600@oracle.com>
	<214BD4A0-7455-48D2-98C4-2F1C49A2F090@oracle.com>
Message-ID: <564B8997.80906@oracle.com>

On 17/11/2015 1:19 PM, Kim Barrett wrote:
> On Nov 16, 2015, at 10:02 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Presumably the -Wundef not working on some llvm is the reason :) And your changes now ensure -Wundef is set always.
>
> No, the changes ensure -Wundef is *not* set when using clang/llvm, by appending -Wno-undef to the end of the list, making use of gcc?s last value wins option processing behavior.

Got it. Need new glasses :(

David


From forax at univ-mlv.fr  Tue Nov 17 21:04:00 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 17 Nov 2015 22:04:00 +0100 (CET)
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
Message-ID: <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>

Hi Konstantin,
Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef.

In term of API, I think it's better to decompose the API, i.e. to have a method
  int getInvokedynamicRefNameAndTypeIndex(int index)
that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. 

cheers,
R?mi

----- Mail original -----
> De: "Christian Thalinger" <christian.thalinger at oracle.com>
> ?: "Konstantin Shefov" <konstantin.shefov at oracle.com>
> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, core-libs-dev at openjdk.java.net
> Envoy?: Lundi 16 Novembre 2015 23:41:45
> Objet: Re: RFR [9] 8141615: Add new public methods to	sun.reflect.ConstantPool
> 
> [CC'ing core-libs-dev]
> 
> > On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
> > <konstantin.shefov at oracle.com> wrote:
> > 
> > Hello
> > 
> > Please review an enhancement to add three new methods to
> > sun.reflect.ConstantPool class.
> > The following methods are suggested:
> > 
> > public String[] getNameAndTypeRefInfoAt(int index) - returns string
> > representation of name and type from a NameAndType constant pool entry
> > with the specified index
> > 
> > public String[] getInvokedynamicRefInfoAt(int index) - returns string
> > representation of name and type from an InvokeDynamic constant pool entry
> > with the specified index
> > 
> > public Tag getTagAt(int index) - returns a Tag enum instance of a constant
> > pool entry with the specified index
> > 
> > These three methods could be used for testing API working with constant
> > pool, e.g. JVMCI.
> > 
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
> > Webrev hotspot:
> > http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
> > Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
> > 
> > Thanks
> > -Konstantin
> 
> 

From christian.thalinger at oracle.com  Wed Nov 18 00:25:25 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 17 Nov 2015 14:25:25 -1000
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
	<1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
Message-ID: <0FECE6CB-C56E-44B3-B8AA-DB1DCB8F06F5@oracle.com>

Kind of related but not really, I?ve filed a bug against ConstantPool to add JSR 292 ?support?:

JDK-8077229: sun.reflect.ConstantPool should support class and method constant pools
https://bugs.openjdk.java.net/browse/JDK-8077229 <https://bugs.openjdk.java.net/browse/JDK-8077229>

> On Nov 17, 2015, at 11:04 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Konstantin,
> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef.
> 
> In term of API, I think it's better to decompose the API, i.e. to have a method
>  int getInvokedynamicRefNameAndTypeIndex(int index)
> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings. 
> 
> cheers,
> R?mi
> 
> ----- Mail original -----
>> De: "Christian Thalinger" <christian.thalinger at oracle.com>
>> ?: "Konstantin Shefov" <konstantin.shefov at oracle.com>
>> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, core-libs-dev at openjdk.java.net
>> Envoy?: Lundi 16 Novembre 2015 23:41:45
>> Objet: Re: RFR [9] 8141615: Add new public methods to	sun.reflect.ConstantPool
>> 
>> [CC'ing core-libs-dev]
>> 
>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>>> <konstantin.shefov at oracle.com> wrote:
>>> 
>>> Hello
>>> 
>>> Please review an enhancement to add three new methods to
>>> sun.reflect.ConstantPool class.
>>> The following methods are suggested:
>>> 
>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string
>>> representation of name and type from a NameAndType constant pool entry
>>> with the specified index
>>> 
>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string
>>> representation of name and type from an InvokeDynamic constant pool entry
>>> with the specified index
>>> 
>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant
>>> pool entry with the specified index
>>> 
>>> These three methods could be used for testing API working with constant
>>> pool, e.g. JVMCI.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
>>> Webrev hotspot:
>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
>>> 
>>> Thanks
>>> -Konstantin
>> 
>> 


From asmundak at google.com  Wed Nov 18 01:14:33 2015
From: asmundak at google.com (Alexander Smundak)
Date: Tue, 17 Nov 2015 17:14:33 -0800
Subject: RFR(M): 8143180: PPC: Internal Error in
	src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
Message-ID: <CAHQ51u5mPQAgzicPd0oHAvBr0RbAQFmV6EOvQVT5=67AgUXZaw@mail.gmail.com>

Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8143180
I have tested it on PPC64LE.

http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.00

Sasha

From david.holmes at oracle.com  Wed Nov 18 08:02:54 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Nov 2015 18:02:54 +1000
Subject: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
In-Reply-To: <564B4A9E.5020704@oracle.com>
References: <8FE908F6-E9E9-4231-A7ED-346511C36F18@me.com>
	<564246BD.90203@oracle.com> <5644D9EB.8070704@oracle.com>
	<564B4A9E.5020704@oracle.com>
Message-ID: <564C30AE.107@oracle.com>

Ship it! :)

Thanks,
David

On 18/11/2015 1:41 AM, gerard ziemski wrote:
> hi all,
>
> I have updated the fix with rev2, incorporating feedback from David and
> Dimitry as per the discussion on this list:
>
> - changed the type to uint64_t (the closest type we can use to 8byte long)
> - max range is divided by 1000 to avoid overflow
> - os:sleep() uses seconds as per flag's comments
>
> http://cr.openjdk.java.net/~gziemski/8141641_rev2
>
>
> cheers
>
> On 11/12/2015 12:26 PM, gerard ziemski wrote:
>> hi all,
>>
>> I have updated the fix with rev1, incorporating the feedback from David:
>>
>> - Use trivial range
>>
>>
>> http://cr.openjdk.java.net/~gziemski/8141641_rev1
>>
>>
>> cheers
>>
>> On 11/10/2015 01:34 PM, gerard ziemski wrote:
>>>
>>> hi all,
>>>
>>> Please review this small fix for JEP-245, which implements range for
>>> the last new runtime flag.
>>>
>>>      bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>>   webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>
>>>
>>> Thank you.
>>

From goetz.lindenmaier at sap.com  Wed Nov 18 09:03:35 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 18 Nov 2015 09:03:35 +0000
Subject: RFR(M): 8143180: PPC: Internal Error in
	src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
In-Reply-To: <CAHQ51u5mPQAgzicPd0oHAvBr0RbAQFmV6EOvQVT5=67AgUXZaw@mail.gmail.com>
References: <CAHQ51u5mPQAgzicPd0oHAvBr0RbAQFmV6EOvQVT5=67AgUXZaw@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41EBA9C7@DEWDFEMB12A.global.corp.sap>

Hi Alexander, 

Did you fix the wrong line?
I think it needs to be 
 2965: __ li(R5, Deoptimization::Unpack_exception);

Could you also use R5_ARG3 as register?  

Thanks for spotting this,
  Goetz.



-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak
Sent: Wednesday, November 18, 2015 2:15 AM
To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: RFR(M): 8143180: PPC: Internal Error in src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287

Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8143180
I have tested it on PPC64LE.

http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.00

Sasha

From sgehwolf at redhat.com  Wed Nov 18 10:50:21 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 18 Nov 2015 11:50:21 +0100
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
Message-ID: <1447843821.3660.11.camel@redhat.com>

Hi,

I'd like to ask for approval of a Zero-specific hotspot 8 backport.
Currently, the jdk8u forest fails to build the Zero variant with GCC 5
due to this:

src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error: function returns address of local variable [-Werror=return-local-addr]
???return dummy;
??????????^
src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note: declared here
???address dummy = (address) &dummy;
???????????^
Note: Fedora 22+ have GCC 5. The above problem and the actual overflow
bug (if warning is ignored at build time + on relevant arch) goes away
when JDK-8087120 gets backported to 8u.

Original Bug:?https://bugs.openjdk.java.net/browse/JDK-8087120
9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/
9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018884.html

The 9 webrev applies with no change to the 8 forest. I'd need somebody
to sponsor this for me.

Thanks,
Severin

From konstantin.shefov at oracle.com  Wed Nov 18 11:11:00 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 18 Nov 2015 14:11:00 +0300
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
	<1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
Message-ID: <564C5CC4.5070003@oracle.com>

Remi,

Thanks for reviewing. Your suggestion sounds sensibly.
May be it also has sense to make a method 
"getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry 
index for methods also.

-Konstantin

On 11/18/2015 12:04 AM, Remi Forax wrote:
> Hi Konstantin,
> Technically, getInvokedynamicRefInfoAt should be getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType value of the InvokeDynamicRef.
>
> In term of API, I think it's better to decompose the API, i.e. to have a method
>    int getInvokedynamicRefNameAndTypeIndex(int index)
> that returns the nameAndType index and to reuse getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings.
>
> cheers,
> R?mi
>
> ----- Mail original -----
>> De: "Christian Thalinger" <christian.thalinger at oracle.com>
>> ?: "Konstantin Shefov" <konstantin.shefov at oracle.com>
>> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, core-libs-dev at openjdk.java.net
>> Envoy?: Lundi 16 Novembre 2015 23:41:45
>> Objet: Re: RFR [9] 8141615: Add new public methods to	sun.reflect.ConstantPool
>>
>> [CC'ing core-libs-dev]
>>
>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>>> <konstantin.shefov at oracle.com> wrote:
>>>
>>> Hello
>>>
>>> Please review an enhancement to add three new methods to
>>> sun.reflect.ConstantPool class.
>>> The following methods are suggested:
>>>
>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string
>>> representation of name and type from a NameAndType constant pool entry
>>> with the specified index
>>>
>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string
>>> representation of name and type from an InvokeDynamic constant pool entry
>>> with the specified index
>>>
>>> public Tag getTagAt(int index) - returns a Tag enum instance of a constant
>>> pool entry with the specified index
>>>
>>> These three methods could be used for testing API working with constant
>>> pool, e.g. JVMCI.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
>>> Webrev hotspot:
>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
>>>
>>> Thanks
>>> -Konstantin
>>


From erik.joelsson at oracle.com  Wed Nov 18 14:03:48 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 18 Nov 2015 15:03:48 +0100
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564A8496.4090605@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com>
Message-ID: <564C8544.40606@oracle.com>

Hello,

Build changes look ok, but I would recommend filing a followup bug for 
fixing the warnings that are being disabled so there is something 
tracking these issues in the zero source code.

/Erik

On 2015-11-17 02:36, Coleen Phillimore wrote:
>
> Sorry that was the wrong webrev:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>
> Thanks,
> Coleen
>
> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>
>> After much discussion between Kim and I, I have a new change which 
>> doesn't include .inline.hpp into a .hpp file.  This also fixes the 
>> Zero build on my Ubuntu system.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>
>> Thanks,
>> Coleen
>>
>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>> fix
>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>
>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>> b/src/share/vm/runtime/java.cpp
>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>> @@ -49,6 +49,7 @@
>>>>>    #include "runtime/arguments.hpp"
>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>> +#include "runtime/deoptimization.hpp"
>>>>>    #include "runtime/fprofiler.hpp"
>>>>>    #include "runtime/init.hpp"
>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>
>>>>> It does not seem the other change is required. Tested with
>>>>> fastdebug
>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>> build
>>>>> without and built fine with the fix.
>>>> I could check in just the deoptimization.hpp change and build only
>>>> fastdebug until the other bug is fixed.
>>> This sounds good to me.
>>>
>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>> fixed by the other hunk?
>>>> The only thing I have is the g++ compilation failures without these
>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>> was:
>>>>
>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>> release'
>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>> ats.hpp:32:
>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>> delete(void*)'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> Since the destructor is complaining about the missing delete
>>>> operator, I
>>>> assume this compiler has the sort of destructor that implicitly can
>>>> also
>>>> call delete.  I don't have any other information or ideas really why
>>>> this fails to compile.
>>> Thanks!
>>>
>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>> release/fastdebug/slowdebug.
>>>
>>> $ gcc --version
>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There 
>>> is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>>> PURPOSE.
>>>
>>> Thanks,
>>> Severin
>>
>


From coleen.phillimore at oracle.com  Wed Nov 18 16:26:49 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Nov 2015 11:26:49 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564C8544.40606@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564C8544.40606@oracle.com>
Message-ID: <564CA6C9.4020600@oracle.com>


Thank you, Erik.

I created bug https://bugs.openjdk.java.net/browse/JDK-8143245 (assigned 
to Severin).

Coleen

On 11/18/15 9:03 AM, Erik Joelsson wrote:
> Hello,
>
> Build changes look ok, but I would recommend filing a followup bug for 
> fixing the warnings that are being disabled so there is something 
> tracking these issues in the zero source code.
>
> /Erik
>
> On 2015-11-17 02:36, Coleen Phillimore wrote:
>>
>> Sorry that was the wrong webrev:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>
>> Thanks,
>> Coleen
>>
>> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>>
>>> After much discussion between Kim and I, I have a new change which 
>>> doesn't include .inline.hpp into a .hpp file.  This also fixes the 
>>> Zero build on my Ubuntu system.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>>> fix
>>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>>
>>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>>> b/src/share/vm/runtime/java.cpp
>>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>>> @@ -49,6 +49,7 @@
>>>>>>    #include "runtime/arguments.hpp"
>>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>>> +#include "runtime/deoptimization.hpp"
>>>>>>    #include "runtime/fprofiler.hpp"
>>>>>>    #include "runtime/init.hpp"
>>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>>
>>>>>> It does not seem the other change is required. Tested with
>>>>>> fastdebug
>>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>>> build
>>>>>> without and built fine with the fix.
>>>>> I could check in just the deoptimization.hpp change and build only
>>>>> fastdebug until the other bug is fixed.
>>>> This sounds good to me.
>>>>
>>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>>> fixed by the other hunk?
>>>>> The only thing I have is the g++ compilation failures without these
>>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>>> was:
>>>>>
>>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>>> release'
>>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>>> ats.hpp:32:
>>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>>> delete(void*)'
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>>> Since the destructor is complaining about the missing delete
>>>>> operator, I
>>>>> assume this compiler has the sort of destructor that implicitly can
>>>>> also
>>>>> call delete.  I don't have any other information or ideas really why
>>>>> this fails to compile.
>>>> Thanks!
>>>>
>>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>>> release/fastdebug/slowdebug.
>>>>
>>>> $ gcc --version
>>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>> This is free software; see the source for copying conditions. There 
>>>> is NO
>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>>>> PURPOSE.
>>>>
>>>> Thanks,
>>>> Severin
>>>
>>
>


From coleen.phillimore at oracle.com  Wed Nov 18 16:30:05 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Nov 2015 11:30:05 -0500
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564C8544.40606@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com>
	<564A7B3A.1070005@oracle.com> <564A8496.4090605@oracle.com>
	<564C8544.40606@oracle.com>
Message-ID: <564CA78D.8040801@oracle.com>


I also removed this line from zeroshark.make since this file has been 
gone for a long time.

OPT_CFLAGS/compactingPermGenGen.o = -O1

Thanks,
Coleen

On 11/18/15 9:03 AM, Erik Joelsson wrote:
> Hello,
>
> Build changes look ok, but I would recommend filing a followup bug for 
> fixing the warnings that are being disabled so there is something 
> tracking these issues in the zero source code.
>
> /Erik
>
> On 2015-11-17 02:36, Coleen Phillimore wrote:
>>
>> Sorry that was the wrong webrev:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>
>> Thanks,
>> Coleen
>>
>> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>>
>>> After much discussion between Kim and I, I have a new change which 
>>> doesn't include .inline.hpp into a .hpp file.  This also fixes the 
>>> Zero build on my Ubuntu system.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>>> fix
>>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>>
>>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>>> b/src/share/vm/runtime/java.cpp
>>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>>> @@ -49,6 +49,7 @@
>>>>>>    #include "runtime/arguments.hpp"
>>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>>> +#include "runtime/deoptimization.hpp"
>>>>>>    #include "runtime/fprofiler.hpp"
>>>>>>    #include "runtime/init.hpp"
>>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>>
>>>>>> It does not seem the other change is required. Tested with
>>>>>> fastdebug
>>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>>> build
>>>>>> without and built fine with the fix.
>>>>> I could check in just the deoptimization.hpp change and build only
>>>>> fastdebug until the other bug is fixed.
>>>> This sounds good to me.
>>>>
>>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>>> fixed by the other hunk?
>>>>> The only thing I have is the g++ compilation failures without these
>>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>>> was:
>>>>>
>>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>>> release'
>>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>>> ats.hpp:32:
>>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>>> delete(void*)'
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>>> Since the destructor is complaining about the missing delete
>>>>> operator, I
>>>>> assume this compiler has the sort of destructor that implicitly can
>>>>> also
>>>>> call delete.  I don't have any other information or ideas really why
>>>>> this fails to compile.
>>>> Thanks!
>>>>
>>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>>> release/fastdebug/slowdebug.
>>>>
>>>> $ gcc --version
>>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>> This is free software; see the source for copying conditions. There 
>>>> is NO
>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>>>> PURPOSE.
>>>>
>>>> Thanks,
>>>> Severin
>>>
>>
>


From erik.joelsson at oracle.com  Wed Nov 18 16:57:57 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 18 Nov 2015 17:57:57 +0100
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <564CA78D.8040801@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com> <564C8544.40606@oracle.com>
	<564CA78D.8040801@oracle.com>
Message-ID: <564CAE15.50706@oracle.com>

Seems fine to me.

/Erik

On 2015-11-18 17:30, Coleen Phillimore wrote:
>
> I also removed this line from zeroshark.make since this file has been 
> gone for a long time.
>
> OPT_CFLAGS/compactingPermGenGen.o = -O1
>
> Thanks,
> Coleen
>
> On 11/18/15 9:03 AM, Erik Joelsson wrote:
>> Hello,
>>
>> Build changes look ok, but I would recommend filing a followup bug 
>> for fixing the warnings that are being disabled so there is something 
>> tracking these issues in the zero source code.
>>
>> /Erik
>>
>> On 2015-11-17 02:36, Coleen Phillimore wrote:
>>>
>>> Sorry that was the wrong webrev:
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>>>
>>>> After much discussion between Kim and I, I have a new change which 
>>>> doesn't include .inline.hpp into a .hpp file.  This also fixes the 
>>>> Zero build on my Ubuntu system.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>>>> fix
>>>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>>>
>>>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>>>> b/src/share/vm/runtime/java.cpp
>>>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>>>> @@ -49,6 +49,7 @@
>>>>>>>    #include "runtime/arguments.hpp"
>>>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>>>> +#include "runtime/deoptimization.hpp"
>>>>>>>    #include "runtime/fprofiler.hpp"
>>>>>>>    #include "runtime/init.hpp"
>>>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>>>
>>>>>>> It does not seem the other change is required. Tested with
>>>>>>> fastdebug
>>>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>>>> build
>>>>>>> without and built fine with the fix.
>>>>>> I could check in just the deoptimization.hpp change and build only
>>>>>> fastdebug until the other bug is fixed.
>>>>> This sounds good to me.
>>>>>
>>>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>>>> fixed by the other hunk?
>>>>>> The only thing I have is the g++ compilation failures without these
>>>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>>>> was:
>>>>>>
>>>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>>>> release'
>>>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt 
>>>>>>
>>>>>> ats.hpp:32:
>>>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>>>> delete(void*)'
>>>>>> collect2: error: ld returned 1 exit status
>>>>>>
>>>>>> Since the destructor is complaining about the missing delete
>>>>>> operator, I
>>>>>> assume this compiler has the sort of destructor that implicitly can
>>>>>> also
>>>>>> call delete.  I don't have any other information or ideas really why
>>>>>> this fails to compile.
>>>>> Thanks!
>>>>>
>>>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>>>> deoptimization.hpp change a Zero JVM builds fine here in all 
>>>>> variants:
>>>>> release/fastdebug/slowdebug.
>>>>>
>>>>> $ gcc --version
>>>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>>> This is free software; see the source for copying conditions. 
>>>>> There is NO
>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>>>>> PURPOSE.
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>
>>>
>>
>


From sgehwolf at redhat.com  Wed Nov 18 17:06:26 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 18 Nov 2015 18:06:26 +0100
Subject: jmx-dev RFR 6425769: jmx remote bind address
In-Reply-To: <1447061525.3551.3.camel@redhat.com>
References: <1446460682.10865.20.camel@redhat.com>
	<56377F17.4050006@oracle.com> <5637871B.30705@oracle.com>
	<1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com>
	<1446634476.3554.8.camel@redhat.com>
	<1447061525.3551.3.camel@redhat.com>
Message-ID: <1447866386.3660.53.camel@redhat.com>

Hi,

Re-posting this for review since I've done another version which
duplicates some of the code in?SslRMIServerSocketFactory.java but does
not change API other than adding the new property. I personally don't
like it, but maybe this version is preferred?

Bug:?https://bugs.openjdk.java.net/browse/JDK-6425769
webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/

Thanks,
Severin

On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> > Hi,
> > 
> > Updated webrev with jtreg test in Java:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
> > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769
> > 
> > I believe this updated webrev addresses all concerns and
> > incorporates
> > suggestions brought up by Jaroslav and Daniel.
> > 
> > I'm still looking for a sponsor and a hotspot/servicability-dev
> > reviewer. Could somebody maintaining javax.rmi.ssl have a look at
> > this
> > as well? Thank you!
> 
> Ping? Friendly reminder that I still need reviewers and a sponsor for
> this.
> 
> Thanks,
> Severin
> 
> > Cheers,
> > Severin
> > 
> > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote:
> > > On 2.11.2015 19:06, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Thanks Jaroslav and Daniel for the reviews! Comments inline.
> > > > 
> > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> > > > > Hi,
> > > > > 
> > > > > On 2.11.2015 16:19, Daniel Fuchs wrote:
> > > > > > Hi Severin,
> > > > > > 
> > > > > > Adding serviceability-dev at openjdk.java.net into the loop -
> > > > > > that's
> > > > > > a better alias than hotspot-dev for this kind of changes -
> > > > > > maybe
> > > > > > someone from serviceability-dev will offer to sponsor :-)
> > > > > > 
> > > > > > I will let serviceability team members comment on the
> > > > > > hotspot
> > > > > > changes.
> > > > > > 
> > > > > > ConnectorBootstrap.java
> > > > > > 
> > > > > > I have one suggestion and one concern:
> > > > > > 
> > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket
> > > > > > Factory)
> > > > > > and
> > > > > > ssf??(Server Socket Factory) variables rather than
> > > > > > introduce
> > > > > > the
> > > > > > two
> > > > > > new variables rmiServerSocketFactory and
> > > > > > rmiClientSocketFactory.
> > > > > > You might want to create a new boolean 'useSocketFactory'
> > > > > > variable,
> > > > > > if that makes the code more readable.
> > > > > > 
> > > > > > Concern: If I understand correctly how RMI socket factories
> > > > > > work,
> > > > > > the client socket factory will be serialized and sent to
> > > > > > the
> > > > > > client
> > > > > > side. This is problematic for interoperability, as the
> > > > > > class
> > > > > > may
> > > > > > not
> > > > > > present in the remote client - if the remote client is e.g.
> > > > > > jdk
> > > > > > 8.
> > > > > > 
> > > > > > As far as I can see, your new DefaultClientSocketFactory
> > > > > > doesn't do
> > > > > > anything useful - so I would suggest to simply get rid of
> > > > > > it,
> > > > > > and
> > > > > > only
> > > > > > set the Server Socket Factory when SSL is not involved.
> > > > 
> > > > Thanks. Fixed in updated webrev.
> > > > 
> > > > > > Tests:
> > > > > > 
> > > > > > Concerning the tests - we're trying to get rid of shell
> > > > > > scripts
> > > > > > rather than introducing new ones :-)
> > > > > > Could the test be rewritten in pure java using the Process
> > > > > > API?
> > > > > > 
> > > > > > I believe there's even a test library that will let you do
> > > > > > that
> > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/
> > > > > > (see ProcessTools.java)
> > > > 
> > > > It'll take me a bit to rewrite the test in pure Java, but
> > > > should
> > > > be
> > > > fine. This is not yet fixed in the updated webrev.
> > > > 
> > > > > > Other:
> > > > > > 
> > > > > > Also - I believe the new option should be documented in:
> > > > > > src/java.management/share/conf/management.properties
> > > > 
> > > > Docs have been updated
> > > > in src/java.management/share/conf/management.properties.
> > > > 
> > > > > I share Daniel's concerns. Also, the part of the changeset is
> > > > > related
> > > > > to javax.rmi.ssl - someone maintaining this library should
> > > > > also
> > > > > comment here.
> > > > > 
> > > > > Also, the change is introducing new API (system property) and
> > > > > changing the existing one (adding SslRmiServerSocketFactory
> > > > > public
> > > > > constructors) so compatibility review process will have to be
> > > > > involved.
> > > > 
> > > > OK. What exactly is there for me to do? I'm not familiar with
> > > > this
> > > > process. Note that the intent would be to get this backported
> > > > to
> > > > JDK 8.
> > > Not much for you. But for the potential Oracle sponsor this means
> > > she
> > > will have to remember to go through some extra hoops before
> > > integrating your patch.
> > 
> > I see. Thanks for clarifying it.
> > 
> > > -JB-
> > > 
> > > > 
> > > > New webrev at:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > -JB-
> > > > > > 
> > > > > > best regards,
> > > > > > 
> > > > > > -- daniel
> > > > > > 
> > > > > > On 02/11/15 11:38, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Here is a patch addressing JDK-6425769. The issue is that
> > > > > > > the
> > > > > > > JMX
> > > > > > > agent
> > > > > > > binds to the wildcard address by default, preventing
> > > > > > > users
> > > > > > > to
> > > > > > > use
> > > > > > > system properties for JMX agents on multi-homed hosts.
> > > > > > > Given
> > > > > > > a
> > > > > > > host
> > > > > > > with local network interfaces, 192.168.0.1 and
> > > > > > > 192.168.0.2
> > > > > > > say,
> > > > > > > it's
> > > > > > > impossible to start two JMX agents binding to fixed ports
> > > > > > > but
> > > > > > > to
> > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and
> > > > > > > 192.168.0.2:{9111,9112} say.
> > > > > > > 
> > > > > > > The JDK would bind to all local interfaces by default. In
> > > > > > > the
> > > > > > > above
> > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is
> > > > > > > that
> > > > > > > the
> > > > > > > second
> > > > > > > Java process would get a "Connection refused" error
> > > > > > > because
> > > > > > > another
> > > > > > > process has already been bound to the specified JMX/RMI
> > > > > > > port
> > > > > > > pairs.
> > > > > > > 
> > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > > > > > > 64
> > > > > > > 25
> > > > > > > 769/
> > > > > > > 00/
> > > > > > > 
> > > > > > > Testing done:
> > > > > > > jdk_jmx and jdk_management tests all pass after this
> > > > > > > change
> > > > > > > (no
> > > > > > > regressions). There is also a new JTREG test which fails
> > > > > > > prior
> > > > > > > this
> > > > > > > change and passes after. Updates to the diagnostic
> > > > > > > command
> > > > > > > have
> > > > > > > been
> > > > > > > tested manually.
> > > > > > > 
> > > > > > > I understand that, if approved, the JDK and hotspot
> > > > > > > changes
> > > > > > > should get
> > > > > > > pushed together? Hotspot changes are fairly trivial since
> > > > > > > it's
> > > > > > > only a
> > > > > > > doc-update for the new JDK property in the relevant
> > > > > > > diagnostic
> > > > > > > command.
> > > > > > > 
> > > > > > > Could someone please review and sponsor this change?
> > > > > > > Please
> > > > > > > let
> > > > > > > me know
> > > > > > > if there are questions.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Severin
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From vladimir.x.ivanov at oracle.com  Wed Nov 18 17:32:43 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 18 Nov 2015 20:32:43 +0300
Subject: [9] RFR (M): 8139595: MethodHandles::remove_dependent_nmethod is
	not MT safe
In-Reply-To: <D4AF699B-9C4D-456E-86A4-C27D8EB3ECB3@oracle.com>
References: <5638FE82.4060801@oracle.com> <563B0CFA.8070508@oracle.com>
	<563B2658.4090505@oracle.com> <563B5F9E.6050606@oracle.com>
	<563B87E2.9010603@oracle.com> <563BA5D3.5060905@oracle.com>
	<563BD90F.7010609@oracle.com> <563CA533.601@oracle.com>
	<FD4C99CD-8474-48D3-ABBA-59F9BD9D1161@oracle.com>
	<5643621E.9060206@oracle.com>
	<BBF03C9E-BDBA-4E8B-B0D4-12F68E802CBB@oracle.com>
	<E14B1D8A-93C4-4903-83EE-CAF0A04144BE@oracle.com>
	<564A1D9E.3090207@oracle.com>
	<D4AF699B-9C4D-456E-86A4-C27D8EB3ECB3@oracle.com>
Message-ID: <564CB63B.3010206@oracle.com>

John, Coleen, thanks for the reviews!

Best regards,
Vladimir Ivanov

On 11/16/15 11:24 PM, John Rose wrote:
> On Nov 16, 2015, at 10:17 AM, Vladimir Ivanov
> <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> wrote:
>>
>> Updated version:
>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04/
>>
>> Changes related to bug fix:
>> http://cr.openjdk.java.net/~vlivanov/8139595/webrev.04.fix/
>
> Good answers.  Reviewed.  ? John

From asmundak at google.com  Wed Nov 18 18:41:30 2015
From: asmundak at google.com (Alexander Smundak)
Date: Wed, 18 Nov 2015 10:41:30 -0800
Subject: RFR(M): 8143180: PPC: Internal Error in
	src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EBA9C7@DEWDFEMB12A.global.corp.sap>
References: <CAHQ51u5mPQAgzicPd0oHAvBr0RbAQFmV6EOvQVT5=67AgUXZaw@mail.gmail.com>
	<4295855A5C1DE049A61835A1887419CC41EBA9C7@DEWDFEMB12A.global.corp.sap>
Message-ID: <CAHQ51u6n2KLHX4wWV1MgHa89WxKf+uFr9zGFO4isFekeTiGOtg@mail.gmail.com>

Hi Goetz,

You are right, sorry about that. Here's the correct one:

http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.01

On Wed, Nov 18, 2015 at 1:03 AM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi Alexander,
>
> Did you fix the wrong line?
> I think it needs to be
>  2965: __ li(R5, Deoptimization::Unpack_exception);
>
> Could you also use R5_ARG3 as register?
>
> Thanks for spotting this,
>   Goetz.
>
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak
> Sent: Wednesday, November 18, 2015 2:15 AM
> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
> Subject: RFR(M): 8143180: PPC: Internal Error in src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
>
> Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-8143180
> I have tested it on PPC64LE.
>
> http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.00
>
> Sasha

From dmitry.dmitriev at oracle.com  Wed Nov 18 20:00:15 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 18 Nov 2015 23:00:15 +0300
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a
	subset of tested values specified for a flag
Message-ID: <564CD8CF.2030002@oracle.com>

Hello,

Please review enhancement to the command line option validation test 
framework.

Currently TestOptionsWithRanges test have several options excluded from 
testing, because these options with big or small values can cause 
problem with testing(create a huge number of threads or consume too much 
memory). This enhancement added ability to exclude max or min values 
from testing and TestOptionsWithRanges was corrected to use this 
enhancement.

Also, in this fix I remove adding negative out-of-range values for the 
unsigned options, because negative values are actual invalid(not 
out-of-range) values for unsigned options.

JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/ 
<http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
Testing: tested on all platforms. One of the test was failed on win-64 
platform, but this is not relate to this change. Filled 
https://bugs.openjdk.java.net/browse/JDK-8143249 for that(which seems 
related to the JDK-8069282)

Thanks,
Dmitry

From david.holmes at oracle.com  Wed Nov 18 20:39:12 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Nov 2015 06:39:12 +1000
Subject: RFR (s) 8141570: Fix Zero interpreter build for
	--disable-precompiled-headers
In-Reply-To: <DBC9802D-A97F-49D3-9C97-A3986CA0EA97@oracle.com>
References: <563C036A.3050008@oracle.com>
	<7E928237-1BAC-4132-B7D1-290B34F537C4@oracle.com>
	<1447073484.3551.30.camel@redhat.com> <56411D2A.3030701@oracle.com>
	<1447153203.3700.15.camel@redhat.com> <564A7B3A.1070005@oracle.com>
	<564A8496.4090605@oracle.com>
	<DBC9802D-A97F-49D3-9C97-A3986CA0EA97@oracle.com>
Message-ID: <564CE1F0.5020407@oracle.com>

On 18/11/2015 5:18 AM, Kim Barrett wrote:
> On Nov 16, 2015, at 8:36 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>
>> Sorry that was the wrong webrev:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>
> Code changes look good.
>
> Not surprisingly, I like the makefile changes, though after the discussion and Severin?s results I?d be
> tempted to remove any special -Wundef handling for llvm and wait for someone with a complaint to
> supply llvm version information.

The makefile changes seem unrelated to the actual bug report, but ok.

src/share/vm/gc/g1/g1EvacStats.cpp

Minor nit: New include isn't in alphabetical order.

Otherwise all seems good.

Thanks,
David

From rob.mckenna at oracle.com  Wed Nov 18 21:08:31 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 18 Nov 2015 21:08:31 +0000
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <1447843821.3660.11.camel@redhat.com>
References: <1447843821.3660.11.camel@redhat.com>
Message-ID: <564CE8CF.4020302@oracle.com>

Approved. Please add a suitable noreg label to the bug.

	-Rob

On 18/11/15 10:50, Severin Gehwolf wrote:
> Hi,
>
> I'd like to ask for approval of a Zero-specific hotspot 8 backport.
> Currently, the jdk8u forest fails to build the Zero variant with GCC 5
> due to this:
>
> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error: function returns address of local variable [-Werror=return-local-addr]
>     return dummy;
>            ^
> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note: declared here
>     address dummy = (address) &dummy;
>             ^
> Note: Fedora 22+ have GCC 5. The above problem and the actual overflow
> bug (if warning is ignored at build time + on relevant arch) goes away
> when JDK-8087120 gets backported to 8u.
>
> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/
> 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018884.html
>
> The 9 webrev applies with no change to the 8 forest. I'd need somebody
> to sponsor this for me.
>
> Thanks,
> Severin
>

From mark.reinhold at oracle.com  Thu Nov 19 01:28:55 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 18 Nov 2015 17:28:55 -0800 (PST)
Subject: JEP 280: Indify String Concatenation
Message-ID: <20151119012855.D501981AC8@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/280

- Mark

From sgehwolf at redhat.com  Thu Nov 19 09:20:28 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Nov 2015 10:20:28 +0100
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <564CE8CF.4020302@oracle.com>
References: <1447843821.3660.11.camel@redhat.com> <564CE8CF.4020302@oracle.com>
Message-ID: <1447924828.4010.3.camel@redhat.com>

On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
> Approved. Please add a suitable noreg label to the bug.
> 
> 	-Rob

Thanks, Rob!

I've added a noreg-hard label to?JDK-8087120.

Cheers,
Severin

> On 18/11/15 10:50, Severin Gehwolf wrote:
> > Hi,
> > 
> > I'd like to ask for approval of a Zero-specific hotspot 8 backport.
> > Currently, the jdk8u forest fails to build the Zero variant with
> > GCC 5
> > due to this:
> > 
> > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error: function
> > returns address of local variable [-Werror=return-local-addr]
> > ????return dummy;
> > ???????????^
> > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note: declared
> > here
> > ????address dummy = (address) &dummy;
> > ????????????^
> > Note: Fedora 22+ have GCC 5. The above problem and the actual
> > overflow
> > bug (if warning is ignored at build time + on relevant arch) goes
> > away
> > when JDK-8087120 gets backported to 8u.
> > 
> > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> > 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/
> > webrev.01/
> > 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev
> > /2015-June/018884.html
> > 
> > The 9 webrev applies with no change to the 8 forest. I'd need
> > somebody
> > to sponsor this for me.
> > 
> > Thanks,
> > Severin
> > 


From sgehwolf at redhat.com  Thu Nov 19 09:41:20 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Nov 2015 10:41:20 +0100
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <564CE8CF.4020302@oracle.com>
References: <1447843821.3660.11.camel@redhat.com> <564CE8CF.4020302@oracle.com>
Message-ID: <1447926080.4010.8.camel@redhat.com>

On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
> Approved. Please add a suitable noreg label to the bug.
> 
> 	-Rob

Another question: Wouldn't I need a sponsor to get this integrated? Is
this being taken care of automatically?

Thanks for your help!

Cheers,
Severin

> On 18/11/15 10:50, Severin Gehwolf wrote:
> > Hi,
> > 
> > I'd like to ask for approval of a Zero-specific hotspot 8 backport.
> > Currently, the jdk8u forest fails to build the Zero variant with
> > GCC 5
> > due to this:
> > 
> > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error: function
> > returns address of local variable [-Werror=return-local-addr]
> > ????return dummy;
> > ???????????^
> > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note: declared
> > here
> > ????address dummy = (address) &dummy;
> > ????????????^
> > Note: Fedora 22+ have GCC 5. The above problem and the actual
> > overflow
> > bug (if warning is ignored at build time + on relevant arch) goes
> > away
> > when JDK-8087120 gets backported to 8u.
> > 
> > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> > 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/
> > webrev.01/
> > 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev
> > /2015-June/018884.html
> > 
> > The 9 webrev applies with no change to the 8 forest. I'd need
> > somebody
> > to sponsor this for me.
> > 
> > Thanks,
> > Severin
> > 


From volker.simonis at gmail.com  Thu Nov 19 09:55:21 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 19 Nov 2015 10:55:21 +0100
Subject: RFR(M): 8143180: PPC: Internal Error in
	src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
In-Reply-To: <CAHQ51u6n2KLHX4wWV1MgHa89WxKf+uFr9zGFO4isFekeTiGOtg@mail.gmail.com>
References: <CAHQ51u5mPQAgzicPd0oHAvBr0RbAQFmV6EOvQVT5=67AgUXZaw@mail.gmail.com>
	<4295855A5C1DE049A61835A1887419CC41EBA9C7@DEWDFEMB12A.global.corp.sap>
	<CAHQ51u6n2KLHX4wWV1MgHa89WxKf+uFr9zGFO4isFekeTiGOtg@mail.gmail.com>
Message-ID: <CA+3eh11_cjgR-Xyv6BFfA6m_RHucJbc+LNsiKvzdacB72E5D8Q@mail.gmail.com>

Looks good!

Thanks for fixing this,
Volker


On Wed, Nov 18, 2015 at 7:41 PM, Alexander Smundak <asmundak at google.com>
wrote:

> Hi Goetz,
>
> You are right, sorry about that. Here's the correct one:
>
> http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.01
>
> On Wed, Nov 18, 2015 at 1:03 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> > Hi Alexander,
> >
> > Did you fix the wrong line?
> > I think it needs to be
> >  2965: __ li(R5, Deoptimization::Unpack_exception);
> >
> > Could you also use R5_ARG3 as register?
> >
> > Thanks for spotting this,
> >   Goetz.
> >
> >
> >
> > -----Original Message-----
> > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Alexander Smundak
> > Sent: Wednesday, November 18, 2015 2:15 AM
> > To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
> > Subject: RFR(M): 8143180: PPC: Internal Error in
> src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
> >
> > Please review the patch fixing
> https://bugs.openjdk.java.net/browse/JDK-8143180
> > I have tested it on PPC64LE.
> >
> > http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.00
> >
> > Sasha
>

From goetz.lindenmaier at sap.com  Thu Nov 19 10:22:22 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 19 Nov 2015 10:22:22 +0000
Subject: RFR(M): 8143180: PPC: Internal Error in
	src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
In-Reply-To: <CAHQ51u6n2KLHX4wWV1MgHa89WxKf+uFr9zGFO4isFekeTiGOtg@mail.gmail.com>
References: <CAHQ51u5mPQAgzicPd0oHAvBr0RbAQFmV6EOvQVT5=67AgUXZaw@mail.gmail.com>
	<4295855A5C1DE049A61835A1887419CC41EBA9C7@DEWDFEMB12A.global.corp.sap>
	<CAHQ51u6n2KLHX4wWV1MgHa89WxKf+uFr9zGFO4isFekeTiGOtg@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41EBB0DF@DEWDFEMB12A.global.corp.sap>

Hi Alexander, 

thanks for fixing this.  I added R5_ARG3 in the call, too.
I pushed the change.  I wanted to get it in before 8141133
is moved over to jdk9/hs/hotspot.
Unfortunately, I forgot to mention you as contributor!  Sorry.
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6100ab176973

Best regards,
  Goetz.



> -----Original Message-----
> From: Alexander Smundak [mailto:asmundak at google.com]
> Sent: Mittwoch, 18. November 2015 19:42
> To: Lindenmaier, Goetz
> Cc: HotSpot Open Source Developers
> Subject: Re: RFR(M): 8143180: PPC: Internal Error in
> src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
> 
> Hi Goetz,
> 
> You are right, sorry about that. Here's the correct one:
> 
> http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.01
> 
> On Wed, Nov 18, 2015 at 1:03 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> > Hi Alexander,
> >
> > Did you fix the wrong line?
> > I think it needs to be
> >  2965: __ li(R5, Deoptimization::Unpack_exception);
> >
> > Could you also use R5_ARG3 as register?
> >
> > Thanks for spotting this,
> >   Goetz.
> >
> >
> >
> > -----Original Message-----
> > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Alexander Smundak
> > Sent: Wednesday, November 18, 2015 2:15 AM
> > To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
> > Subject: RFR(M): 8143180: PPC: Internal Error in
> src/cpu/ppc/vm/macroAssembler_ppc.cpp:4287
> >
> > Please review the patch fixing https://bugs.openjdk.java.net/browse/JDK-
> 8143180
> > I have tested it on PPC64LE.
> >
> > http://cr.openjdk.java.net/~asmundak/8143180/hotspot/webrev.00
> >
> > Sasha

From aph at redhat.com  Thu Nov 19 11:56:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Nov 2015 11:56:47 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
Message-ID: <564DB8FF.2080103@redhat.com>

http://cr.openjdk.java.net/~aph/8143219/

Two things happened, one simple and one not-so-simple.

Firstly, the string comparators now take a byte count (because it's a
byte array now) rather than a char count.

Secondly, string_indexOf needs to have a guard to make sure that
substr.count <= string.count.  This is guaranteed by
LibraryCallKit::inline_string_indexOf but not by
LibraryCallKit::inline_string_indexOfI.  This is a subtle change, and
was quite tricky to figure out.  I have fixed it here in the AArch64
back end.

It would be nice to have the preconditions for the intrinsics
commented somewhere, so that a porter could know what they should do
and what they should expect.

Andrew.

From tobias.hartmann at oracle.com  Thu Nov 19 15:08:28 2015
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 19 Nov 2015 16:08:28 +0100
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564DB8FF.2080103@redhat.com>
References: <564DB8FF.2080103@redhat.com>
Message-ID: <564DE5EC.8040901@oracle.com>

Hi Andrew,

thanks for catching this!

On 19.11.2015 12:56, Andrew Haley wrote:
> http://cr.openjdk.java.net/~aph/8143219/
> 
> Two things happened, one simple and one not-so-simple.
> 
> Firstly, the string comparators now take a byte count (because it's a
> byte array now) rather than a char count.

Looks good.

> Secondly, string_indexOf needs to have a guard to make sure that
> substr.count <= string.count.  This is guaranteed by
> LibraryCallKit::inline_string_indexOf but not by
> LibraryCallKit::inline_string_indexOfI.  This is a subtle change, and
> was quite tricky to figure out.  I have fixed it here in the AArch64
> back end.

I think this check should be done in inline_string_indexOfI() because other intrinsics may also depend on it (see macroAssembler_x86.cpp). Same applies to the "substr count == 0" check. One could probably factor out the checks and use them for both inline_string_indexOf* methods.

I'm moving some more runtime checks from the Java code into the intrinsics (see JDK-8142303 which is currently out for review on hotspot-compiler-dev).

If you want, I can take care of these checks as well.

Best,
Tobias

From aph at redhat.com  Thu Nov 19 15:13:38 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Nov 2015 15:13:38 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564DE5EC.8040901@oracle.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
Message-ID: <564DE722.3050804@redhat.com>

Hi,

On 11/19/2015 03:08 PM, Tobias Hartmann wrote:

> On 19.11.2015 12:56, Andrew Haley wrote:
>> http://cr.openjdk.java.net/~aph/8143219/
>>
>> Two things happened, one simple and one not-so-simple.
>>
>> Firstly, the string comparators now take a byte count (because it's a
>> byte array now) rather than a char count.
> 
> Looks good.
> 
>> Secondly, string_indexOf needs to have a guard to make sure that
>> substr.count <= string.count.  This is guaranteed by
>> LibraryCallKit::inline_string_indexOf but not by
>> LibraryCallKit::inline_string_indexOfI.  This is a subtle change, and
>> was quite tricky to figure out.  I have fixed it here in the AArch64
>> back end.
> 
> I think this check should be done in inline_string_indexOfI()
> because other intrinsics may also depend on it (see
> macroAssembler_x86.cpp). Same applies to the "substr count == 0"
> check. One could probably factor out the checks and use them for
> both inline_string_indexOf* methods.
> 
> I'm moving some more runtime checks from the Java code into the
> intrinsics (see JDK-8142303 which is currently out for review on
> hotspot-compiler-dev).
> 
> If you want, I can take care of these checks as well.

OK, that would be cool.  In the meantime it's a bit difficult for
AArch64 because nothing works without these fixes.  I wonder if I
should push this workaround and back it out later.

Andrew.

From gerard.ziemski at oracle.com  Thu Nov 19 15:22:56 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 19 Nov 2015 09:22:56 -0600
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <564CD8CF.2030002@oracle.com>
References: <564CD8CF.2030002@oracle.com>
Message-ID: <564DE950.100@oracle.com>

hi Dmitry,

Looks good.

They only feedback I have is that I'm not too crazy about the name "notTest*Range" for API. How about 
"excludeTest*Range" instead?


cheers

On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
> Hello,
>
> Please review enhancement to the command line option validation test framework.
>
> Currently TestOptionsWithRanges test have several options excluded from testing, because these options with big or small
> values can cause problem with testing(create a huge number of threads or consume too much memory). This enhancement
> added ability to exclude max or min values from testing and TestOptionsWithRanges was corrected to use this enhancement.
>
> Also, in this fix I remove adding negative out-of-range values for the unsigned options, because negative values are
> actual invalid(not out-of-range) values for unsigned options.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
> Testing: tested on all platforms. One of the test was failed on win-64 platform, but this is not relate to this change.
> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for that(which seems related to the JDK-8069282)
>
> Thanks,
> Dmitry
>

From dmitry.dmitriev at oracle.com  Thu Nov 19 15:27:40 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 19 Nov 2015 18:27:40 +0300
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <564DE950.100@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
Message-ID: <564DEA6C.50604@oracle.com>

Gerard, thank you for the review! Yes, sure, I will change API names.

Dmitry

On 19.11.2015 18:22, gerard ziemski wrote:
> hi Dmitry,
>
> Looks good.
>
> They only feedback I have is that I'm not too crazy about the name 
> "notTest*Range" for API. How about "excludeTest*Range" instead?
>
>
> cheers
>
> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review enhancement to the command line option validation test 
>> framework.
>>
>> Currently TestOptionsWithRanges test have several options excluded 
>> from testing, because these options with big or small
>> values can cause problem with testing(create a huge number of threads 
>> or consume too much memory). This enhancement
>> added ability to exclude max or min values from testing and 
>> TestOptionsWithRanges was corrected to use this enhancement.
>>
>> Also, in this fix I remove adding negative out-of-range values for 
>> the unsigned options, because negative values are
>> actual invalid(not out-of-range) values for unsigned options.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>> Testing: tested on all platforms. One of the test was failed on 
>> win-64 platform, but this is not relate to this change.
>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for 
>> that(which seems related to the JDK-8069282)
>>
>> Thanks,
>> Dmitry
>>


From edward.nevill at gmail.com  Thu Nov 19 15:33:14 2015
From: edward.nevill at gmail.com (Edward Nevill)
Date: Thu, 19 Nov 2015 15:33:14 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564DB8FF.2080103@redhat.com>
References: <564DB8FF.2080103@redhat.com>
Message-ID: <1447947194.9655.12.camel@mylittlepony.linaroharston>

On Thu, 2015-11-19 at 11:56 +0000, Andrew Haley wrote:
> http://cr.openjdk.java.net/~aph/8143219/
> 
> Two things happened, one simple and one not-so-simple.
> 
> Firstly, the string comparators now take a byte count (because it's a
> byte array now) rather than a char count.
> 
> Secondly, string_indexOf needs to have a guard to make sure that
> substr.count <= string.count.  This is guaranteed by
> LibraryCallKit::inline_string_indexOf but not by
> LibraryCallKit::inline_string_indexOfI.  This is a subtle change, and
> was quite tricky to figure out.  I have fixed it here in the AArch64
> back end.
> 
> It would be nice to have the preconditions for the intrinsics
> commented somewhere, so that a porter could know what they should do
> and what they should expect.

Two things

1) Is it really the case that string_compare takes the inputs as a byte count but returns the result as a char count which AFAICS is what this does. It would be nice to know the post-conditions as well.

2) For efficiency the asr cnt, #1 instructions could be folded into the implementations of string_compare and string_equals. I think this could be deferred until we add back end support for CompactStrings - it is more important to get aarch64 tree working again.

All the best,
Ed.



From rob.mckenna at oracle.com  Thu Nov 19 15:43:47 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 19 Nov 2015 15:43:47 +0000
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <1447926080.4010.8.camel@redhat.com>
References: <1447843821.3660.11.camel@redhat.com>
	<564CE8CF.4020302@oracle.com> <1447926080.4010.8.camel@redhat.com>
Message-ID: <564DEE33.5000402@oracle.com>

Correct. You need a sponsor. Perhaps Andrew would be willing to help? 
Failing that please work with the hotspot group.

	-Rob

On 19/11/15 09:41, Severin Gehwolf wrote:
> On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
>> Approved. Please add a suitable noreg label to the bug.
>>
>> 	-Rob
>
> Another question: Wouldn't I need a sponsor to get this integrated? Is
> this being taken care of automatically?
>
> Thanks for your help!
>
> Cheers,
> Severin
>
>> On 18/11/15 10:50, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> I'd like to ask for approval of a Zero-specific hotspot 8 backport.
>>> Currently, the jdk8u forest fails to build the Zero variant with
>>> GCC 5
>>> due to this:
>>>
>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error: function
>>> returns address of local variable [-Werror=return-local-addr]
>>>      return dummy;
>>>             ^
>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note: declared
>>> here
>>>      address dummy = (address) &dummy;
>>>              ^
>>> Note: Fedora 22+ have GCC 5. The above problem and the actual
>>> overflow
>>> bug (if warning is ignored at build time + on relevant arch) goes
>>> away
>>> when JDK-8087120 gets backported to 8u.
>>>
>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
>>> 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/
>>> webrev.01/
>>> 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev
>>> /2015-June/018884.html
>>>
>>> The 9 webrev applies with no change to the 8 forest. I'd need
>>> somebody
>>> to sponsor this for me.
>>>
>>> Thanks,
>>> Severin
>>>
>

From aph at redhat.com  Thu Nov 19 15:57:08 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Nov 2015 15:57:08 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <1447947194.9655.12.camel@mylittlepony.linaroharston>
References: <564DB8FF.2080103@redhat.com>
	<1447947194.9655.12.camel@mylittlepony.linaroharston>
Message-ID: <564DF154.3020706@redhat.com>

On 11/19/2015 03:33 PM, Edward Nevill wrote:
> On Thu, 2015-11-19 at 11:56 +0000, Andrew Haley wrote:
>> http://cr.openjdk.java.net/~aph/8143219/
>>
>> Two things happened, one simple and one not-so-simple.
>>
>> Firstly, the string comparators now take a byte count (because it's a
>> byte array now) rather than a char count.
>>
>> Secondly, string_indexOf needs to have a guard to make sure that
>> substr.count <= string.count.  This is guaranteed by
>> LibraryCallKit::inline_string_indexOf but not by
>> LibraryCallKit::inline_string_indexOfI.  This is a subtle change, and
>> was quite tricky to figure out.  I have fixed it here in the AArch64
>> back end.
>>
>> It would be nice to have the preconditions for the intrinsics
>> commented somewhere, so that a porter could know what they should do
>> and what they should expect.
> 
> Two things
> 
> 1) Is it really the case that string_compare takes the inputs as a
> byte count but returns the result as a char count which AFAICS is
> what this does.

Yes.

> It would be nice to know the post-conditions as well.
> 
> 2) For efficiency the asr cnt, #1 instructions could be folded into
> the implementations of string_compare and string_equals.

They could, and I looked at doing so, but for the sake of robustness
and not changing the interface to the intrinsic generators I didn't.
If (God forbid) there was ever an odd byte length in that array the
intrinsic would scan all of memory, which is a very different kind of
badness from the Java code.  So, I thought I'd mask out the lower bit,
but that's the same instruction count.  Given that the performance
difference is so slight I went with robustness.

Incidentally, I noticed that we have a char_arrays_equals which seems
to do the same job as string_equals.  I think x86 uses the same
primitive for both, and we should too.

Andrew.

From marcus at lagergren.net  Thu Nov 19 16:17:53 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Thu, 19 Nov 2015 17:17:53 +0100
Subject: JFokus VM Tech Day 2016
In-Reply-To: <809E0327-271A-4985-B7E1-F02004500F34@lagergren.net>
References: <809E0327-271A-4985-B7E1-F02004500F34@lagergren.net>
Message-ID: <ACAFD337-72F4-48D5-9373-83A55D2D4B76@lagergren.net>

And all talks have now been finalized: https://www.jfokus.se/jfokus/jvmtech.jsp

A VM tech day without Martin Thompson is no VM tech day!

Regards
Marcus

> On 11 Nov 2015, at 09:35, Marcus Lagergren <marcus at lagergren.net> wrote:
> 
> Greetings community members!
> 
> I am coordinator for the JFokus VM Tech Day at the JFokus conference in February 2016. This is the second year running we have this event, and it was a great success last year. This year we have received significantly more contributions, and the hardest part was sifting through all quality material that we were given.
> 
> We are in the process of finalizing the speaker list, but 5 out of 6 slots are now filled and the current agenda looks like this: https://www.jfokus.se/jfokus/jvmtech.jsp
> 
> This year, Brian Goetz, Java Language Architect from Oracle opens the tech day, and talks about project Valhalla and how the OpenJDK is getting there.
> 
> Brian is followed by Charlie Gracie, IBM, who will cover what is some of the most exciting news in the runtime world for a very long time: The open sourcing of the J9 JVM and its APIs, and example applications in the dynamic language space.
> 
> We are also proud (as always) to host the formidable Mr. Aleksey Shipilev, performance czar extraordinare, always balancing on the fine line between brilliant and crazy. Aleksey's presentation is about String compaction, and String optimisations with invokedynamic in Java 9. Hopefully we have room for him at the ordinary JFokus conference as well, as the man spouts excellent tech presentations like a fountain.
> 
> Charlie Nutter also joins us to discuss JRuby 9000, which was released this summer, and about using the JVM as a platform for multi language development.
> 
> Paul Sandoz, a man who can do anything from REST services down to bare silicone magic in his job, will tell us about how VarHandles are implemented in the JVM, performance aspects and why no one should miss sun.misc.Unsafe.
> 
> Our sixth and final speaker slot is being allocated real soon now. Watch this space.
> 
> As usual there is time allocated for breakout sessions, improvised unscheduled lightning talks and discussions / Q&A.
> 
> Join the best VM internals conference initiative since JVMLS, and the first of its kind in the old world.
> 
> Regards
> Marcus Lagergren
> 


From tobias.hartmann at oracle.com  Thu Nov 19 16:48:07 2015
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 19 Nov 2015 17:48:07 +0100
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564DE722.3050804@redhat.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com>
Message-ID: <564DFD47.6010807@oracle.com>



On 19.11.2015 16:13, Andrew Haley wrote:
> Hi,
> 
> On 11/19/2015 03:08 PM, Tobias Hartmann wrote:
> 
>> On 19.11.2015 12:56, Andrew Haley wrote:
>>> http://cr.openjdk.java.net/~aph/8143219/
>>>
>>> Two things happened, one simple and one not-so-simple.
>>>
>>> Firstly, the string comparators now take a byte count (because it's a
>>> byte array now) rather than a char count.
>>
>> Looks good.
>>
>>> Secondly, string_indexOf needs to have a guard to make sure that
>>> substr.count <= string.count.  This is guaranteed by
>>> LibraryCallKit::inline_string_indexOf but not by
>>> LibraryCallKit::inline_string_indexOfI.  This is a subtle change, and
>>> was quite tricky to figure out.  I have fixed it here in the AArch64
>>> back end.
>>
>> I think this check should be done in inline_string_indexOfI()
>> because other intrinsics may also depend on it (see
>> macroAssembler_x86.cpp). Same applies to the "substr count == 0"
>> check. One could probably factor out the checks and use them for
>> both inline_string_indexOf* methods.
>>
>> I'm moving some more runtime checks from the Java code into the
>> intrinsics (see JDK-8142303 which is currently out for review on
>> hotspot-compiler-dev).
>>
>> If you want, I can take care of these checks as well.
> 
> OK, that would be cool.  In the meantime it's a bit difficult for
> AArch64 because nothing works without these fixes.  I wonder if I
> should push this workaround and back it out later.

I've sent an updated version of my fix for JDK-8142303. Maybe you could verify that this solves the problem.

Thanks,
Tobias

From aph at redhat.com  Thu Nov 19 17:17:25 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Nov 2015 17:17:25 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564DFD47.6010807@oracle.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
Message-ID: <564E0425.4010302@redhat.com>

On 11/19/2015 04:48 PM, Tobias Hartmann wrote:
> I've sent an updated version of my fix for JDK-8142303. Maybe you could verify that this solves the problem.

I'd love to, but where is it?  I can see no email nor a thartmann
on cr.openjdk.java.net.

Andrew.


From sgehwolf at redhat.com  Thu Nov 19 17:21:39 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Nov 2015 18:21:39 +0100
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <564DEE33.5000402@oracle.com>
References: <1447843821.3660.11.camel@redhat.com>
	<564CE8CF.4020302@oracle.com> <1447926080.4010.8.camel@redhat.com>
	<564DEE33.5000402@oracle.com>
Message-ID: <1447953699.4010.45.camel@redhat.com>

On Thu, 2015-11-19 at 15:43 +0000, Rob McKenna wrote:
> Correct. You need a sponsor. Perhaps Andrew would be willing to help?
> Failing that please work with the hotspot group.

Thanks, Rob.

Hotspot people: To which JDK 8 tree should this get pushed? Andrew,
tells me that he can push it for me once we know where :)

Thanks,
Severin

> 	-Rob
> 
> On 19/11/15 09:41, Severin Gehwolf wrote:
> > On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
> > > Approved. Please add a suitable noreg label to the bug.
> > > 
> > > 	-Rob
> > 
> > Another question: Wouldn't I need a sponsor to get this integrated?
> > Is
> > this being taken care of automatically?
> > 
> > Thanks for your help!
> > 
> > Cheers,
> > Severin
> > 
> > > On 18/11/15 10:50, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > I'd like to ask for approval of a Zero-specific hotspot 8
> > > > backport.
> > > > Currently, the jdk8u forest fails to build the Zero variant
> > > > with
> > > > GCC 5
> > > > due to this:
> > > > 
> > > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error:
> > > > function
> > > > returns address of local variable [-Werror=return-local-addr]
> > > > ?????return dummy;
> > > > ????????????^
> > > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note:
> > > > declared
> > > > here
> > > > ?????address dummy = (address) &dummy;
> > > > ?????????????^
> > > > Note: Fedora 22+ have GCC 5. The above problem and the actual
> > > > overflow
> > > > bug (if warning is ignored at build time + on relevant arch)
> > > > goes
> > > > away
> > > > when JDK-8087120 gets backported to 8u.
> > > > 
> > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> > > > 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087
> > > > 120/
> > > > webrev.01/
> > > > 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot
> > > > -dev
> > > > /2015-June/018884.html
> > > > 
> > > > The 9 webrev applies with no change to the 8 forest. I'd need
> > > > somebody
> > > > to sponsor this for me.
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > 


From vladimir.kozlov at oracle.com  Thu Nov 19 17:29:21 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Nov 2015 09:29:21 -0800
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564E0425.4010302@redhat.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
	<564E0425.4010302@redhat.com>
Message-ID: <564E06F1.2080900@oracle.com>

On hotspot-compiler-dev at openjdk.java.net:

[9] RFR(S): 8142303: C2 compilation fails with "bad AD file"

http://cr.openjdk.java.net/~thartmann/8142303/hotspot/webrev.03/

On 11/19/15 9:17 AM, Andrew Haley wrote:
> On 11/19/2015 04:48 PM, Tobias Hartmann wrote:
>> I've sent an updated version of my fix for JDK-8142303. Maybe you could verify that this solves the problem.
>
> I'd love to, but where is it?  I can see no email nor a thartmann
> on cr.openjdk.java.net.
>
> Andrew.
>

From vladimir.kozlov at oracle.com  Thu Nov 19 17:31:33 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Nov 2015 09:31:33 -0800
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564E06F1.2080900@oracle.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
	<564E0425.4010302@redhat.com> <564E06F1.2080900@oracle.com>
Message-ID: <564E0775.6030008@oracle.com>

Forgot JDK part:

http://cr.openjdk.java.net/~thartmann/8142303/jdk/webrev.00/

Vladimir

On 11/19/15 9:29 AM, Vladimir Kozlov wrote:
> On hotspot-compiler-dev at openjdk.java.net:
>
> [9] RFR(S): 8142303: C2 compilation fails with "bad AD file"
>
> http://cr.openjdk.java.net/~thartmann/8142303/hotspot/webrev.03/
>
> On 11/19/15 9:17 AM, Andrew Haley wrote:
>> On 11/19/2015 04:48 PM, Tobias Hartmann wrote:
>>> I've sent an updated version of my fix for JDK-8142303. Maybe you
>>> could verify that this solves the problem.
>>
>> I'd love to, but where is it?  I can see no email nor a thartmann
>> on cr.openjdk.java.net.
>>
>> Andrew.
>>

From vladimir.kozlov at oracle.com  Thu Nov 19 17:53:43 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Nov 2015 09:53:43 -0800
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <1447953699.4010.45.camel@redhat.com>
References: <1447843821.3660.11.camel@redhat.com>
	<564CE8CF.4020302@oracle.com> <1447926080.4010.8.camel@redhat.com>
	<564DEE33.5000402@oracle.com> <1447953699.4010.45.camel@redhat.com>
Message-ID: <564E0CA7.1040302@oracle.com>

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot

On 11/19/15 9:21 AM, Severin Gehwolf wrote:
> On Thu, 2015-11-19 at 15:43 +0000, Rob McKenna wrote:
>> Correct. You need a sponsor. Perhaps Andrew would be willing to help?
>> Failing that please work with the hotspot group.
>
> Thanks, Rob.
>
> Hotspot people: To which JDK 8 tree should this get pushed? Andrew,
> tells me that he can push it for me once we know where :)
>
> Thanks,
> Severin
>
>> 	-Rob
>>
>> On 19/11/15 09:41, Severin Gehwolf wrote:
>>> On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
>>>> Approved. Please add a suitable noreg label to the bug.
>>>>
>>>> 	-Rob
>>>
>>> Another question: Wouldn't I need a sponsor to get this integrated?
>>> Is
>>> this being taken care of automatically?
>>>
>>> Thanks for your help!
>>>
>>> Cheers,
>>> Severin
>>>
>>>> On 18/11/15 10:50, Severin Gehwolf wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to ask for approval of a Zero-specific hotspot 8
>>>>> backport.
>>>>> Currently, the jdk8u forest fails to build the Zero variant
>>>>> with
>>>>> GCC 5
>>>>> due to this:
>>>>>
>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error:
>>>>> function
>>>>> returns address of local variable [-Werror=return-local-addr]
>>>>>       return dummy;
>>>>>              ^
>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note:
>>>>> declared
>>>>> here
>>>>>       address dummy = (address) &dummy;
>>>>>               ^
>>>>> Note: Fedora 22+ have GCC 5. The above problem and the actual
>>>>> overflow
>>>>> bug (if warning is ignored at build time + on relevant arch)
>>>>> goes
>>>>> away
>>>>> when JDK-8087120 gets backported to 8u.
>>>>>
>>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
>>>>> 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087
>>>>> 120/
>>>>> webrev.01/
>>>>> 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot
>>>>> -dev
>>>>> /2015-June/018884.html
>>>>>
>>>>> The 9 webrev applies with no change to the 8 forest. I'd need
>>>>> somebody
>>>>> to sponsor this for me.
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>>
>>>
>

From sgehwolf at redhat.com  Thu Nov 19 17:57:10 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Nov 2015 18:57:10 +0100
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <564E0CA7.1040302@oracle.com>
References: <1447843821.3660.11.camel@redhat.com>
	<564CE8CF.4020302@oracle.com> <1447926080.4010.8.camel@redhat.com>
	<564DEE33.5000402@oracle.com> <1447953699.4010.45.camel@redhat.com>
	<564E0CA7.1040302@oracle.com>
Message-ID: <1447955830.4010.46.camel@redhat.com>

On Thu, 2015-11-19 at 09:53 -0800, Vladimir Kozlov wrote:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot

Thank you, Vladimir!

Cheers,
Severin

> On 11/19/15 9:21 AM, Severin Gehwolf wrote:
> > On Thu, 2015-11-19 at 15:43 +0000, Rob McKenna wrote:
> > > Correct. You need a sponsor. Perhaps Andrew would be willing to
> > > help?
> > > Failing that please work with the hotspot group.
> > 
> > Thanks, Rob.
> > 
> > Hotspot people: To which JDK 8 tree should this get pushed? Andrew,
> > tells me that he can push it for me once we know where :)
> > 
> > Thanks,
> > Severin
> > 
> > > 	-Rob
> > > 
> > > On 19/11/15 09:41, Severin Gehwolf wrote:
> > > > On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
> > > > > Approved. Please add a suitable noreg label to the bug.
> > > > > 
> > > > > 	-Rob
> > > > 
> > > > Another question: Wouldn't I need a sponsor to get this
> > > > integrated?
> > > > Is
> > > > this being taken care of automatically?
> > > > 
> > > > Thanks for your help!
> > > > 
> > > > Cheers,
> > > > Severin
> > > > 
> > > > > On 18/11/15 10:50, Severin Gehwolf wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I'd like to ask for approval of a Zero-specific hotspot 8
> > > > > > backport.
> > > > > > Currently, the jdk8u forest fails to build the Zero variant
> > > > > > with
> > > > > > GCC 5
> > > > > > due to this:
> > > > > > 
> > > > > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error:
> > > > > > function
> > > > > > returns address of local variable [-Werror=return-local-
> > > > > > addr]
> > > > > > ??????return dummy;
> > > > > > ?????????????^
> > > > > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note:
> > > > > > declared
> > > > > > here
> > > > > > ??????address dummy = (address) &dummy;
> > > > > > ??????????????^
> > > > > > Note: Fedora 22+ have GCC 5. The above problem and the
> > > > > > actual
> > > > > > overflow
> > > > > > bug (if warning is ignored at build time + on relevant
> > > > > > arch)
> > > > > > goes
> > > > > > away
> > > > > > when JDK-8087120 gets backported to 8u.
> > > > > > 
> > > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087
> > > > > > 120
> > > > > > 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > > > > > 8087
> > > > > > 120/
> > > > > > webrev.01/
> > > > > > 9 review thread: http://mail.openjdk.java.net/pipermail/hot
> > > > > > spot
> > > > > > -dev
> > > > > > /2015-June/018884.html
> > > > > > 
> > > > > > The 9 webrev applies with no change to the 8 forest. I'd
> > > > > > need
> > > > > > somebody
> > > > > > to sponsor this for me.
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > > > > 
> > > > 
> > 


From jiangli.zhou at oracle.com  Thu Nov 19 18:11:57 2015
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 19 Nov 2015 10:11:57 -0800
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <5644D899.7040300@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com> <5644D899.7040300@oracle.com>
Message-ID: <95EB0217-7CF4-46F8-B12B-930A571CFB9A@oracle.com>

Hi Gerard,

Looks good! Sorry for the delay.

Thanks,
Jiangli

> On Nov 12, 2015, at 10:21 AM, gerard ziemski <gerard.ziemski at oracle.com> wrote:
> 
> hi all,
> 
> I have updated the fix with rev3, incorporating the feedback from Jiangli:
> 
> - After considering the choices I decided to use MIN when calculating the range's MAX values. This seems to be the most correct, however, the SQE testing framework will need to have those flags disabled for now. I filed issue JDK-8142874 to track an enhancement that would allow Shared* (and all other flags that cause the VM to exit with code other than 0) flags to be tested.
> 
> http://cr.openjdk.java.net/~gziemski/8138983_rev3
> 
> 
> cheers
> 
> On 11/10/2015 11:31 AM, gerard ziemski wrote:
>> hi all,
>> 
>> I have updated the fix with rev2, incorporating feedback from David:
>> 
>> - Move the metaspace constants back into metaspace code
>> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
>> 
>> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>> 
>> 
>> cheers
>> 
>> 
>> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>>> hi all,
>>> 
>>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>> 
>>> - Fix comments and indentation
>>> - Add "-XShare:dump" while testing Shared* flags
>>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>>> 
>>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>> 
>>> 
>>> 
>>> cheers
>>> 
>>> 
>>> 
>>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>> 
>>>> hi all,
>>>> 
>>>> Please review this final fix for JEP-245
>>>> 
>>>> We implement the remaining runtime flags in the Shared* family.
>>>> 
>>>> Summary of changes:
>>>> 
>>>> #1 core fix - we factor out the constants to be used in the ranges
>>>> 
>>>> src/share/vm/classfile/compactHashtable.cpp
>>>> src/share/vm/memory/metaspace.cpp
>>>> src/share/vm/memory/metaspaceShared.hpp
>>>> src/share/vm/runtime/globals.hpp
>>>> 
>>>> 
>>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>>> 
>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>> 
>>>> 
>>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>>> 
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>> 
>>>> 
>>>> #4 we add functionality to OptionsValidation test framework that we later use
>>>> 
>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>> 
>>>> 
>>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>>> 
>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>> 
>>>> 
>>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>>> tests
>>>> 
>>>> References:
>>>> 
>>>>     bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>>  open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>> 
>>>> 
>>>> hg_stat:
>>>> 
>>>>  src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>>>  src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>>>  src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>>>  src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>>>  src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>>>  src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>>>  test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>>  test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>>>  9 files changed, 242 insertions(+), 141 deletions(-)
>>> 
>> 


From gerard.ziemski at oracle.com  Thu Nov 19 18:16:31 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 19 Nov 2015 12:16:31 -0600
Subject: RFR (M): 8138983: Runtime: implement ranges for Shared*** flags
In-Reply-To: <95EB0217-7CF4-46F8-B12B-930A571CFB9A@oracle.com>
References: <60C910E8-B44C-45F8-A468-DA33A1C2CBA5@me.com>
	<563CCE35.3000102@oracle.com> <563D1C97.4010702@oracle.com>
	<564229E1.1070500@oracle.com> <5644D899.7040300@oracle.com>
	<95EB0217-7CF4-46F8-B12B-930A571CFB9A@oracle.com>
Message-ID: <564E11FF.8050905@oracle.com>

Thank you for the review.


cheers


On 11/19/2015 12:11 PM, Jiangli Zhou wrote:
> Hi Gerard,
>
> Looks good! Sorry for the delay.
>
> Thanks,
> Jiangli
>
>> On Nov 12, 2015, at 10:21 AM, gerard ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> hi all,
>>
>> I have updated the fix with rev3, incorporating the feedback from Jiangli:
>>
>> - After considering the choices I decided to use MIN when calculating the range's MAX values. This seems to be the most correct, however, the SQE testing framework will need to have those flags disabled for now. I filed issue JDK-8142874 to track an enhancement that would allow Shared* (and all other flags that cause the VM to exit with code other than 0) flags to be tested.
>>
>> http://cr.openjdk.java.net/~gziemski/8138983_rev3
>>
>>
>> cheers
>>
>> On 11/10/2015 11:31 AM, gerard ziemski wrote:
>>> hi all,
>>>
>>> I have updated the fix with rev2, incorporating feedback from David:
>>>
>>> - Move the metaspace constants back into metaspace code
>>> - Fix test framework that specifies jsa file to be used by the "-Xshare:dump" flag tests
>>>
>>> http://cr.openjdk.java.net/~gziemski/8138983_rev2
>>>
>>>
>>> cheers
>>>
>>>
>>> On 11/06/2015 03:33 PM, gerard ziemski wrote:
>>>> hi all,
>>>>
>>>> I have updated the fix with rev1, incorporating feedback from Dmitry:
>>>>
>>>> - Fix comments and indentation
>>>> - Add "-XShare:dump" while testing Shared* flags
>>>> - Temporarily disable testing of SharedMiscDataSize as with current min default it exits the VM with code 2 (which is
>>>> allowed by the JEP, but not the test framework). This issue is tracked by JDK-8141650
>>>>
>>>> http://cr.openjdk.java.net/~gziemski/8138983_rev1
>>>>
>>>>
>>>>
>>>> cheers
>>>>
>>>>
>>>>
>>>> On 11/06/2015 09:58 AM, gerard ziemski wrote:
>>>>>
>>>>> hi all,
>>>>>
>>>>> Please review this final fix for JEP-245
>>>>>
>>>>> We implement the remaining runtime flags in the Shared* family.
>>>>>
>>>>> Summary of changes:
>>>>>
>>>>> #1 core fix - we factor out the constants to be used in the ranges
>>>>>
>>>>> src/share/vm/classfile/compactHashtable.cpp
>>>>> src/share/vm/memory/metaspace.cpp
>>>>> src/share/vm/memory/metaspaceShared.hpp
>>>>> src/share/vm/runtime/globals.hpp
>>>>>
>>>>>
>>>>> #2 we increase default sizes of range and constraint tables to minimize mallocs
>>>>>
>>>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp
>>>>> src/share/vm/runtime/commandLineFlagRangeList.cpp
>>>>>
>>>>>
>>>>> #3 we fix a bug that I run into the OptionsValidation test framework while working
>>>>>
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java
>>>>>
>>>>>
>>>>> #4 we add functionality to OptionsValidation test framework that we later use
>>>>>
>>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java
>>>>>
>>>>>
>>>>> #5 we cleanup and extend the existing test to detect a case where we get out of range value
>>>>>
>>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java
>>>>>
>>>>>
>>>>> The fix passes RBT "hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick? and JPRT ?hotspot"
>>>>> tests
>>>>>
>>>>> References:
>>>>>
>>>>>      bug link: https://bugs.openjdk.java.net/browse/JDK-8138983
>>>>>   open webrev: http://cr.openjdk.java.net/~gziemski/8138983_rev0
>>>>>
>>>>>
>>>>> hg_stat:
>>>>>
>>>>>   src/share/vm/classfile/compactHashtable.cpp                                              |    2 +-
>>>>>   src/share/vm/memory/metaspace.cpp                                                        |   30 --
>>>>>   src/share/vm/memory/metaspaceShared.hpp                                                  |   19 +-
>>>>>   src/share/vm/runtime/commandLineFlagConstraintList.cpp                                   |    2 +-
>>>>>   src/share/vm/runtime/commandLineFlagRangeList.cpp                                        |    2 +-
>>>>>   src/share/vm/runtime/globals.hpp                                                         |   63 +++++-
>>>>>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java    |    4 +-
>>>>>   test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java |   81 +++++++
>>>>>   test/runtime/SharedArchiveFile/LimitSharedSizes.java                                     |  180 +++++++++-------
>>>>>   9 files changed, 242 insertions(+), 141 deletions(-)
>>>>
>>>
>
>

From dl at cs.oswego.edu  Thu Nov 19 18:10:24 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 19 Nov 2015 13:10:24 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <564A7C41.7020708@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
Message-ID: <564E1090.2060500@cs.oswego.edu>

On 11/16/2015 08:00 PM, David Holmes wrote:
>> I've tried that :-) The amount of code being executed with
>> the ReservedStackAccess privilege tends to increase very
>> quickly and I was concerned about keeping the size of the
>> reserved area small.
>
> How much space does each level of calling need? I know that is hard to answer
> but are we talking a few bytes, few kb, many kb?
>

Relatedly, could someone spell out in more detail the
worst-case behavior of StackOverflowError? Knowing this
might be helpful in some cases in which we might be able to
at least preserve minimal sanity without needing to reserve.

-Doug




From david.holmes at oracle.com  Fri Nov 20 02:25:34 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Nov 2015 12:25:34 +1000
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <564E1090.2060500@cs.oswego.edu>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
	<564E1090.2060500@cs.oswego.edu>
Message-ID: <564E849E.6020201@oracle.com>

On 20/11/2015 4:10 AM, Doug Lea wrote:
> On 11/16/2015 08:00 PM, David Holmes wrote:
>>> I've tried that :-) The amount of code being executed with
>>> the ReservedStackAccess privilege tends to increase very
>>> quickly and I was concerned about keeping the size of the
>>> reserved area small.
>>
>> How much space does each level of calling need? I know that is hard to
>> answer
>> but are we talking a few bytes, few kb, many kb?
>>
>
> Relatedly, could someone spell out in more detail the
> worst-case behavior of StackOverflowError? Knowing this
> might be helpful in some cases in which we might be able to
> at least preserve minimal sanity without needing to reserve.

Not sure what you are asking for Doug - worst-case is that an action 
that is critical to complete does not complete. Best example is 
lock/unlock which have to both update AQS-state and update owner. If 
only one is done the lock internal state is inconsistent and the lock 
ceases to function.

David

> -Doug
>
>
>

From gnu.andrew at redhat.com  Fri Nov 20 03:18:34 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 19 Nov 2015 22:18:34 -0500 (EST)
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <564E0CA7.1040302@oracle.com>
References: <1447843821.3660.11.camel@redhat.com> <564CE8CF.4020302@oracle.com>
	<1447926080.4010.8.camel@redhat.com> <564DEE33.5000402@oracle.com>
	<1447953699.4010.45.camel@redhat.com> <564E0CA7.1040302@oracle.com>
Message-ID: <808044557.12110864.1447989514323.JavaMail.zimbra@redhat.com>

----- Original Message -----
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot
> 
> On 11/19/15 9:21 AM, Severin Gehwolf wrote:
> > On Thu, 2015-11-19 at 15:43 +0000, Rob McKenna wrote:
> >> Correct. You need a sponsor. Perhaps Andrew would be willing to help?
> >> Failing that please work with the hotspot group.
> >
> > Thanks, Rob.
> >
> > Hotspot people: To which JDK 8 tree should this get pushed? Andrew,
> > tells me that he can push it for me once we know where :)
> >
> > Thanks,
> > Severin
> >
> >> 	-Rob
> >>
> >> On 19/11/15 09:41, Severin Gehwolf wrote:
> >>> On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
> >>>> Approved. Please add a suitable noreg label to the bug.
> >>>>
> >>>> 	-Rob
> >>>
> >>> Another question: Wouldn't I need a sponsor to get this integrated?
> >>> Is
> >>> this being taken care of automatically?
> >>>
> >>> Thanks for your help!
> >>>
> >>> Cheers,
> >>> Severin
> >>>
> >>>> On 18/11/15 10:50, Severin Gehwolf wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I'd like to ask for approval of a Zero-specific hotspot 8
> >>>>> backport.
> >>>>> Currently, the jdk8u forest fails to build the Zero variant
> >>>>> with
> >>>>> GCC 5
> >>>>> due to this:
> >>>>>
> >>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error:
> >>>>> function
> >>>>> returns address of local variable [-Werror=return-local-addr]
> >>>>>       return dummy;
> >>>>>              ^
> >>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note:
> >>>>> declared
> >>>>> here
> >>>>>       address dummy = (address) &dummy;
> >>>>>               ^
> >>>>> Note: Fedora 22+ have GCC 5. The above problem and the actual
> >>>>> overflow
> >>>>> bug (if warning is ignored at build time + on relevant arch)
> >>>>> goes
> >>>>> away
> >>>>> when JDK-8087120 gets backported to 8u.
> >>>>>
> >>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> >>>>> 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087
> >>>>> 120/
> >>>>> webrev.01/
> >>>>> 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot
> >>>>> -dev
> >>>>> /2015-June/018884.html
> >>>>>
> >>>>> The 9 webrev applies with no change to the 8 forest. I'd need
> >>>>> somebody
> >>>>> to sponsor this for me.
> >>>>>
> >>>>> Thanks,
> >>>>> Severin
> >>>>>
> >>>
> >
> 

Built:

$ /mnt/builder/jdk8u-dev/images/j2sdk-image/bin/java  -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-andre_2015_11_20_01_48-b00)
OpenJDK 64-Bit Zero VM (build 25.66-b00, interpreted mode)

with GCC 5.1.0 and pushed the change:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c6ef40024aa2

An extra fix was needed to make it build, taken from 8075967:

diff -r c6ef40024aa2 src/cpu/zero/vm/frame_zero.cpp
--- a/src/cpu/zero/vm/frame_zero.cpp	Fri Jun 12 16:09:45 2015 +0100
+++ b/src/cpu/zero/vm/frame_zero.cpp	Fri Nov 20 03:17:01 2015 +0000
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
  * Copyright 2007, 2008, 2009, 2010, 2011 Red Hat, Inc.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
@@ -216,7 +216,7 @@
     valuebuf[buflen - 1] = '\0';
 
     // Print the result
-    st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf);
+    st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf, valuebuf);
   }
 }

I don't know if 8075967 should be backported in full (it contains other changes,
and this seems to have been thrown in there to make it build):

8075967: Zero interpreter asserts for SafeFetch<32,N> calls in ObjectMonitor
Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false for Zero
Reviewed-by: sgehwolf, dholmes

or we should backport just the above under a new bug ID. Thoughts?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From vladimir.kozlov at oracle.com  Fri Nov 20 03:33:59 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Nov 2015 19:33:59 -0800
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <808044557.12110864.1447989514323.JavaMail.zimbra@redhat.com>
References: <1447843821.3660.11.camel@redhat.com>
	<564CE8CF.4020302@oracle.com> <1447926080.4010.8.camel@redhat.com>
	<564DEE33.5000402@oracle.com> <1447953699.4010.45.camel@redhat.com>
	<564E0CA7.1040302@oracle.com>
	<808044557.12110864.1447989514323.JavaMail.zimbra@redhat.com>
Message-ID: <564E94A7.7030700@oracle.com>

Related 8074552 and 8075533 are not backported to 8u.
So I would suggest to push your point fix with new bug id (and link it to 8075967)

https://bugs.openjdk.java.net/browse/JDK-8074552
https://bugs.openjdk.java.net/browse/JDK-8075533

Thanks,
Vladimir

On 11/19/15 7:18 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot
>>
>> On 11/19/15 9:21 AM, Severin Gehwolf wrote:
>>> On Thu, 2015-11-19 at 15:43 +0000, Rob McKenna wrote:
>>>> Correct. You need a sponsor. Perhaps Andrew would be willing to help?
>>>> Failing that please work with the hotspot group.
>>>
>>> Thanks, Rob.
>>>
>>> Hotspot people: To which JDK 8 tree should this get pushed? Andrew,
>>> tells me that he can push it for me once we know where :)
>>>
>>> Thanks,
>>> Severin
>>>
>>>> 	-Rob
>>>>
>>>> On 19/11/15 09:41, Severin Gehwolf wrote:
>>>>> On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
>>>>>> Approved. Please add a suitable noreg label to the bug.
>>>>>>
>>>>>> 	-Rob
>>>>>
>>>>> Another question: Wouldn't I need a sponsor to get this integrated?
>>>>> Is
>>>>> this being taken care of automatically?
>>>>>
>>>>> Thanks for your help!
>>>>>
>>>>> Cheers,
>>>>> Severin
>>>>>
>>>>>> On 18/11/15 10:50, Severin Gehwolf wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to ask for approval of a Zero-specific hotspot 8
>>>>>>> backport.
>>>>>>> Currently, the jdk8u forest fails to build the Zero variant
>>>>>>> with
>>>>>>> GCC 5
>>>>>>> due to this:
>>>>>>>
>>>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error:
>>>>>>> function
>>>>>>> returns address of local variable [-Werror=return-local-addr]
>>>>>>>        return dummy;
>>>>>>>               ^
>>>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note:
>>>>>>> declared
>>>>>>> here
>>>>>>>        address dummy = (address) &dummy;
>>>>>>>                ^
>>>>>>> Note: Fedora 22+ have GCC 5. The above problem and the actual
>>>>>>> overflow
>>>>>>> bug (if warning is ignored at build time + on relevant arch)
>>>>>>> goes
>>>>>>> away
>>>>>>> when JDK-8087120 gets backported to 8u.
>>>>>>>
>>>>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
>>>>>>> 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087
>>>>>>> 120/
>>>>>>> webrev.01/
>>>>>>> 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot
>>>>>>> -dev
>>>>>>> /2015-June/018884.html
>>>>>>>
>>>>>>> The 9 webrev applies with no change to the 8 forest. I'd need
>>>>>>> somebody
>>>>>>> to sponsor this for me.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Severin
>>>>>>>
>>>>>
>>>
>>
>
> Built:
>
> $ /mnt/builder/jdk8u-dev/images/j2sdk-image/bin/java  -version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build 1.8.0-internal-andre_2015_11_20_01_48-b00)
> OpenJDK 64-Bit Zero VM (build 25.66-b00, interpreted mode)
>
> with GCC 5.1.0 and pushed the change:
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c6ef40024aa2
>
> An extra fix was needed to make it build, taken from 8075967:
>
> diff -r c6ef40024aa2 src/cpu/zero/vm/frame_zero.cpp
> --- a/src/cpu/zero/vm/frame_zero.cpp	Fri Jun 12 16:09:45 2015 +0100
> +++ b/src/cpu/zero/vm/frame_zero.cpp	Fri Nov 20 03:17:01 2015 +0000
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>    * Copyright 2007, 2008, 2009, 2010, 2011 Red Hat, Inc.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
> @@ -216,7 +216,7 @@
>       valuebuf[buflen - 1] = '\0';
>
>       // Print the result
> -    st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf);
> +    st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf, valuebuf);
>     }
>   }
>
> I don't know if 8075967 should be backported in full (it contains other changes,
> and this seems to have been thrown in there to make it build):
>
> 8075967: Zero interpreter asserts for SafeFetch<32,N> calls in ObjectMonitor
> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false for Zero
> Reviewed-by: sgehwolf, dholmes
>
> or we should backport just the above under a new bug ID. Thoughts?
>
> Thanks,
>

From gnu.andrew at redhat.com  Fri Nov 20 03:36:57 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 19 Nov 2015 22:36:57 -0500 (EST)
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <564E94A7.7030700@oracle.com>
References: <1447843821.3660.11.camel@redhat.com> <564CE8CF.4020302@oracle.com>
	<1447926080.4010.8.camel@redhat.com> <564DEE33.5000402@oracle.com>
	<1447953699.4010.45.camel@redhat.com> <564E0CA7.1040302@oracle.com>
	<808044557.12110864.1447989514323.JavaMail.zimbra@redhat.com>
	<564E94A7.7030700@oracle.com>
Message-ID: <1159453317.12112720.1447990617014.JavaMail.zimbra@redhat.com>

----- Original Message -----
> Related 8074552 and 8075533 are not backported to 8u.
> So I would suggest to push your point fix with new bug id (and link it to
> 8075967)
> 
> https://bugs.openjdk.java.net/browse/JDK-8074552
> https://bugs.openjdk.java.net/browse/JDK-8075533
> 

Yes, I agree that sounds like the safest option. My impression of the original
changeset is that this really should been a separate bug to begin with; the
change is unrelated to the rest. I'll prepare such a bug tomorrow.

> Thanks,
> Vladimir
> 
> On 11/19/15 7:18 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot
> >>
> >> On 11/19/15 9:21 AM, Severin Gehwolf wrote:
> >>> On Thu, 2015-11-19 at 15:43 +0000, Rob McKenna wrote:
> >>>> Correct. You need a sponsor. Perhaps Andrew would be willing to help?
> >>>> Failing that please work with the hotspot group.
> >>>
> >>> Thanks, Rob.
> >>>
> >>> Hotspot people: To which JDK 8 tree should this get pushed? Andrew,
> >>> tells me that he can push it for me once we know where :)
> >>>
> >>> Thanks,
> >>> Severin
> >>>
> >>>> 	-Rob
> >>>>
> >>>> On 19/11/15 09:41, Severin Gehwolf wrote:
> >>>>> On Wed, 2015-11-18 at 21:08 +0000, Rob McKenna wrote:
> >>>>>> Approved. Please add a suitable noreg label to the bug.
> >>>>>>
> >>>>>> 	-Rob
> >>>>>
> >>>>> Another question: Wouldn't I need a sponsor to get this integrated?
> >>>>> Is
> >>>>> this being taken care of automatically?
> >>>>>
> >>>>> Thanks for your help!
> >>>>>
> >>>>> Cheers,
> >>>>> Severin
> >>>>>
> >>>>>> On 18/11/15 10:50, Severin Gehwolf wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I'd like to ask for approval of a Zero-specific hotspot 8
> >>>>>>> backport.
> >>>>>>> Currently, the jdk8u forest fails to build the Zero variant
> >>>>>>> with
> >>>>>>> GCC 5
> >>>>>>> due to this:
> >>>>>>>
> >>>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:59:10: error:
> >>>>>>> function
> >>>>>>> returns address of local variable [-Werror=return-local-addr]
> >>>>>>>        return dummy;
> >>>>>>>               ^
> >>>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp:58:11: note:
> >>>>>>> declared
> >>>>>>> here
> >>>>>>>        address dummy = (address) &dummy;
> >>>>>>>                ^
> >>>>>>> Note: Fedora 22+ have GCC 5. The above problem and the actual
> >>>>>>> overflow
> >>>>>>> bug (if warning is ignored at build time + on relevant arch)
> >>>>>>> goes
> >>>>>>> away
> >>>>>>> when JDK-8087120 gets backported to 8u.
> >>>>>>>
> >>>>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> >>>>>>> 9 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087
> >>>>>>> 120/
> >>>>>>> webrev.01/
> >>>>>>> 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot
> >>>>>>> -dev
> >>>>>>> /2015-June/018884.html
> >>>>>>>
> >>>>>>> The 9 webrev applies with no change to the 8 forest. I'd need
> >>>>>>> somebody
> >>>>>>> to sponsor this for me.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Severin
> >>>>>>>
> >>>>>
> >>>
> >>
> >
> > Built:
> >
> > $ /mnt/builder/jdk8u-dev/images/j2sdk-image/bin/java  -version
> > openjdk version "1.8.0-internal"
> > OpenJDK Runtime Environment (build
> > 1.8.0-internal-andre_2015_11_20_01_48-b00)
> > OpenJDK 64-Bit Zero VM (build 25.66-b00, interpreted mode)
> >
> > with GCC 5.1.0 and pushed the change:
> >
> > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c6ef40024aa2
> >
> > An extra fix was needed to make it build, taken from 8075967:
> >
> > diff -r c6ef40024aa2 src/cpu/zero/vm/frame_zero.cpp
> > --- a/src/cpu/zero/vm/frame_zero.cpp	Fri Jun 12 16:09:45 2015 +0100
> > +++ b/src/cpu/zero/vm/frame_zero.cpp	Fri Nov 20 03:17:01 2015 +0000
> > @@ -1,5 +1,5 @@
> >   /*
> > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
> > reserved.
> > + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights
> > reserved.
> >    * Copyright 2007, 2008, 2009, 2010, 2011 Red Hat, Inc.
> >    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> >    *
> > @@ -216,7 +216,7 @@
> >       valuebuf[buflen - 1] = '\0';
> >
> >       // Print the result
> > -    st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf);
> > +    st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf,
> > valuebuf);
> >     }
> >   }
> >
> > I don't know if 8075967 should be backported in full (it contains other
> > changes,
> > and this seems to have been thrown in there to make it build):
> >
> > 8075967: Zero interpreter asserts for SafeFetch<32,N> calls in
> > ObjectMonitor
> > Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false for
> > Zero
> > Reviewed-by: sgehwolf, dholmes
> >
> > or we should backport just the above under a new bug ID. Thoughts?
> >
> > Thanks,
> >
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From sgehwolf at redhat.com  Fri Nov 20 10:42:08 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 20 Nov 2015 11:42:08 +0100
Subject: [8u] Request for approval: 8087120: [GCC5]
	java.lang.StackOverflowError on Zero JVM initialization on non x86
	platforms
In-Reply-To: <808044557.12110864.1447989514323.JavaMail.zimbra@redhat.com>
References: <1447843821.3660.11.camel@redhat.com>
	<564CE8CF.4020302@oracle.com> <1447926080.4010.8.camel@redhat.com>
	<564DEE33.5000402@oracle.com> <1447953699.4010.45.camel@redhat.com>
	<564E0CA7.1040302@oracle.com>
	<808044557.12110864.1447989514323.JavaMail.zimbra@redhat.com>
Message-ID: <1448016128.5038.1.camel@redhat.com>

On Thu, 2015-11-19 at 22:18 -0500, Andrew Hughes wrote:
> Built:
> 
> $ /mnt/builder/jdk8u-dev/images/j2sdk-image/bin/java??-version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build 1.8.0-internal-
> andre_2015_11_20_01_48-b00)
> OpenJDK 64-Bit Zero VM (build 25.66-b00, interpreted mode)
> 
> with GCC 5.1.0 and pushed the change:
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/c6ef40024aa2

Thanks, Andrew!

Cheers,
Severin

From thomas.stuefe at gmail.com  Fri Nov 20 10:49:19 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 20 Nov 2015 11:49:19 +0100
Subject: RFR(L): 8143125: [aix] Further Developments for AIX
Message-ID: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>

Hi all,

please review and sponsor these AIX only changes. Basically, with this
change we bring the OpenJDK AIX hotspot port up to speed with the
developments done at SAP in the recent months.

For a more detailled number of changes and fixes, please refer to the bug
description.

Bug: https://bugs.openjdk.java.net/browse/JDK-8143125
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.00/webrev/index.html

Kind Regards, Thomas

From dmitry.dmitriev at oracle.com  Fri Nov 20 11:23:46 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 20 Nov 2015 14:23:46 +0300
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <564DE950.100@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
Message-ID: <564F02C2.9060000@oracle.com>

Hello,

I implement Gerard suggestion about API names. Also, I update code to 
the hs-rt tip revision.
webrev.01: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.01/ 
<http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.01/>

Thanks,
Dmitry

On 19.11.2015 18:22, gerard ziemski wrote:
> hi Dmitry,
>
> Looks good.
>
> They only feedback I have is that I'm not too crazy about the name 
> "notTest*Range" for API. How about "excludeTest*Range" instead?
>
>
> cheers
>
> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review enhancement to the command line option validation test 
>> framework.
>>
>> Currently TestOptionsWithRanges test have several options excluded 
>> from testing, because these options with big or small
>> values can cause problem with testing(create a huge number of threads 
>> or consume too much memory). This enhancement
>> added ability to exclude max or min values from testing and 
>> TestOptionsWithRanges was corrected to use this enhancement.
>>
>> Also, in this fix I remove adding negative out-of-range values for 
>> the unsigned options, because negative values are
>> actual invalid(not out-of-range) values for unsigned options.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>> Testing: tested on all platforms. One of the test was failed on 
>> win-64 platform, but this is not relate to this change.
>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for 
>> that(which seems related to the JDK-8069282)
>>
>> Thanks,
>> Dmitry
>>


From christoph.langer at sap.com  Fri Nov 20 11:30:42 2015
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 20 Nov 2015 11:30:42 +0000
Subject: RFR(L): 8143125: [aix] Further Developments for AIX
In-Reply-To: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
References: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F58B19@DEWDFEMB12B.global.corp.sap>

Hi Thomas,

I can see that in your change you are including "libo4.hpp" in os_aix.cpp. But I can't see this header being part of your patch nor of the OpenJDK depot.

Best regards
Christoph

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
Sent: Freitag, 20. November 2015 11:49
To: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: RFR(L): 8143125: [aix] Further Developments for AIX

Hi all,

please review and sponsor these AIX only changes. Basically, with this
change we bring the OpenJDK AIX hotspot port up to speed with the
developments done at SAP in the recent months.

For a more detailled number of changes and fixes, please refer to the bug
description.

Bug: https://bugs.openjdk.java.net/browse/JDK-8143125
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.00/webrev/index.html

Kind Regards, Thomas

From thomas.stuefe at gmail.com  Fri Nov 20 11:46:35 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 20 Nov 2015 12:46:35 +0100
Subject: RFR(L): 8143125: [aix] Further Developments for AIX
In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F58B19@DEWDFEMB12B.global.corp.sap>
References: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
	<0DFD2E72402C9243A8630A7759B27E4338F58B19@DEWDFEMB12B.global.corp.sap>
Message-ID: <CAA-vtUwi3u6mq5uv92yGd=RBNncRoL2+CAyw_MFv=EDiyO8K3Q@mail.gmail.com>

Hi Christoph,

thanks, good catch :)

I updated the webrev.00 in place.

Kind Regards, Thomas

On Fri, Nov 20, 2015 at 12:30 PM, Langer, Christoph <
christoph.langer at sap.com> wrote:

> Hi Thomas,
>
> I can see that in your change you are including "libo4.hpp" in os_aix.cpp.
> But I can't see this header being part of your patch nor of the OpenJDK
> depot.
>
> Best regards
> Christoph
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
> Of Thomas St?fe
> Sent: Freitag, 20. November 2015 11:49
> To: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers <
> hotspot-dev at openjdk.java.net>
> Subject: RFR(L): 8143125: [aix] Further Developments for AIX
>
> Hi all,
>
> please review and sponsor these AIX only changes. Basically, with this
> change we bring the OpenJDK AIX hotspot port up to speed with the
> developments done at SAP in the recent months.
>
> For a more detailled number of changes and fixes, please refer to the bug
> description.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143125
> webrev:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.00/webrev/index.html
>
> Kind Regards, Thomas
>

From frederic.parain at oracle.com  Fri Nov 20 14:23:07 2015
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 20 Nov 2015 15:23:07 +0100
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <564A7C41.7020708@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
Message-ID: <564F2CCB.8030109@oracle.com>

David,

On 17/11/2015 02:00, David Holmes wrote:
>> Another issue is that writing a rule for javac that is not
>> overpessimistic is also an intractable problem. The pattern
>> "atomic operation followed by method invocation to complete
>> status update" is too general to be the trigger of the annotation.
>> 1) It would lead to an excessive number of methods being annotated,
>> and by consequence an over-sizing of the reserved area.
>> 2) Another condition to hit the bug is that the stack space of
>> the callee method must be bigger than the caller method with
>> the atomic operation. This information depends heavily on runtime
>> information like HW, compilation policies (inlining) and execution
>> profile (to know which methods are going to be compiled first).
>> javac won't have access to these information to annotated methods.
>
> Right - there is no way to know that the atomic operation followed by 
> the call should really be a single atomic operation that we can't 
> implement that way. Given many atomic operations have subsequent code 
> actions, the pattern would degenerate to simply involve the atomic 
> operation, and that wouldn't work well at all.
>
> Further, it isn't always that pattern. Consider for example 
> ReentrantReadWriteLock.sync.tryRelease():
>
>             int nextc = getState() - releases;
>             boolean free = exclusiveCount(nextc) == 0;
>             if (free)
>                 setExclusiveOwnerThread(null);
>             setState(nextc);
>
> here we clear the owner first, but then may fail to set the new state. 
> Actually detecting where a stackoverflow can lead to inconsistent 
> state requires detailed scrutiny of the code. I would like to be able 
> to reason that setState requires no more stack than 
> setExclusiveOwnerThread, but I can't do that simply by code inspection.

Exactly. The inspection of method attribute in the class file doesn't 
give reliable
information.  It only provides a hint about the stack space required 
when the method
is interpreted.  The stack space required once the method has been JIT 
compiled
is fully platform dependent, no way to reason with it at the Java source 
level.


>>> Perhaps we should simply start with j.u.c.locks as the initial 
>>> candidate
>>> sets of classes and work out from there. The idiomatic Lock usage:
>>>
>>> l.lock();
>>> try {
>>>   // ...
>>> } finally {
>>>    l.unlock();
>>> }
>>>
>>> epitomizes the critical-finally-block scenario (though the lock()
>>> problem is much more subtle). AQS is too low-level to flag any specific
>>> function I think; and the other synchronizers perhaps too high-level,
>>> with fewer idiomatic use-cases that obviously benefit from this.
>>>
>>> In that regard I don't agree with where Fred has currently placed the
>>> annotation in ReentrantLock and AQS. The placements appear arbitrary at
>>> first glance - though no doubt they are the result of a deep and 
>>> careful
>>> analysis. But it is far from obvious why the annotation is placed on
>>> NonfairSync.lock but FairSync.tryAcquire(), for example.
>>
>> The annotation is used on methods with the problematic pattern
>> "atomic operation followed by method invocation".
>> Their execution could lead to data corruption if atomic operation
>> is executed successfully but the following method invocation
>> fails because of SOE.
>>
>> In the NonFairSync class, this pattern is in the lock() method,
>> while the tryAcquire() is only a method invocation. So lock()
>> is annotated and tryAcquire() is not. Note that the method
>> invoked by try acquire is nonfairTryAcquire() which has the
>> problematic pattern and is annotated.
>>
>> In the FairSync class, the situation is reversed: lock() is
>> just an method invocation and it is not annotated, and
>> tryAcquire() has the problematic pattern and is annotated.
>>
>> I tried to put the annotation as close as possible to the
>> critical sections in order to minimize the size requirement
>> for the reserved area.
>
> Okay I now understand the rule you were applying. But it isn't obvious 
> from the code. Further, there seem to be other places which could also 
> suffer serious problems. In AQS doReleaseShared() we have:
>
>  720                     if (!h.compareAndSetWaitStatus(Node.SIGNAL, 0))
>  721                         continue;            // loop to recheck 
> cases
>  722                     unparkSuccessor(h);
>
> which could seemingly throw SOE without unparking the successor.
>
> Any compound action that logically forms a "transaction" would need to 
> be immune to SOE.
>

I agree but describing all patterns that logically forms a"transaction" 
is far
above the goal of this JEP. The reserved stack area is a mechanism that
can be used to mitigate effects of stack overflows when their occur in these
"transaction". It is obvious that there's to automatic way to annotate all
critical sections or "transactions". This is why I only annotated the code
relative to ReentranLocks (which was the initial bug) and delayed the
annotation of JDK (or j.u.c) critical sections to a future work. As you
noticed above, it is important to have a deep understanding of the code
in order to identify which sections of code should be annotated.

Note that the annotation doesn't make the code "immune" to SOE.
The SOE still happens, it just delayed until the end of the annotated
section in order to mitigate the damages.

>>> I would be tempted to place them on all the public lock/unlock methods
>>> of the Lock implementations, rather than on the internal AQS-derived
>>> functions, and AQS itself.
>>
>> I've tried that :-) The amount of code being executed with
>> the ReservedStackAccess privilege tends to increase very
>> quickly and I was concerned about keeping the size of the
>> reserved area small.
>
> How much space does each level of calling need? I know that is hard to 
> answer but are we talking a few bytes, few kb, many kb?
>

The few sections I've investigated and dis-assembled were small, far
less than a few kb. However,  some sections I've tried to annotate
because they looked critical were accessed through different paths,
or with different entry points.  My expertise on the java.util.concurrent
code is limited, and I was not confident I could put the annotation on
the more appropriate places.

If you feel confident you could make this analysis and annotation work,
I think it will be a very valuable addition to this JEP work.

Thanks,

Fred

> I'd be looking at expanding the current application of the annotation 
> to cover all affected areas of AQS, AQLS, ReentrantLock and 
> ReeentrantReadWriteLock. StampedLock is a bit more problematic - there 
> it seems we do need to annotate the public API - but if we do it then 
> j.u.c.locks is at least covered.
>
> Thanks,
> David
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com


From dmitrij.pochepko at oracle.com  Thu Nov 19 20:08:01 2015
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Thu, 19 Nov 2015 23:08:01 +0300
Subject: RFR(XXS): JDK-8143261 - Need possibility to add custom platforms to
	run hotspot jtreg tests in jprt
Message-ID: <564E2C21.8080904@oracle.com>

Hi,

please take a look at fix for enhancement JDK-8143261: Need possibility 
to add custom platforms to run hotspot jtreg tests in jprt.

A problem: there is no possibility to specify jprt tested platforms for 
hotspot tests other than in make/jprt.properties. It needs to be more 
flexible.

Solution: i've added variable to respective definition in a same manner 
as it's used in other parts of this property file.

Issue: https://bugs.openjdk.java.net/browse/JDK-8143261
Webrev: http://cr.openjdk.java.net/~dpochepk/8143261/webrev.01/

Thanks,
Dmitrij

From karen.kinnear at oracle.com  Fri Nov 20 17:38:09 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 20 Nov 2015 12:38:09 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <564E849E.6020201@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
	<564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com>
Message-ID: <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com>

One other example is an unlock that requires three steps - update state, update owner and
unpark successor.

thanks,
Karen

> On Nov 19, 2015, at 9:25 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 20/11/2015 4:10 AM, Doug Lea wrote:
>> On 11/16/2015 08:00 PM, David Holmes wrote:
>>>> I've tried that :-) The amount of code being executed with
>>>> the ReservedStackAccess privilege tends to increase very
>>>> quickly and I was concerned about keeping the size of the
>>>> reserved area small.
>>> 
>>> How much space does each level of calling need? I know that is hard to
>>> answer
>>> but are we talking a few bytes, few kb, many kb?
>>> 
>> 
>> Relatedly, could someone spell out in more detail the
>> worst-case behavior of StackOverflowError? Knowing this
>> might be helpful in some cases in which we might be able to
>> at least preserve minimal sanity without needing to reserve.
> 
> Not sure what you are asking for Doug - worst-case is that an action that is critical to complete does not complete. Best example is lock/unlock which have to both update AQS-state and update owner. If only one is done the lock internal state is inconsistent and the lock ceases to function.
> 
> David
> 
>> -Doug
>> 
>> 
>> 


From karen.kinnear at oracle.com  Fri Nov 20 17:40:30 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 20 Nov 2015 12:40:30 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <5643E6AC.2050702@cs.oswego.edu>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu>
Message-ID: <BE21FC37-7FD4-4F22-91A6-855A29A5D71A@oracle.com>

Totally appreciate the suggestion that the java.util.concurrent modifications
be done by folks with more domain expertise.

Would you have us incorporate the initial minimal set of j.u.c. updates or none
at all?


thanks,
Karen

> On Nov 11, 2015, at 8:09 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 11/10/2015 12:38 PM, frederic parain wrote:
> 
>>> If I put on some extra-strength rose-coloured glasses I think I can
>>> almost read that as "something is better than nothing". ;-)
> 
> Yeah, that's what I meant :-) It is good to at least have the
> @ReservedStackAccess annotation and mechanism in place. Finding
> the best way to use it will take more thought and empirical evaluation.
> 
> So I suggest that the hotspot support part of the webrev be put into place,
> and that we incorporate j.u.c updates using it after further exploration
> and evaluation -- we do have a lot of tests using locks etc, so are in
> a better position to make better decisions about alternative placement
> strategies after trying them.
> 
>>> But note that it is not the finally part that need be at issue.
> 
> Right. But given the existence of @ReservedStackAccess, we might be
> able to rework some code so as to use it more sparingly.
> 
> -Doug
> 
> 


From gerard.ziemski at oracle.com  Fri Nov 20 18:37:43 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Fri, 20 Nov 2015 12:37:43 -0600
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <564F02C2.9060000@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
	<564F02C2.9060000@oracle.com>
Message-ID: <564F6877.9050101@oracle.com>

hi Dmitry,

Looks good!



On 11/20/2015 05:23 AM, Dmitry Dmitriev wrote:
> Hello,
>
> I implement Gerard suggestion about API names. Also, I update code to the hs-rt tip revision.
> webrev.01: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.01/
> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.01/>
>
> Thanks,
> Dmitry
>
> On 19.11.2015 18:22, gerard ziemski wrote:
>> hi Dmitry,
>>
>> Looks good.
>>
>> They only feedback I have is that I'm not too crazy about the name "notTest*Range" for API. How about
>> "excludeTest*Range" instead?
>>
>>
>> cheers
>>
>> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review enhancement to the command line option validation test framework.
>>>
>>> Currently TestOptionsWithRanges test have several options excluded from testing, because these options with big or small
>>> values can cause problem with testing(create a huge number of threads or consume too much memory). This enhancement
>>> added ability to exclude max or min values from testing and TestOptionsWithRanges was corrected to use this enhancement.
>>>
>>> Also, in this fix I remove adding negative out-of-range values for the unsigned options, because negative values are
>>> actual invalid(not out-of-range) values for unsigned options.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>>> Testing: tested on all platforms. One of the test was failed on win-64 platform, but this is not relate to this change.
>>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for that(which seems related to the JDK-8069282)
>>>
>>> Thanks,
>>> Dmitry
>>>
>
>

From karen.kinnear at oracle.com  Fri Nov 20 18:44:26 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 20 Nov 2015 13:44:26 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
	<564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com>
	<05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com>
Message-ID: <FACEF79A-72E2-4B34-B225-96582FB83F4A@oracle.com>

Frederic,

Code review for web revs you sent out.
Code looks good. I am not as familiar with the compiler code.

I realize you need to check in at least a subset of the java.util.concurrent changes for
the test to work, so maybe I should not have asked Doug about his preference there.
Sorry.

I am impressed you found a way to make a reproducible test!

Comments/questions:
1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if?

2. IIRC, due to another bug with windows handling of our guard pages, this
is disabled for Windows. Would it be worth putting a comment in the
bug , 8067946, that once this is fixed, the reserved stack logic on windows
will need testing before enabling?

3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if
this is in interpreter code, you explicitly return the Java sender
of the current frame. I was expecting to see that on Solaris_sparc and Windows
as well? I do see the assertion in caller that you do have a java frame.

4. test line 83 ?writtent? -> ?written?

5. I like the way you set up the preallocated exception and then set the message - we may
try that for default methods in future.

6. I had a memory that you had found a bug in safe_for_sender - did you already check that in?

7. I see the change in trace.xml, and I see an include added to SharedRuntime.cpp, 
but I didn?t see where it was used - did I just miss it?

thanks,
Karen


From dmitry.dmitriev at oracle.com  Fri Nov 20 19:13:37 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 20 Nov 2015 22:13:37 +0300
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <564F6877.9050101@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
	<564F02C2.9060000@oracle.com> <564F6877.9050101@oracle.com>
Message-ID: <564F70E1.5040708@oracle.com>

Hi Gerard,

Thank you for the review!

Dmitry

On 20.11.2015 21:37, gerard ziemski wrote:
> hi Dmitry,
>
> Looks good!
>
>
>
> On 11/20/2015 05:23 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> I implement Gerard suggestion about API names. Also, I update code to 
>> the hs-rt tip revision.
>> webrev.01: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.01/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.01/>
>>
>> Thanks,
>> Dmitry
>>
>> On 19.11.2015 18:22, gerard ziemski wrote:
>>> hi Dmitry,
>>>
>>> Looks good.
>>>
>>> They only feedback I have is that I'm not too crazy about the name 
>>> "notTest*Range" for API. How about
>>> "excludeTest*Range" instead?
>>>
>>>
>>> cheers
>>>
>>> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please review enhancement to the command line option validation 
>>>> test framework.
>>>>
>>>> Currently TestOptionsWithRanges test have several options excluded 
>>>> from testing, because these options with big or small
>>>> values can cause problem with testing(create a huge number of 
>>>> threads or consume too much memory). This enhancement
>>>> added ability to exclude max or min values from testing and 
>>>> TestOptionsWithRanges was corrected to use this enhancement.
>>>>
>>>> Also, in this fix I remove adding negative out-of-range values for 
>>>> the unsigned options, because negative values are
>>>> actual invalid(not out-of-range) values for unsigned options.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>>>> Testing: tested on all platforms. One of the test was failed on 
>>>> win-64 platform, but this is not relate to this change.
>>>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for 
>>>> that(which seems related to the JDK-8069282)
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>
>>


From sangheon.kim at oracle.com  Fri Nov 20 21:04:27 2015
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Fri, 20 Nov 2015 13:04:27 -0800
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
Message-ID: <564F8ADB.9090008@oracle.com>

Hi all,

Could I have a couple of reviews for this change to add explicit 'range' 
for flags?

Previously, we added 'range' when it is needed to avoid assert/crash but 
now explicit 'range' are needed for all flags.
All flags should have 'range' or 'constraint' at least.

CR: https://bugs.openjdk.java.net/browse/JDK-8142341
Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
Testing: JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist 
--add-tonga-keyword quick), hotspot/test/runtime/CommandLine for embedded

* Summary
1. Added 3 new constraint functions.
    1) HeapBaseMinAddress: Added to avoid an overflow after align up and 
this flag makes hang up without constraint function. (newly added as a 
part of GC work)
    2) TLABWasteIncrement: Without this constraint function we don't 
have problems (even many GCs happen). But added to avoid an overflow at 
ThreadLocalAllocBuffer::record_slow_allocation(). There are also 
separate CR for this overflow ( JDK-8143352 ).
    3) NUMAInterleaveGranularity: Added to avoid an overflow after align up.

2. Some flags have narrower range than their type.
    1) Here's the reason why some flags should have different range. 
(same order from globals.hpp)
{flag type} {flag name}: (range), {comment}
size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), 
max_uintx), there is a comment at numa_interleaving_init() that this 
flag should be larger than vm_allocation_granularity().
uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as 
used for multiplication
uintx CMS_FLSPadding: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
uintx CMS_SweepPadding: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
intx CMSWaitDuration: (min_jint, max_jint), used to set a function which 
has 'long' type input parameter.
uintx PausePadding: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
uintx PromotedPadding: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
uintx SurvivorPadding: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag is 
divided by 100 I assume this is percentage.
uintx GCTimeRatio: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
intx PrefetchCopyIntervalInBytes: (-1, max_jint)
intx PrefetchScanIntervalInBytes:  (-1, max_jint)
intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch* 
flags should have same upper limit and looking at their related codes 
'max_jint' seems appropriate ( no problem with 'max_jint' during 
testing). However, as Prefetch::read/write() needs 'intx', 'intx' also 
seems good but we have to fix some codes (maybe including generated codes).
uintx CPUForCMSThread: (0, max_juint), used to set a function which has 
'unsigned int' type input parameter.
uintx ProcessDistributionStride: (0, max_juint), used to set uint 
variable and used 'for loop' which has uint increment. i.e. for (uint 
i=0; i<ProcessDistributionStride; i++)
uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 'increment 
for loop()' as max value and the increment is uint.
uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for 
loop()' as max value and the increment is uint.
uintx TLABRefillWasteFraction: (1, max_juint), used as a return value of 
uint type function and for division. i.e. uint 
GCTLABConfiguration::tlab_refill_waste_limit()() { return 
TLABRefillWasteFraction; }
uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
intx PrintCMSStatistics: (0,2), flag to choose print mode and we only 
use " if (a !=0, >0, >1)".
intx PrintFLSStatistics: (0,2), flag to choose print mode and we only 
use " if (a !=0, >0, >1)".
intx PrintFLSCensus: (0,1), flag to choose print mode and we only use " 
if (a !=0, >0)".
uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned int'

(g1_globals.hpp)
intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) 
type variable.

3. Excluded flags from TestOptionsWithRanges.java
1) Memory and thread related flags: tests for these flags will consume 
too many resources from the system.
2) VMThreadStackSize: range work for this flag is not included in this 
patch but I faced OOME several times, so excluded.

* I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] 
TestOptionsWithRanges: allow excluding only a subset of tested values 
specified for a flag) next time.

Thanks,
Sangheon




From dl at cs.oswego.edu  Mon Nov 23 00:04:51 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 22 Nov 2015 19:04:51 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <BE21FC37-7FD4-4F22-91A6-855A29A5D71A@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu>
	<BE21FC37-7FD4-4F22-91A6-855A29A5D71A@oracle.com>
Message-ID: <56525823.6010506@cs.oswego.edu>

On 11/20/2015 12:40 PM, Karen Kinnear wrote:
> Totally appreciate the suggestion that the java.util.concurrent modifications
> be done by folks with more domain expertise.
>
> Would you have us incorporate the initial minimal set of j.u.c. updates or none
> at all?

Sorry that I'm still in foot-drag mode on this.
Reading David and Fred's exchanges reinforce my thoughts
that there is no defensible rule or approach to
use @ReservedStackAccess so as to add as little time and
space as possible to reduce the occurrence of stuck
resources as much as possible during StackOverflowError.

After googling "StackOverflowError java util concurrent" and seeing the
range of situations that can be encountered, I don't even know
which kinds of constructions to target.
And I'm less sure whether using @ReservedStackAccess at all
is better than doing nothing.

Maybe there is some decent empirical strategy, but I can't
tell until hotspot support of @ReservedStackAccess is in place.
So my vote is still to keep the JDK changes out for now.

-Doug


From david.holmes at oracle.com  Mon Nov 23 07:03:14 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Nov 2015 17:03:14 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based
	thread-local variables
Message-ID: <5652BA32.8090207@oracle.com>

After all the preliminary discussions here are final proposed changes:

bug: https://bugs.openjdk.java.net/browse/JDK-8132510

Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/

A simple (in principle) but wide-ranging change which should appeal to 
our Code Deletion Engineer's. We implement Thread::current() using a 
compiler/language-based thread-local variable eg:

  static __thread Thread *_thr_current;

  inline Thread* Thread::current() {
    return _thr_current;
  }

with an appropriate setter of course. By doing this we can completely 
remove the os_cpu-specific ThreadLocalStorage implementations, and the 
associated os::thread_local_storage* calls.

As __thread is not async-signal-safe (either in theory or practice) we 
need a fallback library-based solution as used today. For this we use a 
very simple ThreadLocalStorage class and an implementation thereof for 
POSIX (covers AIX, BSD, Linux, OSX and Solaris) using 
pthread_get/setspecific; and one for Windows using its TLS library. 
While these library routines are not guaranteed async-signal-safe, they 
seem to be in practice and are what we have been using all along.

We also allow for use of only the library-based TLS for platforms where 
compiler-based thread locals are not supported (as will be needed in the 
Mobile project). This is enabled at build time by defining 
USE_LIBRARY_BASED_TLS_ONLY.

Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas 
Stuefe for testing PPC and AIX.

Testing:
  - JPRT (core platforms)
  - Jtreg tests (linux & solaris)
  - vm.runtime (core platforms)

Performance:
  - still TBD - this is proving to be extremely difficult. If anyone has 
any simple to run microbenchmarks to suggest I'd give them a try as a 
sanity check. But I lack access to hardware for running serious 
benchmarking.

Footprint:
- varies by platform and the VM (server, client, minimal)
- worst-case: ~1% increase for server VM and minimal VM
- best-case:  0.4% decrease for client VM

Thanks,
David

From bertrand.delsart at oracle.com  Mon Nov 23 10:14:05 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Mon, 23 Nov 2015 11:14:05 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5652BA32.8090207@oracle.com>
References: <5652BA32.8090207@oracle.com>
Message-ID: <5652E6ED.4050106@oracle.com>

Hi David,

Overall looks good.
Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)

One doubt, in case this has not been discussed before.

I'm still catching up on x86_64 (after years of ARM assembly :-)) but it 
seems that there are some stack alignment constraints on runtime calls, 
at least for some x86_64 ABIs.

Some of the x86 MacroAssembler::get_thread implementations had code to 
align the stack before calling pthread_getspecific. See for instance
http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html

This alignment is no longer performed in the new (shared) implementation 
http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html

Now, Solaris was not performing the alignment and Windows has a separate 
path for x86_64. Did we really need the alignment for linux x86_64 and 
bsd_x86_64 ? Might it be needed for other ports ?

IMHO, it might be safer to align the stack by default, knowing it should 
not be expensive since we call get_thread rarely for x86_64 (result is 
cached in r15). I'll let you see whether it is worth adding an ifdef so 
as to explicitly deactivate the alignment on some platforms 
(solaris_x86_64 ?)

Regards,

Bertrand.



On 23/11/2015 08:03, David Holmes wrote:
> After all the preliminary discussions here are final proposed changes:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
> A simple (in principle) but wide-ranging change which should appeal to
> our Code Deletion Engineer's. We implement Thread::current() using a
> compiler/language-based thread-local variable eg:
>
>   static __thread Thread *_thr_current;
>
>   inline Thread* Thread::current() {
>     return _thr_current;
>   }
>
> with an appropriate setter of course. By doing this we can completely
> remove the os_cpu-specific ThreadLocalStorage implementations, and the
> associated os::thread_local_storage* calls.
>
> As __thread is not async-signal-safe (either in theory or practice) we
> need a fallback library-based solution as used today. For this we use a
> very simple ThreadLocalStorage class and an implementation thereof for
> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
> pthread_get/setspecific; and one for Windows using its TLS library.
> While these library routines are not guaranteed async-signal-safe, they
> seem to be in practice and are what we have been using all along.
>
> We also allow for use of only the library-based TLS for platforms where
> compiler-based thread locals are not supported (as will be needed in the
> Mobile project). This is enabled at build time by defining
> USE_LIBRARY_BASED_TLS_ONLY.
>
> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
> Stuefe for testing PPC and AIX.
>
> Testing:
>   - JPRT (core platforms)
>   - Jtreg tests (linux & solaris)
>   - vm.runtime (core platforms)
>
> Performance:
>   - still TBD - this is proving to be extremely difficult. If anyone has
> any simple to run microbenchmarks to suggest I'd give them a try as a
> sanity check. But I lack access to hardware for running serious
> benchmarking.
>
> Footprint:
> - varies by platform and the VM (server, client, minimal)
> - worst-case: ~1% increase for server VM and minimal VM
> - best-case:  0.4% decrease for client VM
>
> Thanks,
> David


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From david.holmes at oracle.com  Mon Nov 23 12:27:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Nov 2015 22:27:04 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5652E6ED.4050106@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
Message-ID: <56530618.2020202@oracle.com>

Hi Bertrand,

On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
> Hi David,
>
> Overall looks good.
> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>
> One doubt, in case this has not been discussed before.
>
> I'm still catching up on x86_64 (after years of ARM assembly :-)) but it
> seems that there are some stack alignment constraints on runtime calls,
> at least for some x86_64 ABIs.
>
> Some of the x86 MacroAssembler::get_thread implementations had code to
> align the stack before calling pthread_getspecific. See for instance
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html

Sorry I'm not that familiar with the MacroAssembler - is it this odd 
fragment:

-   push(r10);
-   // XXX
-   mov(r10, rsp);
-   andq(rsp, -16);
-   push(r10);

I'm not at all clear what that is doing - and if it somehow changes the 
alignment wouldn't something need to be fixed up when popping the 
previous values ??

To be honest I'm not even sure what an "unaligned stack" means.

>
> This alignment is no longer performed in the new (shared) implementation
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>
>
> Now, Solaris was not performing the alignment and Windows has a separate
> path for x86_64. Did we really need the alignment for linux x86_64 and
> bsd_x86_64 ? Might it be needed for other ports ?
>
> IMHO, it might be safer to align the stack by default, knowing it should
> not be expensive since we call get_thread rarely for x86_64 (result is
> cached in r15). I'll let you see whether it is worth adding an ifdef so
> as to explicitly deactivate the alignment on some platforms
> (solaris_x86_64 ?)

I don't have enough knowledge to even begin to comment on this. I will 
have to rely on our x86_64 macroassembler experts to explain the old 
code and what the requirements are.

Thanks,
David

> Regards,
>
> Bertrand.
>
>
>
> On 23/11/2015 08:03, David Holmes wrote:
>> After all the preliminary discussions here are final proposed changes:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>
>> A simple (in principle) but wide-ranging change which should appeal to
>> our Code Deletion Engineer's. We implement Thread::current() using a
>> compiler/language-based thread-local variable eg:
>>
>>   static __thread Thread *_thr_current;
>>
>>   inline Thread* Thread::current() {
>>     return _thr_current;
>>   }
>>
>> with an appropriate setter of course. By doing this we can completely
>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>> associated os::thread_local_storage* calls.
>>
>> As __thread is not async-signal-safe (either in theory or practice) we
>> need a fallback library-based solution as used today. For this we use a
>> very simple ThreadLocalStorage class and an implementation thereof for
>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>> pthread_get/setspecific; and one for Windows using its TLS library.
>> While these library routines are not guaranteed async-signal-safe, they
>> seem to be in practice and are what we have been using all along.
>>
>> We also allow for use of only the library-based TLS for platforms where
>> compiler-based thread locals are not supported (as will be needed in the
>> Mobile project). This is enabled at build time by defining
>> USE_LIBRARY_BASED_TLS_ONLY.
>>
>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>> Stuefe for testing PPC and AIX.
>>
>> Testing:
>>   - JPRT (core platforms)
>>   - Jtreg tests (linux & solaris)
>>   - vm.runtime (core platforms)
>>
>> Performance:
>>   - still TBD - this is proving to be extremely difficult. If anyone has
>> any simple to run microbenchmarks to suggest I'd give them a try as a
>> sanity check. But I lack access to hardware for running serious
>> benchmarking.
>>
>> Footprint:
>> - varies by platform and the VM (server, client, minimal)
>> - worst-case: ~1% increase for server VM and minimal VM
>> - best-case:  0.4% decrease for client VM
>>
>> Thanks,
>> David
>
>

From david.holmes at oracle.com  Mon Nov 23 12:38:13 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Nov 2015 22:38:13 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56530618.2020202@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com>
Message-ID: <565308B5.2040006@oracle.com>

On 23/11/2015 10:27 PM, David Holmes wrote:
> Hi Bertrand,
>
> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>> Hi David,
>>
>> Overall looks good.
>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>> One doubt, in case this has not been discussed before.
>>
>> I'm still catching up on x86_64 (after years of ARM assembly :-)) but it
>> seems that there are some stack alignment constraints on runtime calls,
>> at least for some x86_64 ABIs.
>>
>> Some of the x86 MacroAssembler::get_thread implementations had code to
>> align the stack before calling pthread_getspecific. See for instance
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>
> Sorry I'm not that familiar with the MacroAssembler - is it this odd
> fragment:
>
> -   push(r10);
> -   // XXX
> -   mov(r10, rsp);
> -   andq(rsp, -16);
> -   push(r10);
>
> I'm not at all clear what that is doing - and if it somehow changes the
> alignment wouldn't something need to be fixed up when popping the
> previous values ??
>
> To be honest I'm not even sure what an "unaligned stack" means.

Maybe I know more than I thought - or not :). The original code calls 
pthread_getspecific directly and has to pass the key/index as a 
parameter - that has to be properly aligned. The new code does not pass 
any parameters, but just calls Thread::current.

David
-----

>>
>> This alignment is no longer performed in the new (shared) implementation
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>> Now, Solaris was not performing the alignment and Windows has a separate
>> path for x86_64. Did we really need the alignment for linux x86_64 and
>> bsd_x86_64 ? Might it be needed for other ports ?
>>
>> IMHO, it might be safer to align the stack by default, knowing it should
>> not be expensive since we call get_thread rarely for x86_64 (result is
>> cached in r15). I'll let you see whether it is worth adding an ifdef so
>> as to explicitly deactivate the alignment on some platforms
>> (solaris_x86_64 ?)
>
> I don't have enough knowledge to even begin to comment on this. I will
> have to rely on our x86_64 macroassembler experts to explain the old
> code and what the requirements are.
>
> Thanks,
> David
>
>> Regards,
>>
>> Bertrand.
>>
>>
>>
>> On 23/11/2015 08:03, David Holmes wrote:
>>> After all the preliminary discussions here are final proposed changes:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>
>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>
>>> A simple (in principle) but wide-ranging change which should appeal to
>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>> compiler/language-based thread-local variable eg:
>>>
>>>   static __thread Thread *_thr_current;
>>>
>>>   inline Thread* Thread::current() {
>>>     return _thr_current;
>>>   }
>>>
>>> with an appropriate setter of course. By doing this we can completely
>>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>>> associated os::thread_local_storage* calls.
>>>
>>> As __thread is not async-signal-safe (either in theory or practice) we
>>> need a fallback library-based solution as used today. For this we use a
>>> very simple ThreadLocalStorage class and an implementation thereof for
>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>> While these library routines are not guaranteed async-signal-safe, they
>>> seem to be in practice and are what we have been using all along.
>>>
>>> We also allow for use of only the library-based TLS for platforms where
>>> compiler-based thread locals are not supported (as will be needed in the
>>> Mobile project). This is enabled at build time by defining
>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>
>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>> Stuefe for testing PPC and AIX.
>>>
>>> Testing:
>>>   - JPRT (core platforms)
>>>   - Jtreg tests (linux & solaris)
>>>   - vm.runtime (core platforms)
>>>
>>> Performance:
>>>   - still TBD - this is proving to be extremely difficult. If anyone has
>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>> sanity check. But I lack access to hardware for running serious
>>> benchmarking.
>>>
>>> Footprint:
>>> - varies by platform and the VM (server, client, minimal)
>>> - worst-case: ~1% increase for server VM and minimal VM
>>> - best-case:  0.4% decrease for client VM
>>>
>>> Thanks,
>>> David
>>
>>

From bertrand.delsart at oracle.com  Mon Nov 23 13:46:16 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Mon, 23 Nov 2015 14:46:16 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56530618.2020202@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com>
Message-ID: <565318A8.8050003@oracle.com>

On 23/11/2015 13:27, David Holmes wrote:
> Hi Bertrand,
>
> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>> Hi David,
>>
>> Overall looks good.
>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>> One doubt, in case this has not been discussed before.
>>
>> I'm still catching up on x86_64 (after years of ARM assembly :-)) but it
>> seems that there are some stack alignment constraints on runtime calls,
>> at least for some x86_64 ABIs.
>>
>> Some of the x86 MacroAssembler::get_thread implementations had code to
>> align the stack before calling pthread_getspecific. See for instance
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>
> Sorry I'm not that familiar with the MacroAssembler - is it this odd
> fragment:
>
> -   push(r10);
> -   // XXX
> -   mov(r10, rsp);
> -   andq(rsp, -16);
> -   push(r10);
>
> I'm not at all clear what that is doing - and if it somehow changes the
> alignment wouldn't something need to be fixed up when popping the
> previous values ??
>
> To be honest I'm not even sure what an "unaligned stack" means.

On some platforms, SP may have to be aligned on a 16 bytes boundary when 
calling another method.

After having pushed what needed to be saved, the code above rounds SP 
down and saves the old value. It will then also push r11, which results 
in the expected alignment.

The conterpart, after the VM call, is the:
  pop(r11);
  pop(rsp);



>
>>
>> This alignment is no longer performed in the new (shared) implementation
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>> Now, Solaris was not performing the alignment and Windows has a separate
>> path for x86_64. Did we really need the alignment for linux x86_64 and
>> bsd_x86_64 ? Might it be needed for other ports ?
>>
>> IMHO, it might be safer to align the stack by default, knowing it should
>> not be expensive since we call get_thread rarely for x86_64 (result is
>> cached in r15). I'll let you see whether it is worth adding an ifdef so
>> as to explicitly deactivate the alignment on some platforms
>> (solaris_x86_64 ?)
>
> I don't have enough knowledge to even begin to comment on this. I will
> have to rely on our x86_64 macroassembler experts to explain the old
> code and what the requirements are.

OK. This means that the alignment was not removed purposefully.

In that case, you must either keep the per platform code x86_64 (since 
it was not identical for all platforms) or use the safest version, with 
the additional

    // XXX
    mov(r10, rsp);
    andq(rsp, -16);
    push(r10);

before the push(r11) and with the

    pop(rsp);

after the pop(r11). It should work on all x86_64 platforms.

FYI, there is another way to do the alignment, based on the fact that
we are at least aligned on 8 bytes (see 
MacroAssembler::call_VM_leaf_base). I assume that this second version is 
more efficient (particularly thanks to specilative branches) but it 
might be safer/simpler to continue using andq in get_thread.

Bertrand.

>
> Thanks,
> David
>
>> Regards,
>>
>> Bertrand.
>>
>>
>>
>> On 23/11/2015 08:03, David Holmes wrote:
>>> After all the preliminary discussions here are final proposed changes:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>
>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>
>>> A simple (in principle) but wide-ranging change which should appeal to
>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>> compiler/language-based thread-local variable eg:
>>>
>>>   static __thread Thread *_thr_current;
>>>
>>>   inline Thread* Thread::current() {
>>>     return _thr_current;
>>>   }
>>>
>>> with an appropriate setter of course. By doing this we can completely
>>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>>> associated os::thread_local_storage* calls.
>>>
>>> As __thread is not async-signal-safe (either in theory or practice) we
>>> need a fallback library-based solution as used today. For this we use a
>>> very simple ThreadLocalStorage class and an implementation thereof for
>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>> While these library routines are not guaranteed async-signal-safe, they
>>> seem to be in practice and are what we have been using all along.
>>>
>>> We also allow for use of only the library-based TLS for platforms where
>>> compiler-based thread locals are not supported (as will be needed in the
>>> Mobile project). This is enabled at build time by defining
>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>
>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>> Stuefe for testing PPC and AIX.
>>>
>>> Testing:
>>>   - JPRT (core platforms)
>>>   - Jtreg tests (linux & solaris)
>>>   - vm.runtime (core platforms)
>>>
>>> Performance:
>>>   - still TBD - this is proving to be extremely difficult. If anyone has
>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>> sanity check. But I lack access to hardware for running serious
>>> benchmarking.
>>>
>>> Footprint:
>>> - varies by platform and the VM (server, client, minimal)
>>> - worst-case: ~1% increase for server VM and minimal VM
>>> - best-case:  0.4% decrease for client VM
>>>
>>> Thanks,
>>> David
>>
>>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From bertrand.delsart at oracle.com  Mon Nov 23 13:58:45 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Mon, 23 Nov 2015 14:58:45 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <565308B5.2040006@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565308B5.2040006@oracle.com>
Message-ID: <56531B95.6020001@oracle.com>

On 23/11/2015 13:38, David Holmes wrote:
> On 23/11/2015 10:27 PM, David Holmes wrote:
>> Hi Bertrand,
>>
>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>> Hi David,
>>>
>>> Overall looks good.
>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>
>>> One doubt, in case this has not been discussed before.
>>>
>>> I'm still catching up on x86_64 (after years of ARM assembly :-)) but it
>>> seems that there are some stack alignment constraints on runtime calls,
>>> at least for some x86_64 ABIs.
>>>
>>> Some of the x86 MacroAssembler::get_thread implementations had code to
>>> align the stack before calling pthread_getspecific. See for instance
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>
>>>
>>
>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>> fragment:
>>
>> -   push(r10);
>> -   // XXX
>> -   mov(r10, rsp);
>> -   andq(rsp, -16);
>> -   push(r10);
>>
>> I'm not at all clear what that is doing - and if it somehow changes the
>> alignment wouldn't something need to be fixed up when popping the
>> previous values ??
>>
>> To be honest I'm not even sure what an "unaligned stack" means.
>
> Maybe I know more than I thought - or not :). The original code calls
> pthread_getspecific directly and has to pass the key/index as a
> parameter - that has to be properly aligned. The new code does not pass
> any parameters, but just calls Thread::current.

The index was passed in a register (rdi for linux and bsd)

Are you sure the alignment is needed only when there are arguments ?

Checking quickly the ABI, my understanding is that arguments can add 
extra constraints (in particular if we pass __m256 values) but that by 
default the x86_64 ABI requires 16 bytes alignment (independently of 
whether there are arguments or not).

Bad alignments may not trigger bugs in your tests (depending on how 
Thread::current() is implemented) but this looks like a useless risk.

Bertrand.

>
> David
> -----
>
>>>
>>> This alignment is no longer performed in the new (shared) implementation
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>
>>>
>>>
>>>
>>> Now, Solaris was not performing the alignment and Windows has a separate
>>> path for x86_64. Did we really need the alignment for linux x86_64 and
>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>
>>> IMHO, it might be safer to align the stack by default, knowing it should
>>> not be expensive since we call get_thread rarely for x86_64 (result is
>>> cached in r15). I'll let you see whether it is worth adding an ifdef so
>>> as to explicitly deactivate the alignment on some platforms
>>> (solaris_x86_64 ?)
>>
>> I don't have enough knowledge to even begin to comment on this. I will
>> have to rely on our x86_64 macroassembler experts to explain the old
>> code and what the requirements are.
>>
>> Thanks,
>> David
>>
>>> Regards,
>>>
>>> Bertrand.
>>>
>>>
>>>
>>> On 23/11/2015 08:03, David Holmes wrote:
>>>> After all the preliminary discussions here are final proposed changes:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>
>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>
>>>> A simple (in principle) but wide-ranging change which should appeal to
>>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>>> compiler/language-based thread-local variable eg:
>>>>
>>>>   static __thread Thread *_thr_current;
>>>>
>>>>   inline Thread* Thread::current() {
>>>>     return _thr_current;
>>>>   }
>>>>
>>>> with an appropriate setter of course. By doing this we can completely
>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>>>> associated os::thread_local_storage* calls.
>>>>
>>>> As __thread is not async-signal-safe (either in theory or practice) we
>>>> need a fallback library-based solution as used today. For this we use a
>>>> very simple ThreadLocalStorage class and an implementation thereof for
>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>> While these library routines are not guaranteed async-signal-safe, they
>>>> seem to be in practice and are what we have been using all along.
>>>>
>>>> We also allow for use of only the library-based TLS for platforms where
>>>> compiler-based thread locals are not supported (as will be needed in
>>>> the
>>>> Mobile project). This is enabled at build time by defining
>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>
>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>>> Stuefe for testing PPC and AIX.
>>>>
>>>> Testing:
>>>>   - JPRT (core platforms)
>>>>   - Jtreg tests (linux & solaris)
>>>>   - vm.runtime (core platforms)
>>>>
>>>> Performance:
>>>>   - still TBD - this is proving to be extremely difficult. If anyone
>>>> has
>>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>>> sanity check. But I lack access to hardware for running serious
>>>> benchmarking.
>>>>
>>>> Footprint:
>>>> - varies by platform and the VM (server, client, minimal)
>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>> - best-case:  0.4% decrease for client VM
>>>>
>>>> Thanks,
>>>> David
>>>
>>>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From aph at redhat.com  Mon Nov 23 15:29:16 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 23 Nov 2015 15:29:16 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564DFD47.6010807@oracle.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
Message-ID: <565330CC.7040401@redhat.com>

On 11/19/2015 04:48 PM, Tobias Hartmann wrote:
> I've sent an updated version of my fix for JDK-8142303. Maybe you could verify that this solves the problem.

Yes, that looks fine.

  0x0000007fa8582af4: ldr       w12, [x10,#12]
  0x0000007fa8582af8: ldr       w13, [x11,#12]
  0x0000007fa8582afc: asr       w4, w12, #1
  0x0000007fa8582b00: asr       w2, w13, #1
  0x0000007fa8582b04: cmp       w2, w4
  0x0000007fa8582b08: b.gt      0x0000007fa8582d90

substr.count <= string.count

  0x0000007fa8582b0c: cbz       w2, 0x0000007fa8582d98

substr.count != 0

Thanks,

Andrew.


From frederic.parain at oracle.com  Mon Nov 23 17:44:23 2015
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 23 Nov 2015 18:44:23 +0100
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <FACEF79A-72E2-4B34-B225-96582FB83F4A@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
	<564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com>
	<05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com>
	<FACEF79A-72E2-4B34-B225-96582FB83F4A@oracle.com>
Message-ID: <56535077.9090605@oracle.com>

Karen,

Thank you for your review, my answers are in-lined below.

New Webrevs (including some fixes suggested by Paul Sandoz):

http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/
http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/

On 20/11/2015 19:44, Karen Kinnear wrote:
> Frederic,
>
> Code review for web revs you sent out.
> Code looks good. I am not as familiar with the compiler code.
>
> I realize you need to check in at least a subset of the java.util.concurrent changes for
> the test to work, so maybe I should not have asked Doug about his preference there.
> Sorry.
>
> I am impressed you found a way to make a reproducible test!
>
> Comments/questions:
> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if?

Fixed

> 2. IIRC, due to another bug with windows handling of our guard pages, this
> is disabled for Windows. Would it be worth putting a comment in the
> bug , 8067946, that once this is fixed, the reserved stack logic on windows
> will need testing before enabling?

More than testing, the implementation would have to be completed on
Windows. I've added a comment to JDK-8067946.

> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if
> this is in interpreter code, you explicitly return the Java sender
> of the current frame. I was expecting to see that on Solaris_sparc and Windows
> as well? I do see the assertion in caller that you do have a java frame.

It doesn't make sense to check the current frame (no bytecode has been
executed yet, so risk of partially executed critical section). I did the
change but not for all platforms. This is now fixed for Solaris_SPARC
and Windows too.

> 4. test line 83 ?writtent? -> ?written?

Fixed

> 5. I like the way you set up the preallocated exception and then set the message - we may
> try that for default methods in future.
>
> 6. I had a memory that you had found a bug in safe_for_sender - did you already check that in?

I've fixed x86 platforms in JDK-8068655.
I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635),
I had hoped it would have been silently accepted :-)


> 7. I see the change in trace.xml, and I see an include added to SharedRuntime.cpp,
> but I didn?t see where it was used - did I just miss it?

trace.xml changes define a new event.
This event is created at sharedRuntime.cpp::3006 and it is used
in the next 3 lines.

Thanks,

Fred

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From karen.kinnear at oracle.com  Mon Nov 23 19:10:42 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 23 Nov 2015 14:10:42 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <56535077.9090605@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
	<564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com>
	<05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com>
	<FACEF79A-72E2-4B34-B225-96582FB83F4A@oracle.com>
	<56535077.9090605@oracle.com>
Message-ID: <F295D5BC-97D2-44A2-83D0-30F722F85313@oracle.com>

Frederic,

Looks good.

Many thanks.
Karen

> On Nov 23, 2015, at 12:44 PM, Frederic Parain <frederic.parain at oracle.com> wrote:
> 
> Karen,
> 
> Thank you for your review, my answers are in-lined below.
> 
> New Webrevs (including some fixes suggested by Paul Sandoz):
> 
> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/ <http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/>
> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/ <http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/>
> 
> On 20/11/2015 19:44, Karen Kinnear wrote:
>> Frederic,
>> 
>> Code review for web revs you sent out.
>> Code looks good. I am not as familiar with the compiler code.
>> 
>> I realize you need to check in at least a subset of the java.util.concurrent changes for
>> the test to work, so maybe I should not have asked Doug about his preference there.
>> Sorry.
>> 
>> I am impressed you found a way to make a reproducible test!
>> 
>> Comments/questions:
>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if?
> 
> Fixed
> 
>> 2. IIRC, due to another bug with windows handling of our guard pages, this
>> is disabled for Windows. Would it be worth putting a comment in the
>> bug , 8067946, that once this is fixed, the reserved stack logic on windows
>> will need testing before enabling?
> 
> More than testing, the implementation would have to be completed on
> Windows. I've added a comment to JDK-8067946.
> 
>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if
>> this is in interpreter code, you explicitly return the Java sender
>> of the current frame. I was expecting to see that on Solaris_sparc and Windows
>> as well? I do see the assertion in caller that you do have a java frame.
> 
> It doesn't make sense to check the current frame (no bytecode has been
> executed yet, so risk of partially executed critical section). I did the
> change but not for all platforms. This is now fixed for Solaris_SPARC
> and Windows too.
> 
>> 4. test line 83 ?writtent? -> ?written?
> 
> Fixed
> 
>> 5. I like the way you set up the preallocated exception and then set the message - we may
>> try that for default methods in future.
>> 
>> 6. I had a memory that you had found a bug in safe_for_sender - did you already check that in?
> 
> I've fixed x86 platforms in JDK-8068655.
> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635),
> I had hoped it would have been silently accepted :-)
> 
> 
>> 7. I see the change in trace.xml, and I see an include added to SharedRuntime.cpp,
>> but I didn?t see where it was used - did I just miss it?
> 
> trace.xml changes define a new event.
> This event is created at sharedRuntime.cpp::3006 and it is used
> in the next 3 lines.
Thanks. I must have mistyped when I searched for it.
> 
> Thanks,
> 
> Fred
> 
> -- 
> Frederic Parain - Oracle
> Grenoble Engineering Center - France
> Phone: +33 4 76 18 81 17
> Email: Frederic.Parain at oracle.com <mailto:Frederic.Parain at oracle.com>

From dmitry.dmitriev at oracle.com  Mon Nov 23 21:26:20 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 24 Nov 2015 00:26:20 +0300
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <564F02C2.9060000@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
	<564F02C2.9060000@oracle.com>
Message-ID: <5653847C.8070900@oracle.com>

Hello,

Please, can I get Review for that fix? Thank you!

Dmitry

On 20.11.2015 14:23, Dmitry Dmitriev wrote:
> Hello,
>
> I implement Gerard suggestion about API names. Also, I update code to 
> the hs-rt tip revision.
> webrev.01: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.01/>
>
> Thanks,
> Dmitry
>
> On 19.11.2015 18:22, gerard ziemski wrote:
>> hi Dmitry,
>>
>> Looks good.
>>
>> They only feedback I have is that I'm not too crazy about the name 
>> "notTest*Range" for API. How about "excludeTest*Range" instead?
>>
>>
>> cheers
>>
>> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review enhancement to the command line option validation test 
>>> framework.
>>>
>>> Currently TestOptionsWithRanges test have several options excluded 
>>> from testing, because these options with big or small
>>> values can cause problem with testing(create a huge number of 
>>> threads or consume too much memory). This enhancement
>>> added ability to exclude max or min values from testing and 
>>> TestOptionsWithRanges was corrected to use this enhancement.
>>>
>>> Also, in this fix I remove adding negative out-of-range values for 
>>> the unsigned options, because negative values are
>>> actual invalid(not out-of-range) values for unsigned options.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>>> Testing: tested on all platforms. One of the test was failed on 
>>> win-64 platform, but this is not relate to this change.
>>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for 
>>> that(which seems related to the JDK-8069282)
>>>
>>> Thanks,
>>> Dmitry
>>>
>


From david.holmes at oracle.com  Mon Nov 23 21:42:58 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2015 07:42:58 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <565318A8.8050003@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
Message-ID: <56538862.5010609@oracle.com>

On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
> On 23/11/2015 13:27, David Holmes wrote:
>> Hi Bertrand,
>>
>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>> Hi David,
>>>
>>> Overall looks good.
>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>
>>> One doubt, in case this has not been discussed before.
>>>
>>> I'm still catching up on x86_64 (after years of ARM assembly :-)) but it
>>> seems that there are some stack alignment constraints on runtime calls,
>>> at least for some x86_64 ABIs.
>>>
>>> Some of the x86 MacroAssembler::get_thread implementations had code to
>>> align the stack before calling pthread_getspecific. See for instance
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>
>>>
>>
>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>> fragment:
>>
>> -   push(r10);
>> -   // XXX
>> -   mov(r10, rsp);
>> -   andq(rsp, -16);
>> -   push(r10);
>>
>> I'm not at all clear what that is doing - and if it somehow changes the
>> alignment wouldn't something need to be fixed up when popping the
>> previous values ??
>>
>> To be honest I'm not even sure what an "unaligned stack" means.
>
> On some platforms, SP may have to be aligned on a 16 bytes boundary when
> calling another method.

Okay - that seems to be an x64 ABI requirement based on other code in 
MacroAssembler. The reason it is missing in the Solaris code is because 
I already removed it in the earlier changes that were done on Solaris:

http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10

and nobody picked it up. :(

That said, the absence of this code has not caused any problems so 
presumably we are normally aligned.

> After having pushed what needed to be saved, the code above rounds SP
> down and saves the old value. It will then also push r11, which results
> in the expected alignment.
>
> The conterpart, after the VM call, is the:
>   pop(r11);
>   pop(rsp);

I had assumed this extra manipulation was related to pushing the arg for 
the call.

>>> This alignment is no longer performed in the new (shared) implementation
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>
>>>
>>>
>>>
>>> Now, Solaris was not performing the alignment and Windows has a separate
>>> path for x86_64. Did we really need the alignment for linux x86_64 and
>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>
>>> IMHO, it might be safer to align the stack by default, knowing it should
>>> not be expensive since we call get_thread rarely for x86_64 (result is
>>> cached in r15). I'll let you see whether it is worth adding an ifdef so
>>> as to explicitly deactivate the alignment on some platforms
>>> (solaris_x86_64 ?)
>>
>> I don't have enough knowledge to even begin to comment on this. I will
>> have to rely on our x86_64 macroassembler experts to explain the old
>> code and what the requirements are.
>
> OK. This means that the alignment was not removed purposefully.
>
> In that case, you must either keep the per platform code x86_64 (since
> it was not identical for all platforms) or use the safest version, with
> the additional
>
>     // XXX
>     mov(r10, rsp);
>     andq(rsp, -16);
>     push(r10);
>
> before the push(r11) and with the
>
>     pop(rsp);
>
> after the pop(r11). It should work on all x86_64 platforms.

Right, I will add this back to the code - and replace the meaningless // 
XXX with an actual comment!

Many thanks,
David
-----

> FYI, there is another way to do the alignment, based on the fact that
> we are at least aligned on 8 bytes (see
> MacroAssembler::call_VM_leaf_base). I assume that this second version is
> more efficient (particularly thanks to specilative branches) but it
> might be safer/simpler to continue using andq in get_thread.
>
> Bertrand.
>
>>
>> Thanks,
>> David
>>
>>> Regards,
>>>
>>> Bertrand.
>>>
>>>
>>>
>>> On 23/11/2015 08:03, David Holmes wrote:
>>>> After all the preliminary discussions here are final proposed changes:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>
>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>
>>>> A simple (in principle) but wide-ranging change which should appeal to
>>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>>> compiler/language-based thread-local variable eg:
>>>>
>>>>   static __thread Thread *_thr_current;
>>>>
>>>>   inline Thread* Thread::current() {
>>>>     return _thr_current;
>>>>   }
>>>>
>>>> with an appropriate setter of course. By doing this we can completely
>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>>>> associated os::thread_local_storage* calls.
>>>>
>>>> As __thread is not async-signal-safe (either in theory or practice) we
>>>> need a fallback library-based solution as used today. For this we use a
>>>> very simple ThreadLocalStorage class and an implementation thereof for
>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>> While these library routines are not guaranteed async-signal-safe, they
>>>> seem to be in practice and are what we have been using all along.
>>>>
>>>> We also allow for use of only the library-based TLS for platforms where
>>>> compiler-based thread locals are not supported (as will be needed in
>>>> the
>>>> Mobile project). This is enabled at build time by defining
>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>
>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>>> Stuefe for testing PPC and AIX.
>>>>
>>>> Testing:
>>>>   - JPRT (core platforms)
>>>>   - Jtreg tests (linux & solaris)
>>>>   - vm.runtime (core platforms)
>>>>
>>>> Performance:
>>>>   - still TBD - this is proving to be extremely difficult. If anyone
>>>> has
>>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>>> sanity check. But I lack access to hardware for running serious
>>>> benchmarking.
>>>>
>>>> Footprint:
>>>> - varies by platform and the VM (server, client, minimal)
>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>> - best-case:  0.4% decrease for client VM
>>>>
>>>> Thanks,
>>>> David
>>>
>>>
>
>

From christian.tornqvist at oracle.com  Mon Nov 23 22:20:28 2015
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 23 Nov 2015 17:20:28 -0500
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow
	excluding	only a subset of tested values specified for a flag
In-Reply-To: <564F02C2.9060000@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
	<564F02C2.9060000@oracle.com>
Message-ID: <07fa01d1263d$2df38690$89da93b0$@oracle.com>

Hi Dmitry,

This looks good.

Thanks,
Christian

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Dmitriev
Sent: Friday, November 20, 2015 6:24 AM
To: gerard ziemski <gerard.ziemski at oracle.com>; hotspot-dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a subset of tested values specified for a flag

Hello,

I implement Gerard suggestion about API names. Also, I update code to the hs-rt tip revision.
webrev.01: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.01/
<http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.01/>

Thanks,
Dmitry

On 19.11.2015 18:22, gerard ziemski wrote:
> hi Dmitry,
>
> Looks good.
>
> They only feedback I have is that I'm not too crazy about the name 
> "notTest*Range" for API. How about "excludeTest*Range" instead?
>
>
> cheers
>
> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review enhancement to the command line option validation test 
>> framework.
>>
>> Currently TestOptionsWithRanges test have several options excluded 
>> from testing, because these options with big or small values can 
>> cause problem with testing(create a huge number of threads or consume 
>> too much memory). This enhancement added ability to exclude max or 
>> min values from testing and TestOptionsWithRanges was corrected to 
>> use this enhancement.
>>
>> Also, in this fix I remove adding negative out-of-range values for 
>> the unsigned options, because negative values are actual invalid(not 
>> out-of-range) values for unsigned options.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>> Testing: tested on all platforms. One of the test was failed on
>> win-64 platform, but this is not relate to this change.
>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for 
>> that(which seems related to the JDK-8069282)
>>
>> Thanks,
>> Dmitry
>>



From david.holmes at oracle.com  Tue Nov 24 01:17:02 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2015 11:17:02 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56538862.5010609@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
Message-ID: <5653BA8E.8080802@oracle.com>

Updated webrev:

cr.openjdk.java.net/~dholmes/8132510/webrev.v7/

Only change is in macroAssembler_x86.cpp

Thanks,
David

On 24/11/2015 7:42 AM, David Holmes wrote:
> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>> On 23/11/2015 13:27, David Holmes wrote:
>>> Hi Bertrand,
>>>
>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>> Hi David,
>>>>
>>>> Overall looks good.
>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>
>>>> One doubt, in case this has not been discussed before.
>>>>
>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>> but it
>>>> seems that there are some stack alignment constraints on runtime calls,
>>>> at least for some x86_64 ABIs.
>>>>
>>>> Some of the x86 MacroAssembler::get_thread implementations had code to
>>>> align the stack before calling pthread_getspecific. See for instance
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>
>>>>
>>>>
>>>
>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>> fragment:
>>>
>>> -   push(r10);
>>> -   // XXX
>>> -   mov(r10, rsp);
>>> -   andq(rsp, -16);
>>> -   push(r10);
>>>
>>> I'm not at all clear what that is doing - and if it somehow changes the
>>> alignment wouldn't something need to be fixed up when popping the
>>> previous values ??
>>>
>>> To be honest I'm not even sure what an "unaligned stack" means.
>>
>> On some platforms, SP may have to be aligned on a 16 bytes boundary when
>> calling another method.
>
> Okay - that seems to be an x64 ABI requirement based on other code in
> MacroAssembler. The reason it is missing in the Solaris code is because
> I already removed it in the earlier changes that were done on Solaris:
>
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>
> and nobody picked it up. :(
>
> That said, the absence of this code has not caused any problems so
> presumably we are normally aligned.
>
>> After having pushed what needed to be saved, the code above rounds SP
>> down and saves the old value. It will then also push r11, which results
>> in the expected alignment.
>>
>> The conterpart, after the VM call, is the:
>>   pop(r11);
>>   pop(rsp);
>
> I had assumed this extra manipulation was related to pushing the arg for
> the call.
>
>>>> This alignment is no longer performed in the new (shared)
>>>> implementation
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Now, Solaris was not performing the alignment and Windows has a
>>>> separate
>>>> path for x86_64. Did we really need the alignment for linux x86_64 and
>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>
>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>> should
>>>> not be expensive since we call get_thread rarely for x86_64 (result is
>>>> cached in r15). I'll let you see whether it is worth adding an ifdef so
>>>> as to explicitly deactivate the alignment on some platforms
>>>> (solaris_x86_64 ?)
>>>
>>> I don't have enough knowledge to even begin to comment on this. I will
>>> have to rely on our x86_64 macroassembler experts to explain the old
>>> code and what the requirements are.
>>
>> OK. This means that the alignment was not removed purposefully.
>>
>> In that case, you must either keep the per platform code x86_64 (since
>> it was not identical for all platforms) or use the safest version, with
>> the additional
>>
>>     // XXX
>>     mov(r10, rsp);
>>     andq(rsp, -16);
>>     push(r10);
>>
>> before the push(r11) and with the
>>
>>     pop(rsp);
>>
>> after the pop(r11). It should work on all x86_64 platforms.
>
> Right, I will add this back to the code - and replace the meaningless //
> XXX with an actual comment!
>
> Many thanks,
> David
> -----
>
>> FYI, there is another way to do the alignment, based on the fact that
>> we are at least aligned on 8 bytes (see
>> MacroAssembler::call_VM_leaf_base). I assume that this second version is
>> more efficient (particularly thanks to specilative branches) but it
>> might be safer/simpler to continue using andq in get_thread.
>>
>> Bertrand.
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Regards,
>>>>
>>>> Bertrand.
>>>>
>>>>
>>>>
>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>> After all the preliminary discussions here are final proposed changes:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>
>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>
>>>>> A simple (in principle) but wide-ranging change which should appeal to
>>>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>>>> compiler/language-based thread-local variable eg:
>>>>>
>>>>>   static __thread Thread *_thr_current;
>>>>>
>>>>>   inline Thread* Thread::current() {
>>>>>     return _thr_current;
>>>>>   }
>>>>>
>>>>> with an appropriate setter of course. By doing this we can completely
>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>>>>> associated os::thread_local_storage* calls.
>>>>>
>>>>> As __thread is not async-signal-safe (either in theory or practice) we
>>>>> need a fallback library-based solution as used today. For this we
>>>>> use a
>>>>> very simple ThreadLocalStorage class and an implementation thereof for
>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>> While these library routines are not guaranteed async-signal-safe,
>>>>> they
>>>>> seem to be in practice and are what we have been using all along.
>>>>>
>>>>> We also allow for use of only the library-based TLS for platforms
>>>>> where
>>>>> compiler-based thread locals are not supported (as will be needed in
>>>>> the
>>>>> Mobile project). This is enabled at build time by defining
>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>
>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>>>> Stuefe for testing PPC and AIX.
>>>>>
>>>>> Testing:
>>>>>   - JPRT (core platforms)
>>>>>   - Jtreg tests (linux & solaris)
>>>>>   - vm.runtime (core platforms)
>>>>>
>>>>> Performance:
>>>>>   - still TBD - this is proving to be extremely difficult. If anyone
>>>>> has
>>>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>>>> sanity check. But I lack access to hardware for running serious
>>>>> benchmarking.
>>>>>
>>>>> Footprint:
>>>>> - varies by platform and the VM (server, client, minimal)
>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>> - best-case:  0.4% decrease for client VM
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>>>>
>>
>>

From david.holmes at oracle.com  Tue Nov 24 02:19:28 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2015 12:19:28 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5653BA8E.8080802@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
Message-ID: <5653C930.5090602@oracle.com>

Sorry about that:

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/

David

On 24/11/2015 11:17 AM, David Holmes wrote:
> Updated webrev:
>
> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>
> Only change is in macroAssembler_x86.cpp
>
> Thanks,
> David
>
> On 24/11/2015 7:42 AM, David Holmes wrote:
>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>> On 23/11/2015 13:27, David Holmes wrote:
>>>> Hi Bertrand,
>>>>
>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>> Hi David,
>>>>>
>>>>> Overall looks good.
>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>
>>>>> One doubt, in case this has not been discussed before.
>>>>>
>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>> but it
>>>>> seems that there are some stack alignment constraints on runtime
>>>>> calls,
>>>>> at least for some x86_64 ABIs.
>>>>>
>>>>> Some of the x86 MacroAssembler::get_thread implementations had code to
>>>>> align the stack before calling pthread_getspecific. See for instance
>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>>> fragment:
>>>>
>>>> -   push(r10);
>>>> -   // XXX
>>>> -   mov(r10, rsp);
>>>> -   andq(rsp, -16);
>>>> -   push(r10);
>>>>
>>>> I'm not at all clear what that is doing - and if it somehow changes the
>>>> alignment wouldn't something need to be fixed up when popping the
>>>> previous values ??
>>>>
>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>
>>> On some platforms, SP may have to be aligned on a 16 bytes boundary when
>>> calling another method.
>>
>> Okay - that seems to be an x64 ABI requirement based on other code in
>> MacroAssembler. The reason it is missing in the Solaris code is because
>> I already removed it in the earlier changes that were done on Solaris:
>>
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>
>> and nobody picked it up. :(
>>
>> That said, the absence of this code has not caused any problems so
>> presumably we are normally aligned.
>>
>>> After having pushed what needed to be saved, the code above rounds SP
>>> down and saves the old value. It will then also push r11, which results
>>> in the expected alignment.
>>>
>>> The conterpart, after the VM call, is the:
>>>   pop(r11);
>>>   pop(rsp);
>>
>> I had assumed this extra manipulation was related to pushing the arg for
>> the call.
>>
>>>>> This alignment is no longer performed in the new (shared)
>>>>> implementation
>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>> separate
>>>>> path for x86_64. Did we really need the alignment for linux x86_64 and
>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>
>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>> should
>>>>> not be expensive since we call get_thread rarely for x86_64 (result is
>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>> ifdef so
>>>>> as to explicitly deactivate the alignment on some platforms
>>>>> (solaris_x86_64 ?)
>>>>
>>>> I don't have enough knowledge to even begin to comment on this. I will
>>>> have to rely on our x86_64 macroassembler experts to explain the old
>>>> code and what the requirements are.
>>>
>>> OK. This means that the alignment was not removed purposefully.
>>>
>>> In that case, you must either keep the per platform code x86_64 (since
>>> it was not identical for all platforms) or use the safest version, with
>>> the additional
>>>
>>>     // XXX
>>>     mov(r10, rsp);
>>>     andq(rsp, -16);
>>>     push(r10);
>>>
>>> before the push(r11) and with the
>>>
>>>     pop(rsp);
>>>
>>> after the pop(r11). It should work on all x86_64 platforms.
>>
>> Right, I will add this back to the code - and replace the meaningless //
>> XXX with an actual comment!
>>
>> Many thanks,
>> David
>> -----
>>
>>> FYI, there is another way to do the alignment, based on the fact that
>>> we are at least aligned on 8 bytes (see
>>> MacroAssembler::call_VM_leaf_base). I assume that this second version is
>>> more efficient (particularly thanks to specilative branches) but it
>>> might be safer/simpler to continue using andq in get_thread.
>>>
>>> Bertrand.
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Regards,
>>>>>
>>>>> Bertrand.
>>>>>
>>>>>
>>>>>
>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>> After all the preliminary discussions here are final proposed
>>>>>> changes:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>
>>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>
>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>> appeal to
>>>>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>>>>> compiler/language-based thread-local variable eg:
>>>>>>
>>>>>>   static __thread Thread *_thr_current;
>>>>>>
>>>>>>   inline Thread* Thread::current() {
>>>>>>     return _thr_current;
>>>>>>   }
>>>>>>
>>>>>> with an appropriate setter of course. By doing this we can completely
>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and
>>>>>> the
>>>>>> associated os::thread_local_storage* calls.
>>>>>>
>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>> practice) we
>>>>>> need a fallback library-based solution as used today. For this we
>>>>>> use a
>>>>>> very simple ThreadLocalStorage class and an implementation thereof
>>>>>> for
>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>>> While these library routines are not guaranteed async-signal-safe,
>>>>>> they
>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>
>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>> where
>>>>>> compiler-based thread locals are not supported (as will be needed in
>>>>>> the
>>>>>> Mobile project). This is enabled at build time by defining
>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>
>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>>>>> Stuefe for testing PPC and AIX.
>>>>>>
>>>>>> Testing:
>>>>>>   - JPRT (core platforms)
>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>   - vm.runtime (core platforms)
>>>>>>
>>>>>> Performance:
>>>>>>   - still TBD - this is proving to be extremely difficult. If anyone
>>>>>> has
>>>>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>> benchmarking.
>>>>>>
>>>>>> Footprint:
>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>
>>>>>
>>>
>>>

From dmitry.dmitriev at oracle.com  Tue Nov 24 06:10:49 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 24 Nov 2015 09:10:49 +0300
Subject: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding
	only a subset of tested values specified for a flag
In-Reply-To: <07fa01d1263d$2df38690$89da93b0$@oracle.com>
References: <564CD8CF.2030002@oracle.com> <564DE950.100@oracle.com>
	<564F02C2.9060000@oracle.com>
	<07fa01d1263d$2df38690$89da93b0$@oracle.com>
Message-ID: <5653FF69.1050301@oracle.com>

Hi Christian,

Thank you for the review!

Dmitry

On 24.11.2015 1:20, Christian Tornqvist wrote:
> Hi Dmitry,
>
> This looks good.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Dmitriev
> Sent: Friday, November 20, 2015 6:24 AM
> To: gerard ziemski <gerard.ziemski at oracle.com>; hotspot-dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR: 8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a subset of tested values specified for a flag
>
> Hello,
>
> I implement Gerard suggestion about API names. Also, I update code to the hs-rt tip revision.
> webrev.01: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.01/
> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.01/>
>
> Thanks,
> Dmitry
>
> On 19.11.2015 18:22, gerard ziemski wrote:
>> hi Dmitry,
>>
>> Looks good.
>>
>> They only feedback I have is that I'm not too crazy about the name
>> "notTest*Range" for API. How about "excludeTest*Range" instead?
>>
>>
>> cheers
>>
>> On 11/18/2015 02:00 PM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review enhancement to the command line option validation test
>>> framework.
>>>
>>> Currently TestOptionsWithRanges test have several options excluded
>>> from testing, because these options with big or small values can
>>> cause problem with testing(create a huge number of threads or consume
>>> too much memory). This enhancement added ability to exclude max or
>>> min values from testing and TestOptionsWithRanges was corrected to
>>> use this enhancement.
>>>
>>> Also, in this fix I remove adding negative out-of-range values for
>>> the unsigned options, because negative values are actual invalid(not
>>> out-of-range) values for unsigned options.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143038
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8143038/webrev.00/
>>> <http://cr.openjdk.java.net/%7Eddmitriev/8143038/webrev.00/>
>>> Testing: tested on all platforms. One of the test was failed on
>>> win-64 platform, but this is not relate to this change.
>>> Filled https://bugs.openjdk.java.net/browse/JDK-8143249 for
>>> that(which seems related to the JDK-8069282)
>>>
>>> Thanks,
>>> Dmitry
>>>
>


From tobias.hartmann at oracle.com  Tue Nov 24 08:06:04 2015
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 24 Nov 2015 09:06:04 +0100
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <565330CC.7040401@redhat.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
	<565330CC.7040401@redhat.com>
Message-ID: <56541A6C.2050509@oracle.com>

Hi Andrew,

thanks for verifying! I will push the fix at the end of the week to not disturb the sync with hs-main.

Best,
Tobias

On 23.11.2015 16:29, Andrew Haley wrote:
> On 11/19/2015 04:48 PM, Tobias Hartmann wrote:
>> I've sent an updated version of my fix for JDK-8142303. Maybe you could verify that this solves the problem.
> 
> Yes, that looks fine.
> 
>   0x0000007fa8582af4: ldr       w12, [x10,#12]
>   0x0000007fa8582af8: ldr       w13, [x11,#12]
>   0x0000007fa8582afc: asr       w4, w12, #1
>   0x0000007fa8582b00: asr       w2, w13, #1
>   0x0000007fa8582b04: cmp       w2, w4
>   0x0000007fa8582b08: b.gt      0x0000007fa8582d90
> 
> substr.count <= string.count
> 
>   0x0000007fa8582b0c: cbz       w2, 0x0000007fa8582d98
> 
> substr.count != 0
> 
> Thanks,
> 
> Andrew.
> 

From aph at redhat.com  Tue Nov 24 09:35:33 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Nov 2015 09:35:33 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <56541A6C.2050509@oracle.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
	<565330CC.7040401@redhat.com> <56541A6C.2050509@oracle.com>
Message-ID: <56542F65.101@redhat.com>

Incidentally, why is the range check done in LibraryCallKit?  I thought
we were moving to writing such checks in Java.

Andrew.


From magnus.ihse.bursie at oracle.com  Tue Nov 24 09:56:29 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 24 Nov 2015 10:56:29 +0100
Subject: RFR: JDK-8142336: Convert the SA agent build to modular
	build-infra makefiles
In-Reply-To: <564AF7AB.8080509@oracle.com>
References: <5640E6E2.6090906@oracle.com> <5641C95D.8040103@oracle.com>
	<5641F5D3.1000105@oracle.com> <56430AF1.2050109@oracle.com>
	<56437025.4070504@oracle.com> <5645BDD9.8070008@oracle.com>
	<564AF7AB.8080509@oracle.com>
Message-ID: <5654344D.3010003@oracle.com>

On 2015-11-17 10:47, Erik Joelsson wrote:
> Hello,
>
> I realized that there already was a mechanism for controlling the 
> inclusion of SA from configure. Unfortunately, this variable is not 
> picked up by any makefile currently. I changed the explicit checks for 
> aix-ppc and zero to instead use the variable INCLUDE_SA which 
> configure sets up based on at least these conditions.
>
> I also removed another lingering special case instance of the 
> jdk.hotspot.agent module in Main.gmk.
>
> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.03/

Looks good to me!

/Magnus
>
> /Erik
>
> On 2015-11-13 11:39, Erik Joelsson wrote:
>> Widening the distribution in the hopes of finding another reviewer.
>>
>> I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make 
>> locally. Merge tool error.
>>
>> /Erik
>>
>> On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
>>> On 2015-11-11 10:31, Erik Joelsson wrote:
>>>> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.02/
>>>>
>>>> Fixed the issues listed below. Reverted the faulty attempt at 
>>>> fixing a warning. Did a more thorough attempt at clearing out all 
>>>> references to SA in the old makefiles.
>>>
>>> Looks great. There was a few lines in 
>>> hotspot/make/bsd/makefiles/defs.make where you seem to have 
>>> accidentally broken the indentation. Apart from this it looks good. 
>>> If you just restore the indentation I'm okay (you don't need to 
>>> respin the webrev for that).
>>>
>>> /Magnus
>>>
>>>>
>>>> /Erik
>>>>
>>>> On 2015-11-10 14:49, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-10 11:39, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-09 19:33, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> As a stepping stone in the hotspot makefile conversion, I have 
>>>>>>> broken out the serviceability agent separately and converted it 
>>>>>>> into proper modular build-infra makefiles. Doing this conversion 
>>>>>>> separately has some value on its own by reducing the special 
>>>>>>> cases currently needed for building the jdk.hotspot.agent module.
>>>>>>>
>>>>>>> The current SA java build compiles with the boot jdk javac with 
>>>>>>> -source/-target JDK N-1. The proposed change instead builds SA 
>>>>>>> with the interim-langtools javac for JDK N, like all the rest of 
>>>>>>> the JDK classes.
>>>>>>>
>>>>>>> There is already a bug filed for reorganizing the source of the 
>>>>>>> SA agent to conform to the Jigsaw style modular source layout: 
>>>>>>> JDK-8067194, so I have left the source in its current location.
>>>>>>>
>>>>>>> The native compilation and linking has been changed to base the 
>>>>>>> flags used on what configure sets up for the other JDK 
>>>>>>> libraries. This has caused some changes in flag usage. From what 
>>>>>>> I can tell, nothing important is different however. I have run 
>>>>>>> the relevant jtreg tests on all OSes to verify that it still 
>>>>>>> works. Some of the differences include:
>>>>>>>
>>>>>>> * Linux: "-Xlinker z -Xlinker defs" was added to LDFLAGS, which 
>>>>>>> causes link failure unless "-ldl" was also added to LIBS.
>>>>>>> * Solaris: More warnings activated through "+w" caused need for 
>>>>>>> disabling some warnings. I fixed one warning instance which was 
>>>>>>> trivial (int->size_t), but couldn't figure out the rest. I will 
>>>>>>> file a followup bug for fixing those if this patch is accepted.
>>>>>>>
>>>>>>> I tried to mimic the current behavior of excluding SA on 
>>>>>>> linux-ppc and zero that Volker added a while back. Now it's 
>>>>>>> excluded on the module level instead so that jdk.hotspot.agent 
>>>>>>> isn't even built in that case. It would be good if this could be 
>>>>>>> tested.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>>>>>>
>>>>>> A few remarks:
>>>>>>
>>>>>> * Could you please document the new DISABLED_WARNINGS_CXX and 
>>>>>> DISABLED_WARNINGS_C in the function header?
>>>>>>
>>>>>> * I believe the use of {} here was to signify a set. When only 
>>>>>> jsig remains, it just looks strange:
>>>>>> -# SYMFLAG is used by {jsig,saproc}.make
>>>>>> +# SYMFLAG is used by {jsig}.make
>>>>>>
>>>>>> * The logic of setting up "--hash-style=both" is already done in 
>>>>>> configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if 
>>>>>> you include the LDFLAGS_JDKLIB variable.
>>>>>
>>>>> Also, SA_WINDOWS_LDFLAGS is read but never defined.
>>>>>
>>>>> /Magnus
>>>>
>>>
>>
>


From tobias.hartmann at oracle.com  Tue Nov 24 10:20:05 2015
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 24 Nov 2015 11:20:05 +0100
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <56542F65.101@redhat.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
	<565330CC.7040401@redhat.com> <56541A6C.2050509@oracle.com>
	<56542F65.101@redhat.com>
Message-ID: <565439D5.80708@oracle.com>

Hi Andrew,

On 24.11.2015 10:35, Andrew Haley wrote:
> Incidentally, why is the range check done in LibraryCallKit?  I thought
> we were moving to writing such checks in Java.

I don't think we have a general rule. In this case, I decided to move the range checks into the intrinsics because there are some problems with range checks in the Java code. For example with JDK-8142303, the Java range check is not compiled and C2 compilation crashes because an invalid, constant array index is propagated to the intrinsic (see my description in the RFR [1]). Other problems include JDK-6675699 [2] where we fail because there is no dependency between the range check and the ConvI2L node. And in general, there is always the risk that someone uses an intrinsic without the range-check wrapper, causing runtime exceptions that are hard to debug.

Best,
Tobias

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019834.html
[2] https://bugs.openjdk.java.net/browse/JDK-6675699

From staffan.larsen at oracle.com  Tue Nov 24 10:53:24 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 24 Nov 2015 11:53:24 +0100
Subject: RFR: JDK-8142336: Convert the SA agent build to modular
	build-infra makefiles
In-Reply-To: <564AF7AB.8080509@oracle.com>
References: <5640E6E2.6090906@oracle.com> <5641C95D.8040103@oracle.com>
	<5641F5D3.1000105@oracle.com> <56430AF1.2050109@oracle.com>
	<56437025.4070504@oracle.com> <5645BDD9.8070008@oracle.com>
	<564AF7AB.8080509@oracle.com>
Message-ID: <4AF2843B-4CFD-4698-B5DA-08E4DDCC6080@oracle.com>

Looks good!

Thanks,
/Staffan

> On 17 nov. 2015, at 10:47, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> I realized that there already was a mechanism for controlling the inclusion of SA from configure. Unfortunately, this variable is not picked up by any makefile currently. I changed the explicit checks for aix-ppc and zero to instead use the variable INCLUDE_SA which configure sets up based on at least these conditions.
> 
> I also removed another lingering special case instance of the jdk.hotspot.agent module in Main.gmk.
> 
> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.03/
> 
> /Erik
> 
> On 2015-11-13 11:39, Erik Joelsson wrote:
>> Widening the distribution in the hopes of finding another reviewer.
>> 
>> I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make locally. Merge tool error.
>> 
>> /Erik
>> 
>> On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
>>> On 2015-11-11 10:31, Erik Joelsson wrote:
>>>> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.02/
>>>> 
>>>> Fixed the issues listed below. Reverted the faulty attempt at fixing a warning. Did a more thorough attempt at clearing out all references to SA in the old makefiles.
>>> 
>>> Looks great. There was a few lines in hotspot/make/bsd/makefiles/defs.make where you seem to have accidentally broken the indentation. Apart from this it looks good. If you just restore the indentation I'm okay (you don't need to respin the webrev for that).
>>> 
>>> /Magnus
>>> 
>>>> 
>>>> /Erik
>>>> 
>>>> On 2015-11-10 14:49, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-10 11:39, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-09 19:33, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> As a stepping stone in the hotspot makefile conversion, I have broken out the serviceability agent separately and converted it into proper modular build-infra makefiles. Doing this conversion separately has some value on its own by reducing the special cases currently needed for building the jdk.hotspot.agent module.
>>>>>>> 
>>>>>>> The current SA java build compiles with the boot jdk javac with -source/-target JDK N-1. The proposed change instead builds SA with the interim-langtools javac for JDK N, like all the rest of the JDK classes.
>>>>>>> 
>>>>>>> There is already a bug filed for reorganizing the source of the SA agent to conform to the Jigsaw style modular source layout: JDK-8067194, so I have left the source in its current location.
>>>>>>> 
>>>>>>> The native compilation and linking has been changed to base the flags used on what configure sets up for the other JDK libraries. This has caused some changes in flag usage. From what I can tell, nothing important is different however. I have run the relevant jtreg tests on all OSes to verify that it still works. Some of the differences include:
>>>>>>> 
>>>>>>> * Linux: "-Xlinker z -Xlinker defs" was added to LDFLAGS, which causes link failure unless "-ldl" was also added to LIBS.
>>>>>>> * Solaris: More warnings activated through "+w" caused need for disabling some warnings. I fixed one warning instance which was trivial (int->size_t), but couldn't figure out the rest. I will file a followup bug for fixing those if this patch is accepted.
>>>>>>> 
>>>>>>> I tried to mimic the current behavior of excluding SA on linux-ppc and zero that Volker added a while back. Now it's excluded on the module level instead so that jdk.hotspot.agent isn't even built in that case. It would be good if this could be tested.
>>>>>>> 
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>>>>>> 
>>>>>> A few remarks:
>>>>>> 
>>>>>> * Could you please document the new DISABLED_WARNINGS_CXX and DISABLED_WARNINGS_C in the function header?
>>>>>> 
>>>>>> * I believe the use of {} here was to signify a set. When only jsig remains, it just looks strange:
>>>>>> -# SYMFLAG is used by {jsig,saproc}.make
>>>>>> +# SYMFLAG is used by {jsig}.make
>>>>>> 
>>>>>> * The logic of setting up "--hash-style=both" is already done in configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if you include the LDFLAGS_JDKLIB variable.
>>>>> 
>>>>> Also, SA_WINDOWS_LDFLAGS is read but never defined.
>>>>> 
>>>>> /Magnus
>>>> 
>>> 
>> 
> 


From bertrand.delsart at oracle.com  Tue Nov 24 10:58:14 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Tue, 24 Nov 2015 11:58:14 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5653C930.5090602@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
	<5653C930.5090602@oracle.com>
Message-ID: <565442C6.2070004@oracle.com>

On 24/11/2015 03:19, David Holmes wrote:
> Sorry about that:
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/

Approved.

Regards,

Bertrand (not a Reviewer).

>
> David
>
> On 24/11/2015 11:17 AM, David Holmes wrote:
>> Updated webrev:
>>
>> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>
>> Only change is in macroAssembler_x86.cpp
>>
>> Thanks,
>> David
>>
>> On 24/11/2015 7:42 AM, David Holmes wrote:
>>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>> On 23/11/2015 13:27, David Holmes wrote:
>>>>> Hi Bertrand,
>>>>>
>>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Overall looks good.
>>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>>
>>>>>> One doubt, in case this has not been discussed before.
>>>>>>
>>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>>> but it
>>>>>> seems that there are some stack alignment constraints on runtime
>>>>>> calls,
>>>>>> at least for some x86_64 ABIs.
>>>>>>
>>>>>> Some of the x86 MacroAssembler::get_thread implementations had
>>>>>> code to
>>>>>> align the stack before calling pthread_getspecific. See for instance
>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>>>> fragment:
>>>>>
>>>>> -   push(r10);
>>>>> -   // XXX
>>>>> -   mov(r10, rsp);
>>>>> -   andq(rsp, -16);
>>>>> -   push(r10);
>>>>>
>>>>> I'm not at all clear what that is doing - and if it somehow changes
>>>>> the
>>>>> alignment wouldn't something need to be fixed up when popping the
>>>>> previous values ??
>>>>>
>>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>>
>>>> On some platforms, SP may have to be aligned on a 16 bytes boundary
>>>> when
>>>> calling another method.
>>>
>>> Okay - that seems to be an x64 ABI requirement based on other code in
>>> MacroAssembler. The reason it is missing in the Solaris code is because
>>> I already removed it in the earlier changes that were done on Solaris:
>>>
>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>
>>> and nobody picked it up. :(
>>>
>>> That said, the absence of this code has not caused any problems so
>>> presumably we are normally aligned.
>>>
>>>> After having pushed what needed to be saved, the code above rounds SP
>>>> down and saves the old value. It will then also push r11, which results
>>>> in the expected alignment.
>>>>
>>>> The conterpart, after the VM call, is the:
>>>>   pop(r11);
>>>>   pop(rsp);
>>>
>>> I had assumed this extra manipulation was related to pushing the arg for
>>> the call.
>>>
>>>>>> This alignment is no longer performed in the new (shared)
>>>>>> implementation
>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>>> separate
>>>>>> path for x86_64. Did we really need the alignment for linux x86_64
>>>>>> and
>>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>>
>>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>>> should
>>>>>> not be expensive since we call get_thread rarely for x86_64
>>>>>> (result is
>>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>>> ifdef so
>>>>>> as to explicitly deactivate the alignment on some platforms
>>>>>> (solaris_x86_64 ?)
>>>>>
>>>>> I don't have enough knowledge to even begin to comment on this. I will
>>>>> have to rely on our x86_64 macroassembler experts to explain the old
>>>>> code and what the requirements are.
>>>>
>>>> OK. This means that the alignment was not removed purposefully.
>>>>
>>>> In that case, you must either keep the per platform code x86_64 (since
>>>> it was not identical for all platforms) or use the safest version, with
>>>> the additional
>>>>
>>>>     // XXX
>>>>     mov(r10, rsp);
>>>>     andq(rsp, -16);
>>>>     push(r10);
>>>>
>>>> before the push(r11) and with the
>>>>
>>>>     pop(rsp);
>>>>
>>>> after the pop(r11). It should work on all x86_64 platforms.
>>>
>>> Right, I will add this back to the code - and replace the meaningless //
>>> XXX with an actual comment!
>>>
>>> Many thanks,
>>> David
>>> -----
>>>
>>>> FYI, there is another way to do the alignment, based on the fact that
>>>> we are at least aligned on 8 bytes (see
>>>> MacroAssembler::call_VM_leaf_base). I assume that this second
>>>> version is
>>>> more efficient (particularly thanks to specilative branches) but it
>>>> might be safer/simpler to continue using andq in get_thread.
>>>>
>>>> Bertrand.
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Bertrand.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>>> After all the preliminary discussions here are final proposed
>>>>>>> changes:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>>
>>>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>>
>>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>>> appeal to
>>>>>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>>>>>> compiler/language-based thread-local variable eg:
>>>>>>>
>>>>>>>   static __thread Thread *_thr_current;
>>>>>>>
>>>>>>>   inline Thread* Thread::current() {
>>>>>>>     return _thr_current;
>>>>>>>   }
>>>>>>>
>>>>>>> with an appropriate setter of course. By doing this we can
>>>>>>> completely
>>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and
>>>>>>> the
>>>>>>> associated os::thread_local_storage* calls.
>>>>>>>
>>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>>> practice) we
>>>>>>> need a fallback library-based solution as used today. For this we
>>>>>>> use a
>>>>>>> very simple ThreadLocalStorage class and an implementation thereof
>>>>>>> for
>>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>>>> While these library routines are not guaranteed async-signal-safe,
>>>>>>> they
>>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>>
>>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>>> where
>>>>>>> compiler-based thread locals are not supported (as will be needed in
>>>>>>> the
>>>>>>> Mobile project). This is enabled at build time by defining
>>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>>
>>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for
>>>>>>> Thomas
>>>>>>> Stuefe for testing PPC and AIX.
>>>>>>>
>>>>>>> Testing:
>>>>>>>   - JPRT (core platforms)
>>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>>   - vm.runtime (core platforms)
>>>>>>>
>>>>>>> Performance:
>>>>>>>   - still TBD - this is proving to be extremely difficult. If anyone
>>>>>>> has
>>>>>>> any simple to run microbenchmarks to suggest I'd give them a try
>>>>>>> as a
>>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>>> benchmarking.
>>>>>>>
>>>>>>> Footprint:
>>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>
>>>>>>
>>>>
>>>>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From dmitry.samersoff at oracle.com  Tue Nov 24 11:11:48 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 24 Nov 2015 14:11:48 +0300
Subject: RFR: JDK-8142336: Convert the SA agent build to modular
	build-infra makefiles
In-Reply-To: <564AF7AB.8080509@oracle.com>
References: <5640E6E2.6090906@oracle.com>
	<5641C95D.8040103@oracle.com>	<5641F5D3.1000105@oracle.com>
	<56430AF1.2050109@oracle.com>	<56437025.4070504@oracle.com>
	<5645BDD9.8070008@oracle.com> <564AF7AB.8080509@oracle.com>
Message-ID: <565445F4.6070803@oracle.com>

Erik,

Looks good for me!

-Dmitry

On 2015-11-17 12:47, Erik Joelsson wrote:
> Hello,
> 
> I realized that there already was a mechanism for controlling the
> inclusion of SA from configure. Unfortunately, this variable is not
> picked up by any makefile currently. I changed the explicit checks for
> aix-ppc and zero to instead use the variable INCLUDE_SA which configure
> sets up based on at least these conditions.
> 
> I also removed another lingering special case instance of the
> jdk.hotspot.agent module in Main.gmk.
> 
> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.03/
> 
> /Erik
> 
> On 2015-11-13 11:39, Erik Joelsson wrote:
>> Widening the distribution in the hopes of finding another reviewer.
>>
>> I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make
>> locally. Merge tool error.
>>
>> /Erik
>>
>> On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
>>> On 2015-11-11 10:31, Erik Joelsson wrote:
>>>> New webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.02/
>>>>
>>>> Fixed the issues listed below. Reverted the faulty attempt at fixing
>>>> a warning. Did a more thorough attempt at clearing out all
>>>> references to SA in the old makefiles.
>>>
>>> Looks great. There was a few lines in
>>> hotspot/make/bsd/makefiles/defs.make where you seem to have
>>> accidentally broken the indentation. Apart from this it looks good.
>>> If you just restore the indentation I'm okay (you don't need to
>>> respin the webrev for that).
>>>
>>> /Magnus
>>>
>>>>
>>>> /Erik
>>>>
>>>> On 2015-11-10 14:49, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-10 11:39, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-09 19:33, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> As a stepping stone in the hotspot makefile conversion, I have
>>>>>>> broken out the serviceability agent separately and converted it
>>>>>>> into proper modular build-infra makefiles. Doing this conversion
>>>>>>> separately has some value on its own by reducing the special
>>>>>>> cases currently needed for building the jdk.hotspot.agent module.
>>>>>>>
>>>>>>> The current SA java build compiles with the boot jdk javac with
>>>>>>> -source/-target JDK N-1. The proposed change instead builds SA
>>>>>>> with the interim-langtools javac for JDK N, like all the rest of
>>>>>>> the JDK classes.
>>>>>>>
>>>>>>> There is already a bug filed for reorganizing the source of the
>>>>>>> SA agent to conform to the Jigsaw style modular source layout:
>>>>>>> JDK-8067194, so I have left the source in its current location.
>>>>>>>
>>>>>>> The native compilation and linking has been changed to base the
>>>>>>> flags used on what configure sets up for the other JDK libraries.
>>>>>>> This has caused some changes in flag usage. From what I can tell,
>>>>>>> nothing important is different however. I have run the relevant
>>>>>>> jtreg tests on all OSes to verify that it still works. Some of
>>>>>>> the differences include:
>>>>>>>
>>>>>>> * Linux: "-Xlinker z -Xlinker defs" was added to LDFLAGS, which
>>>>>>> causes link failure unless "-ldl" was also added to LIBS.
>>>>>>> * Solaris: More warnings activated through "+w" caused need for
>>>>>>> disabling some warnings. I fixed one warning instance which was
>>>>>>> trivial (int->size_t), but couldn't figure out the rest. I will
>>>>>>> file a followup bug for fixing those if this patch is accepted.
>>>>>>>
>>>>>>> I tried to mimic the current behavior of excluding SA on
>>>>>>> linux-ppc and zero that Volker added a while back. Now it's
>>>>>>> excluded on the module level instead so that jdk.hotspot.agent
>>>>>>> isn't even built in that case. It would be good if this could be
>>>>>>> tested.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142336
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>>>>>>
>>>>>> A few remarks:
>>>>>>
>>>>>> * Could you please document the new DISABLED_WARNINGS_CXX and
>>>>>> DISABLED_WARNINGS_C in the function header?
>>>>>>
>>>>>> * I believe the use of {} here was to signify a set. When only
>>>>>> jsig remains, it just looks strange:
>>>>>> -# SYMFLAG is used by {jsig,saproc}.make
>>>>>> +# SYMFLAG is used by {jsig}.make
>>>>>>
>>>>>> * The logic of setting up "--hash-style=both" is already done in
>>>>>> configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if
>>>>>> you include the LDFLAGS_JDKLIB variable.
>>>>>
>>>>> Also, SA_WINDOWS_LDFLAGS is read but never defined.
>>>>>
>>>>> /Magnus
>>>>
>>>
>>
> 


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

From goetz.lindenmaier at sap.com  Tue Nov 24 11:38:02 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 24 Nov 2015 11:38:02 +0000
Subject: RFR(L): 8143125: [aix] Further Developments for AIX
In-Reply-To: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
References: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap>

Hi Thomas, 

I looked at your change.  It?s good we get these improvements into 
openJDK.  But I think we should skip some stuff that's not (yet?) 
used there.  I'll sponsor the change. Details:

libperfstat_aix.cpp:

What do you need 
static fun_perfstat_partition_total_t g_fun_perfstat_partition_total = NULL;
static fun_perfstat_wpar_total_t    g_fun_perfstat_wpar_total = NULL;
static fun_wpar_getcid_t            g_fun_wpar_getcid = NULL;
for? I think they are never used.

libperfstat_aix.cpp:161
We support AIX 5.3 with xlC12 only. I think we need not add the older
#defines to openJDK. Also, the comment should be adapted and not mention xlc8 etc.
Also, there are datastructures for 5.2 which can be removed.

Where is this used?
bool libperfstat::get_wparinfo(wparinfo_t* pwi)
Do we need it if it's not used?

libperfstat.hpp:835
I would remove these prototypes commented out.

loadlib_aix.cpp
Why do you do these changes? Please revert them.

os_aix.hpp:219
What's this good for?
get_brk_at_startup()
get_lowest_allocation_above_brk()

os_aix.hpp:259
What's this good for?
parse_qsyslib_path()

os_aix.cpp:410
Why do you move query_multipage_support()?

os_aix.inline.hpp:164
Why do you reverse the order of the functions here?
The old order is the same as in the related files os_linux.inline.hpp etc.

Best regards,
  Goetz.



> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Thomas St?fe
> Sent: Freitag, 20. November 2015 11:49
> To: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers
> Subject: RFR(L): 8143125: [aix] Further Developments for AIX
> 
> Hi all,
> 
> please review and sponsor these AIX only changes. Basically, with this
> change we bring the OpenJDK AIX hotspot port up to speed with the
> developments done at SAP in the recent months.
> 
> For a more detailled number of changes and fixes, please refer to the bug
> description.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143125
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8143125-
> Further/webrev.00/webrev/index.html
> 
> Kind Regards, Thomas

From david.holmes at oracle.com  Tue Nov 24 12:58:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2015 22:58:00 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <565442C6.2070004@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
	<5653C930.5090602@oracle.com> <565442C6.2070004@oracle.com>
Message-ID: <56545ED8.2000002@oracle.com>

Thanks Bertrand!

David

On 24/11/2015 8:58 PM, Bertrand Delsart wrote:
> On 24/11/2015 03:19, David Holmes wrote:
>> Sorry about that:
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>
> Approved.
>
> Regards,
>
> Bertrand (not a Reviewer).
>
>>
>> David
>>
>> On 24/11/2015 11:17 AM, David Holmes wrote:
>>> Updated webrev:
>>>
>>> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>>
>>> Only change is in macroAssembler_x86.cpp
>>>
>>> Thanks,
>>> David
>>>
>>> On 24/11/2015 7:42 AM, David Holmes wrote:
>>>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>>> On 23/11/2015 13:27, David Holmes wrote:
>>>>>> Hi Bertrand,
>>>>>>
>>>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Overall looks good.
>>>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>>>
>>>>>>> One doubt, in case this has not been discussed before.
>>>>>>>
>>>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>>>> but it
>>>>>>> seems that there are some stack alignment constraints on runtime
>>>>>>> calls,
>>>>>>> at least for some x86_64 ABIs.
>>>>>>>
>>>>>>> Some of the x86 MacroAssembler::get_thread implementations had
>>>>>>> code to
>>>>>>> align the stack before calling pthread_getspecific. See for instance
>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>>>>> fragment:
>>>>>>
>>>>>> -   push(r10);
>>>>>> -   // XXX
>>>>>> -   mov(r10, rsp);
>>>>>> -   andq(rsp, -16);
>>>>>> -   push(r10);
>>>>>>
>>>>>> I'm not at all clear what that is doing - and if it somehow changes
>>>>>> the
>>>>>> alignment wouldn't something need to be fixed up when popping the
>>>>>> previous values ??
>>>>>>
>>>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>>>
>>>>> On some platforms, SP may have to be aligned on a 16 bytes boundary
>>>>> when
>>>>> calling another method.
>>>>
>>>> Okay - that seems to be an x64 ABI requirement based on other code in
>>>> MacroAssembler. The reason it is missing in the Solaris code is because
>>>> I already removed it in the earlier changes that were done on Solaris:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>>
>>>> and nobody picked it up. :(
>>>>
>>>> That said, the absence of this code has not caused any problems so
>>>> presumably we are normally aligned.
>>>>
>>>>> After having pushed what needed to be saved, the code above rounds SP
>>>>> down and saves the old value. It will then also push r11, which
>>>>> results
>>>>> in the expected alignment.
>>>>>
>>>>> The conterpart, after the VM call, is the:
>>>>>   pop(r11);
>>>>>   pop(rsp);
>>>>
>>>> I had assumed this extra manipulation was related to pushing the arg
>>>> for
>>>> the call.
>>>>
>>>>>>> This alignment is no longer performed in the new (shared)
>>>>>>> implementation
>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>>>> separate
>>>>>>> path for x86_64. Did we really need the alignment for linux x86_64
>>>>>>> and
>>>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>>>
>>>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>>>> should
>>>>>>> not be expensive since we call get_thread rarely for x86_64
>>>>>>> (result is
>>>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>>>> ifdef so
>>>>>>> as to explicitly deactivate the alignment on some platforms
>>>>>>> (solaris_x86_64 ?)
>>>>>>
>>>>>> I don't have enough knowledge to even begin to comment on this. I
>>>>>> will
>>>>>> have to rely on our x86_64 macroassembler experts to explain the old
>>>>>> code and what the requirements are.
>>>>>
>>>>> OK. This means that the alignment was not removed purposefully.
>>>>>
>>>>> In that case, you must either keep the per platform code x86_64 (since
>>>>> it was not identical for all platforms) or use the safest version,
>>>>> with
>>>>> the additional
>>>>>
>>>>>     // XXX
>>>>>     mov(r10, rsp);
>>>>>     andq(rsp, -16);
>>>>>     push(r10);
>>>>>
>>>>> before the push(r11) and with the
>>>>>
>>>>>     pop(rsp);
>>>>>
>>>>> after the pop(r11). It should work on all x86_64 platforms.
>>>>
>>>> Right, I will add this back to the code - and replace the
>>>> meaningless //
>>>> XXX with an actual comment!
>>>>
>>>> Many thanks,
>>>> David
>>>> -----
>>>>
>>>>> FYI, there is another way to do the alignment, based on the fact that
>>>>> we are at least aligned on 8 bytes (see
>>>>> MacroAssembler::call_VM_leaf_base). I assume that this second
>>>>> version is
>>>>> more efficient (particularly thanks to specilative branches) but it
>>>>> might be safer/simpler to continue using andq in get_thread.
>>>>>
>>>>> Bertrand.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Bertrand.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>>>> After all the preliminary discussions here are final proposed
>>>>>>>> changes:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>>>
>>>>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>>>
>>>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>>>> appeal to
>>>>>>>> our Code Deletion Engineer's. We implement Thread::current()
>>>>>>>> using a
>>>>>>>> compiler/language-based thread-local variable eg:
>>>>>>>>
>>>>>>>>   static __thread Thread *_thr_current;
>>>>>>>>
>>>>>>>>   inline Thread* Thread::current() {
>>>>>>>>     return _thr_current;
>>>>>>>>   }
>>>>>>>>
>>>>>>>> with an appropriate setter of course. By doing this we can
>>>>>>>> completely
>>>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and
>>>>>>>> the
>>>>>>>> associated os::thread_local_storage* calls.
>>>>>>>>
>>>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>>>> practice) we
>>>>>>>> need a fallback library-based solution as used today. For this we
>>>>>>>> use a
>>>>>>>> very simple ThreadLocalStorage class and an implementation thereof
>>>>>>>> for
>>>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>>>>> While these library routines are not guaranteed async-signal-safe,
>>>>>>>> they
>>>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>>>
>>>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>>>> where
>>>>>>>> compiler-based thread locals are not supported (as will be
>>>>>>>> needed in
>>>>>>>> the
>>>>>>>> Mobile project). This is enabled at build time by defining
>>>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>>>
>>>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for
>>>>>>>> Thomas
>>>>>>>> Stuefe for testing PPC and AIX.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>>   - JPRT (core platforms)
>>>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>>>   - vm.runtime (core platforms)
>>>>>>>>
>>>>>>>> Performance:
>>>>>>>>   - still TBD - this is proving to be extremely difficult. If
>>>>>>>> anyone
>>>>>>>> has
>>>>>>>> any simple to run microbenchmarks to suggest I'd give them a try
>>>>>>>> as a
>>>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>>>> benchmarking.
>>>>>>>>
>>>>>>>> Footprint:
>>>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>
>

From dmitry.dmitriev at oracle.com  Tue Nov 24 14:30:18 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 24 Nov 2015 17:30:18 +0300
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <564F8ADB.9090008@oracle.com>
References: <564F8ADB.9090008@oracle.com>
Message-ID: <5654747A.3000908@oracle.com>

Hi Sangheon,

Looks good to me! Thank you for fixing that. I hope that enhancement 
will be pushed today(currently in JPRT queue), so please update your 
patch after that!

Thanks,
Dmitry

On 21.11.2015 0:04, sangheon.kim wrote:
> Hi all,
>
> Could I have a couple of reviews for this change to add explicit 
> 'range' for flags?
>
> Previously, we added 'range' when it is needed to avoid assert/crash 
> but now explicit 'range' are needed for all flags.
> All flags should have 'range' or 'constraint' at least.
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
> Testing: JPRT, RBT 
> (hotspot/test/:hotspot_all,testlist,noncolo.testlist 
> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for embedded
>
> * Summary
> 1. Added 3 new constraint functions.
>    1) HeapBaseMinAddress: Added to avoid an overflow after align up 
> and this flag makes hang up without constraint function. (newly added 
> as a part of GC work)
>    2) TLABWasteIncrement: Without this constraint function we don't 
> have problems (even many GCs happen). But added to avoid an overflow 
> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also 
> separate CR for this overflow ( JDK-8143352 ).
>    3) NUMAInterleaveGranularity: Added to avoid an overflow after 
> align up.
>
> 2. Some flags have narrower range than their type.
>    1) Here's the reason why some flags should have different range. 
> (same order from globals.hpp)
> {flag type} {flag name}: (range), {comment}
> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), 
> max_uintx), there is a comment at numa_interleaving_init() that this 
> flag should be larger than vm_allocation_granularity().
> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as 
> used for multiplication
> uintx CMS_FLSPadding: (0, max_juint), used to set a function which has 
> 'unsigned int' type input parameter.
> uintx CMS_SweepPadding: (0, max_juint), used to set a function which 
> has 'unsigned int' type input parameter.
> intx CMSWaitDuration: (min_jint, max_jint), used to set a function 
> which has 'long' type input parameter.
> uintx PausePadding: (0, max_juint), used to set a function which has 
> 'unsigned int' type input parameter.
> uintx PromotedPadding: (0, max_juint), used to set a function which 
> has 'unsigned int' type input parameter.
> uintx SurvivorPadding: (0, max_juint), used to set a function which 
> has 'unsigned int' type input parameter.
> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag 
> is divided by 100 I assume this is percentage.
> uintx GCTimeRatio: (0, max_juint), used to set a function which has 
> 'unsigned int' type input parameter.
> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch* 
> flags should have same upper limit and looking at their related codes 
> 'max_jint' seems appropriate ( no problem with 'max_jint' during 
> testing). However, as Prefetch::read/write() needs 'intx', 'intx' also 
> seems good but we have to fix some codes (maybe including generated 
> codes).
> uintx CPUForCMSThread: (0, max_juint), used to set a function which 
> has 'unsigned int' type input parameter.
> uintx ProcessDistributionStride: (0, max_juint), used to set uint 
> variable and used 'for loop' which has uint increment. i.e. for (uint 
> i=0; i<ProcessDistributionStride; i++)
> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 
> 'increment for loop()' as max value and the increment is uint.
> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for 
> loop()' as max value and the increment is uint.
> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value 
> of uint type function and for division. i.e. uint 
> GCTLABConfiguration::tlab_refill_waste_limit()() { return 
> TLABRefillWasteFraction; }
> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only 
> use " if (a !=0, >0, >1)".
> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only 
> use " if (a !=0, >0, >1)".
> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use 
> " if (a !=0, >0)".
> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned int'
>
> (g1_globals.hpp)
> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) 
> type variable.
>
> 3. Excluded flags from TestOptionsWithRanges.java
> 1) Memory and thread related flags: tests for these flags will consume 
> too many resources from the system.
> 2) VMThreadStackSize: range work for this flag is not included in this 
> patch but I faced OOME several times, so excluded.
>
> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] 
> TestOptionsWithRanges: allow excluding only a subset of tested values 
> specified for a flag) next time.
>
> Thanks,
> Sangheon
>
>
>


From sangheon.kim at oracle.com  Tue Nov 24 14:37:41 2015
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Tue, 24 Nov 2015 06:37:41 -0800
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <5654747A.3000908@oracle.com>
References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com>
Message-ID: <56547635.9060808@oracle.com>

Hi Dmitry,

Thank you for the review!
Sure I will update my patch related to your enhancement.

Thanks,
Sangheon


On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
> Hi Sangheon,
>
> Looks good to me! Thank you for fixing that. I hope that enhancement 
> will be pushed today(currently in JPRT queue), so please update your 
> patch after that!
>
> Thanks,
> Dmitry
>
> On 21.11.2015 0:04, sangheon.kim wrote:
>> Hi all,
>>
>> Could I have a couple of reviews for this change to add explicit 
>> 'range' for flags?
>>
>> Previously, we added 'range' when it is needed to avoid assert/crash 
>> but now explicit 'range' are needed for all flags.
>> All flags should have 'range' or 'constraint' at least.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>> Testing: JPRT, RBT 
>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist 
>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for 
>> embedded
>>
>> * Summary
>> 1. Added 3 new constraint functions.
>>    1) HeapBaseMinAddress: Added to avoid an overflow after align up 
>> and this flag makes hang up without constraint function. (newly added 
>> as a part of GC work)
>>    2) TLABWasteIncrement: Without this constraint function we don't 
>> have problems (even many GCs happen). But added to avoid an overflow 
>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also 
>> separate CR for this overflow ( JDK-8143352 ).
>>    3) NUMAInterleaveGranularity: Added to avoid an overflow after 
>> align up.
>>
>> 2. Some flags have narrower range than their type.
>>    1) Here's the reason why some flags should have different range. 
>> (same order from globals.hpp)
>> {flag type} {flag name}: (range), {comment}
>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), 
>> max_uintx), there is a comment at numa_interleaving_init() that this 
>> flag should be larger than vm_allocation_granularity().
>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as 
>> used for multiplication
>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which 
>> has 'unsigned int' type input parameter.
>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which 
>> has 'unsigned int' type input parameter.
>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function 
>> which has 'long' type input parameter.
>> uintx PausePadding: (0, max_juint), used to set a function which has 
>> 'unsigned int' type input parameter.
>> uintx PromotedPadding: (0, max_juint), used to set a function which 
>> has 'unsigned int' type input parameter.
>> uintx SurvivorPadding: (0, max_juint), used to set a function which 
>> has 'unsigned int' type input parameter.
>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag 
>> is divided by 100 I assume this is percentage.
>> uintx GCTimeRatio: (0, max_juint), used to set a function which has 
>> 'unsigned int' type input parameter.
>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch* 
>> flags should have same upper limit and looking at their related codes 
>> 'max_jint' seems appropriate ( no problem with 'max_jint' during 
>> testing). However, as Prefetch::read/write() needs 'intx', 'intx' 
>> also seems good but we have to fix some codes (maybe including 
>> generated codes).
>> uintx CPUForCMSThread: (0, max_juint), used to set a function which 
>> has 'unsigned int' type input parameter.
>> uintx ProcessDistributionStride: (0, max_juint), used to set uint 
>> variable and used 'for loop' which has uint increment. i.e. for (uint 
>> i=0; i<ProcessDistributionStride; i++)
>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 
>> 'increment for loop()' as max value and the increment is uint.
>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for 
>> loop()' as max value and the increment is uint.
>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value 
>> of uint type function and for division. i.e. uint 
>> GCTLABConfiguration::tlab_refill_waste_limit()() { return 
>> TLABRefillWasteFraction; }
>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only 
>> use " if (a !=0, >0, >1)".
>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only 
>> use " if (a !=0, >0, >1)".
>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use 
>> " if (a !=0, >0)".
>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned 
>> int'
>>
>> (g1_globals.hpp)
>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) 
>> type variable.
>>
>> 3. Excluded flags from TestOptionsWithRanges.java
>> 1) Memory and thread related flags: tests for these flags will 
>> consume too many resources from the system.
>> 2) VMThreadStackSize: range work for this flag is not included in 
>> this patch but I faced OOME several times, so excluded.
>>
>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] 
>> TestOptionsWithRanges: allow excluding only a subset of tested values 
>> specified for a flag) next time.
>>
>> Thanks,
>> Sangheon
>>
>>
>>
>


From konstantin.shefov at oracle.com  Tue Nov 24 14:48:43 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 24 Nov 2015 17:48:43 +0300
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <564C5CC4.5070003@oracle.com>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
	<1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
	<564C5CC4.5070003@oracle.com>
Message-ID: <565478CB.2030005@oracle.com>

Hello

Please, review modified webrev.

I have added methods
getNameAndTypeRefIndexAt(int index) - to get name and type entry index 
from a method, field or indy entry index;
getClassRefIndexAt(int index) - to get class entry index from a method 
or field entry index;

I removed previously added method
getInvokedynamicRefInfoAt(int index) - as it is no more needed now.

New webrev:
Webrev hotspot: 
http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01
Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01

Thanks
-Konstantin

On 11/18/2015 02:11 PM, Konstantin Shefov wrote:
> Remi,
>
> Thanks for reviewing. Your suggestion sounds sensibly.
> May be it also has sense to make a method 
> "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type 
> entry index for methods also.
>
> -Konstantin
>
> On 11/18/2015 12:04 AM, Remi Forax wrote:
>> Hi Konstantin,
>> Technically, getInvokedynamicRefInfoAt should be 
>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the 
>> nameAndType value of the InvokeDynamicRef.
>>
>> In term of API, I think it's better to decompose the API, i.e. to 
>> have a method
>>    int getInvokedynamicRefNameAndTypeIndex(int index)
>> that returns the nameAndType index and to reuse 
>> getNameAndTypeRefInfoAt(index) to get the corresponding array of 
>> Strings.
>>
>> cheers,
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Christian Thalinger" <christian.thalinger at oracle.com>
>>> ?: "Konstantin Shefov" <konstantin.shefov at oracle.com>
>>> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, 
>>> core-libs-dev at openjdk.java.net
>>> Envoy?: Lundi 16 Novembre 2015 23:41:45
>>> Objet: Re: RFR [9] 8141615: Add new public methods to 
>>> sun.reflect.ConstantPool
>>>
>>> [CC'ing core-libs-dev]
>>>
>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>>>> <konstantin.shefov at oracle.com> wrote:
>>>>
>>>> Hello
>>>>
>>>> Please review an enhancement to add three new methods to
>>>> sun.reflect.ConstantPool class.
>>>> The following methods are suggested:
>>>>
>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string
>>>> representation of name and type from a NameAndType constant pool entry
>>>> with the specified index
>>>>
>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string
>>>> representation of name and type from an InvokeDynamic constant pool 
>>>> entry
>>>> with the specified index
>>>>
>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a 
>>>> constant
>>>> pool entry with the specified index
>>>>
>>>> These three methods could be used for testing API working with 
>>>> constant
>>>> pool, e.g. JVMCI.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
>>>> Webrev hotspot:
>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
>>>>
>>>> Thanks
>>>> -Konstantin
>>>
>


From daniel.daugherty at oracle.com  Tue Nov 24 16:26:03 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 24 Nov 2015 09:26:03 -0700
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <56535077.9090605@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <564A7C41.7020708@oracle.com>
	<564E1090.2060500@cs.oswego.edu> <564E849E.6020201@oracle.com>
	<05C4C616-2085-420C-B3D2-2FF47DF66131@oracle.com>
	<FACEF79A-72E2-4B34-B225-96582FB83F4A@oracle.com>
	<56535077.9090605@oracle.com>
Message-ID: <56548F9B.1000507@oracle.com>

On 11/23/15 10:44 AM, Frederic Parain wrote:
> Karen,
>
> Thank you for your review, my answers are in-lined below.
>
> New Webrevs (including some fixes suggested by Paul Sandoz):
>
> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/hotspot/

src/cpu/sparc/vm/frame_sparc.cpp
     (old) L635:   if (fp() - sp() > 1024 + 
m->max_stack()*Interpreter::stackElementSize) {
     (new) L635:   if (fp() - unextended_sp() > 1024 + 
m->max_stack()*Interpreter::stackElementSize) {
         This looks like a bug fix independent of this fix.


src/share/vm/runtime/thread.hpp
     L953:   intptr_t*        _reserved_stack_activation;
     L1382:   intptr_t* reserved_stack_activation() const { return 
_reserved_stack_activation; }
     L1383:   void      set_reserved_stack_activation(intptr_t* addr) {

         I was expecting this type to be 'address' instead of 'intptr_t*'.

         Update: I've gone back through the changes and I still don't
             see a reason that this is 'intptr_t*'.

     L1341:     { return stack_yellow_zone_base();}
         '{' should be at the end of the previous line.
         Missing space after ';'.

     L1343:     { return StackReservedPages * os::vm_page_size(); }
         '{' should be at the end of the previous line.

src/share/vm/runtime/thread.inline.hpp
     No comments.

src/share/vm/runtime/thread.cpp
     L307:     ((JavaThread*) 
this)->set_reserved_stack_activation((intptr_t*)stack_base());
     L1561:     if (reserved_stack_activation() != 
(intptr_t*)stack_base()) {
     L1562: set_reserved_stack_activation((intptr_t*)stack_base());
     L1565: set_reserved_stack_activation((intptr_t*)stack_base());

         I was expecting this type to be 'address' instead of 'intptr_t*'.

         Update: Still don't know why.

     L2543:   // The base notation is from the stacks point of view, 
growing downward.
     L2565:   // The base notation is from the stacks point of view, 
growing downward.
         Typo: "stacks point of view" -> "stack's point of view"

     L2552:   } else {
     L2553:     warning("Attempt to guard stack reserved zone failed.");
     L2554:   }
     L2555:   enable_register_stack_guard();

         Should enable_register_stack_guard() be called when we issued
         the warning on L2553?

     L2571:   } else {
     L2572:     warning("Attempt to unguard stack reserved zone failed.");
     L2573:   }
     L2574:   disable_register_stack_guard();

         Should disable_register_stack_guard() be called when we issued
         the warning on L2572?

src/share/vm/runtime/sharedRuntime.hpp
     No comments.

src/share/vm/runtime/sharedRuntime.cpp
     L488:       if (thread->reserved_stack_activation() != (intptr_t*) 
thread->stack_base()) {
     L489: thread->set_reserved_stack_activation((intptr_t*) 
thread->stack_base());
     L2954: 
thread->set_reserved_stack_activation((intptr_t*)thread->stack_base());

         I was expecting this type to be 'address' instead of 'intptr_t*'.

         Update: Still don't know why.

     L784:     java_lang_Throwable::set_message(exception_oop,
     L785: Universe::delayed_stack_overflow_error_message());
         Wrong indent; this should line up under the 'e' after the '('.

     L2976:       if (fr.is_interpreted_frame()) {
     L2978:         prv_fr = fr;
     L2982:         prv_fr = fr;
         This line is in both branches of the if-statement on L2976.
         Is there a reason not to save prv_fr before L2976?

     L2996          continue;
         Wrong indent; needs one more space.

     L2958:   frame activation;
     L3013:   return activation;
         The return on L3013 can return a default constructed 'frame'.
         Is that default safe to return here?


src/share/vm/runtime/deoptimization.cpp
     No comments.

src/share/vm/runtime/javaCalls.cpp
     No comments.

src/share/vm/runtime/os.hpp
     No comments.

src/share/vm/runtime/os.cpp
     No comments.

src/os/bsd/vm/os_bsd.hpp
     L109:    static bool get_frame_at_stack_banging_point(JavaThread* 
thread, ucontext_t* uc, frame* fr);
         Wrong indent; needs one less space.

src/os/bsd/vm/os_bsd.cpp
     No comments.

src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
     L322: // For Forte Analyzer AsyncGetCallTrace profiling support - 
thread
     L323: // is currently interrupted by SIGPROF.
         Now fetch_frame_from_ucontext() is also used for stack overflow
         signal handling.

     L379:     assert(fr->safe_for_sender(thread), "Safety check");
     L380:     if (!fr->is_first_java_frame()) {
     L381:       *fr = fr->java_sender();
         The assert() on L379 should be before the java_sender()
         call on L381.

src/os/linux/vm/os_linux.hpp
     No comments.

src/os/linux/vm/os_linux.cpp
     L1902:           jt->stack_guards_enabled()) {       // No pending 
stack overflow exceptions
         This line's comment used to align with the previous line's comment.
         Can you move the previous line's comment to align with this one?

src/os_cpu/linux_x86/vm/os_linux_x86.cpp
     L135: // For Forte Analyzer AsyncGetCallTrace profiling support - 
thread
     L136: // is currently interrupted by SIGPROF.
         Now fetch_frame_from_ucontext() is also used for stack overflow
         signal handling.

     L192:     assert(fr->safe_for_sender(thread), "Safety check");
     L193:     if (!fr->is_first_java_frame()) {
     L194:       *fr = fr->java_sender();
         The assert() on L192 should be before the java_sender()
         call on L194.

src/os/solaris/vm/os_solaris.hpp
     No comments.

src/os/solaris/vm/os_solaris.cpp
     No comments.

src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
     L209: // For Forte Analyzer AsyncGetCallTrace profiling support - 
thread
     L210: // is currently interrupted by SIGPROF.
         Now fetch_frame_from_ucontext() is also used for stack overflow
         signal handling.

     L265:     assert(fr->safe_for_sender(thread), "Safety check");
     L266:     if (!fr->is_first_java_frame()) {
     L267:       *fr = fr->java_sender();
         The assert() on L265 should be before the java_sender()
         call on L267.

     L279:       //assert(fr->safe_for_sender(thread), "Safety check");
         Delete this line; you copied it to L282.

     L287   return true;
         Should this assert be added above this line?

         assert(fr->is_java_frame(), "Safety check");

src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
     L195: // For Forte Analyzer AsyncGetCallTrace profiling support - 
thread
     L196: // is currently interrupted by SIGPROF.
         Now fetch_frame_from_ucontext() is also used for stack overflow
         signal handling.

     L253:     assert(fr->safe_for_sender(thread), "Safety check");
     L254:     if (!fr->is_first_java_frame()) {
     L255:       *fr = fr->java_sender();
         The assert() on L253 should be before the java_sender()
         call on L255.

     L273:          *fr = fr->java_sender();
         Wrong indent; one too many spaces.

src/os/windows/vm/os_windows.hpp
     No comments.

src/os/windows/vm/os_windows.cpp
     L2364:     assert(fr->safe_for_sender(thread), "Safety check");
     L2365:     if (!fr->is_first_java_frame()) {
     L2366:       *fr = fr->java_sender();
The assert() on L2364 should be before the java_sender()
         call on L2366.

     L2387:   return true;
         Should this assert be added above this line?

         assert(fr->is_java_frame(), "Safety check");


src/share/vm/classfile/classFileParser.hpp
     No comments.

src/share/vm/classfile/vmSymbols.hpp
     No comments.

src/share/vm/classfile/classFileParser.cpp
     No comments.

src/share/vm/memory/universe.hpp
     No comments.

src/share/vm/memory/universe.cpp
     No comments.

src/share/vm/oops/method.hpp
     (old) L87:   u1 _flags;
     (new) L88:   u2 _flags;
         Ouch - just needed one more bit...

     L834:       return (_flags & _reserved_stack_access) != 0;
         Wrong indent; two fewer spaces.


src/share/vm/runtime/globals.hpp
     L3549: range(MIN_STACK_RESERVED_PAGES, 
(DEFAULT_STACK_RESERVED_PAGES+10))\
         Wrong indent; should line up below the double quote in
         the previous line.

src/share/vm/runtime/arguments.cpp
     No comments.

src/cpu/aarch64/vm/globals_aarch64.hpp
     No comments.

src/cpu/sparc/vm/globalDefinitions_sparc.hpp
     No comments.

src/cpu/sparc/vm/globals_sparc.hpp
     No comments.

src/cpu/x86/vm/globalDefinitions_x86.hpp
     No comments.

src/cpu/x86/vm/globals_x86.hpp
     No comments.

src/cpu/zero/vm/globals_zero.hpp
     No comments.


src/share/vm/interpreter/interpreterRuntime.hpp
     No comments.

src/share/vm/interpreter/interpreterRuntime.cpp
     L328  IRT_ENTRY(void, 
InterpreterRuntime::throw_delayed_StackOverflowError(JavaThread* thread))

         The regular throw_StackOverflowError() increments
         a counter:

         L313: Atomic::inc(&Exceptions::_stack_overflow_errors);

         Should this function increment the same counter or
         a different counter?

src/cpu/sparc/vm/interp_masm_sparc.cpp
     No comments.

src/cpu/x86/vm/interp_masm_x86.cpp
     No comments.

src/cpu/x86/vm/templateInterpreter_x86_32.cpp
     No comments.

src/cpu/x86/vm/templateInterpreter_x86_64.cpp
     No comments.

src/share/vm/runtime/stubRoutines.hpp
     No comments.

src/share/vm/runtime/stubRoutines.cpp
     No comments.

src/cpu/x86/vm/stubGenerator_x86_32.cpp
     No comments.

src/cpu/x86/vm/stubGenerator_x86_64.cpp
     No comments.

src/cpu/sparc/vm/stubGenerator_sparc.cpp
     No comments.


src/cpu/sparc/vm/macroAssembler_sparc.hpp
     L1423:   // Check for reserved stack access in method being exited 
(for the compilers)
         The X86 version says "for JIT compilers". I prefer "JIT".

src/cpu/sparc/vm/macroAssembler_sparc.cpp
     No comments.

src/cpu/x86/vm/macroAssembler_x86.hpp
     L643:   // Check for reserved stack access in method being exited 
(for JIT compilers)
         The SPARC version says "for the compilers".

src/cpu/x86/vm/macroAssembler_x86.cpp
     No comments.


src/share/vm/ci/ciMethod.hpp
     No comments.

src/share/vm/ci/ciMethod.cpp
     L95:   _has_reserved_stack_access   = 
h_m()->has_reserved_stack_access();
         Wrong indent; should be only one space before '='.

src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
     No comments.

src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
     No comments.

src/share/vm/c1/c1_Compilation.hpp
     No comments.

src/share/vm/c1/c1_Compilation.cpp
     No comments.

src/share/vm/c1/c1_GraphBuilder.cpp
     L3323:       if(callee->has_reserved_stack_access()) {
     L3336:       if(callee->has_reserved_stack_access()) {
     L3356:     if(callee->has_reserved_stack_access()) {
         Missing space between 'if' and '('.

src/share/vm/c1/c1_Runtime1.cpp
     No comments.


src/cpu/sparc/vm/sparc.ad
     No comments.

src/cpu/x86/vm/x86_32.ad
     L737:   size += 64; // added to support ReservedStackAccess
         Usually I hate literals like this, but this function has
         them in spades. :-(

src/cpu/x86/vm/x86_64.ad
     L960:   MacroAssembler _masm(&cbuf);
     L965:     MacroAssembler _masm(&cbuf);

         I think you can delete the _masm on L965.

src/share/vm/opto/compile.hpp
     No comments.

src/share/vm/opto/compile.cpp
     L675: _has_reserved_stack_access(target->has_reserved_stack_access()) {
         Wrong indent; should be a single space between ')' and '{'.

src/share/vm/opto/parse1.cpp
     No comments.


src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
     No comments.

src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
     No comments.

src/share/vm/jvmci/jvmciRuntime.cpp
     No comments.

src/share/vm/runtime/vmStructs.cpp
     No comments.

src/share/vm/trace/trace.xml
     No comments.

test/runtime/ReservedStack/ReservedStackTest.java
     L26:  * @run main/othervm -XX:-Inline 
-XX:CompileCommand=exclude,java/util/concurrent/locks/AbstractOwnableSynchronizer,setExclusiveOwnerThread 
ReservedStackTest

         Should the comma before 'setExclusiveOwnerThread' be a period?
         Perhaps both formats work...

     L47:  *    else
         Wrong indent; needs one more space before 'else'.

     L52:  * successfully update the status of the lock but he method
         Typo: 'update the' -> 'updates the'
         Typo: 'he method' -> 'the method'

     L60:  * first StackOverflowError is thrown, the Error is catched
         Typo: 'is catched' -> 'is caught'

     L61:  * and a few dozens frames are exited. Now the thread has
         Typo: 'a few dozens frames' -> 'a few dozen frames'

     L66:  * of its invocation, tries to acquire the next lock
         Typo: 'its invocation' -> 'its invocations'

     L81:  * stack to prevent false sharing. The test is using this
         Perhaps 'The test is using this'
              -> 'The test relies on this'

         to better match wording on L225-6.

     L82:  * to have different stack alignments and hit the targeted
         Grammar: 'and hit' -> 'when it hits'

     L102:  * exploit the  property that interpreter frames are (much)
         Typo: 'exploit' -> 'exploits'
         Delete extra space after 'the'.

     L123:         //LOCK_ARRAY_SIZE value
         Add a space after '//'.

     L188:         @jdk.internal.vm.annotation.ReservedStackAccess
         This isn't privileged code and -XX:-RestrictReservedStack
         isn't specified so what does this do?

     L201:               System.exit(-1);
         Wrong indent; needs two more spaces.


> http://cr.openjdk.java.net/~fparain/8046936/webrev.01/jdk/

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
     No comments.

src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
     No comments.

src/java.base/share/classes/jdk/internal/vm/annotation/ReservedStackAccess.java
     No comments.


Dan


>
> On 20/11/2015 19:44, Karen Kinnear wrote:
>> Frederic,
>>
>> Code review for web revs you sent out.
>> Code looks good. I am not as familiar with the compiler code.
>>
>> I realize you need to check in at least a subset of the 
>> java.util.concurrent changes for
>> the test to work, so maybe I should not have asked Doug about his 
>> preference there.
>> Sorry.
>>
>> I am impressed you found a way to make a reproducible test!
>>
>> Comments/questions:
>> 1. src/cpu/sparc/vm/interp_masm_sparc.cpp line 1144 ?is? -> ?if?
>
> Fixed
>
>> 2. IIRC, due to another bug with windows handling of our guard pages, 
>> this
>> is disabled for Windows. Would it be worth putting a comment in the
>> bug , 8067946, that once this is fixed, the reserved stack logic on 
>> windows
>> will need testing before enabling?
>
> More than testing, the implementation would have to be completed on
> Windows. I've added a comment to JDK-8067946.
>
>> 3. In get_frame_at_stack_banging_point on Linux, BSD and solaris_x86 if
>> this is in interpreter code, you explicitly return the Java sender
>> of the current frame. I was expecting to see that on Solaris_sparc 
>> and Windows
>> as well? I do see the assertion in caller that you do have a java frame.
>
> It doesn't make sense to check the current frame (no bytecode has been
> executed yet, so risk of partially executed critical section). I did the
> change but not for all platforms. This is now fixed for Solaris_SPARC
> and Windows too.
>
>> 4. test line 83 ?writtent? -> ?written?
>
> Fixed
>
>> 5. I like the way you set up the preallocated exception and then set 
>> the message - we may
>> try that for default methods in future.
>>
>> 6. I had a memory that you had found a bug in safe_for_sender - did 
>> you already check that in?
>
> I've fixed x86 platforms in JDK-8068655.
> I've piggybacked the SPARC fix to this webrev (frame_sparc.cpp:635),
> I had hoped it would have been silently accepted :-)
>
>
>> 7. I see the change in trace.xml, and I see an include added to 
>> SharedRuntime.cpp,
>> but I didn?t see where it was used - did I just miss it?
>
> trace.xml changes define a new event.
> This event is created at sharedRuntime.cpp::3006 and it is used
> in the next 3 lines.
>
> Thanks,
>
> Fred
>


From coleen.phillimore at oracle.com  Tue Nov 24 16:33:18 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Nov 2015 11:33:18 -0500
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <565478CB.2030005@oracle.com>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
	<1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
	<564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com>
Message-ID: <5654914E.1090603@oracle.com>


I have a couple preliminary comments.  First, there are no tests added 
with all this new functionality.  Tests should be added with the 
functionality changeset, not promised afterward.  Secondly, I do not 
like that JDK code knows the implementation details of the JVM's 
constant pool tags.  These should be only for internal use.  My third 
comment is that I haven't looked carefully at this constant pool 
implementation but it seems very unsafe if the class is redefined and 
relies on an implementation detail in the JVM that can change.   I will 
have more comments once I look more at the jvmti specification.

thanks,
Coleen

On 11/24/15 9:48 AM, Konstantin Shefov wrote:
> Hello
>
> Please, review modified webrev.
>
> I have added methods
> getNameAndTypeRefIndexAt(int index) - to get name and type entry index 
> from a method, field or indy entry index;
> getClassRefIndexAt(int index) - to get class entry index from a method 
> or field entry index;
>
> I removed previously added method
> getInvokedynamicRefInfoAt(int index) - as it is no more needed now.
>
> New webrev:
> Webrev hotspot: 
> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01
> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01
>
> Thanks
> -Konstantin
>
> On 11/18/2015 02:11 PM, Konstantin Shefov wrote:
>> Remi,
>>
>> Thanks for reviewing. Your suggestion sounds sensibly.
>> May be it also has sense to make a method 
>> "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type 
>> entry index for methods also.
>>
>> -Konstantin
>>
>> On 11/18/2015 12:04 AM, Remi Forax wrote:
>>> Hi Konstantin,
>>> Technically, getInvokedynamicRefInfoAt should be 
>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the 
>>> nameAndType value of the InvokeDynamicRef.
>>>
>>> In term of API, I think it's better to decompose the API, i.e. to 
>>> have a method
>>>    int getInvokedynamicRefNameAndTypeIndex(int index)
>>> that returns the nameAndType index and to reuse 
>>> getNameAndTypeRefInfoAt(index) to get the corresponding array of 
>>> Strings.
>>>
>>> cheers,
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Christian Thalinger" <christian.thalinger at oracle.com>
>>>> ?: "Konstantin Shefov" <konstantin.shefov at oracle.com>
>>>> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, 
>>>> core-libs-dev at openjdk.java.net
>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45
>>>> Objet: Re: RFR [9] 8141615: Add new public methods to 
>>>> sun.reflect.ConstantPool
>>>>
>>>> [CC'ing core-libs-dev]
>>>>
>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>>>>> <konstantin.shefov at oracle.com> wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> Please review an enhancement to add three new methods to
>>>>> sun.reflect.ConstantPool class.
>>>>> The following methods are suggested:
>>>>>
>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string
>>>>> representation of name and type from a NameAndType constant pool 
>>>>> entry
>>>>> with the specified index
>>>>>
>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns string
>>>>> representation of name and type from an InvokeDynamic constant 
>>>>> pool entry
>>>>> with the specified index
>>>>>
>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a 
>>>>> constant
>>>>> pool entry with the specified index
>>>>>
>>>>> These three methods could be used for testing API working with 
>>>>> constant
>>>>> pool, e.g. JVMCI.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
>>>>> Webrev hotspot:
>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
>>>>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
>>>>>
>>>>> Thanks
>>>>> -Konstantin
>>>>
>>
>


From karen.kinnear at oracle.com  Tue Nov 24 16:46:00 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 24 Nov 2015 11:46:00 -0500
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <56525823.6010506@cs.oswego.edu>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu>
	<BE21FC37-7FD4-4F22-91A6-855A29A5D71A@oracle.com>
	<56525823.6010506@cs.oswego.edu>
Message-ID: <C088E429-EE27-4848-AAAD-C5515A980122@oracle.com>

Doug,

I have been thinking about this more from the perspective of the original problem
we set out to solve, which was identified in the concurrent hash map usage, at the
time in the class loading logic. While the class loading logic has changed, I think we
have enough experience with this particular example and have studied
the code constructs sufficiently that there is value in checking in the small set of 
JDK changes that target that situation. I also think this gives a sample of
the kind of model in which this approach can be effective. In addition, having this small set of
changes provides the ability to test and ensure that the hotspot changes continue to
work.

So I would like to recommend that we go ahead and check in the hotspot changes
and the initial minimal set of j.u.c. updates as a way to put the new mechanism
in place so that the people with more domain expertise in the java.util.concurrent
libraries can experiment with the mechanism and add incremental improvements.

thanks,
Karen

> On Nov 22, 2015, at 7:04 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 11/20/2015 12:40 PM, Karen Kinnear wrote:
>> Totally appreciate the suggestion that the java.util.concurrent modifications
>> be done by folks with more domain expertise.
>> 
>> Would you have us incorporate the initial minimal set of j.u.c. updates or none
>> at all?
> 
> Sorry that I'm still in foot-drag mode on this.
> Reading David and Fred's exchanges reinforce my thoughts
> that there is no defensible rule or approach to
> use @ReservedStackAccess so as to add as little time and
> space as possible to reduce the occurrence of stuck
> resources as much as possible during StackOverflowError.
> 
> After googling "StackOverflowError java util concurrent" and seeing the
> range of situations that can be encountered, I don't even know
> which kinds of constructions to target.
> And I'm less sure whether using @ReservedStackAccess at all
> is better than doing nothing.
> 
> Maybe there is some decent empirical strategy, but I can't
> tell until hotspot support of @ReservedStackAccess is in place.
> So my vote is still to keep the JDK changes out for now.
> 
> -Doug
> 


From igor.ignatyev at oracle.com  Tue Nov 24 19:13:19 2015
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 24 Nov 2015 22:13:19 +0300
Subject: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting
Message-ID: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/
> 3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg

Hi,

Could you please review the webrev[0] for JEP 279[1]?

The scope of the JEP is an implementation of a library which uses jtreg timeout handler and observer extension points to collect information about environment in case of test failures (including timeouts) and about test processes in case of timeouts. This data is then presented together with the test failure to simplify analysis.

To make it easier to specify which tools should be run by the library on which platform when a test failure or timeout occurs, we use properties files to configure the library. Each platform family uses its own property file (named <family>.properties) and common.properties, which contains platform independent tools, such as jps. Using property files allows to easily extend the tools that are used to collect information on test failure or timeout in the future. See the JEP for a more thorough overview of the collected data. Currently, we are using the following tools:
- on all platforms[3]: jps, jstack, jmap, jinfo, jcmd
- on linux[4]: ps, pmap, lsof, lslocks, gdb, gcore, id, who, last, df, env, dmesg, sysctl, top, free, vmstat, netstat
- on solaris[5]: pgrep, pmap, pfiles, pstack, gcore, id, who, last, df, env, dmesg, prtconf, sysdef, swap, ps, top, vmstat, pagesize, netstat
- on mac[6]: pgrep, vmmap, heap, leaks, spindump, lldb, gcore, id, who, last, df, env, dmesg, sysctl, ps, top, vm_stat, netstat
- on windows[7]: wmic, pmap, handle, cdb, id, who, last, df, env, powershell, tasklist, ps, top, free, vmstat, openfiles, netstat

More information can be found in the JEP[1] and README[2].

The library integration into makefiles will be done later as the fix for JDK-8132962[8].

[0] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/
[1] https://bugs.openjdk.java.net/browse/JDK-8075621
[2] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/README.html
[3] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/common.properties.html
[4] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/linux.properties.html
[5] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/solaris.properties.html
[6] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/mac.properties.html
[7] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/windows.properties.html
[8] https://bugs.openjdk.java.net/browse/JDK-8132962

Thanks,
? Igor

From stevenschlansker at gmail.com  Tue Nov 24 18:16:40 2015
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Tue, 24 Nov 2015 10:16:40 -0800
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <C088E429-EE27-4848-AAAD-C5515A980122@oracle.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu>
	<BE21FC37-7FD4-4F22-91A6-855A29A5D71A@oracle.com>
	<56525823.6010506@cs.oswego.edu>
	<C088E429-EE27-4848-AAAD-C5515A980122@oracle.com>
Message-ID: <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com>


On Nov 24, 2015, at 8:46 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:

> Doug,
> 
> I have been thinking about this more from the perspective of the original problem
> we set out to solve

I apologize if this has already been considered -- but for a lot well designed systems,
occasional application failure is an expected fact of life and we design our HA around
this with automatic restarts and monitoring.

If it is so hard to detect / resolve a stack overflow situation, maybe one useful
mitigation of such awful situations (juc hangs, corrupt state, lost locks) would be to
actually treat a stack overflow as a fatal condition, much like OutOfMemoryError.

In fact, we configure all of our production servers with the moral equivalent of
-XX:OnOutOfMemoryError="kill -9 %p"
because once we are in a possibly inconsistent state, we would much rather nuke
it from orbit and start over.

Maybe introducing some new options, like
-XX:OnStackOverflowError=
or
-XX:TreatStackOverflowAsOOM (piggyback on the existing tunable above)
would allow end users to avoid the really bad behavior in a controllable way?


> , which was identified in the concurrent hash map usage, at the
> time in the class loading logic. While the class loading logic has changed, I think we
> have enough experience with this particular example and have studied
> the code constructs sufficiently that there is value in checking in the small set of 
> JDK changes that target that situation. I also think this gives a sample of
> the kind of model in which this approach can be effective. In addition, having this small set of
> changes provides the ability to test and ensure that the hotspot changes continue to
> work.
> 
> So I would like to recommend that we go ahead and check in the hotspot changes
> and the initial minimal set of j.u.c. updates as a way to put the new mechanism
> in place so that the people with more domain expertise in the java.util.concurrent
> libraries can experiment with the mechanism and add incremental improvements.
> 
> thanks,
> Karen
> 
>> On Nov 22, 2015, at 7:04 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>> 
>> On 11/20/2015 12:40 PM, Karen Kinnear wrote:
>>> Totally appreciate the suggestion that the java.util.concurrent modifications
>>> be done by folks with more domain expertise.
>>> 
>>> Would you have us incorporate the initial minimal set of j.u.c. updates or none
>>> at all?
>> 
>> Sorry that I'm still in foot-drag mode on this.
>> Reading David and Fred's exchanges reinforce my thoughts
>> that there is no defensible rule or approach to
>> use @ReservedStackAccess so as to add as little time and
>> space as possible to reduce the occurrence of stuck
>> resources as much as possible during StackOverflowError.
>> 
>> After googling "StackOverflowError java util concurrent" and seeing the
>> range of situations that can be encountered, I don't even know
>> which kinds of constructions to target.
>> And I'm less sure whether using @ReservedStackAccess at all
>> is better than doing nothing.
>> 
>> Maybe there is some decent empirical strategy, but I can't
>> tell until hotspot support of @ReservedStackAccess is in place.
>> So my vote is still to keep the JDK changes out for now.
>> 
>> -Doug
>> 
> 


From daniel.daugherty at oracle.com  Wed Nov 25 01:34:37 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 24 Nov 2015 18:34:37 -0700
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5653C930.5090602@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
	<5653C930.5090602@oracle.com>
Message-ID: <5655102D.20502@oracle.com>

On 11/23/15 7:19 PM, David Holmes wrote:
> Sorry about that:
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/

Please double check the copyright updates before you push.


make/aix/makefiles/xlc.make
     No comments.

src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
     No comments.

src/cpu/sparc/vm/macroAssembler_sparc.cpp
     No comments.

src/cpu/sparc/vm/stubRoutines_sparc.cpp
     No comments.

src/cpu/x86/vm/macroAssembler_x86.cpp
     No comments.

src/os/aix/vm/os_aix.cpp
     No comments.

src/os/aix/vm/os_aix.inline.hpp
     No comments.

src/os/bsd/vm/os_bsd.cpp
     No comments.

src/os/bsd/vm/os_bsd.inline.hpp
     No comments.

src/os/linux/vm/os_linux.cpp
     No comments.

src/os/linux/vm/os_linux.inline.hpp
     No comments.

src/os/solaris/vm/os_solaris.cpp
     No comments.

src/os/windows/vm/os_windows.cpp
     L5998:       os::os_exception_wrapper( (java_call_t)call_wrapper_dummy,
         Wrong indent; should only be two spaces.
         Please delete space after first '('.

     L5999:                                 NULL, NULL, NULL, NULL);
         Indent will have to change to match any fixes on previous line.

src/os/windows/vm/os_windows.hpp
     L127:   static inline void set_thread_ptr_offset( int offset ) {
         Please delete space after '(' and before ')'.

src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
     No comments.

src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp
     No comments.

src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
     No comments.

src/os_cpu/bsd_zero/vm/assembler_bsd_zero.cpp
     No comments.

src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
     No comments.

src/os_cpu/linux_aarch64/vm/assembler_linux_aarch64.cpp
     No comments.

src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp
     No comments.

src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp
     No comments.

src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp
     No comments.

src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
     No comments.

src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp
     No comments.

src/os_cpu/linux_x86/vm/os_linux_x86.cpp
     No comments.

src/os_cpu/linux_zero/vm/assembler_linux_zero.cpp
     No comments.

src/os_cpu/linux_zero/vm/os_linux_zero.cpp
     No comments.

src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
     No comments.

src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp
     No comments.

src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
     No comments.

src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp
     No comments.

src/os_cpu/windows_x86/vm/os_windows_x86.cpp
     No comments.

src/share/vm/code/nmethod.cpp
     No comments.

src/share/vm/gc/cms/concurrentMarkSweepThread.cpp
     No comments.

src/share/vm/gc/g1/g1HotCardCache.hpp
     No comments.

src/share/vm/gc/parallel/gcTaskThread.cpp
     No comments.

     Note: blank first line in this file (not your change)

src/share/vm/gc/shared/concurrentGCThread.cpp
     No comments.

src/share/vm/gc/shared/workgroup.cpp
     No comments.

src/share/vm/memory/allocation.cpp
     No comments.

src/share/vm/memory/resourceArea.hpp
     No comments.

src/share/vm/oops/oopsHierarchy.cpp
     No comments.

src/share/vm/precompiled/precompiled.hpp
     No comments.

src/share/vm/prims/jni.cpp
     L4312:   // If the thread has already been detached the operations 
is a no-op
         Typo: 'the operations is a' -> 'the operation is a'

src/share/vm/prims/jniCheck.cpp
     No comments.

src/share/vm/prims/jvmtiEnter.xsl
     No comments.

src/share/vm/prims/jvmtiExport.cpp
     L377:       JavaThread* current_thread = JavaThread::current();
         Wrong indent; two less spaces

src/share/vm/prims/jvmtiUtil.hpp
     No comments.

src/share/vm/runtime/interfaceSupport.cpp
     No comments.

src/share/vm/runtime/interfaceSupport.hpp
     No comments.

src/share/vm/runtime/java.cpp
     No comments.

src/share/vm/runtime/mutex.cpp
     No comments.

src/share/vm/runtime/mutexLocker.cpp
     No comments.

src/share/vm/runtime/os.cpp
     No comments.

src/share/vm/runtime/os.hpp
     No comments.

src/share/vm/runtime/sharedRuntime.hpp
     No comments.

src/share/vm/runtime/thread.cpp
     No comments.

src/share/vm/runtime/thread.hpp
     No comments.

src/share/vm/runtime/thread.inline.hpp
     No comments.

src/share/vm/runtime/threadLocalStorage.hpp
     L37: // Platforms without compiler-based TLS (ie __thread 
storage-class modifier)
         Typo: 'ie' -> 'i.e.'

src/share/vm/runtime/vmThread.cpp
     No comments.

src/share/vm/runtime/vm_operations.cpp

     (old) L396:   Thread * thr_cur = ThreadLocalStorage::get_thread_slow();
     (new) L396:   Thread * thr_cur = Thread::current();

         I think this should be 'current_or_null()' like L374.

src/share/vm/utilities/debug.cpp
     No comments.

src/share/vm/utilities/events.cpp
     No comments.

src/share/vm/utilities/events.hpp
     No comments.

src/share/vm/utilities/globalDefinitions_gcc.hpp
     No comments.

src/share/vm/utilities/globalDefinitions_sparcWorks.hpp
     No comments.

src/share/vm/utilities/globalDefinitions_visCPP.hpp
     No comments.

src/share/vm/utilities/globalDefinitions_xlc.hpp
     No comments.

src/share/vm/utilities/ostream.cpp
     No comments.

src/os/posix/vm/threadLocalStorage_posix.cpp
     L38:     ThreadLocalStorage::set_thread((Thread*) p);
         Wrong indent; should be two spaces.

src/os/windows/vm/threadLocalStorage_windows.cpp
     L54:   assert(current != 0 || GetLastError() == ERROR_SUCCESS, '
         'current != 0' -> 'current != NULL'
         jcheck will complain about the blank at the end of this line

     L62:   assert(res, "TlsSetValue failed with error code: %lu", 
GetLastError());
         jcheck will complain about the blank at the end of this line

src/os_cpu/linux_aarch64/vm/threadLS_linux_aarch64.s
     No comments.

No comments on the deleted files.


Dan


>
> David
>
> On 24/11/2015 11:17 AM, David Holmes wrote:
>> Updated webrev:
>>
>> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>
>> Only change is in macroAssembler_x86.cpp
>>
>> Thanks,
>> David
>>
>> On 24/11/2015 7:42 AM, David Holmes wrote:
>>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>> On 23/11/2015 13:27, David Holmes wrote:
>>>>> Hi Bertrand,
>>>>>
>>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Overall looks good.
>>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>>
>>>>>> One doubt, in case this has not been discussed before.
>>>>>>
>>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>>> but it
>>>>>> seems that there are some stack alignment constraints on runtime
>>>>>> calls,
>>>>>> at least for some x86_64 ABIs.
>>>>>>
>>>>>> Some of the x86 MacroAssembler::get_thread implementations had 
>>>>>> code to
>>>>>> align the stack before calling pthread_getspecific. See for instance
>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>>>> fragment:
>>>>>
>>>>> -   push(r10);
>>>>> -   // XXX
>>>>> -   mov(r10, rsp);
>>>>> -   andq(rsp, -16);
>>>>> -   push(r10);
>>>>>
>>>>> I'm not at all clear what that is doing - and if it somehow 
>>>>> changes the
>>>>> alignment wouldn't something need to be fixed up when popping the
>>>>> previous values ??
>>>>>
>>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>>
>>>> On some platforms, SP may have to be aligned on a 16 bytes boundary 
>>>> when
>>>> calling another method.
>>>
>>> Okay - that seems to be an x64 ABI requirement based on other code in
>>> MacroAssembler. The reason it is missing in the Solaris code is because
>>> I already removed it in the earlier changes that were done on Solaris:
>>>
>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>
>>> and nobody picked it up. :(
>>>
>>> That said, the absence of this code has not caused any problems so
>>> presumably we are normally aligned.
>>>
>>>> After having pushed what needed to be saved, the code above rounds SP
>>>> down and saves the old value. It will then also push r11, which 
>>>> results
>>>> in the expected alignment.
>>>>
>>>> The conterpart, after the VM call, is the:
>>>>   pop(r11);
>>>>   pop(rsp);
>>>
>>> I had assumed this extra manipulation was related to pushing the arg 
>>> for
>>> the call.
>>>
>>>>>> This alignment is no longer performed in the new (shared)
>>>>>> implementation
>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>>> separate
>>>>>> path for x86_64. Did we really need the alignment for linux 
>>>>>> x86_64 and
>>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>>
>>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>>> should
>>>>>> not be expensive since we call get_thread rarely for x86_64 
>>>>>> (result is
>>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>>> ifdef so
>>>>>> as to explicitly deactivate the alignment on some platforms
>>>>>> (solaris_x86_64 ?)
>>>>>
>>>>> I don't have enough knowledge to even begin to comment on this. I 
>>>>> will
>>>>> have to rely on our x86_64 macroassembler experts to explain the old
>>>>> code and what the requirements are.
>>>>
>>>> OK. This means that the alignment was not removed purposefully.
>>>>
>>>> In that case, you must either keep the per platform code x86_64 (since
>>>> it was not identical for all platforms) or use the safest version, 
>>>> with
>>>> the additional
>>>>
>>>>     // XXX
>>>>     mov(r10, rsp);
>>>>     andq(rsp, -16);
>>>>     push(r10);
>>>>
>>>> before the push(r11) and with the
>>>>
>>>>     pop(rsp);
>>>>
>>>> after the pop(r11). It should work on all x86_64 platforms.
>>>
>>> Right, I will add this back to the code - and replace the 
>>> meaningless //
>>> XXX with an actual comment!
>>>
>>> Many thanks,
>>> David
>>> -----
>>>
>>>> FYI, there is another way to do the alignment, based on the fact that
>>>> we are at least aligned on 8 bytes (see
>>>> MacroAssembler::call_VM_leaf_base). I assume that this second 
>>>> version is
>>>> more efficient (particularly thanks to specilative branches) but it
>>>> might be safer/simpler to continue using andq in get_thread.
>>>>
>>>> Bertrand.
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Bertrand.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>>> After all the preliminary discussions here are final proposed
>>>>>>> changes:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>>
>>>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>>
>>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>>> appeal to
>>>>>>> our Code Deletion Engineer's. We implement Thread::current() 
>>>>>>> using a
>>>>>>> compiler/language-based thread-local variable eg:
>>>>>>>
>>>>>>>   static __thread Thread *_thr_current;
>>>>>>>
>>>>>>>   inline Thread* Thread::current() {
>>>>>>>     return _thr_current;
>>>>>>>   }
>>>>>>>
>>>>>>> with an appropriate setter of course. By doing this we can 
>>>>>>> completely
>>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and
>>>>>>> the
>>>>>>> associated os::thread_local_storage* calls.
>>>>>>>
>>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>>> practice) we
>>>>>>> need a fallback library-based solution as used today. For this we
>>>>>>> use a
>>>>>>> very simple ThreadLocalStorage class and an implementation thereof
>>>>>>> for
>>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>>>> While these library routines are not guaranteed async-signal-safe,
>>>>>>> they
>>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>>
>>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>>> where
>>>>>>> compiler-based thread locals are not supported (as will be 
>>>>>>> needed in
>>>>>>> the
>>>>>>> Mobile project). This is enabled at build time by defining
>>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>>
>>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for 
>>>>>>> Thomas
>>>>>>> Stuefe for testing PPC and AIX.
>>>>>>>
>>>>>>> Testing:
>>>>>>>   - JPRT (core platforms)
>>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>>   - vm.runtime (core platforms)
>>>>>>>
>>>>>>> Performance:
>>>>>>>   - still TBD - this is proving to be extremely difficult. If 
>>>>>>> anyone
>>>>>>> has
>>>>>>> any simple to run microbenchmarks to suggest I'd give them a try 
>>>>>>> as a
>>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>>> benchmarking.
>>>>>>>
>>>>>>> Footprint:
>>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>
>>>>>>
>>>>
>>>>


From david.holmes at oracle.com  Wed Nov 25 05:07:22 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Nov 2015 15:07:22 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5655102D.20502@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
	<5653C930.5090602@oracle.com> <5655102D.20502@oracle.com>
Message-ID: <5655420A.4090805@oracle.com>

Hi Dan,

Many thanks for the meticulous review!

On 25/11/2015 11:34 AM, Daniel D. Daugherty wrote:
> On 11/23/15 7:19 PM, David Holmes wrote:
>> Sorry about that:
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>
> Please double check the copyright updates before you push.

Did you notice something missing? I use:

hg status -man | xargs grep Copyright | grep -v 2015

to find any copyright lines without 2015 present (it turns up the 
non-Oracle copyrights in a few files).

Trimming to files with comments ...

> src/os/windows/vm/os_windows.cpp
>      L5998:       os::os_exception_wrapper(
> (java_call_t)call_wrapper_dummy,
>          Wrong indent; should only be two spaces.
>          Please delete space after first '('.
>
>      L5999:                                 NULL, NULL, NULL, NULL);
>          Indent will have to change to match any fixes on previous line.

Fixed.

> src/os/windows/vm/os_windows.hpp
>      L127:   static inline void set_thread_ptr_offset( int offset ) {
>          Please delete space after '(' and before ')'.

Fixed (was a copy of code from now deleted file)

> src/share/vm/gc/parallel/gcTaskThread.cpp
>      No comments.
>
>      Note: blank first line in this file (not your change)

Fixed.

> src/share/vm/prims/jni.cpp
>      L4312:   // If the thread has already been detached the operations
> is a no-op
>          Typo: 'the operations is a' -> 'the operation is a'

Fixed

> src/share/vm/prims/jvmtiExport.cpp
>      L377:       JavaThread* current_thread = JavaThread::current();
>          Wrong indent; two less spaces

Fixed.

> src/share/vm/runtime/threadLocalStorage.hpp
>      L37: // Platforms without compiler-based TLS (ie __thread
> storage-class modifier)
>          Typo: 'ie' -> 'i.e.'

Fixed.

> src/share/vm/runtime/vm_operations.cpp
>
>      (old) L396:   Thread * thr_cur =
> ThreadLocalStorage::get_thread_slow();
>      (new) L396:   Thread * thr_cur = Thread::current();
>
>          I think this should be 'current_or_null()' like L374.

Actually L374 should just be Thread::current() as NULL is neither 
possible nor expected. These VM_Exit routines can only be called by an 
attached thread. E.g. set_vm_exited is only called from 
Threads::destroy_vm(), while wait_for_threads_in_native_to_block is only 
called on the VMThread.

> src/os/posix/vm/threadLocalStorage_posix.cpp
>      L38:     ThreadLocalStorage::set_thread((Thread*) p);
>          Wrong indent; should be two spaces.

Fixed.

> src/os/windows/vm/threadLocalStorage_windows.cpp
>      L54:   assert(current != 0 || GetLastError() == ERROR_SUCCESS, '
>          'current != 0' -> 'current != NULL'
>          jcheck will complain about the blank at the end of this line
>
>      L62:   assert(res, "TlsSetValue failed with error code: %lu",
> GetLastError());
>          jcheck will complain about the blank at the end of this line

Fixed.

Generated new webrev:

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/

which has been rebased to current hs-rt content.

Thanks,
David

>
> Dan
>
>
>>
>> David
>>
>> On 24/11/2015 11:17 AM, David Holmes wrote:
>>> Updated webrev:
>>>
>>> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>>
>>> Only change is in macroAssembler_x86.cpp
>>>
>>> Thanks,
>>> David
>>>
>>> On 24/11/2015 7:42 AM, David Holmes wrote:
>>>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>>> On 23/11/2015 13:27, David Holmes wrote:
>>>>>> Hi Bertrand,
>>>>>>
>>>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Overall looks good.
>>>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>>>
>>>>>>> One doubt, in case this has not been discussed before.
>>>>>>>
>>>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>>>> but it
>>>>>>> seems that there are some stack alignment constraints on runtime
>>>>>>> calls,
>>>>>>> at least for some x86_64 ABIs.
>>>>>>>
>>>>>>> Some of the x86 MacroAssembler::get_thread implementations had
>>>>>>> code to
>>>>>>> align the stack before calling pthread_getspecific. See for instance
>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>>>>> fragment:
>>>>>>
>>>>>> -   push(r10);
>>>>>> -   // XXX
>>>>>> -   mov(r10, rsp);
>>>>>> -   andq(rsp, -16);
>>>>>> -   push(r10);
>>>>>>
>>>>>> I'm not at all clear what that is doing - and if it somehow
>>>>>> changes the
>>>>>> alignment wouldn't something need to be fixed up when popping the
>>>>>> previous values ??
>>>>>>
>>>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>>>
>>>>> On some platforms, SP may have to be aligned on a 16 bytes boundary
>>>>> when
>>>>> calling another method.
>>>>
>>>> Okay - that seems to be an x64 ABI requirement based on other code in
>>>> MacroAssembler. The reason it is missing in the Solaris code is because
>>>> I already removed it in the earlier changes that were done on Solaris:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>>
>>>> and nobody picked it up. :(
>>>>
>>>> That said, the absence of this code has not caused any problems so
>>>> presumably we are normally aligned.
>>>>
>>>>> After having pushed what needed to be saved, the code above rounds SP
>>>>> down and saves the old value. It will then also push r11, which
>>>>> results
>>>>> in the expected alignment.
>>>>>
>>>>> The conterpart, after the VM call, is the:
>>>>>   pop(r11);
>>>>>   pop(rsp);
>>>>
>>>> I had assumed this extra manipulation was related to pushing the arg
>>>> for
>>>> the call.
>>>>
>>>>>>> This alignment is no longer performed in the new (shared)
>>>>>>> implementation
>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>>>> separate
>>>>>>> path for x86_64. Did we really need the alignment for linux
>>>>>>> x86_64 and
>>>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>>>
>>>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>>>> should
>>>>>>> not be expensive since we call get_thread rarely for x86_64
>>>>>>> (result is
>>>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>>>> ifdef so
>>>>>>> as to explicitly deactivate the alignment on some platforms
>>>>>>> (solaris_x86_64 ?)
>>>>>>
>>>>>> I don't have enough knowledge to even begin to comment on this. I
>>>>>> will
>>>>>> have to rely on our x86_64 macroassembler experts to explain the old
>>>>>> code and what the requirements are.
>>>>>
>>>>> OK. This means that the alignment was not removed purposefully.
>>>>>
>>>>> In that case, you must either keep the per platform code x86_64 (since
>>>>> it was not identical for all platforms) or use the safest version,
>>>>> with
>>>>> the additional
>>>>>
>>>>>     // XXX
>>>>>     mov(r10, rsp);
>>>>>     andq(rsp, -16);
>>>>>     push(r10);
>>>>>
>>>>> before the push(r11) and with the
>>>>>
>>>>>     pop(rsp);
>>>>>
>>>>> after the pop(r11). It should work on all x86_64 platforms.
>>>>
>>>> Right, I will add this back to the code - and replace the
>>>> meaningless //
>>>> XXX with an actual comment!
>>>>
>>>> Many thanks,
>>>> David
>>>> -----
>>>>
>>>>> FYI, there is another way to do the alignment, based on the fact that
>>>>> we are at least aligned on 8 bytes (see
>>>>> MacroAssembler::call_VM_leaf_base). I assume that this second
>>>>> version is
>>>>> more efficient (particularly thanks to specilative branches) but it
>>>>> might be safer/simpler to continue using andq in get_thread.
>>>>>
>>>>> Bertrand.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Bertrand.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>>>> After all the preliminary discussions here are final proposed
>>>>>>>> changes:
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>>>
>>>>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>>>
>>>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>>>> appeal to
>>>>>>>> our Code Deletion Engineer's. We implement Thread::current()
>>>>>>>> using a
>>>>>>>> compiler/language-based thread-local variable eg:
>>>>>>>>
>>>>>>>>   static __thread Thread *_thr_current;
>>>>>>>>
>>>>>>>>   inline Thread* Thread::current() {
>>>>>>>>     return _thr_current;
>>>>>>>>   }
>>>>>>>>
>>>>>>>> with an appropriate setter of course. By doing this we can
>>>>>>>> completely
>>>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and
>>>>>>>> the
>>>>>>>> associated os::thread_local_storage* calls.
>>>>>>>>
>>>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>>>> practice) we
>>>>>>>> need a fallback library-based solution as used today. For this we
>>>>>>>> use a
>>>>>>>> very simple ThreadLocalStorage class and an implementation thereof
>>>>>>>> for
>>>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>>>>> While these library routines are not guaranteed async-signal-safe,
>>>>>>>> they
>>>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>>>
>>>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>>>> where
>>>>>>>> compiler-based thread locals are not supported (as will be
>>>>>>>> needed in
>>>>>>>> the
>>>>>>>> Mobile project). This is enabled at build time by defining
>>>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>>>
>>>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for
>>>>>>>> Thomas
>>>>>>>> Stuefe for testing PPC and AIX.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>>   - JPRT (core platforms)
>>>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>>>   - vm.runtime (core platforms)
>>>>>>>>
>>>>>>>> Performance:
>>>>>>>>   - still TBD - this is proving to be extremely difficult. If
>>>>>>>> anyone
>>>>>>>> has
>>>>>>>> any simple to run microbenchmarks to suggest I'd give them a try
>>>>>>>> as a
>>>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>>>> benchmarking.
>>>>>>>>
>>>>>>>> Footprint:
>>>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>

From thomas.stuefe at gmail.com  Wed Nov 25 08:40:58 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Nov 2015 09:40:58 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56538862.5010609@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
Message-ID: <CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>

Hi David, Bertrand,

about
http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html

I am not sure this is correct for Windows x64.

https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx

windows x64 Abi requires the register parameter area right above the return
address on the stack. It is not guaranteed to be preserved during the
function call:

"Even if the called function has fewer than 4 parameters, these 4 stack
locations are effectively owned by the called function, and may be used by
the called function for other purposes besides saving parameter register
values. Thus the caller may not save information in this region of stack
across a function call."

So, restoring parameters from it may not work if Thread::current() uses
this area for any reason. In this case, r9, rsp, r10, r11 may be
overwritten by the callee.

I also think Windows x64 ABI is different enough from Linux that this
function could live somewhere in <os>_<cpu>.

Kind Regards, Thomas




On Mon, Nov 23, 2015 at 10:42 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>
>> On 23/11/2015 13:27, David Holmes wrote:
>>
>>> Hi Bertrand,
>>>
>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>
>>>> Hi David,
>>>>
>>>> Overall looks good.
>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>
>>>> One doubt, in case this has not been discussed before.
>>>>
>>>> I'm still catching up on x86_64 (after years of ARM assembly :-)) but it
>>>> seems that there are some stack alignment constraints on runtime calls,
>>>> at least for some x86_64 ABIs.
>>>>
>>>> Some of the x86 MacroAssembler::get_thread implementations had code to
>>>> align the stack before calling pthread_getspecific. See for instance
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>
>>>>
>>>>
>>> Sorry I'm not that familiar with the MacroAssembler - is it this odd
>>> fragment:
>>>
>>> -   push(r10);
>>> -   // XXX
>>> -   mov(r10, rsp);
>>> -   andq(rsp, -16);
>>> -   push(r10);
>>>
>>> I'm not at all clear what that is doing - and if it somehow changes the
>>> alignment wouldn't something need to be fixed up when popping the
>>> previous values ??
>>>
>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>
>>
>> On some platforms, SP may have to be aligned on a 16 bytes boundary when
>> calling another method.
>>
>
> Okay - that seems to be an x64 ABI requirement based on other code in
> MacroAssembler. The reason it is missing in the Solaris code is because I
> already removed it in the earlier changes that were done on Solaris:
>
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>
> and nobody picked it up. :(
>
> That said, the absence of this code has not caused any problems so
> presumably we are normally aligned.
>
> After having pushed what needed to be saved, the code above rounds SP
>> down and saves the old value. It will then also push r11, which results
>> in the expected alignment.
>>
>> The conterpart, after the VM call, is the:
>>   pop(r11);
>>   pop(rsp);
>>
>
> I had assumed this extra manipulation was related to pushing the arg for
> the call.
>
> This alignment is no longer performed in the new (shared) implementation
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>> Now, Solaris was not performing the alignment and Windows has a separate
>>>> path for x86_64. Did we really need the alignment for linux x86_64 and
>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>
>>>> IMHO, it might be safer to align the stack by default, knowing it should
>>>> not be expensive since we call get_thread rarely for x86_64 (result is
>>>> cached in r15). I'll let you see whether it is worth adding an ifdef so
>>>> as to explicitly deactivate the alignment on some platforms
>>>> (solaris_x86_64 ?)
>>>>
>>>
>>> I don't have enough knowledge to even begin to comment on this. I will
>>> have to rely on our x86_64 macroassembler experts to explain the old
>>> code and what the requirements are.
>>>
>>
>> OK. This means that the alignment was not removed purposefully.
>>
>> In that case, you must either keep the per platform code x86_64 (since
>> it was not identical for all platforms) or use the safest version, with
>> the additional
>>
>>     // XXX
>>     mov(r10, rsp);
>>     andq(rsp, -16);
>>     push(r10);
>>
>> before the push(r11) and with the
>>
>>     pop(rsp);
>>
>> after the pop(r11). It should work on all x86_64 platforms.
>>
>
> Right, I will add this back to the code - and replace the meaningless //
> XXX with an actual comment!
>
> Many thanks,
> David
> -----
>
>
> FYI, there is another way to do the alignment, based on the fact that
>> we are at least aligned on 8 bytes (see
>> MacroAssembler::call_VM_leaf_base). I assume that this second version is
>> more efficient (particularly thanks to specilative branches) but it
>> might be safer/simpler to continue using andq in get_thread.
>>
>> Bertrand.
>>
>>
>>> Thanks,
>>> David
>>>
>>> Regards,
>>>>
>>>> Bertrand.
>>>>
>>>>
>>>>
>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>
>>>>> After all the preliminary discussions here are final proposed changes:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>
>>>>> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>
>>>>> A simple (in principle) but wide-ranging change which should appeal to
>>>>> our Code Deletion Engineer's. We implement Thread::current() using a
>>>>> compiler/language-based thread-local variable eg:
>>>>>
>>>>>   static __thread Thread *_thr_current;
>>>>>
>>>>>   inline Thread* Thread::current() {
>>>>>     return _thr_current;
>>>>>   }
>>>>>
>>>>> with an appropriate setter of course. By doing this we can completely
>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, and the
>>>>> associated os::thread_local_storage* calls.
>>>>>
>>>>> As __thread is not async-signal-safe (either in theory or practice) we
>>>>> need a fallback library-based solution as used today. For this we use a
>>>>> very simple ThreadLocalStorage class and an implementation thereof for
>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>> pthread_get/setspecific; and one for Windows using its TLS library.
>>>>> While these library routines are not guaranteed async-signal-safe, they
>>>>> seem to be in practice and are what we have been using all along.
>>>>>
>>>>> We also allow for use of only the library-based TLS for platforms where
>>>>> compiler-based thread locals are not supported (as will be needed in
>>>>> the
>>>>> Mobile project). This is enabled at build time by defining
>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>
>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
>>>>> Stuefe for testing PPC and AIX.
>>>>>
>>>>> Testing:
>>>>>   - JPRT (core platforms)
>>>>>   - Jtreg tests (linux & solaris)
>>>>>   - vm.runtime (core platforms)
>>>>>
>>>>> Performance:
>>>>>   - still TBD - this is proving to be extremely difficult. If anyone
>>>>> has
>>>>> any simple to run microbenchmarks to suggest I'd give them a try as a
>>>>> sanity check. But I lack access to hardware for running serious
>>>>> benchmarking.
>>>>>
>>>>> Footprint:
>>>>> - varies by platform and the VM (server, client, minimal)
>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>> - best-case:  0.4% decrease for client VM
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>
>>>>
>>>>
>>
>>

From dmitry.dmitriev at oracle.com  Wed Nov 25 08:41:38 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 25 Nov 2015 11:41:38 +0300
Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework needs
	to handle VM error codes in some cases
Message-ID: <56557442.2080408@oracle.com>

Hello,

Please review this small enhancement to the command line options 
validation test framework. This enhancement allow to specify allowed 
exit code for flags. This is needed for CDS Shared flags, because in 
some cases JVM can exit with error code 2 and this should not be treated 
as error. Also, in this fix I refactor code which parse Shared flags - 
specify explicit names of the flags in switch statement and use only one 
CDS archive file.

JBS: https://bugs.openjdk.java.net/browse/JDK-8142874
webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ 
<http://cr.openjdk.java.net/%7Eddmitriev/8142874/webrev.01/>
Testing: tested on all platforms by RBT

Thanks,
Dmitry

From erik.joelsson at oracle.com  Wed Nov 25 09:02:46 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 25 Nov 2015 10:02:46 +0100
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
Message-ID: <56557936.3070109@oracle.com>

Hello,

The following new build failure has appeared in the hotspot build when 
using the proposed new compiler version on Solaris, SS12u4.

"/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&, 
DIR_Chunk*const&) is not accessible from 
GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
"/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
line 281: Where: While instantiating 
"GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 

"/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
line 281: Where: Instantiated from non-template code.

Tom Rodriguez provided a patch and I have verified that it solves the 
issue. Since this is blocking us upgrading compilers on Solaris, I am 
taking the liberty of posting it for review so we may get this resolved 
quickly.

Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/

/Erik

From bertrand.delsart at oracle.com  Wed Nov 25 09:22:21 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Wed, 25 Nov 2015 10:22:21 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
Message-ID: <56557DCD.9050907@oracle.com>

Good finding Thomas,

On 25/11/2015 09:40, Thomas St?fe wrote:
> Hi David, Bertrand,
>
> about
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>
> I am not sure this is correct for Windows x64.

Unless I'm misreading it, the new code looks a lot like the old one 
(including the alignement part). Hence this does not look like a 
regression caused by David's change.

>
> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>
> windows x64 Abi requires the register parameter area right above the
> return address on the stack. It is not guaranteed to be preserved during
> the function call:
>
> "Even if the called function has fewer than 4 parameters, these 4 stack
> locations are effectively owned by the called function, and may be used
> by the called function for other purposes besides saving parameter
> register values. Thus the caller may not save information in this region
> of stack across a function call."
>
> So, restoring parameters from it may not work if Thread::current() uses
> this area for any reason. In this case, r9, rsp, r10, r11 may be
> overwritten by the callee.
>
> I also think Windows x64 ABI is different enough from Linux that this
> function could live somewhere in <os>_<cpu>.

This is a valid point. However, note that this is similar to the issue 
we have for instance in 'shared' MacroAssembler::call_VM_leaf_base, 
which was not put in <os>_<cpu> files.

In fact, the right fix may be to use call_VM_leaf instead of call :-)

(alternatively we could use "#ifdef _WIN64" or check 
"frame::arg_reg_save_area_bytes != 0", which may be even cleaner and 
more portable)

All these solutions are fine for me.

Since we are near to feature freeze, this should probably be done in a 
separate CR (unless David has enough time to test it).

Regards,

Bertrand.

>
> Kind Regards, Thomas
>
>
>
>
> On Mon, Nov 23, 2015 at 10:42 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>
>         On 23/11/2015 13:27, David Holmes wrote:
>
>             Hi Bertrand,
>
>             On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>
>                 Hi David,
>
>                 Overall looks good.
>                 Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>
>                 One doubt, in case this has not been discussed before.
>
>                 I'm still catching up on x86_64 (after years of ARM
>                 assembly :-)) but it
>                 seems that there are some stack alignment constraints on
>                 runtime calls,
>                 at least for some x86_64 ABIs.
>
>                 Some of the x86 MacroAssembler::get_thread
>                 implementations had code to
>                 align the stack before calling pthread_getspecific. See
>                 for instance
>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>
>
>
>             Sorry I'm not that familiar with the MacroAssembler - is it
>             this odd
>             fragment:
>
>             -   push(r10);
>             -   // XXX
>             -   mov(r10, rsp);
>             -   andq(rsp, -16);
>             -   push(r10);
>
>             I'm not at all clear what that is doing - and if it somehow
>             changes the
>             alignment wouldn't something need to be fixed up when
>             popping the
>             previous values ??
>
>             To be honest I'm not even sure what an "unaligned stack" means.
>
>
>         On some platforms, SP may have to be aligned on a 16 bytes
>         boundary when
>         calling another method.
>
>
>     Okay - that seems to be an x64 ABI requirement based on other code
>     in MacroAssembler. The reason it is missing in the Solaris code is
>     because I already removed it in the earlier changes that were done
>     on Solaris:
>
>     http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>
>     and nobody picked it up. :(
>
>     That said, the absence of this code has not caused any problems so
>     presumably we are normally aligned.
>
>         After having pushed what needed to be saved, the code above
>         rounds SP
>         down and saves the old value. It will then also push r11, which
>         results
>         in the expected alignment.
>
>         The conterpart, after the VM call, is the:
>            pop(r11);
>            pop(rsp);
>
>
>     I had assumed this extra manipulation was related to pushing the arg
>     for the call.
>
>                 This alignment is no longer performed in the new
>                 (shared) implementation
>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>
>
>
>
>                 Now, Solaris was not performing the alignment and
>                 Windows has a separate
>                 path for x86_64. Did we really need the alignment for
>                 linux x86_64 and
>                 bsd_x86_64 ? Might it be needed for other ports ?
>
>                 IMHO, it might be safer to align the stack by default,
>                 knowing it should
>                 not be expensive since we call get_thread rarely for
>                 x86_64 (result is
>                 cached in r15). I'll let you see whether it is worth
>                 adding an ifdef so
>                 as to explicitly deactivate the alignment on some platforms
>                 (solaris_x86_64 ?)
>
>
>             I don't have enough knowledge to even begin to comment on
>             this. I will
>             have to rely on our x86_64 macroassembler experts to explain
>             the old
>             code and what the requirements are.
>
>
>         OK. This means that the alignment was not removed purposefully.
>
>         In that case, you must either keep the per platform code x86_64
>         (since
>         it was not identical for all platforms) or use the safest
>         version, with
>         the additional
>
>              // XXX
>              mov(r10, rsp);
>              andq(rsp, -16);
>              push(r10);
>
>         before the push(r11) and with the
>
>              pop(rsp);
>
>         after the pop(r11). It should work on all x86_64 platforms.
>
>
>     Right, I will add this back to the code - and replace the
>     meaningless // XXX with an actual comment!
>
>     Many thanks,
>     David
>     -----
>
>
>         FYI, there is another way to do the alignment, based on the fact
>         that
>         we are at least aligned on 8 bytes (see
>         MacroAssembler::call_VM_leaf_base). I assume that this second
>         version is
>         more efficient (particularly thanks to specilative branches) but it
>         might be safer/simpler to continue using andq in get_thread.
>
>         Bertrand.
>
>
>             Thanks,
>             David
>
>                 Regards,
>
>                 Bertrand.
>
>
>
>                 On 23/11/2015 08:03, David Holmes wrote:
>
>                     After all the preliminary discussions here are final
>                     proposed changes:
>
>                     bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                     Open webrev:
>                     http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
>                     A simple (in principle) but wide-ranging change
>                     which should appeal to
>                     our Code Deletion Engineer's. We implement
>                     Thread::current() using a
>                     compiler/language-based thread-local variable eg:
>
>                        static __thread Thread *_thr_current;
>
>                        inline Thread* Thread::current() {
>                          return _thr_current;
>                        }
>
>                     with an appropriate setter of course. By doing this
>                     we can completely
>                     remove the os_cpu-specific ThreadLocalStorage
>                     implementations, and the
>                     associated os::thread_local_storage* calls.
>
>                     As __thread is not async-signal-safe (either in
>                     theory or practice) we
>                     need a fallback library-based solution as used
>                     today. For this we use a
>                     very simple ThreadLocalStorage class and an
>                     implementation thereof for
>                     POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>                     pthread_get/setspecific; and one for Windows using
>                     its TLS library.
>                     While these library routines are not guaranteed
>                     async-signal-safe, they
>                     seem to be in practice and are what we have been
>                     using all along.
>
>                     We also allow for use of only the library-based TLS
>                     for platforms where
>                     compiler-based thread locals are not supported (as
>                     will be needed in
>                     the
>                     Mobile project). This is enabled at build time by
>                     defining
>                     USE_LIBRARY_BASED_TLS_ONLY.
>
>                     Thanks to Andrew Haley for providing the Aarch64
>                     code; and for Thomas
>                     Stuefe for testing PPC and AIX.
>
>                     Testing:
>                        - JPRT (core platforms)
>                        - Jtreg tests (linux & solaris)
>                        - vm.runtime (core platforms)
>
>                     Performance:
>                        - still TBD - this is proving to be extremely
>                     difficult. If anyone
>                     has
>                     any simple to run microbenchmarks to suggest I'd
>                     give them a try as a
>                     sanity check. But I lack access to hardware for
>                     running serious
>                     benchmarking.
>
>                     Footprint:
>                     - varies by platform and the VM (server, client,
>                     minimal)
>                     - worst-case: ~1% increase for server VM and minimal VM
>                     - best-case:  0.4% decrease for client VM
>
>                     Thanks,
>                     David
>
>
>
>
>
>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From sgehwolf at redhat.com  Wed Nov 25 10:04:02 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 25 Nov 2015 11:04:02 +0100
Subject: RFR: 8008243: Zero: Implement fast-bytecodes
Message-ID: <1448445842.3498.15.camel@redhat.com>

Hi,

Roman asked me to get his patch integrated. This is basically a rebase
of his patch to latest JDK 9 hs-rt + some incorporated review feedback.

Bug:?https://bugs.openjdk.java.net/browse/JDK-8008243
webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8008243/00/

The old review thread was here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008449.html

With this patch I see a speedup of the Zero interpreter of about 18%.

I don't think we need an extra cache->is_resolved() condition for
putfield since this is already done earlier in the putfield case. As to
the breakpoint conditional I'm not sure how that should look like. Does
anybody have some pointers?

Since the patch relies on ordering of fast bytecodes I've added an
assert which attempts to catch this.

Thoughts?

Note: Once approved I'd need someone to sponsor this patch for me.

Cheers,
Severin

From bertrand.delsart at oracle.com  Wed Nov 25 10:24:16 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Wed, 25 Nov 2015 11:24:16 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56557DCD.9050907@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
Message-ID: <56558C50.5080406@oracle.com>

On 25/11/2015 10:22, Bertrand Delsart wrote:
> Good finding Thomas,
>
> On 25/11/2015 09:40, Thomas St?fe wrote:
>> Hi David, Bertrand,
>>
>> about
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>
>>
>> I am not sure this is correct for Windows x64.
>
> Unless I'm misreading it, the new code looks a lot like the old one
> (including the alignement part). Hence this does not look like a
> regression caused by David's change.

Except that since what we call is different Thread::current() instead of 
TlsGetValue, the behavior now depends on whether Thread::curent uses 
these slots or not.

Hence, we indeed need to check whether this leads to regression (but 
this could easily be fixed after Feature Complete date IMHO).

Bertrand.

>
>>
>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>
>> windows x64 Abi requires the register parameter area right above the
>> return address on the stack. It is not guaranteed to be preserved during
>> the function call:
>>
>> "Even if the called function has fewer than 4 parameters, these 4 stack
>> locations are effectively owned by the called function, and may be used
>> by the called function for other purposes besides saving parameter
>> register values. Thus the caller may not save information in this region
>> of stack across a function call."
>>
>> So, restoring parameters from it may not work if Thread::current() uses
>> this area for any reason. In this case, r9, rsp, r10, r11 may be
>> overwritten by the callee.
>>
>> I also think Windows x64 ABI is different enough from Linux that this
>> function could live somewhere in <os>_<cpu>.
>
> This is a valid point. However, note that this is similar to the issue
> we have for instance in 'shared' MacroAssembler::call_VM_leaf_base,
> which was not put in <os>_<cpu> files.
>
> In fact, the right fix may be to use call_VM_leaf instead of call :-)
>
> (alternatively we could use "#ifdef _WIN64" or check
> "frame::arg_reg_save_area_bytes != 0", which may be even cleaner and
> more portable)
>
> All these solutions are fine for me.
>
> Since we are near to feature freeze, this should probably be done in a
> separate CR (unless David has enough time to test it).
>
> Regards,
>
> Bertrand.
>
>>
>> Kind Regards, Thomas
>>
>>
>>
>>
>> On Mon, Nov 23, 2015 at 10:42 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>
>>         On 23/11/2015 13:27, David Holmes wrote:
>>
>>             Hi Bertrand,
>>
>>             On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>
>>                 Hi David,
>>
>>                 Overall looks good.
>>                 Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>>                 One doubt, in case this has not been discussed before.
>>
>>                 I'm still catching up on x86_64 (after years of ARM
>>                 assembly :-)) but it
>>                 seems that there are some stack alignment constraints on
>>                 runtime calls,
>>                 at least for some x86_64 ABIs.
>>
>>                 Some of the x86 MacroAssembler::get_thread
>>                 implementations had code to
>>                 align the stack before calling pthread_getspecific. See
>>                 for instance
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>>
>>
>>
>>             Sorry I'm not that familiar with the MacroAssembler - is it
>>             this odd
>>             fragment:
>>
>>             -   push(r10);
>>             -   // XXX
>>             -   mov(r10, rsp);
>>             -   andq(rsp, -16);
>>             -   push(r10);
>>
>>             I'm not at all clear what that is doing - and if it somehow
>>             changes the
>>             alignment wouldn't something need to be fixed up when
>>             popping the
>>             previous values ??
>>
>>             To be honest I'm not even sure what an "unaligned stack"
>> means.
>>
>>
>>         On some platforms, SP may have to be aligned on a 16 bytes
>>         boundary when
>>         calling another method.
>>
>>
>>     Okay - that seems to be an x64 ABI requirement based on other code
>>     in MacroAssembler. The reason it is missing in the Solaris code is
>>     because I already removed it in the earlier changes that were done
>>     on Solaris:
>>
>>     http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>
>>     and nobody picked it up. :(
>>
>>     That said, the absence of this code has not caused any problems so
>>     presumably we are normally aligned.
>>
>>         After having pushed what needed to be saved, the code above
>>         rounds SP
>>         down and saves the old value. It will then also push r11, which
>>         results
>>         in the expected alignment.
>>
>>         The conterpart, after the VM call, is the:
>>            pop(r11);
>>            pop(rsp);
>>
>>
>>     I had assumed this extra manipulation was related to pushing the arg
>>     for the call.
>>
>>                 This alignment is no longer performed in the new
>>                 (shared) implementation
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>>
>>
>>                 Now, Solaris was not performing the alignment and
>>                 Windows has a separate
>>                 path for x86_64. Did we really need the alignment for
>>                 linux x86_64 and
>>                 bsd_x86_64 ? Might it be needed for other ports ?
>>
>>                 IMHO, it might be safer to align the stack by default,
>>                 knowing it should
>>                 not be expensive since we call get_thread rarely for
>>                 x86_64 (result is
>>                 cached in r15). I'll let you see whether it is worth
>>                 adding an ifdef so
>>                 as to explicitly deactivate the alignment on some
>> platforms
>>                 (solaris_x86_64 ?)
>>
>>
>>             I don't have enough knowledge to even begin to comment on
>>             this. I will
>>             have to rely on our x86_64 macroassembler experts to explain
>>             the old
>>             code and what the requirements are.
>>
>>
>>         OK. This means that the alignment was not removed purposefully.
>>
>>         In that case, you must either keep the per platform code x86_64
>>         (since
>>         it was not identical for all platforms) or use the safest
>>         version, with
>>         the additional
>>
>>              // XXX
>>              mov(r10, rsp);
>>              andq(rsp, -16);
>>              push(r10);
>>
>>         before the push(r11) and with the
>>
>>              pop(rsp);
>>
>>         after the pop(r11). It should work on all x86_64 platforms.
>>
>>
>>     Right, I will add this back to the code - and replace the
>>     meaningless // XXX with an actual comment!
>>
>>     Many thanks,
>>     David
>>     -----
>>
>>
>>         FYI, there is another way to do the alignment, based on the fact
>>         that
>>         we are at least aligned on 8 bytes (see
>>         MacroAssembler::call_VM_leaf_base). I assume that this second
>>         version is
>>         more efficient (particularly thanks to specilative branches)
>> but it
>>         might be safer/simpler to continue using andq in get_thread.
>>
>>         Bertrand.
>>
>>
>>             Thanks,
>>             David
>>
>>                 Regards,
>>
>>                 Bertrand.
>>
>>
>>
>>                 On 23/11/2015 08:03, David Holmes wrote:
>>
>>                     After all the preliminary discussions here are final
>>                     proposed changes:
>>
>>                     bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                     Open webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>
>>                     A simple (in principle) but wide-ranging change
>>                     which should appeal to
>>                     our Code Deletion Engineer's. We implement
>>                     Thread::current() using a
>>                     compiler/language-based thread-local variable eg:
>>
>>                        static __thread Thread *_thr_current;
>>
>>                        inline Thread* Thread::current() {
>>                          return _thr_current;
>>                        }
>>
>>                     with an appropriate setter of course. By doing this
>>                     we can completely
>>                     remove the os_cpu-specific ThreadLocalStorage
>>                     implementations, and the
>>                     associated os::thread_local_storage* calls.
>>
>>                     As __thread is not async-signal-safe (either in
>>                     theory or practice) we
>>                     need a fallback library-based solution as used
>>                     today. For this we use a
>>                     very simple ThreadLocalStorage class and an
>>                     implementation thereof for
>>                     POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>                     pthread_get/setspecific; and one for Windows using
>>                     its TLS library.
>>                     While these library routines are not guaranteed
>>                     async-signal-safe, they
>>                     seem to be in practice and are what we have been
>>                     using all along.
>>
>>                     We also allow for use of only the library-based TLS
>>                     for platforms where
>>                     compiler-based thread locals are not supported (as
>>                     will be needed in
>>                     the
>>                     Mobile project). This is enabled at build time by
>>                     defining
>>                     USE_LIBRARY_BASED_TLS_ONLY.
>>
>>                     Thanks to Andrew Haley for providing the Aarch64
>>                     code; and for Thomas
>>                     Stuefe for testing PPC and AIX.
>>
>>                     Testing:
>>                        - JPRT (core platforms)
>>                        - Jtreg tests (linux & solaris)
>>                        - vm.runtime (core platforms)
>>
>>                     Performance:
>>                        - still TBD - this is proving to be extremely
>>                     difficult. If anyone
>>                     has
>>                     any simple to run microbenchmarks to suggest I'd
>>                     give them a try as a
>>                     sanity check. But I lack access to hardware for
>>                     running serious
>>                     benchmarking.
>>
>>                     Footprint:
>>                     - varies by platform and the VM (server, client,
>>                     minimal)
>>                     - worst-case: ~1% increase for server VM and
>> minimal VM
>>                     - best-case:  0.4% decrease for client VM
>>
>>                     Thanks,
>>                     David
>>
>>
>>
>>
>>
>>
>
>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From thomas.stuefe at gmail.com  Wed Nov 25 10:46:24 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Nov 2015 11:46:24 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56557DCD.9050907@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
Message-ID: <CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>

On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart <
bertrand.delsart at oracle.com> wrote:

> Good finding Thomas,
>
> On 25/11/2015 09:40, Thomas St?fe wrote:
>
>> Hi David, Bertrand,
>>
>> about
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>
>> I am not sure this is correct for Windows x64.
>>
>
> Unless I'm misreading it, the new code looks a lot like the old one
> (including the alignement part). Hence this does not look like a regression
> caused by David's change.
>
>
Yes, this seems like an old bug.

I also see that this is fixed in our codebase since 2010, exactly the way
you propose (with MacroAssembler
<http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::
call_VM_leaf_base
<http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
So, it is already used since five years. I would propose opening a separate
bug for this one and we contribute our fix.

Regards, Thomas


>
>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>
>> windows x64 Abi requires the register parameter area right above the
>> return address on the stack. It is not guaranteed to be preserved during
>> the function call:
>>
>> "Even if the called function has fewer than 4 parameters, these 4 stack
>> locations are effectively owned by the called function, and may be used
>> by the called function for other purposes besides saving parameter
>> register values. Thus the caller may not save information in this region
>> of stack across a function call."
>>
>> So, restoring parameters from it may not work if Thread::current() uses
>> this area for any reason. In this case, r9, rsp, r10, r11 may be
>> overwritten by the callee.
>>
>> I also think Windows x64 ABI is different enough from Linux that this
>> function could live somewhere in <os>_<cpu>.
>>
>
> This is a valid point. However, note that this is similar to the issue we
> have for instance in 'shared' MacroAssembler::call_VM_leaf_base, which was
> not put in <os>_<cpu> files.
>
> In fact, the right fix may be to use call_VM_leaf instead of call :-)
>
> (alternatively we could use "#ifdef _WIN64" or check
> "frame::arg_reg_save_area_bytes != 0", which may be even cleaner and more
> portable)
>
> All these solutions are fine for me.
>
>

> Since we are near to feature freeze, this should probably be done in a
> separate CR (unless David has enough time to test it).
>
> Regards,
>
> Bertrand.
>
>
>> Kind Regards, Thomas
>>
>>
>>
>>
>> On Mon, Nov 23, 2015 at 10:42 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>
>>         On 23/11/2015 13:27, David Holmes wrote:
>>
>>             Hi Bertrand,
>>
>>             On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>
>>                 Hi David,
>>
>>                 Overall looks good.
>>                 Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>>                 One doubt, in case this has not been discussed before.
>>
>>                 I'm still catching up on x86_64 (after years of ARM
>>                 assembly :-)) but it
>>                 seems that there are some stack alignment constraints on
>>                 runtime calls,
>>                 at least for some x86_64 ABIs.
>>
>>                 Some of the x86 MacroAssembler::get_thread
>>                 implementations had code to
>>                 align the stack before calling pthread_getspecific. See
>>                 for instance
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>>
>>
>>             Sorry I'm not that familiar with the MacroAssembler - is it
>>             this odd
>>             fragment:
>>
>>             -   push(r10);
>>             -   // XXX
>>             -   mov(r10, rsp);
>>             -   andq(rsp, -16);
>>             -   push(r10);
>>
>>             I'm not at all clear what that is doing - and if it somehow
>>             changes the
>>             alignment wouldn't something need to be fixed up when
>>             popping the
>>             previous values ??
>>
>>             To be honest I'm not even sure what an "unaligned stack"
>> means.
>>
>>
>>         On some platforms, SP may have to be aligned on a 16 bytes
>>         boundary when
>>         calling another method.
>>
>>
>>     Okay - that seems to be an x64 ABI requirement based on other code
>>     in MacroAssembler. The reason it is missing in the Solaris code is
>>     because I already removed it in the earlier changes that were done
>>     on Solaris:
>>
>>     http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>
>>     and nobody picked it up. :(
>>
>>     That said, the absence of this code has not caused any problems so
>>     presumably we are normally aligned.
>>
>>         After having pushed what needed to be saved, the code above
>>         rounds SP
>>         down and saves the old value. It will then also push r11, which
>>         results
>>         in the expected alignment.
>>
>>         The conterpart, after the VM call, is the:
>>            pop(r11);
>>            pop(rsp);
>>
>>
>>     I had assumed this extra manipulation was related to pushing the arg
>>     for the call.
>>
>>                 This alignment is no longer performed in the new
>>                 (shared) implementation
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>>
>>                 Now, Solaris was not performing the alignment and
>>                 Windows has a separate
>>                 path for x86_64. Did we really need the alignment for
>>                 linux x86_64 and
>>                 bsd_x86_64 ? Might it be needed for other ports ?
>>
>>                 IMHO, it might be safer to align the stack by default,
>>                 knowing it should
>>                 not be expensive since we call get_thread rarely for
>>                 x86_64 (result is
>>                 cached in r15). I'll let you see whether it is worth
>>                 adding an ifdef so
>>                 as to explicitly deactivate the alignment on some
>> platforms
>>                 (solaris_x86_64 ?)
>>
>>
>>             I don't have enough knowledge to even begin to comment on
>>             this. I will
>>             have to rely on our x86_64 macroassembler experts to explain
>>             the old
>>             code and what the requirements are.
>>
>>
>>         OK. This means that the alignment was not removed purposefully.
>>
>>         In that case, you must either keep the per platform code x86_64
>>         (since
>>         it was not identical for all platforms) or use the safest
>>         version, with
>>         the additional
>>
>>              // XXX
>>              mov(r10, rsp);
>>              andq(rsp, -16);
>>              push(r10);
>>
>>         before the push(r11) and with the
>>
>>              pop(rsp);
>>
>>         after the pop(r11). It should work on all x86_64 platforms.
>>
>>
>>     Right, I will add this back to the code - and replace the
>>     meaningless // XXX with an actual comment!
>>
>>     Many thanks,
>>     David
>>     -----
>>
>>
>>         FYI, there is another way to do the alignment, based on the fact
>>         that
>>         we are at least aligned on 8 bytes (see
>>         MacroAssembler::call_VM_leaf_base). I assume that this second
>>         version is
>>         more efficient (particularly thanks to specilative branches) but
>> it
>>         might be safer/simpler to continue using andq in get_thread.
>>
>>         Bertrand.
>>
>>
>>             Thanks,
>>             David
>>
>>                 Regards,
>>
>>                 Bertrand.
>>
>>
>>
>>                 On 23/11/2015 08:03, David Holmes wrote:
>>
>>                     After all the preliminary discussions here are final
>>                     proposed changes:
>>
>>                     bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                     Open webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>
>>                     A simple (in principle) but wide-ranging change
>>                     which should appeal to
>>                     our Code Deletion Engineer's. We implement
>>                     Thread::current() using a
>>                     compiler/language-based thread-local variable eg:
>>
>>                        static __thread Thread *_thr_current;
>>
>>                        inline Thread* Thread::current() {
>>                          return _thr_current;
>>                        }
>>
>>                     with an appropriate setter of course. By doing this
>>                     we can completely
>>                     remove the os_cpu-specific ThreadLocalStorage
>>                     implementations, and the
>>                     associated os::thread_local_storage* calls.
>>
>>                     As __thread is not async-signal-safe (either in
>>                     theory or practice) we
>>                     need a fallback library-based solution as used
>>                     today. For this we use a
>>                     very simple ThreadLocalStorage class and an
>>                     implementation thereof for
>>                     POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>                     pthread_get/setspecific; and one for Windows using
>>                     its TLS library.
>>                     While these library routines are not guaranteed
>>                     async-signal-safe, they
>>                     seem to be in practice and are what we have been
>>                     using all along.
>>
>>                     We also allow for use of only the library-based TLS
>>                     for platforms where
>>                     compiler-based thread locals are not supported (as
>>                     will be needed in
>>                     the
>>                     Mobile project). This is enabled at build time by
>>                     defining
>>                     USE_LIBRARY_BASED_TLS_ONLY.
>>
>>                     Thanks to Andrew Haley for providing the Aarch64
>>                     code; and for Thomas
>>                     Stuefe for testing PPC and AIX.
>>
>>                     Testing:
>>                        - JPRT (core platforms)
>>                        - Jtreg tests (linux & solaris)
>>                        - vm.runtime (core platforms)
>>
>>                     Performance:
>>                        - still TBD - this is proving to be extremely
>>                     difficult. If anyone
>>                     has
>>                     any simple to run microbenchmarks to suggest I'd
>>                     give them a try as a
>>                     sanity check. But I lack access to hardware for
>>                     running serious
>>                     benchmarking.
>>
>>                     Footprint:
>>                     - varies by platform and the VM (server, client,
>>                     minimal)
>>                     - worst-case: ~1% increase for server VM and minimal
>> VM
>>                     - best-case:  0.4% decrease for client VM
>>
>>                     Thanks,
>>                     David
>>
>>
>>
>>
>>
>>
>>
>
> --
> Bertrand Delsart,                     Grenoble Engineering Center
> Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
> 38330 Montbonnot Saint Martin,                             FRANCE
> bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of
> the original message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

From david.holmes at oracle.com  Wed Nov 25 13:10:33 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Nov 2015 23:10:33 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
Message-ID: <5655B349.9070700@oracle.com>

On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>
> On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
> <bertrand.delsart at oracle.com <mailto:bertrand.delsart at oracle.com>> wrote:
>
>     Good finding Thomas,
>
>     On 25/11/2015 09:40, Thomas St?fe wrote:
>
>         Hi David, Bertrand,
>
>         about
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>
>         I am not sure this is correct for Windows x64.
>
>
>     Unless I'm misreading it, the new code looks a lot like the old one
>     (including the alignement part). Hence this does not look like a
>     regression caused by David's change.
>
>
> Yes, this seems like an old bug.
>
> I also see that this is fixed in our codebase since 2010, exactly the
> way you propose (with MacroAssembler
> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
> So, it is already used since five years. I would propose opening a
> separate bug for this one and we contribute our fix.

That sounds good to me too. I also suspect additional code will need to 
be checked as this stack alignment is performed in a few places in 
./cpu/x86/vm/macroAssembler_x86.cpp with no OS specific differences 
being considered.

Thanks,
David

> Regards, Thomas
>
>
>         https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>
>         windows x64 Abi requires the register parameter area right above the
>         return address on the stack. It is not guaranteed to be
>         preserved during
>         the function call:
>
>         "Even if the called function has fewer than 4 parameters, these
>         4 stack
>         locations are effectively owned by the called function, and may
>         be used
>         by the called function for other purposes besides saving parameter
>         register values. Thus the caller may not save information in
>         this region
>         of stack across a function call."
>
>         So, restoring parameters from it may not work if
>         Thread::current() uses
>         this area for any reason. In this case, r9, rsp, r10, r11 may be
>         overwritten by the callee.
>
>         I also think Windows x64 ABI is different enough from Linux that
>         this
>         function could live somewhere in <os>_<cpu>.
>
>
>     This is a valid point. However, note that this is similar to the
>     issue we have for instance in 'shared'
>     MacroAssembler::call_VM_leaf_base, which was not put in <os>_<cpu>
>     files.
>
>     In fact, the right fix may be to use call_VM_leaf instead of call :-)
>
>     (alternatively we could use "#ifdef _WIN64" or check
>     "frame::arg_reg_save_area_bytes != 0", which may be even cleaner and
>     more portable)
>
>     All these solutions are fine for me.
>
>
>     Since we are near to feature freeze, this should probably be done in
>     a separate CR (unless David has enough time to test it).
>
>     Regards,
>
>     Bertrand.
>
>
>         Kind Regards, Thomas
>
>
>
>
>         On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>
>                  On 23/11/2015 13:27, David Holmes wrote:
>
>                      Hi Bertrand,
>
>                      On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>
>                          Hi David,
>
>                          Overall looks good.
>                          Thanks for the #ifndef
>         USE_LIBRARY_BASED_TLS_ONLY :-)
>
>                          One doubt, in case this has not been discussed
>         before.
>
>                          I'm still catching up on x86_64 (after years of ARM
>                          assembly :-)) but it
>                          seems that there are some stack alignment
>         constraints on
>                          runtime calls,
>                          at least for some x86_64 ABIs.
>
>                          Some of the x86 MacroAssembler::get_thread
>                          implementations had code to
>                          align the stack before calling
>         pthread_getspecific. See
>                          for instance
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>
>
>
>                      Sorry I'm not that familiar with the MacroAssembler
>         - is it
>                      this odd
>                      fragment:
>
>                      -   push(r10);
>                      -   // XXX
>                      -   mov(r10, rsp);
>                      -   andq(rsp, -16);
>                      -   push(r10);
>
>                      I'm not at all clear what that is doing - and if it
>         somehow
>                      changes the
>                      alignment wouldn't something need to be fixed up when
>                      popping the
>                      previous values ??
>
>                      To be honest I'm not even sure what an "unaligned
>         stack" means.
>
>
>                  On some platforms, SP may have to be aligned on a 16 bytes
>                  boundary when
>                  calling another method.
>
>
>              Okay - that seems to be an x64 ABI requirement based on
>         other code
>              in MacroAssembler. The reason it is missing in the Solaris
>         code is
>              because I already removed it in the earlier changes that
>         were done
>              on Solaris:
>
>         http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>
>              and nobody picked it up. :(
>
>              That said, the absence of this code has not caused any
>         problems so
>              presumably we are normally aligned.
>
>                  After having pushed what needed to be saved, the code above
>                  rounds SP
>                  down and saves the old value. It will then also push
>         r11, which
>                  results
>                  in the expected alignment.
>
>                  The conterpart, after the VM call, is the:
>                     pop(r11);
>                     pop(rsp);
>
>
>              I had assumed this extra manipulation was related to
>         pushing the arg
>              for the call.
>
>                          This alignment is no longer performed in the new
>                          (shared) implementation
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>
>
>
>
>                          Now, Solaris was not performing the alignment and
>                          Windows has a separate
>                          path for x86_64. Did we really need the
>         alignment for
>                          linux x86_64 and
>                          bsd_x86_64 ? Might it be needed for other ports ?
>
>                          IMHO, it might be safer to align the stack by
>         default,
>                          knowing it should
>                          not be expensive since we call get_thread
>         rarely for
>                          x86_64 (result is
>                          cached in r15). I'll let you see whether it is
>         worth
>                          adding an ifdef so
>                          as to explicitly deactivate the alignment on
>         some platforms
>                          (solaris_x86_64 ?)
>
>
>                      I don't have enough knowledge to even begin to
>         comment on
>                      this. I will
>                      have to rely on our x86_64 macroassembler experts
>         to explain
>                      the old
>                      code and what the requirements are.
>
>
>                  OK. This means that the alignment was not removed
>         purposefully.
>
>                  In that case, you must either keep the per platform
>         code x86_64
>                  (since
>                  it was not identical for all platforms) or use the safest
>                  version, with
>                  the additional
>
>                       // XXX
>                       mov(r10, rsp);
>                       andq(rsp, -16);
>                       push(r10);
>
>                  before the push(r11) and with the
>
>                       pop(rsp);
>
>                  after the pop(r11). It should work on all x86_64 platforms.
>
>
>              Right, I will add this back to the code - and replace the
>              meaningless // XXX with an actual comment!
>
>              Many thanks,
>              David
>              -----
>
>
>                  FYI, there is another way to do the alignment, based on
>         the fact
>                  that
>                  we are at least aligned on 8 bytes (see
>                  MacroAssembler::call_VM_leaf_base). I assume that this
>         second
>                  version is
>                  more efficient (particularly thanks to specilative
>         branches) but it
>                  might be safer/simpler to continue using andq in
>         get_thread.
>
>                  Bertrand.
>
>
>                      Thanks,
>                      David
>
>                          Regards,
>
>                          Bertrand.
>
>
>
>                          On 23/11/2015 08:03, David Holmes wrote:
>
>                              After all the preliminary discussions here
>         are final
>                              proposed changes:
>
>                              bug:
>         https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                              Open webrev:
>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
>                              A simple (in principle) but wide-ranging change
>                              which should appeal to
>                              our Code Deletion Engineer's. We implement
>                              Thread::current() using a
>                              compiler/language-based thread-local
>         variable eg:
>
>                                 static __thread Thread *_thr_current;
>
>                                 inline Thread* Thread::current() {
>                                   return _thr_current;
>                                 }
>
>                              with an appropriate setter of course. By
>         doing this
>                              we can completely
>                              remove the os_cpu-specific ThreadLocalStorage
>                              implementations, and the
>                              associated os::thread_local_storage* calls.
>
>                              As __thread is not async-signal-safe (either in
>                              theory or practice) we
>                              need a fallback library-based solution as used
>                              today. For this we use a
>                              very simple ThreadLocalStorage class and an
>                              implementation thereof for
>                              POSIX (covers AIX, BSD, Linux, OSX and
>         Solaris) using
>                              pthread_get/setspecific; and one for
>         Windows using
>                              its TLS library.
>                              While these library routines are not guaranteed
>                              async-signal-safe, they
>                              seem to be in practice and are what we have
>         been
>                              using all along.
>
>                              We also allow for use of only the
>         library-based TLS
>                              for platforms where
>                              compiler-based thread locals are not
>         supported (as
>                              will be needed in
>                              the
>                              Mobile project). This is enabled at build
>         time by
>                              defining
>                              USE_LIBRARY_BASED_TLS_ONLY.
>
>                              Thanks to Andrew Haley for providing the
>         Aarch64
>                              code; and for Thomas
>                              Stuefe for testing PPC and AIX.
>
>                              Testing:
>                                 - JPRT (core platforms)
>                                 - Jtreg tests (linux & solaris)
>                                 - vm.runtime (core platforms)
>
>                              Performance:
>                                 - still TBD - this is proving to be
>         extremely
>                              difficult. If anyone
>                              has
>                              any simple to run microbenchmarks to
>         suggest I'd
>                              give them a try as a
>                              sanity check. But I lack access to hardware for
>                              running serious
>                              benchmarking.
>
>                              Footprint:
>                              - varies by platform and the VM (server,
>         client,
>                              minimal)
>                              - worst-case: ~1% increase for server VM
>         and minimal VM
>                              - best-case:  0.4% decrease for client VM
>
>                              Thanks,
>                              David
>
>
>
>
>
>
>
>
>     --
>     Bertrand Delsart,                     Grenoble Engineering Center
>     Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
>     38330 Montbonnot Saint Martin,                             FRANCE
>     bertrand.delsart at oracle.com <mailto:bertrand.delsart at oracle.com>
>               Phone : +33 4 76 18 81 23
>
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     NOTICE: This email message is for the sole use of the intended
>     recipient(s) and may contain confidential and privileged
>     information. Any unauthorized review, use, disclosure or
>     distribution is prohibited. If you are not the intended recipient,
>     please contact the sender by reply email and destroy all copies of
>     the original message.
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>

From george.triantafillou at oracle.com  Wed Nov 25 13:20:30 2015
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Wed, 25 Nov 2015 08:20:30 -0500
Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework
	needs to handle VM error codes in some cases
In-Reply-To: <56557442.2080408@oracle.com>
References: <56557442.2080408@oracle.com>
Message-ID: <5655B59E.8020804@oracle.com>

Hi Dmitry,

Your changes look good.  One nit, will you change 
TestOptionsWithRanges.java from

80         /* Shared flags can cause JVM to exit with 2 error code */

to

80         /* Shared flags can cause JVM to exit with error code 2 */

Thanks.

-George

On 11/25/2015 3:41 AM, Dmitry Dmitriev wrote:
> Hello,
>
> Please review this small enhancement to the command line options 
> validation test framework. This enhancement allow to specify allowed 
> exit code for flags. This is needed for CDS Shared flags, because in 
> some cases JVM can exit with error code 2 and this should not be 
> treated as error. Also, in this fix I refactor code which parse Shared 
> flags - specify explicit names of the flags in switch statement and 
> use only one CDS archive file.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874
> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eddmitriev/8142874/webrev.01/>
> Testing: tested on all platforms by RBT
>
> Thanks,
> Dmitry


From dmitry.dmitriev at oracle.com  Wed Nov 25 13:23:41 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 25 Nov 2015 16:23:41 +0300
Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework
	needs to handle VM error codes in some cases
In-Reply-To: <5655B59E.8020804@oracle.com>
References: <56557442.2080408@oracle.com> <5655B59E.8020804@oracle.com>
Message-ID: <5655B65D.4000804@oracle.com>

Hi George,

Thank you for the review! I will correct comment as you suggested!

Dmitry

On 25.11.2015 16:20, George Triantafillou wrote:
> Hi Dmitry,
>
> Your changes look good.  One nit, will you change 
> TestOptionsWithRanges.java from
>
> 80         /* Shared flags can cause JVM to exit with 2 error code */
>
> to
>
> 80         /* Shared flags can cause JVM to exit with error code 2 */
>
> Thanks.
>
> -George
>
> On 11/25/2015 3:41 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this small enhancement to the command line options 
>> validation test framework. This enhancement allow to specify allowed 
>> exit code for flags. This is needed for CDS Shared flags, because in 
>> some cases JVM can exit with error code 2 and this should not be 
>> treated as error. Also, in this fix I refactor code which parse 
>> Shared flags - specify explicit names of the flags in switch 
>> statement and use only one CDS archive file.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874
>> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eddmitriev/8142874/webrev.01/>
>> Testing: tested on all platforms by RBT
>>
>> Thanks,
>> Dmitry
>


From stanislav.smirnov at oracle.com  Wed Nov 25 14:06:28 2015
From: stanislav.smirnov at oracle.com (Stas Smirnov)
Date: Wed, 25 Nov 2015 17:06:28 +0300
Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework
	needs to handle VM error codes in some cases
In-Reply-To: <56557442.2080408@oracle.com>
References: <56557442.2080408@oracle.com>
Message-ID: <5655C064.8080109@oracle.com>

Hi Dmitry,

changes look good


On 25/11/15 11:41, Dmitry Dmitriev wrote:
> Hello,
>
> Please review this small enhancement to the command line options 
> validation test framework. This enhancement allow to specify allowed 
> exit code for flags. This is needed for CDS Shared flags, because in 
> some cases JVM can exit with error code 2 and this should not be 
> treated as error. Also, in this fix I refactor code which parse Shared 
> flags - specify explicit names of the flags in switch statement and 
> use only one CDS archive file.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874
> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eddmitriev/8142874/webrev.01/>
> Testing: tested on all platforms by RBT
>
> Thanks,
> Dmitry


From daniel.daugherty at oracle.com  Wed Nov 25 14:29:46 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 25 Nov 2015 07:29:46 -0700
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5655420A.4090805@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
	<5653C930.5090602@oracle.com> <5655102D.20502@oracle.com>
	<5655420A.4090805@oracle.com>
Message-ID: <5655C5DA.2090904@oracle.com>

On 11/24/15 10:07 PM, David Holmes wrote:
> Hi Dan,
>
> Many thanks for the meticulous review!

You're welcome.


>
> On 25/11/2015 11:34 AM, Daniel D. Daugherty wrote:
>> On 11/23/15 7:19 PM, David Holmes wrote:
>>> Sorry about that:
>>>
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>
>> Please double check the copyright updates before you push.
>
> Did you notice something missing? I use:
>
> hg status -man | xargs grep Copyright | grep -v 2015
>
> to find any copyright lines without 2015 present (it turns up the 
> non-Oracle copyrights in a few files).

src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp

L2  * Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights 
reserved.

>
> Trimming to files with comments ...
>
>> src/os/windows/vm/os_windows.cpp
>>      L5998:       os::os_exception_wrapper(
>> (java_call_t)call_wrapper_dummy,
>>          Wrong indent; should only be two spaces.
>>          Please delete space after first '('.
>>
>>      L5999:                                 NULL, NULL, NULL, NULL);
>>          Indent will have to change to match any fixes on previous line.
>
> Fixed.
>
>> src/os/windows/vm/os_windows.hpp
>>      L127:   static inline void set_thread_ptr_offset( int offset ) {
>>          Please delete space after '(' and before ')'.
>
> Fixed (was a copy of code from now deleted file)
>
>> src/share/vm/gc/parallel/gcTaskThread.cpp
>>      No comments.
>>
>>      Note: blank first line in this file (not your change)
>
> Fixed.
>
>> src/share/vm/prims/jni.cpp
>>      L4312:   // If the thread has already been detached the operations
>> is a no-op
>>          Typo: 'the operations is a' -> 'the operation is a'
>
> Fixed
>
>> src/share/vm/prims/jvmtiExport.cpp
>>      L377:       JavaThread* current_thread = JavaThread::current();
>>          Wrong indent; two less spaces
>
> Fixed.
>
>> src/share/vm/runtime/threadLocalStorage.hpp
>>      L37: // Platforms without compiler-based TLS (ie __thread
>> storage-class modifier)
>>          Typo: 'ie' -> 'i.e.'
>
> Fixed.
>
>> src/share/vm/runtime/vm_operations.cpp
>>
>>      (old) L396:   Thread * thr_cur =
>> ThreadLocalStorage::get_thread_slow();
>>      (new) L396:   Thread * thr_cur = Thread::current();
>>
>>          I think this should be 'current_or_null()' like L374.
>
> Actually L374 should just be Thread::current() as NULL is neither 
> possible nor expected. These VM_Exit routines can only be called by an 
> attached thread. E.g. set_vm_exited is only called from 
> Threads::destroy_vm(), while wait_for_threads_in_native_to_block is 
> only called on the VMThread.
>
>> src/os/posix/vm/threadLocalStorage_posix.cpp
>>      L38:     ThreadLocalStorage::set_thread((Thread*) p);
>>          Wrong indent; should be two spaces.
>
> Fixed.
>
>> src/os/windows/vm/threadLocalStorage_windows.cpp
>>      L54:   assert(current != 0 || GetLastError() == ERROR_SUCCESS, '
>>          'current != 0' -> 'current != NULL'
>>          jcheck will complain about the blank at the end of this line
>>
>>      L62:   assert(res, "TlsSetValue failed with error code: %lu",
>> GetLastError());
>>          jcheck will complain about the blank at the end of this line
>
> Fixed.

I missed flagging that this line:

     L55:          "TlsGetValue failed with error code: %lu", 
GetLastError());

also ends with a blank. Sorry about that.

>
> Generated new webrev:
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/

Re-reviewed by comparing the v7 and v8 patch files.

Thumbs up!

Dan

>
> which has been rebased to current hs-rt content.
>
> Thanks,
> David
>
>>
>> Dan
>>
>>
>>>
>>> David
>>>
>>> On 24/11/2015 11:17 AM, David Holmes wrote:
>>>> Updated webrev:
>>>>
>>>> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>>>
>>>> Only change is in macroAssembler_x86.cpp
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 24/11/2015 7:42 AM, David Holmes wrote:
>>>>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>>>> On 23/11/2015 13:27, David Holmes wrote:
>>>>>>> Hi Bertrand,
>>>>>>>
>>>>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Overall looks good.
>>>>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>>>>
>>>>>>>> One doubt, in case this has not been discussed before.
>>>>>>>>
>>>>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>>>>> but it
>>>>>>>> seems that there are some stack alignment constraints on runtime
>>>>>>>> calls,
>>>>>>>> at least for some x86_64 ABIs.
>>>>>>>>
>>>>>>>> Some of the x86 MacroAssembler::get_thread implementations had
>>>>>>>> code to
>>>>>>>> align the stack before calling pthread_getspecific. See for 
>>>>>>>> instance
>>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Sorry I'm not that familiar with the MacroAssembler - is it this 
>>>>>>> odd
>>>>>>> fragment:
>>>>>>>
>>>>>>> -   push(r10);
>>>>>>> -   // XXX
>>>>>>> -   mov(r10, rsp);
>>>>>>> -   andq(rsp, -16);
>>>>>>> -   push(r10);
>>>>>>>
>>>>>>> I'm not at all clear what that is doing - and if it somehow
>>>>>>> changes the
>>>>>>> alignment wouldn't something need to be fixed up when popping the
>>>>>>> previous values ??
>>>>>>>
>>>>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>>>>
>>>>>> On some platforms, SP may have to be aligned on a 16 bytes boundary
>>>>>> when
>>>>>> calling another method.
>>>>>
>>>>> Okay - that seems to be an x64 ABI requirement based on other code in
>>>>> MacroAssembler. The reason it is missing in the Solaris code is 
>>>>> because
>>>>> I already removed it in the earlier changes that were done on 
>>>>> Solaris:
>>>>>
>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>>>
>>>>> and nobody picked it up. :(
>>>>>
>>>>> That said, the absence of this code has not caused any problems so
>>>>> presumably we are normally aligned.
>>>>>
>>>>>> After having pushed what needed to be saved, the code above 
>>>>>> rounds SP
>>>>>> down and saves the old value. It will then also push r11, which
>>>>>> results
>>>>>> in the expected alignment.
>>>>>>
>>>>>> The conterpart, after the VM call, is the:
>>>>>>   pop(r11);
>>>>>>   pop(rsp);
>>>>>
>>>>> I had assumed this extra manipulation was related to pushing the arg
>>>>> for
>>>>> the call.
>>>>>
>>>>>>>> This alignment is no longer performed in the new (shared)
>>>>>>>> implementation
>>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>>>>> separate
>>>>>>>> path for x86_64. Did we really need the alignment for linux
>>>>>>>> x86_64 and
>>>>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>>>>
>>>>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>>>>> should
>>>>>>>> not be expensive since we call get_thread rarely for x86_64
>>>>>>>> (result is
>>>>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>>>>> ifdef so
>>>>>>>> as to explicitly deactivate the alignment on some platforms
>>>>>>>> (solaris_x86_64 ?)
>>>>>>>
>>>>>>> I don't have enough knowledge to even begin to comment on this. I
>>>>>>> will
>>>>>>> have to rely on our x86_64 macroassembler experts to explain the 
>>>>>>> old
>>>>>>> code and what the requirements are.
>>>>>>
>>>>>> OK. This means that the alignment was not removed purposefully.
>>>>>>
>>>>>> In that case, you must either keep the per platform code x86_64 
>>>>>> (since
>>>>>> it was not identical for all platforms) or use the safest version,
>>>>>> with
>>>>>> the additional
>>>>>>
>>>>>>     // XXX
>>>>>>     mov(r10, rsp);
>>>>>>     andq(rsp, -16);
>>>>>>     push(r10);
>>>>>>
>>>>>> before the push(r11) and with the
>>>>>>
>>>>>>     pop(rsp);
>>>>>>
>>>>>> after the pop(r11). It should work on all x86_64 platforms.
>>>>>
>>>>> Right, I will add this back to the code - and replace the
>>>>> meaningless //
>>>>> XXX with an actual comment!
>>>>>
>>>>> Many thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>> FYI, there is another way to do the alignment, based on the fact 
>>>>>> that
>>>>>> we are at least aligned on 8 bytes (see
>>>>>> MacroAssembler::call_VM_leaf_base). I assume that this second
>>>>>> version is
>>>>>> more efficient (particularly thanks to specilative branches) but it
>>>>>> might be safer/simpler to continue using andq in get_thread.
>>>>>>
>>>>>> Bertrand.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Bertrand.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>>>>> After all the preliminary discussions here are final proposed
>>>>>>>>> changes:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>>>>
>>>>>>>>> Open webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>>>>
>>>>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>>>>> appeal to
>>>>>>>>> our Code Deletion Engineer's. We implement Thread::current()
>>>>>>>>> using a
>>>>>>>>> compiler/language-based thread-local variable eg:
>>>>>>>>>
>>>>>>>>>   static __thread Thread *_thr_current;
>>>>>>>>>
>>>>>>>>>   inline Thread* Thread::current() {
>>>>>>>>>     return _thr_current;
>>>>>>>>>   }
>>>>>>>>>
>>>>>>>>> with an appropriate setter of course. By doing this we can
>>>>>>>>> completely
>>>>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations, 
>>>>>>>>> and
>>>>>>>>> the
>>>>>>>>> associated os::thread_local_storage* calls.
>>>>>>>>>
>>>>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>>>>> practice) we
>>>>>>>>> need a fallback library-based solution as used today. For this we
>>>>>>>>> use a
>>>>>>>>> very simple ThreadLocalStorage class and an implementation 
>>>>>>>>> thereof
>>>>>>>>> for
>>>>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>>>>> pthread_get/setspecific; and one for Windows using its TLS 
>>>>>>>>> library.
>>>>>>>>> While these library routines are not guaranteed 
>>>>>>>>> async-signal-safe,
>>>>>>>>> they
>>>>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>>>>
>>>>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>>>>> where
>>>>>>>>> compiler-based thread locals are not supported (as will be
>>>>>>>>> needed in
>>>>>>>>> the
>>>>>>>>> Mobile project). This is enabled at build time by defining
>>>>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>>>>
>>>>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for
>>>>>>>>> Thomas
>>>>>>>>> Stuefe for testing PPC and AIX.
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>>   - JPRT (core platforms)
>>>>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>>>>   - vm.runtime (core platforms)
>>>>>>>>>
>>>>>>>>> Performance:
>>>>>>>>>   - still TBD - this is proving to be extremely difficult. If
>>>>>>>>> anyone
>>>>>>>>> has
>>>>>>>>> any simple to run microbenchmarks to suggest I'd give them a try
>>>>>>>>> as a
>>>>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>>>>> benchmarking.
>>>>>>>>>
>>>>>>>>> Footprint:
>>>>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>


From dmitry.dmitriev at oracle.com  Wed Nov 25 14:37:11 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 25 Nov 2015 17:37:11 +0300
Subject: RFR(S): 8142874: [TESTBUG] OptionsValidation testing framework
	needs to handle VM error codes in some cases
In-Reply-To: <5655C064.8080109@oracle.com>
References: <56557442.2080408@oracle.com> <5655C064.8080109@oracle.com>
Message-ID: <5655C797.9010902@oracle.com>

Hi Stas,

Thank you for the review!

Dmitry

On 25.11.2015 17:06, Stas Smirnov wrote:
> Hi Dmitry,
>
> changes look good
>
>
> On 25/11/15 11:41, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this small enhancement to the command line options 
>> validation test framework. This enhancement allow to specify allowed 
>> exit code for flags. This is needed for CDS Shared flags, because in 
>> some cases JVM can exit with error code 2 and this should not be 
>> treated as error. Also, in this fix I refactor code which parse 
>> Shared flags - specify explicit names of the flags in switch 
>> statement and use only one CDS archive file.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8142874
>> webrev: http://cr.openjdk.java.net/~ddmitriev/8142874/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eddmitriev/8142874/webrev.01/>
>> Testing: tested on all platforms by RBT
>>
>> Thanks,
>> Dmitry
>


From coleen.phillimore at oracle.com  Wed Nov 25 14:42:04 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 25 Nov 2015 09:42:04 -0500
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <56557936.3070109@oracle.com>
References: <56557936.3070109@oracle.com>
Message-ID: <5655C8BC.80708@oracle.com>


This is how I fixed it yesterday.

#if INCLUDE_JVMCI
  public:
   static int compare(DIR_Chunk* const & a, DIR_Chunk* const & b) {

I just made the compare function public, not all the other things.

Coleen

On 11/25/15 4:02 AM, Erik Joelsson wrote:
> Hello,
>
> The following new build failure has appeared in the hotspot build when 
> using the proposed new compiler version on Solaris, SS12u4.
>
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&, 
> DIR_Chunk*const&) is not accessible from 
> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
> line 281: Where: While instantiating 
> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
> line 281: Where: Instantiated from non-template code.
>
> Tom Rodriguez provided a patch and I have verified that it solves the 
> issue. Since this is blocking us upgrading compilers on Solaris, I am 
> taking the liberty of posting it for review so we may get this 
> resolved quickly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>
> /Erik


From coleen.phillimore at oracle.com  Wed Nov 25 14:47:37 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 25 Nov 2015 09:47:37 -0500
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <56557936.3070109@oracle.com>
References: <56557936.3070109@oracle.com>
Message-ID: <5655CA09.6020001@oracle.com>


I don't think this change will compile with INCLUDE_JVMCI off either.
Coleen

On 11/25/15 4:02 AM, Erik Joelsson wrote:
> Hello,
>
> The following new build failure has appeared in the hotspot build when 
> using the proposed new compiler version on Solaris, SS12u4.
>
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&, 
> DIR_Chunk*const&) is not accessible from 
> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
> line 281: Where: While instantiating 
> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
> line 281: Where: Instantiated from non-template code.
>
> Tom Rodriguez provided a patch and I have verified that it solves the 
> issue. Since this is blocking us upgrading compilers on Solaris, I am 
> taking the liberty of posting it for review so we may get this 
> resolved quickly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>
> /Erik


From daniel.daugherty at oracle.com  Wed Nov 25 14:52:41 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 25 Nov 2015 07:52:41 -0700
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5655B349.9070700@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com>
Message-ID: <5655CB39.3030007@oracle.com>

On 11/25/15 6:10 AM, David Holmes wrote:
> On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>>
>> On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
>> <bertrand.delsart at oracle.com <mailto:bertrand.delsart at oracle.com>> 
>> wrote:
>>
>>     Good finding Thomas,
>>
>>     On 25/11/2015 09:40, Thomas St?fe wrote:
>>
>>         Hi David, Bertrand,
>>
>>         about
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>
>>         I am not sure this is correct for Windows x64.
>>
>>
>>     Unless I'm misreading it, the new code looks a lot like the old one
>>     (including the alignement part). Hence this does not look like a
>>     regression caused by David's change.
>>
>>
>> Yes, this seems like an old bug.
>>
>> I also see that this is fixed in our codebase since 2010, exactly the
>> way you propose (with MacroAssembler
>> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base 
>>
>> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>). 
>>
>> So, it is already used since five years. I would propose opening a
>> separate bug for this one and we contribute our fix.
>
> That sounds good to me too. I also suspect additional code will need 
> to be checked as this stack alignment is performed in a few places in 
> ./cpu/x86/vm/macroAssembler_x86.cpp with no OS specific differences 
> being considered.

Looks like MacroAssembler::call_VM_leaf_base() does the "right thing"
for stack alignment in the X64 case. Perhaps we need to audit both
stack alignment _and_ uses of MacroAssembler::call() just to make
sure...

Did I mention that all the assembly code stuff gives me a headache? :-)

Dan


>
> Thanks,
> David
>
>> Regards, Thomas
>>
>>
>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>
>>         windows x64 Abi requires the register parameter area right 
>> above the
>>         return address on the stack. It is not guaranteed to be
>>         preserved during
>>         the function call:
>>
>>         "Even if the called function has fewer than 4 parameters, these
>>         4 stack
>>         locations are effectively owned by the called function, and may
>>         be used
>>         by the called function for other purposes besides saving 
>> parameter
>>         register values. Thus the caller may not save information in
>>         this region
>>         of stack across a function call."
>>
>>         So, restoring parameters from it may not work if
>>         Thread::current() uses
>>         this area for any reason. In this case, r9, rsp, r10, r11 may be
>>         overwritten by the callee.
>>
>>         I also think Windows x64 ABI is different enough from Linux that
>>         this
>>         function could live somewhere in <os>_<cpu>.
>>
>>
>>     This is a valid point. However, note that this is similar to the
>>     issue we have for instance in 'shared'
>>     MacroAssembler::call_VM_leaf_base, which was not put in <os>_<cpu>
>>     files.
>>
>>     In fact, the right fix may be to use call_VM_leaf instead of call 
>> :-)
>>
>>     (alternatively we could use "#ifdef _WIN64" or check
>>     "frame::arg_reg_save_area_bytes != 0", which may be even cleaner and
>>     more portable)
>>
>>     All these solutions are fine for me.
>>
>>
>>     Since we are near to feature freeze, this should probably be done in
>>     a separate CR (unless David has enough time to test it).
>>
>>     Regards,
>>
>>     Bertrand.
>>
>>
>>         Kind Regards, Thomas
>>
>>
>>
>>
>>         On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>         <mailto:david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.com>>> wrote:
>>
>>              On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>
>>                  On 23/11/2015 13:27, David Holmes wrote:
>>
>>                      Hi Bertrand,
>>
>>                      On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>
>>                          Hi David,
>>
>>                          Overall looks good.
>>                          Thanks for the #ifndef
>>         USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>>                          One doubt, in case this has not been discussed
>>         before.
>>
>>                          I'm still catching up on x86_64 (after years 
>> of ARM
>>                          assembly :-)) but it
>>                          seems that there are some stack alignment
>>         constraints on
>>                          runtime calls,
>>                          at least for some x86_64 ABIs.
>>
>>                          Some of the x86 MacroAssembler::get_thread
>>                          implementations had code to
>>                          align the stack before calling
>>         pthread_getspecific. See
>>                          for instance
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>>
>>
>>                      Sorry I'm not that familiar with the MacroAssembler
>>         - is it
>>                      this odd
>>                      fragment:
>>
>>                      -   push(r10);
>>                      -   // XXX
>>                      -   mov(r10, rsp);
>>                      -   andq(rsp, -16);
>>                      -   push(r10);
>>
>>                      I'm not at all clear what that is doing - and if it
>>         somehow
>>                      changes the
>>                      alignment wouldn't something need to be fixed up 
>> when
>>                      popping the
>>                      previous values ??
>>
>>                      To be honest I'm not even sure what an "unaligned
>>         stack" means.
>>
>>
>>                  On some platforms, SP may have to be aligned on a 16 
>> bytes
>>                  boundary when
>>                  calling another method.
>>
>>
>>              Okay - that seems to be an x64 ABI requirement based on
>>         other code
>>              in MacroAssembler. The reason it is missing in the Solaris
>>         code is
>>              because I already removed it in the earlier changes that
>>         were done
>>              on Solaris:
>>
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>
>>              and nobody picked it up. :(
>>
>>              That said, the absence of this code has not caused any
>>         problems so
>>              presumably we are normally aligned.
>>
>>                  After having pushed what needed to be saved, the 
>> code above
>>                  rounds SP
>>                  down and saves the old value. It will then also push
>>         r11, which
>>                  results
>>                  in the expected alignment.
>>
>>                  The conterpart, after the VM call, is the:
>>                     pop(r11);
>>                     pop(rsp);
>>
>>
>>              I had assumed this extra manipulation was related to
>>         pushing the arg
>>              for the call.
>>
>>                          This alignment is no longer performed in the 
>> new
>>                          (shared) implementation
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>>
>>                          Now, Solaris was not performing the 
>> alignment and
>>                          Windows has a separate
>>                          path for x86_64. Did we really need the
>>         alignment for
>>                          linux x86_64 and
>>                          bsd_x86_64 ? Might it be needed for other 
>> ports ?
>>
>>                          IMHO, it might be safer to align the stack by
>>         default,
>>                          knowing it should
>>                          not be expensive since we call get_thread
>>         rarely for
>>                          x86_64 (result is
>>                          cached in r15). I'll let you see whether it is
>>         worth
>>                          adding an ifdef so
>>                          as to explicitly deactivate the alignment on
>>         some platforms
>>                          (solaris_x86_64 ?)
>>
>>
>>                      I don't have enough knowledge to even begin to
>>         comment on
>>                      this. I will
>>                      have to rely on our x86_64 macroassembler experts
>>         to explain
>>                      the old
>>                      code and what the requirements are.
>>
>>
>>                  OK. This means that the alignment was not removed
>>         purposefully.
>>
>>                  In that case, you must either keep the per platform
>>         code x86_64
>>                  (since
>>                  it was not identical for all platforms) or use the 
>> safest
>>                  version, with
>>                  the additional
>>
>>                       // XXX
>>                       mov(r10, rsp);
>>                       andq(rsp, -16);
>>                       push(r10);
>>
>>                  before the push(r11) and with the
>>
>>                       pop(rsp);
>>
>>                  after the pop(r11). It should work on all x86_64 
>> platforms.
>>
>>
>>              Right, I will add this back to the code - and replace the
>>              meaningless // XXX with an actual comment!
>>
>>              Many thanks,
>>              David
>>              -----
>>
>>
>>                  FYI, there is another way to do the alignment, based on
>>         the fact
>>                  that
>>                  we are at least aligned on 8 bytes (see
>>                  MacroAssembler::call_VM_leaf_base). I assume that this
>>         second
>>                  version is
>>                  more efficient (particularly thanks to specilative
>>         branches) but it
>>                  might be safer/simpler to continue using andq in
>>         get_thread.
>>
>>                  Bertrand.
>>
>>
>>                      Thanks,
>>                      David
>>
>>                          Regards,
>>
>>                          Bertrand.
>>
>>
>>
>>                          On 23/11/2015 08:03, David Holmes wrote:
>>
>>                              After all the preliminary discussions here
>>         are final
>>                              proposed changes:
>>
>>                              bug:
>>         https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                              Open webrev:
>>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>
>>                              A simple (in principle) but wide-ranging 
>> change
>>                              which should appeal to
>>                              our Code Deletion Engineer's. We implement
>>                              Thread::current() using a
>>                              compiler/language-based thread-local
>>         variable eg:
>>
>>                                 static __thread Thread *_thr_current;
>>
>>                                 inline Thread* Thread::current() {
>>                                   return _thr_current;
>>                                 }
>>
>>                              with an appropriate setter of course. By
>>         doing this
>>                              we can completely
>>                              remove the os_cpu-specific 
>> ThreadLocalStorage
>>                              implementations, and the
>>                              associated os::thread_local_storage* calls.
>>
>>                              As __thread is not async-signal-safe 
>> (either in
>>                              theory or practice) we
>>                              need a fallback library-based solution 
>> as used
>>                              today. For this we use a
>>                              very simple ThreadLocalStorage class and an
>>                              implementation thereof for
>>                              POSIX (covers AIX, BSD, Linux, OSX and
>>         Solaris) using
>>                              pthread_get/setspecific; and one for
>>         Windows using
>>                              its TLS library.
>>                              While these library routines are not 
>> guaranteed
>>                              async-signal-safe, they
>>                              seem to be in practice and are what we have
>>         been
>>                              using all along.
>>
>>                              We also allow for use of only the
>>         library-based TLS
>>                              for platforms where
>>                              compiler-based thread locals are not
>>         supported (as
>>                              will be needed in
>>                              the
>>                              Mobile project). This is enabled at build
>>         time by
>>                              defining
>>                              USE_LIBRARY_BASED_TLS_ONLY.
>>
>>                              Thanks to Andrew Haley for providing the
>>         Aarch64
>>                              code; and for Thomas
>>                              Stuefe for testing PPC and AIX.
>>
>>                              Testing:
>>                                 - JPRT (core platforms)
>>                                 - Jtreg tests (linux & solaris)
>>                                 - vm.runtime (core platforms)
>>
>>                              Performance:
>>                                 - still TBD - this is proving to be
>>         extremely
>>                              difficult. If anyone
>>                              has
>>                              any simple to run microbenchmarks to
>>         suggest I'd
>>                              give them a try as a
>>                              sanity check. But I lack access to 
>> hardware for
>>                              running serious
>>                              benchmarking.
>>
>>                              Footprint:
>>                              - varies by platform and the VM (server,
>>         client,
>>                              minimal)
>>                              - worst-case: ~1% increase for server VM
>>         and minimal VM
>>                              - best-case:  0.4% decrease for client VM
>>
>>                              Thanks,
>>                              David
>>
>>
>>
>>
>>
>>
>>
>>
>>     --
>>     Bertrand Delsart,                     Grenoble Engineering Center
>>     Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
>>     38330 Montbonnot Saint Martin, FRANCE
>>     bertrand.delsart at oracle.com <mailto:bertrand.delsart at oracle.com>
>>               Phone : +33 4 76 18 81 23
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>     NOTICE: This email message is for the sole use of the intended
>>     recipient(s) and may contain confidential and privileged
>>     information. Any unauthorized review, use, disclosure or
>>     distribution is prohibited. If you are not the intended recipient,
>>     please contact the sender by reply email and destroy all copies of
>>     the original message.
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>


From thomas.stuefe at gmail.com  Wed Nov 25 15:20:57 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Nov 2015 16:20:57 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5652BA32.8090207@oracle.com>
References: <5652BA32.8090207@oracle.com>
Message-ID: <CAA-vtUzTxS3CWcv8pdeMEsv8gxgMLjWOgVgHaUP00VbbYVgx4g@mail.gmail.com>

Hi David,

I looked over your latest version at
http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8

This all looks nice and builds on AIX. I am currently running some jtreg
tests.

Some small remarks:

------------

would it be possible to add a configure option (e.g.
--enable-compiler-based-tls)? On AIX, disabling compiler level tls also
makes the -qtls compiler option unnecessary, so it affects the makefile.

Not really important, just would be quite comfortable.

------------

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/os/windows/vm/os_windows.cpp.udiff.html

@@ -5175,11 +5159,11 @@

-  JavaThread* thread = (JavaThread*)(Thread::current());
+  Thread* thread = Thread::current();
   assert(thread->is_Java_thread(), "Must be JavaThread");
   JavaThread *jt = (JavaThread *)thread;

may be simplified to use your new

JavaThread* thread = JavaThread::current();

------------

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.cpp.udiff.html

in

Thread::clear_thread_current()

we could also add a

assert(Thread::current() == ThreadLocalStorage::thread(), "TLS mismatch!");

to catch a case where library tls slot content changed during lifetime of
thread.

----

 JavaThread* JavaThread::active() {
-  Thread* thread = ThreadLocalStorage::thread();
+  Thread* thread = Thread::current();
   assert(thread != NULL, "just checking");

the assert is unnecessary.

-----

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.hpp.udiff.html

 // Inline implementation of JavaThread::current
 inline JavaThread* JavaThread::current() {
-  Thread* thread = ThreadLocalStorage::thread();
+  Thread* thread = Thread::current();
   assert(thread != NULL && thread->is_Java_thread(), "just checking");
   return (JavaThread*)thread;
 }

asserting thread != NULL is unnecessary.

-----

http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/utilities/globalDefinitions_gcc.hpp.udiff.html

(and corresponding globalDefinitions_.. files)

+#define THREAD_LOCAL_DECL __thread

could be surrounded by #ifndef USE_LIBRARY_BASED_TLS_ONLY

-----

Kind Regards, Thomas








On Mon, Nov 23, 2015 at 8:03 AM, David Holmes <david.holmes at oracle.com>
wrote:

> After all the preliminary discussions here are final proposed changes:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
> Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
> A simple (in principle) but wide-ranging change which should appeal to our
> Code Deletion Engineer's. We implement Thread::current() using a
> compiler/language-based thread-local variable eg:
>
>  static __thread Thread *_thr_current;
>
>  inline Thread* Thread::current() {
>    return _thr_current;
>  }
>
> with an appropriate setter of course. By doing this we can completely
> remove the os_cpu-specific ThreadLocalStorage implementations, and the
> associated os::thread_local_storage* calls.
>
> As __thread is not async-signal-safe (either in theory or practice) we
> need a fallback library-based solution as used today. For this we use a
> very simple ThreadLocalStorage class and an implementation thereof for
> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
> pthread_get/setspecific; and one for Windows using its TLS library. While
> these library routines are not guaranteed async-signal-safe, they seem to
> be in practice and are what we have been using all along.
>
> We also allow for use of only the library-based TLS for platforms where
> compiler-based thread locals are not supported (as will be needed in the
> Mobile project). This is enabled at build time by defining
> USE_LIBRARY_BASED_TLS_ONLY.
>
> Thanks to Andrew Haley for providing the Aarch64 code; and for Thomas
> Stuefe for testing PPC and AIX.
>
> Testing:
>  - JPRT (core platforms)
>  - Jtreg tests (linux & solaris)
>  - vm.runtime (core platforms)
>
> Performance:
>  - still TBD - this is proving to be extremely difficult. If anyone has
> any simple to run microbenchmarks to suggest I'd give them a try as a
> sanity check. But I lack access to hardware for running serious
> benchmarking.
>
> Footprint:
> - varies by platform and the VM (server, client, minimal)
> - worst-case: ~1% increase for server VM and minimal VM
> - best-case:  0.4% decrease for client VM
>
> Thanks,
> David
>

From jaroslav.bachorik at oracle.com  Wed Nov 25 16:41:23 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 25 Nov 2015 17:41:23 +0100
Subject: [ping] Re: RFR 8141526: Allow to collect stdout/stderr from the
	FinalizationRunner even before the process returns
In-Reply-To: <563CD13B.8040800@oracle.com>
References: <563CD13B.8040800@oracle.com>
Message-ID: <5655E4B3.30207@oracle.com>

On 6.11.2015 17:11, Jaroslav Bachorik wrote:
> [wider audience included]
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526
> Webrev:
> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00
> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot
> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk
>
> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we
> are not able to get the debug info about the run of the launcher
> FinalizationRunner application in case it gets stuck and harness times
> out. This is because the stdout/err of the application started via
> ProcessTools.executeProcess() is collected only after the application
> has exited.
>
> The solution is to use ProcessTools.startProcess() and consume the
> application stdout/err in a streaming mode. Because this method has only
> been available in the 'jdk' version of ProcessTools and not in the
> 'hotspot' one I decided to merge both of those versions and place the
> merged version into the shared location 'test/lib/share/classes/'.
> During this I decided to change the package for the shared ProcessTools
> class to be 'jdk.test.lib.process' to be more in line with the way this
> shared library is structured. I had to move few other lib classes
> required by ProcessTools to the shared lib as well. All the moved lib
> classes have been marked as deprecated in their original location.
>
>
> Thanks,
>
> -JB-
>


From thomas.stuefe at gmail.com  Wed Nov 25 16:53:56 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Nov 2015 17:53:56 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5655CB39.3030007@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
Message-ID: <CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>

I created a bug to track this:

https://bugs.openjdk.java.net/browse/JDK-8144059

Because Davids change is not submitted yet, the bug refers to the old
coding, but stays relevant also after this fix.

Kind Regards, Thomas

On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty <
daniel.daugherty at oracle.com> wrote:

> On 11/25/15 6:10 AM, David Holmes wrote:
>
>> On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>>
>>>
>>> On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
>>> <bertrand.delsart at oracle.com <mailto:bertrand.delsart at oracle.com>>
>>> wrote:
>>>
>>>     Good finding Thomas,
>>>
>>>     On 25/11/2015 09:40, Thomas St?fe wrote:
>>>
>>>         Hi David, Bertrand,
>>>
>>>         about
>>>
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>>
>>>         I am not sure this is correct for Windows x64.
>>>
>>>
>>>     Unless I'm misreading it, the new code looks a lot like the old one
>>>     (including the alignement part). Hence this does not look like a
>>>     regression caused by David's change.
>>>
>>>
>>> Yes, this seems like an old bug.
>>>
>>> I also see that this is fixed in our codebase since 2010, exactly the
>>> way you propose (with MacroAssembler
>>> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
>>>
>>> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
>>>
>>> So, it is already used since five years. I would propose opening a
>>> separate bug for this one and we contribute our fix.
>>>
>>
>> That sounds good to me too. I also suspect additional code will need to
>> be checked as this stack alignment is performed in a few places in
>> ./cpu/x86/vm/macroAssembler_x86.cpp with no OS specific differences being
>> considered.
>>
>
> Looks like MacroAssembler::call_VM_leaf_base() does the "right thing"
> for stack alignment in the X64 case. Perhaps we need to audit both
> stack alignment _and_ uses of MacroAssembler::call() just to make
> sure...
>
> Did I mention that all the assembly code stuff gives me a headache? :-)
>
> Dan
>
>
>
>
>> Thanks,
>> David
>>
>> Regards, Thomas
>>>
>>>
>>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>>
>>>         windows x64 Abi requires the register parameter area right above
>>> the
>>>         return address on the stack. It is not guaranteed to be
>>>         preserved during
>>>         the function call:
>>>
>>>         "Even if the called function has fewer than 4 parameters, these
>>>         4 stack
>>>         locations are effectively owned by the called function, and may
>>>         be used
>>>         by the called function for other purposes besides saving
>>> parameter
>>>         register values. Thus the caller may not save information in
>>>         this region
>>>         of stack across a function call."
>>>
>>>         So, restoring parameters from it may not work if
>>>         Thread::current() uses
>>>         this area for any reason. In this case, r9, rsp, r10, r11 may be
>>>         overwritten by the callee.
>>>
>>>         I also think Windows x64 ABI is different enough from Linux that
>>>         this
>>>         function could live somewhere in <os>_<cpu>.
>>>
>>>
>>>     This is a valid point. However, note that this is similar to the
>>>     issue we have for instance in 'shared'
>>>     MacroAssembler::call_VM_leaf_base, which was not put in <os>_<cpu>
>>>     files.
>>>
>>>     In fact, the right fix may be to use call_VM_leaf instead of call :-)
>>>
>>>     (alternatively we could use "#ifdef _WIN64" or check
>>>     "frame::arg_reg_save_area_bytes != 0", which may be even cleaner and
>>>     more portable)
>>>
>>>     All these solutions are fine for me.
>>>
>>>
>>>     Since we are near to feature freeze, this should probably be done in
>>>     a separate CR (unless David has enough time to test it).
>>>
>>>     Regards,
>>>
>>>     Bertrand.
>>>
>>>
>>>         Kind Regards, Thomas
>>>
>>>
>>>
>>>
>>>         On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>>>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>>         <mailto:david.holmes at oracle.com
>>>         <mailto:david.holmes at oracle.com>>> wrote:
>>>
>>>              On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>
>>>                  On 23/11/2015 13:27, David Holmes wrote:
>>>
>>>                      Hi Bertrand,
>>>
>>>                      On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>
>>>                          Hi David,
>>>
>>>                          Overall looks good.
>>>                          Thanks for the #ifndef
>>>         USE_LIBRARY_BASED_TLS_ONLY :-)
>>>
>>>                          One doubt, in case this has not been discussed
>>>         before.
>>>
>>>                          I'm still catching up on x86_64 (after years of
>>> ARM
>>>                          assembly :-)) but it
>>>                          seems that there are some stack alignment
>>>         constraints on
>>>                          runtime calls,
>>>                          at least for some x86_64 ABIs.
>>>
>>>                          Some of the x86 MacroAssembler::get_thread
>>>                          implementations had code to
>>>                          align the stack before calling
>>>         pthread_getspecific. See
>>>                          for instance
>>>
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>
>>>
>>>
>>>                      Sorry I'm not that familiar with the MacroAssembler
>>>         - is it
>>>                      this odd
>>>                      fragment:
>>>
>>>                      -   push(r10);
>>>                      -   // XXX
>>>                      -   mov(r10, rsp);
>>>                      -   andq(rsp, -16);
>>>                      -   push(r10);
>>>
>>>                      I'm not at all clear what that is doing - and if it
>>>         somehow
>>>                      changes the
>>>                      alignment wouldn't something need to be fixed up
>>> when
>>>                      popping the
>>>                      previous values ??
>>>
>>>                      To be honest I'm not even sure what an "unaligned
>>>         stack" means.
>>>
>>>
>>>                  On some platforms, SP may have to be aligned on a 16
>>> bytes
>>>                  boundary when
>>>                  calling another method.
>>>
>>>
>>>              Okay - that seems to be an x64 ABI requirement based on
>>>         other code
>>>              in MacroAssembler. The reason it is missing in the Solaris
>>>         code is
>>>              because I already removed it in the earlier changes that
>>>         were done
>>>              on Solaris:
>>>
>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>
>>>              and nobody picked it up. :(
>>>
>>>              That said, the absence of this code has not caused any
>>>         problems so
>>>              presumably we are normally aligned.
>>>
>>>                  After having pushed what needed to be saved, the code
>>> above
>>>                  rounds SP
>>>                  down and saves the old value. It will then also push
>>>         r11, which
>>>                  results
>>>                  in the expected alignment.
>>>
>>>                  The conterpart, after the VM call, is the:
>>>                     pop(r11);
>>>                     pop(rsp);
>>>
>>>
>>>              I had assumed this extra manipulation was related to
>>>         pushing the arg
>>>              for the call.
>>>
>>>                          This alignment is no longer performed in the new
>>>                          (shared) implementation
>>>
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>
>>>
>>>
>>>
>>>                          Now, Solaris was not performing the alignment
>>> and
>>>                          Windows has a separate
>>>                          path for x86_64. Did we really need the
>>>         alignment for
>>>                          linux x86_64 and
>>>                          bsd_x86_64 ? Might it be needed for other ports
>>> ?
>>>
>>>                          IMHO, it might be safer to align the stack by
>>>         default,
>>>                          knowing it should
>>>                          not be expensive since we call get_thread
>>>         rarely for
>>>                          x86_64 (result is
>>>                          cached in r15). I'll let you see whether it is
>>>         worth
>>>                          adding an ifdef so
>>>                          as to explicitly deactivate the alignment on
>>>         some platforms
>>>                          (solaris_x86_64 ?)
>>>
>>>
>>>                      I don't have enough knowledge to even begin to
>>>         comment on
>>>                      this. I will
>>>                      have to rely on our x86_64 macroassembler experts
>>>         to explain
>>>                      the old
>>>                      code and what the requirements are.
>>>
>>>
>>>                  OK. This means that the alignment was not removed
>>>         purposefully.
>>>
>>>                  In that case, you must either keep the per platform
>>>         code x86_64
>>>                  (since
>>>                  it was not identical for all platforms) or use the
>>> safest
>>>                  version, with
>>>                  the additional
>>>
>>>                       // XXX
>>>                       mov(r10, rsp);
>>>                       andq(rsp, -16);
>>>                       push(r10);
>>>
>>>                  before the push(r11) and with the
>>>
>>>                       pop(rsp);
>>>
>>>                  after the pop(r11). It should work on all x86_64
>>> platforms.
>>>
>>>
>>>              Right, I will add this back to the code - and replace the
>>>              meaningless // XXX with an actual comment!
>>>
>>>              Many thanks,
>>>              David
>>>              -----
>>>
>>>
>>>                  FYI, there is another way to do the alignment, based on
>>>         the fact
>>>                  that
>>>                  we are at least aligned on 8 bytes (see
>>>                  MacroAssembler::call_VM_leaf_base). I assume that this
>>>         second
>>>                  version is
>>>                  more efficient (particularly thanks to specilative
>>>         branches) but it
>>>                  might be safer/simpler to continue using andq in
>>>         get_thread.
>>>
>>>                  Bertrand.
>>>
>>>
>>>                      Thanks,
>>>                      David
>>>
>>>                          Regards,
>>>
>>>                          Bertrand.
>>>
>>>
>>>
>>>                          On 23/11/2015 08:03, David Holmes wrote:
>>>
>>>                              After all the preliminary discussions here
>>>         are final
>>>                              proposed changes:
>>>
>>>                              bug:
>>>         https://bugs.openjdk.java.net/browse/JDK-8132510
>>>
>>>                              Open webrev:
>>>         http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>
>>>                              A simple (in principle) but wide-ranging
>>> change
>>>                              which should appeal to
>>>                              our Code Deletion Engineer's. We implement
>>>                              Thread::current() using a
>>>                              compiler/language-based thread-local
>>>         variable eg:
>>>
>>>                                 static __thread Thread *_thr_current;
>>>
>>>                                 inline Thread* Thread::current() {
>>>                                   return _thr_current;
>>>                                 }
>>>
>>>                              with an appropriate setter of course. By
>>>         doing this
>>>                              we can completely
>>>                              remove the os_cpu-specific
>>> ThreadLocalStorage
>>>                              implementations, and the
>>>                              associated os::thread_local_storage* calls.
>>>
>>>                              As __thread is not async-signal-safe
>>> (either in
>>>                              theory or practice) we
>>>                              need a fallback library-based solution as
>>> used
>>>                              today. For this we use a
>>>                              very simple ThreadLocalStorage class and an
>>>                              implementation thereof for
>>>                              POSIX (covers AIX, BSD, Linux, OSX and
>>>         Solaris) using
>>>                              pthread_get/setspecific; and one for
>>>         Windows using
>>>                              its TLS library.
>>>                              While these library routines are not
>>> guaranteed
>>>                              async-signal-safe, they
>>>                              seem to be in practice and are what we have
>>>         been
>>>                              using all along.
>>>
>>>                              We also allow for use of only the
>>>         library-based TLS
>>>                              for platforms where
>>>                              compiler-based thread locals are not
>>>         supported (as
>>>                              will be needed in
>>>                              the
>>>                              Mobile project). This is enabled at build
>>>         time by
>>>                              defining
>>>                              USE_LIBRARY_BASED_TLS_ONLY.
>>>
>>>                              Thanks to Andrew Haley for providing the
>>>         Aarch64
>>>                              code; and for Thomas
>>>                              Stuefe for testing PPC and AIX.
>>>
>>>                              Testing:
>>>                                 - JPRT (core platforms)
>>>                                 - Jtreg tests (linux & solaris)
>>>                                 - vm.runtime (core platforms)
>>>
>>>                              Performance:
>>>                                 - still TBD - this is proving to be
>>>         extremely
>>>                              difficult. If anyone
>>>                              has
>>>                              any simple to run microbenchmarks to
>>>         suggest I'd
>>>                              give them a try as a
>>>                              sanity check. But I lack access to hardware
>>> for
>>>                              running serious
>>>                              benchmarking.
>>>
>>>                              Footprint:
>>>                              - varies by platform and the VM (server,
>>>         client,
>>>                              minimal)
>>>                              - worst-case: ~1% increase for server VM
>>>         and minimal VM
>>>                              - best-case:  0.4% decrease for client VM
>>>
>>>                              Thanks,
>>>                              David
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     --
>>>     Bertrand Delsart,                     Grenoble Engineering Center
>>>     Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
>>>     38330 Montbonnot Saint Martin, FRANCE
>>>     bertrand.delsart at oracle.com <mailto:bertrand.delsart at oracle.com>
>>>               Phone : +33 4 76 18 81 23
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>     NOTICE: This email message is for the sole use of the intended
>>>     recipient(s) and may contain confidential and privileged
>>>     information. Any unauthorized review, use, disclosure or
>>>     distribution is prohibited. If you are not the intended recipient,
>>>     please contact the sender by reply email and destroy all copies of
>>>     the original message.
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>>
>

From thomas.stuefe at gmail.com  Wed Nov 25 17:01:15 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Nov 2015 18:01:15 +0100
Subject: RFR(L): 8143125: [aix] Further Developments for AIX
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap>
References: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
	<4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap>
Message-ID: <CAA-vtUzZpskQsS7NTxdxV_1VsFpX+jdeBz85WSgx3SKE-1hSTA@mail.gmail.com>

Hi Goetz,

new webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.01/webrev/

thank you for reviewing! See remarks inline...

On Tue, Nov 24, 2015 at 12:38 PM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi Thomas,
>
> I looked at your change.  It?s good we get these improvements into
> openJDK.  But I think we should skip some stuff that's not (yet?)
> used there.  I'll sponsor the change. Details:
>
> libperfstat_aix.cpp:
>
> What do you need
> static fun_perfstat_partition_total_t g_fun_perfstat_partition_total =
> NULL;
> static fun_perfstat_wpar_total_t    g_fun_perfstat_wpar_total = NULL;
> static fun_wpar_getcid_t            g_fun_wpar_getcid = NULL;
> for? I think they are never used.
>
>
They are now used (for the respective wrapper functions which in turn are
used in os_aix.cpp. Sorry for omitting this code.


> libperfstat_aix.cpp:161
> We support AIX 5.3 with xlC12 only. I think we need not add the older
> #defines to openJDK. Also, the comment should be adapted and not mention
> xlc8 etc.
> Also, there are datastructures for 5.2 which can be removed.
>
>
Removed the older defines.
I would for now prefer to leave the AIX 5.2 data structures in this file. I
am not sure if we could encounter older libperfstat versions on AIX 5.3
too. I plan to rework this coding to get rid of the duplicate structure
definitions, but would prefer to do this in a separate patch.



> Where is this used?
> bool libperfstat::get_wparinfo(wparinfo_t* pwi)
> Do we need it if it's not used?
>
>
It is now used :) in os_aix.cpp.



> libperfstat.hpp:835
> I would remove these prototypes commented out.
>
>
I removed them.


> loadlib_aix.cpp
> Why do you do these changes? Please revert them.
>
>
I reverted them.


> os_aix.hpp:219
> What's this good for?
> get_brk_at_startup()
> get_lowest_allocation_above_brk()
>
>
I removed those prototypes.


> os_aix.hpp:259
> What's this good for?
> parse_qsyslib_path()
>
>
I removed this prototype.


> os_aix.cpp:410
> Why do you move query_multipage_support()?
>
>
I moved this back to its original position.


> os_aix.inline.hpp:164
> Why do you reverse the order of the functions here?
> The old order is the same as in the related files os_linux.inline.hpp etc.
>
>
I reversed the order back to original order.


> Best regards,
>   Goetz.
>
>
>
Kind Regards, Thomas


>
> > -----Original Message-----
> > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> > Behalf Of Thomas St?fe
> > Sent: Freitag, 20. November 2015 11:49
> > To: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers
> > Subject: RFR(L): 8143125: [aix] Further Developments for AIX
> >
> > Hi all,
> >
> > please review and sponsor these AIX only changes. Basically, with this
> > change we bring the OpenJDK AIX hotspot port up to speed with the
> > developments done at SAP in the recent months.
> >
> > For a more detailled number of changes and fixes, please refer to the bug
> > description.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8143125
> > webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8143125-
> > Further/webrev.00/webrev/index.html
> >
> > Kind Regards, Thomas
>

From asmundak at google.com  Wed Nov 25 19:19:07 2015
From: asmundak at google.com (Alexander Smundak)
Date: Wed, 25 Nov 2015 11:19:07 -0800
Subject: RFR JDK-8141491: Unaligned memory access in Bits.c
Message-ID: <CAHQ51u6wyy3BMjV9U7NUUY0VcRzH+qHEPz=Vc7jWn_m-KTZ3Uw@mail.gmail.com>

Please take a look at
http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
that fixes the problem.

It utilizes the ability of some (GCC and Clang) to declare data
alignment explicitly.
I have verified it works on x86_64 Linux by running
jdk/test/java/nio/Buffer/Basic.java test

I need a sponsor.

Sasha

From coleen.phillimore at oracle.com  Wed Nov 25 19:42:42 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 25 Nov 2015 14:42:42 -0500
Subject: RFR JDK-8141491: Unaligned memory access in Bits.c
In-Reply-To: <CAHQ51u6wyy3BMjV9U7NUUY0VcRzH+qHEPz=Vc7jWn_m-KTZ3Uw@mail.gmail.com>
References: <CAHQ51u6wyy3BMjV9U7NUUY0VcRzH+qHEPz=Vc7jWn_m-KTZ3Uw@mail.gmail.com>
Message-ID: <56560F32.6040300@oracle.com>

Sending to core-libs mailing list.

On 11/25/15 2:19 PM, Alexander Smundak wrote:
> Please take a look at
> http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
> that fixes the problem.
>
> It utilizes the ability of some (GCC and Clang) to declare data
> alignment explicitly.
> I have verified it works on x86_64 Linux by running
> jdk/test/java/nio/Buffer/Basic.java test
>
> I need a sponsor.
>
> Sasha


From mikael.vidstedt at oracle.com  Wed Nov 25 21:32:37 2015
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 25 Nov 2015 13:32:37 -0800
Subject: RFR JDK-8141491: Unaligned memory access in Bits.c
In-Reply-To: <56560F32.6040300@oracle.com>
References: <CAHQ51u6wyy3BMjV9U7NUUY0VcRzH+qHEPz=Vc7jWn_m-KTZ3Uw@mail.gmail.com>
	<56560F32.6040300@oracle.com>
Message-ID: <565628F5.2080801@oracle.com>


Have you looked anything at the performance of the generated code? As 
you may have seen I was playing around with an alternative 
implementation[1] which has the benefit of being pure C++ without 
compiler specific hints. That said, when I did some initial benchmarking 
of that it did seem like the performance impact was significant. I 
didn't have time to look at more in detail why, and will not have time 
to return to that until late next week earliest. It would be interesting 
to understand what type of performance you see with your patch.

Cheers,
Mikael


[1] 
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.01/webrev/jdk.patch

On 2015-11-25 11:42, Coleen Phillimore wrote:
> Sending to core-libs mailing list.
>
> On 11/25/15 2:19 PM, Alexander Smundak wrote:
>> Please take a look at
>> http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
>> that fixes the problem.
>>
>> It utilizes the ability of some (GCC and Clang) to declare data
>> alignment explicitly.
>> I have verified it works on x86_64 Linux by running
>> jdk/test/java/nio/Buffer/Basic.java test
>>
>> I need a sponsor.
>>
>> Sasha
>


From dmitry.samersoff at oracle.com  Wed Nov 25 21:51:28 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 26 Nov 2015 00:51:28 +0300
Subject: RFR 8141526: Allow to collect stdout/stderr from the
	FinalizationRunner even before the process returns
In-Reply-To: <563CD13B.8040800@oracle.com>
References: <563CD13B.8040800@oracle.com>
Message-ID: <56562D60.80306@oracle.com>

Jaroslav,

Looks good for me.

PS: I found a bug in canPtraceAttachLinux not related to your changes -
it's probably my mistake:

 181         if (userName.equals("root")) {
 182             return true;
 183         }

shouldn't be there.

Could you file a separate CR and assign it to me?

-Dmitry

On 2015-11-06 19:11, Jaroslav Bachorik wrote:
> [wider audience included]
> 
> Please, review the following test change
> 
> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526
> Webrev:
> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00
> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot
> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk
> 
> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we
> are not able to get the debug info about the run of the launcher
> FinalizationRunner application in case it gets stuck and harness times
> out. This is because the stdout/err of the application started via
> ProcessTools.executeProcess() is collected only after the application
> has exited.
> 
> The solution is to use ProcessTools.startProcess() and consume the
> application stdout/err in a streaming mode. Because this method has only
> been available in the 'jdk' version of ProcessTools and not in the
> 'hotspot' one I decided to merge both of those versions and place the
> merged version into the shared location 'test/lib/share/classes/'.
> During this I decided to change the package for the shared ProcessTools
> class to be 'jdk.test.lib.process' to be more in line with the way this
> shared library is structured. I had to move few other lib classes
> required by ProcessTools to the shared lib as well. All the moved lib
> classes have been marked as deprecated in their original location.
> 
> 
> Thanks,
> 
> -JB-
> 


-- 
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 jon.masamitsu at oracle.com  Wed Nov 25 22:50:53 2015
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 25 Nov 2015 14:50:53 -0800
Subject: Fwd: Re: Request for Review (s) - 8133023: ParallelGCThreads is not
	calculated correctly
In-Reply-To: <565631DC.1010800@oracle.com>
References: <565631DC.1010800@oracle.com>
Message-ID: <56563B4D.3030301@oracle.com>

Widening the review request.  This fixed changed the order
of some VM initialization for solaris-sparc with hopefully
the minimum change for other platforms.

Thanks.

Jon

-------- Forwarded Message --------
Subject: 	Re: Request for Review (s) - 8133023: ParallelGCThreads is not 
calculated correctly
Date: 	Wed, 25 Nov 2015 14:10:36 -0800
From: 	Jon Masamitsu <jon.masamitsu at oracle.com>
Organization: 	Oracle Corporation
To: 	hotspot-gc-dev at openjdk.java.net



I have a new fix for this bug.  My previous fix broke solaris-x86 (I
had not defined an early_initialize() for x86).  This fix is slightly
smaller and has the virtue of moving the required initialization
closer to where it is used.

http://cr.openjdk.java.net/~jmasa/8133023/webrev.03/index.html

Testing: JPRT build on all platforms, checked by hand that the correct 
number
of GC worker threads are created on later Niagara platforms.

Thanks.

Jon

On 11/12/2015 1:31 PM, Jon Masamitsu wrote:
> GC calls VM_Version::calc_parallel_worker_threads() to determine
> the number of GC threads to create.  On Sparc it checks for newer
> Niagara hardware to decide the proper scaling of the GC threads with
> the hardware threads. calc_parallel_worker_threads() was being called
> before enough information was gathered to determine the Sparc hardware.
>
> Moved the gathering of information needed to earlier in the JVM
> initialization.
>
> http://cr.openjdk.java.net/~jmasa/8133023/webrev.00/
>
> https://bugs.openjdk.java.net/browse/JDK-8133023
>
> Thanks.
>
> Jon




From david.holmes at oracle.com  Wed Nov 25 22:52:16 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Nov 2015 08:52:16 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
	<CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
Message-ID: <56563BA0.1010307@oracle.com>

On 26/11/2015 2:53 AM, Thomas St?fe wrote:
> I created a bug to track this:
>
> https://bugs.openjdk.java.net/browse/JDK-8144059

Thanks. I admit I still don't really grok the exact problem here. It is 
the alignment code that is the problem right?

79 mov(r10, rsp);
80 andq(rsp, -16);
81 push(r10);

?

Thanks,
David

> Because Davids change is not submitted yet, the bug refers to the old
> coding, but stays relevant also after this fix.
>
> Kind Regards, Thomas
>
> On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty
> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>> wrote:
>
>     On 11/25/15 6:10 AM, David Holmes wrote:
>
>         On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>
>
>             On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
>             <bertrand.delsart at oracle.com
>             <mailto:bertrand.delsart at oracle.com>
>             <mailto:bertrand.delsart at oracle.com
>             <mailto:bertrand.delsart at oracle.com>>> wrote:
>
>                  Good finding Thomas,
>
>                  On 25/11/2015 09:40, Thomas St?fe wrote:
>
>                      Hi David, Bertrand,
>
>                      about
>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>
>                      I am not sure this is correct for Windows x64.
>
>
>                  Unless I'm misreading it, the new code looks a lot like
>             the old one
>                  (including the alignement part). Hence this does not
>             look like a
>                  regression caused by David's change.
>
>
>             Yes, this seems like an old bug.
>
>             I also see that this is fixed in our codebase since 2010,
>             exactly the
>             way you propose (with MacroAssembler
>             <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
>
>             <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
>
>             So, it is already used since five years. I would propose
>             opening a
>             separate bug for this one and we contribute our fix.
>
>
>         That sounds good to me too. I also suspect additional code will
>         need to be checked as this stack alignment is performed in a few
>         places in ./cpu/x86/vm/macroAssembler_x86.cpp with no OS
>         specific differences being considered.
>
>
>     Looks like MacroAssembler::call_VM_leaf_base() does the "right thing"
>     for stack alignment in the X64 case. Perhaps we need to audit both
>     stack alignment _and_ uses of MacroAssembler::call() just to make
>     sure...
>
>     Did I mention that all the assembly code stuff gives me a headache? :-)
>
>     Dan
>
>
>
>
>         Thanks,
>         David
>
>             Regards, Thomas
>
>
>             https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>
>                      windows x64 Abi requires the register parameter
>             area right above the
>                      return address on the stack. It is not guaranteed to be
>                      preserved during
>                      the function call:
>
>                      "Even if the called function has fewer than 4
>             parameters, these
>                      4 stack
>                      locations are effectively owned by the called
>             function, and may
>                      be used
>                      by the called function for other purposes besides
>             saving parameter
>                      register values. Thus the caller may not save
>             information in
>                      this region
>                      of stack across a function call."
>
>                      So, restoring parameters from it may not work if
>                      Thread::current() uses
>                      this area for any reason. In this case, r9, rsp,
>             r10, r11 may be
>                      overwritten by the callee.
>
>                      I also think Windows x64 ABI is different enough
>             from Linux that
>                      this
>                      function could live somewhere in <os>_<cpu>.
>
>
>                  This is a valid point. However, note that this is
>             similar to the
>                  issue we have for instance in 'shared'
>                  MacroAssembler::call_VM_leaf_base, which was not put in
>             <os>_<cpu>
>                  files.
>
>                  In fact, the right fix may be to use call_VM_leaf
>             instead of call :-)
>
>                  (alternatively we could use "#ifdef _WIN64" or check
>                  "frame::arg_reg_save_area_bytes != 0", which may be
>             even cleaner and
>                  more portable)
>
>                  All these solutions are fine for me.
>
>
>                  Since we are near to feature freeze, this should
>             probably be done in
>                  a separate CR (unless David has enough time to test it).
>
>                  Regards,
>
>                  Bertrand.
>
>
>                      Kind Regards, Thomas
>
>
>
>
>                      On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>                      <david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>
>             <mailto:david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>>
>                      <mailto:david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>
>                      <mailto:david.holmes at oracle.com
>             <mailto:david.holmes at oracle.com>>>> wrote:
>
>                           On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>
>                               On 23/11/2015 13:27, David Holmes wrote:
>
>                                   Hi Bertrand,
>
>                                   On 23/11/2015 8:14 PM, Bertrand
>             Delsart wrote:
>
>                                       Hi David,
>
>                                       Overall looks good.
>                                       Thanks for the #ifndef
>                      USE_LIBRARY_BASED_TLS_ONLY :-)
>
>                                       One doubt, in case this has not
>             been discussed
>                      before.
>
>                                       I'm still catching up on x86_64
>             (after years of ARM
>                                       assembly :-)) but it
>                                       seems that there are some stack
>             alignment
>                      constraints on
>                                       runtime calls,
>                                       at least for some x86_64 ABIs.
>
>                                       Some of the x86
>             MacroAssembler::get_thread
>                                       implementations had code to
>                                       align the stack before calling
>                      pthread_getspecific. See
>                                       for instance
>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>
>
>
>                                   Sorry I'm not that familiar with the
>             MacroAssembler
>                      - is it
>                                   this odd
>                                   fragment:
>
>                                   -   push(r10);
>                                   -   // XXX
>                                   -   mov(r10, rsp);
>                                   -   andq(rsp, -16);
>                                   -   push(r10);
>
>                                   I'm not at all clear what that is
>             doing - and if it
>                      somehow
>                                   changes the
>                                   alignment wouldn't something need to
>             be fixed up when
>                                   popping the
>                                   previous values ??
>
>                                   To be honest I'm not even sure what an
>             "unaligned
>                      stack" means.
>
>
>                               On some platforms, SP may have to be
>             aligned on a 16 bytes
>                               boundary when
>                               calling another method.
>
>
>                           Okay - that seems to be an x64 ABI requirement
>             based on
>                      other code
>                           in MacroAssembler. The reason it is missing in
>             the Solaris
>                      code is
>                           because I already removed it in the earlier
>             changes that
>                      were done
>                           on Solaris:
>
>             http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>
>                           and nobody picked it up. :(
>
>                           That said, the absence of this code has not
>             caused any
>                      problems so
>                           presumably we are normally aligned.
>
>                               After having pushed what needed to be
>             saved, the code above
>                               rounds SP
>                               down and saves the old value. It will then
>             also push
>                      r11, which
>                               results
>                               in the expected alignment.
>
>                               The conterpart, after the VM call, is the:
>                                  pop(r11);
>                                  pop(rsp);
>
>
>                           I had assumed this extra manipulation was
>             related to
>                      pushing the arg
>                           for the call.
>
>                                       This alignment is no longer
>             performed in the new
>                                       (shared) implementation
>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>
>
>
>
>                                       Now, Solaris was not performing
>             the alignment and
>                                       Windows has a separate
>                                       path for x86_64. Did we really
>             need the
>                      alignment for
>                                       linux x86_64 and
>                                       bsd_x86_64 ? Might it be needed
>             for other ports ?
>
>                                       IMHO, it might be safer to align
>             the stack by
>                      default,
>                                       knowing it should
>                                       not be expensive since we call
>             get_thread
>                      rarely for
>                                       x86_64 (result is
>                                       cached in r15). I'll let you see
>             whether it is
>                      worth
>                                       adding an ifdef so
>                                       as to explicitly deactivate the
>             alignment on
>                      some platforms
>                                       (solaris_x86_64 ?)
>
>
>                                   I don't have enough knowledge to even
>             begin to
>                      comment on
>                                   this. I will
>                                   have to rely on our x86_64
>             macroassembler experts
>                      to explain
>                                   the old
>                                   code and what the requirements are.
>
>
>                               OK. This means that the alignment was not
>             removed
>                      purposefully.
>
>                               In that case, you must either keep the per
>             platform
>                      code x86_64
>                               (since
>                               it was not identical for all platforms) or
>             use the safest
>                               version, with
>                               the additional
>
>                                    // XXX
>                                    mov(r10, rsp);
>                                    andq(rsp, -16);
>                                    push(r10);
>
>                               before the push(r11) and with the
>
>                                    pop(rsp);
>
>                               after the pop(r11). It should work on all
>             x86_64 platforms.
>
>
>                           Right, I will add this back to the code - and
>             replace the
>                           meaningless // XXX with an actual comment!
>
>                           Many thanks,
>                           David
>                           -----
>
>
>                               FYI, there is another way to do the
>             alignment, based on
>                      the fact
>                               that
>                               we are at least aligned on 8 bytes (see
>                               MacroAssembler::call_VM_leaf_base). I
>             assume that this
>                      second
>                               version is
>                               more efficient (particularly thanks to
>             specilative
>                      branches) but it
>                               might be safer/simpler to continue using
>             andq in
>                      get_thread.
>
>                               Bertrand.
>
>
>                                   Thanks,
>                                   David
>
>                                       Regards,
>
>                                       Bertrand.
>
>
>
>                                       On 23/11/2015 08:03, David Holmes
>             wrote:
>
>                                           After all the preliminary
>             discussions here
>                      are final
>                                           proposed changes:
>
>                                           bug:
>             https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                                           Open webrev:
>             http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
>                                           A simple (in principle) but
>             wide-ranging change
>                                           which should appeal to
>                                           our Code Deletion Engineer's.
>             We implement
>                                           Thread::current() using a
>                                           compiler/language-based
>             thread-local
>                      variable eg:
>
>                                              static __thread Thread
>             *_thr_current;
>
>                                              inline Thread*
>             Thread::current() {
>                                                return _thr_current;
>                                              }
>
>                                           with an appropriate setter of
>             course. By
>                      doing this
>                                           we can completely
>                                           remove the os_cpu-specific
>             ThreadLocalStorage
>                                           implementations, and the
>                                           associated
>             os::thread_local_storage* calls.
>
>                                           As __thread is not
>             async-signal-safe (either in
>                                           theory or practice) we
>                                           need a fallback library-based
>             solution as used
>                                           today. For this we use a
>                                           very simple ThreadLocalStorage
>             class and an
>                                           implementation thereof for
>                                           POSIX (covers AIX, BSD, Linux,
>             OSX and
>                      Solaris) using
>                                           pthread_get/setspecific; and
>             one for
>                      Windows using
>                                           its TLS library.
>                                           While these library routines
>             are not guaranteed
>                                           async-signal-safe, they
>                                           seem to be in practice and are
>             what we have
>                      been
>                                           using all along.
>
>                                           We also allow for use of only the
>                      library-based TLS
>                                           for platforms where
>                                           compiler-based thread locals
>             are not
>                      supported (as
>                                           will be needed in
>                                           the
>                                           Mobile project). This is
>             enabled at build
>                      time by
>                                           defining
>                                           USE_LIBRARY_BASED_TLS_ONLY.
>
>                                           Thanks to Andrew Haley for
>             providing the
>                      Aarch64
>                                           code; and for Thomas
>                                           Stuefe for testing PPC and AIX.
>
>                                           Testing:
>                                              - JPRT (core platforms)
>                                              - Jtreg tests (linux & solaris)
>                                              - vm.runtime (core platforms)
>
>                                           Performance:
>                                              - still TBD - this is
>             proving to be
>                      extremely
>                                           difficult. If anyone
>                                           has
>                                           any simple to run
>             microbenchmarks to
>                      suggest I'd
>                                           give them a try as a
>                                           sanity check. But I lack
>             access to hardware for
>                                           running serious
>                                           benchmarking.
>
>                                           Footprint:
>                                           - varies by platform and the
>             VM (server,
>                      client,
>                                           minimal)
>                                           - worst-case: ~1% increase for
>             server VM
>                      and minimal VM
>                                           - best-case:  0.4% decrease
>             for client VM
>
>                                           Thanks,
>                                           David
>
>
>
>
>
>
>
>
>                  --
>                  Bertrand Delsart,                     Grenoble
>             Engineering Center
>                  Oracle,         180 av. de l'Europe,          ZIRST de
>             Montbonnot
>                  38330 Montbonnot Saint Martin, FRANCE
>             bertrand.delsart at oracle.com
>             <mailto:bertrand.delsart at oracle.com>
>             <mailto:bertrand.delsart at oracle.com
>             <mailto:bertrand.delsart at oracle.com>>
>                            Phone : +33 4 76 18 81 23
>
>             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                  NOTICE: This email message is for the sole use of the
>             intended
>                  recipient(s) and may contain confidential and privileged
>                  information. Any unauthorized review, use, disclosure or
>                  distribution is prohibited. If you are not the intended
>             recipient,
>                  please contact the sender by reply email and destroy
>             all copies of
>                  the original message.
>             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>

From david.holmes at oracle.com  Wed Nov 25 22:55:24 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Nov 2015 08:55:24 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5655C5DA.2090904@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com> <5653BA8E.8080802@oracle.com>
	<5653C930.5090602@oracle.com> <5655102D.20502@oracle.com>
	<5655420A.4090805@oracle.com> <5655C5DA.2090904@oracle.com>
Message-ID: <56563C5C.8020909@oracle.com>

On 26/11/2015 12:29 AM, Daniel D. Daugherty wrote:
> On 11/24/15 10:07 PM, David Holmes wrote:
>> Hi Dan,
>>
>> Many thanks for the meticulous review!
>
> You're welcome.
>
>
>>
>> On 25/11/2015 11:34 AM, Daniel D. Daugherty wrote:
>>> On 11/23/15 7:19 PM, David Holmes wrote:
>>>> Sorry about that:
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>>
>>> Please double check the copyright updates before you push.
>>
>> Did you notice something missing? I use:
>>
>> hg status -man | xargs grep Copyright | grep -v 2015
>>
>> to find any copyright lines without 2015 present (it turns up the
>> non-Oracle copyrights in a few files).
>
> src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.hpp
>
> L2  * Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
> reserved.

Thank you. I managed to miss that. I have now updated my grep command:

hg status -man | xargs grep Copyright | grep Oracle | grep -v 2015

Many thanks for the re-review. Now to address Thomas's suggestions.

David
-----


>>
>> Trimming to files with comments ...
>>
>>> src/os/windows/vm/os_windows.cpp
>>>      L5998:       os::os_exception_wrapper(
>>> (java_call_t)call_wrapper_dummy,
>>>          Wrong indent; should only be two spaces.
>>>          Please delete space after first '('.
>>>
>>>      L5999:                                 NULL, NULL, NULL, NULL);
>>>          Indent will have to change to match any fixes on previous line.
>>
>> Fixed.
>>
>>> src/os/windows/vm/os_windows.hpp
>>>      L127:   static inline void set_thread_ptr_offset( int offset ) {
>>>          Please delete space after '(' and before ')'.
>>
>> Fixed (was a copy of code from now deleted file)
>>
>>> src/share/vm/gc/parallel/gcTaskThread.cpp
>>>      No comments.
>>>
>>>      Note: blank first line in this file (not your change)
>>
>> Fixed.
>>
>>> src/share/vm/prims/jni.cpp
>>>      L4312:   // If the thread has already been detached the operations
>>> is a no-op
>>>          Typo: 'the operations is a' -> 'the operation is a'
>>
>> Fixed
>>
>>> src/share/vm/prims/jvmtiExport.cpp
>>>      L377:       JavaThread* current_thread = JavaThread::current();
>>>          Wrong indent; two less spaces
>>
>> Fixed.
>>
>>> src/share/vm/runtime/threadLocalStorage.hpp
>>>      L37: // Platforms without compiler-based TLS (ie __thread
>>> storage-class modifier)
>>>          Typo: 'ie' -> 'i.e.'
>>
>> Fixed.
>>
>>> src/share/vm/runtime/vm_operations.cpp
>>>
>>>      (old) L396:   Thread * thr_cur =
>>> ThreadLocalStorage::get_thread_slow();
>>>      (new) L396:   Thread * thr_cur = Thread::current();
>>>
>>>          I think this should be 'current_or_null()' like L374.
>>
>> Actually L374 should just be Thread::current() as NULL is neither
>> possible nor expected. These VM_Exit routines can only be called by an
>> attached thread. E.g. set_vm_exited is only called from
>> Threads::destroy_vm(), while wait_for_threads_in_native_to_block is
>> only called on the VMThread.
>>
>>> src/os/posix/vm/threadLocalStorage_posix.cpp
>>>      L38:     ThreadLocalStorage::set_thread((Thread*) p);
>>>          Wrong indent; should be two spaces.
>>
>> Fixed.
>>
>>> src/os/windows/vm/threadLocalStorage_windows.cpp
>>>      L54:   assert(current != 0 || GetLastError() == ERROR_SUCCESS, '
>>>          'current != 0' -> 'current != NULL'
>>>          jcheck will complain about the blank at the end of this line
>>>
>>>      L62:   assert(res, "TlsSetValue failed with error code: %lu",
>>> GetLastError());
>>>          jcheck will complain about the blank at the end of this line
>>
>> Fixed.
>
> I missed flagging that this line:
>
>      L55:          "TlsGetValue failed with error code: %lu",
> GetLastError());
>
> also ends with a blank. Sorry about that.
>
>>
>> Generated new webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/
>
> Re-reviewed by comparing the v7 and v8 patch files.
>
> Thumbs up!
>
> Dan
>
>>
>> which has been rebased to current hs-rt content.
>>
>> Thanks,
>> David
>>
>>>
>>> Dan
>>>
>>>
>>>>
>>>> David
>>>>
>>>> On 24/11/2015 11:17 AM, David Holmes wrote:
>>>>> Updated webrev:
>>>>>
>>>>> cr.openjdk.java.net/~dholmes/8132510/webrev.v7/
>>>>>
>>>>> Only change is in macroAssembler_x86.cpp
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 24/11/2015 7:42 AM, David Holmes wrote:
>>>>>> On 23/11/2015 11:46 PM, Bertrand Delsart wrote:
>>>>>>> On 23/11/2015 13:27, David Holmes wrote:
>>>>>>>> Hi Bertrand,
>>>>>>>>
>>>>>>>> On 23/11/2015 8:14 PM, Bertrand Delsart wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> Overall looks good.
>>>>>>>>> Thanks for the #ifndef USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>>>>>>
>>>>>>>>> One doubt, in case this has not been discussed before.
>>>>>>>>>
>>>>>>>>> I'm still catching up on x86_64 (after years of ARM assembly :-))
>>>>>>>>> but it
>>>>>>>>> seems that there are some stack alignment constraints on runtime
>>>>>>>>> calls,
>>>>>>>>> at least for some x86_64 ABIs.
>>>>>>>>>
>>>>>>>>> Some of the x86 MacroAssembler::get_thread implementations had
>>>>>>>>> code to
>>>>>>>>> align the stack before calling pthread_getspecific. See for
>>>>>>>>> instance
>>>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry I'm not that familiar with the MacroAssembler - is it this
>>>>>>>> odd
>>>>>>>> fragment:
>>>>>>>>
>>>>>>>> -   push(r10);
>>>>>>>> -   // XXX
>>>>>>>> -   mov(r10, rsp);
>>>>>>>> -   andq(rsp, -16);
>>>>>>>> -   push(r10);
>>>>>>>>
>>>>>>>> I'm not at all clear what that is doing - and if it somehow
>>>>>>>> changes the
>>>>>>>> alignment wouldn't something need to be fixed up when popping the
>>>>>>>> previous values ??
>>>>>>>>
>>>>>>>> To be honest I'm not even sure what an "unaligned stack" means.
>>>>>>>
>>>>>>> On some platforms, SP may have to be aligned on a 16 bytes boundary
>>>>>>> when
>>>>>>> calling another method.
>>>>>>
>>>>>> Okay - that seems to be an x64 ABI requirement based on other code in
>>>>>> MacroAssembler. The reason it is missing in the Solaris code is
>>>>>> because
>>>>>> I already removed it in the earlier changes that were done on
>>>>>> Solaris:
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>>>>
>>>>>> and nobody picked it up. :(
>>>>>>
>>>>>> That said, the absence of this code has not caused any problems so
>>>>>> presumably we are normally aligned.
>>>>>>
>>>>>>> After having pushed what needed to be saved, the code above
>>>>>>> rounds SP
>>>>>>> down and saves the old value. It will then also push r11, which
>>>>>>> results
>>>>>>> in the expected alignment.
>>>>>>>
>>>>>>> The conterpart, after the VM call, is the:
>>>>>>>   pop(r11);
>>>>>>>   pop(rsp);
>>>>>>
>>>>>> I had assumed this extra manipulation was related to pushing the arg
>>>>>> for
>>>>>> the call.
>>>>>>
>>>>>>>>> This alignment is no longer performed in the new (shared)
>>>>>>>>> implementation
>>>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now, Solaris was not performing the alignment and Windows has a
>>>>>>>>> separate
>>>>>>>>> path for x86_64. Did we really need the alignment for linux
>>>>>>>>> x86_64 and
>>>>>>>>> bsd_x86_64 ? Might it be needed for other ports ?
>>>>>>>>>
>>>>>>>>> IMHO, it might be safer to align the stack by default, knowing it
>>>>>>>>> should
>>>>>>>>> not be expensive since we call get_thread rarely for x86_64
>>>>>>>>> (result is
>>>>>>>>> cached in r15). I'll let you see whether it is worth adding an
>>>>>>>>> ifdef so
>>>>>>>>> as to explicitly deactivate the alignment on some platforms
>>>>>>>>> (solaris_x86_64 ?)
>>>>>>>>
>>>>>>>> I don't have enough knowledge to even begin to comment on this. I
>>>>>>>> will
>>>>>>>> have to rely on our x86_64 macroassembler experts to explain the
>>>>>>>> old
>>>>>>>> code and what the requirements are.
>>>>>>>
>>>>>>> OK. This means that the alignment was not removed purposefully.
>>>>>>>
>>>>>>> In that case, you must either keep the per platform code x86_64
>>>>>>> (since
>>>>>>> it was not identical for all platforms) or use the safest version,
>>>>>>> with
>>>>>>> the additional
>>>>>>>
>>>>>>>     // XXX
>>>>>>>     mov(r10, rsp);
>>>>>>>     andq(rsp, -16);
>>>>>>>     push(r10);
>>>>>>>
>>>>>>> before the push(r11) and with the
>>>>>>>
>>>>>>>     pop(rsp);
>>>>>>>
>>>>>>> after the pop(r11). It should work on all x86_64 platforms.
>>>>>>
>>>>>> Right, I will add this back to the code - and replace the
>>>>>> meaningless //
>>>>>> XXX with an actual comment!
>>>>>>
>>>>>> Many thanks,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> FYI, there is another way to do the alignment, based on the fact
>>>>>>> that
>>>>>>> we are at least aligned on 8 bytes (see
>>>>>>> MacroAssembler::call_VM_leaf_base). I assume that this second
>>>>>>> version is
>>>>>>> more efficient (particularly thanks to specilative branches) but it
>>>>>>> might be safer/simpler to continue using andq in get_thread.
>>>>>>>
>>>>>>> Bertrand.
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Bertrand.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 23/11/2015 08:03, David Holmes wrote:
>>>>>>>>>> After all the preliminary discussions here are final proposed
>>>>>>>>>> changes:
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>>>>>>>
>>>>>>>>>> Open webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>>>>>>>
>>>>>>>>>> A simple (in principle) but wide-ranging change which should
>>>>>>>>>> appeal to
>>>>>>>>>> our Code Deletion Engineer's. We implement Thread::current()
>>>>>>>>>> using a
>>>>>>>>>> compiler/language-based thread-local variable eg:
>>>>>>>>>>
>>>>>>>>>>   static __thread Thread *_thr_current;
>>>>>>>>>>
>>>>>>>>>>   inline Thread* Thread::current() {
>>>>>>>>>>     return _thr_current;
>>>>>>>>>>   }
>>>>>>>>>>
>>>>>>>>>> with an appropriate setter of course. By doing this we can
>>>>>>>>>> completely
>>>>>>>>>> remove the os_cpu-specific ThreadLocalStorage implementations,
>>>>>>>>>> and
>>>>>>>>>> the
>>>>>>>>>> associated os::thread_local_storage* calls.
>>>>>>>>>>
>>>>>>>>>> As __thread is not async-signal-safe (either in theory or
>>>>>>>>>> practice) we
>>>>>>>>>> need a fallback library-based solution as used today. For this we
>>>>>>>>>> use a
>>>>>>>>>> very simple ThreadLocalStorage class and an implementation
>>>>>>>>>> thereof
>>>>>>>>>> for
>>>>>>>>>> POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>>>>>>>>>> pthread_get/setspecific; and one for Windows using its TLS
>>>>>>>>>> library.
>>>>>>>>>> While these library routines are not guaranteed
>>>>>>>>>> async-signal-safe,
>>>>>>>>>> they
>>>>>>>>>> seem to be in practice and are what we have been using all along.
>>>>>>>>>>
>>>>>>>>>> We also allow for use of only the library-based TLS for platforms
>>>>>>>>>> where
>>>>>>>>>> compiler-based thread locals are not supported (as will be
>>>>>>>>>> needed in
>>>>>>>>>> the
>>>>>>>>>> Mobile project). This is enabled at build time by defining
>>>>>>>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>>>>>>>
>>>>>>>>>> Thanks to Andrew Haley for providing the Aarch64 code; and for
>>>>>>>>>> Thomas
>>>>>>>>>> Stuefe for testing PPC and AIX.
>>>>>>>>>>
>>>>>>>>>> Testing:
>>>>>>>>>>   - JPRT (core platforms)
>>>>>>>>>>   - Jtreg tests (linux & solaris)
>>>>>>>>>>   - vm.runtime (core platforms)
>>>>>>>>>>
>>>>>>>>>> Performance:
>>>>>>>>>>   - still TBD - this is proving to be extremely difficult. If
>>>>>>>>>> anyone
>>>>>>>>>> has
>>>>>>>>>> any simple to run microbenchmarks to suggest I'd give them a try
>>>>>>>>>> as a
>>>>>>>>>> sanity check. But I lack access to hardware for running serious
>>>>>>>>>> benchmarking.
>>>>>>>>>>
>>>>>>>>>> Footprint:
>>>>>>>>>> - varies by platform and the VM (server, client, minimal)
>>>>>>>>>> - worst-case: ~1% increase for server VM and minimal VM
>>>>>>>>>> - best-case:  0.4% decrease for client VM
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>

From sangheon.kim at oracle.com  Wed Nov 25 23:00:25 2015
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Wed, 25 Nov 2015 15:00:25 -0800
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <56547635.9060808@oracle.com>
References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com>
	<56547635.9060808@oracle.com>
Message-ID: <56563D89.5090902@oracle.com>

Hi all,

Here's updated webrev which reflects changes by "JDK-8143038: [TESTBUG] 
TestOptionsWithRanges: allow excluding only a subset of tested values 
specified for a flag".

The only updated file is 
test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java.
Changed from "allOptionsAsMap.remove("flag name")" to 
"excludeTestMaxRange("flag name")".

FYI,  JDK-8143038 introduced separated exclude methods of "excludeTest, 
excludeTestMaxRange and excludeTestMinRange".

webrev:
http://cr.openjdk.java.net/~sangheki/8142341/webrev.01/
http://cr.openjdk.java.net/~sangheki/8142341/webrev.01_to_00/

Thanks,
Sangheon


On 11/24/2015 06:37 AM, sangheon.kim wrote:
> Hi Dmitry,
>
> Thank you for the review!
> Sure I will update my patch related to your enhancement.
>
> Thanks,
> Sangheon
>
>
> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
>> Hi Sangheon,
>>
>> Looks good to me! Thank you for fixing that. I hope that enhancement 
>> will be pushed today(currently in JPRT queue), so please update your 
>> patch after that!
>>
>> Thanks,
>> Dmitry
>>
>> On 21.11.2015 0:04, sangheon.kim wrote:
>>> Hi all,
>>>
>>> Could I have a couple of reviews for this change to add explicit 
>>> 'range' for flags?
>>>
>>> Previously, we added 'range' when it is needed to avoid assert/crash 
>>> but now explicit 'range' are needed for all flags.
>>> All flags should have 'range' or 'constraint' at least.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
>>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>>> Testing: JPRT, RBT 
>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist 
>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for 
>>> embedded
>>>
>>> * Summary
>>> 1. Added 3 new constraint functions.
>>>    1) HeapBaseMinAddress: Added to avoid an overflow after align up 
>>> and this flag makes hang up without constraint function. (newly 
>>> added as a part of GC work)
>>>    2) TLABWasteIncrement: Without this constraint function we don't 
>>> have problems (even many GCs happen). But added to avoid an overflow 
>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also 
>>> separate CR for this overflow ( JDK-8143352 ).
>>>    3) NUMAInterleaveGranularity: Added to avoid an overflow after 
>>> align up.
>>>
>>> 2. Some flags have narrower range than their type.
>>>    1) Here's the reason why some flags should have different range. 
>>> (same order from globals.hpp)
>>> {flag type} {flag name}: (range), {comment}
>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), 
>>> max_uintx), there is a comment at numa_interleaving_init() that this 
>>> flag should be larger than vm_allocation_granularity().
>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as 
>>> used for multiplication
>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which 
>>> has 'unsigned int' type input parameter.
>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which 
>>> has 'unsigned int' type input parameter.
>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function 
>>> which has 'long' type input parameter.
>>> uintx PausePadding: (0, max_juint), used to set a function which has 
>>> 'unsigned int' type input parameter.
>>> uintx PromotedPadding: (0, max_juint), used to set a function which 
>>> has 'unsigned int' type input parameter.
>>> uintx SurvivorPadding: (0, max_juint), used to set a function which 
>>> has 'unsigned int' type input parameter.
>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag 
>>> is divided by 100 I assume this is percentage.
>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has 
>>> 'unsigned int' type input parameter.
>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch* 
>>> flags should have same upper limit and looking at their related 
>>> codes 'max_jint' seems appropriate ( no problem with 'max_jint' 
>>> during testing). However, as Prefetch::read/write() needs 'intx', 
>>> 'intx' also seems good but we have to fix some codes (maybe 
>>> including generated codes).
>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which 
>>> has 'unsigned int' type input parameter.
>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint 
>>> variable and used 'for loop' which has uint increment. i.e. for 
>>> (uint i=0; i<ProcessDistributionStride; i++)
>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 
>>> 'increment for loop()' as max value and the increment is uint.
>>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for 
>>> loop()' as max value and the increment is uint.
>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return 
>>> value of uint type function and for division. i.e. uint 
>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return 
>>> TLABRefillWasteFraction; }
>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we 
>>> only use " if (a !=0, >0, >1)".
>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we 
>>> only use " if (a !=0, >0, >1)".
>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only 
>>> use " if (a !=0, >0)".
>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned 
>>> int'
>>>
>>> (g1_globals.hpp)
>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) 
>>> type variable.
>>>
>>> 3. Excluded flags from TestOptionsWithRanges.java
>>> 1) Memory and thread related flags: tests for these flags will 
>>> consume too many resources from the system.
>>> 2) VMThreadStackSize: range work for this flag is not included in 
>>> this patch but I faced OOME several times, so excluded.
>>>
>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] 
>>> TestOptionsWithRanges: allow excluding only a subset of tested 
>>> values specified for a flag) next time.
>>>
>>> Thanks,
>>> Sangheon
>>>
>>>
>>>
>>
>


From daniel.daugherty at oracle.com  Wed Nov 25 23:08:17 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 25 Nov 2015 16:08:17 -0700
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56563BA0.1010307@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
	<CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
	<56563BA0.1010307@oracle.com>
Message-ID: <56563F61.4030008@oracle.com>

If I understand the problem... :-)

The Win-X64 ABI requires that some extra space be allocated on
the stack in the caller for "homing" four registers...

This code uses MacroAssembler::call() which is a lower level
call() function that assumes you know the ABI...

9765 void MacroAssembler::get_thread(Register thread) {
<snip>
9784   call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current)));

If you switch to MacroAssembler::call_VM_leaf_base() it handles
more of the gory details for you than MacroAssembler::call():

src/cpu/x86/vm/macroAssembler_x86.cpp:

    524  void MacroAssembler::call_VM_leaf_base(address entry_point, int 
num_args
) {
    525    Label L, E;
    526
    527  #ifdef _WIN64
    528    // Windows always allocates space for it's register args
    529    assert(num_args <= 4, "only register arguments supported");
    530    subq(rsp,  frame::arg_reg_save_area_bytes);
    531  #endif
    532
    533    // Align stack if necessary
    534    testl(rsp, 15);
    535    jcc(Assembler::zero, L);
    536
    537    subq(rsp, 8);
    538    {
    539      call(RuntimeAddress(entry_point));
    540    }

So call_VM_leaf_base() allocates the "homing" space for register
args for Win-X64 on L530 and it handles any stack alignment before
calling MacroAssembler::call().

So if you switch to call_VM_leaf_base() you can drop
the stack alignment code:

9777   // ensure stack alignment
9778   mov(r10, rsp);
9779   andq(rsp, -16);
9780   push(r10);

and just switch to:

9777   push(rsp);

And you won't be exposed to potential saved register
overwrite by the "homing" of any registers in the call
Thread::current().

I _think_ I have that all correct... :-)

Dan


On 11/25/15 3:52 PM, David Holmes wrote:
> On 26/11/2015 2:53 AM, Thomas St?fe wrote:
>> I created a bug to track this:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8144059
>
> Thanks. I admit I still don't really grok the exact problem here. It 
> is the alignment code that is the problem right?
>
> 79 mov(r10, rsp);
> 80 andq(rsp, -16);
> 81 push(r10);
>
> ?
>
> Thanks,
> David
>
>> Because Davids change is not submitted yet, the bug refers to the old
>> coding, but stays relevant also after this fix.
>>
>> Kind Regards, Thomas
>>
>> On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty
>> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>> 
>> wrote:
>>
>>     On 11/25/15 6:10 AM, David Holmes wrote:
>>
>>         On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>>
>>
>>             On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
>>             <bertrand.delsart at oracle.com
>>             <mailto:bertrand.delsart at oracle.com>
>>             <mailto:bertrand.delsart at oracle.com
>>             <mailto:bertrand.delsart at oracle.com>>> wrote:
>>
>>                  Good finding Thomas,
>>
>>                  On 25/11/2015 09:40, Thomas St?fe wrote:
>>
>>                      Hi David, Bertrand,
>>
>>                      about
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>
>>                      I am not sure this is correct for Windows x64.
>>
>>
>>                  Unless I'm misreading it, the new code looks a lot like
>>             the old one
>>                  (including the alignement part). Hence this does not
>>             look like a
>>                  regression caused by David's change.
>>
>>
>>             Yes, this seems like an old bug.
>>
>>             I also see that this is fixed in our codebase since 2010,
>>             exactly the
>>             way you propose (with MacroAssembler
>> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
>>
>> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
>>
>>             So, it is already used since five years. I would propose
>>             opening a
>>             separate bug for this one and we contribute our fix.
>>
>>
>>         That sounds good to me too. I also suspect additional code will
>>         need to be checked as this stack alignment is performed in a few
>>         places in ./cpu/x86/vm/macroAssembler_x86.cpp with no OS
>>         specific differences being considered.
>>
>>
>>     Looks like MacroAssembler::call_VM_leaf_base() does the "right 
>> thing"
>>     for stack alignment in the X64 case. Perhaps we need to audit both
>>     stack alignment _and_ uses of MacroAssembler::call() just to make
>>     sure...
>>
>>     Did I mention that all the assembly code stuff gives me a 
>> headache? :-)
>>
>>     Dan
>>
>>
>>
>>
>>         Thanks,
>>         David
>>
>>             Regards, Thomas
>>
>>
>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>
>>                      windows x64 Abi requires the register parameter
>>             area right above the
>>                      return address on the stack. It is not 
>> guaranteed to be
>>                      preserved during
>>                      the function call:
>>
>>                      "Even if the called function has fewer than 4
>>             parameters, these
>>                      4 stack
>>                      locations are effectively owned by the called
>>             function, and may
>>                      be used
>>                      by the called function for other purposes besides
>>             saving parameter
>>                      register values. Thus the caller may not save
>>             information in
>>                      this region
>>                      of stack across a function call."
>>
>>                      So, restoring parameters from it may not work if
>>                      Thread::current() uses
>>                      this area for any reason. In this case, r9, rsp,
>>             r10, r11 may be
>>                      overwritten by the callee.
>>
>>                      I also think Windows x64 ABI is different enough
>>             from Linux that
>>                      this
>>                      function could live somewhere in <os>_<cpu>.
>>
>>
>>                  This is a valid point. However, note that this is
>>             similar to the
>>                  issue we have for instance in 'shared'
>>                  MacroAssembler::call_VM_leaf_base, which was not put in
>>             <os>_<cpu>
>>                  files.
>>
>>                  In fact, the right fix may be to use call_VM_leaf
>>             instead of call :-)
>>
>>                  (alternatively we could use "#ifdef _WIN64" or check
>>                  "frame::arg_reg_save_area_bytes != 0", which may be
>>             even cleaner and
>>                  more portable)
>>
>>                  All these solutions are fine for me.
>>
>>
>>                  Since we are near to feature freeze, this should
>>             probably be done in
>>                  a separate CR (unless David has enough time to test 
>> it).
>>
>>                  Regards,
>>
>>                  Bertrand.
>>
>>
>>                      Kind Regards, Thomas
>>
>>
>>
>>
>>                      On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>>                      <david.holmes at oracle.com
>>             <mailto:david.holmes at oracle.com>
>>             <mailto:david.holmes at oracle.com
>>             <mailto:david.holmes at oracle.com>>
>>                      <mailto:david.holmes at oracle.com
>>             <mailto:david.holmes at oracle.com>
>>                      <mailto:david.holmes at oracle.com
>>             <mailto:david.holmes at oracle.com>>>> wrote:
>>
>>                           On 23/11/2015 11:46 PM, Bertrand Delsart 
>> wrote:
>>
>>                               On 23/11/2015 13:27, David Holmes wrote:
>>
>>                                   Hi Bertrand,
>>
>>                                   On 23/11/2015 8:14 PM, Bertrand
>>             Delsart wrote:
>>
>>                                       Hi David,
>>
>>                                       Overall looks good.
>>                                       Thanks for the #ifndef
>>                      USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>>                                       One doubt, in case this has not
>>             been discussed
>>                      before.
>>
>>                                       I'm still catching up on x86_64
>>             (after years of ARM
>>                                       assembly :-)) but it
>>                                       seems that there are some stack
>>             alignment
>>                      constraints on
>>                                       runtime calls,
>>                                       at least for some x86_64 ABIs.
>>
>>                                       Some of the x86
>>             MacroAssembler::get_thread
>>                                       implementations had code to
>>                                       align the stack before calling
>>                      pthread_getspecific. See
>>                                       for instance
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>>
>>
>>                                   Sorry I'm not that familiar with the
>>             MacroAssembler
>>                      - is it
>>                                   this odd
>>                                   fragment:
>>
>>                                   -   push(r10);
>>                                   -   // XXX
>>                                   -   mov(r10, rsp);
>>                                   -   andq(rsp, -16);
>>                                   -   push(r10);
>>
>>                                   I'm not at all clear what that is
>>             doing - and if it
>>                      somehow
>>                                   changes the
>>                                   alignment wouldn't something need to
>>             be fixed up when
>>                                   popping the
>>                                   previous values ??
>>
>>                                   To be honest I'm not even sure what an
>>             "unaligned
>>                      stack" means.
>>
>>
>>                               On some platforms, SP may have to be
>>             aligned on a 16 bytes
>>                               boundary when
>>                               calling another method.
>>
>>
>>                           Okay - that seems to be an x64 ABI requirement
>>             based on
>>                      other code
>>                           in MacroAssembler. The reason it is missing in
>>             the Solaris
>>                      code is
>>                           because I already removed it in the earlier
>>             changes that
>>                      were done
>>                           on Solaris:
>>
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>
>>                           and nobody picked it up. :(
>>
>>                           That said, the absence of this code has not
>>             caused any
>>                      problems so
>>                           presumably we are normally aligned.
>>
>>                               After having pushed what needed to be
>>             saved, the code above
>>                               rounds SP
>>                               down and saves the old value. It will then
>>             also push
>>                      r11, which
>>                               results
>>                               in the expected alignment.
>>
>>                               The conterpart, after the VM call, is the:
>>                                  pop(r11);
>>                                  pop(rsp);
>>
>>
>>                           I had assumed this extra manipulation was
>>             related to
>>                      pushing the arg
>>                           for the call.
>>
>>                                       This alignment is no longer
>>             performed in the new
>>                                       (shared) implementation
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>>
>>                                       Now, Solaris was not performing
>>             the alignment and
>>                                       Windows has a separate
>>                                       path for x86_64. Did we really
>>             need the
>>                      alignment for
>>                                       linux x86_64 and
>>                                       bsd_x86_64 ? Might it be needed
>>             for other ports ?
>>
>>                                       IMHO, it might be safer to align
>>             the stack by
>>                      default,
>>                                       knowing it should
>>                                       not be expensive since we call
>>             get_thread
>>                      rarely for
>>                                       x86_64 (result is
>>                                       cached in r15). I'll let you see
>>             whether it is
>>                      worth
>>                                       adding an ifdef so
>>                                       as to explicitly deactivate the
>>             alignment on
>>                      some platforms
>>                                       (solaris_x86_64 ?)
>>
>>
>>                                   I don't have enough knowledge to even
>>             begin to
>>                      comment on
>>                                   this. I will
>>                                   have to rely on our x86_64
>>             macroassembler experts
>>                      to explain
>>                                   the old
>>                                   code and what the requirements are.
>>
>>
>>                               OK. This means that the alignment was not
>>             removed
>>                      purposefully.
>>
>>                               In that case, you must either keep the per
>>             platform
>>                      code x86_64
>>                               (since
>>                               it was not identical for all platforms) or
>>             use the safest
>>                               version, with
>>                               the additional
>>
>>                                    // XXX
>>                                    mov(r10, rsp);
>>                                    andq(rsp, -16);
>>                                    push(r10);
>>
>>                               before the push(r11) and with the
>>
>>                                    pop(rsp);
>>
>>                               after the pop(r11). It should work on all
>>             x86_64 platforms.
>>
>>
>>                           Right, I will add this back to the code - and
>>             replace the
>>                           meaningless // XXX with an actual comment!
>>
>>                           Many thanks,
>>                           David
>>                           -----
>>
>>
>>                               FYI, there is another way to do the
>>             alignment, based on
>>                      the fact
>>                               that
>>                               we are at least aligned on 8 bytes (see
>> MacroAssembler::call_VM_leaf_base). I
>>             assume that this
>>                      second
>>                               version is
>>                               more efficient (particularly thanks to
>>             specilative
>>                      branches) but it
>>                               might be safer/simpler to continue using
>>             andq in
>>                      get_thread.
>>
>>                               Bertrand.
>>
>>
>>                                   Thanks,
>>                                   David
>>
>>                                       Regards,
>>
>>                                       Bertrand.
>>
>>
>>
>>                                       On 23/11/2015 08:03, David Holmes
>>             wrote:
>>
>>                                           After all the preliminary
>>             discussions here
>>                      are final
>>                                           proposed changes:
>>
>>                                           bug:
>>             https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                                           Open webrev:
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>
>>                                           A simple (in principle) but
>>             wide-ranging change
>>                                           which should appeal to
>>                                           our Code Deletion Engineer's.
>>             We implement
>>                                           Thread::current() using a
>> compiler/language-based
>>             thread-local
>>                      variable eg:
>>
>>                                              static __thread Thread
>>             *_thr_current;
>>
>>                                              inline Thread*
>>             Thread::current() {
>>                                                return _thr_current;
>>                                              }
>>
>>                                           with an appropriate setter of
>>             course. By
>>                      doing this
>>                                           we can completely
>>                                           remove the os_cpu-specific
>>             ThreadLocalStorage
>>                                           implementations, and the
>>                                           associated
>>             os::thread_local_storage* calls.
>>
>>                                           As __thread is not
>>             async-signal-safe (either in
>>                                           theory or practice) we
>>                                           need a fallback library-based
>>             solution as used
>>                                           today. For this we use a
>>                                           very simple ThreadLocalStorage
>>             class and an
>>                                           implementation thereof for
>>                                           POSIX (covers AIX, BSD, Linux,
>>             OSX and
>>                      Solaris) using
>> pthread_get/setspecific; and
>>             one for
>>                      Windows using
>>                                           its TLS library.
>>                                           While these library routines
>>             are not guaranteed
>>                                           async-signal-safe, they
>>                                           seem to be in practice and are
>>             what we have
>>                      been
>>                                           using all along.
>>
>>                                           We also allow for use of 
>> only the
>>                      library-based TLS
>>                                           for platforms where
>>                                           compiler-based thread locals
>>             are not
>>                      supported (as
>>                                           will be needed in
>>                                           the
>>                                           Mobile project). This is
>>             enabled at build
>>                      time by
>>                                           defining
>> USE_LIBRARY_BASED_TLS_ONLY.
>>
>>                                           Thanks to Andrew Haley for
>>             providing the
>>                      Aarch64
>>                                           code; and for Thomas
>>                                           Stuefe for testing PPC and 
>> AIX.
>>
>>                                           Testing:
>>                                              - JPRT (core platforms)
>>                                              - Jtreg tests (linux & 
>> solaris)
>>                                              - vm.runtime (core 
>> platforms)
>>
>>                                           Performance:
>>                                              - still TBD - this is
>>             proving to be
>>                      extremely
>>                                           difficult. If anyone
>>                                           has
>>                                           any simple to run
>>             microbenchmarks to
>>                      suggest I'd
>>                                           give them a try as a
>>                                           sanity check. But I lack
>>             access to hardware for
>>                                           running serious
>>                                           benchmarking.
>>
>>                                           Footprint:
>>                                           - varies by platform and the
>>             VM (server,
>>                      client,
>>                                           minimal)
>>                                           - worst-case: ~1% increase for
>>             server VM
>>                      and minimal VM
>>                                           - best-case:  0.4% decrease
>>             for client VM
>>
>>                                           Thanks,
>>                                           David
>>
>>
>>
>>
>>
>>
>>
>>
>>                  --
>>                  Bertrand Delsart,                     Grenoble
>>             Engineering Center
>>                  Oracle,         180 av. de l'Europe, ZIRST de
>>             Montbonnot
>>                  38330 Montbonnot Saint Martin, FRANCE
>>             bertrand.delsart at oracle.com
>>             <mailto:bertrand.delsart at oracle.com>
>>             <mailto:bertrand.delsart at oracle.com
>>             <mailto:bertrand.delsart at oracle.com>>
>>                            Phone : +33 4 76 18 81 23
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>                  NOTICE: This email message is for the sole use of the
>>             intended
>>                  recipient(s) and may contain confidential and 
>> privileged
>>                  information. Any unauthorized review, use, 
>> disclosure or
>>                  distribution is prohibited. If you are not the intended
>>             recipient,
>>                  please contact the sender by reply email and destroy
>>             all copies of
>>                  the original message.
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>


From david.holmes at oracle.com  Wed Nov 25 23:31:52 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Nov 2015 09:31:52 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUzTxS3CWcv8pdeMEsv8gxgMLjWOgVgHaUP00VbbYVgx4g@mail.gmail.com>
References: <5652BA32.8090207@oracle.com>
	<CAA-vtUzTxS3CWcv8pdeMEsv8gxgMLjWOgVgHaUP00VbbYVgx4g@mail.gmail.com>
Message-ID: <565644E8.2050809@oracle.com>

Hi Thomas,

Thanks for reviewing.

On 26/11/2015 1:20 AM, Thomas St?fe wrote:
> Hi David,
>
> I looked over your latest version at
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8
>
> This all looks nice and builds on AIX. I am currently running some jtreg
> tests.

Thanks. Please let me know if any issues surface. I will need to 
resubmit my own tests after latest changes.

> Some small remarks:
>
> ------------
>
> would it be possible to add a configure option (e.g.
> --enable-compiler-based-tls)? On AIX, disabling compiler level tls also
> makes the -qtls compiler option unnecessary, so it affects the makefile.
>
> Not really important, just would be quite comfortable.

It's possible to file a RFE for this. To be honest I didn't see this as 
some kind of user-defined choice that would need to be configured. The 
intent is that platforms which can't support compiler level TLS simply 
hardwire the flag in their platform specific makefile.

> ------------
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/os/windows/vm/os_windows.cpp.udiff.html
>
> @@ -5175,11 +5159,11 @@
> -  JavaThread* thread = (JavaThread*)(Thread::current());
> +  Thread* thread = Thread::current();
>     assert(thread->is_Java_thread(), "Must be JavaThread");
>     JavaThread *jt = (JavaThread *)thread;
>
> may be simplified to use your new
>
> JavaThread* thread = JavaThread::current();

Indeed it can. Fixed. And changed jt to thread in the following code.

> ------------
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.cpp.udiff.html
>
> in
>
> Thread::clear_thread_current()
>
> we could also add a
>
> assert(Thread::current() == ThreadLocalStorage::thread(), "TLS mismatch!");
>
> to catch a case where library tls slot content changed during lifetime
> of thread.

Fixed.

> ----
>
>   JavaThread* JavaThread::active() {
> -  Thread* thread = ThreadLocalStorage::thread();
> +  Thread* thread = Thread::current();
>     assert(thread != NULL, "just checking");
>
> the assert is unnecessary.

Fixed.
>
> -----
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/runtime/thread.hpp.udiff.html
>
>   // Inline implementation of JavaThread::current
>   inline JavaThread* JavaThread::current() {
> -  Thread* thread = ThreadLocalStorage::thread();
> +  Thread* thread = Thread::current();
>     assert(thread != NULL && thread->is_Java_thread(), "just checking");
>     return (JavaThread*)thread;
>   }
>
> asserting thread != NULL is unnecessary.

Fixed
> -----
>
> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/share/vm/utilities/globalDefinitions_gcc.hpp.udiff.html
>
> (and corresponding globalDefinitions_.. files)
>
> +#define THREAD_LOCAL_DECL __thread
>
> could be surrounded by #ifndef USE_LIBRARY_BASED_TLS_ONLY

Okay - changed.

Updated webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v9/

Thanks,
David
-----

> -----
>
> Kind Regards, Thomas
>
>
>
>
>
>
>
>
> On Mon, Nov 23, 2015 at 8:03 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     After all the preliminary discussions here are final proposed changes:
>
>     bug: https://bugs.openjdk.java.net/browse/JDK-8132510
>
>     Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
>     A simple (in principle) but wide-ranging change which should appeal
>     to our Code Deletion Engineer's. We implement Thread::current()
>     using a compiler/language-based thread-local variable eg:
>
>       static __thread Thread *_thr_current;
>
>       inline Thread* Thread::current() {
>         return _thr_current;
>       }
>
>     with an appropriate setter of course. By doing this we can
>     completely remove the os_cpu-specific ThreadLocalStorage
>     implementations, and the associated os::thread_local_storage* calls.
>
>     As __thread is not async-signal-safe (either in theory or practice)
>     we need a fallback library-based solution as used today. For this we
>     use a very simple ThreadLocalStorage class and an implementation
>     thereof for POSIX (covers AIX, BSD, Linux, OSX and Solaris) using
>     pthread_get/setspecific; and one for Windows using its TLS library.
>     While these library routines are not guaranteed async-signal-safe,
>     they seem to be in practice and are what we have been using all along.
>
>     We also allow for use of only the library-based TLS for platforms
>     where compiler-based thread locals are not supported (as will be
>     needed in the Mobile project). This is enabled at build time by
>     defining USE_LIBRARY_BASED_TLS_ONLY.
>
>     Thanks to Andrew Haley for providing the Aarch64 code; and for
>     Thomas Stuefe for testing PPC and AIX.
>
>     Testing:
>       - JPRT (core platforms)
>       - Jtreg tests (linux & solaris)
>       - vm.runtime (core platforms)
>
>     Performance:
>       - still TBD - this is proving to be extremely difficult. If anyone
>     has any simple to run microbenchmarks to suggest I'd give them a try
>     as a sanity check. But I lack access to hardware for running serious
>     benchmarking.
>
>     Footprint:
>     - varies by platform and the VM (server, client, minimal)
>     - worst-case: ~1% increase for server VM and minimal VM
>     - best-case:  0.4% decrease for client VM
>
>     Thanks,
>     David
>
>

From david.holmes at oracle.com  Wed Nov 25 23:51:26 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Nov 2015 09:51:26 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <56563F61.4030008@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
	<CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
	<56563BA0.1010307@oracle.com> <56563F61.4030008@oracle.com>
Message-ID: <5656497E.2050208@oracle.com>

On 26/11/2015 9:08 AM, Daniel D. Daugherty wrote:
> If I understand the problem... :-)
>
> The Win-X64 ABI requires that some extra space be allocated on
> the stack in the caller for "homing" four registers...
>
> This code uses MacroAssembler::call() which is a lower level
> call() function that assumes you know the ABI...
>
> 9765 void MacroAssembler::get_thread(Register thread) {
> <snip>
> 9784   call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current)));

So the failing here was nothing to do with register saving per-se, nor 
the alignment code, but "simply" not also saving the extra space prior 
to the call!

> If you switch to MacroAssembler::call_VM_leaf_base() it handles
> more of the gory details for you than MacroAssembler::call():

Wow! Not exactly a clearly-defined name for this. AFAICS there's nothing 
VM or leaf specific about this. Also the MacroAssembler is supposed to 
be a platform-agnostic higher-level abstraction that is easy to use - 
but in this case every use of the plain call on Windows-x64 is 
potentially broken if the programmer was not aware of this ABI 
constraint which only applies to Windows (and we're in OS-neutral files!).

This seems fundamentally broken to me.

Thanks for the info.

David

> src/cpu/x86/vm/macroAssembler_x86.cpp:
>
>     524  void MacroAssembler::call_VM_leaf_base(address entry_point, int
> num_args
> ) {
>     525    Label L, E;
>     526
>     527  #ifdef _WIN64
>     528    // Windows always allocates space for it's register args
>     529    assert(num_args <= 4, "only register arguments supported");
>     530    subq(rsp,  frame::arg_reg_save_area_bytes);
>     531  #endif
>     532
>     533    // Align stack if necessary
>     534    testl(rsp, 15);
>     535    jcc(Assembler::zero, L);
>     536
>     537    subq(rsp, 8);
>     538    {
>     539      call(RuntimeAddress(entry_point));
>     540    }
>
> So call_VM_leaf_base() allocates the "homing" space for register
> args for Win-X64 on L530 and it handles any stack alignment before
> calling MacroAssembler::call().
>
> So if you switch to call_VM_leaf_base() you can drop
> the stack alignment code:
>
> 9777   // ensure stack alignment
> 9778   mov(r10, rsp);
> 9779   andq(rsp, -16);
> 9780   push(r10);
>
> and just switch to:
>
> 9777   push(rsp);
>
> And you won't be exposed to potential saved register
> overwrite by the "homing" of any registers in the call
> Thread::current().
>
> I _think_ I have that all correct... :-)
>
> Dan
>
>
> On 11/25/15 3:52 PM, David Holmes wrote:
>> On 26/11/2015 2:53 AM, Thomas St?fe wrote:
>>> I created a bug to track this:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8144059
>>
>> Thanks. I admit I still don't really grok the exact problem here. It
>> is the alignment code that is the problem right?
>>
>> 79 mov(r10, rsp);
>> 80 andq(rsp, -16);
>> 81 push(r10);
>>
>> ?
>>
>> Thanks,
>> David
>>
>>> Because Davids change is not submitted yet, the bug refers to the old
>>> coding, but stays relevant also after this fix.
>>>
>>> Kind Regards, Thomas
>>>
>>> On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty
>>> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>>
>>> wrote:
>>>
>>>     On 11/25/15 6:10 AM, David Holmes wrote:
>>>
>>>         On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>>>
>>>
>>>             On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
>>>             <bertrand.delsart at oracle.com
>>>             <mailto:bertrand.delsart at oracle.com>
>>>             <mailto:bertrand.delsart at oracle.com
>>>             <mailto:bertrand.delsart at oracle.com>>> wrote:
>>>
>>>                  Good finding Thomas,
>>>
>>>                  On 25/11/2015 09:40, Thomas St?fe wrote:
>>>
>>>                      Hi David, Bertrand,
>>>
>>>                      about
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>>
>>>
>>>                      I am not sure this is correct for Windows x64.
>>>
>>>
>>>                  Unless I'm misreading it, the new code looks a lot like
>>>             the old one
>>>                  (including the alignement part). Hence this does not
>>>             look like a
>>>                  regression caused by David's change.
>>>
>>>
>>>             Yes, this seems like an old bug.
>>>
>>>             I also see that this is fixed in our codebase since 2010,
>>>             exactly the
>>>             way you propose (with MacroAssembler
>>> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
>>>
>>>
>>> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
>>>
>>>
>>>             So, it is already used since five years. I would propose
>>>             opening a
>>>             separate bug for this one and we contribute our fix.
>>>
>>>
>>>         That sounds good to me too. I also suspect additional code will
>>>         need to be checked as this stack alignment is performed in a few
>>>         places in ./cpu/x86/vm/macroAssembler_x86.cpp with no OS
>>>         specific differences being considered.
>>>
>>>
>>>     Looks like MacroAssembler::call_VM_leaf_base() does the "right
>>> thing"
>>>     for stack alignment in the X64 case. Perhaps we need to audit both
>>>     stack alignment _and_ uses of MacroAssembler::call() just to make
>>>     sure...
>>>
>>>     Did I mention that all the assembly code stuff gives me a
>>> headache? :-)
>>>
>>>     Dan
>>>
>>>
>>>
>>>
>>>         Thanks,
>>>         David
>>>
>>>             Regards, Thomas
>>>
>>>
>>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>>
>>>                      windows x64 Abi requires the register parameter
>>>             area right above the
>>>                      return address on the stack. It is not
>>> guaranteed to be
>>>                      preserved during
>>>                      the function call:
>>>
>>>                      "Even if the called function has fewer than 4
>>>             parameters, these
>>>                      4 stack
>>>                      locations are effectively owned by the called
>>>             function, and may
>>>                      be used
>>>                      by the called function for other purposes besides
>>>             saving parameter
>>>                      register values. Thus the caller may not save
>>>             information in
>>>                      this region
>>>                      of stack across a function call."
>>>
>>>                      So, restoring parameters from it may not work if
>>>                      Thread::current() uses
>>>                      this area for any reason. In this case, r9, rsp,
>>>             r10, r11 may be
>>>                      overwritten by the callee.
>>>
>>>                      I also think Windows x64 ABI is different enough
>>>             from Linux that
>>>                      this
>>>                      function could live somewhere in <os>_<cpu>.
>>>
>>>
>>>                  This is a valid point. However, note that this is
>>>             similar to the
>>>                  issue we have for instance in 'shared'
>>>                  MacroAssembler::call_VM_leaf_base, which was not put in
>>>             <os>_<cpu>
>>>                  files.
>>>
>>>                  In fact, the right fix may be to use call_VM_leaf
>>>             instead of call :-)
>>>
>>>                  (alternatively we could use "#ifdef _WIN64" or check
>>>                  "frame::arg_reg_save_area_bytes != 0", which may be
>>>             even cleaner and
>>>                  more portable)
>>>
>>>                  All these solutions are fine for me.
>>>
>>>
>>>                  Since we are near to feature freeze, this should
>>>             probably be done in
>>>                  a separate CR (unless David has enough time to test
>>> it).
>>>
>>>                  Regards,
>>>
>>>                  Bertrand.
>>>
>>>
>>>                      Kind Regards, Thomas
>>>
>>>
>>>
>>>
>>>                      On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>>>                      <david.holmes at oracle.com
>>>             <mailto:david.holmes at oracle.com>
>>>             <mailto:david.holmes at oracle.com
>>>             <mailto:david.holmes at oracle.com>>
>>>                      <mailto:david.holmes at oracle.com
>>>             <mailto:david.holmes at oracle.com>
>>>                      <mailto:david.holmes at oracle.com
>>>             <mailto:david.holmes at oracle.com>>>> wrote:
>>>
>>>                           On 23/11/2015 11:46 PM, Bertrand Delsart
>>> wrote:
>>>
>>>                               On 23/11/2015 13:27, David Holmes wrote:
>>>
>>>                                   Hi Bertrand,
>>>
>>>                                   On 23/11/2015 8:14 PM, Bertrand
>>>             Delsart wrote:
>>>
>>>                                       Hi David,
>>>
>>>                                       Overall looks good.
>>>                                       Thanks for the #ifndef
>>>                      USE_LIBRARY_BASED_TLS_ONLY :-)
>>>
>>>                                       One doubt, in case this has not
>>>             been discussed
>>>                      before.
>>>
>>>                                       I'm still catching up on x86_64
>>>             (after years of ARM
>>>                                       assembly :-)) but it
>>>                                       seems that there are some stack
>>>             alignment
>>>                      constraints on
>>>                                       runtime calls,
>>>                                       at least for some x86_64 ABIs.
>>>
>>>                                       Some of the x86
>>>             MacroAssembler::get_thread
>>>                                       implementations had code to
>>>                                       align the stack before calling
>>>                      pthread_getspecific. See
>>>                                       for instance
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>
>>>
>>>
>>>
>>>                                   Sorry I'm not that familiar with the
>>>             MacroAssembler
>>>                      - is it
>>>                                   this odd
>>>                                   fragment:
>>>
>>>                                   -   push(r10);
>>>                                   -   // XXX
>>>                                   -   mov(r10, rsp);
>>>                                   -   andq(rsp, -16);
>>>                                   -   push(r10);
>>>
>>>                                   I'm not at all clear what that is
>>>             doing - and if it
>>>                      somehow
>>>                                   changes the
>>>                                   alignment wouldn't something need to
>>>             be fixed up when
>>>                                   popping the
>>>                                   previous values ??
>>>
>>>                                   To be honest I'm not even sure what an
>>>             "unaligned
>>>                      stack" means.
>>>
>>>
>>>                               On some platforms, SP may have to be
>>>             aligned on a 16 bytes
>>>                               boundary when
>>>                               calling another method.
>>>
>>>
>>>                           Okay - that seems to be an x64 ABI requirement
>>>             based on
>>>                      other code
>>>                           in MacroAssembler. The reason it is missing in
>>>             the Solaris
>>>                      code is
>>>                           because I already removed it in the earlier
>>>             changes that
>>>                      were done
>>>                           on Solaris:
>>>
>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>
>>>                           and nobody picked it up. :(
>>>
>>>                           That said, the absence of this code has not
>>>             caused any
>>>                      problems so
>>>                           presumably we are normally aligned.
>>>
>>>                               After having pushed what needed to be
>>>             saved, the code above
>>>                               rounds SP
>>>                               down and saves the old value. It will then
>>>             also push
>>>                      r11, which
>>>                               results
>>>                               in the expected alignment.
>>>
>>>                               The conterpart, after the VM call, is the:
>>>                                  pop(r11);
>>>                                  pop(rsp);
>>>
>>>
>>>                           I had assumed this extra manipulation was
>>>             related to
>>>                      pushing the arg
>>>                           for the call.
>>>
>>>                                       This alignment is no longer
>>>             performed in the new
>>>                                       (shared) implementation
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>
>>>
>>>
>>>
>>>
>>>                                       Now, Solaris was not performing
>>>             the alignment and
>>>                                       Windows has a separate
>>>                                       path for x86_64. Did we really
>>>             need the
>>>                      alignment for
>>>                                       linux x86_64 and
>>>                                       bsd_x86_64 ? Might it be needed
>>>             for other ports ?
>>>
>>>                                       IMHO, it might be safer to align
>>>             the stack by
>>>                      default,
>>>                                       knowing it should
>>>                                       not be expensive since we call
>>>             get_thread
>>>                      rarely for
>>>                                       x86_64 (result is
>>>                                       cached in r15). I'll let you see
>>>             whether it is
>>>                      worth
>>>                                       adding an ifdef so
>>>                                       as to explicitly deactivate the
>>>             alignment on
>>>                      some platforms
>>>                                       (solaris_x86_64 ?)
>>>
>>>
>>>                                   I don't have enough knowledge to even
>>>             begin to
>>>                      comment on
>>>                                   this. I will
>>>                                   have to rely on our x86_64
>>>             macroassembler experts
>>>                      to explain
>>>                                   the old
>>>                                   code and what the requirements are.
>>>
>>>
>>>                               OK. This means that the alignment was not
>>>             removed
>>>                      purposefully.
>>>
>>>                               In that case, you must either keep the per
>>>             platform
>>>                      code x86_64
>>>                               (since
>>>                               it was not identical for all platforms) or
>>>             use the safest
>>>                               version, with
>>>                               the additional
>>>
>>>                                    // XXX
>>>                                    mov(r10, rsp);
>>>                                    andq(rsp, -16);
>>>                                    push(r10);
>>>
>>>                               before the push(r11) and with the
>>>
>>>                                    pop(rsp);
>>>
>>>                               after the pop(r11). It should work on all
>>>             x86_64 platforms.
>>>
>>>
>>>                           Right, I will add this back to the code - and
>>>             replace the
>>>                           meaningless // XXX with an actual comment!
>>>
>>>                           Many thanks,
>>>                           David
>>>                           -----
>>>
>>>
>>>                               FYI, there is another way to do the
>>>             alignment, based on
>>>                      the fact
>>>                               that
>>>                               we are at least aligned on 8 bytes (see
>>> MacroAssembler::call_VM_leaf_base). I
>>>             assume that this
>>>                      second
>>>                               version is
>>>                               more efficient (particularly thanks to
>>>             specilative
>>>                      branches) but it
>>>                               might be safer/simpler to continue using
>>>             andq in
>>>                      get_thread.
>>>
>>>                               Bertrand.
>>>
>>>
>>>                                   Thanks,
>>>                                   David
>>>
>>>                                       Regards,
>>>
>>>                                       Bertrand.
>>>
>>>
>>>
>>>                                       On 23/11/2015 08:03, David Holmes
>>>             wrote:
>>>
>>>                                           After all the preliminary
>>>             discussions here
>>>                      are final
>>>                                           proposed changes:
>>>
>>>                                           bug:
>>>             https://bugs.openjdk.java.net/browse/JDK-8132510
>>>
>>>                                           Open webrev:
>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>
>>>                                           A simple (in principle) but
>>>             wide-ranging change
>>>                                           which should appeal to
>>>                                           our Code Deletion Engineer's.
>>>             We implement
>>>                                           Thread::current() using a
>>> compiler/language-based
>>>             thread-local
>>>                      variable eg:
>>>
>>>                                              static __thread Thread
>>>             *_thr_current;
>>>
>>>                                              inline Thread*
>>>             Thread::current() {
>>>                                                return _thr_current;
>>>                                              }
>>>
>>>                                           with an appropriate setter of
>>>             course. By
>>>                      doing this
>>>                                           we can completely
>>>                                           remove the os_cpu-specific
>>>             ThreadLocalStorage
>>>                                           implementations, and the
>>>                                           associated
>>>             os::thread_local_storage* calls.
>>>
>>>                                           As __thread is not
>>>             async-signal-safe (either in
>>>                                           theory or practice) we
>>>                                           need a fallback library-based
>>>             solution as used
>>>                                           today. For this we use a
>>>                                           very simple ThreadLocalStorage
>>>             class and an
>>>                                           implementation thereof for
>>>                                           POSIX (covers AIX, BSD, Linux,
>>>             OSX and
>>>                      Solaris) using
>>> pthread_get/setspecific; and
>>>             one for
>>>                      Windows using
>>>                                           its TLS library.
>>>                                           While these library routines
>>>             are not guaranteed
>>>                                           async-signal-safe, they
>>>                                           seem to be in practice and are
>>>             what we have
>>>                      been
>>>                                           using all along.
>>>
>>>                                           We also allow for use of
>>> only the
>>>                      library-based TLS
>>>                                           for platforms where
>>>                                           compiler-based thread locals
>>>             are not
>>>                      supported (as
>>>                                           will be needed in
>>>                                           the
>>>                                           Mobile project). This is
>>>             enabled at build
>>>                      time by
>>>                                           defining
>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>
>>>                                           Thanks to Andrew Haley for
>>>             providing the
>>>                      Aarch64
>>>                                           code; and for Thomas
>>>                                           Stuefe for testing PPC and
>>> AIX.
>>>
>>>                                           Testing:
>>>                                              - JPRT (core platforms)
>>>                                              - Jtreg tests (linux &
>>> solaris)
>>>                                              - vm.runtime (core
>>> platforms)
>>>
>>>                                           Performance:
>>>                                              - still TBD - this is
>>>             proving to be
>>>                      extremely
>>>                                           difficult. If anyone
>>>                                           has
>>>                                           any simple to run
>>>             microbenchmarks to
>>>                      suggest I'd
>>>                                           give them a try as a
>>>                                           sanity check. But I lack
>>>             access to hardware for
>>>                                           running serious
>>>                                           benchmarking.
>>>
>>>                                           Footprint:
>>>                                           - varies by platform and the
>>>             VM (server,
>>>                      client,
>>>                                           minimal)
>>>                                           - worst-case: ~1% increase for
>>>             server VM
>>>                      and minimal VM
>>>                                           - best-case:  0.4% decrease
>>>             for client VM
>>>
>>>                                           Thanks,
>>>                                           David
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>                  --
>>>                  Bertrand Delsart,                     Grenoble
>>>             Engineering Center
>>>                  Oracle,         180 av. de l'Europe, ZIRST de
>>>             Montbonnot
>>>                  38330 Montbonnot Saint Martin, FRANCE
>>>             bertrand.delsart at oracle.com
>>>             <mailto:bertrand.delsart at oracle.com>
>>>             <mailto:bertrand.delsart at oracle.com
>>>             <mailto:bertrand.delsart at oracle.com>>
>>>                            Phone : +33 4 76 18 81 23
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>                  NOTICE: This email message is for the sole use of the
>>>             intended
>>>                  recipient(s) and may contain confidential and
>>> privileged
>>>                  information. Any unauthorized review, use,
>>> disclosure or
>>>                  distribution is prohibited. If you are not the intended
>>>             recipient,
>>>                  please contact the sender by reply email and destroy
>>>             all copies of
>>>                  the original message.
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>>
>>>
>

From david.holmes at oracle.com  Thu Nov 26 02:11:46 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Nov 2015 12:11:46 +1000
Subject: Fwd: Re: Request for Review (s) - 8133023: ParallelGCThreads is
	not calculated correctly
In-Reply-To: <56563B4D.3030301@oracle.com>
References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com>
Message-ID: <56566A62.4030902@oracle.com>

Hi Jon,

We already have VM_Version::early_initialize() that can/should be used 
for this if possible.

Thanks,
David

On 26/11/2015 8:50 AM, Jon Masamitsu wrote:
> Widening the review request.  This fixed changed the order
> of some VM initialization for solaris-sparc with hopefully
> the minimum change for other platforms.
>
> Thanks.
>
> Jon
>
> -------- Forwarded Message --------
> Subject:     Re: Request for Review (s) - 8133023: ParallelGCThreads is
> not calculated correctly
> Date:     Wed, 25 Nov 2015 14:10:36 -0800
> From:     Jon Masamitsu <jon.masamitsu at oracle.com>
> Organization:     Oracle Corporation
> To:     hotspot-gc-dev at openjdk.java.net
>
>
>
> I have a new fix for this bug.  My previous fix broke solaris-x86 (I
> had not defined an early_initialize() for x86).  This fix is slightly
> smaller and has the virtue of moving the required initialization
> closer to where it is used.
>
> http://cr.openjdk.java.net/~jmasa/8133023/webrev.03/index.html
>
> Testing: JPRT build on all platforms, checked by hand that the correct
> number
> of GC worker threads are created on later Niagara platforms.
>
> Thanks.
>
> Jon
>
> On 11/12/2015 1:31 PM, Jon Masamitsu wrote:
>> GC calls VM_Version::calc_parallel_worker_threads() to determine
>> the number of GC threads to create.  On Sparc it checks for newer
>> Niagara hardware to decide the proper scaling of the GC threads with
>> the hardware threads. calc_parallel_worker_threads() was being called
>> before enough information was gathered to determine the Sparc hardware.
>>
>> Moved the gathering of information needed to earlier in the JVM
>> initialization.
>>
>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.00/
>>
>> https://bugs.openjdk.java.net/browse/JDK-8133023
>>
>> Thanks.
>>
>> Jon
>
>
>

From david.holmes at oracle.com  Thu Nov 26 04:47:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Nov 2015 14:47:04 +1000
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <56557936.3070109@oracle.com>
References: <56557936.3070109@oracle.com>
Message-ID: <56568EC8.1080803@oracle.com>

On 25/11/2015 7:02 PM, Erik Joelsson wrote:
> Hello,
>
> The following new build failure has appeared in the hotspot build when
> using the proposed new compiler version on Solaris, SS12u4.
>
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp",
> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&,
> DIR_Chunk*const&) is not accessible from
> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp",
> line 281: Where: While instantiating
> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)".
>
> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp",
> line 281: Where: Instantiated from non-template code.

I'm really struggling to see how those error messages relate to the fix!

David
-----

> Tom Rodriguez provided a patch and I have verified that it solves the
> issue. Since this is blocking us upgrading compilers on Solaris, I am
> taking the liberty of posting it for review so we may get this resolved
> quickly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>
> /Erik

From Leonid.Mesnik at oracle.com  Thu Nov 26 06:58:30 2015
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Thu, 26 Nov 2015 09:58:30 +0300
Subject: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting
In-Reply-To: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com>
References: <2D3984B6-91DE-451F-A814-FD5E30237CE1@oracle.com>
Message-ID: <5656AD96.4040308@oracle.com>

Hi

These changes were already reviewed internally.
Looks good for me. Please get official review from Reviewers.

Leonid

On 24.11.2015 22:13, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/
>> 3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg
> Hi,
>
> Could you please review the webrev[0] for JEP 279[1]?
>
> The scope of the JEP is an implementation of a library which uses jtreg timeout handler and observer extension points to collect information about environment in case of test failures (including timeouts) and about test processes in case of timeouts. This data is then presented together with the test failure to simplify analysis.
>
> To make it easier to specify which tools should be run by the library on which platform when a test failure or timeout occurs, we use properties files to configure the library. Each platform family uses its own property file (named <family>.properties) and common.properties, which contains platform independent tools, such as jps. Using property files allows to easily extend the tools that are used to collect information on test failure or timeout in the future. See the JEP for a more thorough overview of the collected data. Currently, we are using the following tools:
> - on all platforms[3]: jps, jstack, jmap, jinfo, jcmd
> - on linux[4]: ps, pmap, lsof, lslocks, gdb, gcore, id, who, last, df, env, dmesg, sysctl, top, free, vmstat, netstat
> - on solaris[5]: pgrep, pmap, pfiles, pstack, gcore, id, who, last, df, env, dmesg, prtconf, sysdef, swap, ps, top, vmstat, pagesize, netstat
> - on mac[6]: pgrep, vmmap, heap, leaks, spindump, lldb, gcore, id, who, last, df, env, dmesg, sysctl, ps, top, vm_stat, netstat
> - on windows[7]: wmic, pmap, handle, cdb, id, who, last, df, env, powershell, tasklist, ps, top, free, vmstat, openfiles, netstat
>
> More information can be found in the JEP[1] and README[2].
>
> The library integration into makefiles will be done later as the fix for JDK-8132962[8].
>
> [0] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/
> [1] https://bugs.openjdk.java.net/browse/JDK-8075621
> [2] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/README.html
> [3] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/common.properties.html
> [4] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/linux.properties.html
> [5] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/solaris.properties.html
> [6] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/mac.properties.html
> [7] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/windows.properties.html
> [8] https://bugs.openjdk.java.net/browse/JDK-8132962
>
> Thanks,
> ? Igor


From goetz.lindenmaier at sap.com  Thu Nov 26 08:29:27 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 26 Nov 2015 08:29:27 +0000
Subject: RFR(L): 8143125: [aix] Further Developments for AIX
In-Reply-To: <CAA-vtUzZpskQsS7NTxdxV_1VsFpX+jdeBz85WSgx3SKE-1hSTA@mail.gmail.com>
References: <CAA-vtUy17NvzE_qKbXyoz2ETX=h0RBjRFTHWH7nxwaenHcKVvg@mail.gmail.com>
	<4295855A5C1DE049A61835A1887419CC41ED076B@DEWDFEMB12A.global.corp.sap>
	<CAA-vtUzZpskQsS7NTxdxV_1VsFpX+jdeBz85WSgx3SKE-1hSTA@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41ED242C@DEWDFEMB12A.global.corp.sap>

Hi Thomas,

thanks a lot for doing all these changes.
Looks good now.

Could you add the change comment to the patch before you
Make a webrev next time?  Simplifies sponsoring ;)

Best regards,
  Goetz.

From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
Sent: Mittwoch, 25. November 2015 18:01
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(L): 8143125: [aix] Further Developments for AIX

Hi Goetz,

new webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8143125-Further/webrev.01/webrev/

thank you for reviewing! See remarks inline...

On Tue, Nov 24, 2015 at 12:38 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:
Hi Thomas,

I looked at your change.  It?s good we get these improvements into
openJDK.  But I think we should skip some stuff that's not (yet?)
used there.  I'll sponsor the change. Details:

libperfstat_aix.cpp:

What do you need
static fun_perfstat_partition_total_t g_fun_perfstat_partition_total = NULL;
static fun_perfstat_wpar_total_t    g_fun_perfstat_wpar_total = NULL;
static fun_wpar_getcid_t            g_fun_wpar_getcid = NULL;
for? I think they are never used.

They are now used (for the respective wrapper functions which in turn are used in os_aix.cpp. Sorry for omitting this code.

libperfstat_aix.cpp:161
We support AIX 5.3 with xlC12 only. I think we need not add the older
#defines to openJDK. Also, the comment should be adapted and not mention xlc8 etc.
Also, there are datastructures for 5.2 which can be removed.

Removed the older defines.
I would for now prefer to leave the AIX 5.2 data structures in this file. I am not sure if we could encounter older libperfstat versions on AIX 5.3 too. I plan to rework this coding to get rid of the duplicate structure definitions, but would prefer to do this in a separate patch.


Where is this used?
bool libperfstat::get_wparinfo(wparinfo_t* pwi)
Do we need it if it's not used?

It is now used :) in os_aix.cpp.


libperfstat.hpp:835
I would remove these prototypes commented out.

I removed them.

loadlib_aix.cpp
Why do you do these changes? Please revert them.

I reverted them.

os_aix.hpp:219
What's this good for?
get_brk_at_startup()
get_lowest_allocation_above_brk()

I removed those prototypes.

os_aix.hpp:259
What's this good for?
parse_qsyslib_path()

I removed this prototype.

os_aix.cpp:410
Why do you move query_multipage_support()?

I moved this back to its original position.

os_aix.inline.hpp:164
Why do you reverse the order of the functions here?
The old order is the same as in the related files os_linux.inline.hpp etc.

I reversed the order back to original order.

Best regards,
  Goetz.


Kind Regards, Thomas


> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net<mailto:hotspot-dev-bounces at openjdk.java.net>] On
> Behalf Of Thomas St?fe
> Sent: Freitag, 20. November 2015 11:49
> To: ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>; HotSpot Open Source Developers
> Subject: RFR(L): 8143125: [aix] Further Developments for AIX
>
> Hi all,
>
> please review and sponsor these AIX only changes. Basically, with this
> change we bring the OpenJDK AIX hotspot port up to speed with the
> developments done at SAP in the recent months.
>
> For a more detailled number of changes and fixes, please refer to the bug
> description.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143125
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8143125-
> Further/webrev.00/webrev/index.html
>
> Kind Regards, Thomas


From paul.sandoz at oracle.com  Thu Nov 26 09:03:11 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Nov 2015 10:03:11 +0100
Subject: RFR JDK-8141491: Unaligned memory access in Bits.c
In-Reply-To: <CAHQ51u6wyy3BMjV9U7NUUY0VcRzH+qHEPz=Vc7jWn_m-KTZ3Uw@mail.gmail.com>
References: <CAHQ51u6wyy3BMjV9U7NUUY0VcRzH+qHEPz=Vc7jWn_m-KTZ3Uw@mail.gmail.com>
Message-ID: <9448F36A-E8AF-4852-8E83-168AA58678DC@oracle.com>

Hi Sasha,

Bits.c
?

Some minor typos.

  55 /* The destination buffer passed to Java_java_nio_Bits_copyFromShor<type>tArray

s/copyFromShor<type>tArray/copyFrom<type>Array

  58  * 'unaligned' attribute, provided it supports this attribute. Fro recent

s/Fro/For

Paul.

> On 25 Nov 2015, at 20:19, Alexander Smundak <asmundak at google.com> wrote:
> 
> Please take a look at
> http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
> that fixes the problem.
> 
> It utilizes the ability of some (GCC and Clang) to declare data
> alignment explicitly.
> I have verified it works on x86_64 Linux by running
> jdk/test/java/nio/Buffer/Basic.java test
> 
> I need a sponsor.
> 
> Sasha


From thomas.stuefe at gmail.com  Thu Nov 26 09:56:59 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Nov 2015 10:56:59 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <5656497E.2050208@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
	<CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
	<56563BA0.1010307@oracle.com> <56563F61.4030008@oracle.com>
	<5656497E.2050208@oracle.com>
Message-ID: <CAA-vtUw=BNfxq_1fUGGs=QNHu2KQ+sGCpyrcPnDcRo0788gC4A@mail.gmail.com>

Hi David,


On Thu, Nov 26, 2015 at 12:51 AM, David Holmes <david.holmes at oracle.com>
wrote:

> On 26/11/2015 9:08 AM, Daniel D. Daugherty wrote:
>
>> If I understand the problem... :-)
>>
>> The Win-X64 ABI requires that some extra space be allocated on
>> the stack in the caller for "homing" four registers...
>>
>> This code uses MacroAssembler::call() which is a lower level
>> call() function that assumes you know the ABI...
>>
>> 9765 void MacroAssembler::get_thread(Register thread) {
>> <snip>
>> 9784   call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current)));
>>
>
> So the failing here was nothing to do with register saving per-se, nor the
> alignment code, but "simply" not also saving the extra space prior to the
> call!
>
>
Yes. These 32 byte are a scratch area for the callee, which may be used for
parameter registers or anything else. We may just have been lucky so far
that TlsGetValue() did not use this area. As Bertrand already said, now we
call Thread::current(), which does magic tls accesses under the hood, so
this must be tested again.

However I think that a simple addition to your current fix could simply be
subtracting 32 from rsp before the call:

subq(rsp, 32)
call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current)));
addq(rsp, 32)

Also, we could probably skip saving/restoring rdi and rsi on Windows:

https://msdn.microsoft.com/en-us/library/6t169e9c.aspx

"The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile and
must be considered destroyed on function calls (unless otherwise
safety-provable by analysis such as whole program optimization). The
registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered
nonvolatile and must be saved and restored by a function that uses them."

Best Regards, Thomas


If you switch to MacroAssembler::call_VM_leaf_base() it handles
>> more of the gory details for you than MacroAssembler::call():
>>
>
> Wow! Not exactly a clearly-defined name for this. AFAICS there's nothing
> VM or leaf specific about this. Also the MacroAssembler is supposed to be a
> platform-agnostic higher-level abstraction that is easy to use - but in
> this case every use of the plain call on Windows-x64 is potentially broken
> if the programmer was not aware of this ABI constraint which only applies
> to Windows (and we're in OS-neutral files!).
>
> This seems fundamentally broken to me.
>
> Thanks for the info.
>
> David
>
>
> src/cpu/x86/vm/macroAssembler_x86.cpp:
>>
>>     524  void MacroAssembler::call_VM_leaf_base(address entry_point, int
>> num_args
>> ) {
>>     525    Label L, E;
>>     526
>>     527  #ifdef _WIN64
>>     528    // Windows always allocates space for it's register args
>>     529    assert(num_args <= 4, "only register arguments supported");
>>     530    subq(rsp,  frame::arg_reg_save_area_bytes);
>>     531  #endif
>>     532
>>     533    // Align stack if necessary
>>     534    testl(rsp, 15);
>>     535    jcc(Assembler::zero, L);
>>     536
>>     537    subq(rsp, 8);
>>     538    {
>>     539      call(RuntimeAddress(entry_point));
>>     540    }
>>
>> So call_VM_leaf_base() allocates the "homing" space for register
>> args for Win-X64 on L530 and it handles any stack alignment before
>> calling MacroAssembler::call().
>>
>> So if you switch to call_VM_leaf_base() you can drop
>> the stack alignment code:
>>
>> 9777   // ensure stack alignment
>> 9778   mov(r10, rsp);
>> 9779   andq(rsp, -16);
>> 9780   push(r10);
>>
>> and just switch to:
>>
>> 9777   push(rsp);
>>
>> And you won't be exposed to potential saved register
>> overwrite by the "homing" of any registers in the call
>> Thread::current().
>>
>> I _think_ I have that all correct... :-)
>>
>> Dan
>>
>>
>> On 11/25/15 3:52 PM, David Holmes wrote:
>>
>>> On 26/11/2015 2:53 AM, Thomas St?fe wrote:
>>>
>>>> I created a bug to track this:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8144059
>>>>
>>>
>>> Thanks. I admit I still don't really grok the exact problem here. It
>>> is the alignment code that is the problem right?
>>>
>>> 79 mov(r10, rsp);
>>> 80 andq(rsp, -16);
>>> 81 push(r10);
>>>
>>> ?
>>>
>>> Thanks,
>>> David
>>>
>>> Because Davids change is not submitted yet, the bug refers to the old
>>>> coding, but stays relevant also after this fix.
>>>>
>>>> Kind Regards, Thomas
>>>>
>>>> On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty
>>>> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>>
>>>> wrote:
>>>>
>>>>     On 11/25/15 6:10 AM, David Holmes wrote:
>>>>
>>>>         On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>>>>
>>>>
>>>>             On Wed, Nov 25, 2015 at 10:22 AM, Bertrand Delsart
>>>>             <bertrand.delsart at oracle.com
>>>>             <mailto:bertrand.delsart at oracle.com>
>>>>             <mailto:bertrand.delsart at oracle.com
>>>>             <mailto:bertrand.delsart at oracle.com>>> wrote:
>>>>
>>>>                  Good finding Thomas,
>>>>
>>>>                  On 25/11/2015 09:40, Thomas St?fe wrote:
>>>>
>>>>                      Hi David, Bertrand,
>>>>
>>>>                      about
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>>>
>>>>
>>>>                      I am not sure this is correct for Windows x64.
>>>>
>>>>
>>>>                  Unless I'm misreading it, the new code looks a lot like
>>>>             the old one
>>>>                  (including the alignement part). Hence this does not
>>>>             look like a
>>>>                  regression caused by David's change.
>>>>
>>>>
>>>>             Yes, this seems like an old bug.
>>>>
>>>>             I also see that this is fixed in our codebase since 2010,
>>>>             exactly the
>>>>             way you propose (with MacroAssembler
>>>> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot
>>>> >::call_VM_leaf_base
>>>>
>>>>
>>>> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot
>>>> >).
>>>>
>>>>
>>>>             So, it is already used since five years. I would propose
>>>>             opening a
>>>>             separate bug for this one and we contribute our fix.
>>>>
>>>>
>>>>         That sounds good to me too. I also suspect additional code will
>>>>         need to be checked as this stack alignment is performed in a few
>>>>         places in ./cpu/x86/vm/macroAssembler_x86.cpp with no OS
>>>>         specific differences being considered.
>>>>
>>>>
>>>>     Looks like MacroAssembler::call_VM_leaf_base() does the "right
>>>> thing"
>>>>     for stack alignment in the X64 case. Perhaps we need to audit both
>>>>     stack alignment _and_ uses of MacroAssembler::call() just to make
>>>>     sure...
>>>>
>>>>     Did I mention that all the assembly code stuff gives me a
>>>> headache? :-)
>>>>
>>>>     Dan
>>>>
>>>>
>>>>
>>>>
>>>>         Thanks,
>>>>         David
>>>>
>>>>             Regards, Thomas
>>>>
>>>>
>>>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>>>
>>>>                      windows x64 Abi requires the register parameter
>>>>             area right above the
>>>>                      return address on the stack. It is not
>>>> guaranteed to be
>>>>                      preserved during
>>>>                      the function call:
>>>>
>>>>                      "Even if the called function has fewer than 4
>>>>             parameters, these
>>>>                      4 stack
>>>>                      locations are effectively owned by the called
>>>>             function, and may
>>>>                      be used
>>>>                      by the called function for other purposes besides
>>>>             saving parameter
>>>>                      register values. Thus the caller may not save
>>>>             information in
>>>>                      this region
>>>>                      of stack across a function call."
>>>>
>>>>                      So, restoring parameters from it may not work if
>>>>                      Thread::current() uses
>>>>                      this area for any reason. In this case, r9, rsp,
>>>>             r10, r11 may be
>>>>                      overwritten by the callee.
>>>>
>>>>                      I also think Windows x64 ABI is different enough
>>>>             from Linux that
>>>>                      this
>>>>                      function could live somewhere in <os>_<cpu>.
>>>>
>>>>
>>>>                  This is a valid point. However, note that this is
>>>>             similar to the
>>>>                  issue we have for instance in 'shared'
>>>>                  MacroAssembler::call_VM_leaf_base, which was not put in
>>>>             <os>_<cpu>
>>>>                  files.
>>>>
>>>>                  In fact, the right fix may be to use call_VM_leaf
>>>>             instead of call :-)
>>>>
>>>>                  (alternatively we could use "#ifdef _WIN64" or check
>>>>                  "frame::arg_reg_save_area_bytes != 0", which may be
>>>>             even cleaner and
>>>>                  more portable)
>>>>
>>>>                  All these solutions are fine for me.
>>>>
>>>>
>>>>                  Since we are near to feature freeze, this should
>>>>             probably be done in
>>>>                  a separate CR (unless David has enough time to test
>>>> it).
>>>>
>>>>                  Regards,
>>>>
>>>>                  Bertrand.
>>>>
>>>>
>>>>                      Kind Regards, Thomas
>>>>
>>>>
>>>>
>>>>
>>>>                      On Mon, Nov 23, 2015 at 10:42 PM, David Holmes
>>>>                      <david.holmes at oracle.com
>>>>             <mailto:david.holmes at oracle.com>
>>>>             <mailto:david.holmes at oracle.com
>>>>             <mailto:david.holmes at oracle.com>>
>>>>                      <mailto:david.holmes at oracle.com
>>>>             <mailto:david.holmes at oracle.com>
>>>>                      <mailto:david.holmes at oracle.com
>>>>             <mailto:david.holmes at oracle.com>>>> wrote:
>>>>
>>>>                           On 23/11/2015 11:46 PM, Bertrand Delsart
>>>> wrote:
>>>>
>>>>                               On 23/11/2015 13:27, David Holmes wrote:
>>>>
>>>>                                   Hi Bertrand,
>>>>
>>>>                                   On 23/11/2015 8:14 PM, Bertrand
>>>>             Delsart wrote:
>>>>
>>>>                                       Hi David,
>>>>
>>>>                                       Overall looks good.
>>>>                                       Thanks for the #ifndef
>>>>                      USE_LIBRARY_BASED_TLS_ONLY :-)
>>>>
>>>>                                       One doubt, in case this has not
>>>>             been discussed
>>>>                      before.
>>>>
>>>>                                       I'm still catching up on x86_64
>>>>             (after years of ARM
>>>>                                       assembly :-)) but it
>>>>                                       seems that there are some stack
>>>>             alignment
>>>>                      constraints on
>>>>                                       runtime calls,
>>>>                                       at least for some x86_64 ABIs.
>>>>
>>>>                                       Some of the x86
>>>>             MacroAssembler::get_thread
>>>>                                       implementations had code to
>>>>                                       align the stack before calling
>>>>                      pthread_getspecific. See
>>>>                                       for instance
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>>                                   Sorry I'm not that familiar with the
>>>>             MacroAssembler
>>>>                      - is it
>>>>                                   this odd
>>>>                                   fragment:
>>>>
>>>>                                   -   push(r10);
>>>>                                   -   // XXX
>>>>                                   -   mov(r10, rsp);
>>>>                                   -   andq(rsp, -16);
>>>>                                   -   push(r10);
>>>>
>>>>                                   I'm not at all clear what that is
>>>>             doing - and if it
>>>>                      somehow
>>>>                                   changes the
>>>>                                   alignment wouldn't something need to
>>>>             be fixed up when
>>>>                                   popping the
>>>>                                   previous values ??
>>>>
>>>>                                   To be honest I'm not even sure what an
>>>>             "unaligned
>>>>                      stack" means.
>>>>
>>>>
>>>>                               On some platforms, SP may have to be
>>>>             aligned on a 16 bytes
>>>>                               boundary when
>>>>                               calling another method.
>>>>
>>>>
>>>>                           Okay - that seems to be an x64 ABI requirement
>>>>             based on
>>>>                      other code
>>>>                           in MacroAssembler. The reason it is missing in
>>>>             the Solaris
>>>>                      code is
>>>>                           because I already removed it in the earlier
>>>>             changes that
>>>>                      were done
>>>>                           on Solaris:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>>>
>>>>                           and nobody picked it up. :(
>>>>
>>>>                           That said, the absence of this code has not
>>>>             caused any
>>>>                      problems so
>>>>                           presumably we are normally aligned.
>>>>
>>>>                               After having pushed what needed to be
>>>>             saved, the code above
>>>>                               rounds SP
>>>>                               down and saves the old value. It will then
>>>>             also push
>>>>                      r11, which
>>>>                               results
>>>>                               in the expected alignment.
>>>>
>>>>                               The conterpart, after the VM call, is the:
>>>>                                  pop(r11);
>>>>                                  pop(rsp);
>>>>
>>>>
>>>>                           I had assumed this extra manipulation was
>>>>             related to
>>>>                      pushing the arg
>>>>                           for the call.
>>>>
>>>>                                       This alignment is no longer
>>>>             performed in the new
>>>>                                       (shared) implementation
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                                       Now, Solaris was not performing
>>>>             the alignment and
>>>>                                       Windows has a separate
>>>>                                       path for x86_64. Did we really
>>>>             need the
>>>>                      alignment for
>>>>                                       linux x86_64 and
>>>>                                       bsd_x86_64 ? Might it be needed
>>>>             for other ports ?
>>>>
>>>>                                       IMHO, it might be safer to align
>>>>             the stack by
>>>>                      default,
>>>>                                       knowing it should
>>>>                                       not be expensive since we call
>>>>             get_thread
>>>>                      rarely for
>>>>                                       x86_64 (result is
>>>>                                       cached in r15). I'll let you see
>>>>             whether it is
>>>>                      worth
>>>>                                       adding an ifdef so
>>>>                                       as to explicitly deactivate the
>>>>             alignment on
>>>>                      some platforms
>>>>                                       (solaris_x86_64 ?)
>>>>
>>>>
>>>>                                   I don't have enough knowledge to even
>>>>             begin to
>>>>                      comment on
>>>>                                   this. I will
>>>>                                   have to rely on our x86_64
>>>>             macroassembler experts
>>>>                      to explain
>>>>                                   the old
>>>>                                   code and what the requirements are.
>>>>
>>>>
>>>>                               OK. This means that the alignment was not
>>>>             removed
>>>>                      purposefully.
>>>>
>>>>                               In that case, you must either keep the per
>>>>             platform
>>>>                      code x86_64
>>>>                               (since
>>>>                               it was not identical for all platforms) or
>>>>             use the safest
>>>>                               version, with
>>>>                               the additional
>>>>
>>>>                                    // XXX
>>>>                                    mov(r10, rsp);
>>>>                                    andq(rsp, -16);
>>>>                                    push(r10);
>>>>
>>>>                               before the push(r11) and with the
>>>>
>>>>                                    pop(rsp);
>>>>
>>>>                               after the pop(r11). It should work on all
>>>>             x86_64 platforms.
>>>>
>>>>
>>>>                           Right, I will add this back to the code - and
>>>>             replace the
>>>>                           meaningless // XXX with an actual comment!
>>>>
>>>>                           Many thanks,
>>>>                           David
>>>>                           -----
>>>>
>>>>
>>>>                               FYI, there is another way to do the
>>>>             alignment, based on
>>>>                      the fact
>>>>                               that
>>>>                               we are at least aligned on 8 bytes (see
>>>> MacroAssembler::call_VM_leaf_base). I
>>>>             assume that this
>>>>                      second
>>>>                               version is
>>>>                               more efficient (particularly thanks to
>>>>             specilative
>>>>                      branches) but it
>>>>                               might be safer/simpler to continue using
>>>>             andq in
>>>>                      get_thread.
>>>>
>>>>                               Bertrand.
>>>>
>>>>
>>>>                                   Thanks,
>>>>                                   David
>>>>
>>>>                                       Regards,
>>>>
>>>>                                       Bertrand.
>>>>
>>>>
>>>>
>>>>                                       On 23/11/2015 08:03, David Holmes
>>>>             wrote:
>>>>
>>>>                                           After all the preliminary
>>>>             discussions here
>>>>                      are final
>>>>                                           proposed changes:
>>>>
>>>>                                           bug:
>>>>             https://bugs.openjdk.java.net/browse/JDK-8132510
>>>>
>>>>                                           Open webrev:
>>>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>>>
>>>>                                           A simple (in principle) but
>>>>             wide-ranging change
>>>>                                           which should appeal to
>>>>                                           our Code Deletion Engineer's.
>>>>             We implement
>>>>                                           Thread::current() using a
>>>> compiler/language-based
>>>>             thread-local
>>>>                      variable eg:
>>>>
>>>>                                              static __thread Thread
>>>>             *_thr_current;
>>>>
>>>>                                              inline Thread*
>>>>             Thread::current() {
>>>>                                                return _thr_current;
>>>>                                              }
>>>>
>>>>                                           with an appropriate setter of
>>>>             course. By
>>>>                      doing this
>>>>                                           we can completely
>>>>                                           remove the os_cpu-specific
>>>>             ThreadLocalStorage
>>>>                                           implementations, and the
>>>>                                           associated
>>>>             os::thread_local_storage* calls.
>>>>
>>>>                                           As __thread is not
>>>>             async-signal-safe (either in
>>>>                                           theory or practice) we
>>>>                                           need a fallback library-based
>>>>             solution as used
>>>>                                           today. For this we use a
>>>>                                           very simple ThreadLocalStorage
>>>>             class and an
>>>>                                           implementation thereof for
>>>>                                           POSIX (covers AIX, BSD, Linux,
>>>>             OSX and
>>>>                      Solaris) using
>>>> pthread_get/setspecific; and
>>>>             one for
>>>>                      Windows using
>>>>                                           its TLS library.
>>>>                                           While these library routines
>>>>             are not guaranteed
>>>>                                           async-signal-safe, they
>>>>                                           seem to be in practice and are
>>>>             what we have
>>>>                      been
>>>>                                           using all along.
>>>>
>>>>                                           We also allow for use of
>>>> only the
>>>>                      library-based TLS
>>>>                                           for platforms where
>>>>                                           compiler-based thread locals
>>>>             are not
>>>>                      supported (as
>>>>                                           will be needed in
>>>>                                           the
>>>>                                           Mobile project). This is
>>>>             enabled at build
>>>>                      time by
>>>>                                           defining
>>>> USE_LIBRARY_BASED_TLS_ONLY.
>>>>
>>>>                                           Thanks to Andrew Haley for
>>>>             providing the
>>>>                      Aarch64
>>>>                                           code; and for Thomas
>>>>                                           Stuefe for testing PPC and
>>>> AIX.
>>>>
>>>>                                           Testing:
>>>>                                              - JPRT (core platforms)
>>>>                                              - Jtreg tests (linux &
>>>> solaris)
>>>>                                              - vm.runtime (core
>>>> platforms)
>>>>
>>>>                                           Performance:
>>>>                                              - still TBD - this is
>>>>             proving to be
>>>>                      extremely
>>>>                                           difficult. If anyone
>>>>                                           has
>>>>                                           any simple to run
>>>>             microbenchmarks to
>>>>                      suggest I'd
>>>>                                           give them a try as a
>>>>                                           sanity check. But I lack
>>>>             access to hardware for
>>>>                                           running serious
>>>>                                           benchmarking.
>>>>
>>>>                                           Footprint:
>>>>                                           - varies by platform and the
>>>>             VM (server,
>>>>                      client,
>>>>                                           minimal)
>>>>                                           - worst-case: ~1% increase for
>>>>             server VM
>>>>                      and minimal VM
>>>>                                           - best-case:  0.4% decrease
>>>>             for client VM
>>>>
>>>>                                           Thanks,
>>>>                                           David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                  --
>>>>                  Bertrand Delsart,                     Grenoble
>>>>             Engineering Center
>>>>                  Oracle,         180 av. de l'Europe, ZIRST de
>>>>             Montbonnot
>>>>                  38330 Montbonnot Saint Martin, FRANCE
>>>>             bertrand.delsart at oracle.com
>>>>             <mailto:bertrand.delsart at oracle.com>
>>>>             <mailto:bertrand.delsart at oracle.com
>>>>             <mailto:bertrand.delsart at oracle.com>>
>>>>                            Phone : +33 4 76 18 81 23
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>                  NOTICE: This email message is for the sole use of the
>>>>             intended
>>>>                  recipient(s) and may contain confidential and
>>>> privileged
>>>>                  information. Any unauthorized review, use,
>>>> disclosure or
>>>>                  distribution is prohibited. If you are not the intended
>>>>             recipient,
>>>>                  please contact the sender by reply email and destroy
>>>>             all copies of
>>>>                  the original message.
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>>
>>>>
>>>>
>>>>
>>

From dmitry.dmitriev at oracle.com  Thu Nov 26 10:18:53 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 26 Nov 2015 13:18:53 +0300
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <56563D89.5090902@oracle.com>
References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com>
	<56547635.9060808@oracle.com> <56563D89.5090902@oracle.com>
Message-ID: <5656DC8D.4090802@oracle.com>

Hi Sangheon,

Updated version also looks good to me!

Thanks,
Dmitry

On 26.11.2015 2:00, sangheon.kim wrote:
> Hi all,
>
> Here's updated webrev which reflects changes by "JDK-8143038: 
> [TESTBUG] TestOptionsWithRanges: allow excluding only a subset of 
> tested values specified for a flag".
>
> The only updated file is 
> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java.
> Changed from "allOptionsAsMap.remove("flag name")" to 
> "excludeTestMaxRange("flag name")".
>
> FYI,  JDK-8143038 introduced separated exclude methods of 
> "excludeTest, excludeTestMaxRange and excludeTestMinRange".
>
> webrev:
> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01/
> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01_to_00/
>
> Thanks,
> Sangheon
>
>
> On 11/24/2015 06:37 AM, sangheon.kim wrote:
>> Hi Dmitry,
>>
>> Thank you for the review!
>> Sure I will update my patch related to your enhancement.
>>
>> Thanks,
>> Sangheon
>>
>>
>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
>>> Hi Sangheon,
>>>
>>> Looks good to me! Thank you for fixing that. I hope that enhancement 
>>> will be pushed today(currently in JPRT queue), so please update your 
>>> patch after that!
>>>
>>> Thanks,
>>> Dmitry
>>>
>>> On 21.11.2015 0:04, sangheon.kim wrote:
>>>> Hi all,
>>>>
>>>> Could I have a couple of reviews for this change to add explicit 
>>>> 'range' for flags?
>>>>
>>>> Previously, we added 'range' when it is needed to avoid 
>>>> assert/crash but now explicit 'range' are needed for all flags.
>>>> All flags should have 'range' or 'constraint' at least.
>>>>
>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>>>> Testing: JPRT, RBT 
>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist 
>>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for 
>>>> embedded
>>>>
>>>> * Summary
>>>> 1. Added 3 new constraint functions.
>>>>    1) HeapBaseMinAddress: Added to avoid an overflow after align up 
>>>> and this flag makes hang up without constraint function. (newly 
>>>> added as a part of GC work)
>>>>    2) TLABWasteIncrement: Without this constraint function we don't 
>>>> have problems (even many GCs happen). But added to avoid an 
>>>> overflow at ThreadLocalAllocBuffer::record_slow_allocation(). There 
>>>> are also separate CR for this overflow ( JDK-8143352 ).
>>>>    3) NUMAInterleaveGranularity: Added to avoid an overflow after 
>>>> align up.
>>>>
>>>> 2. Some flags have narrower range than their type.
>>>>    1) Here's the reason why some flags should have different range. 
>>>> (same order from globals.hpp)
>>>> {flag type} {flag name}: (range), {comment}
>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), 
>>>> max_uintx), there is a comment at numa_interleaving_init() that 
>>>> this flag should be larger than vm_allocation_granularity().
>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero 
>>>> as used for multiplication
>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which 
>>>> has 'unsigned int' type input parameter.
>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function 
>>>> which has 'unsigned int' type input parameter.
>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function 
>>>> which has 'long' type input parameter.
>>>> uintx PausePadding: (0, max_juint), used to set a function which 
>>>> has 'unsigned int' type input parameter.
>>>> uintx PromotedPadding: (0, max_juint), used to set a function which 
>>>> has 'unsigned int' type input parameter.
>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which 
>>>> has 'unsigned int' type input parameter.
>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this 
>>>> flag is divided by 100 I assume this is percentage.
>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has 
>>>> 'unsigned int' type input parameter.
>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>>>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>>>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 
>>>> Prefetch* flags should have same upper limit and looking at their 
>>>> related codes 'max_jint' seems appropriate ( no problem with 
>>>> 'max_jint' during testing). However, as Prefetch::read/write() 
>>>> needs 'intx', 'intx' also seems good but we have to fix some codes 
>>>> (maybe including generated codes).
>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which 
>>>> has 'unsigned int' type input parameter.
>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint 
>>>> variable and used 'for loop' which has uint increment. i.e. for 
>>>> (uint i=0; i<ProcessDistributionStride; i++)
>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 
>>>> 'increment for loop()' as max value and the increment is uint.
>>>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for 
>>>> loop()' as max value and the increment is uint.
>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return 
>>>> value of uint type function and for division. i.e. uint 
>>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return 
>>>> TLABRefillWasteFraction; }
>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we 
>>>> only use " if (a !=0, >0, >1)".
>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we 
>>>> only use " if (a !=0, >0, >1)".
>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only 
>>>> use " if (a !=0, >0)".
>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 
>>>> 'unsigned int'
>>>>
>>>> (g1_globals.hpp)
>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set 
>>>> (int) type variable.
>>>>
>>>> 3. Excluded flags from TestOptionsWithRanges.java
>>>> 1) Memory and thread related flags: tests for these flags will 
>>>> consume too many resources from the system.
>>>> 2) VMThreadStackSize: range work for this flag is not included in 
>>>> this patch but I faced OOME several times, so excluded.
>>>>
>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] 
>>>> TestOptionsWithRanges: allow excluding only a subset of tested 
>>>> values specified for a flag) next time.
>>>>
>>>> Thanks,
>>>> Sangheon
>>>>
>>>>
>>>>
>>>
>>
>


From aph at redhat.com  Thu Nov 26 10:45:26 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 26 Nov 2015 10:45:26 +0000
Subject: RFR: 8143219: AArch64 broken by 8141132: JEP 254: Compact Strings
In-Reply-To: <564E0775.6030008@oracle.com>
References: <564DB8FF.2080103@redhat.com> <564DE5EC.8040901@oracle.com>
	<564DE722.3050804@redhat.com> <564DFD47.6010807@oracle.com>
	<564E0425.4010302@redhat.com> <564E06F1.2080900@oracle.com>
	<564E0775.6030008@oracle.com>
Message-ID: <5656E2C6.1090409@redhat.com>

Here is a reduced webrev, suitable for just the machine-dependent
parts of the fix:

http://cr.openjdk.java.net/~aph/8143219-2/hotspot.changeset

All it does is adjust the lengths for string_compare and string_equals.

Andrew.

From manasthakur17 at gmail.com  Thu Nov 26 12:22:36 2015
From: manasthakur17 at gmail.com (Manas Thakur)
Date: Thu, 26 Nov 2015 17:52:36 +0530
Subject: Accessing parameters from a methodHandle
Message-ID: <10807D32-55BA-4462-A5A4-52D6B621C025@gmail.com>

Hello all,

I would like to know how to access the parameter nodes (in sequence) from a methodHandle. I could find that in ?opto/parse1.cpp?, ?ParmNodes? are constructed by determining the ?arg_size?. However, this variable doesn?t match the actual number of parameters passed to the corresponding Java method. Any suggestions?

Regards,
Manas

From manasthakur17 at gmail.com  Thu Nov 26 12:51:59 2015
From: manasthakur17 at gmail.com (Manas Thakur)
Date: Thu, 26 Nov 2015 18:21:59 +0530
Subject: Accessing parameters from a methodHandle
In-Reply-To: <5656FBF2.7070309@oracle.com>
References: <10807D32-55BA-4462-A5A4-52D6B621C025@gmail.com>
	<5656FBF2.7070309@oracle.com>
Message-ID: <579A5278-C594-46B1-BAC0-604F30E42149@gmail.com>

Yes, essentially I was trying to iterate over the parameters of a method in C2. I thought it would be accessible via Method* itself; however, your answer solves the problem. Thanks!

Regards,
Manas

> On 26-Nov-2015, at 6:02 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Manas,
> 
> Can you elaborate what problem are you trying to solve?
> 
> It sounds like you want to iterate over all parameters of a compiled method in C2.
> 
> methodHandle is a Handle for Method* which an internal representation of a Java method. It doesn't provide any way to extract actual argument representation during compilation.
> 
> During parsing you can use GraphKit::method(), ciMethod::arg_size(), and GraphKit::argument(int i) to operate on arguments of a method being parsed. See opto/library_call.cpp for examples.
> 
> Best regards,
> Vladimir Ivanov
> 
> (BCC: hotspot-dev at openjdk.java.net)
> 
> On 11/26/15 3:22 PM, Manas Thakur wrote:
>> Hello all,
>> 
>> I would like to know how to access the parameter nodes (in sequence) from a methodHandle. I could find that in ?opto/parse1.cpp?, ?ParmNodes? are constructed by determining the ?arg_size?. However, this variable doesn?t match the actual number of parameters passed to the corresponding Java method. Any suggestions?
>> 
>> Regards,
>> Manas
>> 


From sangheon.kim at oracle.com  Thu Nov 26 15:42:36 2015
From: sangheon.kim at oracle.com (sangheon.kim at oracle.com)
Date: Thu, 26 Nov 2015 07:42:36 -0800
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <5656DC8D.4090802@oracle.com>
References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com>
	<56547635.9060808@oracle.com> <56563D89.5090902@oracle.com>
	<5656DC8D.4090802@oracle.com>
Message-ID: <CE6FCED3-F21E-49A0-84EE-8D72544C0A1A@oracle.com>

Hi Dmitry,  

thank you again for looking at this!

Thanks,
Sangheon


> On Nov 26, 2015, at 2:18 AM, Dmitry Dmitriev <dmitry.dmitriev at oracle.com> wrote:
> 
> Hi Sangheon,
> 
> Updated version also looks good to me!
> 
> Thanks,
> Dmitry
> 
>> On 26.11.2015 2:00, sangheon.kim wrote:
>> Hi all,
>> 
>> Here's updated webrev which reflects changes by "JDK-8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a subset of tested values specified for a flag".
>> 
>> The only updated file is test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java.
>> Changed from "allOptionsAsMap.remove("flag name")" to "excludeTestMaxRange("flag name")".
>> 
>> FYI,  JDK-8143038 introduced separated exclude methods of "excludeTest, excludeTestMaxRange and excludeTestMinRange".
>> 
>> webrev:
>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01/
>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01_to_00/
>> 
>> Thanks,
>> Sangheon
>> 
>> 
>>> On 11/24/2015 06:37 AM, sangheon.kim wrote:
>>> Hi Dmitry,
>>> 
>>> Thank you for the review!
>>> Sure I will update my patch related to your enhancement.
>>> 
>>> Thanks,
>>> Sangheon
>>> 
>>> 
>>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
>>>> Hi Sangheon,
>>>> 
>>>> Looks good to me! Thank you for fixing that. I hope that enhancement will be pushed today(currently in JPRT queue), so please update your patch after that!
>>>> 
>>>> Thanks,
>>>> Dmitry
>>>> 
>>>>> On 21.11.2015 0:04, sangheon.kim wrote:
>>>>> Hi all,
>>>>> 
>>>>> Could I have a couple of reviews for this change to add explicit 'range' for flags?
>>>>> 
>>>>> Previously, we added 'range' when it is needed to avoid assert/crash but now explicit 'range' are needed for all flags.
>>>>> All flags should have 'range' or 'constraint' at least.
>>>>> 
>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>>>>> Testing: JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for embedded
>>>>> 
>>>>> * Summary
>>>>> 1. Added 3 new constraint functions.
>>>>>   1) HeapBaseMinAddress: Added to avoid an overflow after align up and this flag makes hang up without constraint function. (newly added as a part of GC work)
>>>>>   2) TLABWasteIncrement: Without this constraint function we don't have problems (even many GCs happen). But added to avoid an overflow at ThreadLocalAllocBuffer::record_slow_allocation(). There are also separate CR for this overflow ( JDK-8143352 ).
>>>>>   3) NUMAInterleaveGranularity: Added to avoid an overflow after align up.
>>>>> 
>>>>> 2. Some flags have narrower range than their type.
>>>>>   1) Here's the reason why some flags should have different range. (same order from globals.hpp)
>>>>> {flag type} {flag name}: (range), {comment}
>>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), max_uintx), there is a comment at numa_interleaving_init() that this flag should be larger than vm_allocation_granularity().
>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as used for multiplication
>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function which has 'long' type input parameter.
>>>>> uintx PausePadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> uintx PromotedPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag is divided by 100 I assume this is percentage.
>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>>>>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>>>>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch* flags should have same upper limit and looking at their related codes 'max_jint' seems appropriate ( no problem with 'max_jint' during testing). However, as Prefetch::read/write() needs 'intx', 'intx' also seems good but we have to fix some codes (maybe including generated codes).
>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint variable and used 'for loop' which has uint increment. i.e. for (uint i=0; i<ProcessDistributionStride; i++)
>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 'increment for loop()' as max value and the increment is uint.
>>>>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for loop()' as max value and the increment is uint.
>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value of uint type function and for division. i.e. uint GCTLABConfiguration::tlab_refill_waste_limit()() { return TLABRefillWasteFraction; }
>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only use " if (a !=0, >0, >1)".
>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only use " if (a !=0, >0, >1)".
>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use " if (a !=0, >0)".
>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned int'
>>>>> 
>>>>> (g1_globals.hpp)
>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) type variable.
>>>>> 
>>>>> 3. Excluded flags from TestOptionsWithRanges.java
>>>>> 1) Memory and thread related flags: tests for these flags will consume too many resources from the system.
>>>>> 2) VMThreadStackSize: range work for this flag is not included in this patch but I faced OOME several times, so excluded.
>>>>> 
>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a subset of tested values specified for a flag) next time.
>>>>> 
>>>>> Thanks,
>>>>> Sangheon
> 

From frederic.parain at oracle.com  Thu Nov 26 16:11:58 2015
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 26 Nov 2015 17:11:58 +0100
Subject: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical
	Sections
In-Reply-To: <744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com>
References: <563B64EF.1000500@oracle.com> <563C557E.3060505@oracle.com>
	<563FDB3C.5070702@cs.oswego.edu> <5640477B.3010302@oracle.com>
	<56422B85.9080000@oracle.com> <5643E6AC.2050702@cs.oswego.edu>
	<BE21FC37-7FD4-4F22-91A6-855A29A5D71A@oracle.com>
	<56525823.6010506@cs.oswego.edu>
	<C088E429-EE27-4848-AAAD-C5515A980122@oracle.com>
	<744B91D7-A174-4D2C-9F8F-AD9CC6D06189@gmail.com>
Message-ID: <56572F4E.8050603@oracle.com>

Considering stack overflow as fatal errors makes sense for
JVM running single applications. This could be the subject
of a RFE, the feature is well defined and the implementation
should not be too complex.

However, JEP-270 has been designed with multi-tenant applications
in mind. In this context, we'd like to avoid having to crash the
VM and restart the application and all tenants because one
tenant had a misbehaving thread. The reserved stack area is used
to protect the critical locks of the host application, in order
to give it a chance to cleanly kill the problematic tenant without
impacting the others.

Regards,

Fred

On 24/11/2015 19:16, Steven Schlansker wrote:
>
> On Nov 24, 2015, at 8:46 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>
>> Doug,
>>
>> I have been thinking about this more from the perspective of the original problem
>> we set out to solve
>
> I apologize if this has already been considered -- but for a lot well designed systems,
> occasional application failure is an expected fact of life and we design our HA around
> this with automatic restarts and monitoring.
>
> If it is so hard to detect / resolve a stack overflow situation, maybe one useful
> mitigation of such awful situations (juc hangs, corrupt state, lost locks) would be to
> actually treat a stack overflow as a fatal condition, much like OutOfMemoryError.
>
> In fact, we configure all of our production servers with the moral equivalent of
> -XX:OnOutOfMemoryError="kill -9 %p"
> because once we are in a possibly inconsistent state, we would much rather nuke
> it from orbit and start over.
>
> Maybe introducing some new options, like
> -XX:OnStackOverflowError=
> or
> -XX:TreatStackOverflowAsOOM (piggyback on the existing tunable above)
> would allow end users to avoid the really bad behavior in a controllable way?
>
>
>> , which was identified in the concurrent hash map usage, at the
>> time in the class loading logic. While the class loading logic has changed, I think we
>> have enough experience with this particular example and have studied
>> the code constructs sufficiently that there is value in checking in the small set of
>> JDK changes that target that situation. I also think this gives a sample of
>> the kind of model in which this approach can be effective. In addition, having this small set of
>> changes provides the ability to test and ensure that the hotspot changes continue to
>> work.
>>
>> So I would like to recommend that we go ahead and check in the hotspot changes
>> and the initial minimal set of j.u.c. updates as a way to put the new mechanism
>> in place so that the people with more domain expertise in the java.util.concurrent
>> libraries can experiment with the mechanism and add incremental improvements.
>>
>> thanks,
>> Karen
>>
>>> On Nov 22, 2015, at 7:04 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>
>>> On 11/20/2015 12:40 PM, Karen Kinnear wrote:
>>>> Totally appreciate the suggestion that the java.util.concurrent modifications
>>>> be done by folks with more domain expertise.
>>>>
>>>> Would you have us incorporate the initial minimal set of j.u.c. updates or none
>>>> at all?
>>>
>>> Sorry that I'm still in foot-drag mode on this.
>>> Reading David and Fred's exchanges reinforce my thoughts
>>> that there is no defensible rule or approach to
>>> use @ReservedStackAccess so as to add as little time and
>>> space as possible to reduce the occurrence of stuck
>>> resources as much as possible during StackOverflowError.
>>>
>>> After googling "StackOverflowError java util concurrent" and seeing the
>>> range of situations that can be encountered, I don't even know
>>> which kinds of constructions to target.
>>> And I'm less sure whether using @ReservedStackAccess at all
>>> is better than doing nothing.
>>>
>>> Maybe there is some decent empirical strategy, but I can't
>>> tell until hotspot support of @ReservedStackAccess is in place.
>>> So my vote is still to keep the JDK changes out for now.
>>>
>>> -Doug
>>>
>>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com

From aph at redhat.com  Thu Nov 26 17:24:14 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 26 Nov 2015 17:24:14 +0000
Subject: Silence warnings with new GCC
Message-ID: <5657403E.6060906@redhat.com>

I've been getting a lot of warnings such as

warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]

which error out with -Werror.  Almost all of them are bogus.  They are
typically of the form

    unsigned size;

    if (i->get(26, 26)) { // float
      switch(i->get(31, 30)) {
      case 0b10:
        size = 2; break;
      case 0b01:
        size = 1; break;
      case 0b00:
        size = 0; break;
      default:
        ShouldNotReachHere();
      }
    } else {
      size = i->get(31, 31);
    }

The problem here is that GCC does not know that ShouldNotReachHere()
should be treated as an unreachable statement.

The patch here fixes it.  I'd rather do this than add pointless assignments
all over the place.  Thoughts?  Opinions?

Thanks,

Andrew.



diff --git a/src/share/vm/utilities/debug.hpp b/src/share/vm/utilities/debug.hpp
--- a/src/share/vm/utilities/debug.hpp
+++ b/src/share/vm/utilities/debug.hpp
@@ -172,16 +172,24 @@
   BREAKPOINT;                                                                     \
 } while (0)

+#ifdef __GNUC__
+#  define UNREACHABLE __builtin_unreachable()
+#else
+#  define UNREACHABLE do { } while (0)
+#endif
+
 #define ShouldNotReachHere()                                                      \
 do {                                                                              \
   report_should_not_reach_here(__FILE__, __LINE__);                               \
   BREAKPOINT;                                                                     \
+  UNREACHABLE;                                                                    \
 } while (0)

 #define Unimplemented()                                                           \
 do {                                                                              \
   report_unimplemented(__FILE__, __LINE__);                                       \
   BREAKPOINT;                                                                     \
+  UNREACHABLE;                                                                    \
 } while (0)

 #define Untested(msg)

From goetz.lindenmaier at sap.com  Thu Nov 26 19:37:05 2015
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 26 Nov 2015 19:37:05 +0000
Subject: Silence warnings with new GCC
In-Reply-To: <5657403E.6060906@redhat.com>
References: <5657403E.6060906@redhat.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC41ED2893@DEWDFEMB12A.global.corp.sap>

Hi Andrew,

I know about this problem ... I guess a change of mine causes these warnings.
While I found a row of good fixes, these with ShouldNotReachHere are annoying.

What you propose has been discussed in April: 8065585: Change ShouldNotReachHere() to never return.
I didn't follow the discussion all to the end, but it wasn't done for some reason.
Also, I think, one can overrule ShoudlNotReachHere() with -XX:SuppressError=...

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
Sent: Thursday, November 26, 2015 6:24 PM
To: build-dev <build-dev at openjdk.java.net>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: Silence warnings with new GCC

I've been getting a lot of warnings such as

warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]

which error out with -Werror.  Almost all of them are bogus.  They are
typically of the form

    unsigned size;

    if (i->get(26, 26)) { // float
      switch(i->get(31, 30)) {
      case 0b10:
        size = 2; break;
      case 0b01:
        size = 1; break;
      case 0b00:
        size = 0; break;
      default:
        ShouldNotReachHere();
      }
    } else {
      size = i->get(31, 31);
    }

The problem here is that GCC does not know that ShouldNotReachHere()
should be treated as an unreachable statement.

The patch here fixes it.  I'd rather do this than add pointless assignments
all over the place.  Thoughts?  Opinions?

Thanks,

Andrew.



diff --git a/src/share/vm/utilities/debug.hpp b/src/share/vm/utilities/debug.hpp
--- a/src/share/vm/utilities/debug.hpp
+++ b/src/share/vm/utilities/debug.hpp
@@ -172,16 +172,24 @@
   BREAKPOINT;                                                                     \
 } while (0)

+#ifdef __GNUC__
+#  define UNREACHABLE __builtin_unreachable()
+#else
+#  define UNREACHABLE do { } while (0)
+#endif
+
 #define ShouldNotReachHere()                                                      \
 do {                                                                              \
   report_should_not_reach_here(__FILE__, __LINE__);                               \
   BREAKPOINT;                                                                     \
+  UNREACHABLE;                                                                    \
 } while (0)

 #define Unimplemented()                                                           \
 do {                                                                              \
   report_unimplemented(__FILE__, __LINE__);                                       \
   BREAKPOINT;                                                                     \
+  UNREACHABLE;                                                                    \
 } while (0)

 #define Untested(msg)

From david.holmes at oracle.com  Thu Nov 26 21:21:21 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Nov 2015 07:21:21 +1000
Subject: Silence warnings with new GCC
In-Reply-To: <5657403E.6060906@redhat.com>
References: <5657403E.6060906@redhat.com>
Message-ID: <565777D1.3090704@oracle.com>

On 27/11/2015 3:24 AM, Andrew Haley wrote:
> I've been getting a lot of warnings such as
>
> warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> which error out with -Werror.  Almost all of them are bogus.  They are
> typically of the form
>
>      unsigned size;
>
>      if (i->get(26, 26)) { // float
>        switch(i->get(31, 30)) {
>        case 0b10:
>          size = 2; break;
>        case 0b01:
>          size = 1; break;
>        case 0b00:
>          size = 0; break;
>        default:
>          ShouldNotReachHere();
>        }
>      } else {
>        size = i->get(31, 31);
>      }
>
> The problem here is that GCC does not know that ShouldNotReachHere()
> should be treated as an unreachable statement.

Strictly speaking it is of course reachable, but if we do reach it we 
expect never to return. As per the thread Mario pointed to we ran into 
problems trying to mark this as not returning. But I wonder whether 
lying to the compiler about the reachability of it would be a 
workaround? Of course if the compiler used that information to elide the 
ShouldNotReachHere() then that is not acceptable.

David

> The patch here fixes it.  I'd rather do this than add pointless assignments
> all over the place.  Thoughts?  Opinions?
>
> Thanks,
>
> Andrew.
>
>
>
> diff --git a/src/share/vm/utilities/debug.hpp b/src/share/vm/utilities/debug.hpp
> --- a/src/share/vm/utilities/debug.hpp
> +++ b/src/share/vm/utilities/debug.hpp
> @@ -172,16 +172,24 @@
>     BREAKPOINT;                                                                     \
>   } while (0)
>
> +#ifdef __GNUC__
> +#  define UNREACHABLE __builtin_unreachable()
> +#else
> +#  define UNREACHABLE do { } while (0)
> +#endif
> +
>   #define ShouldNotReachHere()                                                      \
>   do {                                                                              \
>     report_should_not_reach_here(__FILE__, __LINE__);                               \
>     BREAKPOINT;                                                                     \
> +  UNREACHABLE;                                                                    \
>   } while (0)
>
>   #define Unimplemented()                                                           \
>   do {                                                                              \
>     report_unimplemented(__FILE__, __LINE__);                                       \
>     BREAKPOINT;                                                                     \
> +  UNREACHABLE;                                                                    \
>   } while (0)
>
>   #define Untested(msg)
>

From david.holmes at oracle.com  Fri Nov 27 07:26:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Nov 2015 17:26:25 +1000
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <CAA-vtUw=BNfxq_1fUGGs=QNHu2KQ+sGCpyrcPnDcRo0788gC4A@mail.gmail.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
	<CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
	<56563BA0.1010307@oracle.com> <56563F61.4030008@oracle.com>
	<5656497E.2050208@oracle.com>
	<CAA-vtUw=BNfxq_1fUGGs=QNHu2KQ+sGCpyrcPnDcRo0788gC4A@mail.gmail.com>
Message-ID: <565805A1.9080803@oracle.com>

Hi Thomas,

On 26/11/2015 7:56 PM, Thomas St?fe wrote:
>
> On Thu, Nov 26, 2015 at 12:51 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 26/11/2015 9:08 AM, Daniel D. Daugherty wrote:
>
>         If I understand the problem... :-)
>
>         The Win-X64 ABI requires that some extra space be allocated on
>         the stack in the caller for "homing" four registers...
>
>         This code uses MacroAssembler::call() which is a lower level
>         call() function that assumes you know the ABI...
>
>         9765 void MacroAssembler::get_thread(Register thread) {
>         <snip>
>         9784   call(RuntimeAddress(CAST_FROM_FN_PTR(address,
>         Thread::current)));
>
>     So the failing here was nothing to do with register saving per-se,
>     nor the alignment code, but "simply" not also saving the extra space
>     prior to the call!
>
> Yes. These 32 byte are a scratch area for the callee, which may be used
> for parameter registers or anything else. We may just have been lucky so
> far that TlsGetValue() did not use this area. As Bertrand already said,
> now we call Thread::current(), which does magic tls accesses under the
> hood, so this must be tested again.

Right. All testing so far has been successful but ...

> However I think that a simple addition to your current fix could simply
> be subtracting 32 from rsp before the call:
>
> subq(rsp, 32)
> call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current)));
> addq(rsp, 32)

... I decided to do what was previously suggested and use:

   call_VM_leaf_base(CAST_FROM_FN_PTR(address, Thread::current), 0);

as it takes care of everything (stack alignment if needed and preserving 
space for the register args on win64).

> Also, we could probably skip saving/restoring rdi and rsi on Windows:

Maybe - but we don't seem to consider that anywhere else ie:

void MacroAssembler::push_callee_saved_registers() {
   push(rsi);
   push(rdi);
   push(rdx);
   push(rcx);
}

so I don't want to be the trail-blazer here. :)

Updated webrev:

  http://cr.openjdk.java.net/~dholmes/8132510/webrev.v10

Only change to macroAssembler_x86.cpp. Re-tested on Windows 32-bit and 
64-bit.

Thanks,
David

> https://msdn.microsoft.com/en-us/library/6t169e9c.aspx
>
> "The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile
> and must be considered destroyed on function calls (unless otherwise
> safety-provable by analysis such as whole program optimization). The
> registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered
> nonvolatile and must be saved and restored by a function that uses them."



> Best Regards, Thomas
>
>
>         If you switch to MacroAssembler::call_VM_leaf_base() it handles
>         more of the gory details for you than MacroAssembler::call():
>
>
>     Wow! Not exactly a clearly-defined name for this. AFAICS there's
>     nothing VM or leaf specific about this. Also the MacroAssembler is
>     supposed to be a platform-agnostic higher-level abstraction that is
>     easy to use - but in this case every use of the plain call on
>     Windows-x64 is potentially broken if the programmer was not aware of
>     this ABI constraint which only applies to Windows (and we're in
>     OS-neutral files!).
>
>     This seems fundamentally broken to me.
>
>     Thanks for the info.
>
>     David
>
>
>         src/cpu/x86/vm/macroAssembler_x86.cpp:
>
>              524  void MacroAssembler::call_VM_leaf_base(address
>         entry_point, int
>         num_args
>         ) {
>              525    Label L, E;
>              526
>              527  #ifdef _WIN64
>              528    // Windows always allocates space for it's register args
>              529    assert(num_args <= 4, "only register arguments
>         supported");
>              530    subq(rsp,  frame::arg_reg_save_area_bytes);
>              531  #endif
>              532
>              533    // Align stack if necessary
>              534    testl(rsp, 15);
>              535    jcc(Assembler::zero, L);
>              536
>              537    subq(rsp, 8);
>              538    {
>              539      call(RuntimeAddress(entry_point));
>              540    }
>
>         So call_VM_leaf_base() allocates the "homing" space for register
>         args for Win-X64 on L530 and it handles any stack alignment before
>         calling MacroAssembler::call().
>
>         So if you switch to call_VM_leaf_base() you can drop
>         the stack alignment code:
>
>         9777   // ensure stack alignment
>         9778   mov(r10, rsp);
>         9779   andq(rsp, -16);
>         9780   push(r10);
>
>         and just switch to:
>
>         9777   push(rsp);
>
>         And you won't be exposed to potential saved register
>         overwrite by the "homing" of any registers in the call
>         Thread::current().
>
>         I _think_ I have that all correct... :-)
>
>         Dan
>
>
>         On 11/25/15 3:52 PM, David Holmes wrote:
>
>             On 26/11/2015 2:53 AM, Thomas St?fe wrote:
>
>                 I created a bug to track this:
>
>                 https://bugs.openjdk.java.net/browse/JDK-8144059
>
>
>             Thanks. I admit I still don't really grok the exact problem
>             here. It
>             is the alignment code that is the problem right?
>
>             79 mov(r10, rsp);
>             80 andq(rsp, -16);
>             81 push(r10);
>
>             ?
>
>             Thanks,
>             David
>
>                 Because Davids change is not submitted yet, the bug
>                 refers to the old
>                 coding, but stays relevant also after this fix.
>
>                 Kind Regards, Thomas
>
>                 On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty
>                 <daniel.daugherty at oracle.com
>                 <mailto:daniel.daugherty at oracle.com>
>                 <mailto:daniel.daugherty at oracle.com
>                 <mailto:daniel.daugherty at oracle.com>>>
>                 wrote:
>
>                      On 11/25/15 6:10 AM, David Holmes wrote:
>
>                          On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>
>
>                              On Wed, Nov 25, 2015 at 10:22 AM, Bertrand
>                 Delsart
>                              <bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>
>                              <mailto:bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>>
>                              <mailto:bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>
>                              <mailto:bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>>>> wrote:
>
>                                   Good finding Thomas,
>
>                                   On 25/11/2015 09:40, Thomas St?fe wrote:
>
>                                       Hi David, Bertrand,
>
>                                       about
>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>
>
>                                       I am not sure this is correct for
>                 Windows x64.
>
>
>                                   Unless I'm misreading it, the new code
>                 looks a lot like
>                              the old one
>                                   (including the alignement part). Hence
>                 this does not
>                              look like a
>                                   regression caused by David's change.
>
>
>                              Yes, this seems like an old bug.
>
>                              I also see that this is fixed in our
>                 codebase since 2010,
>                              exactly the
>                              way you propose (with MacroAssembler
>                 <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
>
>
>                 <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
>
>
>                              So, it is already used since five years. I
>                 would propose
>                              opening a
>                              separate bug for this one and we contribute
>                 our fix.
>
>
>                          That sounds good to me too. I also suspect
>                 additional code will
>                          need to be checked as this stack alignment is
>                 performed in a few
>                          places in ./cpu/x86/vm/macroAssembler_x86.cpp
>                 with no OS
>                          specific differences being considered.
>
>
>                      Looks like MacroAssembler::call_VM_leaf_base() does
>                 the "right
>                 thing"
>                      for stack alignment in the X64 case. Perhaps we
>                 need to audit both
>                      stack alignment _and_ uses of
>                 MacroAssembler::call() just to make
>                      sure...
>
>                      Did I mention that all the assembly code stuff
>                 gives me a
>                 headache? :-)
>
>                      Dan
>
>
>
>
>                          Thanks,
>                          David
>
>                              Regards, Thomas
>
>
>                 https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>
>                                       windows x64 Abi requires the
>                 register parameter
>                              area right above the
>                                       return address on the stack. It is not
>                 guaranteed to be
>                                       preserved during
>                                       the function call:
>
>                                       "Even if the called function has
>                 fewer than 4
>                              parameters, these
>                                       4 stack
>                                       locations are effectively owned by
>                 the called
>                              function, and may
>                                       be used
>                                       by the called function for other
>                 purposes besides
>                              saving parameter
>                                       register values. Thus the caller
>                 may not save
>                              information in
>                                       this region
>                                       of stack across a function call."
>
>                                       So, restoring parameters from it
>                 may not work if
>                                       Thread::current() uses
>                                       this area for any reason. In this
>                 case, r9, rsp,
>                              r10, r11 may be
>                                       overwritten by the callee.
>
>                                       I also think Windows x64 ABI is
>                 different enough
>                              from Linux that
>                                       this
>                                       function could live somewhere in
>                 <os>_<cpu>.
>
>
>                                   This is a valid point. However, note
>                 that this is
>                              similar to the
>                                   issue we have for instance in 'shared'
>                                   MacroAssembler::call_VM_leaf_base,
>                 which was not put in
>                              <os>_<cpu>
>                                   files.
>
>                                   In fact, the right fix may be to use
>                 call_VM_leaf
>                              instead of call :-)
>
>                                   (alternatively we could use "#ifdef
>                 _WIN64" or check
>                                   "frame::arg_reg_save_area_bytes != 0",
>                 which may be
>                              even cleaner and
>                                   more portable)
>
>                                   All these solutions are fine for me.
>
>
>                                   Since we are near to feature freeze,
>                 this should
>                              probably be done in
>                                   a separate CR (unless David has enough
>                 time to test
>                 it).
>
>                                   Regards,
>
>                                   Bertrand.
>
>
>                                       Kind Regards, Thomas
>
>
>
>
>                                       On Mon, Nov 23, 2015 at 10:42 PM,
>                 David Holmes
>                                       <david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>
>                              <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>>
>                              <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>
>                              <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>>>
>                                       <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>
>                              <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>>
>                                       <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>
>                              <mailto:david.holmes at oracle.com
>                 <mailto:david.holmes at oracle.com>>>>> wrote:
>
>                                            On 23/11/2015 11:46 PM,
>                 Bertrand Delsart
>                 wrote:
>
>                                                On 23/11/2015 13:27,
>                 David Holmes wrote:
>
>                                                    Hi Bertrand,
>
>                                                    On 23/11/2015 8:14
>                 PM, Bertrand
>                              Delsart wrote:
>
>                                                        Hi David,
>
>                                                        Overall looks good.
>                                                        Thanks for the
>                 #ifndef
>                                       USE_LIBRARY_BASED_TLS_ONLY :-)
>
>                                                        One doubt, in
>                 case this has not
>                              been discussed
>                                       before.
>
>                                                        I'm still
>                 catching up on x86_64
>                              (after years of ARM
>                                                        assembly :-)) but it
>                                                        seems that there
>                 are some stack
>                              alignment
>                                       constraints on
>                                                        runtime calls,
>                                                        at least for some
>                 x86_64 ABIs.
>
>                                                        Some of the x86
>                              MacroAssembler::get_thread
>                                                        implementations
>                 had code to
>                                                        align the stack
>                 before calling
>                                       pthread_getspecific. See
>                                                        for instance
>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>
>
>
>
>                                                    Sorry I'm not that
>                 familiar with the
>                              MacroAssembler
>                                       - is it
>                                                    this odd
>                                                    fragment:
>
>                                                    -   push(r10);
>                                                    -   // XXX
>                                                    -   mov(r10, rsp);
>                                                    -   andq(rsp, -16);
>                                                    -   push(r10);
>
>                                                    I'm not at all clear
>                 what that is
>                              doing - and if it
>                                       somehow
>                                                    changes the
>                                                    alignment wouldn't
>                 something need to
>                              be fixed up when
>                                                    popping the
>                                                    previous values ??
>
>                                                    To be honest I'm not
>                 even sure what an
>                              "unaligned
>                                       stack" means.
>
>
>                                                On some platforms, SP may
>                 have to be
>                              aligned on a 16 bytes
>                                                boundary when
>                                                calling another method.
>
>
>                                            Okay - that seems to be an
>                 x64 ABI requirement
>                              based on
>                                       other code
>                                            in MacroAssembler. The reason
>                 it is missing in
>                              the Solaris
>                                       code is
>                                            because I already removed it
>                 in the earlier
>                              changes that
>                                       were done
>                                            on Solaris:
>
>                 http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>
>                                            and nobody picked it up. :(
>
>                                            That said, the absence of
>                 this code has not
>                              caused any
>                                       problems so
>                                            presumably we are normally
>                 aligned.
>
>                                                After having pushed what
>                 needed to be
>                              saved, the code above
>                                                rounds SP
>                                                down and saves the old
>                 value. It will then
>                              also push
>                                       r11, which
>                                                results
>                                                in the expected alignment.
>
>                                                The conterpart, after the
>                 VM call, is the:
>                                                   pop(r11);
>                                                   pop(rsp);
>
>
>                                            I had assumed this extra
>                 manipulation was
>                              related to
>                                       pushing the arg
>                                            for the call.
>
>                                                        This alignment is
>                 no longer
>                              performed in the new
>                                                        (shared)
>                 implementation
>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>
>
>
>
>
>                                                        Now, Solaris was
>                 not performing
>                              the alignment and
>                                                        Windows has a
>                 separate
>                                                        path for x86_64.
>                 Did we really
>                              need the
>                                       alignment for
>                                                        linux x86_64 and
>                                                        bsd_x86_64 ?
>                 Might it be needed
>                              for other ports ?
>
>                                                        IMHO, it might be
>                 safer to align
>                              the stack by
>                                       default,
>                                                        knowing it should
>                                                        not be expensive
>                 since we call
>                              get_thread
>                                       rarely for
>                                                        x86_64 (result is
>                                                        cached in r15).
>                 I'll let you see
>                              whether it is
>                                       worth
>                                                        adding an ifdef so
>                                                        as to explicitly
>                 deactivate the
>                              alignment on
>                                       some platforms
>                                                        (solaris_x86_64 ?)
>
>
>                                                    I don't have enough
>                 knowledge to even
>                              begin to
>                                       comment on
>                                                    this. I will
>                                                    have to rely on our
>                 x86_64
>                              macroassembler experts
>                                       to explain
>                                                    the old
>                                                    code and what the
>                 requirements are.
>
>
>                                                OK. This means that the
>                 alignment was not
>                              removed
>                                       purposefully.
>
>                                                In that case, you must
>                 either keep the per
>                              platform
>                                       code x86_64
>                                                (since
>                                                it was not identical for
>                 all platforms) or
>                              use the safest
>                                                version, with
>                                                the additional
>
>                                                     // XXX
>                                                     mov(r10, rsp);
>                                                     andq(rsp, -16);
>                                                     push(r10);
>
>                                                before the push(r11) and
>                 with the
>
>                                                     pop(rsp);
>
>                                                after the pop(r11). It
>                 should work on all
>                              x86_64 platforms.
>
>
>                                            Right, I will add this back
>                 to the code - and
>                              replace the
>                                            meaningless // XXX with an
>                 actual comment!
>
>                                            Many thanks,
>                                            David
>                                            -----
>
>
>                                                FYI, there is another way
>                 to do the
>                              alignment, based on
>                                       the fact
>                                                that
>                                                we are at least aligned
>                 on 8 bytes (see
>                 MacroAssembler::call_VM_leaf_base). I
>                              assume that this
>                                       second
>                                                version is
>                                                more efficient
>                 (particularly thanks to
>                              specilative
>                                       branches) but it
>                                                might be safer/simpler to
>                 continue using
>                              andq in
>                                       get_thread.
>
>                                                Bertrand.
>
>
>                                                    Thanks,
>                                                    David
>
>                                                        Regards,
>
>                                                        Bertrand.
>
>
>
>                                                        On 23/11/2015
>                 08:03, David Holmes
>                              wrote:
>
>                                                            After all the
>                 preliminary
>                              discussions here
>                                       are final
>                                                            proposed changes:
>
>                                                            bug:
>                 https://bugs.openjdk.java.net/browse/JDK-8132510
>
>                                                            Open webrev:
>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>
>                                                            A simple (in
>                 principle) but
>                              wide-ranging change
>                                                            which should
>                 appeal to
>                                                            our Code
>                 Deletion Engineer's.
>                              We implement
>
>                 Thread::current() using a
>                 compiler/language-based
>                              thread-local
>                                       variable eg:
>
>                                                               static
>                 __thread Thread
>                              *_thr_current;
>
>                                                               inline Thread*
>                              Thread::current() {
>                                                                 return
>                 _thr_current;
>                                                               }
>
>                                                            with an
>                 appropriate setter of
>                              course. By
>                                       doing this
>                                                            we can completely
>                                                            remove the
>                 os_cpu-specific
>                              ThreadLocalStorage
>
>                 implementations, and the
>                                                            associated
>                              os::thread_local_storage* calls.
>
>                                                            As __thread
>                 is not
>                              async-signal-safe (either in
>                                                            theory or
>                 practice) we
>                                                            need a
>                 fallback library-based
>                              solution as used
>                                                            today. For
>                 this we use a
>                                                            very simple
>                 ThreadLocalStorage
>                              class and an
>
>                 implementation thereof for
>                                                            POSIX (covers
>                 AIX, BSD, Linux,
>                              OSX and
>                                       Solaris) using
>                 pthread_get/setspecific; and
>                              one for
>                                       Windows using
>                                                            its TLS library.
>                                                            While these
>                 library routines
>                              are not guaranteed
>
>                 async-signal-safe, they
>                                                            seem to be in
>                 practice and are
>                              what we have
>                                       been
>                                                            using all along.
>
>                                                            We also allow
>                 for use of
>                 only the
>                                       library-based TLS
>                                                            for platforms
>                 where
>
>                 compiler-based thread locals
>                              are not
>                                       supported (as
>                                                            will be needed in
>                                                            the
>                                                            Mobile
>                 project). This is
>                              enabled at build
>                                       time by
>                                                            defining
>                 USE_LIBRARY_BASED_TLS_ONLY.
>
>                                                            Thanks to
>                 Andrew Haley for
>                              providing the
>                                       Aarch64
>                                                            code; and for
>                 Thomas
>                                                            Stuefe for
>                 testing PPC and
>                 AIX.
>
>                                                            Testing:
>                                                               - JPRT
>                 (core platforms)
>                                                               - Jtreg
>                 tests (linux &
>                 solaris)
>                                                               -
>                 vm.runtime (core
>                 platforms)
>
>                                                            Performance:
>                                                               - still
>                 TBD - this is
>                              proving to be
>                                       extremely
>                                                            difficult. If
>                 anyone
>                                                            has
>                                                            any simple to run
>                              microbenchmarks to
>                                       suggest I'd
>                                                            give them a
>                 try as a
>                                                            sanity check.
>                 But I lack
>                              access to hardware for
>                                                            running serious
>                                                            benchmarking.
>
>                                                            Footprint:
>                                                            - varies by
>                 platform and the
>                              VM (server,
>                                       client,
>                                                            minimal)
>                                                            - worst-case:
>                 ~1% increase for
>                              server VM
>                                       and minimal VM
>                                                            - best-case:
>                 0.4% decrease
>                              for client VM
>
>                                                            Thanks,
>                                                            David
>
>
>
>
>
>
>
>
>                                   --
>                                   Bertrand Delsart,
>                   Grenoble
>                              Engineering Center
>                                   Oracle,         180 av. de l'Europe,
>                 ZIRST de
>                              Montbonnot
>                                   38330 Montbonnot Saint Martin, FRANCE
>                 bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>
>                              <mailto:bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>>
>                              <mailto:bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>
>                              <mailto:bertrand.delsart at oracle.com
>                 <mailto:bertrand.delsart at oracle.com>>>
>                                             Phone : +33 4 76 18 81 23
>
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                                   NOTICE: This email message is for the
>                 sole use of the
>                              intended
>                                   recipient(s) and may contain
>                 confidential and
>                 privileged
>                                   information. Any unauthorized review, use,
>                 disclosure or
>                                   distribution is prohibited. If you are
>                 not the intended
>                              recipient,
>                                   please contact the sender by reply
>                 email and destroy
>                              all copies of
>                                   the original message.
>                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
>

From bertrand.delsart at oracle.com  Fri Nov 27 08:48:53 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Fri, 27 Nov 2015 09:48:53 +0100
Subject: RFR: 8132510: Replace ThreadLocalStorage with
	compiler/language-based thread-local variables
In-Reply-To: <565805A1.9080803@oracle.com>
References: <5652BA32.8090207@oracle.com> <5652E6ED.4050106@oracle.com>
	<56530618.2020202@oracle.com> <565318A8.8050003@oracle.com>
	<56538862.5010609@oracle.com>
	<CAA-vtUwxjM4VEvF0LbJ6ewLu6ea+LMkrn8nsGii+TYD=AFfHkQ@mail.gmail.com>
	<56557DCD.9050907@oracle.com>
	<CAA-vtUwYNrqKqhUpNbYqivvdmuuatMd+m4K=ZVLY2t_yxWqzgA@mail.gmail.com>
	<5655B349.9070700@oracle.com> <5655CB39.3030007@oracle.com>
	<CAA-vtUxEjzQ=N2tbFZo1fkRqrQpyPEZjmfebZkC20w9ey0=wpQ@mail.gmail.com>
	<56563BA0.1010307@oracle.com> <56563F61.4030008@oracle.com>
	<5656497E.2050208@oracle.com>
	<CAA-vtUw=BNfxq_1fUGGs=QNHu2KQ+sGCpyrcPnDcRo0788gC4A@mail.gmail.com>
	<565805A1.9080803@oracle.com>
Message-ID: <565818F5.30009@oracle.com>

OK for me.

Thanks,

Bertrand.

On 27/11/2015 08:26, David Holmes wrote:
> Hi Thomas,
>
> On 26/11/2015 7:56 PM, Thomas St?fe wrote:
>>
>> On Thu, Nov 26, 2015 at 12:51 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 26/11/2015 9:08 AM, Daniel D. Daugherty wrote:
>>
>>         If I understand the problem... :-)
>>
>>         The Win-X64 ABI requires that some extra space be allocated on
>>         the stack in the caller for "homing" four registers...
>>
>>         This code uses MacroAssembler::call() which is a lower level
>>         call() function that assumes you know the ABI...
>>
>>         9765 void MacroAssembler::get_thread(Register thread) {
>>         <snip>
>>         9784   call(RuntimeAddress(CAST_FROM_FN_PTR(address,
>>         Thread::current)));
>>
>>     So the failing here was nothing to do with register saving per-se,
>>     nor the alignment code, but "simply" not also saving the extra space
>>     prior to the call!
>>
>> Yes. These 32 byte are a scratch area for the callee, which may be used
>> for parameter registers or anything else. We may just have been lucky so
>> far that TlsGetValue() did not use this area. As Bertrand already said,
>> now we call Thread::current(), which does magic tls accesses under the
>> hood, so this must be tested again.
>
> Right. All testing so far has been successful but ...
>
>> However I think that a simple addition to your current fix could simply
>> be subtracting 32 from rsp before the call:
>>
>> subq(rsp, 32)
>> call(RuntimeAddress(CAST_FROM_FN_PTR(address, Thread::current)));
>> addq(rsp, 32)
>
> ... I decided to do what was previously suggested and use:
>
>    call_VM_leaf_base(CAST_FROM_FN_PTR(address, Thread::current), 0);
>
> as it takes care of everything (stack alignment if needed and preserving
> space for the register args on win64).
>
>> Also, we could probably skip saving/restoring rdi and rsi on Windows:
>
> Maybe - but we don't seem to consider that anywhere else ie:
>
> void MacroAssembler::push_callee_saved_registers() {
>    push(rsi);
>    push(rdi);
>    push(rdx);
>    push(rcx);
> }
>
> so I don't want to be the trail-blazer here. :)
>
> Updated webrev:
>
>   http://cr.openjdk.java.net/~dholmes/8132510/webrev.v10
>
> Only change to macroAssembler_x86.cpp. Re-tested on Windows 32-bit and
> 64-bit.
>
> Thanks,
> David
>
>> https://msdn.microsoft.com/en-us/library/6t169e9c.aspx
>>
>> "The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile
>> and must be considered destroyed on function calls (unless otherwise
>> safety-provable by analysis such as whole program optimization). The
>> registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered
>> nonvolatile and must be saved and restored by a function that uses them."
>
>
>
>> Best Regards, Thomas
>>
>>
>>         If you switch to MacroAssembler::call_VM_leaf_base() it handles
>>         more of the gory details for you than MacroAssembler::call():
>>
>>
>>     Wow! Not exactly a clearly-defined name for this. AFAICS there's
>>     nothing VM or leaf specific about this. Also the MacroAssembler is
>>     supposed to be a platform-agnostic higher-level abstraction that is
>>     easy to use - but in this case every use of the plain call on
>>     Windows-x64 is potentially broken if the programmer was not aware of
>>     this ABI constraint which only applies to Windows (and we're in
>>     OS-neutral files!).
>>
>>     This seems fundamentally broken to me.
>>
>>     Thanks for the info.
>>
>>     David
>>
>>
>>         src/cpu/x86/vm/macroAssembler_x86.cpp:
>>
>>              524  void MacroAssembler::call_VM_leaf_base(address
>>         entry_point, int
>>         num_args
>>         ) {
>>              525    Label L, E;
>>              526
>>              527  #ifdef _WIN64
>>              528    // Windows always allocates space for it's
>> register args
>>              529    assert(num_args <= 4, "only register arguments
>>         supported");
>>              530    subq(rsp,  frame::arg_reg_save_area_bytes);
>>              531  #endif
>>              532
>>              533    // Align stack if necessary
>>              534    testl(rsp, 15);
>>              535    jcc(Assembler::zero, L);
>>              536
>>              537    subq(rsp, 8);
>>              538    {
>>              539      call(RuntimeAddress(entry_point));
>>              540    }
>>
>>         So call_VM_leaf_base() allocates the "homing" space for register
>>         args for Win-X64 on L530 and it handles any stack alignment
>> before
>>         calling MacroAssembler::call().
>>
>>         So if you switch to call_VM_leaf_base() you can drop
>>         the stack alignment code:
>>
>>         9777   // ensure stack alignment
>>         9778   mov(r10, rsp);
>>         9779   andq(rsp, -16);
>>         9780   push(r10);
>>
>>         and just switch to:
>>
>>         9777   push(rsp);
>>
>>         And you won't be exposed to potential saved register
>>         overwrite by the "homing" of any registers in the call
>>         Thread::current().
>>
>>         I _think_ I have that all correct... :-)
>>
>>         Dan
>>
>>
>>         On 11/25/15 3:52 PM, David Holmes wrote:
>>
>>             On 26/11/2015 2:53 AM, Thomas St?fe wrote:
>>
>>                 I created a bug to track this:
>>
>>                 https://bugs.openjdk.java.net/browse/JDK-8144059
>>
>>
>>             Thanks. I admit I still don't really grok the exact problem
>>             here. It
>>             is the alignment code that is the problem right?
>>
>>             79 mov(r10, rsp);
>>             80 andq(rsp, -16);
>>             81 push(r10);
>>
>>             ?
>>
>>             Thanks,
>>             David
>>
>>                 Because Davids change is not submitted yet, the bug
>>                 refers to the old
>>                 coding, but stays relevant also after this fix.
>>
>>                 Kind Regards, Thomas
>>
>>                 On Wed, Nov 25, 2015 at 3:52 PM, Daniel D. Daugherty
>>                 <daniel.daugherty at oracle.com
>>                 <mailto:daniel.daugherty at oracle.com>
>>                 <mailto:daniel.daugherty at oracle.com
>>                 <mailto:daniel.daugherty at oracle.com>>>
>>                 wrote:
>>
>>                      On 11/25/15 6:10 AM, David Holmes wrote:
>>
>>                          On 25/11/2015 8:46 PM, Thomas St?fe wrote:
>>
>>
>>                              On Wed, Nov 25, 2015 at 10:22 AM, Bertrand
>>                 Delsart
>>                              <bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>
>>                              <mailto:bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>>
>>                              <mailto:bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>
>>                              <mailto:bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>>>> wrote:
>>
>>                                   Good finding Thomas,
>>
>>                                   On 25/11/2015 09:40, Thomas St?fe
>> wrote:
>>
>>                                       Hi David, Bertrand,
>>
>>                                       about
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v8/src/cpu/x86/vm/macroAssembler_x86.cpp.frames.html
>>
>>
>>
>>                                       I am not sure this is correct for
>>                 Windows x64.
>>
>>
>>                                   Unless I'm misreading it, the new code
>>                 looks a lot like
>>                              the old one
>>                                   (including the alignement part). Hence
>>                 this does not
>>                              look like a
>>                                   regression caused by David's change.
>>
>>
>>                              Yes, this seems like an old bug.
>>
>>                              I also see that this is fixed in our
>>                 codebase since 2010,
>>                              exactly the
>>                              way you propose (with MacroAssembler
>>
>> <http://ld8443:8080/source/s?defs=MacroAssembler&project=dev-hotspot>::call_VM_leaf_base
>>
>>
>>
>>
>> <http://ld8443:8080/source/s?defs=call_VM_leaf_base&project=dev-hotspot>).
>>
>>
>>
>>                              So, it is already used since five years. I
>>                 would propose
>>                              opening a
>>                              separate bug for this one and we contribute
>>                 our fix.
>>
>>
>>                          That sounds good to me too. I also suspect
>>                 additional code will
>>                          need to be checked as this stack alignment is
>>                 performed in a few
>>                          places in ./cpu/x86/vm/macroAssembler_x86.cpp
>>                 with no OS
>>                          specific differences being considered.
>>
>>
>>                      Looks like MacroAssembler::call_VM_leaf_base() does
>>                 the "right
>>                 thing"
>>                      for stack alignment in the X64 case. Perhaps we
>>                 need to audit both
>>                      stack alignment _and_ uses of
>>                 MacroAssembler::call() just to make
>>                      sure...
>>
>>                      Did I mention that all the assembly code stuff
>>                 gives me a
>>                 headache? :-)
>>
>>                      Dan
>>
>>
>>
>>
>>                          Thanks,
>>                          David
>>
>>                              Regards, Thomas
>>
>>
>>
>> https://msdn.microsoft.com/en-us/library/ew5tede7(v=vs.90).aspx
>>
>>                                       windows x64 Abi requires the
>>                 register parameter
>>                              area right above the
>>                                       return address on the stack. It
>> is not
>>                 guaranteed to be
>>                                       preserved during
>>                                       the function call:
>>
>>                                       "Even if the called function has
>>                 fewer than 4
>>                              parameters, these
>>                                       4 stack
>>                                       locations are effectively owned by
>>                 the called
>>                              function, and may
>>                                       be used
>>                                       by the called function for other
>>                 purposes besides
>>                              saving parameter
>>                                       register values. Thus the caller
>>                 may not save
>>                              information in
>>                                       this region
>>                                       of stack across a function call."
>>
>>                                       So, restoring parameters from it
>>                 may not work if
>>                                       Thread::current() uses
>>                                       this area for any reason. In this
>>                 case, r9, rsp,
>>                              r10, r11 may be
>>                                       overwritten by the callee.
>>
>>                                       I also think Windows x64 ABI is
>>                 different enough
>>                              from Linux that
>>                                       this
>>                                       function could live somewhere in
>>                 <os>_<cpu>.
>>
>>
>>                                   This is a valid point. However, note
>>                 that this is
>>                              similar to the
>>                                   issue we have for instance in 'shared'
>>                                   MacroAssembler::call_VM_leaf_base,
>>                 which was not put in
>>                              <os>_<cpu>
>>                                   files.
>>
>>                                   In fact, the right fix may be to use
>>                 call_VM_leaf
>>                              instead of call :-)
>>
>>                                   (alternatively we could use "#ifdef
>>                 _WIN64" or check
>>                                   "frame::arg_reg_save_area_bytes != 0",
>>                 which may be
>>                              even cleaner and
>>                                   more portable)
>>
>>                                   All these solutions are fine for me.
>>
>>
>>                                   Since we are near to feature freeze,
>>                 this should
>>                              probably be done in
>>                                   a separate CR (unless David has enough
>>                 time to test
>>                 it).
>>
>>                                   Regards,
>>
>>                                   Bertrand.
>>
>>
>>                                       Kind Regards, Thomas
>>
>>
>>
>>
>>                                       On Mon, Nov 23, 2015 at 10:42 PM,
>>                 David Holmes
>>                                       <david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>
>>                              <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>>
>>                              <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>
>>                              <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>>>
>>                                       <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>
>>                              <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>>
>>                                       <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>
>>                              <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>>>>> wrote:
>>
>>                                            On 23/11/2015 11:46 PM,
>>                 Bertrand Delsart
>>                 wrote:
>>
>>                                                On 23/11/2015 13:27,
>>                 David Holmes wrote:
>>
>>                                                    Hi Bertrand,
>>
>>                                                    On 23/11/2015 8:14
>>                 PM, Bertrand
>>                              Delsart wrote:
>>
>>                                                        Hi David,
>>
>>                                                        Overall looks
>> good.
>>                                                        Thanks for the
>>                 #ifndef
>>                                       USE_LIBRARY_BASED_TLS_ONLY :-)
>>
>>                                                        One doubt, in
>>                 case this has not
>>                              been discussed
>>                                       before.
>>
>>                                                        I'm still
>>                 catching up on x86_64
>>                              (after years of ARM
>>                                                        assembly :-))
>> but it
>>                                                        seems that there
>>                 are some stack
>>                              alignment
>>                                       constraints on
>>                                                        runtime calls,
>>                                                        at least for some
>>                 x86_64 ABIs.
>>
>>                                                        Some of the x86
>>                              MacroAssembler::get_thread
>>                                                        implementations
>>                 had code to
>>                                                        align the stack
>>                 before calling
>>                                       pthread_getspecific. See
>>                                                        for instance
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp.udiff.html
>>
>>
>>
>>
>>
>>                                                    Sorry I'm not that
>>                 familiar with the
>>                              MacroAssembler
>>                                       - is it
>>                                                    this odd
>>                                                    fragment:
>>
>>                                                    -   push(r10);
>>                                                    -   // XXX
>>                                                    -   mov(r10, rsp);
>>                                                    -   andq(rsp, -16);
>>                                                    -   push(r10);
>>
>>                                                    I'm not at all clear
>>                 what that is
>>                              doing - and if it
>>                                       somehow
>>                                                    changes the
>>                                                    alignment wouldn't
>>                 something need to
>>                              be fixed up when
>>                                                    popping the
>>                                                    previous values ??
>>
>>                                                    To be honest I'm not
>>                 even sure what an
>>                              "unaligned
>>                                       stack" means.
>>
>>
>>                                                On some platforms, SP may
>>                 have to be
>>                              aligned on a 16 bytes
>>                                                boundary when
>>                                                calling another method.
>>
>>
>>                                            Okay - that seems to be an
>>                 x64 ABI requirement
>>                              based on
>>                                       other code
>>                                            in MacroAssembler. The reason
>>                 it is missing in
>>                              the Solaris
>>                                       code is
>>                                            because I already removed it
>>                 in the earlier
>>                              changes that
>>                                       were done
>>                                            on Solaris:
>>
>>
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d5b328043c10
>>
>>                                            and nobody picked it up. :(
>>
>>                                            That said, the absence of
>>                 this code has not
>>                              caused any
>>                                       problems so
>>                                            presumably we are normally
>>                 aligned.
>>
>>                                                After having pushed what
>>                 needed to be
>>                              saved, the code above
>>                                                rounds SP
>>                                                down and saves the old
>>                 value. It will then
>>                              also push
>>                                       r11, which
>>                                                results
>>                                                in the expected alignment.
>>
>>                                                The conterpart, after the
>>                 VM call, is the:
>>                                                   pop(r11);
>>                                                   pop(rsp);
>>
>>
>>                                            I had assumed this extra
>>                 manipulation was
>>                              related to
>>                                       pushing the arg
>>                                            for the call.
>>
>>                                                        This alignment is
>>                 no longer
>>                              performed in the new
>>                                                        (shared)
>>                 implementation
>>
>> http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/src/cpu/x86/vm/macroAssembler_x86.cpp.udiff.html
>>
>>
>>
>>
>>
>>
>>                                                        Now, Solaris was
>>                 not performing
>>                              the alignment and
>>                                                        Windows has a
>>                 separate
>>                                                        path for x86_64.
>>                 Did we really
>>                              need the
>>                                       alignment for
>>                                                        linux x86_64 and
>>                                                        bsd_x86_64 ?
>>                 Might it be needed
>>                              for other ports ?
>>
>>                                                        IMHO, it might be
>>                 safer to align
>>                              the stack by
>>                                       default,
>>                                                        knowing it should
>>                                                        not be expensive
>>                 since we call
>>                              get_thread
>>                                       rarely for
>>                                                        x86_64 (result is
>>                                                        cached in r15).
>>                 I'll let you see
>>                              whether it is
>>                                       worth
>>                                                        adding an ifdef so
>>                                                        as to explicitly
>>                 deactivate the
>>                              alignment on
>>                                       some platforms
>>                                                        (solaris_x86_64 ?)
>>
>>
>>                                                    I don't have enough
>>                 knowledge to even
>>                              begin to
>>                                       comment on
>>                                                    this. I will
>>                                                    have to rely on our
>>                 x86_64
>>                              macroassembler experts
>>                                       to explain
>>                                                    the old
>>                                                    code and what the
>>                 requirements are.
>>
>>
>>                                                OK. This means that the
>>                 alignment was not
>>                              removed
>>                                       purposefully.
>>
>>                                                In that case, you must
>>                 either keep the per
>>                              platform
>>                                       code x86_64
>>                                                (since
>>                                                it was not identical for
>>                 all platforms) or
>>                              use the safest
>>                                                version, with
>>                                                the additional
>>
>>                                                     // XXX
>>                                                     mov(r10, rsp);
>>                                                     andq(rsp, -16);
>>                                                     push(r10);
>>
>>                                                before the push(r11) and
>>                 with the
>>
>>                                                     pop(rsp);
>>
>>                                                after the pop(r11). It
>>                 should work on all
>>                              x86_64 platforms.
>>
>>
>>                                            Right, I will add this back
>>                 to the code - and
>>                              replace the
>>                                            meaningless // XXX with an
>>                 actual comment!
>>
>>                                            Many thanks,
>>                                            David
>>                                            -----
>>
>>
>>                                                FYI, there is another way
>>                 to do the
>>                              alignment, based on
>>                                       the fact
>>                                                that
>>                                                we are at least aligned
>>                 on 8 bytes (see
>>                 MacroAssembler::call_VM_leaf_base). I
>>                              assume that this
>>                                       second
>>                                                version is
>>                                                more efficient
>>                 (particularly thanks to
>>                              specilative
>>                                       branches) but it
>>                                                might be safer/simpler to
>>                 continue using
>>                              andq in
>>                                       get_thread.
>>
>>                                                Bertrand.
>>
>>
>>                                                    Thanks,
>>                                                    David
>>
>>                                                        Regards,
>>
>>                                                        Bertrand.
>>
>>
>>
>>                                                        On 23/11/2015
>>                 08:03, David Holmes
>>                              wrote:
>>
>>                                                            After all the
>>                 preliminary
>>                              discussions here
>>                                       are final
>>                                                            proposed
>> changes:
>>
>>                                                            bug:
>>                 https://bugs.openjdk.java.net/browse/JDK-8132510
>>
>>                                                            Open webrev:
>>                 http://cr.openjdk.java.net/~dholmes/8132510/webrev.v6/
>>
>>                                                            A simple (in
>>                 principle) but
>>                              wide-ranging change
>>                                                            which should
>>                 appeal to
>>                                                            our Code
>>                 Deletion Engineer's.
>>                              We implement
>>
>>                 Thread::current() using a
>>                 compiler/language-based
>>                              thread-local
>>                                       variable eg:
>>
>>                                                               static
>>                 __thread Thread
>>                              *_thr_current;
>>
>>                                                               inline
>> Thread*
>>                              Thread::current() {
>>                                                                 return
>>                 _thr_current;
>>                                                               }
>>
>>                                                            with an
>>                 appropriate setter of
>>                              course. By
>>                                       doing this
>>                                                            we can
>> completely
>>                                                            remove the
>>                 os_cpu-specific
>>                              ThreadLocalStorage
>>
>>                 implementations, and the
>>                                                            associated
>>                              os::thread_local_storage* calls.
>>
>>                                                            As __thread
>>                 is not
>>                              async-signal-safe (either in
>>                                                            theory or
>>                 practice) we
>>                                                            need a
>>                 fallback library-based
>>                              solution as used
>>                                                            today. For
>>                 this we use a
>>                                                            very simple
>>                 ThreadLocalStorage
>>                              class and an
>>
>>                 implementation thereof for
>>                                                            POSIX (covers
>>                 AIX, BSD, Linux,
>>                              OSX and
>>                                       Solaris) using
>>                 pthread_get/setspecific; and
>>                              one for
>>                                       Windows using
>>                                                            its TLS
>> library.
>>                                                            While these
>>                 library routines
>>                              are not guaranteed
>>
>>                 async-signal-safe, they
>>                                                            seem to be in
>>                 practice and are
>>                              what we have
>>                                       been
>>                                                            using all
>> along.
>>
>>                                                            We also allow
>>                 for use of
>>                 only the
>>                                       library-based TLS
>>                                                            for platforms
>>                 where
>>
>>                 compiler-based thread locals
>>                              are not
>>                                       supported (as
>>                                                            will be
>> needed in
>>                                                            the
>>                                                            Mobile
>>                 project). This is
>>                              enabled at build
>>                                       time by
>>                                                            defining
>>                 USE_LIBRARY_BASED_TLS_ONLY.
>>
>>                                                            Thanks to
>>                 Andrew Haley for
>>                              providing the
>>                                       Aarch64
>>                                                            code; and for
>>                 Thomas
>>                                                            Stuefe for
>>                 testing PPC and
>>                 AIX.
>>
>>                                                            Testing:
>>                                                               - JPRT
>>                 (core platforms)
>>                                                               - Jtreg
>>                 tests (linux &
>>                 solaris)
>>                                                               -
>>                 vm.runtime (core
>>                 platforms)
>>
>>                                                            Performance:
>>                                                               - still
>>                 TBD - this is
>>                              proving to be
>>                                       extremely
>>                                                            difficult. If
>>                 anyone
>>                                                            has
>>                                                            any simple
>> to run
>>                              microbenchmarks to
>>                                       suggest I'd
>>                                                            give them a
>>                 try as a
>>                                                            sanity check.
>>                 But I lack
>>                              access to hardware for
>>                                                            running
>> serious
>>                                                            benchmarking.
>>
>>                                                            Footprint:
>>                                                            - varies by
>>                 platform and the
>>                              VM (server,
>>                                       client,
>>                                                            minimal)
>>                                                            - worst-case:
>>                 ~1% increase for
>>                              server VM
>>                                       and minimal VM
>>                                                            - best-case:
>>                 0.4% decrease
>>                              for client VM
>>
>>                                                            Thanks,
>>                                                            David
>>
>>
>>
>>
>>
>>
>>
>>
>>                                   --
>>                                   Bertrand Delsart,
>>                   Grenoble
>>                              Engineering Center
>>                                   Oracle,         180 av. de l'Europe,
>>                 ZIRST de
>>                              Montbonnot
>>                                   38330 Montbonnot Saint Martin, FRANCE
>>                 bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>
>>                              <mailto:bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>>
>>                              <mailto:bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>
>>                              <mailto:bertrand.delsart at oracle.com
>>                 <mailto:bertrand.delsart at oracle.com>>>
>>                                             Phone : +33 4 76 18 81 23
>>
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>                                   NOTICE: This email message is for the
>>                 sole use of the
>>                              intended
>>                                   recipient(s) and may contain
>>                 confidential and
>>                 privileged
>>                                   information. Any unauthorized
>> review, use,
>>                 disclosure or
>>                                   distribution is prohibited. If you are
>>                 not the intended
>>                              recipient,
>>                                   please contact the sender by reply
>>                 email and destroy
>>                              all copies of
>>                                   the original message.
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>
>>
>>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From erik.joelsson at oracle.com  Fri Nov 27 09:16:02 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 27 Nov 2015 10:16:02 +0100
Subject: RFR: JDK-8144134: Nightly tests fail with SIGSEGV in Ticks::now()
Message-ID: <56581F52.9040407@oracle.com>

Hello,

Please review this small fix for the nightly test failure in SA. In my 
makefile conversion I seem to have accidentally deleted a character. In 
this case it had rather interesting side effects.

Bug: https://bugs.openjdk.java.net/browse/JDK-8144134
Patch:
diff -r b8bc00e338c4 make/lib/Lib-jdk.hotspot.agent.gmk
--- a/make/lib/Lib-jdk.hotspot.agent.gmk
+++ b/make/lib/Lib-jdk.hotspot.agent.gmk
@@ -79,7 +79,7 @@
    SA_EXCLUDE_FILES := BsdDebuggerLocal.c ps_proc.c salibelf.c 
StubDebuggerLocal.c
    SA_CFLAGS := $(CFLAGS_JDKLIB) \
        -Damd64 -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
-      -mstack-alignment=1 -fPIC
+      -mstack-alignment=16 -fPIC
    SA_LDFLAGS := $(LDFLAGS_JDKLIB)
    SA_LIBS := -framework Foundation -framework JavaNativeFoundation \
        -framework Security -framework CoreFoundation


From mikael.gerdin at oracle.com  Fri Nov 27 09:19:11 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 27 Nov 2015 10:19:11 +0100
Subject: RFR: JDK-8144134: Nightly tests fail with SIGSEGV in Ticks::now()
In-Reply-To: <56581F52.9040407@oracle.com>
References: <56581F52.9040407@oracle.com>
Message-ID: <5658200F.5030708@oracle.com>

Hi Erik,

On 2015-11-27 10:16, Erik Joelsson wrote:
> Hello,
>
> Please review this small fix for the nightly test failure in SA. In my
> makefile conversion I seem to have accidentally deleted a character. In
> this case it had rather interesting side effects.

Interesting indeed!

Looks good to me.
/Mikael

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144134
> Patch:
> diff -r b8bc00e338c4 make/lib/Lib-jdk.hotspot.agent.gmk
> --- a/make/lib/Lib-jdk.hotspot.agent.gmk
> +++ b/make/lib/Lib-jdk.hotspot.agent.gmk
> @@ -79,7 +79,7 @@
>     SA_EXCLUDE_FILES := BsdDebuggerLocal.c ps_proc.c salibelf.c
> StubDebuggerLocal.c
>     SA_CFLAGS := $(CFLAGS_JDKLIB) \
>         -Damd64 -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> -      -mstack-alignment=1 -fPIC
> +      -mstack-alignment=16 -fPIC
>     SA_LDFLAGS := $(LDFLAGS_JDKLIB)
>     SA_LIBS := -framework Foundation -framework JavaNativeFoundation \
>         -framework Security -framework CoreFoundation
>


From staffan.larsen at oracle.com  Fri Nov 27 09:20:45 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 27 Nov 2015 10:20:45 +0100
Subject: RFR: JDK-8144134: Nightly tests fail with SIGSEGV in Ticks::now()
In-Reply-To: <56581F52.9040407@oracle.com>
References: <56581F52.9040407@oracle.com>
Message-ID: <D0692DBD-A562-4D73-8095-EF43FDED878B@oracle.com>

Looks good!

Thanks,
/Staffan

> On 27 nov. 2015, at 10:16, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> Please review this small fix for the nightly test failure in SA. In my makefile conversion I seem to have accidentally deleted a character. In this case it had rather interesting side effects.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144134
> Patch:
> diff -r b8bc00e338c4 make/lib/Lib-jdk.hotspot.agent.gmk
> --- a/make/lib/Lib-jdk.hotspot.agent.gmk
> +++ b/make/lib/Lib-jdk.hotspot.agent.gmk
> @@ -79,7 +79,7 @@
>   SA_EXCLUDE_FILES := BsdDebuggerLocal.c ps_proc.c salibelf.c StubDebuggerLocal.c
>   SA_CFLAGS := $(CFLAGS_JDKLIB) \
>       -Damd64 -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> -      -mstack-alignment=1 -fPIC
> +      -mstack-alignment=16 -fPIC
>   SA_LDFLAGS := $(LDFLAGS_JDKLIB)
>   SA_LIBS := -framework Foundation -framework JavaNativeFoundation \
>       -framework Security -framework CoreFoundation
> 


From david.holmes at oracle.com  Fri Nov 27 09:29:46 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Nov 2015 19:29:46 +1000
Subject: RFR: JDK-8144134: Nightly tests fail with SIGSEGV in Ticks::now()
In-Reply-To: <56581F52.9040407@oracle.com>
References: <56581F52.9040407@oracle.com>
Message-ID: <5658228A.4060805@oracle.com>

Looks good. I'm assuming we don't have any SA tests in JPRT. :(

Trivial fix so this can  be pushed straight away.

Thanks,
David

On 27/11/2015 7:16 PM, Erik Joelsson wrote:
> Hello,
>
> Please review this small fix for the nightly test failure in SA. In my
> makefile conversion I seem to have accidentally deleted a character. In
> this case it had rather interesting side effects.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144134
> Patch:
> diff -r b8bc00e338c4 make/lib/Lib-jdk.hotspot.agent.gmk
> --- a/make/lib/Lib-jdk.hotspot.agent.gmk
> +++ b/make/lib/Lib-jdk.hotspot.agent.gmk
> @@ -79,7 +79,7 @@
>     SA_EXCLUDE_FILES := BsdDebuggerLocal.c ps_proc.c salibelf.c
> StubDebuggerLocal.c
>     SA_CFLAGS := $(CFLAGS_JDKLIB) \
>         -Damd64 -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> -      -mstack-alignment=1 -fPIC
> +      -mstack-alignment=16 -fPIC
>     SA_LDFLAGS := $(LDFLAGS_JDKLIB)
>     SA_LIBS := -framework Foundation -framework JavaNativeFoundation \
>         -framework Security -framework CoreFoundation
>

From erik.joelsson at oracle.com  Fri Nov 27 09:31:40 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 27 Nov 2015 10:31:40 +0100
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <56568EC8.1080803@oracle.com>
References: <56557936.3070109@oracle.com> <56568EC8.1080803@oracle.com>
Message-ID: <565822FC.8080205@oracle.com>

I'm guessing the "friend" status of DebugInformationRecorder is somehow 
the culprit and that the change to _offset is just done as a consequence 
of removing the friend status. All I know is that it works and that from 
the infra-team, we really need to this bug resolved yesterday.

/Erik

On 2015-11-26 05:47, David Holmes wrote:
> On 25/11/2015 7:02 PM, Erik Joelsson wrote:
>> Hello,
>>
>> The following new build failure has appeared in the hotspot build when
>> using the proposed new compiler version on Solaris, SS12u4.
>>
>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>
>> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&,
>> DIR_Chunk*const&) is not accessible from
>> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&). 
>>
>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>
>> line 281: Where: While instantiating
>> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>>
>>
>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>
>> line 281: Where: Instantiated from non-template code.
>
> I'm really struggling to see how those error messages relate to the fix!
>
> David
> -----
>
>> Tom Rodriguez provided a patch and I have verified that it solves the
>> issue. Since this is blocking us upgrading compilers on Solaris, I am
>> taking the liberty of posting it for review so we may get this resolved
>> quickly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>
>> /Erik


From mikael.gerdin at oracle.com  Fri Nov 27 09:40:44 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 27 Nov 2015 10:40:44 +0100
Subject: RFR: JDK-8144134: Nightly tests fail with SIGSEGV in Ticks::now()
In-Reply-To: <5658200F.5030708@oracle.com>
References: <56581F52.9040407@oracle.com> <5658200F.5030708@oracle.com>
Message-ID: <5658251C.6000400@oracle.com>

Hi Volker,

Since you added the explicit stack alignment parameter as part of the 
integration of Clang compiler support:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-May/007395.html

What is the reason for setting it?
Isn't the stack alignment already "16" on OS X x64?

Some comments talk about i486 support, if setting the stack alignment 
explicitly is only needed on 32 bit builds, would it make sense to only 
set stack alignment on such builds?

/Mikael

On 2015-11-27 10:19, Mikael Gerdin wrote:
> Hi Erik,
>
> On 2015-11-27 10:16, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this small fix for the nightly test failure in SA. In my
>> makefile conversion I seem to have accidentally deleted a character. In
>> this case it had rather interesting side effects.
>
> Interesting indeed!
>
> Looks good to me.
> /Mikael
>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144134
>> Patch:
>> diff -r b8bc00e338c4 make/lib/Lib-jdk.hotspot.agent.gmk
>> --- a/make/lib/Lib-jdk.hotspot.agent.gmk
>> +++ b/make/lib/Lib-jdk.hotspot.agent.gmk
>> @@ -79,7 +79,7 @@
>>     SA_EXCLUDE_FILES := BsdDebuggerLocal.c ps_proc.c salibelf.c
>> StubDebuggerLocal.c
>>     SA_CFLAGS := $(CFLAGS_JDKLIB) \
>>         -Damd64 -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
>> -      -mstack-alignment=1 -fPIC
>> +      -mstack-alignment=16 -fPIC
>>     SA_LDFLAGS := $(LDFLAGS_JDKLIB)
>>     SA_LIBS := -framework Foundation -framework JavaNativeFoundation \
>>         -framework Security -framework CoreFoundation
>>
>


From david.holmes at oracle.com  Fri Nov 27 09:41:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Nov 2015 19:41:00 +1000
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <565822FC.8080205@oracle.com>
References: <56557936.3070109@oracle.com> <56568EC8.1080803@oracle.com>
	<565822FC.8080205@oracle.com>
Message-ID: <5658252C.3070909@oracle.com>

On 27/11/2015 7:31 PM, Erik Joelsson wrote:
> I'm guessing the "friend" status of DebugInformationRecorder is somehow
> the culprit and that the change to _offset is just done as a consequence
> of removing the friend status. All I know is that it works and that from
> the infra-team, we really need to this bug resolved yesterday.

I can see that if DebugInformationRecorder is no longer a friend then 
offset() needs to be public. What I can't see is how it being a friend 
causes the access errors reported. This is where the error originates:

  DIR_Chunk* match = _all_chunks->insert_sorted<DIR_Chunk::compare>(ns);

and while I'm unclear what is accessible to what at this line, I fail to 
see how _removing_ a friend declaration can _increase_ the accessibility!

I'd like to know there is some subtle C++ template access issue here, 
and not just a broken compiler!

Thanks,
David

> /Erik
>
> On 2015-11-26 05:47, David Holmes wrote:
>> On 25/11/2015 7:02 PM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> The following new build failure has appeared in the hotspot build when
>>> using the proposed new compiler version on Solaris, SS12u4.
>>>
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp",
>>>
>>> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&,
>>> DIR_Chunk*const&) is not accessible from
>>> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
>>>
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp",
>>>
>>> line 281: Where: While instantiating
>>> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)".
>>>
>>>
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp",
>>>
>>> line 281: Where: Instantiated from non-template code.
>>
>> I'm really struggling to see how those error messages relate to the fix!
>>
>> David
>> -----
>>
>>> Tom Rodriguez provided a patch and I have verified that it solves the
>>> issue. Since this is blocking us upgrading compilers on Solaris, I am
>>> taking the liberty of posting it for review so we may get this resolved
>>> quickly.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>>
>>> /Erik
>

From aph at redhat.com  Fri Nov 27 09:58:05 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Nov 2015 09:58:05 +0000
Subject: Silence warnings with new GCC
In-Reply-To: <565777D1.3090704@oracle.com>
References: <5657403E.6060906@redhat.com> <565777D1.3090704@oracle.com>
Message-ID: <5658292D.30607@redhat.com>

On 26/11/15 21:21, David Holmes wrote:
> Strictly speaking it is of course reachable, but if we do reach it we 
> expect never to return. As per the thread Mario pointed to we ran into 
> problems trying to mark this as not returning. But I wonder whether 
> lying to the compiler about the reachability of it would be a 
> workaround? Of course if the compiler used that information to elide the 
> ShouldNotReachHere() then that is not acceptable.

I've put the unreachable declaration after ShouldNotReachHere(), so
that will not be affected at all.  It is the responsibility of
ShouldNotReachHere() to make sure that control doesn't, er, reach
here.

A __builtin_unreachable declration is better from this point of view
than declaring ShouldNotReachHere() to never return.

On April 20 Mikael Gerdin posted
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/018093.html

It claims to solve the problems with the stack trace.  I think it's
not been reviewed.

Andrew.

From erik.joelsson at oracle.com  Fri Nov 27 11:19:08 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 27 Nov 2015 12:19:08 +0100
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <5655CA09.6020001@oracle.com>
References: <56557936.3070109@oracle.com> <5655CA09.6020001@oracle.com>
Message-ID: <56583C2C.6040508@oracle.com>

You were correct, it didn't work when I built with "make 
INCLUDE_JMVCI=false". Here is a new webrev where that part is fixed:

http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/

(I accidentally overwrote the old one)

It changes the other accesses to _offset to offset().

Regarding why the patch works, Tom, could you please fill in here?

/Erik

On 2015-11-25 15:47, Coleen Phillimore wrote:
>
> I don't think this change will compile with INCLUDE_JVMCI off either.
> Coleen
>
> On 11/25/15 4:02 AM, Erik Joelsson wrote:
>> Hello,
>>
>> The following new build failure has appeared in the hotspot build 
>> when using the proposed new compiler version on Solaris, SS12u4.
>>
>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&, 
>> DIR_Chunk*const&) is not accessible from 
>> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>> line 281: Where: While instantiating 
>> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>>
>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>> line 281: Where: Instantiated from non-template code.
>>
>> Tom Rodriguez provided a patch and I have verified that it solves the 
>> issue. Since this is blocking us upgrading compilers on Solaris, I am 
>> taking the liberty of posting it for review so we may get this 
>> resolved quickly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>
>> /Erik
>


From staffan.larsen at oracle.com  Fri Nov 27 11:33:56 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 27 Nov 2015 12:33:56 +0100
Subject: RFR: JDK-8144134: Nightly tests fail with SIGSEGV in Ticks::now()
In-Reply-To: <5658228A.4060805@oracle.com>
References: <56581F52.9040407@oracle.com> <5658228A.4060805@oracle.com>
Message-ID: <98BA860F-A869-4FF9-BC8C-1CE1F1FAD31B@oracle.com>


> On 27 nov. 2015, at 10:29, David Holmes <david.holmes at oracle.com> wrote:
> 
> Looks good. I'm assuming we don't have any SA tests in JPRT. :(

No, we don?t. Part of the reason is that they require very specific setup of the machines to be able to attach to (debug) another process. On OS X you either have to run as root or have a correct code signing certificate in your keychain. 

/Staffan

> 
> Trivial fix so this can  be pushed straight away.
> 
> Thanks,
> David
> 
> On 27/11/2015 7:16 PM, Erik Joelsson wrote:
>> Hello,
>> 
>> Please review this small fix for the nightly test failure in SA. In my
>> makefile conversion I seem to have accidentally deleted a character. In
>> this case it had rather interesting side effects.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144134
>> Patch:
>> diff -r b8bc00e338c4 make/lib/Lib-jdk.hotspot.agent.gmk
>> --- a/make/lib/Lib-jdk.hotspot.agent.gmk
>> +++ b/make/lib/Lib-jdk.hotspot.agent.gmk
>> @@ -79,7 +79,7 @@
>>    SA_EXCLUDE_FILES := BsdDebuggerLocal.c ps_proc.c salibelf.c
>> StubDebuggerLocal.c
>>    SA_CFLAGS := $(CFLAGS_JDKLIB) \
>>        -Damd64 -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
>> -      -mstack-alignment=1 -fPIC
>> +      -mstack-alignment=16 -fPIC
>>    SA_LDFLAGS := $(LDFLAGS_JDKLIB)
>>    SA_LIBS := -framework Foundation -framework JavaNativeFoundation \
>>        -framework Security -framework CoreFoundation
>> 


From konstantin.shefov at oracle.com  Fri Nov 27 16:48:16 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 27 Nov 2015 19:48:16 +0300
Subject: RFR [9] 8141615: Add new public methods to
	sun.reflect.ConstantPool
In-Reply-To: <5654914E.1090603@oracle.com>
References: <5645F9C6.2070802@oracle.com>
	<186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com>
	<1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr>
	<564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com>
	<5654914E.1090603@oracle.com>
Message-ID: <56588950.7050101@oracle.com>

Coleen,
Thanks for review

On 11/24/2015 07:33 PM, Coleen Phillimore wrote:
>
> I have a couple preliminary comments.  First, there are no tests added 
> with all this new functionality.  Tests should be added with the 
> functionality changeset, not promised afterward. 
I will add tests.
> Secondly, I do not like that JDK code knows the implementation details 
> of the JVM's constant pool tags.  These should be only for internal use.
The package "sun.reflect" is for internal use only, so it shouldn?t be a 
problem.
> My third comment is that I haven't looked carefully at this constant 
> pool implementation but it seems very unsafe if the class is redefined 
> and relies on an implementation detail in the JVM that can change.   I 
> will have more comments once I look more at the jvmti specification.
>
> thanks,
> Coleen
>
> On 11/24/15 9:48 AM, Konstantin Shefov wrote:
>> Hello
>>
>> Please, review modified webrev.
>>
>> I have added methods
>> getNameAndTypeRefIndexAt(int index) - to get name and type entry 
>> index from a method, field or indy entry index;
>> getClassRefIndexAt(int index) - to get class entry index from a 
>> method or field entry index;
>>
>> I removed previously added method
>> getInvokedynamicRefInfoAt(int index) - as it is no more needed now.
>>
>> New webrev:
>> Webrev hotspot: 
>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01
>> Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01
>>
>> Thanks
>> -Konstantin
>>
>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote:
>>> Remi,
>>>
>>> Thanks for reviewing. Your suggestion sounds sensibly.
>>> May be it also has sense to make a method 
>>> "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type 
>>> entry index for methods also.
>>>
>>> -Konstantin
>>>
>>> On 11/18/2015 12:04 AM, Remi Forax wrote:
>>>> Hi Konstantin,
>>>> Technically, getInvokedynamicRefInfoAt should be 
>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the 
>>>> nameAndType value of the InvokeDynamicRef.
>>>>
>>>> In term of API, I think it's better to decompose the API, i.e. to 
>>>> have a method
>>>>    int getInvokedynamicRefNameAndTypeIndex(int index)
>>>> that returns the nameAndType index and to reuse 
>>>> getNameAndTypeRefInfoAt(index) to get the corresponding array of 
>>>> Strings.
>>>>
>>>> cheers,
>>>> R?mi
>>>>
>>>> ----- Mail original -----
>>>>> De: "Christian Thalinger" <christian.thalinger at oracle.com>
>>>>> ?: "Konstantin Shefov" <konstantin.shefov at oracle.com>
>>>>> Cc: "hotspot-dev developers" <hotspot-dev at openjdk.java.net>, 
>>>>> core-libs-dev at openjdk.java.net
>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45
>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to 
>>>>> sun.reflect.ConstantPool
>>>>>
>>>>> [CC'ing core-libs-dev]
>>>>>
>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>>>>>> <konstantin.shefov at oracle.com> wrote:
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> Please review an enhancement to add three new methods to
>>>>>> sun.reflect.ConstantPool class.
>>>>>> The following methods are suggested:
>>>>>>
>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - returns string
>>>>>> representation of name and type from a NameAndType constant pool 
>>>>>> entry
>>>>>> with the specified index
>>>>>>
>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - returns 
>>>>>> string
>>>>>> representation of name and type from an InvokeDynamic constant 
>>>>>> pool entry
>>>>>> with the specified index
>>>>>>
>>>>>> public Tag getTagAt(int index) - returns a Tag enum instance of a 
>>>>>> constant
>>>>>> pool entry with the specified index
>>>>>>
>>>>>> These three methods could be used for testing API working with 
>>>>>> constant
>>>>>> pool, e.g. JVMCI.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615
>>>>>> Webrev hotspot:
>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00
>>>>>> Webrev jdk: 
>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00
>>>>>>
>>>>>> Thanks
>>>>>> -Konstantin
>>>>>
>>>
>>
>


From asmundak at google.com  Mon Nov 30 02:39:34 2015
From: asmundak at google.com (Alexander Smundak)
Date: Sun, 29 Nov 2015 18:39:34 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value on
	ppc64le cause issues with Java tooling
Message-ID: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>

Please review the patch set that fixes
https://bugs.openjdk.java.net/browse/JDK-8073139: PPC64: User-visible
arch directory and os.arch value on ppc64le cause issues with Java
tooling:
http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.02
http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.02
http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.02

The patch is based on the patch by Andrew Hughes (gnu.andrew at redhat.com),
please see the thread
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017148.html
The current patch set adds the changes to show the correct architecture in the
'java  -Xinternalversion' output and test_env.sh (both pointed by
goetz.lindenmaier at sap.com), and fixes Serviceability Agent and
 disassembler (hsdis).

I need a sponsor.

Sasha

From david.holmes at oracle.com  Mon Nov 30 04:23:52 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Nov 2015 14:23:52 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
Message-ID: <565BCF58.90405@oracle.com>

Hi Sasha,

Trying to trace through this is somewhat complex :)

So ...

At the top level if we see ppc64le then we set VAR_CPU to ppc64le 
instead of ppc64. However, once we get into hotspot build we want ARCH 
to be ppc64 again (in hotspot-spec.gmk.in) - why is that?

Inside hotpot we want:

SRCARCH := ppc
BUILDARCH := ppc64
LIBARCH := ppc64le

right? So can ARCH not be ppc64le from the top-level and then we adjust 
SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH.

More comments below ...

On 30/11/2015 12:39 PM, Alexander Smundak wrote:
> Please review the patch set that fixes
> https://bugs.openjdk.java.net/browse/JDK-8073139: PPC64: User-visible
> arch directory and os.arch value on ppc64le cause issues with Java
> tooling:
> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.02

agent/src/os/linux/LinuxDebuggerLocal.c
agent/src/os/linux/libproc.h

Is it not the case that ppc64le -> ppc64, so that we can avoid "if 
defined(ppc64) | defined(ppc64le) ? I would hope that the only places in 
the sources where you need to check for ppc64le is where that code 
differs from the ppc64 code.

---

make/defs.make

See above discussion re ARCH etc.

---

src/share/vm/runtime/vm_version.cpp

I think this messy code block relates to builds where CPU is not set - 
which should never be the case these days. Maybe just put in a check 
"ifndef CPU -> error" ?

> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.02

No comments.

> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.02

Again referring back to earlier ARCH discussion, I don't like seeing the 
platform specific code in hotspot-spec.gmk.in.

Thanks,
David

> The patch is based on the patch by Andrew Hughes (gnu.andrew at redhat.com),
> please see the thread
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017148.html
> The current patch set adds the changes to show the correct architecture in the
> 'java  -Xinternalversion' output and test_env.sh (both pointed by
> goetz.lindenmaier at sap.com), and fixes Serviceability Agent and
>   disassembler (hsdis).
>
> I need a sponsor.
>
> Sasha
>

From jaroslav.bachorik at oracle.com  Mon Nov 30 10:36:15 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 30 Nov 2015 11:36:15 +0100
Subject: RFR 8141526: Allow to collect stdout/stderr from the
	FinalizationRunner even before the process returns
In-Reply-To: <56562D60.80306@oracle.com>
References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com>
Message-ID: <565C269F.1050206@oracle.com>

On 25.11.2015 22:51, Dmitry Samersoff wrote:
> Jaroslav,
>
> Looks good for me.

Thanks! Could I have someone from outside of svc to take a look at this 
as well? The change needs to augment the hotspot test library with some 
features from the jdk hotspot library. And in order not to duplicate the 
code it consolidate these library classes into the shared library.


>
> PS: I found a bug in canPtraceAttachLinux not related to your changes -
> it's probably my mistake:
>
>   181         if (userName.equals("root")) {
>   182             return true;
>   183         }
>
> shouldn't be there.
>
> Could you file a separate CR and assign it to me?

Will do.

-JB-

>
> -Dmitry
>
> On 2015-11-06 19:11, Jaroslav Bachorik wrote:
>> [wider audience included]
>>
>> Please, review the following test change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526
>> Webrev:
>> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00
>> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot
>> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk
>>
>> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we
>> are not able to get the debug info about the run of the launcher
>> FinalizationRunner application in case it gets stuck and harness times
>> out. This is because the stdout/err of the application started via
>> ProcessTools.executeProcess() is collected only after the application
>> has exited.
>>
>> The solution is to use ProcessTools.startProcess() and consume the
>> application stdout/err in a streaming mode. Because this method has only
>> been available in the 'jdk' version of ProcessTools and not in the
>> 'hotspot' one I decided to merge both of those versions and place the
>> merged version into the shared location 'test/lib/share/classes/'.
>> During this I decided to change the package for the shared ProcessTools
>> class to be 'jdk.test.lib.process' to be more in line with the way this
>> shared library is structured. I had to move few other lib classes
>> required by ProcessTools to the shared lib as well. All the moved lib
>> classes have been marked as deprecated in their original location.
>>
>>
>> Thanks,
>>
>> -JB-
>>
>
>


From magnus.ihse.bursie at oracle.com  Mon Nov 30 12:43:35 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 30 Nov 2015 13:43:35 +0100
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <565BCF58.90405@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com>
Message-ID: <565C4477.4090708@oracle.com>



On 2015-11-30 05:23, David Holmes wrote:
> Hi Sasha,
>
> Trying to trace through this is somewhat complex :)
>
> So ...
>
> At the top level if we see ppc64le then we set VAR_CPU to ppc64le 
> instead of ppc64. However, once we get into hotspot build we want ARCH 
> to be ppc64 again (in hotspot-spec.gmk.in) - why is that?
>
> Inside hotpot we want:
>
> SRCARCH := ppc
> BUILDARCH := ppc64
> LIBARCH := ppc64le
>
> right? So can ARCH not be ppc64le from the top-level and then we 
> adjust SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH.
>
> More comments below ...
>
> On 30/11/2015 12:39 PM, Alexander Smundak wrote:
>> Please review the patch set that fixes
>> https://bugs.openjdk.java.net/browse/JDK-8073139: PPC64: User-visible
>> arch directory and os.arch value on ppc64le cause issues with Java
>> tooling:
>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.02
>
> agent/src/os/linux/LinuxDebuggerLocal.c
> agent/src/os/linux/libproc.h
>
> Is it not the case that ppc64le -> ppc64, so that we can avoid "if 
> defined(ppc64) | defined(ppc64le) ? I would hope that the only places 
> in the sources where you need to check for ppc64le is where that code 
> differs from the ppc64 code.
>
> ---
>
> make/defs.make
>
> See above discussion re ARCH etc.
>
> ---
>
> src/share/vm/runtime/vm_version.cpp
>
> I think this messy code block relates to builds where CPU is not set - 
> which should never be the case these days. Maybe just put in a check 
> "ifndef CPU -> error" ?
I agree. There might be a case for handling zero, though. If I remember 
correctly the hotspot build might not set CPU, or set it incorrectly, 
when building zero. (Then again, zero is a strange beast, a mix between 
a variant and a platform...)

>
>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.02
>
> No comments.
>
>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.02
>
> Again referring back to earlier ARCH discussion, I don't like seeing 
> the platform specific code in hotspot-spec.gmk.in.
I agree. No logic in the spec files, if it can at all be avoided.

I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is 
defined to ppc for both ppc64 and the new ppc64le platform, that it, it 
explicitely excludes address size. I think it's reasonable that it 
excludes endianness as well, but we have not really had to make that 
discussion before. In any case, it should not contain "64", otherwise 
the value will be "ppc" for ppc64 and "ppc64le" for ppc64le, and that's 
just plain wrong.

I'm not sure what would be the proper way to solve this, but as a start, 
I'm not sure you need to really change any of the defines used to build 
hotspot, as long as the build is correct. Instead, if you need to update 
os.arch, maybe you should just add a check for endianness if you're 
running on ppc64 where os.arch is set?

/Magnus
>
> Thanks,
> David
>
>> The patch is based on the patch by Andrew Hughes 
>> (gnu.andrew at redhat.com),
>> please see the thread
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017148.html 
>>
>> The current patch set adds the changes to show the correct 
>> architecture in the
>> 'java  -Xinternalversion' output and test_env.sh (both pointed by
>> goetz.lindenmaier at sap.com), and fixes Serviceability Agent and
>>   disassembler (hsdis).
>>
>> I need a sponsor.
>>
>> Sasha
>>


From magnus.ihse.bursie at oracle.com  Mon Nov 30 13:13:28 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 30 Nov 2015 14:13:28 +0100
Subject: RFR: 8139272: Add configure variable to set concurrency for jtreg
	tests
In-Reply-To: <20151020140535.GG15817@ehelin.jrpg.bea.com>
References: <20151009120947.GU14241@ehelin.jrpg.bea.com>
	<561E4E83.4090502@oracle.com>
	<20151020140535.GG15817@ehelin.jrpg.bea.com>
Message-ID: <565C4B78.8010603@oracle.com>



On 2015-10-20 16:05, Erik Helin wrote:
> On 2015-10-14, Magnus Ihse Bursie wrote:
>> On 2015-10-09 14:09, Erik Helin wrote:
>>> Hi all,
>>>
>>> this patch adds a new configure variable: --with-test-jobs. The new
>>> variable configures how many tests jobs we run concurrently (aka the
>>> -concurrency flag to JTReg). Today --with-jobs is passed as the
>>> -concurrency flag to JTReg which most likely is too big for most
>>> systems with many cores.
>>>
>>> For hotspot, the only "supported" configuration for running the jtreg
>>> tests is with -concurrency:1. However, most machines will run the tests
>>> successfully with more concurrency, but I used a default of 1. For the JDK
>>> tests I kept --with-jobs as the default concurrency since I want to keep
>>> the old behaviour.
>>>
>>> Enhancement:
>>> https://bugs.openjdk.java.net/browse/JDK-8139272
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8139272/webrev.00/
>> Hi Erik,
>>
>> Your patch looks basically sound.
> Thanks for reviewing!
>
>> A few comments:
>>
>> * It would be good if you could add a comment somewhere, perhaps in the new
>> function in build-performance.m4, that "0" test jobs means "let the test
>> system use the default".
> Fixed.
>
>> * You should add TEST_JOBS to the list of INIT_CONTROL_VARIABLES in
>> InitSupport.gmk, to stop make from complaining on it.
> Fixed.
>
>> * Also, it would be great if you updated the help message in Help.gmk to
>> include TEST_JOBS.
> Fixed.
>
> Please see new webrevs:
> - Incremental:
>    http://cr.openjdk.java.net/~ehelin/8139272/webrev.00-01/
> - Full:
>    http://cr.openjdk.java.net/~ehelin/8139272/webrev.01/
>
> Thanks,
> Erik
Hi Erik,

Sorry for the delay in responding to this. Your fix looks good to me now!

/Magnus

>
>> /Magnus


From neugens.limasoftware at gmail.com  Thu Nov 26 20:32:58 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 26 Nov 2015 21:32:58 +0100
Subject: Silence warnings with new GCC
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41ED2893@DEWDFEMB12A.global.corp.sap>
References: <5657403E.6060906@redhat.com>
	<4295855A5C1DE049A61835A1887419CC41ED2893@DEWDFEMB12A.global.corp.sap>
Message-ID: <CAGUMyaQHJOJP4k0JeeWppN+=mvzAxqddFgdDrgvi_BTTBv79AQ@mail.gmail.com>

2015-11-26 20:37 GMT+01:00 Lindenmaier, Goetz <goetz.lindenmaier at sap.com>:
> Hi Andrew,
>
> I know about this problem ... I guess a change of mine causes these warnings.
> While I found a row of good fixes, these with ShouldNotReachHere are annoying.
>
> What you propose has been discussed in April: 8065585: Change ShouldNotReachHere() to never return.
> I didn't follow the discussion all to the end, but it wasn't done for some reason.
> Also, I think, one can overrule ShoudlNotReachHere() with -XX:SuppressError=...

FYI, I believe the full thread is this:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017990.html

Cheers,
Mario

> Best regards,
>   Goetz.
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
> Sent: Thursday, November 26, 2015 6:24 PM
> To: build-dev <build-dev at openjdk.java.net>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
> Subject: Silence warnings with new GCC
>
> I've been getting a lot of warnings such as
>
> warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> which error out with -Werror.  Almost all of them are bogus.  They are
> typically of the form
>
>     unsigned size;
>
>     if (i->get(26, 26)) { // float
>       switch(i->get(31, 30)) {
>       case 0b10:
>         size = 2; break;
>       case 0b01:
>         size = 1; break;
>       case 0b00:
>         size = 0; break;
>       default:
>         ShouldNotReachHere();
>       }
>     } else {
>       size = i->get(31, 31);
>     }
>
> The problem here is that GCC does not know that ShouldNotReachHere()
> should be treated as an unreachable statement.
>
> The patch here fixes it.  I'd rather do this than add pointless assignments
> all over the place.  Thoughts?  Opinions?
>
> Thanks,
>
> Andrew.
>
>
>
> diff --git a/src/share/vm/utilities/debug.hpp b/src/share/vm/utilities/debug.hpp
> --- a/src/share/vm/utilities/debug.hpp
> +++ b/src/share/vm/utilities/debug.hpp
> @@ -172,16 +172,24 @@
>    BREAKPOINT;                                                                     \
>  } while (0)
>
> +#ifdef __GNUC__
> +#  define UNREACHABLE __builtin_unreachable()
> +#else
> +#  define UNREACHABLE do { } while (0)
> +#endif
> +
>  #define ShouldNotReachHere()                                                      \
>  do {                                                                              \
>    report_should_not_reach_here(__FILE__, __LINE__);                               \
>    BREAKPOINT;                                                                     \
> +  UNREACHABLE;                                                                    \
>  } while (0)
>
>  #define Unimplemented()                                                           \
>  do {                                                                              \
>    report_unimplemented(__FILE__, __LINE__);                                       \
>    BREAKPOINT;                                                                     \
> +  UNREACHABLE;                                                                    \
>  } while (0)
>
>  #define Untested(msg)



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From vladimir.x.ivanov at oracle.com  Thu Nov 26 12:32:50 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 26 Nov 2015 15:32:50 +0300
Subject: Accessing parameters from a methodHandle
In-Reply-To: <10807D32-55BA-4462-A5A4-52D6B621C025@gmail.com>
References: <10807D32-55BA-4462-A5A4-52D6B621C025@gmail.com>
Message-ID: <5656FBF2.7070309@oracle.com>

Manas,

Can you elaborate what problem are you trying to solve?

It sounds like you want to iterate over all parameters of a compiled 
method in C2.

methodHandle is a Handle for Method* which an internal representation of 
a Java method. It doesn't provide any way to extract actual argument 
representation during compilation.

During parsing you can use GraphKit::method(), ciMethod::arg_size(), and 
GraphKit::argument(int i) to operate on arguments of a method being 
parsed. See opto/library_call.cpp for examples.

Best regards,
Vladimir Ivanov

(BCC: hotspot-dev at openjdk.java.net)

On 11/26/15 3:22 PM, Manas Thakur wrote:
> Hello all,
>
> I would like to know how to access the parameter nodes (in sequence) from a methodHandle. I could find that in ?opto/parse1.cpp?, ?ParmNodes? are constructed by determining the ?arg_size?. However, this variable doesn?t match the actual number of parameters passed to the corresponding Java method. Any suggestions?
>
> Regards,
> Manas
>

From jon.masamitsu at oracle.com  Mon Nov 30 17:00:41 2015
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 30 Nov 2015 09:00:41 -0800
Subject: Fwd: Re: Request for Review (s) - 8133023: ParallelGCThreads is
	not calculated correctly
In-Reply-To: <56566A62.4030902@oracle.com>
References: <565631DC.1010800@oracle.com> <56563B4D.3030301@oracle.com>
	<56566A62.4030902@oracle.com>
Message-ID: <565C80B9.5070202@oracle.com>



On 11/25/2015 06:11 PM, David Holmes wrote:
> Hi Jon,
>
> We already have VM_Version::early_initialize() that can/should be used 
> for this if possible.

David,

Thanks for looking at this.  I tried to use early_initialize() but found
that I needed to add empty early_initialize() methods for nearly
all the platforms. The code I wanted to move was in os_solaris.cpp
(from the os_init() to the early_initialize()), which made me add an
early_initialize() for solaris x86 which seemed to require I add
an early_initialize() to vm_version_x86.hpp which lead me to
add empty early_initialize()  for all the x86 platforms.

You can look at my first attempt at

http://cr.openjdk.java.net/~jmasa/8133023/webrev.01/

Jon
>
> Thanks,
> David
>
> On 26/11/2015 8:50 AM, Jon Masamitsu wrote:
>> Widening the review request.  This fixed changed the order
>> of some VM initialization for solaris-sparc with hopefully
>> the minimum change for other platforms.
>>
>> Thanks.
>>
>> Jon
>>
>> -------- Forwarded Message --------
>> Subject:     Re: Request for Review (s) - 8133023: ParallelGCThreads is
>> not calculated correctly
>> Date:     Wed, 25 Nov 2015 14:10:36 -0800
>> From:     Jon Masamitsu <jon.masamitsu at oracle.com>
>> Organization:     Oracle Corporation
>> To:     hotspot-gc-dev at openjdk.java.net
>>
>>
>>
>> I have a new fix for this bug.  My previous fix broke solaris-x86 (I
>> had not defined an early_initialize() for x86).  This fix is slightly
>> smaller and has the virtue of moving the required initialization
>> closer to where it is used.
>>
>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.03/index.html
>>
>> Testing: JPRT build on all platforms, checked by hand that the correct
>> number
>> of GC worker threads are created on later Niagara platforms.
>>
>> Thanks.
>>
>> Jon
>>
>> On 11/12/2015 1:31 PM, Jon Masamitsu wrote:
>>> GC calls VM_Version::calc_parallel_worker_threads() to determine
>>> the number of GC threads to create.  On Sparc it checks for newer
>>> Niagara hardware to decide the proper scaling of the GC threads with
>>> the hardware threads. calc_parallel_worker_threads() was being called
>>> before enough information was gathered to determine the Sparc hardware.
>>>
>>> Moved the gathering of information needed to earlier in the JVM
>>> initialization.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8133023/webrev.00/
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8133023
>>>
>>> Thanks.
>>>
>>> Jon
>>
>>
>>


From coleen.phillimore at oracle.com  Mon Nov 30 17:12:14 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Nov 2015 12:12:14 -0500
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <56583C2C.6040508@oracle.com>
References: <56557936.3070109@oracle.com> <5655CA09.6020001@oracle.com>
	<56583C2C.6040508@oracle.com>
Message-ID: <565C836E.7040108@oracle.com>


This change seems fine (if you haven't already pushed) and seems better 
than my making the only the compare function public.  I think the 
compiler complained because the compare function here:

  284   DIR_Chunk* match = _all_chunks->insert_sorted<DIR_Chunk::compare>(ns);


Wasn't in the scope of the DebugInformationRecorder function.  Which is 
probably a bug in the Solaris C++ compiler that you should file, since 
none of the other compilers complain.

Coleen


On 11/27/15 6:19 AM, Erik Joelsson wrote:
> You were correct, it didn't work when I built with "make 
> INCLUDE_JMVCI=false". Here is a new webrev where that part is fixed:
>
> http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>
> (I accidentally overwrote the old one)
>
> It changes the other accesses to _offset to offset().
>
> Regarding why the patch works, Tom, could you please fill in here?
>
> /Erik
>
> On 2015-11-25 15:47, Coleen Phillimore wrote:
>>
>> I don't think this change will compile with INCLUDE_JVMCI off either.
>> Coleen
>>
>> On 11/25/15 4:02 AM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> The following new build failure has appeared in the hotspot build 
>>> when using the proposed new compiler version on Solaris, SS12u4.
>>>
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>> line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&, 
>>> DIR_Chunk*const&) is not accessible from 
>>> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>> line 281: Where: While instantiating 
>>> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>>>
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>> line 281: Where: Instantiated from non-template code.
>>>
>>> Tom Rodriguez provided a patch and I have verified that it solves 
>>> the issue. Since this is blocking us upgrading compilers on Solaris, 
>>> I am taking the liberty of posting it for review so we may get this 
>>> resolved quickly.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>>
>>> /Erik
>>
>


From tom.rodriguez at oracle.com  Mon Nov 30 17:44:17 2015
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Mon, 30 Nov 2015 09:44:17 -0800
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <56583C2C.6040508@oracle.com>
References: <56557936.3070109@oracle.com> <5655CA09.6020001@oracle.com>
	<56583C2C.6040508@oracle.com>
Message-ID: <9E36BD50-6333-4713-9678-F036DA4C5630@oracle.com>


> On Nov 27, 2015, at 3:19 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> You were correct, it didn't work when I built with "make INCLUDE_JMVCI=false". Here is a new webrev where that part is fixed:
> 
> http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
> 
> (I accidentally overwrote the old one)
> 
> It changes the other accesses to _offset to offset().
> 
> Regarding why the patch works, Tom, could you please fill in here?

I?m not sure what you?re asking.  I only tested the JVMCI build so I missed the other usage.  I agree it seems like a bug that the Solaris compiler doesn?t like the previous version of the code, but the fix makes it use normal access controls so I think it?s better anyway.

tom

> 
> /Erik
> 
> On 2015-11-25 15:47, Coleen Phillimore wrote:
>> 
>> I don't think this change will compile with INCLUDE_JVMCI off either.
>> Coleen
>> 
>> On 11/25/15 4:02 AM, Erik Joelsson wrote:
>>> Hello,
>>> 
>>> The following new build failure has appeared in the hotspot build when using the proposed new compiler version on Solaris, SS12u4.
>>> 
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", line 281: Error: static DIR_Chunk::compare(DIR_Chunk*const&, DIR_Chunk*const&) is not accessible from GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", line 281: Where: While instantiating "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", line 281: Where: Instantiated from non-template code.
>>> 
>>> Tom Rodriguez provided a patch and I have verified that it solves the issue. Since this is blocking us upgrading compilers on Solaris, I am taking the liberty of posting it for review so we may get this resolved quickly.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>> 
>>> /Erik
>> 
> 


From asmundak at google.com  Mon Nov 30 18:13:26 2015
From: asmundak at google.com (Alexander Smundak)
Date: Mon, 30 Nov 2015 10:13:26 -0800
Subject: RFR JDK-8141491: Unaligned memory access in Bits.c
Message-ID: <CAHQ51u4=4z3qEiXaVV0EuiK_2CnoaX-HMHhej_+nMFg_Yaxt5w@mail.gmail.com>

On Wed, Nov 25, 2015 at 2:52 PM,  <hotspot-dev-request at openjdk.java.net> wrote:
> Have you looked anything at the performance of the generated code?
No. I looked at the emitted code, saw 'MOVQDU' instruction being used
(it was 'MOVQDA' before that resulted in alignment error), and concluded
 that the compiler knows what it's doing :-)
> It would be interesting to understand what type of performance you see with
> your patch.
If you have specific benchmark in mind, I am willing to run it.

Sasha

From vladimir.kozlov at oracle.com  Mon Nov 30 21:06:14 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 30 Nov 2015 13:06:14 -0800
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <565C836E.7040108@oracle.com>
References: <56557936.3070109@oracle.com> <5655CA09.6020001@oracle.com>
	<56583C2C.6040508@oracle.com> <565C836E.7040108@oracle.com>
Message-ID: <565CBA46.3030905@oracle.com>

Looks fine to me too. I can push the fix into hs-comp for you, if you want. Or it should be hs-rt?

Thanks,
Vladimir

On 11/30/15 9:12 AM, Coleen Phillimore wrote:
>
> This change seems fine (if you haven't already pushed) and seems better than my making the only the compare function
> public.  I think the compiler complained because the compare function here:
>
>   284   DIR_Chunk* match = _all_chunks->insert_sorted<DIR_Chunk::compare>(ns);
>
>
> Wasn't in the scope of the DebugInformationRecorder function.  Which is probably a bug in the Solaris C++ compiler that
> you should file, since none of the other compilers complain.
>
> Coleen
>
>
> On 11/27/15 6:19 AM, Erik Joelsson wrote:
>> You were correct, it didn't work when I built with "make INCLUDE_JMVCI=false". Here is a new webrev where that part is
>> fixed:
>>
>> http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>
>> (I accidentally overwrote the old one)
>>
>> It changes the other accesses to _offset to offset().
>>
>> Regarding why the patch works, Tom, could you please fill in here?
>>
>> /Erik
>>
>> On 2015-11-25 15:47, Coleen Phillimore wrote:
>>>
>>> I don't think this change will compile with INCLUDE_JVMCI off either.
>>> Coleen
>>>
>>> On 11/25/15 4:02 AM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> The following new build failure has appeared in the hotspot build when using the proposed new compiler version on
>>>> Solaris, SS12u4.
>>>>
>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", line 281: Error: static
>>>> DIR_Chunk::compare(DIR_Chunk*const&, DIR_Chunk*const&) is not accessible from
>>>> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&).
>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", line 281: Where: While instantiating
>>>> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)".
>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", line 281: Where: Instantiated from
>>>> non-template code.
>>>>
>>>> Tom Rodriguez provided a patch and I have verified that it solves the issue. Since this is blocking us upgrading
>>>> compilers on Solaris, I am taking the liberty of posting it for review so we may get this resolved quickly.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>>>
>>>> /Erik
>>>
>>
>

From coleen.phillimore at oracle.com  Mon Nov 30 21:43:04 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Nov 2015 16:43:04 -0500
Subject: RFR: JDK-8142333: Build failure in debugInfoRec.cpp with SS12u4
In-Reply-To: <565CBA46.3030905@oracle.com>
References: <56557936.3070109@oracle.com> <5655CA09.6020001@oracle.com>
	<56583C2C.6040508@oracle.com> <565C836E.7040108@oracle.com>
	<565CBA46.3030905@oracle.com>
Message-ID: <565CC2E8.5050709@oracle.com>



On 11/30/15 4:06 PM, Vladimir Kozlov wrote:
> Looks fine to me too. I can push the fix into hs-comp for you, if you 
> want. Or it should be hs-rt?

hs-comp is fine.  I ran into it doing something I'm not doing anymore :)

Coleen
>
> Thanks,
> Vladimir
>
> On 11/30/15 9:12 AM, Coleen Phillimore wrote:
>>
>> This change seems fine (if you haven't already pushed) and seems 
>> better than my making the only the compare function
>> public.  I think the compiler complained because the compare function 
>> here:
>>
>>   284   DIR_Chunk* match = 
>> _all_chunks->insert_sorted<DIR_Chunk::compare>(ns);
>>
>>
>> Wasn't in the scope of the DebugInformationRecorder function. Which 
>> is probably a bug in the Solaris C++ compiler that
>> you should file, since none of the other compilers complain.
>>
>> Coleen
>>
>>
>> On 11/27/15 6:19 AM, Erik Joelsson wrote:
>>> You were correct, it didn't work when I built with "make 
>>> INCLUDE_JMVCI=false". Here is a new webrev where that part is
>>> fixed:
>>>
>>> http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>>
>>> (I accidentally overwrote the old one)
>>>
>>> It changes the other accesses to _offset to offset().
>>>
>>> Regarding why the patch works, Tom, could you please fill in here?
>>>
>>> /Erik
>>>
>>> On 2015-11-25 15:47, Coleen Phillimore wrote:
>>>>
>>>> I don't think this change will compile with INCLUDE_JVMCI off either.
>>>> Coleen
>>>>
>>>> On 11/25/15 4:02 AM, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> The following new build failure has appeared in the hotspot build 
>>>>> when using the proposed new compiler version on
>>>>> Solaris, SS12u4.
>>>>>
>>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>>>> line 281: Error: static
>>>>> DIR_Chunk::compare(DIR_Chunk*const&, DIR_Chunk*const&) is not 
>>>>> accessible from
>>>>> GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&). 
>>>>>
>>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>>>> line 281: Where: While instantiating
>>>>> "GrowableArray<DIR_Chunk*>::insert_sorted<&DIR_Chunk::compare>(DIR_Chunk*&)". 
>>>>>
>>>>> "/opt/jprt/jprtadm/erik/jdk9-dev/hotspot/src/share/vm/code/debugInfoRec.cpp", 
>>>>> line 281: Where: Instantiated from
>>>>> non-template code.
>>>>>
>>>>> Tom Rodriguez provided a patch and I have verified that it solves 
>>>>> the issue. Since this is blocking us upgrading
>>>>> compilers on Solaris, I am taking the liberty of posting it for 
>>>>> review so we may get this resolved quickly.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142333
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142333/webrev.hotspot.01/
>>>>>
>>>>> /Erik
>>>>
>>>
>>


From gerard.ziemski at oracle.com  Mon Nov 30 22:39:44 2015
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Mon, 30 Nov 2015 16:39:44 -0600
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <56563D89.5090902@oracle.com>
References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com>
	<56547635.9060808@oracle.com> <56563D89.5090902@oracle.com>
Message-ID: <565CD030.50507@oracle.com>

hi Sangheon,

I found a few issues:

-------------
#1 An already existing issue, but there are many candidate flags that could have their types changed to "size_t", that 
currently are defined as some other type (usually uintx) ex: ParGCDesiredObjsFromOverflowList, CMSOldPLABReactivityFactor


-------------
#2 Why isn't the range here "range(min_intx, max_intx)" ?

src/share/vm/runtime/globals.hpp lines:
1985   manageable(intx, CMSWaitDuration, 2000,                                   \
1986           "Time in milliseconds that CMS thread waits for young GC")        \
1987           range(min_jint, max_jint)                                         \


-------------
#3 The min in the range must not be 0, because we use it as denominator:

size_t survivor_size = size / InitialSurvivorRatio;

so the range should be range(1, max_uintx) ?

Lines:
src/share/vm/runtime/globals.hpp lines:
2347           "Initial ratio of young generation/survivor space size")          \
2348           range(0, max_uintx)                                               \


-------------
#4 The min in the range must not be 0, because we do:

   if (_cur_file_num > NumberOfGCLogFiles - 1) _cur_file_num = 0;

so the range should be range(1, max_uintx) ?

src/share/vm/runtime/globals.hpp lines:
2599   product(uintx, NumberOfGCLogFiles, 0,                                     \
2600           "Number of gclog files in rotation "                              \
2601           "(default: 0, no rotation)")                                      \
2602           range(0, max_uintx)                                               \


-------------
#5 TLABRefillWasteFraction should have a constraint moved from Arguments::check_vm_args_consistency to 
src/share/vm/runtime/commandLineFlagConstraintsGC ?

// Check the consistency of vm_init_args
bool Arguments::check_vm_args_consistency() {
   // Method for adding checks for flag consistency.
   // The intent is to warn the user of all possible conflicts,
   // before returning an error.
   // Note: Needs platform-dependent factoring.
   bool status = true;

   if (TLABRefillWasteFraction == 0) {
     jio_fprintf(defaultStream::error_stream(),
                 "TLABRefillWasteFraction should be a denominator, "
                 "not " SIZE_FORMAT "\n",
                 TLABRefillWasteFraction);
     status = false;
   }

src/share/vm/runtime/globals.hpp lines:
3419   product(uintx, TLABRefillWasteFraction,    64,                            \
3420           "Maximum TLAB waste at a refill (internal fragmentation)")        \
3421           range(1, max_juint)                                               \


-------------
#6 We multiply NewSizeThreadIncrease later, like

   size_t thread_increase_size = threads_count * NewSizeThreadIncrease;

so the range's max needs to be smaller than max_uintx by some large enough constant (MAX thread count?)

src/share/vm/runtime/globals.hpp lines:
3437   product_pd(size_t, NewSizeThreadIncrease,                                 \
3438           "Additional size added to desired new generation size per "       \
3439           "non-daemon thread (in bytes)")                                   \
3440           range(0, max_uintx)                                               \


cheers

On 11/25/2015 05:00 PM, sangheon.kim wrote:
> Hi all,
>
> Here's updated webrev which reflects changes by "JDK-8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a
> subset of tested values specified for a flag".
>
> The only updated file is test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java.
> Changed from "allOptionsAsMap.remove("flag name")" to "excludeTestMaxRange("flag name")".
>
> FYI,  JDK-8143038 introduced separated exclude methods of "excludeTest, excludeTestMaxRange and excludeTestMinRange".
>
> webrev:
> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01/
> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01_to_00/
>
> Thanks,
> Sangheon
>
>
> On 11/24/2015 06:37 AM, sangheon.kim wrote:
>> Hi Dmitry,
>>
>> Thank you for the review!
>> Sure I will update my patch related to your enhancement.
>>
>> Thanks,
>> Sangheon
>>
>>
>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
>>> Hi Sangheon,
>>>
>>> Looks good to me! Thank you for fixing that. I hope that enhancement will be pushed today(currently in JPRT queue),
>>> so please update your patch after that!
>>>
>>> Thanks,
>>> Dmitry
>>>
>>> On 21.11.2015 0:04, sangheon.kim wrote:
>>>> Hi all,
>>>>
>>>> Could I have a couple of reviews for this change to add explicit 'range' for flags?
>>>>
>>>> Previously, we added 'range' when it is needed to avoid assert/crash but now explicit 'range' are needed for all flags.
>>>> All flags should have 'range' or 'constraint' at least.
>>>>
>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>>>> Testing: JPRT, RBT (hotspot/test/:hotspot_all,testlist,noncolo.testlist --add-tonga-keyword quick),
>>>> hotspot/test/runtime/CommandLine for embedded
>>>>
>>>> * Summary
>>>> 1. Added 3 new constraint functions.
>>>>    1) HeapBaseMinAddress: Added to avoid an overflow after align up and this flag makes hang up without constraint
>>>> function. (newly added as a part of GC work)
>>>>    2) TLABWasteIncrement: Without this constraint function we don't have problems (even many GCs happen). But added
>>>> to avoid an overflow at ThreadLocalAllocBuffer::record_slow_allocation(). There are also separate CR for this
>>>> overflow ( JDK-8143352 ).
>>>>    3) NUMAInterleaveGranularity: Added to avoid an overflow after align up.
>>>>
>>>> 2. Some flags have narrower range than their type.
>>>>    1) Here's the reason why some flags should have different range. (same order from globals.hpp)
>>>> {flag type} {flag name}: (range), {comment}
>>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(), max_uintx), there is a comment at
>>>> numa_interleaving_init() that this flag should be larger than vm_allocation_granularity().
>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as used for multiplication
>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function which has 'long' type input parameter.
>>>> uintx PausePadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> uintx PromotedPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> uintx SurvivorPadding: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag is divided by 100 I assume this is percentage.
>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>>>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>>>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch* flags should have same upper limit and looking
>>>> at their related codes 'max_jint' seems appropriate ( no problem with 'max_jint' during testing). However, as
>>>> Prefetch::read/write() needs 'intx', 'intx' also seems good but we have to fix some codes (maybe including generated
>>>> codes).
>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which has 'unsigned int' type input parameter.
>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint variable and used 'for loop' which has uint
>>>> increment. i.e. for (uint i=0; i<ProcessDistributionStride; i++)
>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 'increment for loop()' as max value and the increment
>>>> is uint.
>>>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for loop()' as max value and the increment is uint.
>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value of uint type function and for division. i.e.
>>>> uint GCTLABConfiguration::tlab_refill_waste_limit()() { return TLABRefillWasteFraction; }
>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only use " if (a !=0, >0, >1)".
>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only use " if (a !=0, >0, >1)".
>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use " if (a !=0, >0)".
>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned int'
>>>>
>>>> (g1_globals.hpp)
>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int) type variable.
>>>>
>>>> 3. Excluded flags from TestOptionsWithRanges.java
>>>> 1) Memory and thread related flags: tests for these flags will consume too many resources from the system.
>>>> 2) VMThreadStackSize: range work for this flag is not included in this patch but I faced OOME several times, so
>>>> excluded.
>>>>
>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] TestOptionsWithRanges: allow excluding only a subset of
>>>> tested values specified for a flag) next time.
>>>>
>>>> Thanks,
>>>> Sangheon
>>>>
>>>>
>>>>
>>>
>>
>
>

From tom.benson at oracle.com  Mon Nov 30 22:46:05 2015
From: tom.benson at oracle.com (Tom Benson)
Date: Mon, 30 Nov 2015 17:46:05 -0500
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
Message-ID: <565CD1AD.90902@oracle.com>

Hi Sangheon,

I think there's a problem with using the same routine to check HeapBaseMinAddress as is used for checking heap size in commandLineFlagConstraintsGC.cpp. I tried running this, to make sure I understood what it was trying to do. When I specified something too large for HeapBaseMinAddress, the check reported that the value must be greater than or equal to maximum value N.  Re-running with that (still huge) value, I get a fatal internal error out of virtualspace.cpp.  (In the debug version, an assertion in universe.cpp triggers before reaching this point).  EG:

$ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff -version
HeapBaseMinAddress (18446744073709551615) must be less than or equal to aligned maximum value (18446744073642442752)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (virtualspace.cpp:456), pid=10359, tid=10360
#  guarantee(size + noaccess_prefix_size(alignment) <= OopEncodingHeapMax) failed: can not allocate compressed oop heap for this size
#

Perhaps you should check only the alignment in the constraint code, without checking the range, because I'm not sure you have the final heap size at that point.  Then maybe the heap reservation code should report this as a non-internal error, at the point where the assertion occurs, if the user specified a base address.

There's also an extraneous single quote in commandLineFlagConstraintsGC.cpp in the comment at line 510.

Tom


Date: Tue, 24 Nov 2015 06:37:41 -0800
From: "sangheon.kim"<sangheon.kim at oracle.com>
To: Dmitry Dmitriev<dmitry.dmitriev at oracle.com>,
	"hotspot-dev at openjdk.java.net Developers"
	<hotspot-dev at openjdk.java.net>
Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be
	implemented
Message-ID:<56547635.9060808 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Dmitry,

Thank you for the review!
Sure I will update my patch related to your enhancement.

Thanks,
Sangheon


On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:

> Hi Sangheon,
>
> Looks good to me! Thank you for fixing that. I hope that enhancement
> will be pushed today(currently in JPRT queue), so please update your
> patch after that!
>
> Thanks,
> Dmitry
>
> On 21.11.2015 0:04, sangheon.kim wrote:
>> Hi all,
>>
>> Could I have a couple of reviews for this change to add explicit
>> 'range' for flags?
>>
>> Previously, we added 'range' when it is needed to avoid assert/crash
>> but now explicit 'range' are needed for all flags.
>> All flags should have 'range' or 'constraint' at least.
>>
>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341
>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>> Testing: JPRT, RBT
>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist
>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for
>> embedded
>>
>> * Summary
>> 1. Added 3 new constraint functions.
>>     1) HeapBaseMinAddress: Added to avoid an overflow after align up
>> and this flag makes hang up without constraint function. (newly added
>> as a part of GC work)
>>     2) TLABWasteIncrement: Without this constraint function we don't
>> have problems (even many GCs happen). But added to avoid an overflow
>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also
>> separate CR for this overflow ( JDK-8143352 ).
>>     3) NUMAInterleaveGranularity: Added to avoid an overflow after
>> align up.
>>
>> 2. Some flags have narrower range than their type.
>>     1) Here's the reason why some flags should have different range.
>> (same order from globals.hpp)
>> {flag type} {flag name}: (range), {comment}
>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(),
>> max_uintx), there is a comment at numa_interleaving_init() that this
>> flag should be larger than vm_allocation_granularity().
>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as
>> used for multiplication
>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which
>> has 'unsigned int' type input parameter.
>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which
>> has 'unsigned int' type input parameter.
>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function
>> which has 'long' type input parameter.
>> uintx PausePadding: (0, max_juint), used to set a function which has
>> 'unsigned int' type input parameter.
>> uintx PromotedPadding: (0, max_juint), used to set a function which
>> has 'unsigned int' type input parameter.
>> uintx SurvivorPadding: (0, max_juint), used to set a function which
>> has 'unsigned int' type input parameter.
>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag
>> is divided by 100 I assume this is percentage.
>> uintx GCTimeRatio: (0, max_juint), used to set a function which has
>> 'unsigned int' type input parameter.
>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch*
>> flags should have same upper limit and looking at their related codes
>> 'max_jint' seems appropriate ( no problem with 'max_jint' during
>> testing). However, as Prefetch::read/write() needs 'intx', 'intx'
>> also seems good but we have to fix some codes (maybe including
>> generated codes).
>> uintx CPUForCMSThread: (0, max_juint), used to set a function which
>> has 'unsigned int' type input parameter.
>> uintx ProcessDistributionStride: (0, max_juint), used to set uint
>> variable and used 'for loop' which has uint increment. i.e. for (uint
>> i=0; i<ProcessDistributionStride; i++)
>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at
>> 'increment for loop()' as max value and the increment is uint.
>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for
>> loop()' as max value and the increment is uint.
>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value
>> of uint type function and for division. i.e. uint
>> GCTLABConfiguration::tlab_refill_waste_limit()() { return
>> TLABRefillWasteFraction; }
>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only
>> use " if (a !=0, >0, >1)".
>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only
>> use " if (a !=0, >0, >1)".
>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use
>> " if (a !=0, >0)".
>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned
>> int'
>>
>> (g1_globals.hpp)
>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int)
>> type variable.
>>
>> 3. Excluded flags from TestOptionsWithRanges.java
>> 1) Memory and thread related flags: tests for these flags will
>> consume too many resources from the system.
>> 2) VMThreadStackSize: range work for this flag is not included in
>> this patch but I faced OOME several times, so excluded.
>>
>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG]
>> TestOptionsWithRanges: allow excluding only a subset of tested values
>> specified for a flag) next time.
>>
>> Thanks,
>> Sangheon
>>
>>
>>

From sangheon.kim at oracle.com  Mon Nov 30 23:41:25 2015
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 30 Nov 2015 15:41:25 -0800
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <565CD030.50507@oracle.com>
References: <564F8ADB.9090008@oracle.com> <5654747A.3000908@oracle.com>
	<56547635.9060808@oracle.com> <56563D89.5090902@oracle.com>
	<565CD030.50507@oracle.com>
Message-ID: <565CDEA5.10603@oracle.com>

Hi Gerard,

Thank you for reviewing this!
I was waiting your review.

On 11/30/2015 02:39 PM, gerard ziemski wrote:
> hi Sangheon,
>
> I found a few issues:
>
> -------------
> #1 An already existing issue, but there are many candidate flags that 
> could have their types changed to "size_t", that currently are defined 
> as some other type (usually uintx) ex: 
> ParGCDesiredObjsFromOverflowList, CMSOldPLABReactivityFactor
Right.
There are some other cases like you mentioned.
Let me address this issue separately.

>
>
> -------------
> #2 Why isn't the range here "range(min_intx, max_intx)" ?
>
> src/share/vm/runtime/globals.hpp lines:
> 1985   manageable(intx, CMSWaitDuration, 
> 2000,                                   \
> 1986           "Time in milliseconds that CMS thread waits for young 
> GC")        \
> 1987           range(min_jint, 
> max_jint)                                         \
As I shortly explained my RFR, this value is used to set a function 
which has an input parameter of 'long' type.
And I think it would be a good reason to narrow its range.

>
>
> -------------
> #3 The min in the range must not be 0, because we use it as denominator:
>
> size_t survivor_size = size / InitialSurvivorRatio;
>
> so the range should be range(1, max_uintx) ?
When we reach to that line, InitialSurvivorRatio will be changed to '3' 
for min by line 58. generationSizer.cpp
GenerationSizer::initialize_flags() {
..
if (InitialSurvivorRatio < 3) {
..
}

>
> Lines:
> src/share/vm/runtime/globals.hpp lines:
> 2347           "Initial ratio of young generation/survivor space 
> size")          \
> 2348           range(0, 
> max_uintx)                                               \
>
>
> -------------
> #4 The min in the range must not be 0, because we do:
>
>   if (_cur_file_num > NumberOfGCLogFiles - 1) _cur_file_num = 0;
>
> so the range should be range(1, max_uintx) ?
NumberOfGCLogFiles==0 is default value for disabling rotation.
And before reaching that line, we already filtered NumberOfGCLogFiles <= 
1 cases.

>
> src/share/vm/runtime/globals.hpp lines:
> 2599   product(uintx, NumberOfGCLogFiles, 
> 0,                                     \
> 2600           "Number of gclog files in rotation 
> "                              \
> 2601           "(default: 0, no 
> rotation)")                                      \
> 2602           range(0, 
> max_uintx)                                               \
>
>
> -------------
> #5 TLABRefillWasteFraction should have a constraint moved from 
> Arguments::check_vm_args_consistency to 
> src/share/vm/runtime/commandLineFlagConstraintsGC ?
>
> // Check the consistency of vm_init_args
> bool Arguments::check_vm_args_consistency() {
>   // Method for adding checks for flag consistency.
>   // The intent is to warn the user of all possible conflicts,
>   // before returning an error.
>   // Note: Needs platform-dependent factoring.
>   bool status = true;
>
>   if (TLABRefillWasteFraction == 0) {
>     jio_fprintf(defaultStream::error_stream(),
>                 "TLABRefillWasteFraction should be a denominator, "
>                 "not " SIZE_FORMAT "\n",
>                 TLABRefillWasteFraction);
>     status = false;
>   }
Right. We have more cases including this.
David Lindholm filed a CR for moving JDK-8133649.

>
> src/share/vm/runtime/globals.hpp lines:
> 3419   product(uintx, TLABRefillWasteFraction, 
> 64,                            \
> 3420           "Maximum TLAB waste at a refill (internal 
> fragmentation)")        \
> 3421           range(1, 
> max_juint)                                               \
>
>
> -------------
> #6 We multiply NewSizeThreadIncrease later, like
>
>   size_t thread_increase_size = threads_count * NewSizeThreadIncrease;
>
> so the range's max needs to be smaller than max_uintx by some large 
> enough constant (MAX thread count?)
You are right.
We don't have any problem without constraint function but it would be 
better to have one.
I will post next webrev soon with this constraint function.

Thanks,
Sangheon


>
> src/share/vm/runtime/globals.hpp lines:
> 3437   product_pd(size_t, 
> NewSizeThreadIncrease,                                 \
> 3438           "Additional size added to desired new generation size 
> per "       \
> 3439           "non-daemon thread (in 
> bytes)")                                   \
> 3440           range(0, 
> max_uintx)                                               \
>
>
> cheers
>
> On 11/25/2015 05:00 PM, sangheon.kim wrote:
>> Hi all,
>>
>> Here's updated webrev which reflects changes by "JDK-8143038: 
>> [TESTBUG] TestOptionsWithRanges: allow excluding only a
>> subset of tested values specified for a flag".
>>
>> The only updated file is 
>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java.
>> Changed from "allOptionsAsMap.remove("flag name")" to 
>> "excludeTestMaxRange("flag name")".
>>
>> FYI,  JDK-8143038 introduced separated exclude methods of 
>> "excludeTest, excludeTestMaxRange and excludeTestMinRange".
>>
>> webrev:
>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01/
>> http://cr.openjdk.java.net/~sangheki/8142341/webrev.01_to_00/
>>
>> Thanks,
>> Sangheon
>>
>>
>> On 11/24/2015 06:37 AM, sangheon.kim wrote:
>>> Hi Dmitry,
>>>
>>> Thank you for the review!
>>> Sure I will update my patch related to your enhancement.
>>>
>>> Thanks,
>>> Sangheon
>>>
>>>
>>> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
>>>> Hi Sangheon,
>>>>
>>>> Looks good to me! Thank you for fixing that. I hope that 
>>>> enhancement will be pushed today(currently in JPRT queue),
>>>> so please update your patch after that!
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>> On 21.11.2015 0:04, sangheon.kim wrote:
>>>>> Hi all,
>>>>>
>>>>> Could I have a couple of reviews for this change to add explicit 
>>>>> 'range' for flags?
>>>>>
>>>>> Previously, we added 'range' when it is needed to avoid 
>>>>> assert/crash but now explicit 'range' are needed for all flags.
>>>>> All flags should have 'range' or 'constraint' at least.
>>>>>
>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8142341
>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>>>>> Testing: JPRT, RBT 
>>>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist 
>>>>> --add-tonga-keyword quick),
>>>>> hotspot/test/runtime/CommandLine for embedded
>>>>>
>>>>> * Summary
>>>>> 1. Added 3 new constraint functions.
>>>>>    1) HeapBaseMinAddress: Added to avoid an overflow after align 
>>>>> up and this flag makes hang up without constraint
>>>>> function. (newly added as a part of GC work)
>>>>>    2) TLABWasteIncrement: Without this constraint function we 
>>>>> don't have problems (even many GCs happen). But added
>>>>> to avoid an overflow at 
>>>>> ThreadLocalAllocBuffer::record_slow_allocation(). There are also 
>>>>> separate CR for this
>>>>> overflow ( JDK-8143352 ).
>>>>>    3) NUMAInterleaveGranularity: Added to avoid an overflow after 
>>>>> align up.
>>>>>
>>>>> 2. Some flags have narrower range than their type.
>>>>>    1) Here's the reason why some flags should have different 
>>>>> range. (same order from globals.hpp)
>>>>> {flag type} {flag name}: (range), {comment}
>>>>> size_t NUMAInterleaveGranularity: 
>>>>> (os::vm_allocation_granularity(), max_uintx), there is a comment at
>>>>> numa_interleaving_init() that this flag should be larger than 
>>>>> vm_allocation_granularity().
>>>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero 
>>>>> as used for multiplication
>>>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which 
>>>>> has 'unsigned int' type input parameter.
>>>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function 
>>>>> which has 'unsigned int' type input parameter.
>>>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function 
>>>>> which has 'long' type input parameter.
>>>>> uintx PausePadding: (0, max_juint), used to set a function which 
>>>>> has 'unsigned int' type input parameter.
>>>>> uintx PromotedPadding: (0, max_juint), used to set a function 
>>>>> which has 'unsigned int' type input parameter.
>>>>> uintx SurvivorPadding: (0, max_juint), used to set a function 
>>>>> which has 'unsigned int' type input parameter.
>>>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this 
>>>>> flag is divided by 100 I assume this is percentage.
>>>>> uintx GCTimeRatio: (0, max_juint), used to set a function which 
>>>>> has 'unsigned int' type input parameter.
>>>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>>>>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>>>>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 
>>>>> Prefetch* flags should have same upper limit and looking
>>>>> at their related codes 'max_jint' seems appropriate ( no problem 
>>>>> with 'max_jint' during testing). However, as
>>>>> Prefetch::read/write() needs 'intx', 'intx' also seems good but we 
>>>>> have to fix some codes (maybe including generated
>>>>> codes).
>>>>> uintx CPUForCMSThread: (0, max_juint), used to set a function 
>>>>> which has 'unsigned int' type input parameter.
>>>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint 
>>>>> variable and used 'for loop' which has uint
>>>>> increment. i.e. for (uint i=0; i<ProcessDistributionStride; i++)
>>>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at 
>>>>> 'increment for loop()' as max value and the increment
>>>>> is uint.
>>>>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for 
>>>>> loop()' as max value and the increment is uint.
>>>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return 
>>>>> value of uint type function and for division. i.e.
>>>>> uint GCTLABConfiguration::tlab_refill_waste_limit()() { return 
>>>>> TLABRefillWasteFraction; }
>>>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>>>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we 
>>>>> only use " if (a !=0, >0, >1)".
>>>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we 
>>>>> only use " if (a !=0, >0, >1)".
>>>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only 
>>>>> use " if (a !=0, >0)".
>>>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 
>>>>> 'unsigned int'
>>>>>
>>>>> (g1_globals.hpp)
>>>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set 
>>>>> (int) type variable.
>>>>>
>>>>> 3. Excluded flags from TestOptionsWithRanges.java
>>>>> 1) Memory and thread related flags: tests for these flags will 
>>>>> consume too many resources from the system.
>>>>> 2) VMThreadStackSize: range work for this flag is not included in 
>>>>> this patch but I faced OOME several times, so
>>>>> excluded.
>>>>>
>>>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG] 
>>>>> TestOptionsWithRanges: allow excluding only a subset of
>>>>> tested values specified for a flag) next time.
>>>>>
>>>>> Thanks,
>>>>> Sangheon
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>


From sangheon.kim at oracle.com  Mon Nov 30 23:51:23 2015
From: sangheon.kim at oracle.com (sangheon.kim)
Date: Mon, 30 Nov 2015 15:51:23 -0800
Subject: RFR(S): 8142341: GC: current flags need ranges to be implemented
In-Reply-To: <565CD1AD.90902@oracle.com>
References: <565CD1AD.90902@oracle.com>
Message-ID: <565CE0FB.8000303@oracle.com>

Hi Tom,

Thank you for reviewing this!

On 11/30/2015 02:46 PM, Tom Benson wrote:
> Hi Sangheon,
>
> I think there's a problem with using the same routine to check 
> HeapBaseMinAddress as is used for checking heap size in 
> commandLineFlagConstraintsGC.cpp. I tried running this, to make sure I 
> understood what it was trying to do. When I specified something too 
> large for HeapBaseMinAddress, the check reported that the value must 
> be greater than or equal to maximum value N. 
Sorry Tom, I can't understand.
Currently we print the error message if its value is too large like, 
"must be less than or equal to aligned maximum value (xxx)".
Do you mean it should be 'address' instead of 'value'?
I thought it is okay.

> Re-running with that (still huge) value, I get a fatal internal error 
> out of virtualspace.cpp.  (In the debug version, an assertion in 
> universe.cpp triggers before reaching this point).  EG:
I am trying to reproduce this assert but I can't. Do you have more 
information to reproduce this?
I did -version and running GCOld to trigger GC.

java -XX:HeapBaseMinAddress=18446744073642442752 -version
java -XX:HeapBaseMinAddress=18446744073642442752 GCOld 20 200 10 100 5000

Thanks,
Sangheon


>
> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=0xffffffffffffffff -version
> HeapBaseMinAddress (18446744073709551615) must be less than or equal 
> to aligned maximum value (18446744073642442752)
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
>
> $ $JAVA_HOME/bin/java -XX:HeapBaseMinAddress=18446744073642442752 
> -version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (virtualspace.cpp:456), pid=10359, tid=10360
> #  guarantee(size + noaccess_prefix_size(alignment) <= 
> OopEncodingHeapMax) failed: can not allocate compressed oop heap for 
> this size
> #
>
> Perhaps you should check only the alignment in the constraint code, 
> without checking the range, because I'm not sure you have the final 
> heap size at that point.  Then maybe the heap reservation code should 
> report this as a non-internal error, at the point where the assertion 
> occurs, if the user specified a base address.
>
> There's also an extraneous single quote in 
> commandLineFlagConstraintsGC.cpp in the comment at line 510.
>
> Tom
>
>
> Date: Tue, 24 Nov 2015 06:37:41 -0800
> From: "sangheon.kim"<sangheon.kim at oracle.com>
> To: Dmitry Dmitriev<dmitry.dmitriev at oracle.com>,
>     "hotspot-dev at openjdk.java.net Developers"
>     <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8142341: GC: current flags need ranges to be
>     implemented
> Message-ID:<56547635.9060808 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Dmitry,
>
> Thank you for the review!
> Sure I will update my patch related to your enhancement.
>
> Thanks,
> Sangheon
>
>
> On 11/24/2015 06:30 AM, Dmitry Dmitriev wrote:
>
>> Hi Sangheon,
>>
>> Looks good to me! Thank you for fixing that. I hope that enhancement
>> will be pushed today(currently in JPRT queue), so please update your
>> patch after that!
>>
>> Thanks,
>> Dmitry
>>
>> On 21.11.2015 0:04, sangheon.kim wrote:
>>> Hi all,
>>>
>>> Could I have a couple of reviews for this change to add explicit
>>> 'range' for flags?
>>>
>>> Previously, we added 'range' when it is needed to avoid assert/crash
>>> but now explicit 'range' are needed for all flags.
>>> All flags should have 'range' or 'constraint' at least.
>>>
>>> CR:https://bugs.openjdk.java.net/browse/JDK-8142341
>>> Webrev:http://cr.openjdk.java.net/~sangheki/8142341/webrev.00
>>> Testing: JPRT, RBT
>>> (hotspot/test/:hotspot_all,testlist,noncolo.testlist
>>> --add-tonga-keyword quick), hotspot/test/runtime/CommandLine for
>>> embedded
>>>
>>> * Summary
>>> 1. Added 3 new constraint functions.
>>>     1) HeapBaseMinAddress: Added to avoid an overflow after align up
>>> and this flag makes hang up without constraint function. (newly added
>>> as a part of GC work)
>>>     2) TLABWasteIncrement: Without this constraint function we don't
>>> have problems (even many GCs happen). But added to avoid an overflow
>>> at ThreadLocalAllocBuffer::record_slow_allocation(). There are also
>>> separate CR for this overflow ( JDK-8143352 ).
>>>     3) NUMAInterleaveGranularity: Added to avoid an overflow after
>>> align up.
>>>
>>> 2. Some flags have narrower range than their type.
>>>     1) Here's the reason why some flags should have different range.
>>> (same order from globals.hpp)
>>> {flag type} {flag name}: (range), {comment}
>>> size_t NUMAInterleaveGranularity: (os::vm_allocation_granularity(),
>>> max_uintx), there is a comment at numa_interleaving_init() that this
>>> flag should be larger than vm_allocation_granularity().
>>> uintx CMSOldPLABReactivityFactor: (1,max_uintx), couldn't be zero as
>>> used for multiplication
>>> uintx CMS_FLSPadding: (0, max_juint), used to set a function which
>>> has 'unsigned int' type input parameter.
>>> uintx CMS_SweepPadding: (0, max_juint), used to set a function which
>>> has 'unsigned int' type input parameter.
>>> intx CMSWaitDuration: (min_jint, max_jint), used to set a function
>>> which has 'long' type input parameter.
>>> uintx PausePadding: (0, max_juint), used to set a function which has
>>> 'unsigned int' type input parameter.
>>> uintx PromotedPadding: (0, max_juint), used to set a function which
>>> has 'unsigned int' type input parameter.
>>> uintx SurvivorPadding: (0, max_juint), used to set a function which
>>> has 'unsigned int' type input parameter.
>>> uintx AdaptiveSizePolicyCollectionCostMargin: (0, 100), as this flag
>>> is divided by 100 I assume this is percentage.
>>> uintx GCTimeRatio: (0, max_juint), used to set a function which has
>>> 'unsigned int' type input parameter.
>>> intx PrefetchCopyIntervalInBytes: (-1, max_jint)
>>> intx PrefetchScanIntervalInBytes:  (-1, max_jint)
>>> intx PrefetchFieldsAhead:  (-1, max_jint), I think these 3 Prefetch*
>>> flags should have same upper limit and looking at their related codes
>>> 'max_jint' seems appropriate ( no problem with 'max_jint' during
>>> testing). However, as Prefetch::read/write() needs 'intx', 'intx'
>>> also seems good but we have to fix some codes (maybe including
>>> generated codes).
>>> uintx CPUForCMSThread: (0, max_juint), used to set a function which
>>> has 'unsigned int' type input parameter.
>>> uintx ProcessDistributionStride: (0, max_juint), used to set uint
>>> variable and used 'for loop' which has uint increment. i.e. for (uint
>>> i=0; i<ProcessDistributionStride; i++)
>>> uintx CMSCoordinatorYieldSleepCount: (0, max_juint), used at
>>> 'increment for loop()' as max value and the increment is uint.
>>> uintx CMSYieldSleepCount: (0, max_juint),  used at 'increment for
>>> loop()' as max value and the increment is uint.
>>> uintx TLABRefillWasteFraction: (1, max_juint), used as a return value
>>> of uint type function and for division. i.e. uint
>>> GCTLABConfiguration::tlab_refill_waste_limit()() { return
>>> TLABRefillWasteFraction; }
>>> uintx TLABWasteIncrement: (0, max_jint), type cast to (int)
>>> intx PrintCMSStatistics: (0,2), flag to choose print mode and we only
>>> use " if (a !=0, >0, >1)".
>>> intx PrintFLSStatistics: (0,2), flag to choose print mode and we only
>>> use " if (a !=0, >0, >1)".
>>> intx PrintFLSCensus: (0,1), flag to choose print mode and we only use
>>> " if (a !=0, >0)".
>>> uintx GCDrainStackTargetSize: (0, max_juint), type cast to 'unsigned
>>> int'
>>>
>>> (g1_globals.hpp)
>>> intx G1ConcRefinementThresholdStep: (0, max_jint), used to set (int)
>>> type variable.
>>>
>>> 3. Excluded flags from TestOptionsWithRanges.java
>>> 1) Memory and thread related flags: tests for these flags will
>>> consume too many resources from the system.
>>> 2) VMThreadStackSize: range work for this flag is not included in
>>> this patch but I faced OOME several times, so excluded.
>>>
>>> * I will reflect Dmitry's enhancement(JDK-8143038: [TESTBUG]
>>> TestOptionsWithRanges: allow excluding only a subset of tested values
>>> specified for a flag) next time.
>>>
>>> Thanks,
>>> Sangheon
>>>
>>>
>>>