From david.holmes at oracle.com Tue Aug 1 06:59:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Aug 2017 16:59:47 +1000 Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro In-Reply-To: <4d2f3964b0924ffa897074759e508653@sap.com> References: <4d2f3964b0924ffa897074759e508653@sap.com> Message-ID: Hi Matthias, Back from a long vacation ... Baesken, Matthias matthias.baesken at sap.com wrote on Thu Jul 13 12:18:56 UTC 2017: >> Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. >> I can help you integrate the changes after they are reviewed. > > Thanks for your feedback ! > > I created a bug : > > https://bugs.openjdk.java.net/browse/JDK-8184323 > > > and a webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/ For the record it was a deliberate choice to not sprinkle INCLUDE_CDS ifdefs all through the shared code. INCLUDE_CDS exists only to support the minimal VM for which we wanted to exclude complete subsystems not every individual line of code that might relate to an unsupported function. The fact UseSharedSpaces is false in the MinimalVM was sufficient to guard the remaining logic. Cheers, David From david.holmes at oracle.com Tue Aug 1 07:04:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Aug 2017 17:04:23 +1000 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: Message-ID: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> Bernd Eckenfels ecki at zusammenkunft.net wrote on Mon Jul 17 21:57:39 UTC 2017 > > For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones). > > I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however. > > Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP? The VM already handles cpusets (as used by cgroups and thus Docker) on Linux, as their use is exposed through the sched_getaffinity API. David > Gruss > Bernd From david.holmes at oracle.com Tue Aug 1 07:33:14 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Aug 2017 17:33:14 +1000 Subject: RFR(xs): 8184339: Thread::current_or_null() should not assert if Posix TLS is not yet initialized In-Reply-To: References: Message-ID: <284b9d57-a6b1-6e1c-732d-d01262d07e29@oracle.com> Hi Thomas, Back from vacation ... I appreciate the effort to fix this problem, however ... :) > Thomas St?fe thomas.stuefe at gmail.com > Mon Jul 17 07:00:01 UTC 2017 > Hi all, > > may I please have reviews + a sponsor for the following fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8184339 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8184339-Thread-current-or-null-shall-not-assert/webrev.00/webrev/ > > The problem is caused by the fact that Posix TLS cannot be used before it > is initialized. It is initialized in os::init(). If we use Posix TLS (eg > via Thread::current()) before, we assert. It is used now (since JDK-8183925 > ) before os::init() (see > callstack in bug description). ... those kind of initialization order changes are exactly what the assertion was supposed to detect! It can be dangerous to use various VM facilities "too soon" in the initialization sequence. The change in JDK-8183925 needs a close examination IMHO before relaxing this guard. :( > There are two functions, Thread::current() and Thread::current_or_null(). > The latter should not assert if Posix TLS is not yet available but return > NULL instead. This is what callers expect: this function is safe to call, > but it might not return a valid Thread*. Yes but because the current thread has not yet been set, not because we're executing the code well before any VM initialization has been performed! :( > Note that this issue currently only comes up at AIX, because AIX is the > only platform using Posix TLS for Thread::current() - all other platforms > use Compiler-based TLS (__thread variables). It's also used in the mobile-dev project IIRC, but they don't have JDK-8183925 applied. > However, we want to keep the Posix TLS code path alive, so this may also > affect other platforms. There have been compiler bugs in the past (e.g. gcc > + glibc) leading to errors when using compiler-based TLS, so it is good to > have a reliable fallback. Definitely! Cheers, David > Thanks, > > Thomas > From thomas.stuefe at gmail.com Tue Aug 1 13:40:54 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Aug 2017 15:40:54 +0200 Subject: RFR(xs): 8184339: Thread::current_or_null() should not assert if Posix TLS is not yet initialized In-Reply-To: <284b9d57-a6b1-6e1c-732d-d01262d07e29@oracle.com> References: <284b9d57-a6b1-6e1c-732d-d01262d07e29@oracle.com> Message-ID: Hi David! On Tue, Aug 1, 2017 at 9:33 AM, David Holmes wrote: > Hi Thomas, > > Back from vacation ... > > I appreciate the effort to fix this problem, however ... :) > > Thomas St?fe thomas.stuefe at gmail.com >> Mon Jul 17 07:00:01 UTC 2017 >> Hi all, >> >> may I please have reviews + a sponsor for the following fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8184339 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8184339-Thread-cu >> rrent-or-null-shall-not-assert/webrev.00/webrev/ >> >> The problem is caused by the fact that Posix TLS cannot be used before it >> is initialized. It is initialized in os::init(). If we use Posix TLS (eg >> via Thread::current()) before, we assert. It is used now (since >> JDK-8183925 >> ) before os::init() >> (see >> callstack in bug description). >> > > ... those kind of initialization order changes are exactly what the > assertion was supposed to detect! It can be dangerous to use various VM > facilities "too soon" in the initialization sequence. The change in > JDK-8183925 needs a close examination IMHO before relaxing this guard. :( I agree with you that using a VM facility "too soon" is the core of this problem. But I am not sure that just forbidding that is a practical solution, because these pre-init-uses have the tendency to creep up on you: There are many functions in the VM which very basic and which are used without regard for initialization sequence. os::malloc() is one example, Thread::current_or_null() is another. It is difficult to find pre-init uses with tests, especially if we have code paths which are only executed on one platform, like in this case. In this case, on AIX, we had two problems, Thread::current_or_null() was asserting, then it was again used in error handling, asserting again, which lead to an annoying recursion difficult to entangle (on AIX with its less-than-optimal debugger at least). To prevent this from happening, one would have to guard every "Thread::current_or_null()" use with something like "if ThreadLocalStorage.is_initialized()". But I think a more practical solution would be to keep these basic functions safe to be called anytime. And maybe make this a clear part of the interface, and test this too. Similar to the Posix list of functions safe to be called in signal handlers. Thread::current_or_null() could return NULL before initialization, os::malloc() could refrain from using NMT before its initialization ran, and NMT in turn could tolerate "free/realloc-without-malloc" cases... (Note that this discussion feels similar to the "CanUseSafeFetch()" issue we had two years ago, and we did not agree then either :) > > There are two functions, Thread::current() and Thread::current_or_null(). >> The latter should not assert if Posix TLS is not yet available but return >> NULL instead. This is what callers expect: this function is safe to call, >> but it might not return a valid Thread*. >> > > Yes but because the current thread has not yet been set, not because we're > executing the code well before any VM initialization has been performed! :( I think anyone using Thread::current_or_null() is aware that the thread pointer returned may be NULL and is prepared to handle it, but does not care for the reason it is NULL. Like, in error handling. > Note that this issue currently only comes up at AIX, because AIX is the >> only platform using Posix TLS for Thread::current() - all other platforms >> use Compiler-based TLS (__thread variables). >> > > It's also used in the mobile-dev project IIRC, but they don't have > JDK-8183925 applied. > > However, we want to keep the Posix TLS code path alive, so this may also >> affect other platforms. There have been compiler bugs in the past (e.g. >> gcc >> + glibc) leading to errors when using compiler-based TLS, so it is good to >> have a reliable fallback. >> > > Definitely! > > Good to be in agreement here! Kind Regards, Thomas Cheers, > David > > Thanks, >> >> Thomas >> >> From coleen.phillimore at oracle.com Tue Aug 1 14:18:12 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 10:18:12 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() Message-ID: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> Summary: Counting number of instanceKlass code didn't work. A late code review change caused this regression. Tested with internal NSK mlvm tests with -XX:-TieredCompilation -XX:CompileThreshold=100 including the one where I reproduced the failure overnight. open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8185590 Thanks, Coleen From shade at redhat.com Tue Aug 1 14:23:58 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Aug 2017 16:23:58 +0200 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> Message-ID: <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: > Summary: Counting number of instanceKlass code didn't work. > > A late code review change caused this regression. Tested with internal NSK mlvm tests with > -XX:-TieredCompilation -XX:CompileThreshold=100 including the one where I reproduced the failure > overnight. > > open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev Hm, so now that the loop variable is _conditionally_ incremented, what guarantees the loop termination? Thanks, -Aleksey From coleen.phillimore at oracle.com Tue Aug 1 14:32:55 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 10:32:55 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> Message-ID: On 8/1/17 10:23 AM, Aleksey Shipilev wrote: > On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >> Summary: Counting number of instanceKlass code didn't work. >> >> A late code review change caused this regression. Tested with internal NSK mlvm tests with >> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one where I reproduced the failure >> overnight. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev > Hm, so now that the loop variable is _conditionally_ incremented, what guarantees the loop termination? The fact that number_of_classes can't be zero so something has to be returned? I had trouble coming up with something better. If you have a good idea, I'll change it. thanks! Coleen > > Thanks, > -Aleksey > From coleen.phillimore at oracle.com Tue Aug 1 14:33:32 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 10:33:32 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> Message-ID: I forgot to thank you for looking at it so quickly. Thank you! Coleen On 8/1/17 10:23 AM, Aleksey Shipilev wrote: > On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >> Summary: Counting number of instanceKlass code didn't work. >> >> A late code review change caused this regression. Tested with internal NSK mlvm tests with >> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one where I reproduced the failure >> overnight. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev > Hm, so now that the loop variable is _conditionally_ incremented, what guarantees the loop termination? > > Thanks, > -Aleksey > From zgu at redhat.com Tue Aug 1 14:45:19 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Aug 2017 10:45:19 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> Message-ID: <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> How about setup a marker before entering the loop, ensure the loop won't come back to initial entry? #ifdef ASSERT Klass* starting_class_entry = _current_class_entry; #endif for (int i = 0; i < max_classes; ) { .... ASSERT(_current_class_entry != starting_class_entry, ....) } Thanks, -Zhengyu On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: > > > On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>> Summary: Counting number of instanceKlass code didn't work. >>> >>> A late code review change caused this regression. Tested with >>> internal NSK mlvm tests with >>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>> where I reproduced the failure >>> overnight. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >> Hm, so now that the loop variable is _conditionally_ incremented, what >> guarantees the loop termination? > > The fact that number_of_classes can't be zero so something has to be > returned? > > I had trouble coming up with something better. If you have a good idea, > I'll change it. > > thanks! > Coleen >> >> Thanks, >> -Aleksey >> > From shade at redhat.com Tue Aug 1 15:01:54 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Aug 2017 17:01:54 +0200 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: <6d83ef4a-321c-bfb9-5417-015fc0ba7d62@redhat.com> On 08/01/2017 04:45 PM, Zhengyu Gu wrote: > On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>> Summary: Counting number of instanceKlass code didn't work. >>>> >>>> A late code review change caused this regression. Tested with >>>> internal NSK mlvm tests with >>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>> where I reproduced the failure >>>> overnight. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>> Hm, so now that the loop variable is _conditionally_ incremented, what >>> guarantees the loop termination? >> >> The fact that number_of_classes can't be zero so something has to be >> returned? I see! Your current patch seems to be the lesser evil, comparing to alternatives I have. I would probably add the circuit breaker suggested by Zhengyu to be extra safe, but that looks not that critical. Looks good! -Aleksey From coleen.phillimore at oracle.com Tue Aug 1 15:03:00 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 11:03:00 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: On 8/1/17 10:45 AM, Zhengyu Gu wrote: > How about setup a marker before entering the loop, ensure the loop > won't come back to initial entry? It's ok for the loop to get back to the initial entry though.... if there are less classes than the count in compilationPolicy. Coleen > > #ifdef ASSERT > Klass* starting_class_entry = _current_class_entry; > #endif > > for (int i = 0; i < max_classes; ) { > > .... > > ASSERT(_current_class_entry != starting_class_entry, ....) > } > > Thanks, > > -Zhengyu > > > On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>> Summary: Counting number of instanceKlass code didn't work. >>>> >>>> A late code review change caused this regression. Tested with >>>> internal NSK mlvm tests with >>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>> where I reproduced the failure >>>> overnight. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>> Hm, so now that the loop variable is _conditionally_ incremented, what >>> guarantees the loop termination? >> >> The fact that number_of_classes can't be zero so something has to be >> returned? >> >> I had trouble coming up with something better. If you have a good idea, >> I'll change it. >> >> thanks! >> Coleen >>> >>> Thanks, >>> -Aleksey >>> >> From coleen.phillimore at oracle.com Tue Aug 1 15:57:38 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 11:57:38 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: On 8/1/17 11:03 AM, coleen.phillimore at oracle.com wrote: > > > On 8/1/17 10:45 AM, Zhengyu Gu wrote: >> How about setup a marker before entering the loop, ensure the loop >> won't come back to initial entry? > > It's ok for the loop to get back to the initial entry though.... if > there are less classes than the count in compilationPolicy. Sorry, I'm wrong about this. Maybe this makes sense too, but not as an assert but as a terminating condition. Coleen > > Coleen >> >> #ifdef ASSERT >> Klass* starting_class_entry = _current_class_entry; >> #endif >> >> for (int i = 0; i < max_classes; ) { >> >> .... >> >> ASSERT(_current_class_entry != starting_class_entry, ....) >> } >> >> Thanks, >> >> -Zhengyu >> >> >> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Counting number of instanceKlass code didn't work. >>>>> >>>>> A late code review change caused this regression. Tested with >>>>> internal NSK mlvm tests with >>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>>> where I reproduced the failure >>>>> overnight. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>>> Hm, so now that the loop variable is _conditionally_ incremented, what >>>> guarantees the loop termination? >>> >>> The fact that number_of_classes can't be zero so something has to be >>> returned? >>> >>> I had trouble coming up with something better. If you have a good >>> idea, >>> I'll change it. >>> >>> thanks! >>> Coleen >>>> >>>> Thanks, >>>> -Aleksey >>>> >>> > From zgu at redhat.com Tue Aug 1 16:08:44 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Aug 2017 12:08:44 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: On 08/01/2017 11:57 AM, coleen.phillimore at oracle.com wrote: > > > On 8/1/17 11:03 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/1/17 10:45 AM, Zhengyu Gu wrote: >>> How about setup a marker before entering the loop, ensure the loop >>> won't come back to initial entry? >> >> It's ok for the loop to get back to the initial entry though.... if >> there are less classes than the count in compilationPolicy. > > Sorry, I'm wrong about this. Maybe this makes sense too, but not as an > assert but as a terminating condition. If InstanceKlass::number_of_instance_classes() counting is right, then the two termination conditions are equivalent, right? Thanks, -Zhengyu > > Coleen > >> >> Coleen >>> >>> #ifdef ASSERT >>> Klass* starting_class_entry = _current_class_entry; >>> #endif >>> >>> for (int i = 0; i < max_classes; ) { >>> >>> .... >>> >>> ASSERT(_current_class_entry != starting_class_entry, ....) >>> } >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Counting number of instanceKlass code didn't work. >>>>>> >>>>>> A late code review change caused this regression. Tested with >>>>>> internal NSK mlvm tests with >>>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>>>> where I reproduced the failure >>>>>> overnight. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>>>> Hm, so now that the loop variable is _conditionally_ incremented, what >>>>> guarantees the loop termination? >>>> >>>> The fact that number_of_classes can't be zero so something has to be >>>> returned? >>>> >>>> I had trouble coming up with something better. If you have a good >>>> idea, >>>> I'll change it. >>>> >>>> thanks! >>>> Coleen >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>>> >> > From kirk at kodewerk.com Tue Aug 1 16:08:42 2017 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 1 Aug 2017 18:08:42 +0200 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> References: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> Message-ID: <1765F9DF-F08D-41E3-8C87-A78ECDDD0BD8@kodewerk.com> Hi, Is is wise to standardize the JVM around the container du jour? Kind regards, Kirk Pepperdine > On Aug 1, 2017, at 9:04 AM, David Holmes wrote: > > Bernd Eckenfels ecki at zusammenkunft.net wrote on Mon Jul 17 21:57:39 UTC 2017 >> For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones). >> I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however. >> Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP? > > The VM already handles cpusets (as used by cgroups and thus Docker) on Linux, as their use is exposed through the sched_getaffinity API. > > David > >> Gruss >> Bernd > From coleen.phillimore at oracle.com Tue Aug 1 16:53:54 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 12:53:54 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: On 8/1/17 12:08 PM, Zhengyu Gu wrote: > > > On 08/01/2017 11:57 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/1/17 11:03 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/1/17 10:45 AM, Zhengyu Gu wrote: >>>> How about setup a marker before entering the loop, ensure the loop >>>> won't come back to initial entry? >>> >>> It's ok for the loop to get back to the initial entry though.... if >>> there are less classes than the count in compilationPolicy. >> >> Sorry, I'm wrong about this. Maybe this makes sense too, but not as an >> assert but as a terminating condition. > > If InstanceKlass::number_of_instance_classes() counting is right, then > the two termination conditions are equivalent, right? Yes. Is this a code review? thanks, Coleen > > Thanks, > > -Zhengyu > >> >> Coleen >> >>> >>> Coleen >>>> >>>> #ifdef ASSERT >>>> Klass* starting_class_entry = _current_class_entry; >>>> #endif >>>> >>>> for (int i = 0; i < max_classes; ) { >>>> >>>> .... >>>> >>>> ASSERT(_current_class_entry != starting_class_entry, ....) >>>> } >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>>>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Counting number of instanceKlass code didn't work. >>>>>>> >>>>>>> A late code review change caused this regression. Tested with >>>>>>> internal NSK mlvm tests with >>>>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>>>>> where I reproduced the failure >>>>>>> overnight. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>>>>> Hm, so now that the loop variable is _conditionally_ incremented, >>>>>> what >>>>>> guarantees the loop termination? >>>>> >>>>> The fact that number_of_classes can't be zero so something has to be >>>>> returned? >>>>> >>>>> I had trouble coming up with something better. If you have a good >>>>> idea, >>>>> I'll change it. >>>>> >>>>> thanks! >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> -Aleksey >>>>>> >>>>> >>> >> From coleen.phillimore at oracle.com Tue Aug 1 16:54:27 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 12:54:27 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <6d83ef4a-321c-bfb9-5417-015fc0ba7d62@redhat.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> <6d83ef4a-321c-bfb9-5417-015fc0ba7d62@redhat.com> Message-ID: <6a4254f0-6a0d-cf7b-b7cc-11053de693a2@oracle.com> On 8/1/17 11:01 AM, Aleksey Shipilev wrote: > On 08/01/2017 04:45 PM, Zhengyu Gu wrote: >> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >>> >>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Counting number of instanceKlass code didn't work. >>>>> >>>>> A late code review change caused this regression. Tested with >>>>> internal NSK mlvm tests with >>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>>> where I reproduced the failure >>>>> overnight. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>>> Hm, so now that the loop variable is _conditionally_ incremented, what >>>> guarantees the loop termination? >>> The fact that number_of_classes can't be zero so something has to be >>> returned? > I see! Your current patch seems to be the lesser evil, comparing to alternatives I have. I would > probably add the circuit breaker suggested by Zhengyu to be extra safe, but that looks not that > critical. Thanks, Aleksey! Coleen > > Looks good! > > -Aleksey > > From zgu at redhat.com Tue Aug 1 19:30:41 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Aug 2017 15:30:41 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: On 08/01/2017 12:53 PM, coleen.phillimore at oracle.com wrote: > > > On 8/1/17 12:08 PM, Zhengyu Gu wrote: >> >> >> On 08/01/2017 11:57 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/1/17 11:03 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 8/1/17 10:45 AM, Zhengyu Gu wrote: >>>>> How about setup a marker before entering the loop, ensure the loop >>>>> won't come back to initial entry? >>>> >>>> It's ok for the loop to get back to the initial entry though.... if >>>> there are less classes than the count in compilationPolicy. >>> >>> Sorry, I'm wrong about this. Maybe this makes sense too, but not as an >>> assert but as a terminating condition. >> >> If InstanceKlass::number_of_instance_classes() counting is right, then >> the two termination conditions are equivalent, right? > > Yes. Is this a code review? Reviewed. -Zhengyu > thanks, > Coleen > >> >> Thanks, >> >> -Zhengyu >> >>> >>> Coleen >>> >>>> >>>> Coleen >>>>> >>>>> #ifdef ASSERT >>>>> Klass* starting_class_entry = _current_class_entry; >>>>> #endif >>>>> >>>>> for (int i = 0; i < max_classes; ) { >>>>> >>>>> .... >>>>> >>>>> ASSERT(_current_class_entry != starting_class_entry, ....) >>>>> } >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>>>>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Counting number of instanceKlass code didn't work. >>>>>>>> >>>>>>>> A late code review change caused this regression. Tested with >>>>>>>> internal NSK mlvm tests with >>>>>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>>>>>> where I reproduced the failure >>>>>>>> overnight. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>>>>>> Hm, so now that the loop variable is _conditionally_ incremented, >>>>>>> what >>>>>>> guarantees the loop termination? >>>>>> >>>>>> The fact that number_of_classes can't be zero so something has to be >>>>>> returned? >>>>>> >>>>>> I had trouble coming up with something better. If you have a good >>>>>> idea, >>>>>> I'll change it. >>>>>> >>>>>> thanks! >>>>>> Coleen >>>>>>> >>>>>>> Thanks, >>>>>>> -Aleksey >>>>>>> >>>>>> >>>> >>> > From coleen.phillimore at oracle.com Tue Aug 1 19:43:18 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 15:43:18 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> <5ff9f11e-5bac-a6a9-adc1-fd7dde38d536@redhat.com> <0450f63c-d127-f457-451e-0fe924f27566@redhat.com> Message-ID: On 8/1/17 3:30 PM, Zhengyu Gu wrote: > > > On 08/01/2017 12:53 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/1/17 12:08 PM, Zhengyu Gu wrote: >>> >>> >>> On 08/01/2017 11:57 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 8/1/17 11:03 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 8/1/17 10:45 AM, Zhengyu Gu wrote: >>>>>> How about setup a marker before entering the loop, ensure the loop >>>>>> won't come back to initial entry? >>>>> >>>>> It's ok for the loop to get back to the initial entry though.... if >>>>> there are less classes than the count in compilationPolicy. >>>> >>>> Sorry, I'm wrong about this. Maybe this makes sense too, but not >>>> as an >>>> assert but as a terminating condition. >>> >>> If InstanceKlass::number_of_instance_classes() counting is right, then >>> the two termination conditions are equivalent, right? >> >> Yes. Is this a code review? > > Reviewed. Thank you! Coleen > > -Zhengyu > >> thanks, >> Coleen >> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>>> >>>> Coleen >>>> >>>>> >>>>> Coleen >>>>>> >>>>>> #ifdef ASSERT >>>>>> Klass* starting_class_entry = _current_class_entry; >>>>>> #endif >>>>>> >>>>>> for (int i = 0; i < max_classes; ) { >>>>>> >>>>>> .... >>>>>> >>>>>> ASSERT(_current_class_entry != starting_class_entry, ....) >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> >>>>>> On 08/01/2017 10:32 AM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> >>>>>>> On 8/1/17 10:23 AM, Aleksey Shipilev wrote: >>>>>>>> On 08/01/2017 04:18 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>> Summary: Counting number of instanceKlass code didn't work. >>>>>>>>> >>>>>>>>> A late code review change caused this regression. Tested with >>>>>>>>> internal NSK mlvm tests with >>>>>>>>> -XX:-TieredCompilation -XX:CompileThreshold=100 including the one >>>>>>>>> where I reproduced the failure >>>>>>>>> overnight. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >>>>>>>> Hm, so now that the loop variable is _conditionally_ incremented, >>>>>>>> what >>>>>>>> guarantees the loop termination? >>>>>>> >>>>>>> The fact that number_of_classes can't be zero so something has >>>>>>> to be >>>>>>> returned? >>>>>>> >>>>>>> I had trouble coming up with something better. If you have a good >>>>>>> idea, >>>>>>> I'll change it. >>>>>>> >>>>>>> thanks! >>>>>>> Coleen >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Aleksey >>>>>>>> >>>>>>> >>>>> >>>> >> From jiangli.zhou at oracle.com Tue Aug 1 19:43:31 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 1 Aug 2017 12:43:31 -0700 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> Message-ID: Hi Coleen, The logic is a bit tricky, but looks correct to me. Thanks, Jiangli > On Aug 1, 2017, at 7:18 AM, coleen.phillimore at oracle.com wrote: > > Summary: Counting number of instanceKlass code didn't work. > > A late code review change caused this regression. Tested with internal NSK mlvm tests with -XX:-TieredCompilation -XX:CompileThreshold=100 including the one where I reproduced the failure overnight. > > open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8185590 > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Aug 1 19:45:10 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 1 Aug 2017 15:45:10 -0400 Subject: RFR (S) 8185590: ShouldNotReachHere from ClassLoaderData::try_get_next_class() In-Reply-To: References: <38e11a9b-af37-8ac6-ac3d-4ab7e72fdf7b@oracle.com> Message-ID: On 8/1/17 3:43 PM, Jiangli Zhou wrote: > Hi Coleen, > > The logic is a bit tricky, but looks correct to me. Yes, it's really unfortunate. Thank you for the code review. Coleen > > Thanks, > Jiangli > >> On Aug 1, 2017, at 7:18 AM, coleen.phillimore at oracle.com wrote: >> >> Summary: Counting number of instanceKlass code didn't work. >> >> A late code review change caused this regression. Tested with internal NSK mlvm tests with -XX:-TieredCompilation -XX:CompileThreshold=100 including the one where I reproduced the failure overnight. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8185590.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8185590 >> >> Thanks, >> Coleen From david.holmes at oracle.com Tue Aug 1 21:40:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 07:40:28 +1000 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: <1765F9DF-F08D-41E3-8C87-A78ECDDD0BD8@kodewerk.com> References: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> <1765F9DF-F08D-41E3-8C87-A78ECDDD0BD8@kodewerk.com> Message-ID: <9012a573-e1fc-02ca-10e7-d67b3861fefe@oracle.com> Hi Kirk, On 2/08/2017 2:08 AM, Kirk Pepperdine wrote: > Hi, > > Is is wise to standardize the JVM around the container du jour? Not sure what you mean here. The use of sched_getaffinity doesn't relate to any container technology it is simply a Linux system API with which the cgroups facility has integrated to "do the right thing" when it comes to cpuset usage. For things like memory management cgroups is not integrated with the existing system APIs for memory queries so explicit cgroup mechanisms have to be used. I don't think cgroups would be classified as "the container du jour" given it is part of the Linux system. But we would not want to have to build in direct Docker-specific support, for example, but ultimately it comes down to what the user needs. If container technology X is important and the JVM must run well within it then we need to try and support that somehow. If technology X integrates with system APIs so they "do the right thing" then that is great. Otherwise we have no choice but to use whatever API is provided, while maintaining as much flexibility in the VM as possible. Cheers, David > Kind regards, > Kirk Pepperdine > > >> On Aug 1, 2017, at 9:04 AM, David Holmes wrote: >> >> Bernd Eckenfels ecki at zusammenkunft.net wrote on Mon Jul 17 21:57:39 UTC 2017 >>> For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones). >>> I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however. >>> Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP? >> >> The VM already handles cpusets (as used by cgroups and thus Docker) on Linux, as their use is exposed through the sched_getaffinity API. >> >> David >> >>> Gruss >>> Bernd >> > From david.holmes at oracle.com Wed Aug 2 03:35:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 13:35:46 +1000 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> Message-ID: Hi Kim, Good planning on Erik's part to go on vacation just as I have returned ;-) On 1/08/2017 4:18 AM, Kim Barrett wrote: >> On Jul 28, 2017, at 12:25 PM, Erik Osterlund wrote: >> >> Hi Andrew, >> >> In that case, feel free to propose a revised solution while I am gone. > > Erik has asked me to try to make progress on this while he's on > vacation, rather than possibly letting it sit until he gets back. Okay, while Erik is gone perhaps you can clarify a few things. As Andrew and Roman have expressed, I too find this: + template + inline static U cmpxchg(T exchange_value, volatile U* dest, V compare_value, cmpxchg_memory_order order); totally unintuitive and unappealing. I do not understand the rationale for this this at all. It does not make any sense to me to allow T, U and V to be different types (even if constrained). It has been stated that if we force them to all be the same there is some problem with literals and the need for casts, but I don't understand what that problem would be. I'm also unclear about these assertions: STATIC_ASSERT(sizeof(T) <= size_t(BytesPerWord)); // Does the machine support atomic wide accesses? as that is not a guarantee of atomic access support. It isn't always even a necessary condition; but it certainly isn't sufficient. The conversion from use of the j* types also seems an unnecessary disruption to the APIs. Bear in mind in many cases these functions are for operating on Java-level fields and so have Java types. Those java types are well defined (jint is signed 32-bit, jshort is signed 16-bit etc etc). If compilers had had broad support for the int8_t, int16_t, int32_t etc typedefs back in Java 5 then perhaps we would have used those instead of the j* aliases/synonyms. But changing it now seems disruptive and driven by personal preference IMHO. I don't understand methods like this: 75 template 76 inline static T specialized_xchg(T exchange_value, volatile T* dest) { 77 STATIC_ASSERT(Never::value); 78 return exchange_value; 79 } 80 is this a new form of ShouldNotReachHere() ?? ie these functions should always be overridden by each platform? I admit I'm not very fluent in template-ese. For example how does one read this, and what does it mean ?? typedef Conditional::value, PlatformAtomic, GeneralizedAtomic>::type AtomicImpl; And I'm still trying to get my head around the introduced "trait" stuff. (I hate pseudo-languages that can be written within other languages :( ). Thanks, David ----- > (This is just one of a large stack of patches Erik has prepared toward > the GC access interface that he's been talking about for a while. > Providing a solid base for that work is the underlying goal for > changing atomics.) I'm getting caught up on the discussion, and > looking at Erik's most recent proposal. I should have something more > concrete soon, possibly just agreeing with Erik's recent ideas, > possibly some alternative. I'm also open to suggestions? > > From david.holmes at oracle.com Wed Aug 2 04:00:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 14:00:20 +1000 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: <9012a573-e1fc-02ca-10e7-d67b3861fefe@oracle.com> References: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> <1765F9DF-F08D-41E3-8C87-A78ECDDD0BD8@kodewerk.com> <9012a573-e1fc-02ca-10e7-d67b3861fefe@oracle.com> Message-ID: Hi Bob, Reading about the proposed CPU limit support: --- number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. --- I don't think this is workable. In short CPU quotas/shares/periods can not be effectively used to "size" the number of threads you need to get the right "utilization" of CPU resources. If there are 10 cpus available but you only have a 50% share you effectively get 5 cpus at 100%, but that doesn't translate to needing 5 threads! If you only have 5 threads you can only use 5 cpus, but you will still only get 50% of the time on those 5 cpus - giving the effect of 2.5 cpus. IMHO only cpusets (the actual number of available processors) are relevant to sizing/configuring the VM itself, the libraries and even the application. Information about quotas/shares etc would be needed by application logic if it wanted to reason about its own performance characteristics (throughput, latency etc). Cheers, David From david.holmes at oracle.com Wed Aug 2 04:35:01 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 14:35:01 +1000 Subject: RFC: 8185062: os::is_MP() sometimes returns false Message-ID: https://bugs.openjdk.java.net/browse/JDK-8185062 Is it time to completely remove runtime optimizations aimed at uniprocessor systems ie. if (os::is_MP()) { x(); } just becomes: x(); ? Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would be a problem? As outlined in the "bug" report there are three basic options: 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container environments) 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP macros. 3. Assume the universe is MP and only allow MP to be built Cheers, David ----- From vladimir.kozlov at oracle.com Wed Aug 2 05:02:56 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 1 Aug 2017 22:02:56 -0700 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: I am fine to drop non_MP now (3.) if people are fine with it. Lets hear from our colleges who support other systems and give them build macros (2.) if needed. 1. choice regarding AssumeMP flag could be used in previous releases. And done per platform by converting flag to product_pd() if needed. Thanks, Vladimir On 8/1/17 9:35 PM, David Holmes wrote: > https://bugs.openjdk.java.net/browse/JDK-8185062 > > Is it time to completely remove runtime optimizations aimed at uniprocessor systems ie. > > if (os::is_MP()) { > x(); > } > > just becomes: > > x(); > > ? > > Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would be a > problem? > > As outlined in the "bug" report there are three basic options: > > 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container environments) > > 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP macros. > > 3. Assume the universe is MP and only allow MP to be built > > Cheers, > David > ----- From glaubitz at physik.fu-berlin.de Wed Aug 2 05:53:39 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 2 Aug 2017 07:53:39 +0200 Subject: RFR: Fix atomic_copy64 on PPC32 - was: Re: Debugging segmentation faults in the JVM on linux-powerpc In-Reply-To: References: <20170609131521.GE2477@physik.fu-berlin.de> <593AB105.5020303@linux.vnet.ibm.com> <6e2530d9-294c-7fd6-2117-178fcb295f1e@physik.fu-berlin.de> <0e758a35-fa4a-96d2-5ab4-14e04ff3c3de@physik.fu-berlin.de> <89c98506-3586-80a7-1058-41c86f391f3e@oracle.com> <6b65524c-ec36-bef7-b7cf-948ff2b3f03b@physik.fu-berlin.de> <1497268280.3582.11.camel@redhat.com> Message-ID: Hi! On 06/12/2017 03:23 PM, Andrew Haley wrote:> Ignore the SafeFetch problem; it's something else> > Let's concentrate on one thing at at a time. Andrew has found the problem and provided a patch to fix the issue. The problem for the crash is atomic_copy64 which is broken on PPC32. The inline-assembly is incorrect and does not actually transfer any data. The attached patch fixes the problem. Could some please review and apply it? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-inline-assembly-in-atomic_copy64-on-PPC32.patch Type: text/x-patch Size: 1062 bytes Desc: not available URL: From aph at redhat.com Wed Aug 2 08:31:48 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Aug 2017 09:31:48 +0100 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> Message-ID: <920b0165-92b2-0d22-45aa-2ccba3858d74@redhat.com> On 02/08/17 04:35, David Holmes wrote: > Hi Kim, > > Good planning on Erik's part to go on vacation just as I have returned ;-) > > On 1/08/2017 4:18 AM, Kim Barrett wrote: >>> On Jul 28, 2017, at 12:25 PM, Erik Osterlund wrote: >>> >>> In that case, feel free to propose a revised solution while I am gone. >> >> Erik has asked me to try to make progress on this while he's on >> vacation, rather than possibly letting it sit until he gets back. > > Okay, while Erik is gone perhaps you can clarify a few things. As Andrew > and Roman have expressed, I too find this: > > + template > + inline static U cmpxchg(T exchange_value, volatile U* dest, V > compare_value, cmpxchg_memory_order order); > > totally unintuitive and unappealing. I do not understand the rationale > for this this at all. It does not make any sense to me to allow T, U and > V to be different types (even if constrained). It has been stated that > if we force them to all be the same there is some problem with literals > and the need for casts, but I don't understand what that problem would be. A couple of examples would help: diff -r d207c56d5b5a src/share/vm/runtime/os.cpp --- a/src/share/vm/runtime/os.cpp Tue Jul 25 15:35:09 2017 +0100 +++ b/src/share/vm/runtime/os.cpp Wed Aug 02 09:24:30 2017 +0100 @@ -756,7 +756,7 @@ while (true) { unsigned int seed = _rand_seed; int rand = random_helper(seed); - if (Atomic::cmpxchg(rand, &_rand_seed, seed) == seed) { + if (Atomic::cmpxchg((unsigned)rand, &_rand_seed, seed) == seed) { return rand; } } diff -r d207c56d5b5a src/share/vm/runtime/thread.cpp --- a/src/share/vm/runtime/thread.cpp Tue Jul 25 15:35:09 2017 +0100 +++ b/src/share/vm/runtime/thread.cpp Wed Aug 02 09:24:30 2017 +0100 @@ -4741,7 +4741,7 @@ enum MuxBits { LOCKBIT = 1 }; void Thread::muxAcquire(volatile intptr_t * Lock, const char * LockName) { - intptr_t w = Atomic::cmpxchg(LOCKBIT, Lock, 0); + intptr_t w = Atomic::cmpxchg((intptr_t)LOCKBIT, Lock, (intptr_t)0); if (w == 0) return; if ((w & LOCKBIT) == 0 && Atomic::cmpxchg (w|LOCKBIT, Lock, w) == w) { return; There are eight such changes required in the HotSpot codebase. I strongly believe that these changes make the code better. They show exactly where types do not match. In the case of the random generator, they show that there is a type mismatch which is IMO probably wrong, and it wouldn't hurt to fix it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Aug 2 08:33:24 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Aug 2017 09:33:24 +0100 Subject: RFR: Fix atomic_copy64 on PPC32 - was: Re: Debugging segmentation faults in the JVM on linux-powerpc In-Reply-To: References: <20170609131521.GE2477@physik.fu-berlin.de> <593AB105.5020303@linux.vnet.ibm.com> <6e2530d9-294c-7fd6-2117-178fcb295f1e@physik.fu-berlin.de> <0e758a35-fa4a-96d2-5ab4-14e04ff3c3de@physik.fu-berlin.de> <89c98506-3586-80a7-1058-41c86f391f3e@oracle.com> <6b65524c-ec36-bef7-b7cf-948ff2b3f03b@physik.fu-berlin.de> <1497268280.3582.11.camel@redhat.com> Message-ID: <17cdf344-aecc-4d1f-8a5a-1f207eb9b915@redhat.com> On 02/08/17 06:53, John Paul Adrian Glaubitz wrote: > Could some please review and apply it? I'll handle this. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Aug 2 09:00:09 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Aug 2017 11:00:09 +0200 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: On 08/02/2017 06:35 AM, David Holmes wrote: > Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things > only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would > be a problem? Very happy to see os::is_MP phased out and go. Performance-wise, as the experience with expunging is_MP from Atomics [1] shows, there is a benefit for MP systems with expunging is_MP checks from native code paths. My only concern is with low-power single-processor ARMs and MIPSes. Looking around HS codebase, I think only that matters now. > As outlined in the "bug" report there are three basic options: > > 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container > environments) FWIW, we (Red Hat) are shipping our RPMs with AssumeMP switched to "true" by default [2, 3], because of the container issues. Recent glibc helps there too [4]. > 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to > disable MP support, and compile-time MP_ONLY/NOT_MP macros. > 3. Assume the universe is MP and only allow MP to be built On the fence between these two. Completely fine with removing is_MP from the native codepaths, because that yields benefits for others. Kinda see the reason to keep is_MP checks/macros in the compiler code, to claim the benefits on lower ARMs and MIPSes. Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8169061 [2] https://git.centos.org/blob/rpms!java-1.8.0-openjdk.git/c7/SOURCES!always_assumemp.patch [3] https://git.centos.org/blob/rpms!java-1.8.0-openjdk.git/c7/SPECS!java-1.8.0-openjdk.spec#L963 [4] https://sourceware.org/ml/libc-alpha/2017-06/msg00101.html From kirk at kodewerk.com Wed Aug 2 09:00:57 2017 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 2 Aug 2017 11:00:57 +0200 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: <9012a573-e1fc-02ca-10e7-d67b3861fefe@oracle.com> References: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> <1765F9DF-F08D-41E3-8C87-A78ECDDD0BD8@kodewerk.com> <9012a573-e1fc-02ca-10e7-d67b3861fefe@oracle.com> Message-ID: Hi David, I wasn?t questioning you? and I think we?re saying the same things. Sorry for the noise. Kind regards, Kirk > On Aug 1, 2017, at 11:40 PM, David Holmes wrote: > > Hi Kirk, > > On 2/08/2017 2:08 AM, Kirk Pepperdine wrote: >> Hi, >> Is is wise to standardize the JVM around the container du jour? > > Not sure what you mean here. The use of sched_getaffinity doesn't relate to any container technology it is simply a Linux system API with which the cgroups facility has integrated to "do the right thing" when it comes to cpuset usage. > > For things like memory management cgroups is not integrated with the existing system APIs for memory queries so explicit cgroup mechanisms have to be used. I don't think cgroups would be classified as "the container du jour" given it is part of the Linux system. But we would not want to have to build in direct Docker-specific support, for example, but ultimately it comes down to what the user needs. If container technology X is important and the JVM must run well within it then we need to try and support that somehow. If technology X integrates with system APIs so they "do the right thing" then that is great. Otherwise we have no choice but to use whatever API is provided, while maintaining as much flexibility in the VM as possible. > > Cheers, > David > >> Kind regards, >> Kirk Pepperdine >>> On Aug 1, 2017, at 9:04 AM, David Holmes wrote: >>> >>> Bernd Eckenfels ecki at zusammenkunft.net wrote on Mon Jul 17 21:57:39 UTC 2017 >>>> For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones). >>>> I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however. >>>> Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP? >>> >>> The VM already handles cpusets (as used by cgroups and thus Docker) on Linux, as their use is exposed through the sched_getaffinity API. >>> >>> David >>> >>>> Gruss >>>> Bernd >>> From rkennke at redhat.com Wed Aug 2 09:21:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 2 Aug 2017 11:21:07 +0200 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> Message-ID: <1c6f6ddc-41c5-4450-35d9-2e52e6919689@redhat.com> > I admit I'm not very fluent in template-ese. For example how does one > read this, and what does it mean ?? > > > And I'm still trying to get my head around the introduced "trait" > stuff. (I hate pseudo-languages that can be written within other > languages :( ). And this is, IMO, the biggest problem with the patch. It makes the code unnecessarily hard to understand and buries the actual stuff (usually 1-liners) under layers of templates and redirections. Roman From david.holmes at oracle.com Wed Aug 2 09:45:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 19:45:49 +1000 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: <7da33949-f6c5-069a-1c99-97e7365cca20@oracle.com> <1765F9DF-F08D-41E3-8C87-A78ECDDD0BD8@kodewerk.com> <9012a573-e1fc-02ca-10e7-d67b3861fefe@oracle.com> Message-ID: On 2/08/2017 7:00 PM, Kirk Pepperdine wrote: > Hi David, > > I wasn?t questioning you? and I think we?re saying the same things. Sorry for the noise. No problem - you replied to me so I assumed you were questioning what I had written. Cheers, David > Kind regards, > Kirk > >> On Aug 1, 2017, at 11:40 PM, David Holmes wrote: >> >> Hi Kirk, >> >> On 2/08/2017 2:08 AM, Kirk Pepperdine wrote: >>> Hi, >>> Is is wise to standardize the JVM around the container du jour? >> >> Not sure what you mean here. The use of sched_getaffinity doesn't relate to any container technology it is simply a Linux system API with which the cgroups facility has integrated to "do the right thing" when it comes to cpuset usage. >> >> For things like memory management cgroups is not integrated with the existing system APIs for memory queries so explicit cgroup mechanisms have to be used. I don't think cgroups would be classified as "the container du jour" given it is part of the Linux system. But we would not want to have to build in direct Docker-specific support, for example, but ultimately it comes down to what the user needs. If container technology X is important and the JVM must run well within it then we need to try and support that somehow. If technology X integrates with system APIs so they "do the right thing" then that is great. Otherwise we have no choice but to use whatever API is provided, while maintaining as much flexibility in the VM as possible. >> >> Cheers, >> David >> >>> Kind regards, >>> Kirk Pepperdine >>>> On Aug 1, 2017, at 9:04 AM, David Holmes wrote: >>>> >>>> Bernd Eckenfels ecki at zusammenkunft.net wrote on Mon Jul 17 21:57:39 UTC 2017 >>>>> For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones). >>>>> I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however. >>>>> Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP? >>>> >>>> The VM already handles cpusets (as used by cgroups and thus Docker) on Linux, as their use is exposed through the sched_getaffinity API. >>>> >>>> David >>>> >>>>> Gruss >>>>> Bernd >>>> > From david.holmes at oracle.com Wed Aug 2 09:51:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 19:51:35 +1000 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <920b0165-92b2-0d22-45aa-2ccba3858d74@redhat.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <920b0165-92b2-0d22-45aa-2ccba3858d74@redhat.com> Message-ID: On 2/08/2017 6:31 PM, Andrew Haley wrote: > On 02/08/17 04:35, David Holmes wrote: >> Hi Kim, >> >> Good planning on Erik's part to go on vacation just as I have returned ;-) >> >> On 1/08/2017 4:18 AM, Kim Barrett wrote: >>>> On Jul 28, 2017, at 12:25 PM, Erik Osterlund wrote: >>>> >>>> In that case, feel free to propose a revised solution while I am gone. >>> >>> Erik has asked me to try to make progress on this while he's on >>> vacation, rather than possibly letting it sit until he gets back. >> >> Okay, while Erik is gone perhaps you can clarify a few things. As Andrew >> and Roman have expressed, I too find this: >> >> + template >> + inline static U cmpxchg(T exchange_value, volatile U* dest, V >> compare_value, cmpxchg_memory_order order); >> >> totally unintuitive and unappealing. I do not understand the rationale >> for this this at all. It does not make any sense to me to allow T, U and >> V to be different types (even if constrained). It has been stated that >> if we force them to all be the same there is some problem with literals >> and the need for casts, but I don't understand what that problem would be. > > A couple of examples would help: > > diff -r d207c56d5b5a src/share/vm/runtime/os.cpp > --- a/src/share/vm/runtime/os.cpp Tue Jul 25 15:35:09 2017 +0100 > +++ b/src/share/vm/runtime/os.cpp Wed Aug 02 09:24:30 2017 +0100 > @@ -756,7 +756,7 @@ > while (true) { > unsigned int seed = _rand_seed; > int rand = random_helper(seed); > - if (Atomic::cmpxchg(rand, &_rand_seed, seed) == seed) { > + if (Atomic::cmpxchg((unsigned)rand, &_rand_seed, seed) == seed) { > return rand; > } > } > diff -r d207c56d5b5a src/share/vm/runtime/thread.cpp > --- a/src/share/vm/runtime/thread.cpp Tue Jul 25 15:35:09 2017 +0100 > +++ b/src/share/vm/runtime/thread.cpp Wed Aug 02 09:24:30 2017 +0100 > @@ -4741,7 +4741,7 @@ > enum MuxBits { LOCKBIT = 1 }; > > void Thread::muxAcquire(volatile intptr_t * Lock, const char * LockName) { > - intptr_t w = Atomic::cmpxchg(LOCKBIT, Lock, 0); > + intptr_t w = Atomic::cmpxchg((intptr_t)LOCKBIT, Lock, (intptr_t)0); > if (w == 0) return; > if ((w & LOCKBIT) == 0 && Atomic::cmpxchg (w|LOCKBIT, Lock, w) == w) { > return; > > There are eight such changes required in the HotSpot codebase. > > I strongly believe that these changes make the code better. They show > exactly where types do not match. In the case of the random > generator, they show that there is a type mismatch which is IMO > probably wrong, and it wouldn't hurt to fix it. > I agree. I don't think there is any problem having to coerce types to the correct form when they do not match directly. The casts make it explicit. Though I'm unsure how we manage to avoid the casts in the existing code in some of those cases. Cheers, David From adinn at redhat.com Wed Aug 2 09:53:02 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 2 Aug 2017 10:53:02 +0100 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <920b0165-92b2-0d22-45aa-2ccba3858d74@redhat.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <920b0165-92b2-0d22-45aa-2ccba3858d74@redhat.com> Message-ID: On 02/08/17 09:31, Andrew Haley wrote: > There are eight such changes required in the HotSpot codebase. > > I strongly believe that these changes make the code better. They show > exactly where types do not match. In the case of the random > generator, they show that there is a type mismatch which is IMO > probably wrong, and it wouldn't hurt to fix it. I am of the same opinion. If there were hundreds of such changes required then I would agree that this might i) indicate that there is some fundamental issue which implies the need to cater for mix and match argument types to cmpxchg or ii) the code base is in a terrible state. With a count of 8 I am very strongly led to conclude that neither of the above is an issue. That's not to say I can't/don't admire the nicer points of Erik's implementation. It's very clever and very interesting that you can do something like this with templates but ... it is clearly hard to follow. As a result, I think it is likely to cause more maintenance overhead and, hence, be more risky than the (demonstrably) rare alternative need to correctly cast the occasional argument to a cmpxchg call. Of course, that's merely another 2c in the balance. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Wed Aug 2 11:54:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Aug 2017 21:54:03 +1000 Subject: [PATCH] c1_Canonicalizer.hpp method const In-Reply-To: References: Message-ID: <7e9d60a8-f06a-d4e2-4fc5-80135e6ae3ce@oracle.com> Hi Vasili, On 28/07/2017 7:22 PM, Vasili Svirski wrote: > Hi, > > It is my first patch in the attached file. Attachments get stripped by the mail system, you need to include things as an inline attachment. > In my patch, I just make one class method const > > In c1_Canonicalizer.hpp > - Compilation *compilation() { return > _compilation; } > + Compilation *compilation() const { return _compilation; } > > My steps are: > - read StyleGuide > - make the simple change > - build all > - run native tests by jtreg > > Could somebody review the patch and confirm that I right in my steps? Your steps are okay, but this is far too small a patch to warrant the overhead of processing it. This type of thing would be fixed if doing other work in the area; or as a broader project to tackle code cleanliness. Cheers, David > Best regards, > Vasili > From rohitarulraj at gmail.com Wed Aug 2 15:32:23 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Wed, 2 Aug 2017 21:02:23 +0530 Subject: Help with generating library call In-Reply-To: <436f03b4-f352-e2df-4afb-a70905d3927e@redhat.com> References: <436f03b4-f352-e2df-4afb-a70905d3927e@redhat.com> Message-ID: On Mon, Jul 31, 2017 at 1:48 PM, Andrew Haley wrote: > On 31/07/17 05:33, Rohit Arul Raj wrote: >> Can any one point me in the right direction? Any reference to similar >> implementation of any other C or Math library function will be >> helpful? >> >> I ended up doing the following, but not sure if this is the right way >> to go about it. >> push (c_rarg2); >> push (c_rarg1); >> push (c_rarg0); >> call_VM_leaf(CAST_FROM_FN_PTR(address, memset),3); > > This doesn't look totally wrong. > > There are many examples in the source. For example, look at any calls > to MacroAssembler::call_VM and call_VM_leaf. Be aware, however, that > if you're calling this from compiled code most registers are live so > you're going to have to be extremely careful to save and restore them. > One of the advantages of using HotSpot's builtins for zeroing is that > we can know exactly which registers are used. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 Thanks Andrew, I managed to generate the required instructions. But while generating the code (from the interpreter), the instructions are getting re-ordered. Is there a way to generate a sequence of instructions without breaking the chain? Any suggestions? push (base_ptr); push (c_rarg0); push (c_rarg1); push (c_rarg2); if (base_ptr != c_rarg0) { if (base_ptr != c_rarg2) { movq(c_rarg0, base_ptr); if (cnt_dwords != c_rarg2) movq(c_rarg2, cnt_dwords); } else { if (cnt_dwords != c_rarg2) movq(c_rarg2, cnt_dwords); movq(c_rarg0, base_ptr); } } else { if (cnt_dwords != c_rarg2) movq(c_rarg2, cnt_dwords); } addq(c_rarg0, disp); xorl (c_rarg1, c_rarg1); call_VM_leaf(CAST_FROM_FN_PTR(address, memset), c_rarg0, c_rarg1, c_rarg2); pop (c_rarg2); pop (c_rarg1); pop (c_rarg0); pop (base_ptr); Regards, Rohit From aph at redhat.com Wed Aug 2 16:35:08 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Aug 2017 17:35:08 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit Message-ID: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> We've been seeing baffling segfaults in the C++ interpreter on Power PC 32-bit. Zero is so called because it uses zero assembly language, but this is not quite true: there is a tiny bit of assembly language, and it is wrong. Here is the PPC32 definition of atomic_copy64. It uses a floating-point register to copy a 64-bit doubleword atomically: // Atomically copy 64 bits of data static void atomic_copy64(volatile void *src, volatile void *dst) { #if defined(PPC32) && !defined(__NO_FPRS__) double tmp; asm volatile ("lfd %0, 0(%1)\n" "stfd %0, 0(%2)\n" : "=f"(tmp) : "b"(src), "b"(dst)); The eagle-eyed among you might have noticed the bug: this asm has no memory effect. It has no memory inputs, no memory outputs, and no memory clobber. So, as far as GCC is concerned atomic_copy64 does not touch memory at all, and there is no need to store the source operand into memory. For all GCC knows, the asm might just be doing some arithmetic on the pointers. We need a better definition of atomic_copy64, and this is mine: // Atomically copy 64 bits of data static void atomic_copy64(volatile void *src, volatile void *dst) { #if defined(PPC32) && !defined(__NO_FPRS__) double tmp; asm volatile ("lfd %0, %2\n" "stfd %0, %1\n" : "=&f"(tmp), "=Q"(*(volatile double*)dst) : "Q"(*(volatile double*)src)); Note that we dereference src and dst and pass the actual memory operands to the asm, not just pointers to them. http://cr.openjdk.java.net/~aph/8185723/ OK? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From cthalinger at twitter.com Thu Aug 3 09:01:35 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 3 Aug 2017 11:01:35 +0200 Subject: [10] RFR(S) 8185018: Put AOT tests on problem list for OS-X and Windows In-Reply-To: <1ccaa9d3-da06-4cae-3ba0-af0c09043b76@oracle.com> References: <1ccaa9d3-da06-4cae-3ba0-af0c09043b76@oracle.com> Message-ID: > On Jul 21, 2017, at 1:59 AM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8185018 > webrev: http://cr.openjdk.java.net/~kvn/8185018/webrev.00/ > > Put AOT tests on problem list for OS-X and Windows until we solve the problem JDK-8183337 with missing tools (linker) on tests machines. Both bugs are confidential. Any chance to make them public? > > Thanks, > Vladimir From sgehwolf at redhat.com Thu Aug 3 09:25:29 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 Aug 2017 11:25:29 +0200 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> Message-ID: <1501752329.3823.3.camel@redhat.com> Hi, On Wed, 2017-08-02 at 17:35 +0100, Andrew Haley wrote: > We've been seeing baffling segfaults in the C++ interpreter on Power > PC 32-bit. > > Zero is so called because it uses zero assembly language, but this is > not quite true: there is a tiny bit of assembly language, and it is > wrong.??Here is the PPC32 definition of atomic_copy64.??It uses a > floating-point register to copy a 64-bit doubleword atomically: > > ? // Atomically copy 64 bits of data > ? static void atomic_copy64(volatile void *src, volatile void *dst) { > #if defined(PPC32) && !defined(__NO_FPRS__) > ????double tmp; > ????asm volatile ("lfd??%0, 0(%1)\n" > ??????????????????"stfd %0, 0(%2)\n" > ??????????????????: "=f"(tmp) > ??????????????????: "b"(src), "b"(dst)); > > The eagle-eyed among you might have noticed the bug: this asm has no > memory effect.??It has no memory inputs, no memory outputs, and no > memory clobber.??So, as far as GCC is concerned atomic_copy64 does not > touch memory at all, and there is no need to store the source operand > into memory.??For all GCC knows, the asm might just be doing some > arithmetic on the pointers.??We need a better definition of > atomic_copy64, and this is mine: > > ? // Atomically copy 64 bits of data > static void atomic_copy64(volatile void *src, volatile void *dst) { > #if defined(PPC32) && !defined(__NO_FPRS__) > ????double tmp; > ????asm volatile ("lfd??%0, %2\n" > ??????????????????"stfd %0, %1\n" > ??????????????????: "=&f"(tmp), "=Q"(*(volatile double*)dst) > ??????????????????: "Q"(*(volatile double*)src)); > > Note that we dereference src and dst and pass the actual memory > operands to the asm, not just pointers to them. > > http://cr.openjdk.java.net/~aph/8185723/ > > OK? FWIW, with this patch OpenJDK 9 Zero bootcyle-images builds for me on PPC32 in the release variant. That used to segv prior this patch. Slowdebug builds were OK pre-patch. Issue was only observable with fastdebug/release builds. If it matters, we also know that passing -fno-tree-dce to the hotspot build "fixed" the issue pre-patch. +1 from me. Thanks, Severin From glaubitz at physik.fu-berlin.de Thu Aug 3 09:32:26 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 3 Aug 2017 11:32:26 +0200 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <1501752329.3823.3.camel@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> Message-ID: <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> On 08/03/2017 11:25 AM, Severin Gehwolf wrote: > FWIW, with this patch OpenJDK 9 Zero bootcyle-images builds for me on > PPC32 in the release variant. Awesome :). > That used to segv prior this patch. Slowdebug builds were OK pre-patch. > Issue was only observable with fastdebug/release builds. Yep, that was my initial observation as well. > If it matters, we also know that passing -fno-tree-dce to the hotspot > build "fixed" the issue pre-patch. Interesting. > +1 from me. Thanks. Btw, I'm currently trying to wrap my head around how to implement atomic_copy64() on m68k with inline assembly using cas2 which allows compare-and-swap with two 32-bit values and hence the implementation of an atomic_copy64(). I think either __arch_compare_and_exchange_val_64_acq() or atomic_exchange_acq() from [1] should help. Adrian > [1] https://github.com/kaffe/kaffe/blob/master/config/m68k/atomic.h#L69 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Aug 3 10:06:31 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Aug 2017 11:06:31 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> Message-ID: On 03/08/17 10:32, John Paul Adrian Glaubitz wrote: > Btw, I'm currently trying to wrap my head around how to implement > atomic_copy64() on m68k with inline assembly using cas2 which allows > compare-and-swap with two 32-bit values and hence the implementation > of an atomic_copy64(). > > I think either __arch_compare_and_exchange_val_64_acq() or > atomic_exchange_acq() from [1] should help. The first one is what you want, assuming that you're happy to write to an operand you're supposed to only read. But there may be a better way of handling atomic doublewords on the 68k. Instead, define an array of lock words and yield on one of them when reading or writing a doubleword. That way you (probably) only block when two threads really are contending, and the instant you detect contention you yield. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Thu Aug 3 10:43:34 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 3 Aug 2017 12:43:34 +0200 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> Message-ID: On 08/03/2017 12:06 PM, Andrew Haley wrote: > But there may be a better way of handling atomic doublewords on the > 68k. Instead, define an array of lock words and yield on one of them > when reading or writing a doubleword. That way you (probably) only > block when two threads really are contending, and the instant you > detect contention you yield. Hmm, I have honestly no idea how to implement that though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Aug 3 11:07:17 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Aug 2017 12:07:17 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> Message-ID: <049044d8-1d8d-f667-66b0-f5898b277f89@redhat.com> On 03/08/17 11:43, John Paul Adrian Glaubitz wrote: > On 08/03/2017 12:06 PM, Andrew Haley wrote: >> But there may be a better way of handling atomic doublewords on the >> 68k. Instead, define an array of lock words and yield on one of them >> when reading or writing a doubleword. That way you (probably) only >> block when two threads really are contending, and the instant you >> detect contention you yield. > > Hmm, I have honestly no idea how to implement that though. I'll have a look. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Aug 3 11:58:22 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Aug 2017 12:58:22 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> Message-ID: <4730aa20-8126-4830-12ee-5a46e9270b94@redhat.com> On 03/08/17 11:43, John Paul Adrian Glaubitz wrote: > On 08/03/2017 12:06 PM, Andrew Haley wrote: >> But there may be a better way of handling atomic doublewords on the >> 68k. Instead, define an array of lock words and yield on one of them >> when reading or writing a doubleword. That way you (probably) only >> block when two threads really are contending, and the instant you >> detect contention you yield. Use lock_address(a) for all atomic double operations. Then you don't need any assembly language for 64-bit atomic ops. It's simple, but it's not super-efficient. It has the virtue that it will work on every platform. My guess is that it's good enough for Zero. template static inline int hash(T *a) { unsigned int n = (unsigned int)(uintptr_t)a; return (n + (n >> 8)) & 255; // Or simply n % 255 if that's faster } template static inline void lock_address(T *a) { int n = hash(a); while (__sync_lock_test_and_set(&locks[n], 1)) { pthread_yield(); } } template static inline void unlock_address(T *a) { int n = hash(a); __sync_lock_release(&locks[n]); } void atomic_copy64(const volatile void *src, volatile void *dst) { lock_address(src); uint64_t tmp = *(uint64_t*)src; unlock_address(src); lock_address(dst); *(uint64_t*)dst = tmp; unlock_address(dst); } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Thu Aug 3 12:03:03 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 3 Aug 2017 08:03:03 -0400 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> Message-ID: Hi, Looks like a good find. I think this should be on the list of things you can push directly from the open. Otherwise, I'll sponsor it. I didn't review it though. Coleen On 8/2/17 12:35 PM, Andrew Haley wrote: > We've been seeing baffling segfaults in the C++ interpreter on Power > PC 32-bit. > > Zero is so called because it uses zero assembly language, but this is > not quite true: there is a tiny bit of assembly language, and it is > wrong. Here is the PPC32 definition of atomic_copy64. It uses a > floating-point register to copy a 64-bit doubleword atomically: > > // Atomically copy 64 bits of data > static void atomic_copy64(volatile void *src, volatile void *dst) { > #if defined(PPC32) && !defined(__NO_FPRS__) > double tmp; > asm volatile ("lfd %0, 0(%1)\n" > "stfd %0, 0(%2)\n" > : "=f"(tmp) > : "b"(src), "b"(dst)); > > The eagle-eyed among you might have noticed the bug: this asm has no > memory effect. It has no memory inputs, no memory outputs, and no > memory clobber. So, as far as GCC is concerned atomic_copy64 does not > touch memory at all, and there is no need to store the source operand > into memory. For all GCC knows, the asm might just be doing some > arithmetic on the pointers. We need a better definition of > atomic_copy64, and this is mine: > > // Atomically copy 64 bits of data > static void atomic_copy64(volatile void *src, volatile void *dst) { > #if defined(PPC32) && !defined(__NO_FPRS__) > double tmp; > asm volatile ("lfd %0, %2\n" > "stfd %0, %1\n" > : "=&f"(tmp), "=Q"(*(volatile double*)dst) > : "Q"(*(volatile double*)src)); > > Note that we dereference src and dst and pass the actual memory > operands to the asm, not just pointers to them. > > http://cr.openjdk.java.net/~aph/8185723/ > > OK? > From aph at redhat.com Thu Aug 3 12:07:03 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Aug 2017 13:07:03 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <4730aa20-8126-4830-12ee-5a46e9270b94@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> <4730aa20-8126-4830-12ee-5a46e9270b94@redhat.com> Message-ID: <0a8fc679-fc4c-4f70-6bd1-5e78fb9fecdd@redhat.com> On 03/08/17 12:58, Andrew Haley wrote: > On 03/08/17 11:43, John Paul Adrian Glaubitz wrote: >> On 08/03/2017 12:06 PM, Andrew Haley wrote: >>> But there may be a better way of handling atomic doublewords on the >>> 68k. Instead, define an array of lock words and yield on one of them >>> when reading or writing a doubleword. That way you (probably) only >>> block when two threads really are contending, and the instant you >>> detect contention you yield. > > Use lock_address(a) for all atomic double operations. Then you don't > need any assembly language for 64-bit atomic ops. It's simple, but > it's not super-efficient. It has the virtue that it will work on > every platform. > > My guess is that it's good enough for Zero. Missed this: #define LOCKS_SIZE 256 static unsigned int locks[LOCKS_SIZE]; > template > static inline int hash(T *a) { > unsigned int n = (unsigned int)(uintptr_t)a; > return (n + (n >> 8)) & 255; // Or simply n % 255 if that's faster > } > > template > static inline void lock_address(T *a) { > int n = hash(a); > while (__sync_lock_test_and_set(&locks[n], 1)) { > pthread_yield(); > } > } > > template > static inline void unlock_address(T *a) { > int n = hash(a); > __sync_lock_release(&locks[n]); > } > > void atomic_copy64(const volatile void *src, volatile void *dst) { > lock_address(src); > uint64_t tmp = *(uint64_t*)src; > unlock_address(src); > > lock_address(dst); > *(uint64_t*)dst = tmp; > unlock_address(dst); > } > -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Thu Aug 3 12:19:30 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 3 Aug 2017 14:19:30 +0200 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> Message-ID: <0c1b7faa-3a30-7e7d-664c-746bec451a21@physik.fu-berlin.de> On 08/03/2017 12:06 PM, Andrew Haley wrote: > On 03/08/17 10:32, John Paul Adrian Glaubitz wrote: >> I think either __arch_compare_and_exchange_val_64_acq() or >> atomic_exchange_acq() from [1] should help. > > The first one is what you want, assuming that you're happy to > write to an operand you're supposed to only read. I'm trying this now: --- jdk9-fe8466adaef8.orig/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp 2017-07-14 06:32:55.000000000 +0200 +++ jdk9-fe8466adaef8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.hpp 2017-08-03 13:59:40.257640677 +0200 @@ -48,6 +48,22 @@ "std %0, 0(%2)\n" : "=r"(tmp) : "a"(src), "a"(dst)); +#elif defined(M68K) +# define __arch_compare_and_exchange_val_64_acq(mem, newval, oldval) \ + ({ __typeof (*(mem)) __ret; \ + __typeof (mem) __memp = (mem); \ + __asm __volatile ("cas2%.l %0:%R0,%1:%R1,(%2):(%3)" \ + : "=d" (__ret) \ + : "d" ((__typeof (*(mem))) (newval)), "r" (__memp), \ + "r" ((char *) __memp + 4), "0" (oldval) \ + : "memory"); \ + __ret; }) + + jlong tmp; + do { + tmp = *(jlong *)src; + } while(!__arch_compare_and_exchange_val_64_acq(src, tmp, tmp)); + while(__arch_compare_and_exchange_val_64_acq(dst, *(jlong*)dst, tmp)); #else *(jlong *) dst = *(jlong *) src; #endif I have no idea whether it's correct, but I'll find out. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Aug 3 12:22:26 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Aug 2017 13:22:26 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <0c1b7faa-3a30-7e7d-664c-746bec451a21@physik.fu-berlin.de> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> <0c1b7faa-3a30-7e7d-664c-746bec451a21@physik.fu-berlin.de> Message-ID: <6038b3a1-f4d8-6aa3-4936-a064a8c4057e@redhat.com> On 03/08/17 13:19, John Paul Adrian Glaubitz wrote: > I have no idea whether it's correct, but I'll find out. It's not obviously wrong. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Thu Aug 3 12:33:51 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 3 Aug 2017 14:33:51 +0200 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <6038b3a1-f4d8-6aa3-4936-a064a8c4057e@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <1501752329.3823.3.camel@redhat.com> <6c840ea1-383a-6a57-9896-a3f8d1c32362@physik.fu-berlin.de> <0c1b7faa-3a30-7e7d-664c-746bec451a21@physik.fu-berlin.de> <6038b3a1-f4d8-6aa3-4936-a064a8c4057e@redhat.com> Message-ID: <3561bc1b-cb55-ca40-00a7-d1efaafc0753@physik.fu-berlin.de> On 08/03/2017 02:22 PM, Andrew Haley wrote: > On 03/08/17 13:19, John Paul Adrian Glaubitz wrote: >> I have no idea whether it's correct, but I'll find out. > > It's not obviously wrong. :-) dst and src need to be cast to (jlong*) though. It's still compiling. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From yasuenag at gmail.com Thu Aug 3 13:16:33 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 3 Aug 2017 22:16:33 +0900 Subject: HotSpot build failure with GCC 7.1.1 Message-ID: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> Hi all, I tried to jdk10/hs on Fedora 26 x86_64 with GCC 7.1.1, however it was failed as below: ------------------- /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp: In static member function 'static int Array::size(int, int)': /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp:138:12: error: there are no arguments to 'align_size_up' that depend on a template parameter, so a declaration of 'align_size_up' must be available [-fpermissive] return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME ^~~~~~~~~~~~~ /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp:138:12: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) In file included from /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/runtime/os.inline.hpp:30:0, from /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/runtime/thread.inline.hpp:31, ... (rest of output omitted) ------------------- I think this failure is since JDK-8072061: http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/731370f39fcd#l42.35 IMHO we can fix this error as below: ------------------- diff -r 731370f39fcd src/share/vm/oops/array.hpp --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 +++ b/src/share/vm/oops/array.hpp Thu Aug 03 22:14:46 2017 +0900 @@ -135,7 +135,7 @@ return (int)words; } static int size(int length, int elm_byte_size) { - return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME + return align_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; } int size() { ------------------- Someone is working for this issue? If not, I will file it to JBS and will send review request. Thanks, Yasumasa From vladimir.kozlov at oracle.com Thu Aug 3 14:48:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Aug 2017 07:48:50 -0700 Subject: [10] RFR(S) 8185018: Put AOT tests on problem list for OS-X and Windows In-Reply-To: References: <1ccaa9d3-da06-4cae-3ba0-af0c09043b76@oracle.com> Message-ID: Unfortunately 8183337 has internal names in Description and 8185018 is subtask of it. There is no important information for community there. Only list of failed tests and machines which miss XCode and VS. Vladimir On 8/3/17 2:01 AM, Christian Thalinger wrote: > >> On Jul 21, 2017, at 1:59 AM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8185018 >> webrev: http://cr.openjdk.java.net/~kvn/8185018/webrev.00/ >> >> Put AOT tests on problem list for OS-X and Windows until we solve the problem JDK-8183337 with missing tools (linker) on tests machines. > > Both bugs are confidential. Any chance to make them public? > >> >> Thanks, >> Vladimir > From cthalinger at twitter.com Thu Aug 3 16:09:09 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 3 Aug 2017 18:09:09 +0200 Subject: [10] RFR(S) 8185018: Put AOT tests on problem list for OS-X and Windows In-Reply-To: References: <1ccaa9d3-da06-4cae-3ba0-af0c09043b76@oracle.com> Message-ID: <912DD95F-BEB5-4F31-9EA8-866F61CE7072@twitter.com> > On Aug 3, 2017, at 4:48 PM, Vladimir Kozlov wrote: > > Unfortunately 8183337 has internal names in Description and 8185018 is subtask of it. > > There is no important information for community there. Only list of failed tests and machines which miss XCode and VS. Ok, thanks. > > Vladimir > > On 8/3/17 2:01 AM, Christian Thalinger wrote: >>> On Jul 21, 2017, at 1:59 AM, Vladimir Kozlov wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185018 >>> webrev: http://cr.openjdk.java.net/~kvn/8185018/webrev.00/ >>> >>> Put AOT tests on problem list for OS-X and Windows until we solve the problem JDK-8183337 with missing tools (linker) on tests machines. >> Both bugs are confidential. Any chance to make them public? >>> >>> Thanks, >>> Vladimir From kim.barrett at oracle.com Thu Aug 3 17:12:55 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Aug 2017 13:12:55 -0400 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> Message-ID: > On Aug 3, 2017, at 9:16 AM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to jdk10/hs on Fedora 26 x86_64 with GCC 7.1.1, however it was failed as below: > ------------------- > /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp: In static member function 'static int Array::size(int, int)': > /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp:138:12: error: there are no arguments to 'align_size_up' that depend on a template parameter, so a declaration of 'align_size_up' must be available [-fpermissive] > return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME > ^~~~~~~~~~~~~ > /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp:138:12: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) > In file included from /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/runtime/os.inline.hpp:30:0, > from /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/runtime/thread.inline.hpp:31, > ... (rest of output omitted) > ------------------- > > I think this failure is since JDK-8072061: > http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/731370f39fcd#l42.35 > > IMHO we can fix this error as below: > ------------------- > diff -r 731370f39fcd src/share/vm/oops/array.hpp > --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 > +++ b/src/share/vm/oops/array.hpp Thu Aug 03 22:14:46 2017 +0900 > @@ -135,7 +135,7 @@ > return (int)words; > } > static int size(int length, int elm_byte_size) { > - return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME > + return align_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; > } > > int size() { > ------------------- > > Someone is working for this issue? > If not, I will file it to JBS and will send review request. I don?t know of a bug for this. Yes, please fix. I?m surprised this made it through JPRT. There is value dependency on T (in byte_sizeof), but it doesn?t seem like something that ought to make the lookup of align_size_up dependent. I guess I need to go re-read about two-phase lookup. From kim.barrett at oracle.com Thu Aug 3 19:27:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Aug 2017 15:27:18 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> Message-ID: <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> > On Aug 1, 2017, at 11:35 PM, David Holmes wrote: > > Hi Kim, > > Good planning on Erik's part to go on vacation just as I have returned ;-) > > On 1/08/2017 4:18 AM, Kim Barrett wrote: >>> On Jul 28, 2017, at 12:25 PM, Erik Osterlund wrote: >>> >>> Hi Andrew, >>> >>> In that case, feel free to propose a revised solution while I am gone. >> Erik has asked me to try to make progress on this while he's on >> vacation, rather than possibly letting it sit until he gets back. > > Okay, while Erik is gone perhaps you can clarify a few things. As Andrew and Roman have expressed, I too find this: > > + template > + inline static U cmpxchg(T exchange_value, volatile U* dest, V compare_value, cmpxchg_memory_order order); > > totally unintuitive and unappealing. I do not understand the rationale for this this at all. It does not make any sense to me to allow T, U and V to be different types (even if constrained). It has been stated that if we force them to all be the same there is some problem with literals and the need for casts, but I don't understand what that problem would be. This response is about the types for a cmpxchg template. I'll respond to other comments separately. It is certainly simpler to implement if the types for all three arguments are required to be the same. I suggested Erik do that, but he reported running into "lots" of compilation failures. I guess Erik was less persistent than Andrew in working through them. Given Andrew's reported small number, I've also done that experiment and looked at the failing cases. I think (nearly?) all would be improved by making the argument types match. There's also one similar case for xchg. However, there are use-cases that I think are reasonable which don't immediately fit that restriction. (1) cmpxchg(v, p, NULL), to store a pointer if no pointer is already present. This can be used as an alternative to DCLP. One way to deal with this might be an overload on std::nullptr_t and use nullptr, but that requires C++11. We don't have any current uses of this that I could find, but it's a sufficiently interesting idiom that I'm relucant to forbid it. But such idiomatic usage could be wrapped up in its own little package that can deal with the restriction. (2) The use of literals can make getting a type match more difficult, especially when the pointee type doesn't have portable syntax (like intx and uintx). But using properly typed named values solves this, and may be seen as an improvement over magic literal values. (3) Passing a derived pointer as the new value when updating an atomic pointer seems reasonable to me. A derived pointer compare value seems somewhat less so. Similarly, new and compare values that have pointee types that are less cv-qualified than the destination also seems reasonable. (4) Several of the problematic cases involve enums, which aren't especially well handled by the original proposal. From Erik's explorations I knew there were some issues with enums. Having now looked at some of these cmpxchg problems, I think we should try harder to deal well with enums. One problem is that C++11 std::is_enum is at least hard (maybe impossible?) to portabily emulate in C++98, so some other mechanism would be needed to recognize them. Probably the simplest is a registration mechanism for enum types that are used for atomic-access values (e.g a type predicate defaulting to false, and specializations for relevant enum types, near their definitions.) (5) One of our goals is to eliminate, as much as possible, the need for explicit casts and conversions in uses of this API. We think the existing widespread use of casts makes code difficult to understand and is a source of bugs. I think the small number of call sites affected by requiring the cmpxchg types all be the same is in no small measure a result of that widespread use of casts in calling code. Unfortunately, Hotspot is rife with boundaries across which there are type mismatches (and often inconsistencies even within a single logical chunk of code). We don't think that's a good thing, but it's the context in which we were developing this change. I think the proposed change may be more lax than it should / could be, but I think there are valid reasons to not require the types for cmpxchg arguments to all match. From david.holmes at oracle.com Thu Aug 3 23:12:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Aug 2017 09:12:44 +1000 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> Message-ID: <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> On 4/08/2017 3:12 AM, Kim Barrett wrote: >> On Aug 3, 2017, at 9:16 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to jdk10/hs on Fedora 26 x86_64 with GCC 7.1.1, however it was failed as below: >> ------------------- >> /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp: In static member function 'static int Array::size(int, int)': >> /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp:138:12: error: there are no arguments to 'align_size_up' that depend on a template parameter, so a declaration of 'align_size_up' must be available [-fpermissive] >> return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME >> ^~~~~~~~~~~~~ >> /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/oops/array.hpp:138:12: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) >> In file included from /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/runtime/os.inline.hpp:30:0, >> from /home/ysuenaga/OpenJDK/jdk10-hs/hotspot/src/share/vm/runtime/thread.inline.hpp:31, >> ... (rest of output omitted) >> ------------------- >> >> I think this failure is since JDK-8072061: >> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/731370f39fcd#l42.35 >> >> IMHO we can fix this error as below: >> ------------------- >> diff -r 731370f39fcd src/share/vm/oops/array.hpp >> --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 >> +++ b/src/share/vm/oops/array.hpp Thu Aug 03 22:14:46 2017 +0900 >> @@ -135,7 +135,7 @@ >> return (int)words; >> } >> static int size(int length, int elm_byte_size) { >> - return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME >> + return align_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; >> } >> >> int size() { >> ------------------- >> >> Someone is working for this issue? >> If not, I will file it to JBS and will send review request. > > I don?t know of a bug for this. Yes, please fix. > > I?m surprised this made it through JPRT. There is value dependency on T (in byte_sizeof), > but it doesn?t seem like something that ought to make the lookup of align_size_up dependent. > I guess I need to go re-read about two-phase lookup. I can't even see a definition of align_size_up - where is it coming from ??? David > > From david.holmes at oracle.com Thu Aug 3 23:42:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Aug 2017 09:42:44 +1000 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: Hi Kim, On 4/08/2017 5:27 AM, Kim Barrett wrote: >> On Aug 1, 2017, at 11:35 PM, David Holmes wrote: >> >> Hi Kim, >> >> Good planning on Erik's part to go on vacation just as I have returned ;-) >> >> On 1/08/2017 4:18 AM, Kim Barrett wrote: >>>> On Jul 28, 2017, at 12:25 PM, Erik Osterlund wrote: >>>> >>>> Hi Andrew, >>>> >>>> In that case, feel free to propose a revised solution while I am gone. >>> Erik has asked me to try to make progress on this while he's on >>> vacation, rather than possibly letting it sit until he gets back. >> >> Okay, while Erik is gone perhaps you can clarify a few things. As Andrew and Roman have expressed, I too find this: >> >> + template >> + inline static U cmpxchg(T exchange_value, volatile U* dest, V compare_value, cmpxchg_memory_order order); >> >> totally unintuitive and unappealing. I do not understand the rationale for this this at all. It does not make any sense to me to allow T, U and V to be different types (even if constrained). It has been stated that if we force them to all be the same there is some problem with literals and the need for casts, but I don't understand what that problem would be. > > This response is about the types for a cmpxchg template. I'll respond > to other comments separately. > > It is certainly simpler to implement if the types for all three > arguments are required to be the same. > > I suggested Erik do that, but he reported running into "lots" of > compilation failures. I guess Erik was less persistent than Andrew in > working through them. Given Andrew's reported small number, I've also > done that experiment and looked at the failing cases. I think > (nearly?) all would be improved by making the argument types match. > There's also one similar case for xchg. > > However, there are use-cases that I think are reasonable which don't > immediately fit that restriction. > > (1) cmpxchg(v, p, NULL), to store a pointer if no pointer is already > present. This can be used as an alternative to DCLP. One way to deal I thought NULL (aka 0 in a pointer context) was assignable to any pointer type without any casts. ?? > with this might be an overload on std::nullptr_t and use nullptr, but > that requires C++11. We don't have any current uses of this that I > could find, but it's a sufficiently interesting idiom that I'm > relucant to forbid it. But such idiomatic usage could be wrapped up > in its own little package that can deal with the restriction. > > (2) The use of literals can make getting a type match more difficult, > especially when the pointee type doesn't have portable syntax (like > intx and uintx). But using properly typed named values solves this, > and may be seen as an improvement over magic literal values. I'd like to see specific examples. I would hope that normal conversions/promotions would handle the majority of cases. > (3) Passing a derived pointer as the new value when updating an atomic > pointer seems reasonable to me. A derived pointer compare value seems > somewhat less so. Similarly, new and compare values that have pointee > types that are less cv-qualified than the destination also seems > reasonable. My C++ is rusty. Is a derived pointer not usable where a base pointer is declared?? Seems fundamental to polymorphism. The cv-qualifiers is a mess - shouldn't they really match? (I know we cast them on and off all over - but thats the mess part). Regardless, this suggests to me a relaxed form might be needed for pointer types. > (4) Several of the problematic cases involve enums, which aren't > especially well handled by the original proposal. From Erik's > explorations I knew there were some issues with enums. Having now > looked at some of these cmpxchg problems, I think we should try harder > to deal well with enums. One problem is that C++11 std::is_enum is at > least hard (maybe impossible?) to portabily emulate in C++98, so some > other mechanism would be needed to recognize them. Probably the > simplest is a registration mechanism for enum types that are used for > atomic-access values (e.g a type predicate defaulting to false, and > specializations for relevant enum types, near their definitions.) Enums are a disaster in C/C++ - maybe better in C++11. But I thought there were nice design patterns for type-safe enums that allow easy conversion to integer types within range? > (5) One of our goals is to eliminate, as much as possible, the need > for explicit casts and conversions in uses of this API. We think the > existing widespread use of casts makes code difficult to understand > and is a source of bugs. I think the small number of call sites > affected by requiring the cmpxchg types all be the same is in no small > measure a result of that widespread use of casts in calling code. > Unfortunately, Hotspot is rife with boundaries across which there are > type mismatches (and often inconsistencies even within a single > logical chunk of code). We don't think that's a good thing, but it's > the context in which we were developing this change. That's too hand-wavy for me. Many of the casts may not even be needed today but who is going to go through and try and figure that out! I don't even see that many casts in Atomic calls and the ones that are there seem to group into common sets in relation to pointers and intptr_t. > I think the proposed change may be more lax than it should / could > be, but I think there are valid reasons to not require the types for > cmpxchg arguments to all match. Sorry I'm not convinced. Points 1,3 and 5 may suggest the need for relaxed pointer variants. Also floating-point atomic ops make little sense - hardware doesn't provide discrete atomic ops on FP values. So the only thing you can do is a cas-loop on the memory location. That's why j.u.c.atomic doesn't support them - they'd be grossly inefficient. Cheers, David From kim.barrett at oracle.com Fri Aug 4 00:08:05 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Aug 2017 20:08:05 -0400 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> Message-ID: <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> > On Aug 3, 2017, at 7:12 PM, David Holmes wrote: > I can't even see a definition of align_size_up - where is it coming from ??? It was recently removed. 8178499: Remove _ptr_ and _size_ infixes from align functions From david.holmes at oracle.com Fri Aug 4 00:38:02 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Aug 2017 10:38:02 +1000 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> Message-ID: <17d667c6-41d2-b95c-e4f3-2e95c4482d79@oracle.com> On 4/08/2017 10:08 AM, Kim Barrett wrote: >> On Aug 3, 2017, at 7:12 PM, David Holmes wrote: >> I can't even see a definition of align_size_up - where is it coming from ??? > > It was recently removed. > > 8178499: Remove _ptr_ and _size_ infixes from align functions Then how is it still referenced in array.hpp ??? Thanks, David From yasuenag at gmail.com Fri Aug 4 00:49:40 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Aug 2017 09:49:40 +0900 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> Message-ID: Thanks Kim, David, I filed this issue to JBS and uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ I cannot access JPRT. So I need a sponsor. Yasumasa 2017-08-04 9:08 GMT+09:00 Kim Barrett : >> On Aug 3, 2017, at 7:12 PM, David Holmes wrote: >> I can't even see a definition of align_size_up - where is it coming from ??? > > It was recently removed. > > 8178499: Remove _ptr_ and _size_ infixes from align functions > From david.holmes at oracle.com Fri Aug 4 02:00:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Aug 2017 12:00:34 +1000 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> Message-ID: <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> Hi Yasumasa, On 4/08/2017 10:49 AM, Yasumasa Suenaga wrote: > Thanks Kim, David, > > I filed this issue to JBS and uploaded webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ I'm still at a loss to understand how the current code even compiles/links at all with any version of the compiler. ?? You removed a "// FIXME" comment - what was that referring to ?? Thanks, David > I cannot access JPRT. So I need a sponsor. > > > Yasumasa > > > > 2017-08-04 9:08 GMT+09:00 Kim Barrett : >>> On Aug 3, 2017, at 7:12 PM, David Holmes wrote: >>> I can't even see a definition of align_size_up - where is it coming from ??? >> >> It was recently removed. >> >> 8178499: Remove _ptr_ and _size_ infixes from align functions >> From ioi.lam at oracle.com Fri Aug 4 04:50:15 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 3 Aug 2017 21:50:15 -0700 Subject: RFR XXS (8185826) HotSpot build failure with GCC 7.1.1 In-Reply-To: <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> Message-ID: <91a540f0-f2cc-ce46-84b5-dcdcd5e5b570@oracle.com> On 8/3/17 7:00 PM, David Holmes wrote: > Hi Yasumasa, > > On 4/08/2017 10:49 AM, Yasumasa Suenaga wrote: >> Thanks Kim, David, >> >> I filed this issue to JBS and uploaded webrev. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ > > I'm still at a loss to understand how the current code even > compiles/links at all with any version of the compiler. ?? > Hi Yasumasa, thanks for noticing this. Sorry, it was my bug. I checked this in as part of JDK-8072061 on Tuesday. Apparently older C++ compilers are quite lenient when compiling template declarations that aren't instantiated. Here's a test case: template class X { static int size() { return align_size_up(byte_sizeof()); } static int byte_sizeof() { return sizeof(T); } }; # from gcc 5.4: $ gcc -c ~/t.cpp && echo $? 0 In our case, presumably, gcc will detect the error when an instantiated Array type access the size(int, int) method. However, I added this function during my development, but didn't need it after all. So this function was never referenced, so all of our existing compilers never had a chance to generate an error for I removed this function and HotSpot built with no error. $ hg diff diff -r 731370f39fcd src/share/vm/oops/array.hpp --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 +++ b/src/share/vm/oops/array.hpp Thu Aug 03 21:47:41 2017 -0700 @@ -134,10 +134,6 @@ return (int)words; } - static int size(int length, int elm_byte_size) { - return align_size_up(byte_sizeof(length, elm_byte_size), BytesPerWord) / BytesPerWord; // FIXME - } - int size() { return size(_length); } So I think proper fix is to just remove this function. Thanks - Ioi > You removed a "// FIXME" comment - what was that referring to ?? > > Thanks, > David > >> I cannot access JPRT. So I need a sponsor. >> >> >> Yasumasa >> >> >> >> 2017-08-04 9:08 GMT+09:00 Kim Barrett : >>>> On Aug 3, 2017, at 7:12 PM, David Holmes >>>> wrote: >>>> I can't even see a definition of align_size_up - where is it coming >>>> from ??? >>> >>> It was recently removed. >>> >>> 8178499: Remove _ptr_ and _size_ infixes from align functions >>> From yasuenag at gmail.com Fri Aug 4 04:57:13 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Aug 2017 13:57:13 +0900 Subject: HotSpot build failure with GCC 7.1.1 In-Reply-To: <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> Message-ID: Hi David, > I'm still at a loss to understand how the current code even compiles/links > at all with any version of the compiler. ?? I guess Array::size() is not used from any code. For example, clang 4.0.0 in Fedora 26 passes this compilation, however GCC 7.1.1 is failed. I grep'ed following command, but I could not find the use. -------------- grep -nrE 'Array.+align_size_up' * -------------- Most compilers might not check unused declarations. > You removed a "// FIXME" comment - what was that referring to ?? Sorry, I missed. I guess the reason of "FIXME" is known by the author of JDK-8072061. Thanks, Yasumasa 2017-08-04 11:00 GMT+09:00 David Holmes : > Hi Yasumasa, > > On 4/08/2017 10:49 AM, Yasumasa Suenaga wrote: >> >> Thanks Kim, David, >> >> I filed this issue to JBS and uploaded webrev. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ > > > I'm still at a loss to understand how the current code even compiles/links > at all with any version of the compiler. ?? > > You removed a "// FIXME" comment - what was that referring to ?? > > Thanks, > David > > >> I cannot access JPRT. So I need a sponsor. >> >> >> Yasumasa >> >> >> >> 2017-08-04 9:08 GMT+09:00 Kim Barrett : >>>> >>>> On Aug 3, 2017, at 7:12 PM, David Holmes >>>> wrote: >>>> I can't even see a definition of align_size_up - where is it coming from >>>> ??? >>> >>> >>> It was recently removed. >>> >>> 8178499: Remove _ptr_ and _size_ infixes from align functions >>> > From david.holmes at oracle.com Fri Aug 4 05:12:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Aug 2017 15:12:21 +1000 Subject: RFR XXS (8185826) HotSpot build failure with GCC 7.1.1 In-Reply-To: <91a540f0-f2cc-ce46-84b5-dcdcd5e5b570@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> <91a540f0-f2cc-ce46-84b5-dcdcd5e5b570@oracle.com> Message-ID: <4d5473c6-e0b9-ba66-a2e8-e8b827eee9e5@oracle.com> Hi Ioi, On 4/08/2017 2:50 PM, Ioi Lam wrote: > On 8/3/17 7:00 PM, David Holmes wrote: > >> Hi Yasumasa, >> >> On 4/08/2017 10:49 AM, Yasumasa Suenaga wrote: >>> Thanks Kim, David, >>> >>> I filed this issue to JBS and uploaded webrev. Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ >> >> I'm still at a loss to understand how the current code even >> compiles/links at all with any version of the compiler. ?? >> > Hi Yasumasa, thanks for noticing this. > > Sorry, it was my bug. I checked this in as part of JDK-8072061 on Tuesday. > > Apparently older C++ compilers are quite lenient when compiling template > declarations that aren't instantiated. Here's a test case: > > template class X { > static int size() { > return align_size_up(byte_sizeof()); > } > static int byte_sizeof() { > return sizeof(T); > } > }; > > # from gcc 5.4: > $ gcc -c ~/t.cpp && echo $? > 0 > > In our case, presumably, gcc will detect the error when an instantiated > Array type access the size(int, int) method. Ah I see. > However, I added this function during my development, but didn't need it > after all. So this function was never referenced, so all of our existing > compilers never had a chance to generate an error for > > I removed this function and HotSpot built with no error. > > $ hg diff > diff -r 731370f39fcd src/share/vm/oops/array.hpp > --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 > +++ b/src/share/vm/oops/array.hpp Thu Aug 03 21:47:41 2017 -0700 > @@ -134,10 +134,6 @@ > > return (int)words; > } > - static int size(int length, int elm_byte_size) { > - return align_size_up(byte_sizeof(length, elm_byte_size), > BytesPerWord) / BytesPerWord; // FIXME > - } > - > int size() { > return size(_length); > } > > > So I think proper fix is to just remove this function. Sounds good to me. Reviewed! Thanks, David > Thanks > - Ioi > > > > >> You removed a "// FIXME" comment - what was that referring to ?? >> >> Thanks, >> David >> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Yasumasa >>> >>> >>> >>> 2017-08-04 9:08 GMT+09:00 Kim Barrett : >>>>> On Aug 3, 2017, at 7:12 PM, David Holmes >>>>> wrote: >>>>> I can't even see a definition of align_size_up - where is it coming >>>>> from ??? >>>> >>>> It was recently removed. >>>> >>>> 8178499: Remove _ptr_ and _size_ infixes from align functions >>>> > From yasuenag at gmail.com Fri Aug 4 05:17:45 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 4 Aug 2017 14:17:45 +0900 Subject: RFR XXS (8185826) HotSpot build failure with GCC 7.1.1 In-Reply-To: <4d5473c6-e0b9-ba66-a2e8-e8b827eee9e5@oracle.com> References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> <91a540f0-f2cc-ce46-84b5-dcdcd5e5b570@oracle.com> <4d5473c6-e0b9-ba66-a2e8-e8b827eee9e5@oracle.com> Message-ID: Hi Ioi, Your change looks good. I reviewed (OpenJDK name: ysuenaga). Could you push this change? (I cannot access JPRT) Thanks, Yasumasa 2017-08-04 14:12 GMT+09:00 David Holmes : > Hi Ioi, > > On 4/08/2017 2:50 PM, Ioi Lam wrote: >> >> On 8/3/17 7:00 PM, David Holmes wrote: >> >>> Hi Yasumasa, >>> >>> On 4/08/2017 10:49 AM, Yasumasa Suenaga wrote: >>>> >>>> Thanks Kim, David, >>>> >>>> I filed this issue to JBS and uploaded webrev. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ >>> >>> >>> I'm still at a loss to understand how the current code even >>> compiles/links at all with any version of the compiler. ?? >>> >> Hi Yasumasa, thanks for noticing this. >> >> Sorry, it was my bug. I checked this in as part of JDK-8072061 on Tuesday. >> >> Apparently older C++ compilers are quite lenient when compiling template >> declarations that aren't instantiated. Here's a test case: >> >> template class X { >> static int size() { >> return align_size_up(byte_sizeof()); >> } >> static int byte_sizeof() { >> return sizeof(T); >> } >> }; >> >> # from gcc 5.4: >> $ gcc -c ~/t.cpp && echo $? >> 0 >> >> In our case, presumably, gcc will detect the error when an instantiated >> Array type access the size(int, int) method. > > > Ah I see. > >> However, I added this function during my development, but didn't need it >> after all. So this function was never referenced, so all of our existing >> compilers never had a chance to generate an error for >> >> I removed this function and HotSpot built with no error. >> >> $ hg diff >> diff -r 731370f39fcd src/share/vm/oops/array.hpp >> --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 >> +++ b/src/share/vm/oops/array.hpp Thu Aug 03 21:47:41 2017 -0700 >> @@ -134,10 +134,6 @@ >> >> return (int)words; >> } >> - static int size(int length, int elm_byte_size) { >> - return align_size_up(byte_sizeof(length, elm_byte_size), >> BytesPerWord) / BytesPerWord; // FIXME >> - } >> - >> int size() { >> return size(_length); >> } >> >> >> So I think proper fix is to just remove this function. > > > Sounds good to me. Reviewed! > > Thanks, > David > >> Thanks >> - Ioi >> >> >> >> >>> You removed a "// FIXME" comment - what was that referring to ?? >>> >>> Thanks, >>> David >>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> 2017-08-04 9:08 GMT+09:00 Kim Barrett : >>>>>> >>>>>> On Aug 3, 2017, at 7:12 PM, David Holmes >>>>>> wrote: >>>>>> I can't even see a definition of align_size_up - where is it coming >>>>>> from ??? >>>>> >>>>> >>>>> It was recently removed. >>>>> >>>>> 8178499: Remove _ptr_ and _size_ infixes from align functions >>>>> >> > From ioi.lam at oracle.com Fri Aug 4 05:37:44 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 3 Aug 2017 22:37:44 -0700 Subject: RFR XXS (8185826) HotSpot build failure with GCC 7.1.1 In-Reply-To: References: <3d373354-cd4f-0659-270c-94e263e9afa8@gmail.com> <0488b2e8-e7aa-178c-6338-df743013c302@oracle.com> <5EF45293-6D55-4190-AD6C-A97590E3B1EB@oracle.com> <20a48f4c-fd78-717c-6f96-e2f901a8a035@oracle.com> <91a540f0-f2cc-ce46-84b5-dcdcd5e5b570@oracle.com> <4d5473c6-e0b9-ba66-a2e8-e8b827eee9e5@oracle.com> Message-ID: <80ccb0f7-c6b3-68b5-e191-803c462f767c@oracle.com> Yes, I will push it now. Thanks - Ioi On 8/3/17 10:17 PM, Yasumasa Suenaga wrote: > Hi Ioi, > > Your change looks good. > I reviewed (OpenJDK name: ysuenaga). > > Could you push this change? > (I cannot access JPRT) > > > Thanks, > > Yasumasa > > > 2017-08-04 14:12 GMT+09:00 David Holmes : >> Hi Ioi, >> >> On 4/08/2017 2:50 PM, Ioi Lam wrote: >>> On 8/3/17 7:00 PM, David Holmes wrote: >>> >>>> Hi Yasumasa, >>>> >>>> On 4/08/2017 10:49 AM, Yasumasa Suenaga wrote: >>>>> Thanks Kim, David, >>>>> >>>>> I filed this issue to JBS and uploaded webrev. Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185826/webrev.00/ >>>> >>>> I'm still at a loss to understand how the current code even >>>> compiles/links at all with any version of the compiler. ?? >>>> >>> Hi Yasumasa, thanks for noticing this. >>> >>> Sorry, it was my bug. I checked this in as part of JDK-8072061 on Tuesday. >>> >>> Apparently older C++ compilers are quite lenient when compiling template >>> declarations that aren't instantiated. Here's a test case: >>> >>> template class X { >>> static int size() { >>> return align_size_up(byte_sizeof()); >>> } >>> static int byte_sizeof() { >>> return sizeof(T); >>> } >>> }; >>> >>> # from gcc 5.4: >>> $ gcc -c ~/t.cpp && echo $? >>> 0 >>> >>> In our case, presumably, gcc will detect the error when an instantiated >>> Array type access the size(int, int) method. >> >> Ah I see. >> >>> However, I added this function during my development, but didn't need it >>> after all. So this function was never referenced, so all of our existing >>> compilers never had a chance to generate an error for >>> >>> I removed this function and HotSpot built with no error. >>> >>> $ hg diff >>> diff -r 731370f39fcd src/share/vm/oops/array.hpp >>> --- a/src/share/vm/oops/array.hpp Wed Aug 02 18:06:38 2017 -0700 >>> +++ b/src/share/vm/oops/array.hpp Thu Aug 03 21:47:41 2017 -0700 >>> @@ -134,10 +134,6 @@ >>> >>> return (int)words; >>> } >>> - static int size(int length, int elm_byte_size) { >>> - return align_size_up(byte_sizeof(length, elm_byte_size), >>> BytesPerWord) / BytesPerWord; // FIXME >>> - } >>> - >>> int size() { >>> return size(_length); >>> } >>> >>> >>> So I think proper fix is to just remove this function. >> >> Sounds good to me. Reviewed! >> >> Thanks, >> David >> >>> Thanks >>> - Ioi >>> >>> >>> >>> >>>> You removed a "// FIXME" comment - what was that referring to ?? >>>> >>>> Thanks, >>>> David >>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> >>>>> 2017-08-04 9:08 GMT+09:00 Kim Barrett : >>>>>>> On Aug 3, 2017, at 7:12 PM, David Holmes >>>>>>> wrote: >>>>>>> I can't even see a definition of align_size_up - where is it coming >>>>>>> from ??? >>>>>> >>>>>> It was recently removed. >>>>>> >>>>>> 8178499: Remove _ptr_ and _size_ infixes from align functions >>>>>> From csjammi at gmail.com Thu Aug 3 19:28:46 2017 From: csjammi at gmail.com (Chandra Shekahr Jammi) Date: Thu, 03 Aug 2017 19:28:46 +0000 Subject: TLAB pointer movement in Hotspot implementation Message-ID: Hi all, We are working on a project where we want to use com.sun.management.ThreadMXBean#getThreadAllocatedBytes(long) ( https://goo.gl/j5FDDz) to monitor a thread's memory usage via its TLAB. The java doc says that "some Java virtual machine implementations may use object allocation mechanisms that result in a delay between the time an object is allocated and the time its size is recorded". For Hotspot implementation, we traced native call to src/share/vm/services/management.cpp::jmm_GetThreadAllocatedMemory and src/share/vm/runtime/thread.inline.hpp::cooked_allocated_bytes We are still browsing the code. But, we haven't yet figured out if Hotspot's implementation uses object allocation mechanisms that result in a delay between the time an object is allocated and the time its size is recorded. It would be much appreciated if anyone can tell us whether the mechanisms are used in Hotspot could cause a delay. Or, even point us to the code where our time will be best spent. Thanks for your time CJ Here is the java version Im running [root@~]# java -version java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode) From rednaxelafx at gmail.com Fri Aug 4 06:18:45 2017 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 3 Aug 2017 23:18:45 -0700 Subject: TLAB pointer movement in Hotspot implementation In-Reply-To: References: Message-ID: Hi CJ, The JavaThread::_allocated_bytes field is updated every time the thread's TLAB is being retired (ThreadLocalAllocBuffer::make_parsable()), and also when there's a big allocation that goes through the slow path (CollectedHeap::common_mem_allocate_noinit()). So, that keeps track of the cumulative sum of all GC heap memory allocated from this thread. By adding that with the current TLAB's used(), you'd get a fairly accurate number of the allocated bytes of a thread. There's no intentional delay. The only "delay" would come from the fact that the _allocated_bytes field is only loaded with acquire semantics, but not written to with release semantics, so there might be a slight gap there due to lack of synchronization, by design. Hope it helps, Kris On Thu, Aug 3, 2017 at 12:28 PM, Chandra Shekahr Jammi wrote: > Hi all, > We are working on a project where we want to use > com.sun.management.ThreadMXBean#getThreadAllocatedBytes(long) ( > https://goo.gl/j5FDDz) to monitor a thread's memory usage via its TLAB. > The > java doc says that > "some Java virtual machine implementations may use object allocation > mechanisms that result in a delay between the time an object is allocated > and the time its size is recorded". > > For Hotspot implementation, we traced native call to > src/share/vm/services/management.cpp::jmm_GetThreadAllocatedMemory > and > src/share/vm/runtime/thread.inline.hpp::cooked_allocated_bytes > > We are still browsing the code. But, we haven't yet figured out if > Hotspot's implementation uses object allocation mechanisms that result in a > delay between the time an object is allocated and the time its size is > recorded. > > It would be much appreciated if anyone can tell us whether the mechanisms > are used in Hotspot could cause a delay. Or, even point us to the code > where our time will be best spent. > > Thanks for your time > CJ > > > Here is the java version Im running > > [root@~]# java -version > > java version "1.8.0_102" > > Java(TM) SE Runtime Environment (build 1.8.0_102-b14) > > Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode) > From aph at redhat.com Fri Aug 4 08:42:02 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Aug 2017 09:42:02 +0100 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: <4cd2ba0f-394e-3e10-2800-c80a234a582f@redhat.com> Hi, On 03/08/17 20:27, Kim Barrett wrote: > > This response is about the types for a cmpxchg template. I'll respond > to other comments separately. > > It is certainly simpler to implement if the types for all three > arguments are required to be the same. > > I suggested Erik do that, but he reported running into "lots" of > compilation failures. I guess Erik was less persistent than Andrew > in working through them. Given Andrew's reported small number, I've > also done that experiment and looked at the failing cases. I think > (nearly?) all would be improved by making the argument types match. > There's also one similar case for xchg. > > However, there are use-cases that I think are reasonable which don't > immediately fit that restriction. > > (1) cmpxchg(v, p, NULL), to store a pointer if no pointer is already > present. This can be used as an alternative to DCLP. One way to > deal with this might be an overload on std::nullptr_t and use > nullptr, but that requires C++11. We don't have any current uses of > this that I could find, but it's a sufficiently interesting idiom > that I'm relucant to forbid it. But such idiomatic usage could be > wrapped up in its own little package that can deal with the > restriction. > > (2) The use of literals can make getting a type match more > difficult, especially when the pointee type doesn't have portable > syntax (like intx and uintx). But using properly typed named values > solves this, and may be seen as an improvement over magic literal > values. > > (3) Passing a derived pointer as the new value when updating an > atomic pointer seems reasonable to me. A derived pointer compare > value seems somewhat less so. Similarly, new and compare values > that have pointee types that are less cv-qualified than the > destination also seems reasonable. I wonder if our disagreement here is perhaps a philosophical one. C++ overload resolution rules can be obscure and sometimes surprising, especially when using subtypes. A cast or an assignment to a local variable of an exactly matching type serves as a notice to the reader of what is intended. In my view that is beneficial: nothing is hidden. Because Lock-free code is inherently tricky to write, any use of Atomic is going to require careful and sensitive analysis. Casts of argument types will slow down the reader slightly, but most of the difficulty understanding such code is essential complexity rather than accidental due to the rules of the language. > (4) Several of the problematic cases involve enums, which aren't > especially well handled by the original proposal. From Erik's > explorations I knew there were some issues with enums. Having now > looked at some of these cmpxchg problems, I think we should try > harder to deal well with enums. One problem is that C++11 > std::is_enum is at least hard (maybe impossible?) to portabily > emulate in C++98, so some other mechanism would be needed to > recognize them. Probably the simplest is a registration mechanism > for enum types that are used for atomic-access values (e.g a type > predicate defaulting to false, and specializations for relevant enum > types, near their definitions.) I don't understand why this is a problem. Conversions between enums and integer types are well-defined. > (5) One of our goals is to eliminate, as much as possible, the need > for explicit casts and conversions in uses of this API. We think the > existing widespread use of casts makes code difficult to understand > and is a source of bugs. I think the small number of call sites > affected by requiring the cmpxchg types all be the same is in no small > measure a result of that widespread use of casts in calling code. > Unfortunately, Hotspot is rife with boundaries across which there are > type mismatches (and often inconsistencies even within a single > logical chunk of code). We don't think that's a good thing, but it's > the context in which we were developing this change. I believe that eliminating type mismatches is a worthwhile goal, but this proposal doesn't quite do that. Instead, it hides type mismatches by coercing arguments. Despite that we're agreed that we will need -fno-strict-aliasing for some time to come, I still believe that gratuitous undefined behaviour should be eliminated when it is practical to do so. (And new UB shouldn't be added now!) Visible casts between compatible integer types may be ugly, but to my mind they are far less of a sin than unnecessary undefined behaviour. > I think the proposed change may be more lax than it should / could > be, but I think there are valid reasons to not require the types for > cmpxchg arguments to all match. There are, but IMO this is a balance of concerns. On the one hand, a strict requirement for some users of atomic cmpxchg. On the other hand, hundreds (thousands?) of lines of hairy template code. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.schatzl at oracle.com Fri Aug 4 08:46:11 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 04 Aug 2017 10:46:11 +0200 Subject: TLAB pointer movement in Hotspot implementation In-Reply-To: References: Message-ID: <1501836371.2387.21.camel@oracle.com> Hi, On Thu, 2017-08-03 at 23:18 -0700, Krystal Mok wrote: > Hi CJ, > > The JavaThread::_allocated_bytes field is updated every time the > thread's TLAB is being retired > (ThreadLocalAllocBuffer::make_parsable()), and also > when there's a big allocation that goes through the slow path > (CollectedHeap::common_mem_allocate_noinit()). So, that keeps track > of the cumulative sum of all GC heap memory allocated from this > thread. This behavior is exactly what the somewhat generic description also tries to cover: with -XX:UseTLAB (which is by default enabled), you get allocation information on a TLAB basis, not an object basis. > By adding that with the current TLAB's used(), you'd get a fairly > accurate number of the allocated bytes of a thread. There's no > intentional delay. The only "delay" would come from the fact that the > _allocated_bytes field is only loaded with acquire semantics, but not > written to with release semantics, so there might be a slight gap > there due to lack of synchronization, by design. Due to this unsynchronized access between amount of TLAB space allocated and current TLAB's used, it might also happen that the reported number of bytes allocated jumps backwards intermittently. E.g. if you have multiple readings of that bean: reading-1 = JavaThread::_allocated_bytes?(=1000) + TLAB::used() for TLAB X (=3000) ?-> 4000 reading-2 = JavaThread::_allocated_bytes?(=1000) + TLAB::used() for TLAB X+1 (=0) -> 1000 I.e. between the reading of the old value of allocated so far and reading TLAB's used() the thread retired a TLAB and allocated a new one. Or the new value for TLAB::used() X+1 just got visible to the CPU reading the data before the new value of JavaThread::_allocated_bytes. Thanks, ? Thomas From rwestrel at redhat.com Fri Aug 4 08:53:57 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 04 Aug 2017 10:53:57 +0200 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8185723/ That looks good to me. Roland. From aph at redhat.com Fri Aug 4 08:54:02 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Aug 2017 09:54:02 +0100 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: <73fae08f-f5ea-7e97-3419-d1d0ae63c101@redhat.com> Hi, On 04/08/17 00:42, David Holmes wrote: > On 4/08/2017 5:27 AM, Kim Barrett wrote: >> >> However, there are use-cases that I think are reasonable which don't >> immediately fit that restriction. >> >> (1) cmpxchg(v, p, NULL), to store a pointer if no pointer is already >> present. This can be used as an alternative to DCLP. One way to deal > > I thought NULL (aka 0 in a pointer context) was assignable to any > pointer type without any casts. ?? They are, but you have to distinguish between default conversions and overload resolution. If you have two methods int a(foo *p); int a(bar *p); and you have a call a(NULL); the only way to resolve the overload is to do this: a((foo*)NULL); or this: foo *tmp = NULL; a(tmp); C++ is pretty strict about this rule, because it's safer in practice to insist that programmers say exactly what they mean than apply conversions that might be surprising. In several places C++ is fussier than C. For example, you can say this in C but not C++: foo *p = malloc(n); This is a deliberate design deicison. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From 515248659 at qq.com Fri Aug 4 16:29:44 2017 From: 515248659 at qq.com (QQ mail) Date: Sat, 5 Aug 2017 00:29:44 +0800 Subject: Some doubts about the LIR Operand Message-ID: Hi all,? I want to Insert a runtime function to print the StoreField's write barrier information produced by C1 compiler. But it seems that the passed LIR operands sometimes crash the hotspot. Details: First I write a debug function to print the values: jdk8u/hotspot/src/share/vm/c1/c1_Runtime1.cpp JRT_LEAF(void, Runtime1::debug_function(HeapWord* field_addr, HeapWord* target_addr)) ? tty->print(" C1 : after ?decode: src addr: %#lx , dst addr: %#lx \n",(unsigned long)field_addr, (unsigned long)target_addr); JRT_END Then, I build a runtime function invoke ?in :?void LIRGenerator::do_StoreField(StoreField* x) , just after the post_barrier() . The source code: jdk8u/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp void LIRGenerator::do_StoreField(StoreField* x) { ? bool needs_patching = x->needs_patching(); ? bool is_volatile = x->field()->is_volatile(); ? BasicType field_type = x->field_type(); ? bool is_oop = (field_type == T_ARRAY || field_type == T_OBJECT); ? CodeEmitInfo* info = NULL; ? if (needs_patching) { ? ? assert(x->explicit_null_check() == NULL, "can't fold null check into patching field access"); ? ? info = state_for(x, x->state_before()); ? } else if (x->needs_null_check()) { ? ? NullCheck* nc = x->explicit_null_check(); ? ? if (nc == NULL) { ? ? ? info = state_for(x); ? ? } else { ? ? ? info = state_for(nc); ? ? } ? } ? LIRItem object(x->obj(), this); ? LIRItem value(x->value(), ?this); ? object.load_item(); ? if (is_volatile || needs_patching) { ? ? // load item if field is volatile (fewer special cases for volatiles) ? ? // load item if field not initialized ? ? // load item if field not constant ? ? // because of code patching we cannot inline constants ? ? if (field_type == T_BYTE || field_type == T_BOOLEAN) { ? ? ? value.load_byte_item(); ? ? } else ?{ ? ? ? value.load_item(); ? ? } ? } else { ? ? value.load_for_store(field_type); ? } ? set_no_result(x); #ifndef PRODUCT ? if (PrintNotLoaded && needs_patching) { ? ? tty->print_cr(" ? ###class not loaded at store_%s bci %d", ? ? ? ? ? ? ? ? ? x->is_static() ? ?"static" : "field", x->printable_bci()); ? } #endif ? if (x->needs_null_check() && ? ? ? (needs_patching || ? ? ? ?MacroAssembler::needs_explicit_null_check(x->offset()))) { ? ? // emit an explicit null check because the offset is too large ? ? __ null_check(object.result(), new CodeEmitInfo(info)); ? } ? LIR_Address* address; ? if (needs_patching) { ? ? // we need to patch the offset in the instruction so don't allow ? ? // generate_address to try to be smart about emitting the -1. ? ? // Otherwise the patching code won't know how to find the ? ? // instruction to patch. ? ? address = new LIR_Address(object.result(), PATCHED_ADDR, field_type); ? } else { ? ? address = generate_address(object.result(), x->offset(), field_type); ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar_release(); ? } ? if (is_oop) { ? ? // Do the pre-write barrier, if any. ? ? pre_barrier(LIR_OprFact::address(address), ? ? ? ? ? ? ? ? LIR_OprFact::illegalOpr /* pre_val */, ? ? ? ? ? ? ? ? true /* do_load*/, ? ? ? ? ? ? ? ? needs_patching, ? ? ? ? ? ? ? ? (info ? new CodeEmitInfo(info) : NULL)); ? } ? if (is_volatile && !needs_patching) { ? ? volatile_field_store(value.result(), address, info); ? } else { ? ? LIR_PatchCode patch_code = needs_patching ? lir_patch_normal : lir_patch_none; ? ? __ store(value.result(), address, info, patch_code); ? } ? if (is_oop) { ? ? // Store to object so mark the card of the header ? ? post_barrier(object.result(), value.result()); ? ? ? //debug ? ? BasicTypeList signature; ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 1st argument, HeapWord* src_addr, ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 2nd argument, HeapWord* target_addr, ? ? CallingConvention* cc = frame_map()->c_calling_convention(&signature); ? ? __ move(object.result(), cc->args()->at(0)); ? ? ? ? ?// &obj.field ?-> 1st arg ? ? __ move(value.result(), cc->args()->at(1)); ? ? ? ? ? // target addr -> 2nd arg ? ? __ call_runtime_leaf( CAST_FROM_FN_PTR(u_char*, Runtime1::debug_function), getThreadTemp(), LIR_OprFact::illegalOpr,cc->args()); ?? ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar(); ? } } Then it sometimes crashes and print the call stack: (gdb) bt #0 ?0x00007ffff7a47c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 ?0x00007ffff7a4b028 in __GI_abort () at abort.c:89 #2 ?0x00007ffff6ce804a in os::abort (dump_core=true) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:1496 #3 ?0x00007ffff6eb4ba2 in VMError::report_and_die (this=0x7fff7b9f7e90) at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/vmError.cpp:1060 #4 ?0x00007ffff684647b in report_vm_error (file=0x7ffff6f610f0 "/home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp", line=420, error_msg=0x7ffff6f612a8 "assert(is_single_cpu() && !is_virtual()) failed", ? ?detail_msg=0x7ffff6f61155 "type check") at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/debug.cpp:226 #5 ?0x00007ffff6673596 in LIR_OprDesc::cpu_regnr (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp:420 #6 ?0x00007ffff666971e in LIR_OprDesc::as_register (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:34 #7 ?0x00007ffff667be52 in LIR_Assembler::const2reg (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, patch_code=lir_patch_none, info=0x0) at /home2/spark06/jdk8u/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:681 #8 ?0x00007ffff6677d2e in LIR_Assembler::move_op (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, type=T_LONG, patch_code=lir_patch_none, info=0x0, pop_fpu_stack=false, unaligned=false, wide=false) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:841 #9 ?0x00007ffff6676dcc in LIR_Assembler::emit_op1 (this=0x7fff7b9f8290, op=0x7ffe5802f9d0) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:523 #10 0x00007ffff666def7 in LIR_Op1::emit_code (this=0x7ffe5802f9d0, masm=0x7fff7b9f8290) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:1103 #11 0x00007ffff6676255 in LIR_Assembler::emit_lir_list (this=0x7fff7b9f8290, list=0x7ffe50056080) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:308 #12 0x00007ffff6676081 in LIR_Assembler::emit_block (this=0x7fff7b9f8290, block=0x7ffe50052390) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:274 #13 0x00007ffff6675e61 in LIR_Assembler::emit_code (this=0x7fff7b9f8290, hir=0x7ffe50054600) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:233 #14 0x00007ffff663564b in Compilation::emit_code_body (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:343 #15 0x00007ffff663593b in Compilation::compile_java_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:395 #16 0x00007ffff6635c31 in Compilation::compile_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:448 #17 0x00007ffff6636275 in Compilation::Compilation (this=0x7fff7b9f8590, compiler=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, osr_bci=-1, buffer_blob=0x7fffe11f5650) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:559 #18 0x00007ffff6638f7e in Compiler::compile_method (this=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, entry_bci=-1) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compiler.cpp:106 #19 0x00007ffff67e20f4 in CompileBroker::invoke_compiler_on_method (task=0x7ffff027d680) at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:2000 #20 0x00007ffff67e1651 in CompileBroker::compiler_thread_loop () at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:1815 #21 0x00007ffff6e58c92 in compiler_thread_entry (thread=0x7ffff01fd800, __the_thread__=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:3233 #22 0x00007ffff6e5402e in JavaThread::thread_main_inner (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1702 #23 0x00007ffff6e53efb in JavaThread::run (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1682 #24 0x00007ffff6ce6b33 in java_start (thread=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:782 #25 0x00007ffff75f7184 in start_thread (arg=0x7fff7b9f9700) at pthread_create.c:312 #26 0x00007ffff7b0effd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 It seems that, the operand , object.result() and value.result() cause the error. But I can?t understand why, if this is a oop store field , I think the object.result() and value.result() should be pointer(LIR_OprPtr) or array address(LIR_Address), Why it cause errors? Can any one give me some advices ? Thank you for your help. Chenxi Wang. From kim.barrett at oracle.com Sun Aug 6 23:32:38 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Aug 2017 19:32:38 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: Here is a start at addressing the various comments. I still owe email responses to some comments, but wanted to get this out first. http://cr.openjdk.java.net/~kbarrett/cmpxchg_template_20170806/webrev/ So far this only deals with cmpxchg, and then only for linux-x86/64. It builds and passes basic tests. I want to get feedback on this before spending time on other platforms, other operations, and more extensive testing. The metaprogramming support layer has been substantially reduced and simplified. IntegerTypes is still there, but is more focused, with a very small public API. It also badly needs a new name, but I'll worry about that later. Floating point types are still there; they can be dropped easily enough (and reinstated if later needed). I've kept them for now because they are easy (which is itself somewhat interesting), and because I don't recall whether later GC interface work needed it. I've included a mechanism for dealing with thin wrappers over primitive types. The driver for this is oop, which is normally just a typedef for oopDesc*, but is a class with an oopDesc* member when CHECK_UNHANDLED_OOPS is defined (such as during fastdebug builds). We (Erik and I) knew we would need something there, if only for the case of oop, but hadn't agreed on a solution. Well, I'm proposing one here. I've included a mechanism for dealing with enums. The previously proposed change didn't handle them, as recognizing enums requires a lot more metaprogramming, since we don't have C++11 std::is_enum. And as mentioned earlier, I now think we need to try harder in this area. The approach being taken is the registration mechanism I mentioned in earlier email. The reason for including this is to allow filtering and dispatching involving enum types, which are *not* integral types, even though conversions are supported. New files for metaprogramming: metaprogramming/integerTypes.hpp metaprogramming/registeredEnum.hpp Atomic::cmpxchg is still changed to be function template. And it still has three different template parameters. But there are more constraints on the parameters, encoded in the specializations for CmpxchgImpl. (Note that CmpxchgImpl isn't necessary; we could accomplish the same dispatch via SFINAEed specializations for cmpxchg. I just prefer the class vs the (IMO) syntactically horried syntax for SFINAE of function templates. C++11 improves that a lot. Erik prefers SFINAE of function templates rather than introducing a helper class template like CmpxchgImpl.) That front-end uses private Atomic::PlatformCmpxchg to perform . Specializations are function objects with a template operator() with signature T(T, T volatile*, T, order). Only Linux x86/64 updated so far. That makes use of the existing inline assembly, but wrapped in templates rather than functions with fixed parameter types. Replacing the assembly code with calls to gcc's __sync_compare_and_swap would be syntactically trivial (and indeed builds without any problems). I've also added bool Atomic::conditional_store_ptr(T, D volatile*), for the idiom of storing a value if the old value is NULL. It turns out there are about 25 occurrences of this idiom in Hotspot, so a utility for it seems warranted. The current implementation is just a straightforward wrapper around cmpxchg, which means it can't take advantage of gcc's __sync_bool_compare_and_swap. That can be dealt with later if desired. I also had to modify a few uses of cmpxchg to get this to compile. These are presumably the same ones that Andrew encountered. Changed files for Atomic: runtime/atomic.hpp os_cpu/linux_x86/vm/atomic_linux_x86.hpp Changed files for uses, so atomic changes compile: aot/aotCodeHeap.cpp aot/aotCodeHeap.hpp gc/parallel/psParallelCompact.hpp gc/shared/workgroup.cpp runtime/os.cpp [Plus one additional closed change.] I then replaced a few uses of cmpxchg_ptr with cmpxchg, taking advantage of the new API. This eliminated a number of casts. There are still about 110-120 uses of cmpxchg_ptr remaining. Changed files for cmpxchg_ptr removal: oops/oop.inline.hpp -- demonstrates oop translation utilities/bitMap.cpp utilities/bitMap.inline.hpp I'm looking for feedback on this before I try to carry it any further. From david.holmes at oracle.com Mon Aug 7 01:18:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Aug 2017 11:18:46 +1000 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: <2e85182c-8253-25ab-cd94-09a4e8bda2cb@oracle.com> Hi Kim, On 7/08/2017 9:32 AM, Kim Barrett wrote: > Here is a start at addressing the various comments. I still owe email > responses to some comments, but wanted to get this out first. > > http://cr.openjdk.java.net/~kbarrett/cmpxchg_template_20170806/webrev/ > > So far this only deals with cmpxchg, and then only for linux-x86/64. > It builds and passes basic tests. I want to get feedback on this > before spending time on other platforms, other operations, and more > extensive testing. Pardon my ignorance but I can't follow/read/understand the vast majority of this template code. If I was using this API and got a compile-time error I likely would not have a clue how to try and figure out what was going wrong where. I certainly can not maintain or debug this code, nor explain to someone else how it works. :( David ----- > The metaprogramming support layer has been substantially reduced and > simplified. IntegerTypes is still there, but is more focused, with a > very small public API. It also badly needs a new name, but I'll worry > about that later. > > Floating point types are still there; they can be dropped easily > enough (and reinstated if later needed). I've kept them for now > because they are easy (which is itself somewhat interesting), and > because I don't recall whether later GC interface work needed it. > > I've included a mechanism for dealing with thin wrappers over > primitive types. The driver for this is oop, which is normally just a > typedef for oopDesc*, but is a class with an oopDesc* member when > CHECK_UNHANDLED_OOPS is defined (such as during fastdebug builds). We > (Erik and I) knew we would need something there, if only for the case > of oop, but hadn't agreed on a solution. Well, I'm proposing one here. > > I've included a mechanism for dealing with enums. The previously > proposed change didn't handle them, as recognizing enums requires a > lot more metaprogramming, since we don't have C++11 std::is_enum. And > as mentioned earlier, I now think we need to try harder in this area. > The approach being taken is the registration mechanism I mentioned in > earlier email. The reason for including this is to allow filtering > and dispatching involving enum types, which are *not* integral types, > even though conversions are supported. > > New files for metaprogramming: > metaprogramming/integerTypes.hpp > metaprogramming/registeredEnum.hpp > > Atomic::cmpxchg is still changed to be function template. And it > still has three different template parameters. But there are more > constraints on the parameters, encoded in the specializations for > CmpxchgImpl. (Note that CmpxchgImpl isn't necessary; we could > accomplish the same dispatch via SFINAEed specializations for > cmpxchg. I just prefer the class vs the (IMO) syntactically horried > syntax for SFINAE of function templates. C++11 improves that a lot. > Erik prefers SFINAE of function templates rather than introducing a > helper class template like CmpxchgImpl.) > > That front-end uses private Atomic::PlatformCmpxchg > to perform . Specializations are function objects > with a template operator() with signature T(T, T volatile*, T, order). > Only Linux x86/64 updated so far. That makes use of the existing > inline assembly, but wrapped in templates rather than functions with > fixed parameter types. Replacing the assembly code with calls to > gcc's __sync_compare_and_swap would be syntactically trivial (and > indeed builds without any problems). > > I've also added bool Atomic::conditional_store_ptr(T, D volatile*), > for the idiom of storing a value if the old value is NULL. It turns > out there are about 25 occurrences of this idiom in Hotspot, so a > utility for it seems warranted. The current implementation is just a > straightforward wrapper around cmpxchg, which means it can't take > advantage of gcc's __sync_bool_compare_and_swap. That can be dealt > with later if desired. > > I also had to modify a few uses of cmpxchg to get this to compile. > These are presumably the same ones that Andrew encountered. > > Changed files for Atomic: > runtime/atomic.hpp > os_cpu/linux_x86/vm/atomic_linux_x86.hpp > > Changed files for uses, so atomic changes compile: > aot/aotCodeHeap.cpp > aot/aotCodeHeap.hpp > gc/parallel/psParallelCompact.hpp > gc/shared/workgroup.cpp > runtime/os.cpp > [Plus one additional closed change.] > > I then replaced a few uses of cmpxchg_ptr with cmpxchg, taking > advantage of the new API. This eliminated a number of casts. There > are still about 110-120 uses of cmpxchg_ptr remaining. > > Changed files for cmpxchg_ptr removal: > oops/oop.inline.hpp -- demonstrates oop translation > utilities/bitMap.cpp > utilities/bitMap.inline.hpp > > I'm looking for feedback on this before I try to carry it any further. > From david.holmes at oracle.com Mon Aug 7 03:26:52 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Aug 2017 13:26:52 +1000 Subject: RFR(xs): 8184339: Thread::current_or_null() should not assert if Posix TLS is not yet initialized In-Reply-To: References: <284b9d57-a6b1-6e1c-732d-d01262d07e29@oracle.com> Message-ID: <3add892e-eedd-6af1-c757-8ad71266dddc@oracle.com> Hi Thomas, On 1/08/2017 11:40 PM, Thomas St?fe wrote: > Hi David! > > On Tue, Aug 1, 2017 at 9:33 AM, David Holmes > wrote: > > Hi Thomas, > > Back from vacation ... > > I appreciate the effort to fix this problem, however ... :) > > Thomas St?fe thomas.stuefe at gmail.com > Mon Jul 17 07:00:01 UTC 2017 > Hi all, > > may I please have reviews + a sponsor for the following fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8184339 > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8184339-Thread-current-or-null-shall-not-assert/webrev.00/webrev/ > > > The problem is caused by the fact that Posix TLS cannot be used > before it > is initialized. It is initialized in os::init(). If we use Posix > TLS (eg > via Thread::current()) before, we assert. It is used now (since > JDK-8183925 > >) before > os::init() (see > callstack in bug description). > > > ... those kind of initialization order changes are exactly what the > assertion was supposed to detect! It can be dangerous to use various > VM facilities "too soon" in the initialization sequence. The change > in JDK-8183925 needs a close examination IMHO before relaxing this > guard. :( > > > I agree with you that using a VM facility "too soon" is the core of this > problem. But I am not sure that just forbidding that is a practical > solution, because these pre-init-uses have the tendency to creep up on you: > > There are many functions in the VM which very basic and which are used > without regard for initialization sequence. os::malloc() is one example, > Thread::current_or_null() is another. It is difficult to find pre-init > uses with tests, especially if we have code paths which are only > executed on one platform, like in this case. > > In this case, on AIX, we had two problems, Thread::current_or_null() was > asserting, then it was again used in error handling, asserting again, > which lead to an annoying recursion difficult to entangle (on AIX with > its less-than-optimal debugger at least). > > To prevent this from happening, one would have to guard every > "Thread::current_or_null()" use with something like "if > ThreadLocalStorage.is_initialized()". But I think a more practical > solution would be to keep these basic functions safe to be called > anytime. And maybe make this a clear part of the interface, and test > this too. Similar to the Posix list of functions safe to be called in > signal handlers. I don't agree :) I would prefer if nothing were executed prior to VM initialization - certainly "on load" actions and C++ static initialization actions are very fragile because there is nothing in any of that code to indicate that it is being executed in such an environment. So it is far too easy for people to make changes to code that is called from that environment in ways that are incompatible with that environment. Hence using asserts to try and catch when someone makes such a change. The fact such assertion failures can trigger further problems with error reporting just reinforces the basic problem. Error reporting makes lots of assumptions about the state of things and should not be called "very early" in the VM init sequence. > Thread::current_or_null() could return NULL before initialization, > os::malloc() could refrain from using NMT before its initialization ran, > and NMT in turn could tolerate "free/realloc-without-malloc" cases... > > (Note that this discussion feels similar to the "CanUseSafeFetch()" > issue we had two years ago, and we did not agree then either :) :) Cheers, David > > > There are two functions, Thread::current() and > Thread::current_or_null(). > The latter should not assert if Posix TLS is not yet available > but return > NULL instead. This is what callers expect: this function is safe > to call, > but it might not return a valid Thread*. > > > Yes but because the current thread has not yet been set, not because > we're executing the code well before any VM initialization has been > performed! :( > > > I think anyone using Thread::current_or_null() is aware that the thread > pointer returned may be NULL and is prepared to handle it, but does not > care for the reason it is NULL. Like, in error handling. > > Note that this issue currently only comes up at AIX, because AIX > is the > only platform using Posix TLS for Thread::current() - all other > platforms > use Compiler-based TLS (__thread variables). > > > It's also used in the mobile-dev project IIRC, but they don't have > JDK-8183925 applied. > > However, we want to keep the Posix TLS code path alive, so this > may also > affect other platforms. There have been compiler bugs in the > past (e.g. gcc > + glibc) leading to errors when using compiler-based TLS, so it > is good to > have a reliable fallback. > > > Definitely! > > > Good to be in agreement here! > Kind Regards, Thomas > > Cheers, > David > > Thanks, > > Thomas > > From kim.barrett at oracle.com Mon Aug 7 04:34:52 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Aug 2017 00:34:52 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: > On Aug 6, 2017, at 7:32 PM, Kim Barrett wrote: > > Here is a start at addressing the various comments. I still owe email > responses to some comments, but wanted to get this out first. > > http://cr.openjdk.java.net/~kbarrett/cmpxchg_template_20170806/webrev/ I made an "improvement" in the handling of translated types today, but it turned out to just make things more complicated. I've backed it out and updated the webrev in-place. This simplification is neither expected nor intended to address David's complaints about how templates are used in this code. From sgehwolf at redhat.com Mon Aug 7 12:13:41 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 07 Aug 2017 14:13:41 +0200 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 Message-ID: <1502108021.3811.14.camel@redhat.com> Hi, Could I get reviews for this hotspot build issue, please? Some versions of GCC, for example GCC 4.4.7, fail to compile hotspot with dtrace probes compiled in on Linux. The issue is *very* similar to JDK-8047382 which got classified as 9-na, which I believe was incorrect. DTRACE_CLASS* macros need similar treatment in JDK 10 and subsequently 9. Since the changed files are shared, I'd need a sponsor please. Bug: https://bugs.openjdk.java.net/browse/JDK-8185900 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185900/webrev.01/ Testing: JDK 10 hotspot now builds on RHEL-6 with dtrace on (-DDTRACE_ENABLED). Failed previously. Thanks, Severin From david.holmes at oracle.com Mon Aug 7 12:33:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Aug 2017 22:33:33 +1000 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: <1502108021.3811.14.camel@redhat.com> References: <1502108021.3811.14.camel@redhat.com> Message-ID: Hi Severin, On 7/08/2017 10:13 PM, Severin Gehwolf wrote: > Hi, > > Could I get reviews for this hotspot build issue, please? > > Some versions of GCC, for example GCC 4.4.7, fail to compile hotspot We only recently set the minimum supported gcc version to 4.7 for JDK 10: https://bugs.openjdk.java.net/browse/JDK-8184338 http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019518.html David ----- > with dtrace probes compiled in on Linux. The issue is *very* similar to > JDK-8047382 which got classified as 9-na, which I believe was > incorrect. DTRACE_CLASS* macros need similar treatment in JDK 10 and > subsequently 9. > > Since the changed files are shared, I'd need a sponsor please. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185900 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185900/webrev.01/ > > Testing: JDK 10 hotspot now builds on RHEL-6 with dtrace on (-DDTRACE_ENABLED). > Failed previously. > > Thanks, > Severin > From aph at redhat.com Mon Aug 7 13:04:10 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Aug 2017 14:04:10 +0100 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: References: <1502108021.3811.14.camel@redhat.com> Message-ID: <0ead6392-b22e-f686-eb7f-fdf3cd1af471@redhat.com> On 07/08/17 13:33, David Holmes wrote: > We only recently set the minimum supported gcc version to 4.7 for JDK 10: > > https://bugs.openjdk.java.net/browse/JDK-8184338 > http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019518.html Well, yeah, but the distros have their own needs. I think we should take pit on them, where reasonable. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Mon Aug 7 14:59:30 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 7 Aug 2017 10:59:30 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass Message-ID: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> Hi, Please review this small change, which corrects memory type of taskqueue from mtClass to mtGC. Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ Test: hotspot_tier1_runtime: Linux x64 release build Thanks, -Zhengyu From coleen.phillimore at oracle.com Mon Aug 7 15:07:56 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 11:07:56 -0400 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: <0ead6392-b22e-f686-eb7f-fdf3cd1af471@redhat.com> References: <1502108021.3811.14.camel@redhat.com> <0ead6392-b22e-f686-eb7f-fdf3cd1af471@redhat.com> Message-ID: This seems fine and I will sponsor this, any other reviewers? I think it meets trival rules. Coleen On 8/7/17 9:04 AM, Andrew Haley wrote: > On 07/08/17 13:33, David Holmes wrote: >> We only recently set the minimum supported gcc version to 4.7 for JDK 10: >> >> https://bugs.openjdk.java.net/browse/JDK-8184338 >> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019518.html > Well, yeah, but the distros have their own needs. I think we should > take pit on them, where reasonable. > From coleen.phillimore at oracle.com Mon Aug 7 15:08:58 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 11:08:58 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> Message-ID: <1316b227-9d8b-48f1-3a90-17b306501320@oracle.com> I like this change. It looks good. I think it falls into trivial rules so I'll sponsor. Coleen On 8/7/17 10:59 AM, Zhengyu Gu wrote: > Hi, > > Please review this small change, which corrects memory type of > taskqueue from mtClass to mtGC. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 > Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ > > > Test: > hotspot_tier1_runtime: Linux x64 release build > > > > Thanks, > > -Zhengyu From shade at redhat.com Mon Aug 7 15:13:10 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Aug 2017 17:13:10 +0200 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: <1502108021.3811.14.camel@redhat.com> References: <1502108021.3811.14.camel@redhat.com> Message-ID: On 08/07/2017 02:13 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8185900 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185900/webrev.01/ Looks good. Coleen: Count me in, if you need another Reviewer. -Aleksey From shade at redhat.com Mon Aug 7 15:13:37 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Aug 2017 17:13:37 +0200 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> Message-ID: <7fe090ea-868e-a8d5-41b7-63a3685db1b4@redhat.com> On 08/07/2017 04:59 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 > Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ That makes sense. Looks good! -Aleksey From thomas.schatzl at oracle.com Mon Aug 7 15:14:45 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 07 Aug 2017 17:14:45 +0200 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> Message-ID: <1502118885.2950.51.camel@oracle.com> Hi Zhengyu, On Mon, 2017-08-07 at 10:59 -0400, Zhengyu Gu wrote: > Hi, > > Please review this small change, which corrects memory type of > taskqueue? > from mtClass to mtGC. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 > Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ > > > Test: > hotspot_tier1_runtime: Linux x64 release build > ? looks good. Thomas From aph at redhat.com Mon Aug 7 15:23:46 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Aug 2017 16:23:46 +0100 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: <97a3c455-c3d1-7df4-a20f-90f1d1102e6d@redhat.com> On 07/08/17 00:32, Kim Barrett wrote: > I'm looking for feedback on this before I try to carry it any further. I don't like it because it converts pointers to operand types before calling the back end. For example, in here: intptr_t v = CASPTR(&_LockWord, 0, _LBIT); // agro ... the type of the operand LockWord is SplitWord. But the SplitWord * argument gets converted to void* volatile* when we call this: inline static void* cmpxchg_ptr(void* exchange_value, volatile void* dest, void* compare_value, cmpxchg_memory_order order = memory_order_conservative) { return cmpxchg(exchange_value, reinterpret_cast(dest), compare_value, order); Here's what I first wrote: I don't see the point of such a type conversion. We could call cmpxchg with the actual types of the operands, could we not? Why is cmpxchg_ptr even a thing? We're casting away type information for no reason that I can see. Couldn't cmpxchg_ptr() be defined as a template function in such a way that only the back ends that actually need to cast away the types have to do so? That is, if the back ends can define cmpxchg_ptr() themselves without resorting to pointer type conversion, we should let them so so. But rather than sending that message straight away, I tried it. And now I see: the compiler can't get the types right in those cases where we have mismatched operand types in the call. Argh. The only way we can get method resolution to work is to throw way the pointer type information and use void* for everything. At th erisk of being boring, I repeat what I said before: IMO this is not what we should be doing in 2017. We should be looking to the future, and get the types to match now, at the call site. Also, and this is a relatively slight objection, I find myself defining template<> struct Atomic::PlatformCmpxchg<1> VALUE_OBJ_CLASS_SPEC { template T operator()(T exchange_value, T volatile* dest, T compare_value, cmpxchg_memory_order order) const { return ::cmpxchg(exchange_value, dest, compare_value, order); } }; for 1, 4, and 8. I guess that can't be avoided, and in any case it would be easy enough to do it with preprocessor macros. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Mon Aug 7 15:24:07 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 7 Aug 2017 11:24:07 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <1316b227-9d8b-48f1-3a90-17b306501320@oracle.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> <1316b227-9d8b-48f1-3a90-17b306501320@oracle.com> Message-ID: <91b20196-b0c2-d020-af4d-403ac61f7831@redhat.com> Coleen, Please find attached changeset. Thanks for the quick review and sponsoring the change! -Zhengyu On 08/07/2017 11:08 AM, coleen.phillimore at oracle.com wrote: > > I like this change. It looks good. I think it falls into trivial > rules so I'll sponsor. > Coleen > > On 8/7/17 10:59 AM, Zhengyu Gu wrote: >> Hi, >> >> Please review this small change, which corrects memory type of >> taskqueue from mtClass to mtGC. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 >> Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ >> >> >> Test: >> hotspot_tier1_runtime: Linux x64 release build >> >> >> >> Thanks, >> >> -Zhengyu > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8185884.patch Type: text/x-patch Size: 1604 bytes Desc: not available URL: From coleen.phillimore at oracle.com Mon Aug 7 15:41:29 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 11:41:29 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <91b20196-b0c2-d020-af4d-403ac61f7831@redhat.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> <1316b227-9d8b-48f1-3a90-17b306501320@oracle.com> <91b20196-b0c2-d020-af4d-403ac61f7831@redhat.com> Message-ID: <0b4bfafe-d324-84af-a4a9-3c49c79ee49c@oracle.com> You are welcome! Coleen On 8/7/17 11:24 AM, Zhengyu Gu wrote: > Coleen, > > Please find attached changeset. > > Thanks for the quick review and sponsoring the change! > > -Zhengyu > > > > On 08/07/2017 11:08 AM, coleen.phillimore at oracle.com wrote: >> >> I like this change. It looks good. I think it falls into trivial >> rules so I'll sponsor. >> Coleen >> >> On 8/7/17 10:59 AM, Zhengyu Gu wrote: >>> Hi, >>> >>> Please review this small change, which corrects memory type of >>> taskqueue from mtClass to mtGC. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 >>> Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ >>> >>> >>> Test: >>> hotspot_tier1_runtime: Linux x64 release build >>> >>> >>> >>> Thanks, >>> >>> -Zhengyu >> > From coleen.phillimore at oracle.com Mon Aug 7 15:42:41 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 11:42:41 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <0b4bfafe-d324-84af-a4a9-3c49c79ee49c@oracle.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> <1316b227-9d8b-48f1-3a90-17b306501320@oracle.com> <91b20196-b0c2-d020-af4d-403ac61f7831@redhat.com> <0b4bfafe-d324-84af-a4a9-3c49c79ee49c@oracle.com> Message-ID: <4ea1a448-d91b-80c6-6597-1527a913d972@oracle.com> On 8/7/17 11:41 AM, coleen.phillimore at oracle.com wrote: > > You are welcome! I added Aleksey as reviewer to your patch. Coleen > Coleen > > On 8/7/17 11:24 AM, Zhengyu Gu wrote: >> Coleen, >> >> Please find attached changeset. >> >> Thanks for the quick review and sponsoring the change! >> >> -Zhengyu >> >> >> >> On 08/07/2017 11:08 AM, coleen.phillimore at oracle.com wrote: >>> >>> I like this change. It looks good. I think it falls into trivial >>> rules so I'll sponsor. >>> Coleen >>> >>> On 8/7/17 10:59 AM, Zhengyu Gu wrote: >>>> Hi, >>>> >>>> Please review this small change, which corrects memory type of >>>> taskqueue from mtClass to mtGC. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 >>>> Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ >>>> >>>> >>>> Test: >>>> hotspot_tier1_runtime: Linux x64 release build >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>> >> > From zgu at redhat.com Mon Aug 7 15:52:59 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 7 Aug 2017 11:52:59 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <4ea1a448-d91b-80c6-6597-1527a913d972@oracle.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> <1316b227-9d8b-48f1-3a90-17b306501320@oracle.com> <91b20196-b0c2-d020-af4d-403ac61f7831@redhat.com> <0b4bfafe-d324-84af-a4a9-3c49c79ee49c@oracle.com> <4ea1a448-d91b-80c6-6597-1527a913d972@oracle.com> Message-ID: <1dd04a12-c5a8-2b74-3dea-e811115731f9@redhat.com> > On 8/7/17 11:41 AM, coleen.phillimore at oracle.com wrote: >> >> You are welcome! > > I added Aleksey as reviewer to your patch. > Coleen Yes, please. Thank you! -Zhengyu > >> Coleen >> >> On 8/7/17 11:24 AM, Zhengyu Gu wrote: >>> Coleen, >>> >>> Please find attached changeset. >>> >>> Thanks for the quick review and sponsoring the change! >>> >>> -Zhengyu >>> >>> >>> >>> On 08/07/2017 11:08 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> I like this change. It looks good. I think it falls into trivial >>>> rules so I'll sponsor. >>>> Coleen >>>> >>>> On 8/7/17 10:59 AM, Zhengyu Gu wrote: >>>>> Hi, >>>>> >>>>> Please review this small change, which corrects memory type of >>>>> taskqueue from mtClass to mtGC. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ >>>>> >>>>> >>>>> Test: >>>>> hotspot_tier1_runtime: Linux x64 release build >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>> >>> >> > From sgehwolf at redhat.com Mon Aug 7 16:06:51 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 07 Aug 2017 18:06:51 +0200 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: References: <1502108021.3811.14.camel@redhat.com> <0ead6392-b22e-f686-eb7f-fdf3cd1af471@redhat.com> Message-ID: <1502122011.3811.21.camel@redhat.com> On Mon, 2017-08-07 at 11:07 -0400, coleen.phillimore at oracle.com wrote: > This seems fine and I will sponsor this, any other reviewers???I think? > it meets trival rules. Thanks, Coleen. Here is the link to HG export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185900/JDK-8185900.export.patch Cheers, Severin > On 8/7/17 9:04 AM, Andrew Haley wrote: > > On 07/08/17 13:33, David Holmes wrote: > > > We only recently set the minimum supported gcc version to 4.7 for JDK 10: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8184338 > > > http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019518.html > > > > Well, yeah, but the distros have their own needs.??I think we should > > take pit on them, where reasonable. > > > > From zgu at redhat.com Mon Aug 7 16:41:34 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 7 Aug 2017 12:41:34 -0400 Subject: RFR(XXS): 8185884 NMT: taskqueues are miscategorized to mtClass In-Reply-To: <1502118885.2950.51.camel@oracle.com> References: <89657ee7-de8f-14e2-2f99-01e85b1e9a61@redhat.com> <1502118885.2950.51.camel@oracle.com> Message-ID: Thomas, Thanks for the review! -Zhengyu On 08/07/2017 11:14 AM, Thomas Schatzl wrote: > Hi Zhengyu, > > On Mon, 2017-08-07 at 10:59 -0400, Zhengyu Gu wrote: >> Hi, >> >> Please review this small change, which corrects memory type of >> taskqueue >> from mtClass to mtGC. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185884 >> Webrev: http://cr.openjdk.java.net/~zgu/8185884/webrev.00/ >> >> >> Test: >> hotspot_tier1_runtime: Linux x64 release build >> > > looks good. > > Thomas > From kim.barrett at oracle.com Mon Aug 7 17:49:52 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Aug 2017 13:49:52 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <97a3c455-c3d1-7df4-a20f-90f1d1102e6d@redhat.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: > On Aug 7, 2017, at 11:23 AM, Andrew Haley wrote: > > On 07/08/17 00:32, Kim Barrett wrote: >> I'm looking for feedback on this before I try to carry it any further. > > I don't like it because it converts pointers to operand types before > calling the back end. > > For example, in here: > > intptr_t v = CASPTR(&_LockWord, 0, _LBIT); // agro ... > > the type of the operand LockWord is SplitWord. But the SplitWord * > argument gets converted to void* volatile* when we call this: > > inline static void* cmpxchg_ptr(void* exchange_value, volatile void* dest, void* compare_value, cmpxchg_memory_order order = memory_order_conservative) { > return cmpxchg(exchange_value, > reinterpret_cast(dest), > compare_value, > order); > Here's what I first wrote: > > I don't see the point of such a type conversion. We could call > cmpxchg with the actual types of the operands, could we not? Why is > cmpxchg_ptr even a thing? We're casting away type information for > no reason that I can see. > > Couldn't cmpxchg_ptr() be defined as a template function in such a > way that only the back ends that actually need to cast away the > types have to do so? That is, if the back ends can define > cmpxchg_ptr() themselves without resorting to pointer type > conversion, we should let them so so. > > But rather than sending that message straight away, I tried it. And > now I see: the compiler can't get the types right in those cases where > we have mismatched operand types in the call. Argh. The only way we > can get method resolution to work is to throw way the pointer type > information and use void* for everything. At th erisk of being > boring, I repeat what I said before: IMO this is not what we should be > doing in 2017. We should be looking to the future, and get the types > to match now, at the call site. Maybe you?ve forgotten this, from Erik?s original RFR email? "The X_ptr member functions have been deprecated, but are still there and can be used with identical behaviour as they had before. But new code should just use the non-ptr member functions instead.? I converted a few examples in cmpxchg_template_20170806, but there are over 100 left to go, and many of them require caller source changes because they are discarding the relevant type information at the call site in order to conform to the existing API. For folks other than Andrew who haven?t done the experiment, here?s just one example: ../src/share/vm/oops/method.hpp: In member function 'bool Method::init_method_counters(MethodCounters*)': ../src/share/vm/oops/method.hpp:353:88: error: NULL used in arithmetic [-Werror=pointer-arith] return Atomic::cmpxchg_ptr(counters, (volatile void*)&_method_counters, NULL) == NULL; Note the cast of &_method_counters. There are lots like that. I expect most to be easy to fix, and then the information losing cmpxchg_ptr can be removed. But that's a lot more work than I want to do before getting some feedback on the cmpxchg changes. And I?d actually prefer to separate the two tasks, with cmpxchg_ptr cleanup being a followup incremental set of tasks. I expect there to be *some* finicky cases that need careful review, and I?d rather not inflict (or have inflicted upon) reviewers with a large and mostly boringly similar set of changes with the occasional lurking tricky bit. So I think I?m entirely in agreement with Andrew about the target, just not necessarily in the timing of reaching it. > Also, and this is a relatively slight objection, I find myself > defining > > template<> > struct Atomic::PlatformCmpxchg<1> VALUE_OBJ_CLASS_SPEC { > template > T operator()(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) const { > return ::cmpxchg(exchange_value, dest, compare_value, order); > } > }; > > for 1, 4, and 8. I guess that can't be avoided, and in any case it > would be easy enough to do it with preprocessor macros. What?s wrong with template struct Atomic::PlatformCmpxchg VALUE_OBJ_CLASS_SPEC { template T operator()(T nv, T volatile* d, T ov, cmpxchg_memory_order order) const { return ::cmpxchg(nv, d, ov, order); } }; and maybe an explicit specialization on 2 that errors rather than calling ::cmpxchg if that?s needed? I intentionally left the unspecialized case undefined, in part to permit platform backends to do that sort of thing. Though that ought to be a written part of the contract? From coleen.phillimore at oracle.com Mon Aug 7 21:33:11 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 17:33:11 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <97a3c455-c3d1-7df4-a20f-90f1d1102e6d@redhat.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> <97a3c455-c3d1-7df4-a20f-90f1d1102e6d@redhat.com> Message-ID: <93f47228-f2a8-ba87-9019-5ee4e099971e@oracle.com> On 8/7/17 11:23 AM, Andrew Haley wrote: > On 07/08/17 00:32, Kim Barrett wrote: >> I'm looking for feedback on this before I try to carry it any further. > I don't like it because it converts pointers to operand types before > calling the back end. > > For example, in here: > > intptr_t v = CASPTR(&_LockWord, 0, _LBIT); // agro ... > > the type of the operand LockWord is SplitWord. But the SplitWord * > argument gets converted to void* volatile* when we call this: > > inline static void* cmpxchg_ptr(void* exchange_value, volatile void* dest, void* compare_value, cmpxchg_memory_order order = memory_order_conservative) { > return cmpxchg(exchange_value, > reinterpret_cast(dest), > compare_value, > order); I'm confused. Is this CASPTR code a reason to not create a template layer to cast to the base types, or something to clean up once we have it? Having the void* casts in the caller pushes the undefined behavior into all these places. Having it in the template/atomic layer has it in one that can be fixed when we have more modern C++ compilers. > > Here's what I first wrote: > > I don't see the point of such a type conversion. We could call > cmpxchg with the actual types of the operands, could we not? Why is > cmpxchg_ptr even a thing? We're casting away type information for > no reason that I can see. > > Couldn't cmpxchg_ptr() be defined as a template function in such a > way that only the back ends that actually need to cast away the > types have to do so? That is, if the back ends can define > cmpxchg_ptr() themselves without resorting to pointer type > conversion, we should let them so so. > > But rather than sending that message straight away, I tried it. And > now I see: the compiler can't get the types right in those cases where > we have mismatched operand types in the call. Argh. The only way we > can get method resolution to work is to throw way the pointer type > information and use void* for everything. At th erisk of being > boring, I repeat what I said before: IMO this is not what we should be > doing in 2017. We should be looking to the future, and get the types > to match now, at the call site. I agree. I think we should fix this code. It's actually quite disturbing because while the literature may have CAS operands in one order, all over hotspot we have them in another. So this should match the hotspot code. Coleen > Also, and this is a relatively slight objection, I find myself > defining > > template<> > struct Atomic::PlatformCmpxchg<1> VALUE_OBJ_CLASS_SPEC { > template > T operator()(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) const { > return ::cmpxchg(exchange_value, dest, compare_value, order); > } > }; > > for 1, 4, and 8. I guess that can't be avoided, and in any case it > would be easy enough to do it with preprocessor macros. > From david.holmes at oracle.com Mon Aug 7 21:59:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Aug 2017 07:59:00 +1000 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: References: <1502108021.3811.14.camel@redhat.com> <0ead6392-b22e-f686-eb7f-fdf3cd1af471@redhat.com> Message-ID: On 8/08/2017 1:07 AM, coleen.phillimore at oracle.com wrote: > > This seems fine and I will sponsor this, any other reviewers? I think > it meets trival rules. Perhaps. But my concern is that when we make a change to suit an old compiler how do we know it won't trigger some new warning in a new compiler? We have patches going in to fix gcc 7 at one end, and now patches for gcc 4.4.7 at the other, with everything in between. That is why we set a minimum supported compiler version. My understanding was that flags we use now won't work with such old compilers anyway. David > Coleen > > > On 8/7/17 9:04 AM, Andrew Haley wrote: >> On 07/08/17 13:33, David Holmes wrote: >>> We only recently set the minimum supported gcc version to 4.7 for JDK >>> 10: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8184338 >>> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019518.html >> Well, yeah, but the distros have their own needs. I think we should >> take pit on them, where reasonable. >> > From coleen.phillimore at oracle.com Mon Aug 7 22:02:04 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 18:02:04 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: Thank you to Kim for being patient and explaining metaprogramming 101 to me. This latest version seems much simpler and less like "line noise". It's still very dense. Some lines have implicit compiler actions that you pretty much just have to know about. I asked Kim to put a few more comments in places to quickly answer the question, essentially, "why do we need this?" What I like about this is that it has exactly the code needed to cast/transform template types to the types to the sizes that the platforms support. I think it isolates the casts to one place, in the template layer, with checking for compatible sizes. We were talking about this and being able to add more checking in the template layer, eg. that the template destination parameter is declared volatile, which is easy to forget. I think with this code, we can incrementally clean up the rest of the code to study and eliminate casts. Andrew said that lock free programming is tricky to write, but I'd rather not spend time on missed return type casts or blindly copied intptr_t casts rather concentrate on the multiprogramming aspect of the code. From what I understand, the flexibility of template code is necessary for the GC interface, which we all want, and the removal of casting is a bonus. On 8/6/17 7:32 PM, Kim Barrett wrote: > Here is a start at addressing the various comments. I still owe email > responses to some comments, but wanted to get this out first. > > http://cr.openjdk.java.net/~kbarrett/cmpxchg_template_20170806/webrev/ > > So far this only deals with cmpxchg, and then only for linux-x86/64. > It builds and passes basic tests. I want to get feedback on this > before spending time on other platforms, other operations, and more > extensive testing. > > The metaprogramming support layer has been substantially reduced and > simplified. IntegerTypes is still there, but is more focused, with a > very small public API. It also badly needs a new name, but I'll worry > about that later. > > Floating point types are still there; they can be dropped easily > enough (and reinstated if later needed). I've kept them for now > because they are easy (which is itself somewhat interesting), and > because I don't recall whether later GC interface work needed it. > > I've included a mechanism for dealing with thin wrappers over > primitive types. The driver for this is oop, which is normally just a > typedef for oopDesc*, but is a class with an oopDesc* member when > CHECK_UNHANDLED_OOPS is defined (such as during fastdebug builds). We > (Erik and I) knew we would need something there, if only for the case > of oop, but hadn't agreed on a solution. Well, I'm proposing one here. This solution seems pretty understandable to me after learning what a TrueType and FalseType are. See src/share/vm/metaprogramming/integralConstant.hpp Example: http://cr.openjdk.java.net/~kbarrett/cmpxchg_template_20170806/webrev/src/share/vm/oops/oopsHierarchy.hpp.udiff.html > > I've included a mechanism for dealing with enums. The previously > proposed change didn't handle them, as recognizing enums requires a > lot more metaprogramming, since we don't have C++11 std::is_enum. And > as mentioned earlier, I now think we need to try harder in this area. > The approach being taken is the registration mechanism I mentioned in > earlier email. The reason for including this is to allow filtering > and dispatching involving enum types, which are *not* integral types, > even though conversions are supported. This seems pretty understandable to me also, example: http://cr.openjdk.java.net/~kbarrett/cmpxchg_template_20170806/webrev/src/share/vm/aot/aotCodeHeap.hpp.udiff.html > > New files for metaprogramming: > metaprogramming/integerTypes.hpp > metaprogramming/registeredEnum.hpp > > Atomic::cmpxchg is still changed to be function template. And it > still has three different template parameters. But there are more > constraints on the parameters, encoded in the specializations for > CmpxchgImpl. (Note that CmpxchgImpl isn't necessary; we could > accomplish the same dispatch via SFINAEed specializations for > cmpxchg. I just prefer the class vs the (IMO) syntactically horried > syntax for SFINAE of function templates. C++11 improves that a lot. > Erik prefers SFINAE of function templates rather than introducing a > helper class template like CmpxchgImpl.) > > That front-end uses private Atomic::PlatformCmpxchg > to perform . Specializations are function objects > with a template operator() with signature T(T, T volatile*, T, order). > Only Linux x86/64 updated so far. That makes use of the existing > inline assembly, but wrapped in templates rather than functions with > fixed parameter types. Replacing the assembly code with calls to > gcc's __sync_compare_and_swap would be syntactically trivial (and > indeed builds without any problems). > > I've also added bool Atomic::conditional_store_ptr(T, D volatile*), > for the idiom of storing a value if the old value is NULL. It turns > out there are about 25 occurrences of this idiom in Hotspot, so a > utility for it seems warranted. The current implementation is just a > straightforward wrapper around cmpxchg, which means it can't take > advantage of gcc's __sync_bool_compare_and_swap. That can be dealt > with later if desired. > > I also had to modify a few uses of cmpxchg to get this to compile. > These are presumably the same ones that Andrew encountered. > > Changed files for Atomic: > runtime/atomic.hpp > os_cpu/linux_x86/vm/atomic_linux_x86.hpp > > Changed files for uses, so atomic changes compile: > aot/aotCodeHeap.cpp > aot/aotCodeHeap.hpp > gc/parallel/psParallelCompact.hpp > gc/shared/workgroup.cpp > runtime/os.cpp > [Plus one additional closed change.] > > I then replaced a few uses of cmpxchg_ptr with cmpxchg, taking > advantage of the new API. This eliminated a number of casts. There > are still about 110-120 uses of cmpxchg_ptr remaining. > > Changed files for cmpxchg_ptr removal: > oops/oop.inline.hpp -- demonstrates oop translation > utilities/bitMap.cpp > utilities/bitMap.inline.hpp > > I'm looking for feedback on this before I try to carry it any further. > Besides some helpful comment suggestions, I think this looks good to build on. The bitMap changes should be motivating. thanks, Coleen From coleen.phillimore at oracle.com Mon Aug 7 22:27:26 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Aug 2017 18:27:26 -0400 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 In-Reply-To: References: <1502108021.3811.14.camel@redhat.com> <0ead6392-b22e-f686-eb7f-fdf3cd1af471@redhat.com> Message-ID: On 8/7/17 5:59 PM, David Holmes wrote: > On 8/08/2017 1:07 AM, coleen.phillimore at oracle.com wrote: >> >> This seems fine and I will sponsor this, any other reviewers? I >> think it meets trival rules. > > Perhaps. But my concern is that when we make a change to suit an old > compiler how do we know it won't trigger some new warning in a new > compiler? We have patches going in to fix gcc 7 at one end, and now > patches for gcc 4.4.7 at the other, with everything in between. That > is why we set a minimum supported compiler version. My understanding > was that flags we use now won't work with such old compilers anyway. > This seems like a harmless change. If it gives compilation warnings during checkin and fails, then we won't check it in. Thanks, Coleen > David > >> Coleen >> >> >> On 8/7/17 9:04 AM, Andrew Haley wrote: >>> On 07/08/17 13:33, David Holmes wrote: >>>> We only recently set the minimum supported gcc version to 4.7 for >>>> JDK 10: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8184338 >>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019518.html >>> Well, yeah, but the distros have their own needs. I think we should >>> take pit on them, where reasonable. >>> >> From david.holmes at oracle.com Tue Aug 8 01:37:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Aug 2017 11:37:09 +1000 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <97a3c455-c3d1-7df4-a20f-90f1d1102e6d@redhat.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> <97a3c455-c3d1-7df4-a20f-90f1d1102e6d@redhat.com> Message-ID: On 8/08/2017 1:23 AM, Andrew Haley wrote: > On 07/08/17 00:32, Kim Barrett wrote: >> I'm looking for feedback on this before I try to carry it any further. > > I don't like it because it converts pointers to operand types before > calling the back end. > > For example, in here: > > intptr_t v = CASPTR(&_LockWord, 0, _LBIT); // agro ... > > the type of the operand LockWord is SplitWord. But the SplitWord * > argument gets converted to void* volatile* when we call this: > > inline static void* cmpxchg_ptr(void* exchange_value, volatile void* dest, void* compare_value, cmpxchg_memory_order order = memory_order_conservative) { > return cmpxchg(exchange_value, > reinterpret_cast(dest), > compare_value, > order); > > Here's what I first wrote: > > I don't see the point of such a type conversion. We could call > cmpxchg with the actual types of the operands, could we not? Why is > cmpxchg_ptr even a thing? We're casting away type information for > no reason that I can see. While I'd be happy to see cmpxchg_ptr go away, my understanding was that it was needed in the API precisely to avoid (where possible) casts at the call site. I find it very frustrating that we have to jump through so many hoops to get the compiler to get out of the way. The atomic ops work on bits not semantics types - we only need to know how many bits we're dealing with, we don't care about pointers or ints or longs etc. The only semantics we need are that we check for a value that is valid for the destination to hold, and we provide a new value that is valid for the destination to hold. We know what those values are. The compiler doesn't and continually gets in our way because of that - and so we have to jump through hoop to persuade the compiler what we are doing is okay. End of rant. :) Cheers, David ----- > Couldn't cmpxchg_ptr() be defined as a template function in such a > way that only the back ends that actually need to cast away the > types have to do so? That is, if the back ends can define > cmpxchg_ptr() themselves without resorting to pointer type > conversion, we should let them so so. > > But rather than sending that message straight away, I tried it. And > now I see: the compiler can't get the types right in those cases where > we have mismatched operand types in the call. Argh. The only way we > can get method resolution to work is to throw way the pointer type > information and use void* for everything. At th erisk of being > boring, I repeat what I said before: IMO this is not what we should be > doing in 2017. We should be looking to the future, and get the types > to match now, at the call site. > > Also, and this is a relatively slight objection, I find myself > defining > > template<> > struct Atomic::PlatformCmpxchg<1> VALUE_OBJ_CLASS_SPEC { > template > T operator()(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) const { > return ::cmpxchg(exchange_value, dest, compare_value, order); > } > }; > > for 1, 4, and 8. I guess that can't be avoided, and in any case it > would be easy enough to do it with preprocessor macros. > From kim.barrett at oracle.com Tue Aug 8 02:26:54 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Aug 2017 22:26:54 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596CD126.6080100@oracle.com> <596DD713.6080806@oracle.com> <77d5a9e7-b2b0-79e4-effd-903dfe226512@redhat.com> <596E1142.6040708@oracle.com> <3432d11c-5904-a446-1cb5-419627f1794f@redhat.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: <3435B896-5770-45F0-B698-DC765CD08DEA@oracle.com> > On Aug 6, 2017, at 7:32 PM, Kim Barrett wrote: > I've included a mechanism for dealing with thin wrappers over > primitive types. The driver for this is oop, which is normally just a > typedef for oopDesc*, but is a class with an oopDesc* member when > CHECK_UNHANDLED_OOPS is defined (such as during fastdebug builds). We > (Erik and I) knew we would need something there, if only for the case > of oop, but hadn't agreed on a solution. Well, I'm proposing one here. If this really is only needed for oop with CHECK_UNHANDLED_OOPS, an alternative to this general IntegerTypes::Translate mechanism (and making the Atomic/OrderedAccess layer pay attention to it) would be to make that special oop class definition deal with the problem. In oopsHierarchy.hpp, #include atomic.hpp (and eventually orderAccess.hpp) and add definitions like following after the class definition for oop (replacing the proposed Translate specialization) template<> inline oop Atomic::cmpxchg(oop exchange_value, oop volatile* dest, oop compare_value, cmpxchg_memory_order order) { return oop(Atomic::cmpxchg(exchange_value.obj(), reinterpret_cast(dest), compare_value.obj(), order)); } and similarly for all the other Atomic and OrderAccess operations that we want to accept oop arguments. This is kind of ugly, in that it puts all these definitions far away from where one might expect to find them. But then, this whole "oop is a typedef except when it's a class" thing is kind of ugly too. This also runs into include order problems; I'm not sure how hard those would be to deal with. Right now I'm inclined to stick with the Translate mechanism, especially because of the unknowns involved in the include order problem. Consider the Translate mechanism to be the usual additional level of indirection needed to solve a problem. From matthias.baesken at sap.com Tue Aug 8 06:42:06 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 8 Aug 2017 06:42:06 +0000 Subject: [10] RFR (XS) 8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 Message-ID: > On 8/7/17 5:59 PM, David Holmes wrote: > On 8/08/2017 1:07 AM, coleen.phillimore at oracle.com wrote: >> >> This seems fine and I will sponsor this, any other reviewers? I >> think it meets trival rules. > > Perhaps. But my concern is that when we make a change to suit an old > compiler how do we know it won't trigger some new warning in a new > compiler? We have patches going in to fix gcc 7 at one end, and now > patches for gcc 4.4.7 at the other, with everything in between. That > is why we set a minimum supported compiler version. My understanding > was that flags we use now won't work with such old compilers anyway. > Hello, the check for minimum gcc 4.7 was done a while ago because the "-fno-var-tracking-assignments" gcc compiler flag was used in the HS makefiles (JvmOverrideFiles.gmk ) and this flag was not supported in older gcc versions, for example in gcc 4.3 . This was leading to the bad situation that configure was ending successfully but the build was failing (for example on SLES11 with default compiler used ). Best regards, Matthias From thomas.stuefe at gmail.com Tue Aug 8 12:23:17 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 8 Aug 2017 14:23:17 +0200 Subject: RFR(xs): 8184339: Thread::current_or_null() should not assert if Posix TLS is not yet initialized In-Reply-To: <3add892e-eedd-6af1-c757-8ad71266dddc@oracle.com> References: <284b9d57-a6b1-6e1c-732d-d01262d07e29@oracle.com> <3add892e-eedd-6af1-c757-8ad71266dddc@oracle.com> Message-ID: Hi David, On Mon, Aug 7, 2017 at 5:26 AM, David Holmes wrote: > Hi Thomas, > > On 1/08/2017 11:40 PM, Thomas St?fe wrote: > >> Hi David! >> >> On Tue, Aug 1, 2017 at 9:33 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> Back from vacation ... >> >> I appreciate the effort to fix this problem, however ... :) >> >> Thomas St?fe thomas.stuefe at gmail.com >> >> Mon Jul 17 07:00:01 UTC 2017 >> Hi all, >> >> may I please have reviews + a sponsor for the following fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8184339 >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8184339-Thread-cu >> rrent-or-null-shall-not-assert/webrev.00/webrev/ >> > urrent-or-null-shall-not-assert/webrev.00/webrev/> >> >> The problem is caused by the fact that Posix TLS cannot be used >> before it >> is initialized. It is initialized in os::init(). If we use Posix >> TLS (eg >> via Thread::current()) before, we assert. It is used now (since >> JDK-8183925 >> > >) before >> os::init() (see >> callstack in bug description). >> >> >> ... those kind of initialization order changes are exactly what the >> assertion was supposed to detect! It can be dangerous to use various >> VM facilities "too soon" in the initialization sequence. The change >> in JDK-8183925 needs a close examination IMHO before relaxing this >> guard. :( >> >> >> I agree with you that using a VM facility "too soon" is the core of this >> problem. But I am not sure that just forbidding that is a practical >> solution, because these pre-init-uses have the tendency to creep up on you: >> >> There are many functions in the VM which very basic and which are used >> without regard for initialization sequence. os::malloc() is one example, >> Thread::current_or_null() is another. It is difficult to find pre-init uses >> with tests, especially if we have code paths which are only executed on one >> platform, like in this case. >> >> In this case, on AIX, we had two problems, Thread::current_or_null() was >> asserting, then it was again used in error handling, asserting again, which >> lead to an annoying recursion difficult to entangle (on AIX with its >> less-than-optimal debugger at least). >> >> To prevent this from happening, one would have to guard every >> "Thread::current_or_null()" use with something like "if >> ThreadLocalStorage.is_initialized()". But I think a more practical >> solution would be to keep these basic functions safe to be called anytime. >> And maybe make this a clear part of the interface, and test this too. >> Similar to the Posix list of functions safe to be called in signal handlers. >> > > I don't agree :) I would prefer if nothing were executed prior to VM > initialization - certainly "on load" actions and C++ static initialization > actions are very fragile because there is nothing in any of that code to > indicate that it is being executed in such an environment. So it is far too > easy for people to make changes to code that is called from that > environment in ways that are incompatible with that environment. No disagreement from me. In fact, where I have the choice I very much prefer strict rules and asserting them to being tolerant and hiding errors behind a feel-good API. > Hence using asserts to try and catch when someone makes such a change. > > The fact such assertion failures can trigger further problems with error > reporting just reinforces the basic problem. Error reporting makes lots of > assumptions about the state of things and should not be called "very early" > in the VM init sequence. Here I disagree. Error reporting is a perfect example for code that should always work, regardless the phase. Maybe the difference is in how we (SAP) do analyze customer issues compared to how Oracle does it. For us, robust and rich hs-err files are very important. We hardened and expanded error reporting a lot, so much in fact that a large percentage of issues at customer sites can be analyzed with our error reports alone; we often do not need core files. We did this because getting core files from customer systems is complicated and fragile, and tool support for analyzing cores is terrible on some OSes (like AIX or HPUX). So, robust error reporting is one of our most important tool. And quite a lot of problems happen before initialization or also at shutdown, after cleanup. Or maybe in threads which only happen to share the process space with us, without being attached to the VM. Without useful error reporting in those corners support would be much more difficult. That is why I'd like to have a small subset of ubiquitous VM functions to always work, regardless of life phase. Top priority for us is error reporting. > > Thread::current_or_null() could return NULL before initialization, >> os::malloc() could refrain from using NMT before its initialization ran, >> and NMT in turn could tolerate "free/realloc-without-malloc" cases... >> >> (Note that this discussion feels similar to the "CanUseSafeFetch()" issue >> we had two years ago, and we did not agree then either :) >> > > :) > > Cheers, > David > > > Kind Regards, Thomas > >> >> There are two functions, Thread::current() and >> Thread::current_or_null(). >> The latter should not assert if Posix TLS is not yet available >> but return >> NULL instead. This is what callers expect: this function is safe >> to call, >> but it might not return a valid Thread*. >> >> >> Yes but because the current thread has not yet been set, not because >> we're executing the code well before any VM initialization has been >> performed! :( >> >> >> I think anyone using Thread::current_or_null() is aware that the thread >> pointer returned may be NULL and is prepared to handle it, but does not >> care for the reason it is NULL. Like, in error handling. >> >> Note that this issue currently only comes up at AIX, because AIX >> is the >> only platform using Posix TLS for Thread::current() - all other >> platforms >> use Compiler-based TLS (__thread variables). >> >> >> It's also used in the mobile-dev project IIRC, but they don't have >> JDK-8183925 applied. >> >> However, we want to keep the Posix TLS code path alive, so this >> may also >> affect other platforms. There have been compiler bugs in the >> past (e.g. gcc >> + glibc) leading to errors when using compiler-based TLS, so it >> is good to >> have a reliable fallback. >> >> >> Definitely! >> >> >> Good to be in agreement here! >> Kind Regards, Thomas >> >> Cheers, >> David >> >> Thanks, >> >> Thomas >> >> >> From aph at redhat.com Tue Aug 8 13:14:00 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Aug 2017 14:14:00 +0100 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> Message-ID: <5c6b3711-ab1b-1ea1-50e9-1b916eb8a5dc@redhat.com> On 07/08/17 18:49, Kim Barrett wrote: >> On Aug 7, 2017, at 11:23 AM, Andrew Haley wrote: >> >> On 07/08/17 00:32, Kim Barrett wrote: >>> I'm looking for feedback on this before I try to carry it any further. >> >> I don't like it because it converts pointers to operand types before >> calling the back end. >> >> For example, in here: >> >> intptr_t v = CASPTR(&_LockWord, 0, _LBIT); // agro ... >> >> the type of the operand LockWord is SplitWord. But the SplitWord * >> argument gets converted to void* volatile* when we call this: >> >> inline static void* cmpxchg_ptr(void* exchange_value, volatile void* dest, void* compare_value, cmpxchg_memory_order order = memory_order_conservative) { >> return cmpxchg(exchange_value, >> reinterpret_cast(dest), >> compare_value, >> order); >> Here's what I first wrote: >> >> I don't see the point of such a type conversion. We could call >> cmpxchg with the actual types of the operands, could we not? Why is >> cmpxchg_ptr even a thing? We're casting away type information for >> no reason that I can see. >> >> Couldn't cmpxchg_ptr() be defined as a template function in such a >> way that only the back ends that actually need to cast away the >> types have to do so? That is, if the back ends can define >> cmpxchg_ptr() themselves without resorting to pointer type >> conversion, we should let them so so. >> >> But rather than sending that message straight away, I tried it. And >> now I see: the compiler can't get the types right in those cases where >> we have mismatched operand types in the call. Argh. The only way we >> can get method resolution to work is to throw way the pointer type >> information and use void* for everything. At th erisk of being >> boring, I repeat what I said before: IMO this is not what we should be >> doing in 2017. We should be looking to the future, and get the types >> to match now, at the call site. > > Maybe you?ve forgotten this, from Erik?s original RFR email? > > "The X_ptr member functions have been deprecated, but are still > there and can be used with identical behaviour as they had > before. But new code should just use the non-ptr member functions > instead.? No, I hadn't forgotten, it's because I wrote a version of this patch which made the problem go away. But that did result in a few changes at call sites, as discussed. > So I think I?m entirely in agreement with Andrew about the target, > just not necessarily in the timing of reaching it. OK. > What?s wrong with > > template > struct Atomic::PlatformCmpxchg VALUE_OBJ_CLASS_SPEC { > template > T operator()(T nv, T volatile* d, T ov, cmpxchg_memory_order order) const { > return ::cmpxchg(nv, d, ov, order); > } > }; Thanks. That seems to work, but I have no idea why. :-) > and maybe an explicit specialization on 2 that errors rather than > calling ::cmpxchg if that?s needed? No, there's no need for that: if anyone uses cmpxchg(short) that'll just work. I guess I will drop my objection to cmpxchg_ptr() staying as it is, because it looks like we have a general improvement on the status quo. It certainly seems to work, and everything inlines beautifully. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Tue Aug 8 15:26:13 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 8 Aug 2017 11:26:13 -0400 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> Message-ID: <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> Hi! On 08/02/2017 12:35 PM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8185723/ > > OK? Are there any updates on this? It doesn't look like it has been committed yet. Is there also a chance that this gets backported to JDK9? It's not affecting any code outside Zero and PPC32, but fixes a serious crash on the affected target. So, I think that should be in JDK9 as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Aug 8 15:28:43 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 8 Aug 2017 11:28:43 -0400 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> Message-ID: <7374ae4c-4fa6-a868-7e22-170e3ab5b6ac@physik.fu-berlin.de> On 08/08/2017 11:26 AM, John Paul Adrian Glaubitz wrote: > Are there any updates on this? It doesn't look like it has been > committed yet. Oh, never mind. I just noticed I was browsing the wrong JDK10 repository. Why are there actually multiple JDK10 repos? Is this the main one: http://hg.openjdk.java.net/jdk10/hs/hotspot/ > Is there also a chance that this gets backported to JDK9? It's not > affecting any code outside Zero and PPC32, but fixes a serious crash > on the affected target. So, I think that should be in JDK9 as well -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Tue Aug 8 15:36:44 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Aug 2017 16:36:44 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: <7374ae4c-4fa6-a868-7e22-170e3ab5b6ac@physik.fu-berlin.de> References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> <7374ae4c-4fa6-a868-7e22-170e3ab5b6ac@physik.fu-berlin.de> Message-ID: On 08/08/17 16:28, John Paul Adrian Glaubitz wrote: > Oh, never mind. I just noticed I was browsing the wrong JDK10 > repository. Why are there actually multiple JDK10 repos? Heaven only knows. It's complicated. > Is this the main one: > > http://hg.openjdk.java.net/jdk10/hs/hotspot/ It's the one I use. >> Is there also a chance that this gets backported to JDK9? It's not >> affecting any code outside Zero and PPC32, but fixes a serious crash >> on the affected target. So, I think that should be in JDK9 as well I have applied for permission to backport to 9. It might happen. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Tue Aug 8 15:42:05 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 8 Aug 2017 11:42:05 -0400 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> <7374ae4c-4fa6-a868-7e22-170e3ab5b6ac@physik.fu-berlin.de> Message-ID: On 08/08/2017 11:36 AM, Andrew Haley wrote: > On 08/08/17 16:28, John Paul Adrian Glaubitz wrote: >> Oh, never mind. I just noticed I was browsing the wrong JDK10 >> repository. Why are there actually multiple JDK10 repos? > > Heaven only knows. It's complicated. Aye ;-). >> Is this the main one: >> >> http://hg.openjdk.java.net/jdk10/hs/hotspot/ > > It's the one I use. Ok, good. I pulled the proper one then. >>> Is there also a chance that this gets backported to JDK9? It's not >>> affecting any code outside Zero and PPC32, but fixes a serious crash >>> on the affected target. So, I think that should be in JDK9 as well > > I have applied for permission to backport to 9. It might happen. That would be awesome. I have another couple of Zero fixes that I would like to push upstream. OpenJDK-9 fixed now builds fine on all of Debian's Linux targets [1]. Adrian > [1] https://buildd.debian.org/status/package.php?p=openjdk-9&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Tue Aug 8 15:51:09 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Aug 2017 16:51:09 +0100 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> <7374ae4c-4fa6-a868-7e22-170e3ab5b6ac@physik.fu-berlin.de> Message-ID: On 08/08/17 16:42, John Paul Adrian Glaubitz wrote: > I have another couple of Zero fixes that I > would like to push upstream. Send them along. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Tue Aug 8 16:04:59 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 8 Aug 2017 12:04:59 -0400 Subject: [PATCH]: Zero: Define search_string for M68K Message-ID: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> On Linux/m68k, the proper search string for the CPU type is "CPU": root at mama:~# cat /proc/cpuinfo CPU: 68040 MMU: 68040 FPU: 68040 Clocking: 604.5MHz BogoMips: 403.04 Calibration: 2015232 loops root at mama:~# The attached patch adds the definition of search_string for M68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001_Zero-Define-search_string-for-M68K.diff Type: text/x-patch Size: 712 bytes Desc: not available URL: From glaubitz at physik.fu-berlin.de Tue Aug 8 16:08:21 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 8 Aug 2017 12:08:21 -0400 Subject: [PATCH]: Zero: Define search_string for M68K In-Reply-To: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> References: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> Message-ID: <99d5d62b-0793-891d-b55d-b54f99f52416@physik.fu-berlin.de> On 08/08/2017 12:04 PM, John Paul Adrian Glaubitz wrote:> The attached patch adds the definition of search_string for M68k. FWIW, I have signed the Oracle Contributor Agreement [1]. Adrian > [1] http://www.oracle.com/technetwork/community/oca-486395.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Tue Aug 8 20:25:52 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Aug 2017 16:25:52 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: <5c6b3711-ab1b-1ea1-50e9-1b916eb8a5dc@redhat.com> References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> <5c6b3711-ab1b-1ea1-50e9-1b91! 6eb8a5dc@redhat.com> Message-ID: > On Aug 8, 2017, at 9:14 AM, Andrew Haley wrote: > > On 07/08/17 18:49, Kim Barrett wrote: >>> On Aug 7, 2017, at 11:23 AM, Andrew Haley wrote: >>> >>> On 07/08/17 00:32, Kim Barrett wrote: >>>> I'm looking for feedback on this before I try to carry it any further. >>> >>> I don't like it because it converts pointers to operand types before >>> calling the back end. >>> >>> For example, in here: >>> >>> intptr_t v = CASPTR(&_LockWord, 0, _LBIT); // agro ... >>> >>> the type of the operand LockWord is SplitWord. But the SplitWord * >>> argument gets converted to void* volatile* when we call this: >>> >>> inline static void* cmpxchg_ptr(void* exchange_value, volatile void* dest, void* compare_value, cmpxchg_memory_order order = memory_order_conservative) { >>> return cmpxchg(exchange_value, >>> reinterpret_cast(dest), >>> compare_value, >>> order); >>> Here's what I first wrote: >>> >>> I don't see the point of such a type conversion. We could call >>> cmpxchg with the actual types of the operands, could we not? Why is >>> cmpxchg_ptr even a thing? We're casting away type information for >>> no reason that I can see. >>> >>> Couldn't cmpxchg_ptr() be defined as a template function in such a >>> way that only the back ends that actually need to cast away the >>> types have to do so? That is, if the back ends can define >>> cmpxchg_ptr() themselves without resorting to pointer type >>> conversion, we should let them so so. >>> >>> But rather than sending that message straight away, I tried it. And >>> now I see: the compiler can't get the types right in those cases where >>> we have mismatched operand types in the call. Argh. The only way we >>> can get method resolution to work is to throw way the pointer type >>> information and use void* for everything. At th erisk of being >>> boring, I repeat what I said before: IMO this is not what we should be >>> doing in 2017. We should be looking to the future, and get the types >>> to match now, at the call site. >> >> Maybe you?ve forgotten this, from Erik?s original RFR email? >> >> "The X_ptr member functions have been deprecated, but are still >> there and can be used with identical behaviour as they had >> before. But new code should just use the non-ptr member functions >> instead.? > > No, I hadn't forgotten, it's because I wrote a version of this patch > which made the problem go away. But that did result in a few changes > at call sites, as discussed. I recall a discussion about fixing (8-ish) call sites to work with a requirement that all the types match. Those were ordinary cmpxchg, not cmpxchg_ptr. There are *lots* of cmpxchg_ptr call sites that are problematic. Just for starters, there are the 20-25 that pass NULL as the compare_value. >> So I think I?m entirely in agreement with Andrew about the target, >> just not necessarily in the timing of reaching it. > > OK. > >> What?s wrong with >> >> template >> struct Atomic::PlatformCmpxchg VALUE_OBJ_CLASS_SPEC { >> template >> T operator()(T nv, T volatile* d, T ov, cmpxchg_memory_order order) const { >> return ::cmpxchg(nv, d, ov, order); >> } >> }; > > Thanks. That seems to work, but I have no idea why. :-) Atomic declares PlatformCmpxchg (and fails to document it's requirements; I did say this was a prototype...), but does not provide any definition. The above definition is unspecialized on the size, so is applicable for any size value. Since the body code doesn't seem to care about the size (or rather, figures out what it needs on its own, inside ::cmpxchg)... >> and maybe an explicit specialization on 2 that errors rather than >> calling ::cmpxchg if that?s needed? > > No, there's no need for that: if anyone uses cmpxchg(short) that'll > just work. > > I guess I will drop my objection to cmpxchg_ptr() staying as it is, > because it looks like we have a general improvement on the status quo. > It certainly seems to work, and everything inlines beautifully. Great! Thank you. My plan at this point is to focus on finishing cmpxchg, and put just that (with the associated infrastructure) out for review. Then circle back to deal with the other operations, using the new infrastructure, approach, and any additional lessons learned from cmpxchg. That should also make the handoff of remaining work back to Erik go more smoothly when he comes back from vacation and I start mine. > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Wed Aug 9 02:02:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Aug 2017 12:02:28 +1000 Subject: RFR: 8185723: Zero: segfaults on Power PC 32-bit In-Reply-To: References: <83a26b69-e741-6f2a-6551-aeee7165b51f@redhat.com> <694f3e6f-2f5d-0fa0-740b-977d73cc99d2@physik.fu-berlin.de> <7374ae4c-4fa6-a868-7e22-170e3ab5b6ac@physik.fu-berlin.de> Message-ID: On 9/08/2017 1:36 AM, Andrew Haley wrote: > On 08/08/17 16:28, John Paul Adrian Glaubitz wrote: >> Oh, never mind. I just noticed I was browsing the wrong JDK10 >> repository. Why are there actually multiple JDK10 repos? > > Heaven only knows. It's complicated. There have been multiple forests since OpenJDK started. There are fewer now than there used to be and soon there will only be one (and the wheel comes full circle). The main concern to date has been keeping jdk10/jdk10 easy to forward port fixes from 9 to; which necessitated doing all the interesting new hotspot work in the jdk10/hs forest. David ----- >> Is this the main one: >> >> http://hg.openjdk.java.net/jdk10/hs/hotspot/ > > It's the one I use. > >>> Is there also a chance that this gets backported to JDK9? It's not >>> affecting any code outside Zero and PPC32, but fixes a serious crash >>> on the affected target. So, I think that should be in JDK9 as well > > I have applied for permission to backport to 9. It might happen. > From 515248659 at qq.com Fri Aug 11 03:59:24 2017 From: 515248659 at qq.com (Chenxi Wang) Date: Fri, 11 Aug 2017 11:59:24 +0800 Subject: Some doubts about the LIR Operand In-Reply-To: References: Message-ID: I think I know the reason. This crash is caused by the wrong type assigned to arguments. Some times, the object.result() can be T_INT, so it?s better to assign T_OBJECT as the parameter type. ? ? BasicTypeList signature; ? // ?signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 1st argument, HeapWord* src_addr, ? ? signature.append(T_OBJECT); ?// 1st argument,? ? ? signature.append(T_OBJECT); ?// 2nd argument,? ? ? CallingConvention* cc = frame_map()->c_calling_convention(&signature); ? ? __ move(object.result(), cc->args()->at(0)); ? ? ? ?? ? ? __ move(value.result(), cc->args()->at(1)); ? ? ?? ? ? __ call_runtime_leaf( CAST_FROM_FN_PTR(u_char*, Runtime1::debug_function), getThreadTemp(), LIR_OprFact::illegalOpr,cc->args()); I?m new here. If I asked questions in a wrong way, please tell me. I will correct it. Thank you for your help. On 5 August 2017 at 12:29:44 AM, QQ mail (515248659 at qq.com) wrote: Hi all,? I want to Insert a runtime function to print the StoreField's write barrier information produced by C1 compiler. But it seems that the passed LIR operands sometimes crash the hotspot. Details: First I write a debug function to print the values: jdk8u/hotspot/src/share/vm/c1/c1_Runtime1.cpp JRT_LEAF(void, Runtime1::debug_function(HeapWord* field_addr, HeapWord* target_addr)) ? tty->print(" C1 : after ?decode: src addr: %#lx , dst addr: %#lx \n",(unsigned long)field_addr, (unsigned long)target_addr); JRT_END Then, I build a runtime function invoke ?in :?void LIRGenerator::do_StoreField(StoreField* x) , just after the post_barrier() . The source code: jdk8u/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp void LIRGenerator::do_StoreField(StoreField* x) { ? bool needs_patching = x->needs_patching(); ? bool is_volatile = x->field()->is_volatile(); ? BasicType field_type = x->field_type(); ? bool is_oop = (field_type == T_ARRAY || field_type == T_OBJECT); ? CodeEmitInfo* info = NULL; ? if (needs_patching) { ? ? assert(x->explicit_null_check() == NULL, "can't fold null check into patching field access"); ? ? info = state_for(x, x->state_before()); ? } else if (x->needs_null_check()) { ? ? NullCheck* nc = x->explicit_null_check(); ? ? if (nc == NULL) { ? ? ? info = state_for(x); ? ? } else { ? ? ? info = state_for(nc); ? ? } ? } ? LIRItem object(x->obj(), this); ? LIRItem value(x->value(), ?this); ? object.load_item(); ? if (is_volatile || needs_patching) { ? ? // load item if field is volatile (fewer special cases for volatiles) ? ? // load item if field not initialized ? ? // load item if field not constant ? ? // because of code patching we cannot inline constants ? ? if (field_type == T_BYTE || field_type == T_BOOLEAN) { ? ? ? value.load_byte_item(); ? ? } else ?{ ? ? ? value.load_item(); ? ? } ? } else { ? ? value.load_for_store(field_type); ? } ? set_no_result(x); #ifndef PRODUCT ? if (PrintNotLoaded && needs_patching) { ? ? tty->print_cr(" ? ###class not loaded at store_%s bci %d", ? ? ? ? ? ? ? ? ? x->is_static() ? ?"static" : "field", x->printable_bci()); ? } #endif ? if (x->needs_null_check() && ? ? ? (needs_patching || ? ? ? ?MacroAssembler::needs_explicit_null_check(x->offset()))) { ? ? // emit an explicit null check because the offset is too large ? ? __ null_check(object.result(), new CodeEmitInfo(info)); ? } ? LIR_Address* address; ? if (needs_patching) { ? ? // we need to patch the offset in the instruction so don't allow ? ? // generate_address to try to be smart about emitting the -1. ? ? // Otherwise the patching code won't know how to find the ? ? // instruction to patch. ? ? address = new LIR_Address(object.result(), PATCHED_ADDR, field_type); ? } else { ? ? address = generate_address(object.result(), x->offset(), field_type); ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar_release(); ? } ? if (is_oop) { ? ? // Do the pre-write barrier, if any. ? ? pre_barrier(LIR_OprFact::address(address), ? ? ? ? ? ? ? ? LIR_OprFact::illegalOpr /* pre_val */, ? ? ? ? ? ? ? ? true /* do_load*/, ? ? ? ? ? ? ? ? needs_patching, ? ? ? ? ? ? ? ? (info ? new CodeEmitInfo(info) : NULL)); ? } ? if (is_volatile && !needs_patching) { ? ? volatile_field_store(value.result(), address, info); ? } else { ? ? LIR_PatchCode patch_code = needs_patching ? lir_patch_normal : lir_patch_none; ? ? __ store(value.result(), address, info, patch_code); ? } ? if (is_oop) { ? ? // Store to object so mark the card of the header ? ? post_barrier(object.result(), value.result()); ? ? ? //debug ? ? BasicTypeList signature; ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 1st argument, HeapWord* src_addr, ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 2nd argument, HeapWord* target_addr, ? ? CallingConvention* cc = frame_map()->c_calling_convention(&signature); ? ? __ move(object.result(), cc->args()->at(0)); ? ? ? ? ?// &obj.field ?-> 1st arg ? ? __ move(value.result(), cc->args()->at(1)); ? ? ? ? ? // target addr -> 2nd arg ? ? __ call_runtime_leaf( CAST_FROM_FN_PTR(u_char*, Runtime1::debug_function), getThreadTemp(), LIR_OprFact::illegalOpr,cc->args()); ?? ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar(); ? } } Then it sometimes crashes and print the call stack: (gdb) bt #0 ?0x00007ffff7a47c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 ?0x00007ffff7a4b028 in __GI_abort () at abort.c:89 #2 ?0x00007ffff6ce804a in os::abort (dump_core=true) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:1496 #3 ?0x00007ffff6eb4ba2 in VMError::report_and_die (this=0x7fff7b9f7e90) at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/vmError.cpp:1060 #4 ?0x00007ffff684647b in report_vm_error (file=0x7ffff6f610f0 "/home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp", line=420, error_msg=0x7ffff6f612a8 "assert(is_single_cpu() && !is_virtual()) failed", ? ?detail_msg=0x7ffff6f61155 "type check") at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/debug.cpp:226 #5 ?0x00007ffff6673596 in LIR_OprDesc::cpu_regnr (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp:420 #6 ?0x00007ffff666971e in LIR_OprDesc::as_register (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:34 #7 ?0x00007ffff667be52 in LIR_Assembler::const2reg (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, patch_code=lir_patch_none, info=0x0) at /home2/spark06/jdk8u/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:681 #8 ?0x00007ffff6677d2e in LIR_Assembler::move_op (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, type=T_LONG, patch_code=lir_patch_none, info=0x0, pop_fpu_stack=false, unaligned=false, wide=false) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:841 #9 ?0x00007ffff6676dcc in LIR_Assembler::emit_op1 (this=0x7fff7b9f8290, op=0x7ffe5802f9d0) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:523 #10 0x00007ffff666def7 in LIR_Op1::emit_code (this=0x7ffe5802f9d0, masm=0x7fff7b9f8290) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:1103 #11 0x00007ffff6676255 in LIR_Assembler::emit_lir_list (this=0x7fff7b9f8290, list=0x7ffe50056080) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:308 #12 0x00007ffff6676081 in LIR_Assembler::emit_block (this=0x7fff7b9f8290, block=0x7ffe50052390) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:274 #13 0x00007ffff6675e61 in LIR_Assembler::emit_code (this=0x7fff7b9f8290, hir=0x7ffe50054600) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:233 #14 0x00007ffff663564b in Compilation::emit_code_body (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:343 #15 0x00007ffff663593b in Compilation::compile_java_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:395 #16 0x00007ffff6635c31 in Compilation::compile_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:448 #17 0x00007ffff6636275 in Compilation::Compilation (this=0x7fff7b9f8590, compiler=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, osr_bci=-1, buffer_blob=0x7fffe11f5650) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:559 #18 0x00007ffff6638f7e in Compiler::compile_method (this=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, entry_bci=-1) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compiler.cpp:106 #19 0x00007ffff67e20f4 in CompileBroker::invoke_compiler_on_method (task=0x7ffff027d680) at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:2000 #20 0x00007ffff67e1651 in CompileBroker::compiler_thread_loop () at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:1815 #21 0x00007ffff6e58c92 in compiler_thread_entry (thread=0x7ffff01fd800, __the_thread__=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:3233 #22 0x00007ffff6e5402e in JavaThread::thread_main_inner (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1702 #23 0x00007ffff6e53efb in JavaThread::run (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1682 #24 0x00007ffff6ce6b33 in java_start (thread=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:782 #25 0x00007ffff75f7184 in start_thread (arg=0x7fff7b9f9700) at pthread_create.c:312 #26 0x00007ffff7b0effd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 It seems that, the operand , object.result() and value.result() cause the error. But I can?t understand why, if this is a oop store field , I think the object.result() and value.result() should be pointer(LIR_OprPtr) or array address(LIR_Address), Why it cause errors? Can any one give me some advices ? Thank you for your help. Chenxi Wang. From igor.ignatyev at oracle.com Fri Aug 11 04:02:38 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 21:02:38 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 Message-ID: http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html > 14 lines changed: 1 ins; 0 del; 13 mod; Hi all, could you please review this small patch which bumps up jtreg version? besides updating jib profiles and all TEST.ROOT files, the fix updates hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to rely on having "library" test.Empty class in 'test.classes' and put test.Empty class in the workdir instead. testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] Thanks, -- Igor From david.holmes at oracle.com Fri Aug 11 04:22:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 14:22:27 +1000 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> Hi Igor, On 11/08/2017 2:02 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >> 14 lines changed: 1 ins; 0 del; 13 mod; > > Hi all, > > could you please review this small patch which bumps up jtreg version? > besides updating jib profiles and all TEST.ROOT files, That all looks fine (though deploy should not be in there). > the fix updates > hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to > rely on having "library" test.Empty class in 'test.classes' and put > test.Empty class in the workdir instead. Sorry I'm not following this part. You made two changes: 1. Added @library /test/lib What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? Thanks, David ----- > testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Aug 11 04:31:05 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 21:31:05 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> Message-ID: <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> > On Aug 10, 2017, at 9:22 PM, David Holmes wrote: > > Hi Igor, > > On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>> 14 lines changed: 1 ins; 0 del; 13 mod; >> Hi all, >> could you please review this small patch which bumps up jtreg version? >> besides updating jib profiles and all TEST.ROOT files, > > That all looks fine (though deploy should not be in there). > >> the fix updates >> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to >> rely on having "library" test.Empty class in 'test.classes' and put >> test.Empty class in the workdir instead. > > Sorry I'm not following this part. You made two changes: > > 1. Added @library /test/lib /test/lib is needed for ClassFileInstaller. > > What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) existing 'classes' is the directory in hotspot/test/runtime/Metaspace/ which contains source of test.Empty. > > 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. > > How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? test.classes points to the directory w/ classes from a test, but not from test libraries. directories w/ all needed classes (either from a test or from libraries) are added to classpath and 'test.class.path'. ClassFileInstaller uses class loader to get resources, test.Empty will be in CP, so ClassFileInstaller will have access to it. > > Thanks, > David > ----- > >> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >> Thanks, >> -- Igor From david.holmes at oracle.com Fri Aug 11 04:46:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 14:46:59 +1000 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> Message-ID: <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> On 11/08/2017 2:31 PM, Igor Ignatyev wrote: > >> On Aug 10, 2017, at 9:22 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>> Hi all, >>> could you please review this small patch which bumps up jtreg version? >>> besides updating jib profiles and all TEST.ROOT files, >> >> That all looks fine (though deploy should not be in there). >> >>> the fix updates >>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to >>> rely on having "library" test.Empty class in 'test.classes' and put >>> test.Empty class in the workdir instead. >> >> Sorry I'm not following this part. You made two changes: >> >> 1. Added @library /test/lib > /test/lib is needed for ClassFileInstaller. Okay. >> >> What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) > existing 'classes' is the directory in hotspot/test/runtime/Metaspace/ which contains source of test.Empty. Okay. >> >> 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. >> >> How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? > test.classes points to the directory w/ classes from a test, but not from test libraries. directories w/ all needed classes (either from a test or from libraries) are added to classpath and 'test.class.path'. ClassFileInstaller uses class loader to get resources, test.Empty will be in CP, so ClassFileInstaller will have access to it. Sorry still don't understand the change. Where does: @build test.Empty place Empty.class? If not in test.classes then how has this test ever passed? I'm assuming the change is needed because it no longer passes with the updated jtreg. Thanks, David >> >> Thanks, >> David >> ----- >> >>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Fri Aug 11 04:55:04 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 21:55:04 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> Message-ID: > On Aug 10, 2017, at 9:46 PM, David Holmes wrote: > > On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >>> On Aug 10, 2017, at 9:22 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>> Hi all, >>>> could you please review this small patch which bumps up jtreg version? >>>> besides updating jib profiles and all TEST.ROOT files, >>> >>> That all looks fine (though deploy should not be in there). >>> >>>> the fix updates >>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to >>>> rely on having "library" test.Empty class in 'test.classes' and put >>>> test.Empty class in the workdir instead. >>> >>> Sorry I'm not following this part. You made two changes: >>> >>> 1. Added @library /test/lib >> /test/lib is needed for ClassFileInstaller. > > Okay. > >>> >>> What is this doing? (For that matter what is the existing "classes" entry supposed to mean ??? how is "classes" a library?) >> existing 'classes' is the directory in hotspot/test/runtime/Metaspace/ which contains source of test.Empty. > > Okay. > >>> >>> 2. Instead of the test reading from test.classes you are using the ClassfileInstaller to copy the class to the working directory. >>> >>> How does this make a difference to anything? If the test wouldn't find the class in test.classes, doesn't that mean ClassfileInstaller will also fail to find it? >> test.classes points to the directory w/ classes from a test, but not from test libraries. directories w/ all needed classes (either from a test or from libraries) are added to classpath and 'test.class.path'. ClassFileInstaller uses class loader to get resources, test.Empty will be in CP, so ClassFileInstaller will have access to it. > > Sorry still don't understand the change. Where does: > > @build test.Empty > > place Empty.class? If not in test.classes then how has this test ever passed? I'm assuming the change is needed because it no longer passes with the updated jtreg. build places it in a library dedicated directory, in this case it will be 'JTwork/classes//runtime/Metaspace/classes', but 'test.classes' points to 'JTwork/classes//runtime/Metaspace/FragmentMetaspaceSimple.d'. 'test.class.path' will have both (separated by path separator), classpath has these two paths and couple others. > > Thanks, > David > >>> >>> Thanks, >>> David >>> ----- >>> >>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>> Thanks, >>>> -- Igor From ioi.lam at oracle.com Fri Aug 11 05:15:43 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Aug 2017 22:15:43 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: <3944d77a-e7a0-1724-2bd5-5c6d5adc5b86@oracle.com> The hotspot changes look fine to me, but the other repos need to be reviewed by other teams. Thanks - Ioi On 8/10/17 9:02 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >> 14 lines changed: 1 ins; 0 del; 13 mod; > Hi all, > > could you please review this small patch which bumps up jtreg version? > besides updating jib profiles and all TEST.ROOT files, the fix updates hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test not to rely on having "library" test.Empty class in 'test.classes' and put test.Empty class in the workdir instead. > > testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] > > Thanks, > -- Igor From ioi.lam at oracle.com Fri Aug 11 05:23:14 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Aug 2017 22:23:14 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> Message-ID: <55822d40-565e-401d-d807-fbab0749d987@oracle.com> On 8/10/17 9:46 PM, David Holmes wrote: > On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >> >>> On Aug 10, 2017, at 9:22 PM, David Holmes >>> wrote: >>> >>> Hi Igor, >>> >>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>> Hi all, >>>> could you please review this small patch which bumps up jtreg version? >>>> besides updating jib profiles and all TEST.ROOT files, >>> >>> That all looks fine (though deploy should not be in there). >>> >>>> the fix updates >>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test >>>> not to >>>> rely on having "library" test.Empty class in 'test.classes' and put >>>> test.Empty class in the workdir instead. >>> >>> Sorry I'm not following this part. You made two changes: >>> >>> 1. Added @library /test/lib >> /test/lib is needed for ClassFileInstaller. > > Okay. > >>> >>> What is this doing? (For that matter what is the existing "classes" >>> entry supposed to mean ??? how is "classes" a library?) >> existing 'classes' is the directory in >> hotspot/test/runtime/Metaspace/ which contains source of test.Empty. > > Okay. > >>> >>> 2. Instead of the test reading from test.classes you are using the >>> ClassfileInstaller to copy the class to the working directory. >>> >>> How does this make a difference to anything? If the test wouldn't >>> find the class in test.classes, doesn't that mean ClassfileInstaller >>> will also fail to find it? >> test.classes points to the directory w/ classes from a test, but not >> from test libraries. directories w/ all needed classes (either from a >> test or from libraries) are added to classpath and 'test.class.path'. >> ClassFileInstaller uses class loader to get resources, test.Empty >> will be in CP, so ClassFileInstaller will have access to it. > > Sorry still don't understand the change. Where does: > > @build test.Empty > > place Empty.class? If not in test.classes then how has this test ever > passed? I'm assuming the change is needed because it no longer passes > with the updated jtreg. > Hi David, 27 * @build test.Empty puts test.Empty class somewhere in the classpath 28 * @run driver ClassFileInstaller test.Empty ClassFileInstaller uses Class.getResourceAsStream("test/Empty.class") to read the contents of this class (from the CLASSPATH), and writes it to ./test/Empty.class 55 String fileName = "test" + sep + "Empty.class"; 56 File file = new File(fileName); 57 byte buff[] = read(file); here the test reads "./test/Empty.class" into a buffer. (When the test runs, the current directory is the "scratch" directory). The old version of this test assumed that JTREG builds the Empty.class into a certain location, but that has changed with the jtreg 4.2 b08 feature. ClassFileInstaller is the proper way of reading the bytes of class files, and has been used by most other test cases. FragmentMetaspaceSimple seems to be the only exception. Thanks - Ioi > Thanks, > David > >>> >>> Thanks, >>> David >>> ----- >>> >>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>> Thanks, >>>> -- Igor >> From david.holmes at oracle.com Fri Aug 11 05:29:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 15:29:27 +1000 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <55822d40-565e-401d-d807-fbab0749d987@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> <55822d40-565e-401d-d807-fbab0749d987@oracle.com> Message-ID: <37ffb056-12d6-9591-457e-76e02e6248cb@oracle.com> Thanks Ioi, and Igor, for clarifying. David On 11/08/2017 3:23 PM, Ioi Lam wrote: > > > On 8/10/17 9:46 PM, David Holmes wrote: >> On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >>> >>>> On Aug 10, 2017, at 9:22 PM, David Holmes >>>> wrote: >>>> >>>> Hi Igor, >>>> >>>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>>> Hi all, >>>>> could you please review this small patch which bumps up jtreg version? >>>>> besides updating jib profiles and all TEST.ROOT files, >>>> >>>> That all looks fine (though deploy should not be in there). >>>> >>>>> the fix updates >>>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test >>>>> not to >>>>> rely on having "library" test.Empty class in 'test.classes' and put >>>>> test.Empty class in the workdir instead. >>>> >>>> Sorry I'm not following this part. You made two changes: >>>> >>>> 1. Added @library /test/lib >>> /test/lib is needed for ClassFileInstaller. >> >> Okay. >> >>>> >>>> What is this doing? (For that matter what is the existing "classes" >>>> entry supposed to mean ??? how is "classes" a library?) >>> existing 'classes' is the directory in >>> hotspot/test/runtime/Metaspace/ which contains source of test.Empty. >> >> Okay. >> >>>> >>>> 2. Instead of the test reading from test.classes you are using the >>>> ClassfileInstaller to copy the class to the working directory. >>>> >>>> How does this make a difference to anything? If the test wouldn't >>>> find the class in test.classes, doesn't that mean ClassfileInstaller >>>> will also fail to find it? >>> test.classes points to the directory w/ classes from a test, but not >>> from test libraries. directories w/ all needed classes (either from a >>> test or from libraries) are added to classpath and 'test.class.path'. >>> ClassFileInstaller uses class loader to get resources, test.Empty >>> will be in CP, so ClassFileInstaller will have access to it. >> >> Sorry still don't understand the change. Where does: >> >> @build test.Empty >> >> place Empty.class? If not in test.classes then how has this test ever >> passed? I'm assuming the change is needed because it no longer passes >> with the updated jtreg. >> > Hi David, > > 27 * @build test.Empty > > puts test.Empty class somewhere in the classpath > > 28 * @run driver ClassFileInstaller test.Empty > > ClassFileInstaller uses Class.getResourceAsStream("test/Empty.class") to > read the contents of this class (from the CLASSPATH), and writes it to > ./test/Empty.class > > 55 String fileName = "test" + sep + "Empty.class"; > 56 File file = new File(fileName); > 57 byte buff[] = read(file); > > here the test reads "./test/Empty.class" into a buffer. (When the test > runs, the current directory is the "scratch" directory). > > The old version of this test assumed that JTREG builds the Empty.class > into a certain location, but that has changed with the jtreg 4.2 b08 > feature. > > ClassFileInstaller is the proper way of reading the bytes of class > files, and has been used by most other test cases. > FragmentMetaspaceSimple seems to be the only exception. > > Thanks > - Ioi > > > > >> Thanks, >> David >> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>>> Thanks, >>>>> -- Igor >>> > From Roger.Riggs at Oracle.com Fri Aug 11 13:00:36 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 11 Aug 2017 09:00:36 -0400 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: <37ffb056-12d6-9591-457e-76e02e6248cb@oracle.com> References: <5e4e11cc-f2bd-dc88-c01e-e5e19ed7d5d5@oracle.com> <56D2736D-63AB-42D7-9D74-37F0DED65616@oracle.com> <48c4bfd2-7bec-8519-d740-40990b8dc1b6@oracle.com> <55822d40-565e-401d-d807-fbab0749d987@oracle.com> <37ffb056-12d6-9591-457e-76e02e6248cb@oracle.com> Message-ID: Hi Igor, In (some of) the TEST.ROOT files, maintenance of the files can be simplified by removing the version number from the comment. The version that is in jaxp is reasonable: "# Minimum jtreg version" and should be applied to the hotspot, jdk, langtools, and nashorn TEST.ROOT files. Thanks, Roger On 8/11/2017 1:29 AM, David Holmes wrote: > Thanks Ioi, and Igor, for clarifying. > > David > > > On 11/08/2017 3:23 PM, Ioi Lam wrote: >> >> >> On 8/10/17 9:46 PM, David Holmes wrote: >>> On 11/08/2017 2:31 PM, Igor Ignatyev wrote: >>>> >>>>> On Aug 10, 2017, at 9:22 PM, David Holmes >>>>> wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 11/08/2017 2:02 PM, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html >>>>>>> 14 lines changed: 1 ins; 0 del; 13 mod; >>>>>> Hi all, >>>>>> could you please review this small patch which bumps up jtreg >>>>>> version? >>>>>> besides updating jib profiles and all TEST.ROOT files, >>>>> >>>>> That all looks fine (though deploy should not be in there). >>>>> >>>>>> the fix updates >>>>>> hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java test >>>>>> not to >>>>>> rely on having "library" test.Empty class in 'test.classes' and put >>>>>> test.Empty class in the workdir instead. >>>>> >>>>> Sorry I'm not following this part. You made two changes: >>>>> >>>>> 1. Added @library /test/lib >>>> /test/lib is needed for ClassFileInstaller. >>> >>> Okay. >>> >>>>> >>>>> What is this doing? (For that matter what is the existing >>>>> "classes" entry supposed to mean ??? how is "classes" a library?) >>>> existing 'classes' is the directory in >>>> hotspot/test/runtime/Metaspace/ which contains source of test.Empty. >>> >>> Okay. >>> >>>>> >>>>> 2. Instead of the test reading from test.classes you are using the >>>>> ClassfileInstaller to copy the class to the working directory. >>>>> >>>>> How does this make a difference to anything? If the test wouldn't >>>>> find the class in test.classes, doesn't that mean >>>>> ClassfileInstaller will also fail to find it? >>>> test.classes points to the directory w/ classes from a test, but >>>> not from test libraries. directories w/ all needed classes (either >>>> from a test or from libraries) are added to classpath and >>>> 'test.class.path'. ClassFileInstaller uses class loader to get >>>> resources, test.Empty will be in CP, so ClassFileInstaller will >>>> have access to it. >>> >>> Sorry still don't understand the change. Where does: >>> >>> @build test.Empty >>> >>> place Empty.class? If not in test.classes then how has this test >>> ever passed? I'm assuming the change is needed because it no longer >>> passes with the updated jtreg. >>> >> Hi David, >> >> 27 * @build test.Empty >> >> puts test.Empty class somewhere in the classpath >> >> 28 * @run driver ClassFileInstaller test.Empty >> >> ClassFileInstaller uses Class.getResourceAsStream("test/Empty.class") >> to read the contents of this class (from the CLASSPATH), and writes >> it to ./test/Empty.class >> >> 55 String fileName = "test" + sep + "Empty.class"; >> 56 File file = new File(fileName); >> 57 byte buff[] = read(file); >> >> here the test reads "./test/Empty.class" into a buffer. (When the >> test runs, the current directory is the "scratch" directory). >> >> The old version of this test assumed that JTREG builds the >> Empty.class into a certain location, but that has changed with the >> jtreg 4.2 b08 feature. >> >> ClassFileInstaller is the proper way of reading the bytes of class >> files, and has been used by most other test cases. >> FragmentMetaspaceSimple seems to be the only exception. >> >> Thanks >> - Ioi >> >> >> >> >>> Thanks, >>> David >>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> testing: :hotspot_all, {jdk,langtools,nashorn,jaxp}/test/:tier[1-3] >>>>>> Thanks, >>>>>> -- Igor >>>> >> From goetz.lindenmaier at sap.com Fri Aug 11 14:55:40 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Aug 2017 14:55:40 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> Message-ID: <4c61f03b278d46959ca496f7c31db929@sap.com> Hi Gustavo, thanks for the new change and posting to the other lists :) I appreciate the shorter function. I think you need to check for noreg and keep that unchanged, though. Some copyrights are not updated to 2017. Consider it reviewed if the new function is fixed. I posted the webrev on the cr server: http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ and added you as contributor. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Freitag, 11. August 2017 15:55 > To: Doerr, Martin > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > It worked for me Martin. Please check the new webrev: > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > Thanks for the review. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Martin, > > > > Alright. I'll analyze that and update to a new webrev. > > > > Thanks > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > To: Gustavo Serra Scalet ; ppc-aix-port- > > dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > seems like you're preparing new VSR code :-) Nice change, but please > > update the copyright messages in the modified files. > > > > register_ppc.cpp > > to_vsr(): I don't like large code for a trivial computation. I'd prefer > > something like "return as_VectorSRegister(encoding() + 32)". > > > > I can sponsor this change. > > > > Thanks and best regards, > > Martin > > > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Dienstag, 8. August 2017 22:19 > > To: ppc-aix-port-dev at openjdk.java.net > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to > > 64 registers > > > > Hi, > > > > Could you please review this specific PPC64 change to hotspot? The aim > > of these changes is to allow a more complete usage of VSR. I make use of > > these interfaces on an instrinsic that I plan to send next but I decided > > to separate this change and send it first. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > Best regards, > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Fri Aug 11 13:55:26 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 11 Aug 2017 13:55:26 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> Message-ID: It worked for me Martin. Please check the new webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ Thanks for the review. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: quinta-feira, 10 de agosto de 2017 14:21 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Martin, > > Alright. I'll analyze that and update to a new webrev. > > Thanks > > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: quarta-feira, 9 de agosto de 2017 09:58 > To: Gustavo Serra Scalet ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > seems like you're preparing new VSR code :-) Nice change, but please > update the copyright messages in the modified files. > > register_ppc.cpp > to_vsr(): I don't like large code for a trivial computation. I'd prefer > something like "return as_VectorSRegister(encoding() + 32)". > > I can sponsor this change. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Dienstag, 8. August 2017 22:19 > To: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to > 64 registers > > Hi, > > Could you please review this specific PPC64 change to hotspot? The aim > of these changes is to allow a more complete usage of VSR. I make use of > these interfaces on an instrinsic that I plan to send next but I decided > to separate this change and send it first. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > Best regards, > Gustavo Serra Scalet From mandy.chung at oracle.com Fri Aug 11 19:47:25 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 11 Aug 2017 12:47:25 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: On 8/10/17 9:02 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java 26 * @library /test/lib classes 27 * @build test.Empty 28 * @run driver ClassFileInstaller test.Empty jdk.test.lib.compiler.CompilerUtils is easy to use. I would suggest to convert these implicit compile+copy steps into an explicit setup step to compile ${test.src}/test/Empty.java into the destination directory. It'd be easy to read and understand. Bumping up jtreg version is fine. Mandy From coleen.phillimore at oracle.com Fri Aug 11 21:34:00 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 11 Aug 2017 17:34:00 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle Message-ID: Summary: Make an OopHandle type to replace jobject to encapsulate these oop pointers in metadata and module entry. This replaces places where there's a jobject that doesn't point into the JNIHandles, notably things allocated in ClassLoaderData::_handles. There were platform specific changes that I tried to carefully make - can someone test them for s390, aarch64 and ppc? Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, monitoring, parallel class loading and g1class unloading tests. open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8186088 Thanks, Coleen From igor.ignatyev at oracle.com Fri Aug 11 23:05:34 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 11 Aug 2017 16:05:34 -0700 Subject: RFR(XS) : 8186095 : upgrade to jtreg 4.2 b08 In-Reply-To: References: Message-ID: <9C9EF5E5-DD06-4202-BCB0-992D55C1954D@oracle.com> Hi Mandy, thank you for your review. although jdk.test.lib.compiler.CompilerUtils is easy to use, it introduces dependency on jdk.compiler module and currently FragmentMetaspaceSimple.java depends only on java.base module and I would prefer it remain so. Thanks, -- Igor > On Aug 11, 2017, at 12:47 PM, mandy chung wrote: > On 8/10/17 9:02 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8186095/webrev.00/index.html > hotspot/test/runtime/Metaspace/FragmentMetaspaceSimple.java > 26 * @library /test/lib classes > 27 * @build test.Empty > 28 * @run driver ClassFileInstaller test.Empty > > jdk.test.lib.compiler.CompilerUtils is easy to use. I would suggest > to convert these implicit compile+copy steps into an explicit > setup step to compile ${test.src}/test/Empty.java into > the destination directory. It'd be easy to read and understand. > > Bumping up jtreg version is fine. > > Mandy From serguei.spitsyn at oracle.com Sat Aug 12 07:59:57 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 12 Aug 2017 00:59:57 -0700 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: References: Message-ID: <0394520d-6616-dfcd-89fa-c9cf0bcd869e@oracle.com> Hi Coleen, The fix looks good. Thanks, Serguei On 8/11/17 14:34, coleen.phillimore at oracle.com wrote: > Summary: Make an OopHandle type to replace jobject to encapsulate > these oop pointers in metadata and module entry. > > This replaces places where there's a jobject that doesn't point into > the JNIHandles, notably things allocated in ClassLoaderData::_handles. > > There were platform specific changes that I tried to carefully make - > can someone test them for s390, aarch64 and ppc? > > Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, > monitoring, parallel class loading and g1class unloading tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8186088 > > Thanks, > Coleen > > From martin.doerr at sap.com Sat Aug 12 10:01:17 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Sat, 12 Aug 2017 10:01:17 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> Message-ID: Hi Gustavo, I think returning vsnoregi is the better choice. If you want to check the upper limit as well, it should be ">=32". Copyright year needs to be updated in the header (first 2 lines) of the register_ppc files. Thanks and best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Freitag, 11. August 2017 22:03 To: Lindenmaier, Goetz ; Doerr, Martin Cc: 'hotspot-compiler-dev at openjdk.java.net' ; hotspot-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Hello Goetz, About the noreg: if the VectorRegisterImpl::encoding() is not a value from 0-32 expected, it was an invalid VectorRegister which will, in turn, continue to be invalid as VectorSRegister. Anyway, do you want me to add a verification of "if ((encoding() < 0) || (encoding() > 32)) return vsnoregi;" before? Or an assert? And about the copyright, where do you mean? Thanks > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: sexta-feira, 11 de agosto de 2017 11:56 > To: Gustavo Serra Scalet ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > thanks for the new change and posting to the other lists :) > > I appreciate the shorter function. I think you need to check for noreg > and keep that unchanged, though. > Some copyrights are not updated to 2017. > Consider it reviewed if the new function is fixed. > > I posted the webrev on the cr server: > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > and added you as contributor. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Freitag, 11. August 2017 15:55 > > To: Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > It worked for me Martin. Please check the new webrev: > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > Thanks for the review. > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Martin, > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > To: Gustavo Serra Scalet ; > > > ppc-aix-port- dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > seems like you're preparing new VSR code :-) Nice change, but please > > > update the copyright messages in the modified files. > > > > > > register_ppc.cpp > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > prefer something like "return as_VectorSRegister(encoding() + 32)". > > > > > > I can sponsor this change. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Dienstag, 8. August 2017 22:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > > to > > > 64 registers > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? The > > > aim of these changes is to allow a more complete usage of VSR. I > > > make use of these interfaces on an instrinsic that I plan to send > > > next but I decided to separate this change and send it first. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > Best regards, > > > Gustavo Serra Scalet From david.holmes at oracle.com Mon Aug 14 01:04:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Aug 2017 11:04:16 +1000 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: References: Message-ID: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> Hi Coleen, On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: > Summary: Make an OopHandle type to replace jobject to encapsulate these > oop pointers in metadata and module entry. > > This replaces places where there's a jobject that doesn't point into the > JNIHandles, notably things allocated in ClassLoaderData::_handles. > > There were platform specific changes that I tried to carefully make - > can someone test them for s390, aarch64 and ppc? > > Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, > monitoring, parallel class loading and g1class unloading tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8186088 Is it possible to put the declaration of MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp file to avoid the need to add it to the platform specific hpp files? I'm unsure about the OopHandle containing set_atomic. First if it is present then the _obj field should be volatile. But then it also raises the question: if we can race to set this, do we need load-acquire versions of the accessors? Based on the single existing usage I don't think we presently do. But I think it may be cleaner/simpler to not have set_atomic, make the OopHandle immutable, and do the cmpxchg back in the caller code by atomically updating _pd (which should also be volatile even today) with a new OopHandle. Thanks, David > Thanks, > Coleen > > From kim.barrett at oracle.com Mon Aug 14 02:41:04 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 13 Aug 2017 22:41:04 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates Message-ID: Please review this change to Atomic::cmpxchg, making it a function template with a per-platform underlying implementation. This has been broken out from 8184334: "Generalizing Atomic with templates", as the originally proposed change there encountered various objections. This change takes a somewhat different approach to the same problem. One goal is to generalize the API and make it more type-safe, eliminating (nearly) all need for casts by callers. Another is to allow more direct per-platform implementations, especially where there are appropriate compiler intrinsics available. If all goes well and this change is accepted, it is intended that the remainder of Atomic, and later OrderAccess, will be changed in a similar manner as one or more followups. This change to cmpxchg deprecates cmpxchg_ptr. Followup changes will convert existing uses of cmpxchg_ptr and eventually remove it. Followup changes will also update uses of cmpxchg that can be simplified because of the generalized API. The cmpxchg function calls private Atomic::CmpxchgImpl, to select among several cases, based on the argument types. Each case performs some checking and possibly conversion to reach a standard form of the arguments (or fail and report a compile time error), which are then passed to private Atomic::PlatformCmpxchg. The PlatformCmpxchg class is provided by each platform, and performs additional case analysis to generate the appropriate code for the platform. This change involves modifications to all of the existing platform implementations of cmpxchg. I've updated all of the platforms, but only tested those supported by Oracle. I'll need help from the various platform maintainers to check and test my changes. Changes to files can be categorized as follows: New metaprogramming utilities: integerTypes.hpp test_integerTypes.cpp isRegisteredEnum.hpp test_isRegisteredEnum.cpp Change cmpxchg to a template: atomic.hpp Oracle-supported platforms: atomic_bsd_x86.hpp - 64bit only atomic_linux_arm.hpp atomic_linux_x86.hpp atomic_solaris_sparc.hpp solaris_sparc.il atomic_solaris_x86.hpp atomic_windows_x86 Non-Oracle platform changes: atomic_aix_ppc.hpp atomic_bsd_x86.hpp - 32bit atomic_bsd_zero.hpp atomic_linux_aarch.hpp atomic_linux_ppc.hpp atomic_linux_s390.hpp atomic_linux_sparc.hpp atomic_linux_zero.hpp Usage changes required by API change: os_bsd.cpp os_solaris.cpp aotCodeHeap.cpp aotCodeHeap.hpp psParallelCompact.hpp workgroup.cpp oopsHierarchy.hpp os.cpp Example updates of cmpxchg_ptr to cmpxchg: oop.inline.hpp bitMap.cpp bitMap.inline.hpp Some specific issues: - For Solaris (both SPARC and x86), we were using helper functions defined in corresponding .il files. Using the cmpxchg_using_stub helper didn't work; passing a "defined in .il" function as a template parameter didn't work, leading to linker errors. The ideal solution is to use gcc-style inline assembly, which is now supported by Solaris Studio. That change was made for SPARC. However, making that change for x86 ran into related segfaults, so using the .il definition with direct conversions for now, until that problem can be resolved. - I've added the function template Atomic::condition_store_ptr, which is a cmpxchg for pointer types with a NULL compare_value. That might not be the best name for it. - The name IntegerTypes was retained from the original RFR for JDK-8184334. However, that name no longer fits the provided functionality very well, and I think a new name is needed. Something involving Bitwise, or ValueRepresentation perhaps? I'm open to suggestions. - Issues with casts/conversions provided by IntegerTypes. * Conversions between integers and floating point values are supported. It was suggested during the discussion of the RFR for JDK-8184334 that this was not needed, as there are no uses of atomic/ordered floating point values in Hotspot. However, I'm told VarHandles may include atomic floating point values. * Conversions between integers and floating point values are presently implemented using the memcpy technique. While this technique is correct, it is known to be quite poorly optimized by some compilers. It may be necessary to use the "union trick" for performance reasons, even though it is technically undefined behavior. Hotspot already does this elsewhere (and we should merge some of the different conversion handling). * In the original RFR for JDK-8184334, conversions between different integral types of the same size (along with enums) were performed using reinterpret_cast(from_value) This was based on discussion from several months ago, referring to C++03 3.10/15. However, re-reading that section in response to discussion of the RFR for JDK-8184334, I now think that implementation is not supported in many cases needed here, and indeed invokes undefined behavior in those cases. In particular, where 3.10/15 says "- a type that is the signed or unsigned type corresponding to the dynamic type of the object," I interpret this to mean that if the dynamic type of an object is an integral type of a given rank, the value may be accessed using an lvalue of an integral type of the same rank and the opposite sign. (Using the same rank and sign is already permitted, since that's the same type.) I don't think it allows access using an lvalue of an integral type with a different rank. So, for example, a signed int value may be accessed via an unsigned int lvalue. But access via a signed long lvalue is not permitted, even if int and long have the same size. I don't think there is a good way to perform the integral and enum conversions we need, without invoking implementation-defined, unspecified, or undefined behavior. ** The memcpy technique avoids such problems, but as noted above, is known to be quite poorly optimized by some compilers. ** Using static_cast avoids any undefined behavior, but does have cases of implementation-defined or unspecified behavior. (When casting an unsigned value to a signed type, the result may be implementation defined; 5.2.9/2 and 4.7/3. C++11 plus the reinterpret_cast to reference seems to provide possibly multi-step conversion paths that avoid such qualifications on all of the steps.) (When casting an integral value to an enum type, the result may be unspecified; 5.2.9/7. With C++11 , the problem doesn't arise so long as the starting value is appropriate, e.g. we're reversing an enum to integer conversion.) ** Again here, we might consider the "union trick". I haven't changed the implementation from the JDK-8184334 RFR, but I'm presently leaning toward the "union trick", despite previous strong resistance to it. Right now it seems to me to be the best option in practice, despite being disallowed by the standard. It's really too bad the memcpy technique is so poorly supported by some compilers. CR: https://bugs.openjdk.java.net/browse/JDK-8186166 Webrev: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/ Testing: Ad hoc Hotspot nightly test. From kim.barrett at oracle.com Mon Aug 14 02:43:41 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 13 Aug 2017 22:43:41 -0400 Subject: RFR (M): 8184334: Generalizing Atomic with templates In-Reply-To: References: <72F3D5DE-E517-4E3A-81F3-556F5A2222DA@oracle.com> <596E288B.90706@oracle.com> <773a0b64-8273-1a58-a46a-22ae18f927b7@redhat.com> <5970B3FD.607@oracle.com> <8e1d9a32-7e01-b917-df1d-595c4000e4b2@redhat.com> <597226E2.6090803@oracle.com> <2c637e28-8d95-cbaf-c29e-d01867ed9157@redhat.com> <5979FEB6.10506@oracle.com> <3C8BDDFA-1044-47F6-B15C-6DE2085ACF7C@oracle.com> <597B5FC6.5020702@oracle.com> <4e10660a-4dee-78bb-333e-fe99a9c2295d@redhat.com> <13B920D8-8190-4F8A-A18A-16C5BF473732@oracle.com> <5c6b3711-ab1b-1ea1-50e9-1b91! ! 6eb8a5dc@redhat.com> Message-ID: <1E672A08-6768-4039-B4A5-2CA7DC99CA0C@oracle.com> > On Aug 8, 2017, at 4:25 PM, Kim Barrett wrote: > My plan at this point is to focus on finishing cmpxchg, and put just > that (with the associated infrastructure) out for review. Then circle > back to deal with the other operations, using the new infrastructure, > approach, and any additional lessons learned from cmpxchg. That > should also make the handoff of remaining work back to Erik go more > smoothly when he comes back from vacation and I start mine. I?ve just sent to hotspot-dev an RFR for 8186166: Generalize Atomic::cmpxchg with templates. From david.holmes at oracle.com Mon Aug 14 05:08:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Aug 2017 15:08:23 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: Hi Kim, This is an initial partial review. I have to move onto other stuff today so will get back to this tomorrow. On 14/08/2017 12:41 PM, Kim Barrett wrote: > Please review this change to Atomic::cmpxchg, making it a function > template with a per-platform underlying implementation. > > This has been broken out from 8184334: "Generalizing Atomic with > templates", as the originally proposed change there encountered > various objections. This change takes a somewhat different approach > to the same problem. I assume the intent is not to push this yet, so that Erik has a chance to weigh-in when he gets back from vacation? I would not want to see unnecessary churn here. First for the record, and for those who followed the other review thread, I have been learning about template metaprogramming under Kim's guidance. I can see some uses for it, even though it can be extremely difficult to read and interpret. I'm not a Functional Programmer so I don't find the style of it particularly appealing, or "natural". But I'm no longer opposed to its use in moderation and with good taste - and with definite advantage to its use. :) > One goal is to generalize the API and make it more type-safe, > eliminating (nearly) all need for casts by callers. Another is to > allow more direct per-platform implementations, especially where there > are appropriate compiler intrinsics available. Sounds good. > If all goes well and this change is accepted, it is intended that the > remainder of Atomic, and later OrderAccess, will be changed in a > similar manner as one or more followups. Ok. > This change to cmpxchg deprecates cmpxchg_ptr. Followup changes will > convert existing uses of cmpxchg_ptr and eventually remove it. > Followup changes will also update uses of cmpxchg that can be > simplified because of the generalized API. Sounds good. > The cmpxchg function calls private Atomic::CmpxchgImpl, to select > among several cases, based on the argument types. Each case performs > some checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformCmpxchg. The PlatformCmpxchg class > is provided by each platform, and performs additional case analysis to > generate the appropriate code for the platform. Not sure how many levels of indirection we have here yet ... > This change involves modifications to all of the existing platform > implementations of cmpxchg. I've updated all of the platforms, but > only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > New metaprogramming utilities: > integerTypes.hpp > test_integerTypes.cpp > isRegisteredEnum.hpp > test_isRegisteredEnum.cpp > > Change cmpxchg to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > os_bsd.cpp > os_solaris.cpp > aotCodeHeap.cpp > aotCodeHeap.hpp > psParallelCompact.hpp > workgroup.cpp > oopsHierarchy.hpp > os.cpp > > Example updates of cmpxchg_ptr to cmpxchg: > oop.inline.hpp > bitMap.cpp > bitMap.inline.hpp > > Some specific issues: > > - For Solaris (both SPARC and x86), we were using helper functions > defined in corresponding .il files. Using the cmpxchg_using_stub > helper didn't work; passing a "defined in .il" function as a template > parameter didn't work, leading to linker errors. The ideal solution > is to use gcc-style inline assembly, which is now supported by Solaris > Studio. That change was made for SPARC. However, making that change > for x86 ran into related segfaults, so using the .il definition with > direct conversions for now, until that problem can be resolved. We already have an issue open for getting rid of the .il files: https://bugs.openjdk.java.net/browse/JDK-8153076 The template usage probably adds fuel to the argument for doing so. > - I've added the function template Atomic::condition_store_ptr, which > is a cmpxchg for pointer types with a NULL compare_value. That might > not be the best name for it. Definitely not the best name for it. :) replace_if_null seems to describe it more precisely. > - The name IntegerTypes was retained from the original RFR for > JDK-8184334. However, that name no longer fits the provided > functionality very well, and I think a new name is needed. Something > involving Bitwise, or ValueRepresentation perhaps? I'm open to > suggestions. How about PrimitiveTypes? > - Issues with casts/conversions provided by IntegerTypes. > > * Conversions between integers and floating point values are > supported. It was suggested during the discussion of the RFR for > JDK-8184334 that this was not needed, as there are no uses of > atomic/ordered floating point values in Hotspot. However, I'm told > VarHandles may include atomic floating point values. Yes they were added. However at the level of jdk.internal.misc.Unsafe all the FP operations are converted to int/long variants using eg Float.floatToRawIntBits etc. But I'm not convinced we need to complicate things by supporting floating-point Atomic::cmpxchg in the VM's Atomic API. You can only do so by implementing the floatToRawIntBits etc functionality, and there are no native mappings for any "atomic" floating-point operation (ie the only way to do Atomic::inc on a floating=point value is to use cmpxchg.) > * Conversions between integers and floating point values are presently > implemented using the memcpy technique. While this technique is > correct, it is known to be quite poorly optimized by some compilers. > It may be necessary to use the "union trick" for performance reasons, > even though it is technically undefined behavior. Hotspot already > does this elsewhere (and we should merge some of the different > conversion handling). More argument for just avoiding this morass if we don't need to go there. > * In the original RFR for JDK-8184334, conversions between different > integral types of the same size (along with enums) were performed > using > > reinterpret_cast(from_value) > > This was based on discussion from several months ago, referring to > C++03 3.10/15. However, re-reading that section in response to > discussion of the RFR for JDK-8184334, I now think that implementation > is not supported in many cases needed here, and indeed invokes > undefined behavior in those cases. In particular, where 3.10/15 says > > "- a type that is the signed or unsigned type corresponding to the > dynamic type of the object," > > I interpret this to mean that if the dynamic type of an object is an > integral type of a given rank, the value may be accessed using an > lvalue of an integral type of the same rank and the opposite sign. > (Using the same rank and sign is already permitted, since that's the > same type.) I don't think it allows access using an lvalue of an > integral type with a different rank. So, for example, a signed int > value may be accessed via an unsigned int lvalue. But access via a > signed long lvalue is not permitted, even if int and long have the > same size. > > I don't think there is a good way to perform the integral and enum > conversions we need, without invoking implementation-defined, > unspecified, or undefined behavior. > > ** The memcpy technique avoids such problems, but as noted above, is > known to be quite poorly optimized by some compilers. > > ** Using static_cast avoids any undefined behavior, but does have > cases of implementation-defined or unspecified behavior. (When > casting an unsigned value to a signed type, the result may be > implementation defined; 5.2.9/2 and 4.7/3. C++11 plus > the reinterpret_cast to reference seems to provide possibly multi-step > conversion paths that avoid such qualifications on all of the steps.) > (When casting an integral value to an enum type, the result may be > unspecified; 5.2.9/7. With C++11 , the problem doesn't > arise so long as the starting value is appropriate, e.g. we're > reversing an enum to integer conversion.) > > ** Again here, we might consider the "union trick". > > I haven't changed the implementation from the JDK-8184334 RFR, but I'm > presently leaning toward the "union trick", despite previous strong > resistance to it. Right now it seems to me to be the best option in > practice, despite being disallowed by the standard. It's really too > bad the memcpy technique is so poorly supported by some compilers. I find that all rather dismaying. > CR: > https://bugs.openjdk.java.net/browse/JDK-8186166 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/ Looking at the new metaprogramming files first: src/share/vm/metaprogramming/integerTypes.hpp With a bit of exertion I can read all this and am 90% confident I understand what they do. src/share/vm/metaprogramming/isRegisteredEnum.hpp My initial personal preference here is to see registered enum types added to this header file rather than as template specializations at the point of use. Is that reasonable/feasible, or are there reasons to spread this around? test/native/metaprogramming/test_integerTypes.cpp test/native/metaprogramming/test_isRegisteredEnum.cpp Seems minimalist but ok. Aside: I find it slightly limiting that because these templates involve compile-time checks, that we can't actually write negative tests. Seems to me that when writing the templates you had to write a test case that will fail, to verify the correctness of the template, but you can't check-in that testcase. Maybe we need a test harness that can handle 'tests' that simply fail to compile ... ? --- That's all for now. Thanks, David ----- > Testing: > Ad hoc Hotspot nightly test. > > From glaubitz at physik.fu-berlin.de Mon Aug 14 05:25:38 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 14 Aug 2017 05:25:38 +0000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <775E1871-4A2A-46A1-8079-9D40145D05F1@physik.fu-berlin.de> Hi Kim! Quick question: Is this going to remove affect the aromics code in Zero that we have for PPC32, ARM and M68K? I have a couple of patches that I want to send in this week which contains several fixes for Zero as there are still many users for it, especially in distributions like Debian. I was also wondering whether one could use the C++11 synchronization primitives in the future? Adrian > On Aug 14, 2017, at 2:41 AM, Kim Barrett wrote: > > Please review this change to Atomic::cmpxchg, making it a function > template with a per-platform underlying implementation. > > This has been broken out from 8184334: "Generalizing Atomic with > templates", as the originally proposed change there encountered > various objections. This change takes a somewhat different approach > to the same problem. > > One goal is to generalize the API and make it more type-safe, > eliminating (nearly) all need for casts by callers. Another is to > allow more direct per-platform implementations, especially where there > are appropriate compiler intrinsics available. > > If all goes well and this change is accepted, it is intended that the > remainder of Atomic, and later OrderAccess, will be changed in a > similar manner as one or more followups. > > This change to cmpxchg deprecates cmpxchg_ptr. Followup changes will > convert existing uses of cmpxchg_ptr and eventually remove it. > Followup changes will also update uses of cmpxchg that can be > simplified because of the generalized API. > > The cmpxchg function calls private Atomic::CmpxchgImpl, to select > among several cases, based on the argument types. Each case performs > some checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformCmpxchg. The PlatformCmpxchg class > is provided by each platform, and performs additional case analysis to > generate the appropriate code for the platform. > > This change involves modifications to all of the existing platform > implementations of cmpxchg. I've updated all of the platforms, but > only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > New metaprogramming utilities: > integerTypes.hpp > test_integerTypes.cpp > isRegisteredEnum.hpp > test_isRegisteredEnum.cpp > > Change cmpxchg to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > os_bsd.cpp > os_solaris.cpp > aotCodeHeap.cpp > aotCodeHeap.hpp > psParallelCompact.hpp > workgroup.cpp > oopsHierarchy.hpp > os.cpp > > Example updates of cmpxchg_ptr to cmpxchg: > oop.inline.hpp > bitMap.cpp > bitMap.inline.hpp > > Some specific issues: > > - For Solaris (both SPARC and x86), we were using helper functions > defined in corresponding .il files. Using the cmpxchg_using_stub > helper didn't work; passing a "defined in .il" function as a template > parameter didn't work, leading to linker errors. The ideal solution > is to use gcc-style inline assembly, which is now supported by Solaris > Studio. That change was made for SPARC. However, making that change > for x86 ran into related segfaults, so using the .il definition with > direct conversions for now, until that problem can be resolved. > > - I've added the function template Atomic::condition_store_ptr, which > is a cmpxchg for pointer types with a NULL compare_value. That might > not be the best name for it. > > - The name IntegerTypes was retained from the original RFR for > JDK-8184334. However, that name no longer fits the provided > functionality very well, and I think a new name is needed. Something > involving Bitwise, or ValueRepresentation perhaps? I'm open to > suggestions. > > - Issues with casts/conversions provided by IntegerTypes. > > * Conversions between integers and floating point values are > supported. It was suggested during the discussion of the RFR for > JDK-8184334 that this was not needed, as there are no uses of > atomic/ordered floating point values in Hotspot. However, I'm told > VarHandles may include atomic floating point values. > > * Conversions between integers and floating point values are presently > implemented using the memcpy technique. While this technique is > correct, it is known to be quite poorly optimized by some compilers. > It may be necessary to use the "union trick" for performance reasons, > even though it is technically undefined behavior. Hotspot already > does this elsewhere (and we should merge some of the different > conversion handling). > > * In the original RFR for JDK-8184334, conversions between different > integral types of the same size (along with enums) were performed > using > > reinterpret_cast(from_value) > > This was based on discussion from several months ago, referring to > C++03 3.10/15. However, re-reading that section in response to > discussion of the RFR for JDK-8184334, I now think that implementation > is not supported in many cases needed here, and indeed invokes > undefined behavior in those cases. In particular, where 3.10/15 says > > "- a type that is the signed or unsigned type corresponding to the > dynamic type of the object," > > I interpret this to mean that if the dynamic type of an object is an > integral type of a given rank, the value may be accessed using an > lvalue of an integral type of the same rank and the opposite sign. > (Using the same rank and sign is already permitted, since that's the > same type.) I don't think it allows access using an lvalue of an > integral type with a different rank. So, for example, a signed int > value may be accessed via an unsigned int lvalue. But access via a > signed long lvalue is not permitted, even if int and long have the > same size. > > I don't think there is a good way to perform the integral and enum > conversions we need, without invoking implementation-defined, > unspecified, or undefined behavior. > > ** The memcpy technique avoids such problems, but as noted above, is > known to be quite poorly optimized by some compilers. > > ** Using static_cast avoids any undefined behavior, but does have > cases of implementation-defined or unspecified behavior. (When > casting an unsigned value to a signed type, the result may be > implementation defined; 5.2.9/2 and 4.7/3. C++11 plus > the reinterpret_cast to reference seems to provide possibly multi-step > conversion paths that avoid such qualifications on all of the steps.) > (When casting an integral value to an enum type, the result may be > unspecified; 5.2.9/7. With C++11 , the problem doesn't > arise so long as the starting value is appropriate, e.g. we're > reversing an enum to integer conversion.) > > ** Again here, we might consider the "union trick". > > I haven't changed the implementation from the JDK-8184334 RFR, but I'm > presently leaning toward the "union trick", despite previous strong > resistance to it. Right now it seems to me to be the best option in > practice, despite being disallowed by the standard. It's really too > bad the memcpy technique is so poorly supported by some compilers. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8186166 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/ > > Testing: > Ad hoc Hotspot nightly test. From kim.barrett at oracle.com Mon Aug 14 05:33:24 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Aug 2017 01:33:24 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <775E1871-4A2A-46A1-8079-9D40145D05F1@physik.fu-berlin.de> References: <775E1871-4A2A-46A1-8079-9D40145D05F1@physik.fu-berlin.de> Message-ID: <04543849-189F-4408-A652-DBF7EC31CC61@oracle.com> > On Aug 14, 2017, at 1:25 AM, John Paul Adrian Glaubitz wrote: > > Hi Kim! > > Quick question: Is this going to remove affect the aromics code in Zero that we have for PPC32, ARM and M68K? > > I have a couple of patches that I want to send in this week which contains several fixes for Zero as there are still many users for it, especially in distributions like Debian. There are zero changes; see below. I was planning to direct email various folks interested in the care of various platforms not directly supported by Oracle, and you are on my list for that. > I was also wondering whether one could use the C++11 synchronization primitives in the future? Maybe, someday, for some platforms. There are problems with getting C++11 into use, because of deficiencies in some compilers. There are also some questions about the interaction between compiler primitives and what we need for interaction with Java. >> On Aug 14, 2017, at 2:41 AM, Kim Barrett wrote: >> >> Please review this change to Atomic::cmpxchg, making it a function >> template with a per-platform underlying implementation. >> >> [?] >> Non-Oracle platform changes: >> atomic_aix_ppc.hpp >> atomic_bsd_x86.hpp - 32bit >> atomic_bsd_zero.hpp >> atomic_linux_aarch.hpp >> atomic_linux_ppc.hpp >> atomic_linux_s390.hpp >> atomic_linux_sparc.hpp >> atomic_linux_zero.hpp >> [?] From goetz.lindenmaier at sap.com Mon Aug 14 10:17:28 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Aug 2017 10:17:28 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> Message-ID: <83ad97f2d3a24b65806055531f426c1c@sap.com> Hi Gustavo, noreg* is meant to be used intentionally. So you should not match any illegal values to noreg*. I would implement it like this: if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel like, you can assert for values < -1 and > 31. For the copyrights: You must adapt the copyright year of the Oracle copyright line in any file you edit. There must always be a trailing comma. I.e., you change * Copyright (c) 2000, Oracle and/or its affiliates. All rights reserved. to * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. or * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. to * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. You may add one line of your own copyright. But this is only common in new files. New files usually also get the Oracle copyright line. That's why these files have the SAP copyright. You don't need to update the SAP copyright :). Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Samstag, 12. August 2017 12:01 > To: Gustavo Serra Scalet ; Lindenmaier, > Goetz > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Gustavo, > > I think returning vsnoregi is the better choice. If you want to check the upper > limit as well, it should be ">=32". > Copyright year needs to be updated in the header (first 2 lines) of the > register_ppc files. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Freitag, 11. August 2017 22:03 > To: Lindenmaier, Goetz ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hello Goetz, > > About the noreg: if the VectorRegisterImpl::encoding() is not a value from 0-32 > expected, it was an invalid VectorRegister which will, in turn, continue to be > invalid as VectorSRegister. > > Anyway, do you want me to add a verification of "if ((encoding() < 0) || > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > And about the copyright, where do you mean? > > Thanks > > > -----Original Message----- > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > To: Gustavo Serra Scalet ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > thanks for the new change and posting to the other lists :) > > > > I appreciate the shorter function. I think you need to check for noreg > > and keep that unchanged, though. > > Some copyrights are not updated to 2017. > > Consider it reviewed if the new function is fixed. > > > > I posted the webrev on the cr server: > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > and added you as contributor. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Freitag, 11. August 2017 15:55 > > > To: Doerr, Martin > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > It worked for me Martin. Please check the new webrev: > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > Thanks for the review. > > > > > > > -----Original Message----- > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net> > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Martin, > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > Thanks > > > > > > > > -----Original Message----- > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > To: Gustavo Serra Scalet ; > > > > ppc-aix-port- dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but please > > > > update the copyright messages in the modified files. > > > > > > > > register_ppc.cpp > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > prefer something like "return as_VectorSRegister(encoding() + 32)". > > > > > > > > I can sponsor this change. > > > > > > > > Thanks and best regards, > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > > > to > > > > 64 registers > > > > > > > > Hi, > > > > > > > > Could you please review this specific PPC64 change to hotspot? The > > > > aim of these changes is to allow a more complete usage of VSR. I > > > > make use of these interfaces on an instrinsic that I plan to send > > > > next but I decided to separate this change and send it first. > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > Best regards, > > > > Gustavo Serra Scalet From christian.tornqvist at oracle.com Mon Aug 14 11:39:52 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 14 Aug 2017 07:39:52 -0400 Subject: RFR(XS): 8184772 - Make it possible to pass arguments only to the Java running the tests when running jtreg through make Message-ID: <8E8074E9-7E43-4724-A46C-543CF8027E1F@oracle.com> Hi everyone, Please review this small change that enables passing options only to the Java under test when running jtreg through the make files. Options passed as -vmoption will be passed to both to the Java compiling and running the tests, options passed as -javaoptions are only passed to the Java running the tests. Change has been verified locally and in our test lab by running the Hotspot jtreg tests along with JDK tier1-3. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8184772/webrev.00/ Bug (Unfortunately not publicly available): https://bugs.openjdk.java.net/browse/JDK-8184772 Thanks, Christian From coleen.phillimore at oracle.com Mon Aug 14 12:09:02 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 08:09:02 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <0394520d-6616-dfcd-89fa-c9cf0bcd869e@oracle.com> References: <0394520d-6616-dfcd-89fa-c9cf0bcd869e@oracle.com> Message-ID: Thank you Serguei! Coleen On 8/12/17 3:59 AM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The fix looks good. > > Thanks, > Serguei > > > On 8/11/17 14:34, coleen.phillimore at oracle.com wrote: >> Summary: Make an OopHandle type to replace jobject to encapsulate >> these oop pointers in metadata and module entry. >> >> This replaces places where there's a jobject that doesn't point into >> the JNIHandles, notably things allocated in ClassLoaderData::_handles. >> >> There were platform specific changes that I tried to carefully make - >> can someone test them for s390, aarch64 and ppc? >> >> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >> monitoring, parallel class loading and g1class unloading tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Mon Aug 14 12:37:57 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 08:37:57 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> Message-ID: <9de36817-18bd-9fc0-6d4b-b9c750dd9431@oracle.com> On 8/13/17 9:04 PM, David Holmes wrote: > Hi Coleen, > > On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >> Summary: Make an OopHandle type to replace jobject to encapsulate >> these oop pointers in metadata and module entry. >> >> This replaces places where there's a jobject that doesn't point into >> the JNIHandles, notably things allocated in ClassLoaderData::_handles. >> >> There were platform specific changes that I tried to carefully make - >> can someone test them for s390, aarch64 and ppc? >> >> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >> monitoring, parallel class loading and g1class unloading tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 > > Is it possible to put the declaration of > MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp > file to avoid the need to add it to the platform specific hpp files? I did look at that but the platform independent macroAssembler.hpp file is empty and only includes the platform dependent one. The platform dependent one is a full class declaration, so isn't additive of the platform independent one unfortunately. There are a lot of duplication which would be nice to clean up. > > I'm unsure about the OopHandle containing set_atomic. First if it is > present then the _obj field should be volatile. But then it also > raises the question: if we can race to set this, do we need > load-acquire versions of the accessors? Based on the single existing > usage I don't think we presently do. But I think it may be > cleaner/simpler to not have set_atomic, make the OopHandle immutable, > and do the cmpxchg back in the caller code by atomically updating _pd > (which should also be volatile even today) with a new OopHandle. I had trouble writing this in the caller, which is where I would have preferred it also. But I certainly don't want to make resolve() do a load_acquire for this case. I'll try to rewrite it. Coleen > > Thanks, > David > >> Thanks, >> Coleen >> >> From goetz.lindenmaier at sap.com Mon Aug 14 12:50:23 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Aug 2017 12:50:23 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> Message-ID: <155aa1c770674d88938f8318012faa0e@sap.com> Hi Gustavo, hmm, I tried to say that noreg is a special value and _not_ an illegal one. You _must_ map vnoreg to vsnoregi and not any other values. You _can_ assert for illegal values: assert (encoding() >=-1 && encoding() <=31, "register encoding out of range") See for example check_klass_subtype_slow_path() on ppc how we use noreg. Please list only first and last year in register_ppc.cpp copyright. Thanks, Goetz. > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 14:39 > To: Lindenmaier, Goetz ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Goetz and Martin, > > Thanks for your comments. The webrev was updated accordingly: > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > -----Original Message----- > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > noreg* is meant to be used intentionally. So you should not match any > > illegal values to noreg*. I would implement it like this: > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel > > like, you can assert for values < -1 and > 31. > > > > For the copyrights: > > You must adapt the copyright year of the Oracle copyright line in any > > file you edit. There must always be a trailing comma. I.e., > > you change > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > or > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > > > You may add one line of your own copyright. But this is only common in > > new files. New files usually also get the Oracle copyright line. > > That's why these files have the SAP copyright. You don't need to update > > the SAP copyright :). > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Samstag, 12. August 2017 12:01 > > > To: Gustavo Serra Scalet ; > > > Lindenmaier, Goetz > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > I think returning vsnoregi is the better choice. If you want to check > > > the upper limit as well, it should be ">=32". > > > Copyright year needs to be updated in the header (first 2 lines) of > > > the register_ppc files. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Freitag, 11. August 2017 22:03 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hello Goetz, > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a value > > > from 0-32 expected, it was an invalid VectorRegister which will, in > > > turn, continue to be invalid as VectorSRegister. > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < 0) > > > || > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > And about the copyright, where do you mean? > > > > > > Thanks > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > To: Gustavo Serra Scalet ; Doerr, > > > > Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > noreg and keep that unchanged, though. > > > > Some copyrights are not updated to 2017. > > > > Consider it reviewed if the new function is fixed. > > > > > > > > I posted the webrev on the cr server: > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > and added you as contributor. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > To: Doerr, Martin > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > Thanks for the review. > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net> > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > Thanks > > > > > > > > > > > > -----Original Message----- > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > To: Gustavo Serra Scalet ; > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but > > > > > > please update the copyright messages in the modified files. > > > > > > > > > > > > register_ppc.cpp > > > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > > > prefer something like "return as_VectorSRegister(encoding() + > > 32)". > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > Thanks and best regards, > > > > > > Martin > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > > > up to > > > > > > 64 registers > > > > > > > > > > > > Hi, > > > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > > The aim of these changes is to allow a more complete usage of > > > > > > VSR. I make use of these interfaces on an instrinsic that I plan > > > > > > to send next but I decided to separate this change and send it > > first. > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > Best regards, > > > > > > Gustavo Serra Scalet From martin.doerr at sap.com Mon Aug 14 12:53:21 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Aug 2017 12:53:21 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <155aa1c770674d88938f8318012faa0e@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> Message-ID: <159e123bb0804f329902116fdd1b6644@sap.com> Hi Gustavo, I can do these minor changes before pushing if you're ok with it. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 14. August 2017 14:50 To: Gustavo Serra Scalet ; Doerr, Martin Cc: 'hotspot-compiler-dev at openjdk.java.net' ; hotspot-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Hi Gustavo, hmm, I tried to say that noreg is a special value and _not_ an illegal one. You _must_ map vnoreg to vsnoregi and not any other values. You _can_ assert for illegal values: assert (encoding() >=-1 && encoding() <=31, "register encoding out of range") See for example check_klass_subtype_slow_path() on ppc how we use noreg. Please list only first and last year in register_ppc.cpp copyright. Thanks, Goetz. > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 14:39 > To: Lindenmaier, Goetz ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Goetz and Martin, > > Thanks for your comments. The webrev was updated accordingly: > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > -----Original Message----- > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > noreg* is meant to be used intentionally. So you should not match any > > illegal values to noreg*. I would implement it like this: > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel > > like, you can assert for values < -1 and > 31. > > > > For the copyrights: > > You must adapt the copyright year of the Oracle copyright line in any > > file you edit. There must always be a trailing comma. I.e., > > you change > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > or > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > > > You may add one line of your own copyright. But this is only common in > > new files. New files usually also get the Oracle copyright line. > > That's why these files have the SAP copyright. You don't need to update > > the SAP copyright :). > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Samstag, 12. August 2017 12:01 > > > To: Gustavo Serra Scalet ; > > > Lindenmaier, Goetz > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > I think returning vsnoregi is the better choice. If you want to check > > > the upper limit as well, it should be ">=32". > > > Copyright year needs to be updated in the header (first 2 lines) of > > > the register_ppc files. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Freitag, 11. August 2017 22:03 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hello Goetz, > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a value > > > from 0-32 expected, it was an invalid VectorRegister which will, in > > > turn, continue to be invalid as VectorSRegister. > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < 0) > > > || > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > And about the copyright, where do you mean? > > > > > > Thanks > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > To: Gustavo Serra Scalet ; Doerr, > > > > Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > noreg and keep that unchanged, though. > > > > Some copyrights are not updated to 2017. > > > > Consider it reviewed if the new function is fixed. > > > > > > > > I posted the webrev on the cr server: > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > and added you as contributor. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > To: Doerr, Martin > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > Thanks for the review. > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net> > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > Thanks > > > > > > > > > > > > -----Original Message----- > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > To: Gustavo Serra Scalet ; > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but > > > > > > please update the copyright messages in the modified files. > > > > > > > > > > > > register_ppc.cpp > > > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > > > prefer something like "return as_VectorSRegister(encoding() + > > 32)". > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > Thanks and best regards, > > > > > > Martin > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > > > up to > > > > > > 64 registers > > > > > > > > > > > > Hi, > > > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > > The aim of these changes is to allow a more complete usage of > > > > > > VSR. I make use of these interfaces on an instrinsic that I plan > > > > > > to send next but I decided to separate this change and send it > > first. > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > Best regards, > > > > > > Gustavo Serra Scalet From goetz.lindenmaier at sap.com Mon Aug 14 13:35:13 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Aug 2017 13:35:13 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> <159e123bb0804f329902116fdd1b6644@sap.com> Message-ID: Me too :) > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 15:13 > To: Doerr, Martin ; Lindenmaier, Goetz > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Martin, > > Yes please. I'm ok with that. > > @Goetz: sorry, I misunderstood. I read your and Martin's comments and mixed > them up. I got it now about keeping your original "if" and adding and "assert". > > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 09:53 > > To: Lindenmaier, Goetz ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > I can do these minor changes before pushing if you're ok with it. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Montag, 14. August 2017 14:50 > > To: Gustavo Serra Scalet ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > hmm, I tried to say that noreg is a special value and _not_ an illegal > > one. > > You _must_ map vnoreg to vsnoregi and not any other values. > > You _can_ assert for illegal values: > > assert (encoding() >=-1 && encoding() <=31, "register encoding out of > > range") > > > > See for example check_klass_subtype_slow_path() on ppc how we use noreg. > > > > Please list only first and last year in register_ppc.cpp copyright. > > > > Thanks, > > Goetz. > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Montag, 14. August 2017 14:39 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Goetz and Martin, > > > > > > Thanks for your comments. The webrev was updated accordingly: > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > noreg* is meant to be used intentionally. So you should not match > > > > any illegal values to noreg*. I would implement it like this: > > > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you > > > > feel like, you can assert for values < -1 and > 31. > > > > > > > > For the copyrights: > > > > You must adapt the copyright year of the Oracle copyright line in > > > > any file you edit. There must always be a trailing comma. I.e., you > > > > change > > > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > > > reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > or > > > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All > > > > rights reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > > > > > You may add one line of your own copyright. But this is only common > > > > in new files. New files usually also get the Oracle copyright line. > > > > That's why these files have the SAP copyright. You don't need to > > > > update the SAP copyright :). > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin > > > > > Sent: Samstag, 12. August 2017 12:01 > > > > > To: Gustavo Serra Scalet ; > > > > > Lindenmaier, Goetz > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > I think returning vsnoregi is the better choice. If you want to > > > > > check the upper limit as well, it should be ">=32". > > > > > Copyright year needs to be updated in the header (first 2 lines) > > > > > of the register_ppc files. > > > > > > > > > > Thanks and best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > > Sent: Freitag, 11. August 2017 22:03 > > > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hello Goetz, > > > > > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a > > > > > value from 0-32 expected, it was an invalid VectorRegister which > > > > > will, in turn, continue to be invalid as VectorSRegister. > > > > > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < > > > > > 0) > > > > > || > > > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > > > > > > > And about the copyright, where do you mean? > > > > > > > > > > Thanks > > > > > > > > > > > -----Original Message----- > > > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > > > To: Gustavo Serra Scalet ; > > > > > > Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > > > noreg and keep that unchanged, though. > > > > > > Some copyrights are not updated to 2017. > > > > > > Consider it reviewed if the new function is fixed. > > > > > > > > > > > > I posted the webrev on the cr server: > > > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > > > and added you as contributor. > > > > > > > > > > > > Best regards, > > > > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > > > To: Doerr, Martin > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support > > > > > > > to use up to 64 registers > > > > > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > > > > > > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > > > To: Gustavo Serra Scalet ; > > > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, > > > > > > > > but please update the copyright messages in the modified > > files. > > > > > > > > > > > > > > > > register_ppc.cpp > > > > > > > > to_vsr(): I don't like large code for a trivial computation. > > > > > > > > I'd prefer something like "return > > > > > > > > as_VectorSRegister(encoding() + > > > > 32)". > > > > > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > > > > > Thanks and best regards, > > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > > > use up to > > > > > > > > 64 registers > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could you please review this specific PPC64 change to > > hotspot? > > > > > > > > The aim of these changes is to allow a more complete usage > > > > > > > > of VSR. I make use of these interfaces on an instrinsic that > > > > > > > > I plan to send next but I decided to separate this change > > > > > > > > and send it > > > > first. > > > > > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > > > Webrev: > > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Gustavo Serra Scalet From jesper.wilhelmsson at oracle.com Mon Aug 14 13:47:12 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 14 Aug 2017 15:47:12 +0200 Subject: Stabilising jdk10/hs - Please hold large changes for now Message-ID: Hi, We are aiming at integrating jdk10/hs to jdk10/jdk10 within a week or two. There are currently 438 new changes in 10/hs (not including merges). To be able to integrate we need to find and fix all integration blockers, or accept that they escape into 10/10. We are now looking at three integration blockers. If you know of any other bug that is new in 10/hs and has not already been triaged and determined not to be a blocker, please add the integration_blocker label to it asap. Even if the bug can't be fixed within the next week it is better to know in advance what we are pushing to 10/10 in case we need to do any other preparations. To minimize the risk of introducing new integration blockers we ask everyone to be restrictive about what changes that go in to 10/hs over the next week until an approved snapshot has been produced. This is not a lockdown of the repository, but an appeal to hold those larger potentially risky changes for a week or so if possible. Thanks, /Jesper From gustavo.scalet at eldorado.org.br Fri Aug 11 20:02:45 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 11 Aug 2017 20:02:45 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <4c61f03b278d46959ca496f7c31db929@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> Message-ID: <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> Hello Goetz, About the noreg: if the VectorRegisterImpl::encoding() is not a value from 0-32 expected, it was an invalid VectorRegister which will, in turn, continue to be invalid as VectorSRegister. Anyway, do you want me to add a verification of "if ((encoding() < 0) || (encoding() > 32)) return vsnoregi;" before? Or an assert? And about the copyright, where do you mean? Thanks > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: sexta-feira, 11 de agosto de 2017 11:56 > To: Gustavo Serra Scalet ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > thanks for the new change and posting to the other lists :) > > I appreciate the shorter function. I think you need to check for noreg > and keep that unchanged, though. > Some copyrights are not updated to 2017. > Consider it reviewed if the new function is fixed. > > I posted the webrev on the cr server: > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > and added you as contributor. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Freitag, 11. August 2017 15:55 > > To: Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > It worked for me Martin. Please check the new webrev: > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > Thanks for the review. > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Martin, > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > To: Gustavo Serra Scalet ; > > > ppc-aix-port- dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > seems like you're preparing new VSR code :-) Nice change, but please > > > update the copyright messages in the modified files. > > > > > > register_ppc.cpp > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > prefer something like "return as_VectorSRegister(encoding() + 32)". > > > > > > I can sponsor this change. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Dienstag, 8. August 2017 22:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > > to > > > 64 registers > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? The > > > aim of these changes is to allow a more complete usage of VSR. I > > > make use of these interfaces on an instrinsic that I plan to send > > > next but I decided to separate this change and send it first. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > Best regards, > > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Mon Aug 14 12:38:36 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 14 Aug 2017 12:38:36 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <83ad97f2d3a24b65806055531f426c1c@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> Message-ID: <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> Hi Goetz and Martin, Thanks for your comments. The webrev was updated accordingly: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: segunda-feira, 14 de agosto de 2017 07:17 > To: Doerr, Martin ; Gustavo Serra Scalet > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > noreg* is meant to be used intentionally. So you should not match any > illegal values to noreg*. I would implement it like this: > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel > like, you can assert for values < -1 and > 31. > > For the copyrights: > You must adapt the copyright year of the Oracle copyright line in any > file you edit. There must always be a trailing comma. I.e., > you change > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > reserved. > to > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > reserved. > or > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights > reserved. > to > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > reserved. > > You may add one line of your own copyright. But this is only common in > new files. New files usually also get the Oracle copyright line. > That's why these files have the SAP copyright. You don't need to update > the SAP copyright :). > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Samstag, 12. August 2017 12:01 > > To: Gustavo Serra Scalet ; > > Lindenmaier, Goetz > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > Hi Gustavo, > > > > I think returning vsnoregi is the better choice. If you want to check > > the upper limit as well, it should be ">=32". > > Copyright year needs to be updated in the header (first 2 lines) of > > the register_ppc files. > > > > Thanks and best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Freitag, 11. August 2017 22:03 > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > Hello Goetz, > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a value > > from 0-32 expected, it was an invalid VectorRegister which will, in > > turn, continue to be invalid as VectorSRegister. > > > > Anyway, do you want me to add a verification of "if ((encoding() < 0) > > || > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > And about the copyright, where do you mean? > > > > Thanks > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > To: Gustavo Serra Scalet ; Doerr, > > > Martin > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > thanks for the new change and posting to the other lists :) > > > > > > I appreciate the shorter function. I think you need to check for > > > noreg and keep that unchanged, though. > > > Some copyrights are not updated to 2017. > > > Consider it reviewed if the new function is fixed. > > > > > > I posted the webrev on the cr server: > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > and added you as contributor. > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: Freitag, 11. August 2017 15:55 > > > > To: Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > use up to 64 registers > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > Thanks for the review. > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net> > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Martin, > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > Thanks > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > To: Gustavo Serra Scalet ; > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but > > > > > please update the copyright messages in the modified files. > > > > > > > > > > register_ppc.cpp > > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > > prefer something like "return as_VectorSRegister(encoding() + > 32)". > > > > > > > > > > I can sponsor this change. > > > > > > > > > > Thanks and best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > > up to > > > > > 64 registers > > > > > > > > > > Hi, > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > The aim of these changes is to allow a more complete usage of > > > > > VSR. I make use of these interfaces on an instrinsic that I plan > > > > > to send next but I decided to separate this change and send it > first. > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > Best regards, > > > > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Mon Aug 14 13:12:59 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 14 Aug 2017 13:12:59 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <159e123bb0804f329902116fdd1b6644@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> <159e123bb0804f329902116fdd1b6644@sap.com> Message-ID: Hi Martin, Yes please. I'm ok with that. @Goetz: sorry, I misunderstood. I read your and Martin's comments and mixed them up. I got it now about keeping your original "if" and adding and "assert". > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: segunda-feira, 14 de agosto de 2017 09:53 > To: Lindenmaier, Goetz ; Gustavo Serra Scalet > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > I can do these minor changes before pushing if you're ok with it. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 14. August 2017 14:50 > To: Gustavo Serra Scalet ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > hmm, I tried to say that noreg is a special value and _not_ an illegal > one. > You _must_ map vnoreg to vsnoregi and not any other values. > You _can_ assert for illegal values: > assert (encoding() >=-1 && encoding() <=31, "register encoding out of > range") > > See for example check_klass_subtype_slow_path() on ppc how we use noreg. > > Please list only first and last year in register_ppc.cpp copyright. > > Thanks, > Goetz. > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Montag, 14. August 2017 14:39 > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > Hi Goetz and Martin, > > > > Thanks for your comments. The webrev was updated accordingly: > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > noreg* is meant to be used intentionally. So you should not match > > > any illegal values to noreg*. I would implement it like this: > > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you > > > feel like, you can assert for values < -1 and > 31. > > > > > > For the copyrights: > > > You must adapt the copyright year of the Oracle copyright line in > > > any file you edit. There must always be a trailing comma. I.e., you > > > change > > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > > reserved. > > > to > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > rights reserved. > > > or > > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All > > > rights reserved. > > > to > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > rights reserved. > > > > > > You may add one line of your own copyright. But this is only common > > > in new files. New files usually also get the Oracle copyright line. > > > That's why these files have the SAP copyright. You don't need to > > > update the SAP copyright :). > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > From: Doerr, Martin > > > > Sent: Samstag, 12. August 2017 12:01 > > > > To: Gustavo Serra Scalet ; > > > > Lindenmaier, Goetz > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > use up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > I think returning vsnoregi is the better choice. If you want to > > > > check the upper limit as well, it should be ">=32". > > > > Copyright year needs to be updated in the header (first 2 lines) > > > > of the register_ppc files. > > > > > > > > Thanks and best regards, > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > Sent: Freitag, 11. August 2017 22:03 > > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > use up to 64 registers > > > > > > > > Hello Goetz, > > > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a > > > > value from 0-32 expected, it was an invalid VectorRegister which > > > > will, in turn, continue to be invalid as VectorSRegister. > > > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < > > > > 0) > > > > || > > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > > > > And about the copyright, where do you mean? > > > > > > > > Thanks > > > > > > > > > -----Original Message----- > > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > > To: Gustavo Serra Scalet ; > > > > > Doerr, Martin > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > > noreg and keep that unchanged, though. > > > > > Some copyrights are not updated to 2017. > > > > > Consider it reviewed if the new function is fixed. > > > > > > > > > > I posted the webrev on the cr server: > > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > > and added you as contributor. > > > > > > > > > > Best regards, > > > > > Goetz. > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > > To: Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support > > > > > > to use up to 64 registers > > > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > > > > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > > To: Gustavo Serra Scalet ; > > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, > > > > > > > but please update the copyright messages in the modified > files. > > > > > > > > > > > > > > register_ppc.cpp > > > > > > > to_vsr(): I don't like large code for a trivial computation. > > > > > > > I'd prefer something like "return > > > > > > > as_VectorSRegister(encoding() + > > > 32)". > > > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > > > Thanks and best regards, > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > > use up to > > > > > > > 64 registers > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Could you please review this specific PPC64 change to > hotspot? > > > > > > > The aim of these changes is to allow a more complete usage > > > > > > > of VSR. I make use of these interfaces on an instrinsic that > > > > > > > I plan to send next but I decided to separate this change > > > > > > > and send it > > > first. > > > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > > Webrev: > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > > > Best regards, > > > > > > > Gustavo Serra Scalet From rkennke at redhat.com Mon Aug 14 14:28:43 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 14 Aug 2017 16:28:43 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> I still don't understand why we want to allow for different types for the new and expected values and the memory location (T, D and U). We haven't allowed for this before, why are we doing it now? Roman Am 14.08.2017 um 04:41 schrieb Kim Barrett: > Please review this change to Atomic::cmpxchg, making it a function > template with a per-platform underlying implementation. > > This has been broken out from 8184334: "Generalizing Atomic with > templates", as the originally proposed change there encountered > various objections. This change takes a somewhat different approach > to the same problem. > > One goal is to generalize the API and make it more type-safe, > eliminating (nearly) all need for casts by callers. Another is to > allow more direct per-platform implementations, especially where there > are appropriate compiler intrinsics available. > > If all goes well and this change is accepted, it is intended that the > remainder of Atomic, and later OrderAccess, will be changed in a > similar manner as one or more followups. > > This change to cmpxchg deprecates cmpxchg_ptr. Followup changes will > convert existing uses of cmpxchg_ptr and eventually remove it. > Followup changes will also update uses of cmpxchg that can be > simplified because of the generalized API. > > The cmpxchg function calls private Atomic::CmpxchgImpl, to select > among several cases, based on the argument types. Each case performs > some checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformCmpxchg. The PlatformCmpxchg class > is provided by each platform, and performs additional case analysis to > generate the appropriate code for the platform. > > This change involves modifications to all of the existing platform > implementations of cmpxchg. I've updated all of the platforms, but > only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > New metaprogramming utilities: > integerTypes.hpp > test_integerTypes.cpp > isRegisteredEnum.hpp > test_isRegisteredEnum.cpp > > Change cmpxchg to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > os_bsd.cpp > os_solaris.cpp > aotCodeHeap.cpp > aotCodeHeap.hpp > psParallelCompact.hpp > workgroup.cpp > oopsHierarchy.hpp > os.cpp > > Example updates of cmpxchg_ptr to cmpxchg: > oop.inline.hpp > bitMap.cpp > bitMap.inline.hpp > > Some specific issues: > > - For Solaris (both SPARC and x86), we were using helper functions > defined in corresponding .il files. Using the cmpxchg_using_stub > helper didn't work; passing a "defined in .il" function as a template > parameter didn't work, leading to linker errors. The ideal solution > is to use gcc-style inline assembly, which is now supported by Solaris > Studio. That change was made for SPARC. However, making that change > for x86 ran into related segfaults, so using the .il definition with > direct conversions for now, until that problem can be resolved. > > - I've added the function template Atomic::condition_store_ptr, which > is a cmpxchg for pointer types with a NULL compare_value. That might > not be the best name for it. > > - The name IntegerTypes was retained from the original RFR for > JDK-8184334. However, that name no longer fits the provided > functionality very well, and I think a new name is needed. Something > involving Bitwise, or ValueRepresentation perhaps? I'm open to > suggestions. > > - Issues with casts/conversions provided by IntegerTypes. > > * Conversions between integers and floating point values are > supported. It was suggested during the discussion of the RFR for > JDK-8184334 that this was not needed, as there are no uses of > atomic/ordered floating point values in Hotspot. However, I'm told > VarHandles may include atomic floating point values. > > * Conversions between integers and floating point values are presently > implemented using the memcpy technique. While this technique is > correct, it is known to be quite poorly optimized by some compilers. > It may be necessary to use the "union trick" for performance reasons, > even though it is technically undefined behavior. Hotspot already > does this elsewhere (and we should merge some of the different > conversion handling). > > * In the original RFR for JDK-8184334, conversions between different > integral types of the same size (along with enums) were performed > using > > reinterpret_cast(from_value) > > This was based on discussion from several months ago, referring to > C++03 3.10/15. However, re-reading that section in response to > discussion of the RFR for JDK-8184334, I now think that implementation > is not supported in many cases needed here, and indeed invokes > undefined behavior in those cases. In particular, where 3.10/15 says > > "- a type that is the signed or unsigned type corresponding to the > dynamic type of the object," > > I interpret this to mean that if the dynamic type of an object is an > integral type of a given rank, the value may be accessed using an > lvalue of an integral type of the same rank and the opposite sign. > (Using the same rank and sign is already permitted, since that's the > same type.) I don't think it allows access using an lvalue of an > integral type with a different rank. So, for example, a signed int > value may be accessed via an unsigned int lvalue. But access via a > signed long lvalue is not permitted, even if int and long have the > same size. > > I don't think there is a good way to perform the integral and enum > conversions we need, without invoking implementation-defined, > unspecified, or undefined behavior. > > ** The memcpy technique avoids such problems, but as noted above, is > known to be quite poorly optimized by some compilers. > > ** Using static_cast avoids any undefined behavior, but does have > cases of implementation-defined or unspecified behavior. (When > casting an unsigned value to a signed type, the result may be > implementation defined; 5.2.9/2 and 4.7/3. C++11 plus > the reinterpret_cast to reference seems to provide possibly multi-step > conversion paths that avoid such qualifications on all of the steps.) > (When casting an integral value to an enum type, the result may be > unspecified; 5.2.9/7. With C++11 , the problem doesn't > arise so long as the starting value is appropriate, e.g. we're > reversing an enum to integer conversion.) > > ** Again here, we might consider the "union trick". > > I haven't changed the implementation from the JDK-8184334 RFR, but I'm > presently leaning toward the "union trick", despite previous strong > resistance to it. Right now it seems to me to be the best option in > practice, despite being disallowed by the standard. It's really too > bad the memcpy technique is so poorly supported by some compilers. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8186166 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/ > > Testing: > Ad hoc Hotspot nightly test. > > From martin.doerr at sap.com Mon Aug 14 15:04:00 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Aug 2017 15:04:00 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> <159e123bb0804f329902116fdd1b6644@sap.com> Message-ID: <1363c2f592e94e5ba208bfad67f0a627@sap.com> Tested and pushed with the modification. Note that the range assertion is done in encoding(). Thanks for the contribution and for reviewing. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 14. August 2017 15:35 To: Gustavo Serra Scalet ; Doerr, Martin Cc: 'hotspot-compiler-dev at openjdk.java.net' ; hotspot-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Me too :) > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 15:13 > To: Doerr, Martin ; Lindenmaier, Goetz > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Martin, > > Yes please. I'm ok with that. > > @Goetz: sorry, I misunderstood. I read your and Martin's comments and mixed > them up. I got it now about keeping your original "if" and adding and "assert". > > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 09:53 > > To: Lindenmaier, Goetz ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > I can do these minor changes before pushing if you're ok with it. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Montag, 14. August 2017 14:50 > > To: Gustavo Serra Scalet ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > hmm, I tried to say that noreg is a special value and _not_ an illegal > > one. > > You _must_ map vnoreg to vsnoregi and not any other values. > > You _can_ assert for illegal values: > > assert (encoding() >=-1 && encoding() <=31, "register encoding out of > > range") > > > > See for example check_klass_subtype_slow_path() on ppc how we use noreg. > > > > Please list only first and last year in register_ppc.cpp copyright. > > > > Thanks, > > Goetz. > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Montag, 14. August 2017 14:39 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Goetz and Martin, > > > > > > Thanks for your comments. The webrev was updated accordingly: > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > noreg* is meant to be used intentionally. So you should not match > > > > any illegal values to noreg*. I would implement it like this: > > > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you > > > > feel like, you can assert for values < -1 and > 31. > > > > > > > > For the copyrights: > > > > You must adapt the copyright year of the Oracle copyright line in > > > > any file you edit. There must always be a trailing comma. I.e., you > > > > change > > > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > > > reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > or > > > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All > > > > rights reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > > > > > You may add one line of your own copyright. But this is only common > > > > in new files. New files usually also get the Oracle copyright line. > > > > That's why these files have the SAP copyright. You don't need to > > > > update the SAP copyright :). > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin > > > > > Sent: Samstag, 12. August 2017 12:01 > > > > > To: Gustavo Serra Scalet ; > > > > > Lindenmaier, Goetz > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > I think returning vsnoregi is the better choice. If you want to > > > > > check the upper limit as well, it should be ">=32". > > > > > Copyright year needs to be updated in the header (first 2 lines) > > > > > of the register_ppc files. > > > > > > > > > > Thanks and best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > > Sent: Freitag, 11. August 2017 22:03 > > > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hello Goetz, > > > > > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a > > > > > value from 0-32 expected, it was an invalid VectorRegister which > > > > > will, in turn, continue to be invalid as VectorSRegister. > > > > > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < > > > > > 0) > > > > > || > > > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > > > > > > > And about the copyright, where do you mean? > > > > > > > > > > Thanks > > > > > > > > > > > -----Original Message----- > > > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > > > To: Gustavo Serra Scalet ; > > > > > > Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > > > noreg and keep that unchanged, though. > > > > > > Some copyrights are not updated to 2017. > > > > > > Consider it reviewed if the new function is fixed. > > > > > > > > > > > > I posted the webrev on the cr server: > > > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > > > and added you as contributor. > > > > > > > > > > > > Best regards, > > > > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > > > To: Doerr, Martin > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support > > > > > > > to use up to 64 registers > > > > > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > > > > > > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > > > To: Gustavo Serra Scalet ; > > > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, > > > > > > > > but please update the copyright messages in the modified > > files. > > > > > > > > > > > > > > > > register_ppc.cpp > > > > > > > > to_vsr(): I don't like large code for a trivial computation. > > > > > > > > I'd prefer something like "return > > > > > > > > as_VectorSRegister(encoding() + > > > > 32)". > > > > > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > > > > > Thanks and best regards, > > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > > > use up to > > > > > > > > 64 registers > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could you please review this specific PPC64 change to > > hotspot? > > > > > > > > The aim of these changes is to allow a more complete usage > > > > > > > > of VSR. I make use of these interfaces on an instrinsic that > > > > > > > > I plan to send next but I decided to separate this change > > > > > > > > and send it > > > > first. > > > > > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > > > Webrev: > > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Gustavo Serra Scalet From coleen.phillimore at oracle.com Mon Aug 14 15:38:09 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 11:38:09 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> Message-ID: <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> On 8/13/17 9:04 PM, David Holmes wrote: > Hi Coleen, > > On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >> Summary: Make an OopHandle type to replace jobject to encapsulate >> these oop pointers in metadata and module entry. >> >> This replaces places where there's a jobject that doesn't point into >> the JNIHandles, notably things allocated in ClassLoaderData::_handles. >> >> There were platform specific changes that I tried to carefully make - >> can someone test them for s390, aarch64 and ppc? >> >> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >> monitoring, parallel class loading and g1class unloading tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 > > Is it possible to put the declaration of > MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp > file to avoid the need to add it to the platform specific hpp files? > > I'm unsure about the OopHandle containing set_atomic. First if it is > present then the _obj field should be volatile. But then it also > raises the question: if we can race to set this, do we need > load-acquire versions of the accessors? Based on the single existing > usage I don't think we presently do. But I think it may be > cleaner/simpler to not have set_atomic, make the OopHandle immutable, > and do the cmpxchg back in the caller code by atomically updating _pd > (which should also be volatile even today) with a new OopHandle. I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() to an address of OopHandle since it is not a pointer but a struct. The casting would be wrong. So I added a resolve_acquire() for the protection_domain case in ModuleEntry, and some commentary. open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev thanks, Coleen > > Thanks, > David > >> Thanks, >> Coleen >> >> From kim.barrett at oracle.com Mon Aug 14 15:56:42 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Aug 2017 11:56:42 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> References: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> Message-ID: > On Aug 14, 2017, at 10:28 AM, Roman Kennke wrote: > > I still don't understand why we want to allow for different types for > the new and expected values and the memory location (T, D and U). We > haven't allowed for this before, why are we doing it now? Different types are only permitted in the pointer value case, e.g. cmpxchg(T*, D* volatile*, U*). The compare_value type is permitted to differ from the destination's value type only in cv-qualifiers. Consider a member variable "var" of type int*. const int* old_value = var; ... compute new_value ... cmpxchg(new_value, &var, old_value); It is perfectly reasonable and appropriate to const-qualify old_value's type in that way. But that would require a source level cast if cmpxchg required an exact type match for *dest and compare_value. We permit the exchange_value type to be less cv-qualified than the *dest type. We also permit derived to base conversions. Both of those are natural and type-safe, and may eliminate the need for some source level casts. > We haven't allowed for this before, why are we doing it now? Because of the complete type-discarding done by cmpxchg_ptr, I suggest we have no clue what our current code might or might not be doing. From kim.barrett at oracle.com Mon Aug 14 16:35:37 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Aug 2017 12:35:37 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> > On Aug 14, 2017, at 1:08 AM, David Holmes wrote: > > Hi Kim, > > This is an initial partial review. I have to move onto other stuff today so will get back to this tomorrow. Thanks. > On 14/08/2017 12:41 PM, Kim Barrett wrote: >> Please review this change to Atomic::cmpxchg, making it a function >> template with a per-platform underlying implementation. >> This has been broken out from 8184334: "Generalizing Atomic with >> templates", as the originally proposed change there encountered >> various objections. This change takes a somewhat different approach >> to the same problem. > > I assume the intent is not to push this yet, so that Erik has a chance to weigh-in when he gets back from vacation? I would not want to see unnecessary churn here. I had thought it might depend on how quickly this review went. But Jesper's request to make jdk/hs temporarily slushy makes a push before Erik's return seem quite unlikely. > [?] >> - I've added the function template Atomic::condition_store_ptr, which >> is a cmpxchg for pointer types with a NULL compare_value. That might >> not be the best name for it. > > Definitely not the best name for it. :) replace_if_null seems to describe it more precisely. That seems like a good name. I'll wait a bit for other opinions. >> - The name IntegerTypes was retained from the original RFR for >> JDK-8184334. However, that name no longer fits the provided >> functionality very well, and I think a new name is needed. Something >> involving Bitwise, or ValueRepresentation perhaps? I'm open to >> suggestions. > > How about PrimitiveTypes? I'll wait for other opinions. That name suggests to me that support for floating point should be included. And see below. >> - Issues with casts/conversions provided by IntegerTypes. >> * Conversions between integers and floating point values are >> supported. It was suggested during the discussion of the RFR for >> JDK-8184334 that this was not needed, as there are no uses of >> atomic/ordered floating point values in Hotspot. However, I'm told >> VarHandles may include atomic floating point values. > > Yes they were added. However at the level of jdk.internal.misc.Unsafe all the FP operations are converted to int/long variants using eg Float.floatToRawIntBits etc. > > But I'm not convinced we need to complicate things by supporting floating-point Atomic::cmpxchg in the VM's Atomic API. You can only do so by implementing the floatToRawIntBits etc functionality, and there are no native mappings for any "atomic" floating-point operation (ie the only way to do Atomic::inc on a floating=point value is to use cmpxchg.) I was about to agree to removal of floating point from here. Then I remembered the jmumble_cast suite of functions in globalDefinitions.hpp. Erik and I had discussed a unification, with the jmumble_cast functions built on IntegerTypes. We can't presently do that, because of include dependencies, but that's probably fixable. We see this utility as having application beyond Atomic &etc template reimplementation. But clearly the memcpy technique can't be retained, due to the deficiencies of some compilers. >> * In the original RFR for JDK-8184334, conversions between different >> integral types of the same size (along with enums) were performed >> using >> reinterpret_cast(from_value) >> [?] > > I find that all rather dismaying. No kidding! > [?] > src/share/vm/metaprogramming/isRegisteredEnum.hpp > > My initial personal preference here is to see registered enum types added to this header file rather than as template specializations at the point of use. Is that reasonable/feasible, or are there reasons to spread this around? That would require moving the complete enum definitions here, far away from their natural location. We can't forward declare them here for registration; forward declaration of enum types doesn't work (doesn't compile), since the compiler can't determine the underlying type without knowing the enumerators. Also, such a move would only be possible for an enum type defined at namespace scope; class scoped enums cannot be so moved. > test/native/metaprogramming/test_integerTypes.cpp > test/native/metaprogramming/test_isRegisteredEnum.cpp > > Seems minimalist but ok. > > Aside: I find it slightly limiting that because these templates involve compile-time checks, that we can't actually write negative tests. Seems to me that when writing the templates you had to write a test case that will fail, to verify the correctness of the template, but you can't check-in that testcase. Maybe we need a test harness that can handle 'tests' that simply fail to compile ... ? When the addition of native testing was being discussed, that was a feature I mentioned as being needed. But that doesn't seem to have happened, and I couldn't find an existing RFE, so I filed a new one: https://bugs.openjdk.java.net/browse/JDK-8186177 Native testing needs support for compile-fail tests From jiangli.zhou at Oracle.COM Mon Aug 14 17:41:05 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Mon, 14 Aug 2017 10:41:05 -0700 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> Message-ID: <29D266B8-375F-4538-B39C-5AB323B93DB7@oracle.com> Hi Coleen, This looks good to me. I noticed a small issue, which isn?t caused by your change, but related to ClassLoaderData::remove_handle_unsafe(). There could be a small memory leak in the ChunkedHandleList when remove_handle_unsafe() is used to remove a handle under race condition. ClassLoaderData::remove_handle_unsafe() only sets the *_data[idx] to NULL in the list. However, that _data[idx] is never reused and set to another oop after the point. Currently the race condition could only happen during setting one of the shared ProtectionDomain, so the leak is small. To avoid the memory leak, ChunkedHandleList::add() could try to reuse a NULL _data[idx] in the list, but that requires to scan the _data[] array of all chunks. Since this is not part of your change, I think we can handle that separately. Thanks, Jiangli > On Aug 14, 2017, at 8:38 AM, coleen.phillimore at oracle.com wrote: > > > > On 8/13/17 9:04 PM, David Holmes wrote: >> Hi Coleen, >> >> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Make an OopHandle type to replace jobject to encapsulate these oop pointers in metadata and module entry. >>> >>> This replaces places where there's a jobject that doesn't point into the JNIHandles, notably things allocated in ClassLoaderData::_handles. >>> >>> There were platform specific changes that I tried to carefully make - can someone test them for s390, aarch64 and ppc? >>> >>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, monitoring, parallel class loading and g1class unloading tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >> >> Is it possible to put the declaration of MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp file to avoid the need to add it to the platform specific hpp files? >> >> I'm unsure about the OopHandle containing set_atomic. First if it is present then the _obj field should be volatile. But then it also raises the question: if we can race to set this, do we need load-acquire versions of the accessors? Based on the single existing usage I don't think we presently do. But I think it may be cleaner/simpler to not have set_atomic, make the OopHandle immutable, and do the cmpxchg back in the caller code by atomically updating _pd (which should also be volatile even today) with a new OopHandle. > > I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() to an address of OopHandle since it is not a pointer but a struct. The casting would be wrong. So I added a resolve_acquire() for the protection_domain case in ModuleEntry, and some commentary. > > open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev > > thanks, > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> > From glaubitz at physik.fu-berlin.de Mon Aug 14 18:43:34 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 14 Aug 2017 20:43:34 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <04543849-189F-4408-A652-DBF7EC31CC61@oracle.com> References: <775E1871-4A2A-46A1-8079-9D40145D05F1@physik.fu-berlin.de> <04543849-189F-4408-A652-DBF7EC31CC61@oracle.com> Message-ID: <20170814184334.GB19344@physik.fu-berlin.de> Hi Kim! On Mon, Aug 14, 2017 at 01:33:24AM -0400, Kim Barrett wrote: > There are zero changes; see below. I was planning to direct email > various folks interested in the care of various platforms not directly > supported by Oracle, and you are on my list for that. Thank you for doing that. I was currently in transit at the airport when I wrote my previous email, hence my bad posting style. I will have a look at your changes regarding Zero tomorrow, I'm still a bit jet-lagged ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From serguei.spitsyn at oracle.com Mon Aug 14 20:04:35 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 14 Aug 2017 13:04:35 -0700 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> Message-ID: Hi Coleen, Looks good. http://cr.openjdk.java.net/~coleenp/8186088.02/webrev/src/share/vm/oops/oopHandle.hpp.html There is unneeded space after the const: 50 oop resolve() const { return (_obj == NULL) ? (oop)NULL : *_obj; } Thanks, Serguei On 8/14/17 08:38, coleen.phillimore at oracle.com wrote: > > > On 8/13/17 9:04 PM, David Holmes wrote: >> Hi Coleen, >> >> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Make an OopHandle type to replace jobject to encapsulate >>> these oop pointers in metadata and module entry. >>> >>> This replaces places where there's a jobject that doesn't point into >>> the JNIHandles, notably things allocated in ClassLoaderData::_handles. >>> >>> There were platform specific changes that I tried to carefully make >>> - can someone test them for s390, aarch64 and ppc? >>> >>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>> monitoring, parallel class loading and g1class unloading tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >> >> Is it possible to put the declaration of >> MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp >> file to avoid the need to add it to the platform specific hpp files? >> >> I'm unsure about the OopHandle containing set_atomic. First if it is >> present then the _obj field should be volatile. But then it also >> raises the question: if we can race to set this, do we need >> load-acquire versions of the accessors? Based on the single existing >> usage I don't think we presently do. But I think it may be >> cleaner/simpler to not have set_atomic, make the OopHandle immutable, >> and do the cmpxchg back in the caller code by atomically updating _pd >> (which should also be volatile even today) with a new OopHandle. > > I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() > to an address of OopHandle since it is not a pointer but a struct. The > casting would be wrong. So I added a resolve_acquire() for the > protection_domain case in ModuleEntry, and some commentary. > > open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev > > thanks, > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> > From david.holmes at oracle.com Mon Aug 14 20:36:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Aug 2017 06:36:17 +1000 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> Message-ID: <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> Hi Coleen, On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: > > > On 8/13/17 9:04 PM, David Holmes wrote: >> Hi Coleen, >> >> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Make an OopHandle type to replace jobject to encapsulate >>> these oop pointers in metadata and module entry. >>> >>> This replaces places where there's a jobject that doesn't point into >>> the JNIHandles, notably things allocated in ClassLoaderData::_handles. >>> >>> There were platform specific changes that I tried to carefully make - >>> can someone test them for s390, aarch64 and ppc? >>> >>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>> monitoring, parallel class loading and g1class unloading tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >> >> Is it possible to put the declaration of >> MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp >> file to avoid the need to add it to the platform specific hpp files? >> >> I'm unsure about the OopHandle containing set_atomic. First if it is >> present then the _obj field should be volatile. But then it also >> raises the question: if we can race to set this, do we need >> load-acquire versions of the accessors? Based on the single existing >> usage I don't think we presently do. But I think it may be >> cleaner/simpler to not have set_atomic, make the OopHandle immutable, >> and do the cmpxchg back in the caller code by atomically updating _pd >> (which should also be volatile even today) with a new OopHandle. > > I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() to > an address of OopHandle since it is not a pointer but a struct. The _pd would have to be a pointer. > casting would be wrong. So I added a resolve_acquire() for the > protection_domain case in ModuleEntry, and some commentary. For completeness you may also need ptr_acquire(). The _obj field should be volatile. Thanks, David ----- > open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev > > thanks, > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> > From coleen.phillimore at oracle.com Mon Aug 14 21:11:59 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 17:11:59 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <2022a039-4aa5-3775-a1bf-d7fe8dfe67d7@oracle.com> Kim, It's good of you to break this up. Some initial comments: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp.frames.html Should all of the CmpxchgPlatform<1,4,8> functions have an assert like below? I saw them somewhere. With template expansion, perhaps it's impossible otherwise, but this is good documentation of the function's expectations. 231 STATIC_ASSERT(4 == sizeof(T)); Trying to find what happened to: VM_HAS_SPECIALIZED_CMPXCHG_BYTE ... http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/os_cpu/solaris_sparc/vm/solaris_sparc.il.frames.html Very nice. After the atomics, we can file an RFE to move the rest into asm. http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp.frames.html I haven't worked out cmpxchg_using_stub yet. But doing a call like this seems a lot simpler. Why not do this for all the platforms that have stub functions rather than inline assembly? I don't think the cost of doing a call is going to be noticeable performance wise, relative to doing synchronized operations. Could avoid another template. http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html For the second two cmpxchg_ptr functions, can you remove the weird formatting since it's not trying to line up with anything. Can you add a comment just above conditional_store_ptr about what it's for? ie. initialization or rather replacing a null value. This comment about PlatformCmpxchg is really confusing which is D and T. Do you mean T instead of D in the comment below, since the function () takes T ? + // - dest is of type D*. + // - exchange_value and compare_value are of type D. + // - order is of type cmpxchg_memory_order. + // - platform_cmpxchg is an object of type PlatformCmpxchg. + // + // Then + // platform_cmpxchg()(exchange_value, dest, compare_value, order) + // must be a valid expression, returning a result convertible to D. + // + // A default definition is provided, which declares a function template + // T operator()(T, T volatile*, T, cmpxchg_memory_order) const Can you move the public above the comment so it's clear that the comment refers to this CmpxchgByteUsingInt ? And spell out RMW. + // Support platforms that do not provide RMW byte-level atomic access + // To use, derive PlatformCmpxchg<1> from this class. + // Can't be private: C++03 11.4/2; fixed in C++11. +public: + struct CmpxchgByteUsingInt; I could look at IsPointerConvertible for hours and not know what it does without your previous explanation, and even now I can't recall the details. Can you add comment hints? Ie why is (&no)[2] declared like that, and why aren't there function declarations. And that you're using overload resolution to try to convert From* to To*. They don't have to be long comments because nobody's going to stare at this for a while after they get the gist of it. nit, can you remove 'all' in this sentence. Or "These need to be". I'm reading comments now. +// specializations of the class. That all needs to be provided by the So am I reading this right, this doesn't depend on integer promotions, all the integer types must be identical in sign and size? This would be good. +// Handle cmpxchg for integral and enum types. +// +// All the involved types must be identical. +template +struct Atomic::CmpxchgImpl< + T, T, T, + typename EnableIf::value || IsRegisteredEnum::value>::type> + VALUE_OBJ_CLASS_SPEC +{ + T operator()(T exchange_value, T volatile* dest, T compare_value, + cmpxchg_memory_order order) const { + // Forward to the platform handler for the size of T. + return PlatformCmpxchg()(exchange_value, + dest, + compare_value, + order); + } +}; Regarding platforms that don't have a cmpxchg for byte. I see the magic now. Can you add this comment to all the platforms, then also add the line that the implementation of () is shared in atomic.hpp ? +// No direct support for cmpxchg of bytes; emulate using int. +template<> +struct Atomic::PlatformCmpxchg<1> : Atomic::CmpxchgByteUsingInt {}; + Does the name of the function have to be "operator()" ? It's very C++y and maybe standard practice but it's never called as () is it? It could have an english verb for the name, couldn't it? Then one could do some sort of find-all pattern match on it. This is all I can look at for pass 1. It seems reasonable to me. I haven't looked at IntegerTypes again yet. I also didn't look at the sparc asm for correctness since I can't do that. More below: On 8/13/17 10:41 PM, Kim Barrett wrote: > Please review this change to Atomic::cmpxchg, making it a function > template with a per-platform underlying implementation. > > This has been broken out from 8184334: "Generalizing Atomic with > templates", as the originally proposed change there encountered > various objections. This change takes a somewhat different approach > to the same problem. > > One goal is to generalize the API and make it more type-safe, > eliminating (nearly) all need for casts by callers. Another is to > allow more direct per-platform implementations, especially where there > are appropriate compiler intrinsics available. > > If all goes well and this change is accepted, it is intended that the > remainder of Atomic, and later OrderAccess, will be changed in a > similar manner as one or more followups. > > This change to cmpxchg deprecates cmpxchg_ptr. Followup changes will > convert existing uses of cmpxchg_ptr and eventually remove it. > Followup changes will also update uses of cmpxchg that can be > simplified because of the generalized API. Yes, totally agree with the follow-up RFEs. This is going in the right direction. > > The cmpxchg function calls private Atomic::CmpxchgImpl, to select > among several cases, based on the argument types. Each case performs > some checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformCmpxchg. The PlatformCmpxchg class > is provided by each platform, and performs additional case analysis to > generate the appropriate code for the platform. > > This change involves modifications to all of the existing platform > implementations of cmpxchg. I've updated all of the platforms, but > only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > New metaprogramming utilities: > integerTypes.hpp > test_integerTypes.cpp > isRegisteredEnum.hpp > test_isRegisteredEnum.cpp I haven't reviewed the test code. > > Change cmpxchg to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > os_bsd.cpp > os_solaris.cpp > aotCodeHeap.cpp > aotCodeHeap.hpp > psParallelCompact.hpp > workgroup.cpp > oopsHierarchy.hpp > os.cpp > > Example updates of cmpxchg_ptr to cmpxchg: > oop.inline.hpp > bitMap.cpp > bitMap.inline.hpp > > Some specific issues: > > - For Solaris (both SPARC and x86), we were using helper functions > defined in corresponding .il files. Using the cmpxchg_using_stub > helper didn't work; passing a "defined in .il" function as a template > parameter didn't work, leading to linker errors. The ideal solution > is to use gcc-style inline assembly, which is now supported by Solaris > Studio. That change was made for SPARC. However, making that change > for x86 ran into related segfaults, so using the .il definition with > direct conversions for now, until that problem can be resolved. > > - I've added the function template Atomic::condition_store_ptr, which > is a cmpxchg for pointer types with a NULL compare_value. That might > not be the best name for it. Maybe conditional_store_pointer (not condition). otherwise seems ok. > > - The name IntegerTypes was retained from the original RFR for > JDK-8184334. However, that name no longer fits the provided > functionality very well, and I think a new name is needed. Something > involving Bitwise, or ValueRepresentation perhaps? I'm open to > suggestions. I don't mind the IntegerTypes name even though it's not perfect. The other two names suggest other implementations of completely different things already in the vm, so I don't liek them. There are no other sorts of IntegerTypes. > > - Issues with casts/conversions provided by IntegerTypes. > > * Conversions between integers and floating point values are > supported. It was suggested during the discussion of the RFR for > JDK-8184334 that this was not needed, as there are no uses of > atomic/ordered floating point values in Hotspot. However, I'm told > VarHandles may include atomic floating point values. > > * Conversions between integers and floating point values are presently > implemented using the memcpy technique. While this technique is > correct, it is known to be quite poorly optimized by some compilers. > It may be necessary to use the "union trick" for performance reasons, > even though it is technically undefined behavior. Hotspot already > does this elsewhere (and we should merge some of the different > conversion handling). > > * In the original RFR for JDK-8184334, conversions between different > integral types of the same size (along with enums) were performed > using > > reinterpret_cast(from_value) > > This was based on discussion from several months ago, referring to > C++03 3.10/15. However, re-reading that section in response to > discussion of the RFR for JDK-8184334, I now think that implementation > is not supported in many cases needed here, and indeed invokes > undefined behavior in those cases. In particular, where 3.10/15 says > "- a type that is the signed or unsigned type corresponding to the > dynamic type of the object," > > I interpret this to mean that if the dynamic type of an object is an > integral type of a given rank, the value may be accessed using an > lvalue of an integral type of the same rank and the opposite sign. > (Using the same rank and sign is already permitted, since that's the > same type.) I don't think it allows access using an lvalue of an > integral type with a different rank. So, for example, a signed int > value may be accessed via an unsigned int lvalue. But access via a > signed long lvalue is not permitted, even if int and long have the > same size. > > I don't think there is a good way to perform the integral and enum > conversions we need, without invoking implementation-defined, > unspecified, or undefined behavior. > > ** The memcpy technique avoids such problems, but as noted above, is > known to be quite poorly optimized by some compilers. > > ** Using static_cast avoids any undefined behavior, but does have > cases of implementation-defined or unspecified behavior. (When > casting an unsigned value to a signed type, the result may be > implementation defined; 5.2.9/2 and 4.7/3. C++11 plus > the reinterpret_cast to reference seems to provide possibly multi-step > conversion paths that avoid such qualifications on all of the steps.) > (When casting an integral value to an enum type, the result may be > unspecified; 5.2.9/7. With C++11 , the problem doesn't > arise so long as the starting value is appropriate, e.g. we're > reversing an enum to integer conversion.) > > ** Again here, we might consider the "union trick". So the union trick is undefined behavior and reinterpret_cast<> is also undefined behavior (sometimes?). If that's the case, I think we should pick reinterpret_cast<> then because it's intended behavior is clearer. The union trick is really ugly. Won't these undefined behaviors not cause bugs because we compile with the -fno-alias-pattern ? Thanks, Coleen > > I haven't changed the implementation from the JDK-8184334 RFR, but I'm > presently leaning toward the "union trick", despite previous strong > resistance to it. Right now it seems to me to be the best option in > practice, despite being disallowed by the standard. It's really too > bad the memcpy technique is so poorly supported by some compilers. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8186166 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/ > > Testing: > Ad hoc Hotspot nightly test. > > From coleen.phillimore at oracle.com Mon Aug 14 22:27:04 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 18:27:04 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> Message-ID: <66c55369-22ae-530a-53bf-05c37b759508@oracle.com> On 8/14/17 4:36 PM, David Holmes wrote: > Hi Coleen, > > On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/13/17 9:04 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>> these oop pointers in metadata and module entry. >>>> >>>> This replaces places where there's a jobject that doesn't point >>>> into the JNIHandles, notably things allocated in >>>> ClassLoaderData::_handles. >>>> >>>> There were platform specific changes that I tried to carefully make >>>> - can someone test them for s390, aarch64 and ppc? >>>> >>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>>> monitoring, parallel class loading and g1class unloading tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>> >>> Is it possible to put the declaration of >>> MacroAssembler::resolve_oop_handle into the shared >>> macroAssembler.hpp file to avoid the need to add it to the platform >>> specific hpp files? >>> >>> I'm unsure about the OopHandle containing set_atomic. First if it is >>> present then the _obj field should be volatile. But then it also >>> raises the question: if we can race to set this, do we need >>> load-acquire versions of the accessors? Based on the single existing >>> usage I don't think we presently do. But I think it may be >>> cleaner/simpler to not have set_atomic, make the OopHandle >>> immutable, and do the cmpxchg back in the caller code by atomically >>> updating _pd (which should also be volatile even today) with a new >>> OopHandle. >> >> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() >> to an address of OopHandle since it is not a pointer but a struct. The > > _pd would have to be a pointer. Yeah but it's not a pointer. > >> casting would be wrong. So I added a resolve_acquire() for the >> protection_domain case in ModuleEntry, and some commentary. > > For completeness you may also need ptr_acquire(). I can add that too for completeness. > > The _obj field should be volatile. This seems like complete overkill because the one case it matters will access through these order access operations. Coleen > > Thanks, > David > ----- > >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >> >> thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> >> From coleen.phillimore at oracle.com Mon Aug 14 22:34:35 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 18:34:35 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <66c55369-22ae-530a-53bf-05c37b759508@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> <66c55369-22ae-530a-53bf-05c37b759508@oracle.com> Message-ID: <1856b6e4-fccd-dd5e-6f15-72399f5af33a@oracle.com> On 8/14/17 6:27 PM, coleen.phillimore at oracle.com wrote: > > > On 8/14/17 4:36 PM, David Holmes wrote: >> Hi Coleen, >> >> On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/13/17 9:04 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>>> these oop pointers in metadata and module entry. >>>>> >>>>> This replaces places where there's a jobject that doesn't point >>>>> into the JNIHandles, notably things allocated in >>>>> ClassLoaderData::_handles. >>>>> >>>>> There were platform specific changes that I tried to carefully >>>>> make - can someone test them for s390, aarch64 and ppc? >>>>> >>>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>>>> monitoring, parallel class loading and g1class unloading tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>>> >>>> Is it possible to put the declaration of >>>> MacroAssembler::resolve_oop_handle into the shared >>>> macroAssembler.hpp file to avoid the need to add it to the platform >>>> specific hpp files? >>>> >>>> I'm unsure about the OopHandle containing set_atomic. First if it >>>> is present then the _obj field should be volatile. But then it also >>>> raises the question: if we can race to set this, do we need >>>> load-acquire versions of the accessors? Based on the single >>>> existing usage I don't think we presently do. But I think it may be >>>> cleaner/simpler to not have set_atomic, make the OopHandle >>>> immutable, and do the cmpxchg back in the caller code by atomically >>>> updating _pd (which should also be volatile even today) with a new >>>> OopHandle. >>> >>> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() >>> to an address of OopHandle since it is not a pointer but a struct. The >> >> _pd would have to be a pointer. > > Yeah but it's not a pointer. >> >>> casting would be wrong. So I added a resolve_acquire() for the >>> protection_domain case in ModuleEntry, and some commentary. >> >> For completeness you may also need ptr_acquire(). > > I can add that too for completeness. ptr() isn't accessed by multiple threads, so doesn't need acquire. It's for the special case that we want to null out an OopHandle in the CLD::_handles block. Only one thread will have access to that OopHandle because it just created it. Coleen >> >> The _obj field should be volatile. > > This seems like complete overkill because the one case it matters will > access through these order access operations. > > Coleen > >> >> Thanks, >> David >> ----- >> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >>> >>> thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>> > From coleen.phillimore at oracle.com Mon Aug 14 23:46:56 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 19:46:56 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> Message-ID: <1990779c-f3b8-2bbb-5d1a-2a031cb158d9@oracle.com> Better yet, I removed the _pd field assignment from being cmpxchg/conditional and do it under the metaspace_lock which we take out anyway to add the handle. How is this? open webrev at http://cr.openjdk.java.net/~coleenp/8186088.03/webrev I reran the tests that use this code. thanks, Coleen On 8/14/17 4:36 PM, David Holmes wrote: > Hi Coleen, > > On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/13/17 9:04 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>> these oop pointers in metadata and module entry. >>>> >>>> This replaces places where there's a jobject that doesn't point >>>> into the JNIHandles, notably things allocated in >>>> ClassLoaderData::_handles. >>>> >>>> There were platform specific changes that I tried to carefully make >>>> - can someone test them for s390, aarch64 and ppc? >>>> >>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>>> monitoring, parallel class loading and g1class unloading tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>> >>> Is it possible to put the declaration of >>> MacroAssembler::resolve_oop_handle into the shared >>> macroAssembler.hpp file to avoid the need to add it to the platform >>> specific hpp files? >>> >>> I'm unsure about the OopHandle containing set_atomic. First if it is >>> present then the _obj field should be volatile. But then it also >>> raises the question: if we can race to set this, do we need >>> load-acquire versions of the accessors? Based on the single existing >>> usage I don't think we presently do. But I think it may be >>> cleaner/simpler to not have set_atomic, make the OopHandle >>> immutable, and do the cmpxchg back in the caller code by atomically >>> updating _pd (which should also be volatile even today) with a new >>> OopHandle. >> >> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() >> to an address of OopHandle since it is not a pointer but a struct. The > > _pd would have to be a pointer. > >> casting would be wrong. So I added a resolve_acquire() for the >> protection_domain case in ModuleEntry, and some commentary. > > For completeness you may also need ptr_acquire(). > > The _obj field should be volatile. > > Thanks, > David > ----- > >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >> >> thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> >> From david.holmes at oracle.com Tue Aug 15 00:04:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Aug 2017 10:04:48 +1000 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <66c55369-22ae-530a-53bf-05c37b759508@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> <66c55369-22ae-530a-53bf-05c37b759508@oracle.com> Message-ID: <39afd6c4-9a52-506a-e24f-95c87846dac9@oracle.com> On 15/08/2017 8:27 AM, coleen.phillimore at oracle.com wrote: > On 8/14/17 4:36 PM, David Holmes wrote: >> Hi Coleen, >> >> On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/13/17 9:04 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>>> these oop pointers in metadata and module entry. >>>>> >>>>> This replaces places where there's a jobject that doesn't point >>>>> into the JNIHandles, notably things allocated in >>>>> ClassLoaderData::_handles. >>>>> >>>>> There were platform specific changes that I tried to carefully make >>>>> - can someone test them for s390, aarch64 and ppc? >>>>> >>>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>>>> monitoring, parallel class loading and g1class unloading tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>>> >>>> Is it possible to put the declaration of >>>> MacroAssembler::resolve_oop_handle into the shared >>>> macroAssembler.hpp file to avoid the need to add it to the platform >>>> specific hpp files? >>>> >>>> I'm unsure about the OopHandle containing set_atomic. First if it is >>>> present then the _obj field should be volatile. But then it also >>>> raises the question: if we can race to set this, do we need >>>> load-acquire versions of the accessors? Based on the single existing >>>> usage I don't think we presently do. But I think it may be >>>> cleaner/simpler to not have set_atomic, make the OopHandle >>>> immutable, and do the cmpxchg back in the caller code by atomically >>>> updating _pd (which should also be volatile even today) with a new >>>> OopHandle. >>> >>> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() >>> to an address of OopHandle since it is not a pointer but a struct. The >> >> _pd would have to be a pointer. > > Yeah but it's not a pointer. >> >>> casting would be wrong. So I added a resolve_acquire() for the >>> protection_domain case in ModuleEntry, and some commentary. >> >> For completeness you may also need ptr_acquire(). > > I can add that too for completeness. >> >> The _obj field should be volatile. > > This seems like complete overkill because the one case it matters will > access through these order access operations. ?? Any field accessed via race conditions, and which thus will be accessed via orderAccess and Atomics should always be declared volatile! Cheers, David > Coleen > >> >> Thanks, >> David >> ----- >> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >>> >>> thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>> > From david.holmes at oracle.com Tue Aug 15 00:26:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Aug 2017 10:26:33 +1000 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <1990779c-f3b8-2bbb-5d1a-2a031cb158d9@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> <1990779c-f3b8-2bbb-5d1a-2a031cb158d9@oracle.com> Message-ID: On 15/08/2017 9:46 AM, coleen.phillimore at oracle.com wrote: > > Better yet, I removed the _pd field assignment from being > cmpxchg/conditional and do it under the metaspace_lock which we take out > anyway to add the handle. How is this? > > open webrev at http://cr.openjdk.java.net/~coleenp/8186088.03/webrev I like the fact OopHandle no longer has atomics. :) Sorry I'm being a bit dense today when it comes to this code: ! void ClassLoaderData::init_handle_locked(OopHandle& dest, Handle h) { ! MutexLockerEx ml(metaspace_lock(), Mutex::_no_safepoint_check_flag); ! if (dest.resolve() != NULL) { ! return; ! } else { ! dest = _handles.add(h()); ! } } I would have expected to see something like dest.set(x). I'm not sure what magic operator= is doing behind the scenes here ?? I did check the code that calls this, and the locking seems safe in that context. Thanks, David > I reran the tests that use this code. > > thanks, > Coleen > > On 8/14/17 4:36 PM, David Holmes wrote: >> Hi Coleen, >> >> On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/13/17 9:04 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>>> these oop pointers in metadata and module entry. >>>>> >>>>> This replaces places where there's a jobject that doesn't point >>>>> into the JNIHandles, notably things allocated in >>>>> ClassLoaderData::_handles. >>>>> >>>>> There were platform specific changes that I tried to carefully make >>>>> - can someone test them for s390, aarch64 and ppc? >>>>> >>>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>>>> monitoring, parallel class loading and g1class unloading tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>>> >>>> Is it possible to put the declaration of >>>> MacroAssembler::resolve_oop_handle into the shared >>>> macroAssembler.hpp file to avoid the need to add it to the platform >>>> specific hpp files? >>>> >>>> I'm unsure about the OopHandle containing set_atomic. First if it is >>>> present then the _obj field should be volatile. But then it also >>>> raises the question: if we can race to set this, do we need >>>> load-acquire versions of the accessors? Based on the single existing >>>> usage I don't think we presently do. But I think it may be >>>> cleaner/simpler to not have set_atomic, make the OopHandle >>>> immutable, and do the cmpxchg back in the caller code by atomically >>>> updating _pd (which should also be volatile even today) with a new >>>> OopHandle. >>> >>> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() >>> to an address of OopHandle since it is not a pointer but a struct. The >> >> _pd would have to be a pointer. >> >>> casting would be wrong. So I added a resolve_acquire() for the >>> protection_domain case in ModuleEntry, and some commentary. >> >> For completeness you may also need ptr_acquire(). >> >> The _obj field should be volatile. >> >> Thanks, >> David >> ----- >> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >>> >>> thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>> > From david.holmes at oracle.com Tue Aug 15 00:59:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Aug 2017 10:59:19 +1000 Subject: [PATCH]: Zero: Define search_string for M68K In-Reply-To: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> References: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> Message-ID: <911f8225-b8f2-2962-d4b4-36d6f334dea2@oracle.com> Hi Adrian, On 9/08/2017 2:04 AM, John Paul Adrian Glaubitz wrote: > On Linux/m68k, the proper search string for the CPU type is "CPU": > > root at mama:~# cat /proc/cpuinfo > CPU: 68040 > MMU: 68040 > FPU: 68040 > Clocking: 604.5MHz > BogoMips: 403.04 > Calibration: 2015232 loops > root at mama:~# > > The attached patch adds the definition of search_string for M68k. Patch seems fine. I can sponsor this. I filed: https://bugs.openjdk.java.net/browse/JDK-8186221 I'll push this under the trivial rules. David ----- > Adrian > From glaubitz at physik.fu-berlin.de Tue Aug 15 02:15:20 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 15 Aug 2017 04:15:20 +0200 Subject: [PATCH]: Zero: Define search_string for M68K In-Reply-To: <911f8225-b8f2-2962-d4b4-36d6f334dea2@oracle.com> References: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> <911f8225-b8f2-2962-d4b4-36d6f334dea2@oracle.com> Message-ID: <5f93b22c-90ad-ac7f-2b18-dd94212ad9a2@physik.fu-berlin.de> On 08/15/2017 02:59 AM, David Holmes wrote: > Patch seems fine. I can sponsor this. I filed: > > https://bugs.openjdk.java.net/browse/JDK-8186221 > > I'll push this under the trivial rules. Thank you. I hope that I will receive my own account for the JBS soon, so I can publish my patches in the proper way. I have around 25 patches queued ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Tue Aug 15 02:21:27 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Aug 2017 22:21:27 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <2022a039-4aa5-3775-a1bf-d7fe8dfe67d7@oracle.com> References: <2022a039-4aa5-3775-a1bf-d7fe8dfe67d7@oracle.com> Message-ID: <862AB794-BD21-42F9-96D8-741912FF73B0@oracle.com> > On Aug 14, 2017, at 5:11 PM, coleen.phillimore at oracle.com wrote: > > > Kim, > > It's good of you to break this up. Some initial comments: Thanks for looking at this. I didn't want to do all the work of dealing with all of Atomic this way until there was general agreement that this way was acceptable. I?m going to hold off on a new webrev for a bit, to see if there are more comments, or problems found (esp. with the platforms I haven?t tested). > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp.frames.html > > Should all of the CmpxchgPlatform<1,4,8> functions have an assert like below? Yes. Done. > Trying to find what happened to: > > VM_HAS_SPECIALIZED_CMPXCHG_BYTE VM_HAS_SPECIALIZED_CMPXCHG_BYTE no longer exists. Platforms *must* provide cmpxchg for bytes, either (1) directly, (2) by using CmpxchgByteUsingInt, or (3) by some other mechanism, of which there are presently no examples. Requiring it be explicitly handled is pretty simple, and makes it clear that using the helper is intentional, and not an oversight. > ... > > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/os_cpu/solaris_sparc/vm/solaris_sparc.il.frames.html > > Very nice. After the atomics, we can file an RFE to move the rest into asm. As David pointed out, that RFE already exists. https://bugs.openjdk.java.net/browse/JDK-8153076 > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp.frames.html > > I haven't worked out cmpxchg_using_stub yet. But doing a call like this seems a lot simpler. Why not do this for all the platforms that have stub functions rather than inline assembly? I don't think the cost of doing a call is going to be noticeable performance wise, relative to doing synchronized operations. Could avoid another template. cmpxchg_using_stub exists because I got tired of typing IntegerTypes::cast over, and over, and over... cmpxchg_using_stub just packages that up. > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html > > For the second two cmpxchg_ptr functions, can you remove the weird formatting since it's not trying to line up with anything. Done. > Can you add a comment just above conditional_store_ptr about what it's for? ie. initialization or rather replacing a null value. Done. > This comment about PlatformCmpxchg is really confusing which is D and T. Do you mean T instead of D in the comment below, since the function () takes T ? Yes, there were a few problems there. I think I?ve fixed them all. > Can you move the public above the comment so it's clear that the comment refers to this CmpxchgByteUsingInt ? And spell out RMW. > > + // Support platforms that do not provide RMW byte-level atomic access > + // To use, derive PlatformCmpxchg<1> from this class. > + // Can't be private: C++03 11.4/2; fixed in C++11. > +public: > + struct CmpxchgByteUsingInt; I expanded RMW. I moved the ?Can?t be private?? comment to the same line as public: I don?t really want to move the public: - it exists only as a (temporary?) workaround for a C++98 defect, and moving it would make the intent less clear. (The intent being that one should squint and pretend it isn?t there.) > I could look at IsPointerConvertible for hours and not know what it does without your previous explanation, and even now I can't recall the details. Can you add comment hints? Ie why is (&no)[2] declared like that, and why aren't there function declarations. And that you're using overload resolution to try to convert From* to To*. They don't have to be long comments because nobody's going to stare at this for a while after they get the gist of it. I made the existing comment more explicit about what it?s accomplishing, while leaving the mechanism described by reference to the ?sizeof trick?. I don?t really want to write a primer on a ?well known? and fundamental technique. > nit, can you remove 'all' in this sentence. Or "These need to be?. > +// specializations of the class. That all needs to be provided by the I reworded it. > I'm reading comments now. :) > So am I reading this right, this doesn't depend on integer promotions, all the integer types must be identical in sign and size? This would be good. > > +// Handle cmpxchg for integral and enum types. > +// > +// All the involved types must be identical. > +template > +struct Atomic::CmpxchgImpl< > + T, T, T, > + typename EnableIf::value || IsRegisteredEnum::value>::type> > [?] Not just same size, same rank. So int, long, and long long are different, even if some pairs are the same size. This is most likely to lead to annoying mismatches where literal constants are used. That doesn?t seem to come up much with cmpxchg, but I?m expecting Atomic::add to be more ?interesting?. > Regarding platforms that don't have a cmpxchg for byte. I see the magic now. Magic? It?s just class inheritance? > Does the name of the function have to be "operator()" ? It's very C++y and maybe standard practice but it's never called as () is it? It could have an english verb for the name, couldn't it? Then one could do some sort of find-all pattern match on it. The pattern you want to look for with something like this is the class name, e.g. PlatformCmpxchg. There?s no particularly good name for the operation that makes it easier to find. What would you call it? cmpxchg? doit? >> - I've added the function template Atomic::condition_store_ptr, which >> is a cmpxchg for pointer types with a NULL compare_value. That might >> not be the best name for it. > > Maybe conditional_store_pointer (not condition). otherwise seems ok. ?condition? was a typo; it?s presently called conditional_store_ptr. >> - The name IntegerTypes was retained from the original RFR for >> JDK-8184334. However, that name no longer fits the provided >> functionality very well, and I think a new name is needed. Something >> involving Bitwise, or ValueRepresentation perhaps? I'm open to >> suggestions. > > I don't mind the IntegerTypes name even though it's not perfect. The other two names suggest other implementations of completely different things already in the vm, so I don't liek them. There are no other sorts of IntegerTypes. I really dislike IntegerTypes; I don?t think that?s at all evocative of what it?s become. >> - Issues with casts/conversions provided by IntegerTypes. >> > > So the union trick is undefined behavior and reinterpret_cast<> is also undefined behavior (sometimes?). If that's the case, I think we should pick reinterpret_cast<> then because it's intended behavior is clearer. The union trick is really ugly. The union trick has the benefit of being explicitly supported by some platforms, and long use on others. And some commentary would be needed regardless. And it?s not really that ugly, e.g. something like template inline T convert_using_union(U x) { union { T t; U u; }; u = x; return t; } From david.holmes at oracle.com Tue Aug 15 02:55:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Aug 2017 12:55:18 +1000 Subject: [PATCH]: Zero: Define search_string for M68K In-Reply-To: <5f93b22c-90ad-ac7f-2b18-dd94212ad9a2@physik.fu-berlin.de> References: <6db7a456-be89-b477-6414-66a886e9b3e6@physik.fu-berlin.de> <911f8225-b8f2-2962-d4b4-36d6f334dea2@oracle.com> <5f93b22c-90ad-ac7f-2b18-dd94212ad9a2@physik.fu-berlin.de> Message-ID: <16954d7d-5086-78b7-c683-952235588e9a@oracle.com> On 15/08/2017 12:15 PM, John Paul Adrian Glaubitz wrote: > On 08/15/2017 02:59 AM, David Holmes wrote: >> Patch seems fine. I can sponsor this. I filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8186221 >> >> I'll push this under the trivial rules. > > Thank you. > > I hope that I will receive my own account for the JBS soon, so I can > publish my patches in the proper way. > > I have around 25 patches queued ;-). :) You'll still need a sponsor for any shared-code changes to hotspot so it can be pushed via our build&test system JPRT. Cheers, David > Adrian > From coleen.phillimore at oracle.com Tue Aug 15 02:56:43 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 22:56:43 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> <1990779c-f3b8-2bbb-5d1a-2a031cb158d9@oracle.com> Message-ID: On 8/14/17 8:26 PM, David Holmes wrote: > On 15/08/2017 9:46 AM, coleen.phillimore at oracle.com wrote: >> >> Better yet, I removed the _pd field assignment from being >> cmpxchg/conditional and do it under the metaspace_lock which we take >> out anyway to add the handle. How is this? >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.03/webrev > > I like the fact OopHandle no longer has atomics. :) Yes, this solved a bunch of problems. > > Sorry I'm being a bit dense today when it comes to this code: > > ! void ClassLoaderData::init_handle_locked(OopHandle& dest, Handle h) { > ! MutexLockerEx ml(metaspace_lock(), Mutex::_no_safepoint_check_flag); > ! if (dest.resolve() != NULL) { > ! return; > ! } else { > ! dest = _handles.add(h()); > ! } > } > > I would have expected to see something like dest.set(x). I'm not sure > what magic operator= is doing behind the scenes here ?? It's doing a bitwise copy. > > I did check the code that calls this, and the locking seems safe in > that context. > Thanks. It's a lot better now. Coleen > Thanks, > David > >> I reran the tests that use this code. >> >> thanks, >> Coleen >> >> On 8/14/17 4:36 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 8/13/17 9:04 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>>>> these oop pointers in metadata and module entry. >>>>>> >>>>>> This replaces places where there's a jobject that doesn't point >>>>>> into the JNIHandles, notably things allocated in >>>>>> ClassLoaderData::_handles. >>>>>> >>>>>> There were platform specific changes that I tried to carefully >>>>>> make - can someone test them for s390, aarch64 and ppc? >>>>>> >>>>>> Tested with tier1 testing, JPRT (all oracle platforms), >>>>>> nsk.jvmti, monitoring, parallel class loading and g1class >>>>>> unloading tests. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>>>> >>>>> Is it possible to put the declaration of >>>>> MacroAssembler::resolve_oop_handle into the shared >>>>> macroAssembler.hpp file to avoid the need to add it to the >>>>> platform specific hpp files? >>>>> >>>>> I'm unsure about the OopHandle containing set_atomic. First if it >>>>> is present then the _obj field should be volatile. But then it >>>>> also raises the question: if we can race to set this, do we need >>>>> load-acquire versions of the accessors? Based on the single >>>>> existing usage I don't think we presently do. But I think it may >>>>> be cleaner/simpler to not have set_atomic, make the OopHandle >>>>> immutable, and do the cmpxchg back in the caller code by >>>>> atomically updating _pd (which should also be volatile even today) >>>>> with a new OopHandle. >>>> >>>> I couldn't convince the compiler to compile an >>>> Atomic::cmpxchg_ptr() to an address of OopHandle since it is not a >>>> pointer but a struct. The >>> >>> _pd would have to be a pointer. >>> >>>> casting would be wrong. So I added a resolve_acquire() for the >>>> protection_domain case in ModuleEntry, and some commentary. >>> >>> For completeness you may also need ptr_acquire(). >>> >>> The _obj field should be volatile. >>> >>> Thanks, >>> David >>> ----- >>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >>>> >>>> thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>> >> From coleen.phillimore at oracle.com Tue Aug 15 03:02:02 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Aug 2017 23:02:02 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <29D266B8-375F-4538-B39C-5AB323B93DB7@oracle.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <29D266B8-375F-4538-B39C-5AB323B93DB7@oracle.com> Message-ID: <99c92309-b5db-21b9-a2ca-0f602852893f@oracle.com> On 8/14/17 1:41 PM, Jiangli Zhou wrote: > Hi Coleen, > > This looks good to me. I noticed a small issue, which isn?t caused by your change, but related to ClassLoaderData::remove_handle_unsafe(). There could be a small memory leak in the ChunkedHandleList when remove_handle_unsafe() is used to remove a handle under race condition. ClassLoaderData::remove_handle_unsafe() only sets the *_data[idx] to NULL in the list. However, that _data[idx] is never reused and set to another oop after the point. Currently the race condition could only happen during setting one of the shared ProtectionDomain, so the leak is small. To avoid the memory leak, ChunkedHandleList::add() could try to reuse a NULL _data[idx] in the list, but that requires to scan the _data[] array of all chunks. Since this is not part of your change, I think we can handle that separately. Hi Jiangli, Can you have a look at the latest RFR? I removed this remove_handle_unsafe. I probably need to add it back again to fix a longstanding bug with redefinition. When they were JNIHandleBlocks we did reuse entries sometimes, but now that they're chunked array. I'm not sure if they can do that without breaking GC (CMS). Thanks, Coleen > > Thanks, > Jiangli > >> On Aug 14, 2017, at 8:38 AM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 8/13/17 9:04 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make an OopHandle type to replace jobject to encapsulate these oop pointers in metadata and module entry. >>>> >>>> This replaces places where there's a jobject that doesn't point into the JNIHandles, notably things allocated in ClassLoaderData::_handles. >>>> >>>> There were platform specific changes that I tried to carefully make - can someone test them for s390, aarch64 and ppc? >>>> >>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, monitoring, parallel class loading and g1class unloading tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>> Is it possible to put the declaration of MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp file to avoid the need to add it to the platform specific hpp files? >>> >>> I'm unsure about the OopHandle containing set_atomic. First if it is present then the _obj field should be volatile. But then it also raises the question: if we can race to set this, do we need load-acquire versions of the accessors? Based on the single existing usage I don't think we presently do. But I think it may be cleaner/simpler to not have set_atomic, make the OopHandle immutable, and do the cmpxchg back in the caller code by atomically updating _pd (which should also be volatile even today) with a new OopHandle. >> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() to an address of OopHandle since it is not a pointer but a struct. The casting would be wrong. So I added a resolve_acquire() for the protection_domain case in ModuleEntry, and some commentary. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >> >> thanks, >> Coleen >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> From david.holmes at oracle.com Tue Aug 15 06:57:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Aug 2017 16:57:19 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> Message-ID: Hi Kim, All points in your response below noted - in particular the problem with enum definition locations for registration. Again many thanks for your perseverance on this and for making things more palatable for those of us not familiar with this style of programming. Here's the rest of the review - with some things already addressed, or flagged, by Coleen's review and your responses ("sizeof trick"!!). Many of my initial questions/comments have resolved themselves as I've gotten further through the review. :) Just a few queries and a couple of suggestions left. src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp The actual body has: 435 long old_value; rather than "T old_value". I presume the AIX compiler can't handle using T with inline asm? --- src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp We must revisit why we are using the stub generator on Windows! --- src/share/vm/gc/shared/workgroup.cpp if (old == 0) { ! old = Atomic::cmpxchg(1u, &_tasks[t], 0u); } assert(_tasks[t] == 1, "What else?"); I don't understand why we can compare against 0 and 1, yet must pass 0u and 1u to our extremely clever template function. :( --- src/share/vm/oops/oop.inline.hpp 400 volatile HeapWord *dest, 411 narrowOop old = Atomic::cmpxchg(val, (narrowOop*)dest, cmp); 418 return Atomic::cmpxchg(exchange_value, (oop*)dest, compare_value); do the casts here indicate we should have some conversion function from HeapWord to oop and narrowoop? --- src/share/vm/runtime/atomic.hpp So the overall chain of things is: cmpxchg -> CmpxchgImpl -> PlatformCmpxchg -> inline assembly; or |-> cmpxchg_using_stub -> external .s/.il definition. I'm unclear why we need CmpxchgImpl - or more accurately I'm unclear why all the type "dispatching" that CmpxchgImpl does can't be done by the top-level Atomic::cmpxchg template? So cmpxchg_using_stub exists to deal with any needed conversions (type or order) between the PlatformCmpxchg API and the actual platform-specific functions (if they exist) - ok. Only nit I have here is the use of "stub" because when I see that I think of the stubGenerator, and this has nothing to do with that. How about cmpxchg_adapter? (And perhaps StubFn should be something else ... I don't see it as a stub, as its the real function to do the work ... could just be Fn? --- inline T Atomic::PlatformCmpxchg<1>::operator() Coleen flagged that use of operator() is somewhat obscure, and I tend to agree. At the moment calling it cmpxchg might seem redundant, but what if the naming scheme were eg: Atomic::Platform<1>:cmpxchg Atomic::Platform<1>:add etc? --- 182 template 183 static T cmpxchg_using_stub(StubFn stub_fn, 184 T exchange_value, 185 T volatile* dest, 186 T compare_value); Templates 101 question: why when we instantiate this template do we only need to pass StubType explicitly eg: cmpxchg_using_stub(_Atomic_cmpxchg_long, exchange_value, dest, compare_value); are the other types inferred from the function arguments? --- IsPointerConvertible ... yep now I get it. I got the sizeof trick quickly but was missing the actual conversion check - now realizing that test() will select test(To*) if there is a conversion, and test(...) if not. :) ---- That's it. :) Thanks, David ----- On 15/08/2017 2:35 AM, Kim Barrett wrote: >> On Aug 14, 2017, at 1:08 AM, David Holmes wrote: >> >> Hi Kim, >> >> This is an initial partial review. I have to move onto other stuff today so will get back to this tomorrow. > > Thanks. > >> On 14/08/2017 12:41 PM, Kim Barrett wrote: >>> Please review this change to Atomic::cmpxchg, making it a function >>> template with a per-platform underlying implementation. >>> This has been broken out from 8184334: "Generalizing Atomic with >>> templates", as the originally proposed change there encountered >>> various objections. This change takes a somewhat different approach >>> to the same problem. >> >> I assume the intent is not to push this yet, so that Erik has a chance to weigh-in when he gets back from vacation? I would not want to see unnecessary churn here. > > I had thought it might depend on how quickly this review went. But > Jesper's request to make jdk/hs temporarily slushy makes a push before > Erik's return seem quite unlikely. > >> [?] >>> - I've added the function template Atomic::condition_store_ptr, which >>> is a cmpxchg for pointer types with a NULL compare_value. That might >>> not be the best name for it. >> >> Definitely not the best name for it. :) replace_if_null seems to describe it more precisely. > > That seems like a good name. I'll wait a bit for other opinions. > >>> - The name IntegerTypes was retained from the original RFR for >>> JDK-8184334. However, that name no longer fits the provided >>> functionality very well, and I think a new name is needed. Something >>> involving Bitwise, or ValueRepresentation perhaps? I'm open to >>> suggestions. >> >> How about PrimitiveTypes? > > I'll wait for other opinions. That name suggests to me that support > for floating point should be included. And see below. > >>> - Issues with casts/conversions provided by IntegerTypes. >>> * Conversions between integers and floating point values are >>> supported. It was suggested during the discussion of the RFR for >>> JDK-8184334 that this was not needed, as there are no uses of >>> atomic/ordered floating point values in Hotspot. However, I'm told >>> VarHandles may include atomic floating point values. >> >> Yes they were added. However at the level of jdk.internal.misc.Unsafe all the FP operations are converted to int/long variants using eg Float.floatToRawIntBits etc. >> >> But I'm not convinced we need to complicate things by supporting floating-point Atomic::cmpxchg in the VM's Atomic API. You can only do so by implementing the floatToRawIntBits etc functionality, and there are no native mappings for any "atomic" floating-point operation (ie the only way to do Atomic::inc on a floating=point value is to use cmpxchg.) > > I was about to agree to removal of floating point from here. Then I > remembered the jmumble_cast suite of functions in > globalDefinitions.hpp. Erik and I had discussed a unification, with > the jmumble_cast functions built on IntegerTypes. We can't presently > do that, because of include dependencies, but that's probably fixable. > We see this utility as having application beyond Atomic &etc template > reimplementation. > > But clearly the memcpy technique can't be retained, due to the > deficiencies of some compilers. > >>> * In the original RFR for JDK-8184334, conversions between different >>> integral types of the same size (along with enums) were performed >>> using >>> reinterpret_cast(from_value) >>> [?] >> >> I find that all rather dismaying. > > No kidding! > >> [?] >> src/share/vm/metaprogramming/isRegisteredEnum.hpp >> >> My initial personal preference here is to see registered enum types added to this header file rather than as template specializations at the point of use. Is that reasonable/feasible, or are there reasons to spread this around? > > That would require moving the complete enum definitions here, far away > from their natural location. We can't forward declare them here for > registration; forward declaration of enum types doesn't work (doesn't > compile), since the compiler can't determine the underlying type > without knowing the enumerators. Also, such a move would only be > possible for an enum type defined at namespace scope; class scoped > enums cannot be so moved. > >> test/native/metaprogramming/test_integerTypes.cpp >> test/native/metaprogramming/test_isRegisteredEnum.cpp >> >> Seems minimalist but ok. >> >> Aside: I find it slightly limiting that because these templates involve compile-time checks, that we can't actually write negative tests. Seems to me that when writing the templates you had to write a test case that will fail, to verify the correctness of the template, but you can't check-in that testcase. Maybe we need a test harness that can handle 'tests' that simply fail to compile ... ? > > When the addition of native testing was being discussed, that was a > feature I mentioned as being needed. But that doesn't seem to have > happened, and I couldn't find an existing RFE, so I filed a new one: > https://bugs.openjdk.java.net/browse/JDK-8186177 > Native testing needs support for compile-fail tests > From rkennke at redhat.com Tue Aug 15 14:22:58 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 15 Aug 2017 10:22:58 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> Message-ID: <8beaf90e-4461-e129-4b7f-ce79e7152c38@redhat.com> Am 14.08.2017 um 11:56 schrieb Kim Barrett: >> On Aug 14, 2017, at 10:28 AM, Roman Kennke wrote: >> >> I still don't understand why we want to allow for different types for >> the new and expected values and the memory location (T, D and U). We >> haven't allowed for this before, why are we doing it now? > Different types are only permitted in the pointer value case, > e.g. cmpxchg(T*, D* volatile*, U*). > > The compare_value type is permitted to differ from the destination's > value type only in cv-qualifiers. Consider a member variable "var" of > type int*. > > const int* old_value = var; > ... compute new_value ... > cmpxchg(new_value, &var, old_value); > > It is perfectly reasonable and appropriate to const-qualify > old_value's type in that way. But that would require a source level > cast if cmpxchg required an exact type match for *dest and > compare_value. > > We permit the exchange_value type to be less cv-qualified than the > *dest type. We also permit derived to base conversions. Both of > those are natural and type-safe, and may eliminate the need for some > source level casts. > >> We haven't allowed for this before, why are we doing it now? > Because of the complete type-discarding done by cmpxchg_ptr, I suggest > we have no clue what our current code might or might not be doing. > I don't see that anywhere. The only situations that I could find are a few places where dest is cast to (volatile foo*), which makes me question whether that dest field should be marked volatile in the first place. I see no patterns as you described above involving any const casts. And I am absolutely against introducing some machinery that is not actually used. If it's not used, it's dead, and only increases debt rather than decrease it. (Note: the situation would be different if it were a public API. but it isn't) From glaubitz at physik.fu-berlin.de Tue Aug 15 15:45:31 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 15 Aug 2017 17:45:31 +0200 Subject: generated-configure.sh vs. platform.m4 Message-ID: <937689c2-d7a5-c4f5-7538-a6fb6d553b41@physik.fu-berlin.de> Hi! I am currently preparing patches to add a couple of missing architectures to autoconf which we are using in Debian. For that, I looked at an earlier commit which added s390(x): changeset: 786:0874bb4707b7 tag: jdk8-b107 user: omajid date: Wed Sep 11 12:08:34 2013 -0400 summary: 8024320: Add s390(x) detection to platform.m4 In this commit, the definitions were both added to platform.m4 and generated_configure.sh. However, in Debian, we're carrying local patches for that which only modify platform.m4 and in Debian, we usually just run autoconf to make sure the generated configure scripts are up-to-date. So, in order to get these definitions upstream, should I patch both platform.m4 and generated_configure.sh or just the former? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Tue Aug 15 17:28:42 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Aug 2017 13:28:42 -0400 Subject: generated-configure.sh vs. platform.m4 In-Reply-To: <937689c2-d7a5-c4f5-7538-a6fb6d553b41@physik.fu-berlin.de> References: <937689c2-d7a5-c4f5-7538-a6fb6d553b41@physik.fu-berlin.de> Message-ID: <105CD573-A19B-4129-9F99-8400482CA33F@oracle.com> > On Aug 15, 2017, at 11:45 AM, John Paul Adrian Glaubitz wrote: > > Hi! > > I am currently preparing patches to add a couple of missing > architectures to autoconf which we are using in Debian. > > For that, I looked at an earlier commit which added s390(x): > > changeset: 786:0874bb4707b7 > tag: jdk8-b107 > user: omajid > date: Wed Sep 11 12:08:34 2013 -0400 > summary: 8024320: Add s390(x) detection to platform.m4 > > In this commit, the definitions were both added to platform.m4 and > generated_configure.sh. However, in Debian, we're carrying local > patches for that which only modify platform.m4 and in Debian, we > usually just run autoconf to make sure the generated configure > scripts are up-to-date. > > So, in order to get these definitions upstream, should I patch both > platform.m4 and generated_configure.sh or just the former? There is a closed generated_configure.sh that also needs to be updated. Since that can only be done by someone within Oracle, and the update process affects both generated files, I think just the patch to platform.m4 is sufficient. Your sponsor who does the push is responsible for the regeneration of those files as part of preparing to push the change. Just remind your sponsor that the regeneration is needed. Also note it in the RFR, to remind any reviewers who want to test the change that they need that step. > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From igor.ignatyev at oracle.com Tue Aug 15 19:05:00 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 15 Aug 2017 12:05:00 -0700 Subject: RFR(XS): 8184772 - Make it possible to pass arguments only to the Java running the tests when running jtreg through make In-Reply-To: <8E8074E9-7E43-4724-A46C-543CF8027E1F@oracle.com> References: <8E8074E9-7E43-4724-A46C-543CF8027E1F@oracle.com> Message-ID: <46B38B89-7BC3-448E-803D-4863F7AAFA28@oracle.com> Hi Christian, the fix looks good to me. Thanks, -- Igor > On Aug 14, 2017, at 4:39 AM, Christian Tornqvist wrote: > > Hi everyone, > > Please review this small change that enables passing options only to the Java under test when running jtreg through the make files. Options passed as -vmoption will be passed to both to the Java compiling and running the tests, options passed as -javaoptions are only passed to the Java running the tests. > > Change has been verified locally and in our test lab by running the Hotspot jtreg tests along with JDK tier1-3. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8184772/webrev.00/ > Bug (Unfortunately not publicly available): https://bugs.openjdk.java.net/browse/JDK-8184772 > > Thanks, > Christian From george.triantafillou at oracle.com Tue Aug 15 19:17:19 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 15 Aug 2017 15:17:19 -0400 Subject: RFR(XS): 8184772 - Make it possible to pass arguments only to the Java running the tests when running jtreg through make In-Reply-To: <8E8074E9-7E43-4724-A46C-543CF8027E1F@oracle.com> References: <8E8074E9-7E43-4724-A46C-543CF8027E1F@oracle.com> Message-ID: Hi Christian, Looks good. -George On 8/14/2017 7:39 AM, Christian Tornqvist wrote: > Hi everyone, > > Please review this small change that enables passing options only to the Java under test when running jtreg through the make files. Options passed as -vmoption will be passed to both to the Java compiling and running the tests, options passed as -javaoptions are only passed to the Java running the tests. > > Change has been verified locally and in our test lab by running the Hotspot jtreg tests along with JDK tier1-3. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8184772/webrev.00/ > Bug (Unfortunately not publicly available): https://bugs.openjdk.java.net/browse/JDK-8184772 > > Thanks, > Christian From david.holmes at oracle.com Tue Aug 15 21:33:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Aug 2017 07:33:56 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <8beaf90e-4461-e129-4b7f-ce79e7152c38@redhat.com> References: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> <8beaf90e-4461-e129-4b7f-ce79e7152c38@redhat.com> Message-ID: <5ce1c3c2-9aaf-17ad-eddd-beb348f247ed@oracle.com> Hi Roman, On 16/08/2017 12:22 AM, Roman Kennke wrote: > Am 14.08.2017 um 11:56 schrieb Kim Barrett: >>> On Aug 14, 2017, at 10:28 AM, Roman Kennke wrote: >>> >>> I still don't understand why we want to allow for different types for >>> the new and expected values and the memory location (T, D and U). We >>> haven't allowed for this before, why are we doing it now? >> Different types are only permitted in the pointer value case, >> e.g. cmpxchg(T*, D* volatile*, U*). >> >> The compare_value type is permitted to differ from the destination's >> value type only in cv-qualifiers. Consider a member variable "var" of >> type int*. >> >> const int* old_value = var; >> ... compute new_value ... >> cmpxchg(new_value, &var, old_value); >> >> It is perfectly reasonable and appropriate to const-qualify >> old_value's type in that way. But that would require a source level >> cast if cmpxchg required an exact type match for *dest and >> compare_value. >> >> We permit the exchange_value type to be less cv-qualified than the >> *dest type. We also permit derived to base conversions. Both of >> those are natural and type-safe, and may eliminate the need for some >> source level casts. >> >>> We haven't allowed for this before, why are we doing it now? >> Because of the complete type-discarding done by cmpxchg_ptr, I suggest >> we have no clue what our current code might or might not be doing. >> > I don't see that anywhere. The only situations that I could find are a > few places where dest is cast to (volatile foo*), which makes me > question whether that dest field should be marked volatile in the first > place. I see no patterns as you described above involving any const I think it is the very existence of cmpxchg_ptr, to isolate the cases involving pointers, that is at issue. There should not be a need for cmpxchg_ptr - a well-typed cmpxchg should handle all type variants. And that requires the template mechanisms. > casts. And I am absolutely against introducing some machinery that is > not actually used. If it's not used, it's dead, and only increases debt > rather than decrease it. (Note: the situation would be different if it > were a public API. but it isn't) I don't see how this will be unused dead code - it will be used whenever pointers are used with cmpxchg. ?? Cheers, David From david.holmes at oracle.com Tue Aug 15 21:36:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Aug 2017 07:36:20 +1000 Subject: generated-configure.sh vs. platform.m4 In-Reply-To: <105CD573-A19B-4129-9F99-8400482CA33F@oracle.com> References: <937689c2-d7a5-c4f5-7538-a6fb6d553b41@physik.fu-berlin.de> <105CD573-A19B-4129-9F99-8400482CA33F@oracle.com> Message-ID: <4fa3ec09-c653-b53a-b710-e81cb5154e56@oracle.com> Also note that any changes to the .m4 files need to be reviewed on build-dev at openjdk.java.net, not hotspot-dev (or not just hotspot-dev). David On 16/08/2017 3:28 AM, Kim Barrett wrote: >> On Aug 15, 2017, at 11:45 AM, John Paul Adrian Glaubitz wrote: >> >> Hi! >> >> I am currently preparing patches to add a couple of missing >> architectures to autoconf which we are using in Debian. >> >> For that, I looked at an earlier commit which added s390(x): >> >> changeset: 786:0874bb4707b7 >> tag: jdk8-b107 >> user: omajid >> date: Wed Sep 11 12:08:34 2013 -0400 >> summary: 8024320: Add s390(x) detection to platform.m4 >> >> In this commit, the definitions were both added to platform.m4 and >> generated_configure.sh. However, in Debian, we're carrying local >> patches for that which only modify platform.m4 and in Debian, we >> usually just run autoconf to make sure the generated configure >> scripts are up-to-date. >> >> So, in order to get these definitions upstream, should I patch both >> platform.m4 and generated_configure.sh or just the former? > > There is a closed generated_configure.sh that also needs to be updated. > Since that can only be done by someone within Oracle, and the update > process affects both generated files, I think just the patch to platform.m4 > is sufficient. Your sponsor who does the push is responsible for the > regeneration of those files as part of preparing to push the change. Just > remind your sponsor that the regeneration is needed. Also note it in the > RFR, to remind any reviewers who want to test the change that they need > that step. > >> Thanks, >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaubitz at debian.org >> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > From glaubitz at physik.fu-berlin.de Tue Aug 15 21:37:27 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 15 Aug 2017 23:37:27 +0200 Subject: generated-configure.sh vs. platform.m4 In-Reply-To: <4fa3ec09-c653-b53a-b710-e81cb5154e56@oracle.com> References: <937689c2-d7a5-c4f5-7538-a6fb6d553b41@physik.fu-berlin.de> <105CD573-A19B-4129-9F99-8400482CA33F@oracle.com> <4fa3ec09-c653-b53a-b710-e81cb5154e56@oracle.com> Message-ID: On 08/15/2017 11:36 PM, David Holmes wrote: > Also note that any changes to the .m4 files need to be reviewed on > build-dev at openjdk.java.net, not hotspot-dev (or not just hotspot-dev). Oh, right. Very good point. I forgot about this. Thanks! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From rkennke at redhat.com Wed Aug 16 00:08:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 15 Aug 2017 20:08:07 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <5ce1c3c2-9aaf-17ad-eddd-beb348f247ed@oracle.com> References: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> <8beaf90e-4461-e129-4b7f-ce79e7152c38@redhat.com> <5ce1c3c2-9aaf-17ad-eddd-beb348f247ed@oracle.com> Message-ID: <30e528bd-4ff3-b16f-b965-511c4fcb960f@redhat.com> Am 15.08.2017 um 17:33 schrieb David Holmes: > Hi Roman, > > On 16/08/2017 12:22 AM, Roman Kennke wrote: >> Am 14.08.2017 um 11:56 schrieb Kim Barrett: >>>> On Aug 14, 2017, at 10:28 AM, Roman Kennke wrote: >>>> >>>> I still don't understand why we want to allow for different types for >>>> the new and expected values and the memory location (T, D and U). We >>>> haven't allowed for this before, why are we doing it now? >>> Different types are only permitted in the pointer value case, >>> e.g. cmpxchg(T*, D* volatile*, U*). >>> >>> The compare_value type is permitted to differ from the destination's >>> value type only in cv-qualifiers. Consider a member variable "var" of >>> type int*. >>> >>> const int* old_value = var; >>> ... compute new_value ... >>> cmpxchg(new_value, &var, old_value); >>> >>> It is perfectly reasonable and appropriate to const-qualify >>> old_value's type in that way. But that would require a source level >>> cast if cmpxchg required an exact type match for *dest and >>> compare_value. >>> >>> We permit the exchange_value type to be less cv-qualified than the >>> *dest type. We also permit derived to base conversions. Both of >>> those are natural and type-safe, and may eliminate the need for some >>> source level casts. >>> >>>> We haven't allowed for this before, why are we doing it now? >>> Because of the complete type-discarding done by cmpxchg_ptr, I suggest >>> we have no clue what our current code might or might not be doing. >>> >> I don't see that anywhere. The only situations that I could find are a >> few places where dest is cast to (volatile foo*), which makes me >> question whether that dest field should be marked volatile in the first >> place. I see no patterns as you described above involving any const > > I think it is the very existence of cmpxchg_ptr, to isolate the cases > involving pointers, that is at issue. There should not be a need for > cmpxchg_ptr - a well-typed cmpxchg should handle all type variants. > And that requires the template mechanisms. Oh I think you misunderstood. I was not taking issue with cmpxchg_ptr or templates. cmpxchg_ptr will go away as I understand, and I am fine with using templates. I do agree that using templates for cmpxchg() is the right thing to do. I was asking why the new templated cmpxchg() needs 3 different types for new, expected and dest, whereas it should just be one type (in my mind). Kim was saying that is only because of pointers and not being able to match different cv qualifications. I looked through the code and could not find one instance where const would be involved, and I only found a few places where we used to cast to volatile or cast away volatile, and it seems to me we should rather fix those fields to be of the matching type (i.e. volatile foo*) instead. We are accessing them using cmpxchg after all. >> casts. And I am absolutely against introducing some machinery that is >> not actually used. If it's not used, it's dead, and only increases debt >> rather than decrease it. (Note: the situation would be different if it >> were a public API. but it isn't) > > I don't see how this will be unused dead code - it will be used > whenever pointers are used with cmpxchg. ?? I was arguing that adding code (e.g. template args and casting code) specifically to deal with pointers and cv mismatches, where there are no actual such mismatches (at least not involving const, and we can fix the volatile stuff), would be dead code. Roman From kim.barrett at oracle.com Wed Aug 16 05:02:46 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Aug 2017 01:02:46 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <8beaf90e-4461-e129-4b7f-ce79e7152c38@redhat.com> References: <4f43bdf1-5cf3-e909-7d7d-176fa9f22903@redhat.com> <8beaf90e-4461-e129-4b7f-ce79e7152c38@redhat.com> Message-ID: <33547C0A-E920-4E0F-BAF5-1946E0EAEE70@oracle.com> > On Aug 15, 2017, at 10:22 AM, Roman Kennke wrote: > > Am 14.08.2017 um 11:56 schrieb Kim Barrett: >>> On Aug 14, 2017, at 10:28 AM, Roman Kennke wrote: >>> >>> I still don't understand why we want to allow for different types for >>> the new and expected values and the memory location (T, D and U). We >>> haven't allowed for this before, why are we doing it now? >> Different types are only permitted in the pointer value case, >> e.g. cmpxchg(T*, D* volatile*, U*). >> >> The compare_value type is permitted to differ from the destination's >> value type only in cv-qualifiers. Consider a member variable "var" of >> type int*. >> >> const int* old_value = var; >> ... compute new_value ... >> cmpxchg(new_value, &var, old_value); >> >> It is perfectly reasonable and appropriate to const-qualify >> old_value's type in that way. But that would require a source level >> cast if cmpxchg required an exact type match for *dest and >> compare_value. >> >> We permit the exchange_value type to be less cv-qualified than the >> *dest type. We also permit derived to base conversions. Both of >> those are natural and type-safe, and may eliminate the need for some >> source level casts. >> >>> We haven't allowed for this before, why are we doing it now? >> Because of the complete type-discarding done by cmpxchg_ptr, I suggest >> we have no clue what our current code might or might not be doing. >> > I don't see that anywhere. The only situations that I could find are a > few places where dest is cast to (volatile foo*), which makes me > question whether that dest field should be marked volatile in the first > place. I see no patterns as you described above involving any const > casts. And I am absolutely against introducing some machinery that is > not actually used. If it's not used, it's dead, and only increases debt > rather than decrease it. (Note: the situation would be different if it > were a public API. but it isn't) The API affects the surrounding using code. There being no uses of more cv-qualifed compare_value than the destination type shouldn't be surprising, since the present API doesn't allow *any* cv-qualifiers for the compare_value. But I suggest that's a bug in the present API, much like the bug that Atomic::load didn't const-qualify the source (which I fixed not so long ago). Hotspot code is missing a lot of const qualifiers. I ran into this one myself at some point, with exactly the use-case I described in earlier mail, and was quite annoyed that the API inhibited writing obviously correct and idiomatic code. For the exchange_value, I just encountered a case where the cv-qualifiers of that new value should be expected to differ from the destination. In the published webrev is a change to BitMap::init_pop_count_table() to use the new conditional_store_ptr instead of cmpxchg_ptr with a NULL compare_value. What I didn't notice at the time is that the type of _pop_count_table should be const BitMap::idx_t*, but was missing the const qualifier. I've fixed that, and because of the implicit conversion support, that just worked. If the new value type had to match that const qualified type, there would need to be a conversion of some kind added to the caller. The new value is a just constructed and explicitly filled in array, so the variable holding it clearly can't have that const qualifier in its type. An API that requires such an explicit conversion in the caller in a case like this is simply broken, in my opinion. From kim.barrett at oracle.com Wed Aug 16 06:03:02 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Aug 2017 02:03:02 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> Message-ID: <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> > On Aug 15, 2017, at 2:57 AM, David Holmes wrote: > > Hi Kim, > > All points in your response below noted - in particular the problem with enum definition locations for registration. > > Again many thanks for your perseverance on this and for making things more palatable for those of us not familiar with this style of programming. > > Here's the rest of the review - with some things already addressed, or flagged, by Coleen's review and your responses ("sizeof trick"!!). Many of my initial questions/comments have resolved themselves as I've gotten further through the review. :) Just a few queries and a couple of suggestions left. Thanks for looking at this, and for learning a lot about some parts of C++ in a very short time. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ This includes changes mentioned in reply to Coleen's review. It also contains changes discussed below in response to David's review. David suggested renaming IntegerTypes to PrimitiveTypes. That isn't entirely satisfying to me. This class is, to me, more about conversion than types per se. I'm presently leaning toward PrimitiveConversions, especially since, as discussed in a previous message, I think floats should remain. I haven't made any change to the name yet though. I'll probably leave the name change to the very end, before pushing, to ease incremental reviews, and to allow more time for bike shedding. I've changed over to using the union trick. This resulted in fewer cases to handle, so allowed further simplification of IntegerTypes. David suggested renaming conditional_store_ptr to replace_if_null. I've made that change. I've simplified the conversion of the compare_value in the pointer case of cmpxchg. I realized there's no need for any metaprogramming-based type manipulation; just a straight const_cast to D* does what's needed. I changed the type of BitMap::_pop_count_table to add a const qualifier. It should have always been there, and provides an example of why requiring exact type matching in the pointer case is harmful. Additional comments inline below. > src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp > > The actual body has: > > 435 long old_value; > > rather than "T old_value". I presume the AIX compiler can't handle using T with inline asm? There wasn't any good reason not to do that, that I know of, so I've made that change. Similarly for linux_ppc. I made a similar change to linux_s390 for the 8-byte case, but not 4-byte, where the existing code is declaring old to be unsigned long rather than the expected unsigned int. I don't know if that's a bug or something about the s390. Looking at the s390 code, I think there might be missing compile barriers that allow (non-volatile) memory accesses to be reordered across the operation. I'll bring those issues up directly with the SAP folks. > src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp > > We must revisit why we are using the stub generator on Windows! Not my problem :) > src/share/vm/gc/shared/workgroup.cpp > > if (old == 0) { > ! old = Atomic::cmpxchg(1u, &_tasks[t], 0u); > } > assert(_tasks[t] == 1, "What else?"); > > I don't understand why we can compare against 0 and 1, yet must pass 0u and 1u to our extremely clever template function. :( The usual conversions are applied to the comparison. Comparing a signed with an unsigned will generate a warning with some options for some compilers, but not when the value that needs to be converted is a constant (or maybe only a literal) known to be safe to convert. In the cmpxchg, we're requiring an exact match, and no conversions are applied. Remember that the deduced template parameters take on the actual (and exact) static types of the arguments. We could manually apply conversions in the template implementation, possibly attempting to only apply safe conversions. That would require removing the "all same types" requirement for the integral/enum case, and some effort for a case that can be handled by just using the correct types. > src/share/vm/oops/oop.inline.hpp > > 400 volatile HeapWord *dest, > 411 narrowOop old = Atomic::cmpxchg(val, (narrowOop*)dest, cmp); > 418 return Atomic::cmpxchg(exchange_value, (oop*)dest, compare_value); > > do the casts here indicate we should have some conversion function from HeapWord to oop and narrowoop? Maybe, but not my problem :) I was expecting there to be lots of narrowOop* casts, but there are only about 25. Though there are probably a lot more where the type is a template parameter, so not as obvious. > src/share/vm/runtime/atomic.hpp > > So the overall chain of things is: > > cmpxchg -> CmpxchgImpl -> PlatformCmpxchg -> inline assembly; or > |-> cmpxchg_using_stub -> external .s/.il definition. > > I'm unclear why we need CmpxchgImpl - or more accurately I'm unclear why all the type "dispatching" that CmpxchgImpl does can't be done by the top-level Atomic::cmpxchg template? We can't have just one cmpxchg template that handles the various cases. The case handling code may not even compile without the correct static context. For example, we can't have if (IntegerTypes::Translate::value) { return IntegerTypes::Translate::recover(...); } because if T doesn't have a translator, there is no recover function to reference. So we need separate compilation contexts for the different cases. [C++17 adds "if constexpr (...)", where only the selected clause is subjected to some compiler stages. Using that, the above example *would* work. I don't think this change should wait for that...] One way to get those separate contexts is through the use of a helper class like CmpxchgImpl, and using SFINAE to guide the selection. Another is to use overloading and use SFINAE to prune the applicable set. Both generally work, and I think it's mostly a matter of style and personal preference which to use. Erik seems to prefer overloading, and avoiding the extra helper class. I think the syntax for function SFINAE is pretty horrible, and usually prefer the extra helper class, though that shifted when I was using C++11. In C++11 one can write a (clever :) macro we'll call ENABLE_IF, such that one can write (for example) template::value)> inline T Atomic::cmpxchg(T exchange_value, T volatile* dest, T compare_value, cmpxchg_memory_order order) { return IntegerTypes::recover(...); } instead of a C++98 form like template inline typename EnableIf::value, T>::type Atomic::cmpxchg(T exchange_value, T volatile* dest, T compare_value, cmpxchg_memory_order order) { return IntegerTypes::recover(...); } > So cmpxchg_using_stub exists to deal with any needed conversions (type or order) between the PlatformCmpxchg API and the actual platform-specific functions (if they exist) - ok. Only nit I have here is the use of "stub" because when I see that I think of the stubGenerator, and this has nothing to do with that. How about cmpxchg_adapter? (And perhaps StubFn should be something else ... I don't see it as a stub, as its the real function to do the work ... could just be Fn? I first recognized something like this would be useful when looking at the windows port, which *is* using the stub generator, and got "stub" stuck in my head. cmpxchg_adapter seems like a fine name for this, except for spelling confusion over "adapt[eo]r". I personally tend to use the (apparently much less frequent) "adaptor", which is also the spelling used by the C++ standard and Boost. I read somewhere that Java usage prefers "adapter". In the description comment I call it a "helper function". I agree "stub" has wrong implications, so going with cmpxchg_using_helper. > inline T Atomic::PlatformCmpxchg<1>::operator() > > Coleen flagged that use of operator() is somewhat obscure, and I tend to agree. At the moment calling it cmpxchg might seem redundant, but what if the naming scheme were eg: > > Atomic::Platform<1>:cmpxchg > Atomic::Platform<1>:add > etc? Then, for example, we can't implement cmpxchg for the 1-byte case by deriving Atomic::Platform<1> from CmpxchgByteUsingInt. I think there will be opportunities for similar utility classes for other operations; I already have one in mind for (part of) Atomic::add, which would apply to all sizes, not just the 1-byte case. Platform< ?? >::cmpxchg is also a bit harder to search for than PlatformCmpxchg. I think function objects are the normal and natural way to write this sort of thing. I realize its not common style for Hotspot. But then, neither is metaprogramming in general. > 182 template > 183 static T cmpxchg_using_stub(StubFn stub_fn, > 184 T exchange_value, > 185 T volatile* dest, > 186 T compare_value); > > Templates 101 question: why when we instantiate this template do we only need to pass StubType explicitly eg: > > cmpxchg_using_stub(_Atomic_cmpxchg_long, exchange_value, dest, compare_value); > > are the other types inferred from the function arguments? Yes. Those unsupplied template parameters are "deduced" (to use the proper jargon). Note that type parameter deduction is only provided for function templates, not class templates. (Class templates get deduction in C++17.) > IsPointerConvertible ... yep now I get it. I got the sizeof trick quickly but was missing the actual conversion check - now realizing that test() will select test(To*) if there is a conversion, and test(...) if not. :) By George, he's got it! > That's it. :) > > Thanks, > David Thanks for your perseverance. From gerard.ziemski at oracle.com Wed Aug 16 17:48:07 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 16 Aug 2017 12:48:07 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler Message-ID: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> hi all, (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. The changes are XL, but straightforward. If anyone knows of any other remnants that should still be removed, please let me know. issue: https://bugs.openjdk.java.net/browse/JDK-8173715 webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot passes the following tests: JPRT RBT test_hotspot/test/serviceability/jvmti RBT test_hotspot/test/gc RBT test_hotspot/test/compiler RBT test_hotspot/test/runtime Thank you. From coleen.phillimore at oracle.com Wed Aug 16 18:16:08 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Aug 2017 14:16:08 -0400 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> Message-ID: Gerard, The change looks great! thanks, Coleen On 8/16/17 1:48 PM, Gerard Ziemski wrote: > hi all, > > (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) > > The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. > > The changes are XL, but straightforward. > > If anyone knows of any other remnants that should still be removed, please let me know. > > issue: https://bugs.openjdk.java.net/browse/JDK-8173715 > webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot > > passes the following tests: > > JPRT > RBT test_hotspot/test/serviceability/jvmti > RBT test_hotspot/test/gc > RBT test_hotspot/test/compiler > RBT test_hotspot/test/runtime > > Thank you. > From jesper.wilhelmsson at oracle.com Wed Aug 16 18:53:56 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 16 Aug 2017 20:53:56 +0200 Subject: Hotspot repo jdk10/hs is closed for all pushes Message-ID: <91834B67-5932-4F70-875B-9E48BEDA9355@oracle.com> Hi all, In order to allow for the last two (known) integration blockers to be fixed we are closing jdk10/hs for all pushes effective immediately. You can track the status of the integration blockers using this JBS filter: https://bugs.openjdk.java.net/issues/?filter=27377 Thank you for your cooperation! /Jesper From david.holmes at oracle.com Wed Aug 16 20:33:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Aug 2017 06:33:08 +1000 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> Message-ID: <9151ae34-70c1-d0ec-2a03-ebd91bc10f5e@oracle.com> Hi Gerard, Not a review yet. On 17/08/2017 3:48 AM, Gerard Ziemski wrote: > hi all, > > (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) The jdk part should be reviewed on core-libs-dev. The build change should be reviewed on build-dev. And you have more work to do there to remove fprof from the set of known jvm features - see: common/autoconf/hotspot.m4 Thanks, David > The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. > > The changes are XL, but straightforward. > > If anyone knows of any other remnants that should still be removed, please let me know. > > issue: https://bugs.openjdk.java.net/browse/JDK-8173715 > webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot > > passes the following tests: > > JPRT > RBT test_hotspot/test/serviceability/jvmti > RBT test_hotspot/test/gc > RBT test_hotspot/test/compiler > RBT test_hotspot/test/runtime > > Thank you. > From kim.barrett at oracle.com Wed Aug 16 20:38:01 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Aug 2017 16:38:01 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> Message-ID: <67AA6B82-EF93-4B20-BBF0-A96CE201E3EB@oracle.com> > On Aug 16, 2017, at 2:03 AM, Kim Barrett wrote: > >> On Aug 15, 2017, at 2:57 AM, David Holmes wrote:src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp >> >> The actual body has: >> >> 435 long old_value; >> >> rather than "T old_value". I presume the AIX compiler can't handle using T with inline asm? > > There wasn't any good reason not to do that, that I know of, so I've > made that change. Similarly for linux_ppc. I made a similar change > to linux_s390 for the 8-byte case, but not 4-byte, where the existing > code is declaring old to be unsigned long rather than the expected > unsigned int. I don't know if that's a bug or something about the > s390. Looking at the s390 code, I think there might be missing > compile barriers that allow (non-volatile) memory accesses to be > reordered across the operation. I'll bring those issues up directly > with the SAP folks. Martin Doerr has confirmed the s390 4-byte cmpxchg?s use of unsigned long rather than unsigned int is a (harmless) mistake, so I?ve made the same changes there as elsewhere now. (No new webrev for this change, the diff is below.) SAP will address the compile barrier issue. ========== diff -r ece36cba61c1 -r f203533cabc6 src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp --- a/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Tue Aug 15 19:50:03 2017 -0400 +++ b/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Wed Aug 16 13:17:52 2017 -0400 @@ -489,7 +489,7 @@ T cmp_val, cmpxchg_memory_order unused) const { STATIC_ASSERT(4 == sizeof(T)); - unsigned long old; + T old; __asm__ __volatile__ ( " CS %[old],%[upd],%[mem] \n\t" // Try to xchg upd with mem. @@ -503,7 +503,7 @@ : "cc" ); - return IntegerTypes::cast((uint32_t)old); + return old; } template<> ========== From david.holmes at oracle.com Wed Aug 16 21:13:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Aug 2017 07:13:37 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <67AA6B82-EF93-4B20-BBF0-A96CE201E3EB@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <67AA6B82-EF93-4B20-BBF0-A96CE201E3EB@oracle.com> Message-ID: <480056f8-8fb1-ee20-a2fe-108b60b70d9a@oracle.com> On 17/08/2017 6:38 AM, Kim Barrett wrote: >> On Aug 16, 2017, at 2:03 AM, Kim Barrett wrote: >> >>> On Aug 15, 2017, at 2:57 AM, David Holmes wrote:src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp >>> >>> The actual body has: >>> >>> 435 long old_value; >>> >>> rather than "T old_value". I presume the AIX compiler can't handle using T with inline asm? >> >> There wasn't any good reason not to do that, that I know of, so I've >> made that change. Similarly for linux_ppc. I made a similar change >> to linux_s390 for the 8-byte case, but not 4-byte, where the existing >> code is declaring old to be unsigned long rather than the expected >> unsigned int. I don't know if that's a bug or something about the >> s390. Looking at the s390 code, I think there might be missing >> compile barriers that allow (non-volatile) memory accesses to be >> reordered across the operation. I'll bring those issues up directly >> with the SAP folks. > > Martin Doerr has confirmed the s390 4-byte cmpxchg?s use of unsigned long > rather than unsigned int is a (harmless) mistake, so I?ve made the same changes > there as elsewhere now. (No new webrev for this change, the diff is below.) SAP > will address the compile barrier issue. Looks good. Glad we got that tidied up. :) Thanks, David > ========== > diff -r ece36cba61c1 -r f203533cabc6 src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp > --- a/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Tue Aug 15 19:50:03 2017 -0400 > +++ b/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Wed Aug 16 13:17:52 2017 -0400 > @@ -489,7 +489,7 @@ > T cmp_val, > cmpxchg_memory_order unused) const { > STATIC_ASSERT(4 == sizeof(T)); > - unsigned long old; > + T old; > > __asm__ __volatile__ ( > " CS %[old],%[upd],%[mem] \n\t" // Try to xchg upd with mem. > @@ -503,7 +503,7 @@ > : "cc" > ); > > - return IntegerTypes::cast((uint32_t)old); > + return old; > } > > template<> > ========== > From david.holmes at oracle.com Wed Aug 16 23:22:25 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Aug 2017 09:22:25 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> Message-ID: <2981717d-e281-4c15-90ef-80acd791f913@oracle.com> Hi Kim, On 16/08/2017 4:03 PM, Kim Barrett wrote: >> On Aug 15, 2017, at 2:57 AM, David Holmes wrote: >> >> Hi Kim, >> >> All points in your response below noted - in particular the problem with enum definition locations for registration. >> >> Again many thanks for your perseverance on this and for making things more palatable for those of us not familiar with this style of programming. >> >> Here's the rest of the review - with some things already addressed, or flagged, by Coleen's review and your responses ("sizeof trick"!!). Many of my initial questions/comments have resolved themselves as I've gotten further through the review. :) Just a few queries and a couple of suggestions left. > > Thanks for looking at this, and for learning a lot about some parts > of C++ in a very short time. I think I still have only learnt a little :) > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ Overall this seems okay to me and I have no further major comments or discussion comments. Thanks, David ----- > This includes changes mentioned in reply to Coleen's review. It also > contains changes discussed below in response to David's review. > > David suggested renaming IntegerTypes to PrimitiveTypes. That isn't > entirely satisfying to me. This class is, to me, more about > conversion than types per se. I'm presently leaning toward > PrimitiveConversions, especially since, as discussed in a previous > message, I think floats should remain. I haven't made any change to > the name yet though. I'll probably leave the name change to the very > end, before pushing, to ease incremental reviews, and to allow more > time for bike shedding. > > I've changed over to using the union trick. This resulted in fewer > cases to handle, so allowed further simplification of IntegerTypes. > > David suggested renaming conditional_store_ptr to replace_if_null. > I've made that change. > > I've simplified the conversion of the compare_value in the pointer > case of cmpxchg. I realized there's no need for any > metaprogramming-based type manipulation; just a straight const_cast to > D* does what's needed. > > I changed the type of BitMap::_pop_count_table to add a const > qualifier. It should have always been there, and provides an example > of why requiring exact type matching in the pointer case is harmful. > > Additional comments inline below. > >> src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp >> >> The actual body has: >> >> 435 long old_value; >> >> rather than "T old_value". I presume the AIX compiler can't handle using T with inline asm? > > There wasn't any good reason not to do that, that I know of, so I've > made that change. Similarly for linux_ppc. I made a similar change > to linux_s390 for the 8-byte case, but not 4-byte, where the existing > code is declaring old to be unsigned long rather than the expected > unsigned int. I don't know if that's a bug or something about the > s390. Looking at the s390 code, I think there might be missing > compile barriers that allow (non-volatile) memory accesses to be > reordered across the operation. I'll bring those issues up directly > with the SAP folks. > >> src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp >> >> We must revisit why we are using the stub generator on Windows! > > Not my problem :) > >> src/share/vm/gc/shared/workgroup.cpp >> >> if (old == 0) { >> ! old = Atomic::cmpxchg(1u, &_tasks[t], 0u); >> } >> assert(_tasks[t] == 1, "What else?"); >> >> I don't understand why we can compare against 0 and 1, yet must pass 0u and 1u to our extremely clever template function. :( > > The usual conversions are applied to the comparison. Comparing a > signed with an unsigned will generate a warning with some options for > some compilers, but not when the value that needs to be converted is a > constant (or maybe only a literal) known to be safe to convert. In > the cmpxchg, we're requiring an exact match, and no conversions are > applied. Remember that the deduced template parameters take on the > actual (and exact) static types of the arguments. We could manually > apply conversions in the template implementation, possibly attempting > to only apply safe conversions. That would require removing the "all > same types" requirement for the integral/enum case, and some effort > for a case that can be handled by just using the correct types. > >> src/share/vm/oops/oop.inline.hpp >> >> 400 volatile HeapWord *dest, >> 411 narrowOop old = Atomic::cmpxchg(val, (narrowOop*)dest, cmp); >> 418 return Atomic::cmpxchg(exchange_value, (oop*)dest, compare_value); >> >> do the casts here indicate we should have some conversion function from HeapWord to oop and narrowoop? > > Maybe, but not my problem :) I was expecting there to be lots of > narrowOop* casts, but there are only about 25. Though there are > probably a lot more where the type is a template parameter, so not as > obvious. > >> src/share/vm/runtime/atomic.hpp >> >> So the overall chain of things is: >> >> cmpxchg -> CmpxchgImpl -> PlatformCmpxchg -> inline assembly; or >> |-> cmpxchg_using_stub -> external .s/.il definition. >> >> I'm unclear why we need CmpxchgImpl - or more accurately I'm unclear why all the type "dispatching" that CmpxchgImpl does can't be done by the top-level Atomic::cmpxchg template? > > We can't have just one cmpxchg template that handles the various > cases. The case handling code may not even compile without the > correct static context. For example, we can't have > > if (IntegerTypes::Translate::value) { > return IntegerTypes::Translate::recover(...); > } > > because if T doesn't have a translator, there is no recover function > to reference. So we need separate compilation contexts for the > different cases. > > [C++17 adds "if constexpr (...)", where only the selected clause is > subjected to some compiler stages. Using that, the above example > *would* work. I don't think this change should wait for that...] > > One way to get those separate contexts is through the use of a helper > class like CmpxchgImpl, and using SFINAE to guide the selection. > Another is to use overloading and use SFINAE to prune the applicable > set. Both generally work, and I think it's mostly a matter of style > and personal preference which to use. Erik seems to prefer > overloading, and avoiding the extra helper class. I think the syntax > for function SFINAE is pretty horrible, and usually prefer the extra > helper class, though that shifted when I was using C++11. In C++11 > one can write a (clever :) macro we'll call ENABLE_IF, such that one > can write (for example) > > template::value)> > inline T Atomic::cmpxchg(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) { > return IntegerTypes::recover(...); > } > > instead of a C++98 form like > > template > inline typename EnableIf::value, T>::type > Atomic::cmpxchg(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) { > return IntegerTypes::recover(...); > } > >> So cmpxchg_using_stub exists to deal with any needed conversions (type or order) between the PlatformCmpxchg API and the actual platform-specific functions (if they exist) - ok. Only nit I have here is the use of "stub" because when I see that I think of the stubGenerator, and this has nothing to do with that. How about cmpxchg_adapter? (And perhaps StubFn should be something else ... I don't see it as a stub, as its the real function to do the work ... could just be Fn? > > I first recognized something like this would be useful when looking at > the windows port, which *is* using the stub generator, and got "stub" > stuck in my head. cmpxchg_adapter seems like a fine name for this, > except for spelling confusion over "adapt[eo]r". I personally tend to > use the (apparently much less frequent) "adaptor", which is also the > spelling used by the C++ standard and Boost. I read somewhere that > Java usage prefers "adapter". > > In the description comment I call it a "helper function". I agree > "stub" has wrong implications, so going with cmpxchg_using_helper. > > >> inline T Atomic::PlatformCmpxchg<1>::operator() >> >> Coleen flagged that use of operator() is somewhat obscure, and I tend to agree. At the moment calling it cmpxchg might seem redundant, but what if the naming scheme were eg: >> >> Atomic::Platform<1>:cmpxchg >> Atomic::Platform<1>:add >> etc? > > Then, for example, we can't implement cmpxchg for the 1-byte case by > deriving Atomic::Platform<1> from CmpxchgByteUsingInt. I think there > will be opportunities for similar utility classes for other > operations; I already have one in mind for (part of) Atomic::add, > which would apply to all sizes, not just the 1-byte case. > > Platform< ?? >::cmpxchg is also a bit harder to search for than > PlatformCmpxchg. > > I think function objects are the normal and natural way to write this > sort of thing. I realize its not common style for Hotspot. But then, > neither is metaprogramming in general. > >> 182 template >> 183 static T cmpxchg_using_stub(StubFn stub_fn, >> 184 T exchange_value, >> 185 T volatile* dest, >> 186 T compare_value); >> >> Templates 101 question: why when we instantiate this template do we only need to pass StubType explicitly eg: >> >> cmpxchg_using_stub(_Atomic_cmpxchg_long, exchange_value, dest, compare_value); >> >> are the other types inferred from the function arguments? > > Yes. Those unsupplied template parameters are "deduced" (to use the > proper jargon). Note that type parameter deduction is only provided > for function templates, not class templates. (Class templates get > deduction in C++17.) > >> IsPointerConvertible ... yep now I get it. I got the sizeof trick quickly but was missing the actual conversion check - now realizing that test() will select test(To*) if there is a conversion, and test(...) if not. :) > > By George, he's got it! > >> That's it. :) >> >> Thanks, >> David > > Thanks for your perseverance. > > From glaubitz at physik.fu-berlin.de Wed Aug 16 23:28:56 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 17 Aug 2017 01:28:56 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> Message-ID: <350c7d3e-ef13-4d59-95c6-81e68a731040@physik.fu-berlin.de> On 08/16/2017 08:03 AM, Kim Barrett wrote: > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ Excuse my ignorance as a recently new contributor, but how can I check out this particular tree to test the changes on the various Debian platforms? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Thu Aug 17 00:21:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Aug 2017 10:21:53 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <350c7d3e-ef13-4d59-95c6-81e68a731040@physik.fu-berlin.de> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <350c7d3e-ef13-4d59-95c6-81e68a731040@physik.fu-berlin.de> Message-ID: On 17/08/2017 9:28 AM, John Paul Adrian Glaubitz wrote: > On 08/16/2017 08:03 AM, Kim Barrett wrote: >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ > > Excuse my ignorance as a recently new contributor, but how can I check > out this particular tree to test the changes on the various Debian > platforms? On the webrev there is a link to the patch e.g. http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/hotspot.patch which you can then hg import David > Adrian > From david.holmes at oracle.com Thu Aug 17 01:09:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Aug 2017 11:09:28 +1000 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> Message-ID: <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> Hi Gerard, On 17/08/2017 3:48 AM, Gerard Ziemski wrote: > hi all, > > (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) > > The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? > The changes are XL, but straightforward. > > If anyone knows of any other remnants that should still be removed, please let me know. > > issue: https://bugs.openjdk.java.net/browse/JDK-8173715 > webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: src/cpu/sparc/vm/macroAssembler_sparc.cpp - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) Are we still propagating Lmethod here? If so why? Ditto for other places in the file. In: src/share/vm/runtime/thread.cpp - // eventually timeout, but that takes time. Making this wait a - // suspend-equivalent condition solves that timeout problem. - // Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, Mutex::_as_suspend_equivalent_flag); So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). --- I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: -// within hotspot. Now there is a single use-case for this: -// - calling get_thread_pc() on the VMThread by the flat-profiler task -// that runs in the watcher thread. +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: +// - Forte Analyzer: AsyncGetCallTrace() +// - StackBanging: get_frame_at_stack_banging_point() I don't see any use of low-level suspend/resume with the two cases you added ?? --- src/os_cpu/linux_s390/vm/thread_linux_s390.hpp /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. That's an incorrect copyright update - should be "2016, 2017," --- src/os/solaris/vm/osThread_solaris.hpp // *************************************************************** - // interrupt support. interrupts (using signals) are used to get - // the thread context (get_thread_pc), to set the thread context - // (set_thread_pc), and to implement java.lang.Thread.interrupt. + // interrupt support. interrupts (using signals) are used to + // implement java.lang.Thread.interrupt. // *************************************************************** That entire comment block can be deleted. We haven't used signals for j.l.T.interrupt for years. --- Thanks, David > passes the following tests: > > JPRT > RBT test_hotspot/test/serviceability/jvmti > RBT test_hotspot/test/gc > RBT test_hotspot/test/compiler > RBT test_hotspot/test/runtime > > Thank you. > From per.liden at oracle.com Thu Aug 17 06:06:47 2017 From: per.liden at oracle.com (Per Liden) Date: Thu, 17 Aug 2017 08:06:47 +0200 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> Message-ID: <4ae10c07-d166-e699-6514-d68c7ec03c87@oracle.com> Hi Gerard, On 2017-08-16 19:48, Gerard Ziemski wrote: > hi all, > > (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) > > The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. > > The changes are XL, but straightforward. > > If anyone knows of any other remnants that should still be removed, please let me know. > > issue: https://bugs.openjdk.java.net/browse/JDK-8173715 The changes to the GC parts look good! cheers, Per > webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot > > passes the following tests: > > JPRT > RBT test_hotspot/test/serviceability/jvmti > RBT test_hotspot/test/gc > RBT test_hotspot/test/compiler > RBT test_hotspot/test/runtime > > Thank you. > From gunter.haug at sap.com Thu Aug 17 12:24:59 2017 From: gunter.haug at sap.com (Haug, Gunter) Date: Thu, 17 Aug 2017 12:24:59 +0000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly Message-ID: Hi, can I please have reviews and a sponsor fort the following small bug fix: http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ https://bugs.openjdk.java.net/browse/JDK-8186286 At least on Mac OS 10.12 we have observed stack sizes of the primary thread not aligned to pages boundries. This can be provoked by e.g. setrlimit() (ulimit -s xxxx in the shell).This voids the computation of the addresses of the guard pages. Fix: Apparently Mac OS actually rounds upwards to next multiple of page size however, it is conservative to round downwards here to be on the safe side. Thanks and best regards, Gunter From glaubitz at physik.fu-berlin.de Thu Aug 17 12:45:44 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 17 Aug 2017 14:45:44 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> Message-ID: <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> On 08/16/2017 08:03 AM, Kim Barrett wrote: > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ This fails to build on linux-sparc: /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:130:10: error: template-id ?operator()<>? for ?T Atomic::PlatformCmpxchg<4>::operator()(T, volatile T*, T, cmpxchg_memory_order)? does not match any template declaration inline T Atomic::PlatformCmpxchg<4>::operator()(T exchange_value, ^~~~~~ Full log in [1]. Going to test linux-zero next. Adrian > [1] https://people.debian.org/~glaubitz/linux-sparc-build.log -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From shade at redhat.com Thu Aug 17 12:54:21 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Aug 2017 15:54:21 +0300 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: <449d0e3a-94b3-8bbd-11a3-ff52662b2dbe@redhat.com> On 08/17/2017 03:24 PM, Haug, Gunter wrote: > Hi, > > can I please have reviews and a sponsor fort the following small bug fix: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ This looks sane to me. There are useful macros in align.hpp, use them? align_down and is_aligned seem useful here. Thanks, -Aleksey From thomas.stuefe at gmail.com Thu Aug 17 13:06:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Aug 2017 15:06:03 +0200 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: Hi Gunter, On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter wrote: > Hi, > > can I please have reviews and a sponsor fort the following small bug fix: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ > https://bugs.openjdk.java.net/browse/JDK-8186286 > > At least on Mac OS 10.12 we have observed stack sizes of the primary > thread not aligned to pages boundries. This can be provoked by e.g. > setrlimit() (ulimit -s xxxx in the shell).This voids the computation of the > addresses of the guard pages. > > Fix: > Apparently Mac OS actually rounds upwards to next multiple of page size > however, it is conservative to round downwards here to be on the safe side. > > Thanks and best regards, > Gunter > Thanks for the patch! Very minor nits: what Alexey wrote (we also have "is_aligned"). Plus, any reason not to use os::vm_page_size()? Initialization dependencies? Kind Regards, Thomas From glaubitz at physik.fu-berlin.de Thu Aug 17 13:44:14 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 17 Aug 2017 15:44:14 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: On 08/17/2017 02:45 PM, John Paul Adrian Glaubitz wrote: > On 08/16/2017 08:03 AM, Kim Barrett wrote: >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ > > This fails to build on linux-sparc: Same problem with linux-zero: /tmp/glaubitz/hs/hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.hpp:270:10: error: template-id ?operator()<>? for ?T Atomic::PlatformCmpxchg<4ul>::operator()(T, volatile T*, T, cmpxchg_memory_order)? does not match any template declaration inline T Atomic::PlatformCmpxchg<4>::operator()(T exchange_value, Full log in [1]. Adrian > [1] https://people.debian.org/~glaubitz/linux-zero-build.log -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From gerard.ziemski at oracle.com Thu Aug 17 13:55:44 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 08:55:44 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <9151ae34-70c1-d0ec-2a03-ebd91bc10f5e@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <9151ae34-70c1-d0ec-2a03-ebd91bc10f5e@oracle.com> Message-ID: <99ABD5FB-A07C-4746-B240-CB8FE3254084@oracle.com> Thank you for spotting a remnant in common/autoconf/hotspot.m4 I will remove ?fprof? from the file and spin up new webrev, making sure the reviews are posted on correct mailing lists. cheers > On Aug 16, 2017, at 3:33 PM, David Holmes wrote: > > Hi Gerard, > > Not a review yet. > > On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >> hi all, >> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) > > The jdk part should be reviewed on core-libs-dev. > > The build change should be reviewed on build-dev. And you have more work to do there to remove fprof from the set of known jvm features - see: > > common/autoconf/hotspot.m4 > > Thanks, > David From gerard.ziemski at oracle.com Thu Aug 17 13:56:25 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 08:56:25 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> Message-ID: <18F26F03-ED3F-4AA1-8907-1DDD0A9BDEB3@oracle.com> Thank you Coleen. cheers > On Aug 16, 2017, at 1:16 PM, coleen.phillimore at oracle.com wrote: > > Gerard, The change looks great! > thanks, > Coleen > > > On 8/16/17 1:48 PM, Gerard Ziemski wrote: >> hi all, >> >> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >> >> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >> >> The changes are XL, but straightforward. >> >> If anyone knows of any other remnants that should still be removed, please let me know. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot >> >> passes the following tests: >> >> JPRT >> RBT test_hotspot/test/serviceability/jvmti >> RBT test_hotspot/test/gc >> RBT test_hotspot/test/compiler >> RBT test_hotspot/test/runtime >> >> Thank you. >> > From gerard.ziemski at oracle.com Thu Aug 17 13:56:56 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 08:56:56 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <4ae10c07-d166-e699-6514-d68c7ec03c87@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <4ae10c07-d166-e699-6514-d68c7ec03c87@oracle.com> Message-ID: <6AD50AE2-4BB4-493C-BCC5-572AF5ECDEF4@oracle.com> Thank you Per! cheers > On Aug 17, 2017, at 1:06 AM, Per Liden wrote: > > On 2017-08-16 19:48, Gerard Ziemski wrote: >> hi all, >> >> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >> >> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >> >> The changes are XL, but straightforward. >> >> If anyone knows of any other remnants that should still be removed, please let me know. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 > > The changes to the GC parts look good! From gerard.ziemski at oracle.com Thu Aug 17 14:34:46 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 09:34:46 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> Message-ID: <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> hi David, Thank you for the review! > On Aug 16, 2017, at 8:09 PM, David Holmes wrote: > > Hi Gerard, > > On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >> hi all, >> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. > > That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? So normally for -XX flags it?s deprecated -> obsolete -> remove, correct? I?m not sure about -X flag either, but it was explained to me that making -Xprof flag work in jdk10 would take considerable amount of effort, so instead of supporting already deprecated flag, we simply remove it - it was officially deprecated in jdk9 using JDK-8176098. >> The changes are XL, but straightforward. >> If anyone knows of any other remnants that should still be removed, please let me know. >> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot > > There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: > > src/cpu/sparc/vm/macroAssembler_sparc.cpp > > - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) > + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) > > Are we still propagating Lmethod here? If so why? Ditto for other places in the file. I couldn?t figure out whether we still needed to propagate the Lmethod, and assumed that it was safe to leave it in - the extra code is saving a register, which seems harmless to me and there are other places in the file where we do it. > In: src/share/vm/runtime/thread.cpp > > - // eventually timeout, but that takes time. Making this wait a > - // suspend-equivalent condition solves that timeout problem. > - // > Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, > Mutex::_as_suspend_equivalent_flag); > > So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). I wasn?t completely sure about this, and was going back and forth on this, but I figured it was safer to leave it in, since there are code paths that still use suspend/resume mechanism, i.e. the deprecated java.lang.Thread.suspend()/resume() APIs. Are we sure it?s OK to remove these locks? > > --- > > I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: > > -// within hotspot. Now there is a single use-case for this: > -// - calling get_thread_pc() on the VMThread by the flat-profiler task > -// that runs in the watcher thread. > +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: > +// - Forte Analyzer: AsyncGetCallTrace() > +// - StackBanging: get_frame_at_stack_banging_point() > > I don't see any use of low-level suspend/resume with the two cases you added ?? Those cases depend on ?ucontext? being set up using the resume_clear_context()/suspend_save_context() APIs, which are part of the resume/suspend mechanism - I will try to re-do the comment. > > --- > > src/os_cpu/linux_s390/vm/thread_linux_s390.hpp > > /* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. > > That's an incorrect copyright update - should be "2016, 2017,? Thank you for catching this. > > --- > > src/os/solaris/vm/osThread_solaris.hpp > > // *************************************************************** > - // interrupt support. interrupts (using signals) are used to get > - // the thread context (get_thread_pc), to set the thread context > - // (set_thread_pc), and to implement java.lang.Thread.interrupt. > + // interrupt support. interrupts (using signals) are used to > + // implement java.lang.Thread.interrupt. > // *************************************************************** > > That entire comment block can be deleted. We haven't used signals for j.l.T.interrupt for years. Thank you for catching this. cheers From gunter.haug at sap.com Thu Aug 17 15:01:14 2017 From: gunter.haug at sap.com (Haug, Gunter) Date: Thu, 17 Aug 2017 15:01:14 +0000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: Thanks for the review, Aleksey and Thomas You?re right, it is much nicer to use the macros. I?ve updated the change accordingly: http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 @Thomas: os::vm_page_size() is not used in current_stack_region(), I think because of initialization dependencies. Best regards, Gunter From: Thomas St?fe Date: Thursday, 17. August 2017 at 15:06 To: "Haug, Gunter" Cc: "hotspot-dev at openjdk.java.net" Subject: Re: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly Hi Gunter, On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter > wrote: Hi, can I please have reviews and a sponsor fort the following small bug fix: http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ https://bugs.openjdk.java.net/browse/JDK-8186286 At least on Mac OS 10.12 we have observed stack sizes of the primary thread not aligned to pages boundries. This can be provoked by e.g. setrlimit() (ulimit -s xxxx in the shell).This voids the computation of the addresses of the guard pages. Fix: Apparently Mac OS actually rounds upwards to next multiple of page size however, it is conservative to round downwards here to be on the safe side. Thanks and best regards, Gunter Thanks for the patch! Very minor nits: what Alexey wrote (we also have "is_aligned"). Plus, any reason not to use os::vm_page_size()? Initialization dependencies? Kind Regards, Thomas From glaubitz at physik.fu-berlin.de Thu Aug 17 15:04:23 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 17 Aug 2017 17:04:23 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: <05a019c0-2f7e-90aa-8ecf-1988a192ef65@physik.fu-berlin.de> On 08/17/2017 03:44 PM, John Paul Adrian Glaubitz wrote: >> This fails to build on linux-sparc: > Same problem with linux-zero: I also tested linux-x86_64 and linux-ppc64el. Both build fine. Will also test the remaining targets later. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From gerard.ziemski at oracle.com Thu Aug 17 15:26:30 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 10:26:30 -0500 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <05a019c0-2f7e-90aa-8ecf-1988a192ef65@physik.fu-berlin.de> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> <05a019c0-2f7e-90aa-8ecf-1988a192ef65@physik.fu-berlin.de> Message-ID: hi Kim, I got this error building on Mac OS X: /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:275:10: error: implicit instantiation of undefined template 'Atomic::CmpxchgImpl' return CmpxchgImpl()(exchange_value, dest, compare_value, order); ^ /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:80:34: note: in instantiation of function template specialization 'Atomic::cmpxchg' requested here const jbyte result = Atomic::cmpxchg(current ^ flag, dest, current); ^ /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:164:10: note: template is declared here struct CmpxchgImpl; ^ 1 error generated. lib/CompileJvm.gmk:208: recipe for target '/Volumes/Work/bugs/0000000/jdk10/build/macosx-x64/hotspot/variant-server/libjvm/objs/jfrTaggedArtifacts.o' failed make[3]: *** [/Volumes/Work/bugs/0000000/jdk10/build/macosx-x64/hotspot/variant-server/libjvm/objs/jfrTaggedArtifacts.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed make[2]: *** [hotspot-server-libs] Error 2 ERROR: Build failed for target 'jdk' in configuration 'macosx-x64' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_jfrTaggedArtifacts.o: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:1: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/precompiled/precompiled.hpp:29: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/asm/assembler.hpp:28: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/asm/codeBuffer.hpp:28: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/code/oopRecorder.hpp:28: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/memory/universe.hpp:28: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/oops/array.hpp:29: In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/memory/allocation.inline.hpp:28: /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:275:10: error: implicit instantiation of undefined template 'Atomic::CmpxchgImpl' return CmpxchgImpl()(exchange_value, dest, compare_value, order); ^ /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:80:34: note: in instantiation of function template specialization 'Atomic::cmpxchg' requested here ... (rest of output omitted) From kim.barrett at oracle.com Thu Aug 17 17:07:39 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Aug 2017 13:07:39 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> <05a019c0-2f7e-90aa-8ecf-1988a192ef65@physik.fu-berlin.de> Message-ID: > On Aug 17, 2017, at 11:26 AM, Gerard Ziemski wrote: > > hi Kim, > > I got this error building on Mac OS X: > > /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:275:10: error: implicit instantiation of undefined template 'Atomic::CmpxchgImpl' > return CmpxchgImpl()(exchange_value, dest, compare_value, order); > ^ > /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:80:34: note: in instantiation of function template specialization 'Atomic::cmpxchg' requested here > const jbyte result = Atomic::cmpxchg(current ^ flag, dest, current); > ^ > /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:164:10: note: template is declared here > struct CmpxchgImpl; > ^ > 1 error generated. > lib/CompileJvm.gmk:208: recipe for target '/Volumes/Work/bugs/0000000/jdk10/build/macosx-x64/hotspot/variant-server/libjvm/objs/jfrTaggedArtifacts.o' failed > make[3]: *** [/Volumes/Work/bugs/0000000/jdk10/build/macosx-x64/hotspot/variant-server/libjvm/objs/jfrTaggedArtifacts.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed > make[2]: *** [hotspot-server-libs] Error 2 > > ERROR: Build failed for target 'jdk' in configuration 'macosx-x64' (exit code 2) > > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_libjvm_objs_jfrTaggedArtifacts.o: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:1: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/precompiled/precompiled.hpp:29: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/asm/assembler.hpp:28: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/asm/codeBuffer.hpp:28: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/code/oopRecorder.hpp:28: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/memory/universe.hpp:28: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/oops/array.hpp:29: > In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/memory/allocation.inline.hpp:28: > /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:275:10: error: implicit instantiation of undefined template 'Atomic::CmpxchgImpl' > return CmpxchgImpl()(exchange_value, dest, compare_value, order); > ^ > /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:80:34: note: in instantiation of function template specialization 'Atomic::cmpxchg' requested here > ... (rest of output omitted) Gerard - you are missing the closed part of the change. I don?t yet know what John?s problem is, though it?s not the missing closed change, obviously. From coleen.phillimore at oracle.com Thu Aug 17 17:21:09 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 13:21:09 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior Message-ID: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this pointer can be verified Also included is: 8164984: Improper use of is_oop in production code http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html I also moved is_oop() to the .cpp file, which reduces the size of fastdebug libjvm.so a little, since is_oop is only used for assert and verification. before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so Ran all platforms nightly tests (still in progress but no new failures). Sorry for the boring code review request. Thanks, Coleen From coleen.phillimore at oracle.com Thu Aug 17 17:30:39 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 13:30:39 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> Message-ID: On 8/16/17 2:03 AM, Kim Barrett wrote: >> On Aug 15, 2017, at 2:57 AM, David Holmes wrote: >> >> Hi Kim, >> >> All points in your response below noted - in particular the problem with enum definition locations for registration. >> >> Again many thanks for your perseverance on this and for making things more palatable for those of us not familiar with this style of programming. >> >> Here's the rest of the review - with some things already addressed, or flagged, by Coleen's review and your responses ("sizeof trick"!!). Many of my initial questions/comments have resolved themselves as I've gotten further through the review. :) Just a few queries and a couple of suggestions left. > Thanks for looking at this, and for learning a lot about some parts > of C++ in a very short time. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ I like the name change to cmpxchg_using_helper. http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp.udiff.html Why does this have rather than the constants like the other platforms? http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/src/share/vm/metaprogramming/integerTypes.hpp.udiff.html Okay, seeing this change, I have to prefer the cast using union. That's super simple and disturbing in it's power. Thank you for the commentary before it. The incremental change looks good. I've reviewed this enough to be glad when it's pushed, once all the platforms are verified. Thanks, Coleen > > This includes changes mentioned in reply to Coleen's review. It also > contains changes discussed below in response to David's review. > > David suggested renaming IntegerTypes to PrimitiveTypes. That isn't > entirely satisfying to me. This class is, to me, more about > conversion than types per se. I'm presently leaning toward > PrimitiveConversions, especially since, as discussed in a previous > message, I think floats should remain. I haven't made any change to > the name yet though. I'll probably leave the name change to the very > end, before pushing, to ease incremental reviews, and to allow more > time for bike shedding. > > I've changed over to using the union trick. This resulted in fewer > cases to handle, so allowed further simplification of IntegerTypes. > > David suggested renaming conditional_store_ptr to replace_if_null. > I've made that change. > > I've simplified the conversion of the compare_value in the pointer > case of cmpxchg. I realized there's no need for any > metaprogramming-based type manipulation; just a straight const_cast to > D* does what's needed. > > I changed the type of BitMap::_pop_count_table to add a const > qualifier. It should have always been there, and provides an example > of why requiring exact type matching in the pointer case is harmful. > > Additional comments inline below. > >> src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp >> >> The actual body has: >> >> 435 long old_value; >> >> rather than "T old_value". I presume the AIX compiler can't handle using T with inline asm? > There wasn't any good reason not to do that, that I know of, so I've > made that change. Similarly for linux_ppc. I made a similar change > to linux_s390 for the 8-byte case, but not 4-byte, where the existing > code is declaring old to be unsigned long rather than the expected > unsigned int. I don't know if that's a bug or something about the > s390. Looking at the s390 code, I think there might be missing > compile barriers that allow (non-volatile) memory accesses to be > reordered across the operation. I'll bring those issues up directly > with the SAP folks. > >> src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp >> >> We must revisit why we are using the stub generator on Windows! > Not my problem :) > >> src/share/vm/gc/shared/workgroup.cpp >> >> if (old == 0) { >> ! old = Atomic::cmpxchg(1u, &_tasks[t], 0u); >> } >> assert(_tasks[t] == 1, "What else?"); >> >> I don't understand why we can compare against 0 and 1, yet must pass 0u and 1u to our extremely clever template function. :( > The usual conversions are applied to the comparison. Comparing a > signed with an unsigned will generate a warning with some options for > some compilers, but not when the value that needs to be converted is a > constant (or maybe only a literal) known to be safe to convert. In > the cmpxchg, we're requiring an exact match, and no conversions are > applied. Remember that the deduced template parameters take on the > actual (and exact) static types of the arguments. We could manually > apply conversions in the template implementation, possibly attempting > to only apply safe conversions. That would require removing the "all > same types" requirement for the integral/enum case, and some effort > for a case that can be handled by just using the correct types. > >> src/share/vm/oops/oop.inline.hpp >> >> 400 volatile HeapWord *dest, >> 411 narrowOop old = Atomic::cmpxchg(val, (narrowOop*)dest, cmp); >> 418 return Atomic::cmpxchg(exchange_value, (oop*)dest, compare_value); >> >> do the casts here indicate we should have some conversion function from HeapWord to oop and narrowoop? > Maybe, but not my problem :) I was expecting there to be lots of > narrowOop* casts, but there are only about 25. Though there are > probably a lot more where the type is a template parameter, so not as > obvious. > >> src/share/vm/runtime/atomic.hpp >> >> So the overall chain of things is: >> >> cmpxchg -> CmpxchgImpl -> PlatformCmpxchg -> inline assembly; or >> |-> cmpxchg_using_stub -> external .s/.il definition. >> >> I'm unclear why we need CmpxchgImpl - or more accurately I'm unclear why all the type "dispatching" that CmpxchgImpl does can't be done by the top-level Atomic::cmpxchg template? > We can't have just one cmpxchg template that handles the various > cases. The case handling code may not even compile without the > correct static context. For example, we can't have > > if (IntegerTypes::Translate::value) { > return IntegerTypes::Translate::recover(...); > } > > because if T doesn't have a translator, there is no recover function > to reference. So we need separate compilation contexts for the > different cases. > > [C++17 adds "if constexpr (...)", where only the selected clause is > subjected to some compiler stages. Using that, the above example > *would* work. I don't think this change should wait for that...] > > One way to get those separate contexts is through the use of a helper > class like CmpxchgImpl, and using SFINAE to guide the selection. > Another is to use overloading and use SFINAE to prune the applicable > set. Both generally work, and I think it's mostly a matter of style > and personal preference which to use. Erik seems to prefer > overloading, and avoiding the extra helper class. I think the syntax > for function SFINAE is pretty horrible, and usually prefer the extra > helper class, though that shifted when I was using C++11. In C++11 > one can write a (clever :) macro we'll call ENABLE_IF, such that one > can write (for example) > > template::value)> > inline T Atomic::cmpxchg(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) { > return IntegerTypes::recover(...); > } > > instead of a C++98 form like > > template > inline typename EnableIf::value, T>::type > Atomic::cmpxchg(T exchange_value, > T volatile* dest, > T compare_value, > cmpxchg_memory_order order) { > return IntegerTypes::recover(...); > } > >> So cmpxchg_using_stub exists to deal with any needed conversions (type or order) between the PlatformCmpxchg API and the actual platform-specific functions (if they exist) - ok. Only nit I have here is the use of "stub" because when I see that I think of the stubGenerator, and this has nothing to do with that. How about cmpxchg_adapter? (And perhaps StubFn should be something else ... I don't see it as a stub, as its the real function to do the work ... could just be Fn? > I first recognized something like this would be useful when looking at > the windows port, which *is* using the stub generator, and got "stub" > stuck in my head. cmpxchg_adapter seems like a fine name for this, > except for spelling confusion over "adapt[eo]r". I personally tend to > use the (apparently much less frequent) "adaptor", which is also the > spelling used by the C++ standard and Boost. I read somewhere that > Java usage prefers "adapter". > > In the description comment I call it a "helper function". I agree > "stub" has wrong implications, so going with cmpxchg_using_helper. > > >> inline T Atomic::PlatformCmpxchg<1>::operator() >> >> Coleen flagged that use of operator() is somewhat obscure, and I tend to agree. At the moment calling it cmpxchg might seem redundant, but what if the naming scheme were eg: >> >> Atomic::Platform<1>:cmpxchg >> Atomic::Platform<1>:add >> etc? > Then, for example, we can't implement cmpxchg for the 1-byte case by > deriving Atomic::Platform<1> from CmpxchgByteUsingInt. I think there > will be opportunities for similar utility classes for other > operations; I already have one in mind for (part of) Atomic::add, > which would apply to all sizes, not just the 1-byte case. > > Platform< ?? >::cmpxchg is also a bit harder to search for than > PlatformCmpxchg. > > I think function objects are the normal and natural way to write this > sort of thing. I realize its not common style for Hotspot. But then, > neither is metaprogramming in general. > >> 182 template >> 183 static T cmpxchg_using_stub(StubFn stub_fn, >> 184 T exchange_value, >> 185 T volatile* dest, >> 186 T compare_value); >> >> Templates 101 question: why when we instantiate this template do we only need to pass StubType explicitly eg: >> >> cmpxchg_using_stub(_Atomic_cmpxchg_long, exchange_value, dest, compare_value); >> >> are the other types inferred from the function arguments? > Yes. Those unsupplied template parameters are "deduced" (to use the > proper jargon). Note that type parameter deduction is only provided > for function templates, not class templates. (Class templates get > deduction in C++17.) > >> IsPointerConvertible ... yep now I get it. I got the sizeof trick quickly but was missing the actual conversion check - now realizing that test() will select test(To*) if there is a conversion, and test(...) if not. :) > By George, he's got it! > >> That's it. :) >> >> Thanks, >> David > Thanks for your perseverance. > > From coleen.phillimore at oracle.com Thu Aug 17 17:32:08 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 13:32:08 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> Message-ID: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Maybe the links would help: open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8160399 bug link https://bugs.openjdk.java.net/browse/JDK-8164984 On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: > Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this > pointer can be verified > > Also included is: > 8164984: Improper use of is_oop in production code > > http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html > > > I also moved is_oop() to the .cpp file, which reduces the size of > fastdebug libjvm.so a little, since is_oop is only used for assert and > verification. > > before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so > after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so > > Ran all platforms nightly tests (still in progress but no new failures). > > Sorry for the boring code review request. > > Thanks, > Coleen From kim.barrett at oracle.com Thu Aug 17 17:35:36 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Aug 2017 13:35:36 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: > On Aug 17, 2017, at 8:45 AM, John Paul Adrian Glaubitz wrote: > > On 08/16/2017 08:03 AM, Kim Barrett wrote: >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ > > This fails to build on linux-sparc: > > /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:130:10: error: template-id ?operator()<>? for ?T Atomic::PlatformCmpxchg<4>::operator()(T, volatile T*, T, cmpxchg_memory_order)? does not match any template declaration > inline T Atomic::PlatformCmpxchg<4>::operator()(T exchange_value, > ^~~~~~ > > Full log in [1]. Going to test linux-zero next. I accidentally left off the ?const? qualifier for those definitions for all of linux_sparc, linux_zero, and bsd_zero. Sorry about that. I?ve rechecked that bit for all platforms. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.02/ incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.02.inc/ > > Adrian > >> [1] https://people.debian.org/~glaubitz/linux-sparc-build.log > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Thu Aug 17 17:42:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Aug 2017 13:42:18 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> Message-ID: > On Aug 17, 2017, at 1:30 PM, coleen.phillimore at oracle.com wrote: > On 8/16/17 2:03 AM, Kim Barrett wrote: >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/ > > I like the name change to cmpxchg_using_helper. > > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp.udiff.html > > Why does this have rather than the constants like the other platforms? One definition for all cases. The other platforms have different (sometimes only very slightly) code in the specializations for the different sizes. In this case, it?s the same code, regardless of the size. So we don?t need multiple specializations, one for each specific size. > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.01.inc/src/share/vm/metaprogramming/integerTypes.hpp.udiff.html > > Okay, seeing this change, I have to prefer the cast using union. That's super simple and disturbing in it's power. Thank you for the commentary before it. > > The incremental change looks good. I've reviewed this enough to be glad when it's pushed, once all the platforms are verified. Thanks. From ioi.lam at oracle.com Thu Aug 17 17:47:13 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 17 Aug 2017 10:47:13 -0700 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: Hi Coleen, This looks good to me. Thanks Ioi > On Aug 17, 2017, at 10:32 AM, coleen.phillimore at oracle.com wrote: > > > Maybe the links would help: > > open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160399 > bug link https://bugs.openjdk.java.net/browse/JDK-8164984 > > >> On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this pointer can be verified >> >> Also included is: >> 8164984: Improper use of is_oop in production code >> >> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >> >> I also moved is_oop() to the .cpp file, which reduces the size of fastdebug libjvm.so a little, since is_oop is only used for assert and verification. >> >> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >> >> Ran all platforms nightly tests (still in progress but no new failures). >> >> Sorry for the boring code review request. >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Thu Aug 17 18:00:55 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 14:00:55 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: <6a54366a-8c26-64b1-e0c0-08370ad52b4d@oracle.com> Thanks Ioi for slogging through it. Coleen On 8/17/17 1:47 PM, Ioi Lam wrote: > Hi Coleen, > > This looks good to me. > > Thanks > Ioi > >> On Aug 17, 2017, at 10:32 AM, coleen.phillimore at oracle.com wrote: >> >> >> Maybe the links would help: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8160399 >> bug link https://bugs.openjdk.java.net/browse/JDK-8164984 >> >> >>> On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >>> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this pointer can be verified >>> >>> Also included is: >>> 8164984: Improper use of is_oop in production code >>> >>> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >>> >>> I also moved is_oop() to the .cpp file, which reduces the size of fastdebug libjvm.so a little, since is_oop is only used for assert and verification. >>> >>> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >>> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >>> >>> Ran all platforms nightly tests (still in progress but no new failures). >>> >>> Sorry for the boring code review request. >>> >>> Thanks, >>> Coleen From gerard.ziemski at oracle.com Thu Aug 17 18:03:49 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 13:03:49 -0500 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> <05a019c0-2f7e-90aa-8ecf-1988a192ef65@physik.fu-berlin.de> Message-ID: > On Aug 17, 2017, at 12:07 PM, Kim Barrett wrote: > >> On Aug 17, 2017, at 11:26 AM, Gerard Ziemski wrote: >> >> hi Kim, >> >> I got this error building on Mac OS X: >> >> /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:275:10: error: implicit instantiation of undefined template 'Atomic::CmpxchgImpl' >> return CmpxchgImpl()(exchange_value, dest, compare_value, order); >> ^ >> /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:80:34: note: in instantiation of function template specialization 'Atomic::cmpxchg' requested here >> const jbyte result = Atomic::cmpxchg(current ^ flag, dest, current); >> ^ >> /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:164:10: note: template is declared here >> struct CmpxchgImpl; >> ^ >> 1 error generated. >> lib/CompileJvm.gmk:208: recipe for target '/Volumes/Work/bugs/0000000/jdk10/build/macosx-x64/hotspot/variant-server/libjvm/objs/jfrTaggedArtifacts.o' failed >> make[3]: *** [/Volumes/Work/bugs/0000000/jdk10/build/macosx-x64/hotspot/variant-server/libjvm/objs/jfrTaggedArtifacts.o] Error 1 >> make[3]: *** Waiting for unfinished jobs.... >> make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed >> make[2]: *** [hotspot-server-libs] Error 2 >> >> ERROR: Build failed for target 'jdk' in configuration 'macosx-x64' (exit code 2) >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-server_libjvm_objs_jfrTaggedArtifacts.o: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:1: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/precompiled/precompiled.hpp:29: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/asm/assembler.hpp:28: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/asm/codeBuffer.hpp:28: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/code/oopRecorder.hpp:28: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/memory/universe.hpp:28: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/oops/array.hpp:29: >> In file included from /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/memory/allocation.inline.hpp:28: >> /Volumes/Work/bugs/0000000/jdk10/hotspot/src/share/vm/runtime/atomic.hpp:275:10: error: implicit instantiation of undefined template 'Atomic::CmpxchgImpl' >> return CmpxchgImpl()(exchange_value, dest, compare_value, order); >> ^ >> /Volumes/Work/bugs/0000000/jdk10/hotspot/src/closed/share/vm/jfr/jfrTaggedArtifacts.cpp:80:34: note: in instantiation of function template specialization 'Atomic::cmpxchg' requested here >> ... (rest of output omitted) > > Gerard - you are missing the closed part of the change. > > I don?t yet know what John?s problem is, though it?s not the missing closed change, obviously. Verified, that it indeed builds with the open and closed changes applied on Mac OS X. cheers From vladimir.kozlov at oracle.com Thu Aug 17 18:11:43 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Aug 2017 11:11:43 -0700 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: <4629e0e6-608a-b477-d63c-0e6bc330268a@oracle.com> Looks good to me (I did not look on GC changes). Thanks, Vladimir On 8/17/17 10:32 AM, coleen.phillimore at oracle.com wrote: > > Maybe the links would help: > > open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160399 > bug link https://bugs.openjdk.java.net/browse/JDK-8164984 > > > On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this pointer can be verified >> >> Also included is: >> 8164984: Improper use of is_oop in production code >> >> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >> >> I also moved is_oop() to the .cpp file, which reduces the size of fastdebug libjvm.so a little, since is_oop is only used for assert and verification. >> >> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >> >> Ran all platforms nightly tests (still in progress but no new failures). >> >> Sorry for the boring code review request. >> >> Thanks, >> Coleen > From thomas.stuefe at gmail.com Thu Aug 17 18:38:20 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Aug 2017 20:38:20 +0200 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: Hi Gunter, On Thu, Aug 17, 2017 at 5:01 PM, Haug, Gunter wrote: > Thanks for the review, Aleksey and Thomas > > > > You?re right, it is much nicer to use the macros. I?ve updated the change > accordingly: > > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 > > > Small typo: boundries->boundaries Otherwise this is fine. I do not need a new webrev. > @Thomas: os::vm_page_size() is not used in current_stack_region(), I think > because of initialization dependencies. > > Yes, I thought so. Kind Regards, Thomas > > > Best regards, > > Gunter > > > > *From: *Thomas St?fe > *Date: *Thursday, 17. August 2017 at 15:06 > *To: *"Haug, Gunter" > *Cc: *"hotspot-dev at openjdk.java.net" > *Subject: *Re: RFR(S): 8186286: [BSD] Primary thread's stack size is > reported incorrectly > > > > Hi Gunter, > > > > > > On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter wrote: > > Hi, > > can I please have reviews and a sponsor fort the following small bug fix: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ > https://bugs.openjdk.java.net/browse/JDK-8186286 > > At least on Mac OS 10.12 we have observed stack sizes of the primary > thread not aligned to pages boundries. This can be provoked by e.g. > setrlimit() (ulimit -s xxxx in the shell).This voids the computation of the > addresses of the guard pages. > > Fix: > Apparently Mac OS actually rounds upwards to next multiple of page size > however, it is conservative to round downwards here to be on the safe side. > > Thanks and best regards, > Gunter > > > > Thanks for the patch! > > > > Very minor nits: what Alexey wrote (we also have "is_aligned"). Plus, any > reason not to use os::vm_page_size()? Initialization dependencies? > > > > Kind Regards, Thomas > > > > > > > From coleen.phillimore at oracle.com Thu Aug 17 18:59:09 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 14:59:09 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <4629e0e6-608a-b477-d63c-0e6bc330268a@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <4629e0e6-608a-b477-d63c-0e6bc330268a@oracle.com> Message-ID: <66bcb4fd-3395-4e4f-0647-c689b1c42f79@oracle.com> Thanks Vladimir! Coleen On 8/17/17 2:11 PM, Vladimir Kozlov wrote: > Looks good to me (I did not look on GC changes). > > Thanks, > Vladimir > > On 8/17/17 10:32 AM, coleen.phillimore at oracle.com wrote: >> >> Maybe the links would help: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8160399 >> bug link https://bugs.openjdk.java.net/browse/JDK-8164984 >> >> >> On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >>> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >>> pointer can be verified >>> >>> Also included is: >>> 8164984: Improper use of is_oop in production code >>> >>> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >>> >>> >>> I also moved is_oop() to the .cpp file, which reduces the size of >>> fastdebug libjvm.so a little, since is_oop is only used for assert >>> and verification. >>> >>> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >>> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >>> >>> Ran all platforms nightly tests (still in progress but no new >>> failures). >>> >>> Sorry for the boring code review request. >>> >>> Thanks, >>> Coleen >> From gerard.ziemski at oracle.com Thu Aug 17 19:05:28 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Aug 2017 14:05:28 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> Message-ID: <37F57147-78D6-421F-80CE-0011E925C267@oracle.com> > On Aug 17, 2017, at 9:34 AM, Gerard Ziemski wrote: > > hi David, > > Thank you for the review! > > >> On Aug 16, 2017, at 8:09 PM, David Holmes wrote: >> >> Hi Gerard, >> >> On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >>> hi all, >>> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >>> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >> >> That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? > > So normally for -XX flags it?s deprecated -> obsolete -> remove, correct? > > I?m not sure about -X flag either, but it was explained to me that making -Xprof flag work in jdk10 would take considerable amount of effort, so instead of supporting already deprecated flag, we simply remove it - it was officially deprecated in jdk9 using JDK-8176098. > > >>> The changes are XL, but straightforward. >>> If anyone knows of any other remnants that should still be removed, please let me know. >>> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >>> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot >> >> There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: >> >> src/cpu/sparc/vm/macroAssembler_sparc.cpp >> >> - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) >> + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) >> >> Are we still propagating Lmethod here? If so why? Ditto for other places in the file. > > I couldn?t figure out whether we still needed to propagate the Lmethod, and assumed that it was safe to leave it in - the extra code is saving a register, which seems harmless to me and there are other places in the file where we do it. > > >> In: src/share/vm/runtime/thread.cpp >> >> - // eventually timeout, but that takes time. Making this wait a >> - // suspend-equivalent condition solves that timeout problem. >> - // >> Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, >> Mutex::_as_suspend_equivalent_flag); >> >> So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). > > I wasn?t completely sure about this, and was going back and forth on this, but I figured it was safer to leave it in, since there are code paths that still use suspend/resume mechanism, i.e. the deprecated java.lang.Thread.suspend()/resume() APIs. > > Are we sure it?s OK to remove these locks? I verified that j.l.T.suspend()/resume() mechanism doesn?t use the signal based SR APIs, but instead uses JavaThread::java_suspend/java_resume, and since the comment specifically refers to FlatProfiler, I?m going to go ahead and remove these lock->wait() calls. > >> >> --- >> >> I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: >> >> -// within hotspot. Now there is a single use-case for this: >> -// - calling get_thread_pc() on the VMThread by the flat-profiler task >> -// that runs in the watcher thread. >> +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: >> +// - Forte Analyzer: AsyncGetCallTrace() >> +// - StackBanging: get_frame_at_stack_banging_point() >> >> I don't see any use of low-level suspend/resume with the two cases you added ?? > > Those cases depend on ?ucontext? being set up using the resume_clear_context()/suspend_save_context() APIs, which are part of the resume/suspend mechanism - I will try to re-do the comment. After looking into it further I propose the following comment here: //////////////////////////////////////////////////////////////////////////////// // suspend/resume support // The low-level signal-based suspend/resume support is a remnant from the // old VM-suspension that used to be for java-suspension, safepoints etc, // within hotspot. Currently used by JFR's OSThreadSampler // // The remaining code is greatly simplified from the more general suspension // code that used to be used. // // The protocol is quite simple: // - suspend: // - sends a signal to the target thread // - polls the suspend state of the osthread using a yield loop // - target thread signal handler (SR_handler) sets suspend state // and blocks in sigsuspend until continued // - resume: // - sets target osthread state to continue // - sends signal to end the sigsuspend loop in the SR_handler // // Note that the SR_lock plays no role in this suspend/resume protocol, // but is checked for NULL in SR_handler as a thread termination indicator. // The SR_lock is, however, used by JavaThread::java_suspend()/java_resume() APIs. // // Note that resume_clear_context() and suspend_save_context() are needed // by SR_handler(), so that fetch_frame_from_ucontext() works, // which in part is used by: // - Forte Analyzer: AsyncGetCallTrace() // - StackBanging: get_frame_at_stack_banging_point() cheers From george.triantafillou at oracle.com Thu Aug 17 21:09:01 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 17 Aug 2017 17:09:01 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: <661e7992-b25c-74fb-d76d-2769675f5998@oracle.com> Hi Coleen, Looks good. -George On 8/17/2017 1:32 PM, coleen.phillimore at oracle.com wrote: > > Maybe the links would help: > > open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160399 > bug link https://bugs.openjdk.java.net/browse/JDK-8164984 > > > On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >> pointer can be verified >> >> Also included is: >> 8164984: Improper use of is_oop in production code >> >> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >> >> >> I also moved is_oop() to the .cpp file, which reduces the size of >> fastdebug libjvm.so a little, since is_oop is only used for assert >> and verification. >> >> before: -rw-r--r-- 1 cphillim?? 35086408 Aug 17 12:08 libjvm.so >> after: -rw-r--r-- 1 cphillim????? 35073384 Aug 17 12:12 libjvm.so >> >> Ran all platforms nightly tests (still in progress but no new failures). >> >> Sorry for the boring code review request. >> >> Thanks, >> Coleen > From david.holmes at oracle.com Thu Aug 17 21:23:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Aug 2017 07:23:23 +1000 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <37F57147-78D6-421F-80CE-0011E925C267@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> <37F57147-78D6-421F-80CE-0011E925C267@oracle.com> Message-ID: On 18/08/2017 5:05 AM, Gerard Ziemski wrote: > >> On Aug 17, 2017, at 9:34 AM, Gerard Ziemski wrote: >> >> hi David, >> >> Thank you for the review! >> >> >>> On Aug 16, 2017, at 8:09 PM, David Holmes wrote: >>> >>> Hi Gerard, >>> >>> On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >>>> hi all, >>>> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >>>> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >>> >>> That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? >> >> So normally for -XX flags it?s deprecated -> obsolete -> remove, correct? >> >> I?m not sure about -X flag either, but it was explained to me that making -Xprof flag work in jdk10 would take considerable amount of effort, so instead of supporting already deprecated flag, we simply remove it - it was officially deprecated in jdk9 using JDK-8176098. >> >> >>>> The changes are XL, but straightforward. >>>> If anyone knows of any other remnants that should still be removed, please let me know. >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >>>> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot >>> >>> There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: >>> >>> src/cpu/sparc/vm/macroAssembler_sparc.cpp >>> >>> - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) >>> + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) >>> >>> Are we still propagating Lmethod here? If so why? Ditto for other places in the file. >> >> I couldn?t figure out whether we still needed to propagate the Lmethod, and assumed that it was safe to leave it in - the extra code is saving a register, which seems harmless to me and there are other places in the file where we do it. >> >> >>> In: src/share/vm/runtime/thread.cpp >>> >>> - // eventually timeout, but that takes time. Making this wait a >>> - // suspend-equivalent condition solves that timeout problem. >>> - // >>> Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, >>> Mutex::_as_suspend_equivalent_flag); >>> >>> So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). >> >> I wasn?t completely sure about this, and was going back and forth on this, but I figured it was safer to leave it in, since there are code paths that still use suspend/resume mechanism, i.e. the deprecated java.lang.Thread.suspend()/resume() APIs. >> >> Are we sure it?s OK to remove these locks? > > > I verified that j.l.T.suspend()/resume() mechanism doesn?t use the signal based SR APIs, but instead uses JavaThread::java_suspend/java_resume, and since the comment specifically refers to FlatProfiler, I?m going to go ahead and remove these lock->wait() calls. Hold on! That's not what I meant. It is only the use of the Mutex::_as_suspend_equivalent_flag that was needed due to interactions with flat-profiler! We still have to do the rest of the logic. David ----- > >> >>> >>> --- >>> >>> I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: >>> >>> -// within hotspot. Now there is a single use-case for this: >>> -// - calling get_thread_pc() on the VMThread by the flat-profiler task >>> -// that runs in the watcher thread. >>> +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: >>> +// - Forte Analyzer: AsyncGetCallTrace() >>> +// - StackBanging: get_frame_at_stack_banging_point() >>> >>> I don't see any use of low-level suspend/resume with the two cases you added ?? >> >> Those cases depend on ?ucontext? being set up using the resume_clear_context()/suspend_save_context() APIs, which are part of the resume/suspend mechanism - I will try to re-do the comment. > > After looking into it further I propose the following comment here: > > //////////////////////////////////////////////////////////////////////////////// > // suspend/resume support > > // The low-level signal-based suspend/resume support is a remnant from the > // old VM-suspension that used to be for java-suspension, safepoints etc, > // within hotspot. Currently used by JFR's OSThreadSampler > // > // The remaining code is greatly simplified from the more general suspension > // code that used to be used. > // > // The protocol is quite simple: > // - suspend: > // - sends a signal to the target thread > // - polls the suspend state of the osthread using a yield loop > // - target thread signal handler (SR_handler) sets suspend state > // and blocks in sigsuspend until continued > // - resume: > // - sets target osthread state to continue > // - sends signal to end the sigsuspend loop in the SR_handler > // > // Note that the SR_lock plays no role in this suspend/resume protocol, > // but is checked for NULL in SR_handler as a thread termination indicator. > // The SR_lock is, however, used by JavaThread::java_suspend()/java_resume() APIs. > // > // Note that resume_clear_context() and suspend_save_context() are needed > // by SR_handler(), so that fetch_frame_from_ucontext() works, > // which in part is used by: > // - Forte Analyzer: AsyncGetCallTrace() > // - StackBanging: get_frame_at_stack_banging_point() > > > cheers > > From glaubitz at physik.fu-berlin.de Thu Aug 17 21:32:38 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 17 Aug 2017 23:32:38 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: On 08/17/2017 07:35 PM, Kim Barrett wrote: > I accidentally left off the ?const? qualifier for those definitions for all of linux_sparc, linux_zero, and bsd_zero. > Sorry about that. I?ve rechecked that bit for all platforms. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.02/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.02.inc/ Yes, I can confirm that this fixes the particular problem on linux-zero and linux-sparc, although both builds still fail. For linux-zero I had to add a missing "#include " to hotspot/src/share/vm/runtime/vmStructs.hpp as otherwise the build would bail out complaining that "uint32_t" and "uint64_t" are not defined. On linux-sparc, the build currently fails with: Building target 'default (exploded-image)' in configuration 'linux-sparcv9-normal-server-release' Compiling 2901 files for java.base /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:65:5: error: prototype for ?int VM_Version::platform_features(int)? does not match any in class ?VM_Version? int VM_Version::platform_features(int features) { ^~~~~~~~~~ In file included from /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:28:0: /var/lib/buildd/openjdk/hs/hotspot/src/cpu/sparc/vm/vm_version_sparc.hpp:196:15: error: candidate is: static void VM_Version::platform_features() static void platform_features(); ^~~~~~~~~~~~~~~~~ /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:61:13: warning: ?bool detect_blkinit()? defined but not used [-Wunused-function] static bool detect_blkinit() { ^~~~~~~~~~~~~~ /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:57:13: warning: ?bool detect_M_family()? defined but not used [-Wunused-function] static bool detect_M_family() { ^~~~~~~~~~~~~~~ /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:53:13: warning: ?bool detect_niagara()? defined but not used [-Wunused-function] static bool detect_niagara() { ^~~~~~~~~~~~~~ lib/CompileJvm.gmk:208: recipe for target '/var/lib/buildd/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/vm_version_linux_sparc.o' failed make[3]: *** [/var/lib/buildd/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/vm_version_linux_sparc.o] Error 1 make[3]: *** Waiting for unfinished jobs.... But I'm too tired now to debug this. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Thu Aug 17 21:38:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Aug 2017 07:38:05 +1000 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> Message-ID: <66d3f1b0-3c1e-65c1-8d4d-72b9e52bac08@oracle.com> Hi Gerard, On 18/08/2017 12:34 AM, Gerard Ziemski wrote: > hi David, > > Thank you for the review! > > >> On Aug 16, 2017, at 8:09 PM, David Holmes wrote: >> >> Hi Gerard, >> >> On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >>> hi all, >>> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >>> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >> >> That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? > > So normally for -XX flags it?s deprecated -> obsolete -> remove, correct? Yes. > I?m not sure about -X flag either, but it was explained to me that making -Xprof flag work in jdk10 would take considerable amount of effort, so instead of supporting already deprecated flag, we simply remove it - it was officially deprecated in jdk9 using JDK-8176098. Obsoleting the flag still allows removal of all the functionality, it just means use of the flag itself doesn't produce an error, but a warning telling you the flag is obsolete and has no effect and will be removed in the future. > >>> The changes are XL, but straightforward. >>> If anyone knows of any other remnants that should still be removed, please let me know. >>> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >>> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot >> >> There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: >> >> src/cpu/sparc/vm/macroAssembler_sparc.cpp >> >> - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) >> + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) >> >> Are we still propagating Lmethod here? If so why? Ditto for other places in the file. > > I couldn?t figure out whether we still needed to propagate the Lmethod, and assumed that it was safe to leave it in - the extra code is saving a register, which seems harmless to me and there are other places in the file where we do it. This needs to be assessed by compiler folk. If we leave in code that was only needed for flat-profiler but remove all such comments then no-one will know why we are doing something. If this code is needed then the comment should reflect why; if not needed it should be removed. > >> In: src/share/vm/runtime/thread.cpp >> >> - // eventually timeout, but that takes time. Making this wait a >> - // suspend-equivalent condition solves that timeout problem. >> - // >> Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, >> Mutex::_as_suspend_equivalent_flag); >> >> So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). > > I wasn?t completely sure about this, and was going back and forth on this, but I figured it was safer to leave it in, since there are code paths that still use suspend/resume mechanism, i.e. the deprecated java.lang.Thread.suspend()/resume() APIs. > > Are we sure it?s OK to remove these locks? As per other email it is only the use of the flag that could be removed, if it truly only was needed due to flat-profiler interactions. But looking at the full block of code in context it seems that the need to be "suspend equivalent" was already part of this logic and that that was sufficient to fix the flat-profiler issue. So it looks like the code should remain as-is. >> --- >> >> I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: >> >> -// within hotspot. Now there is a single use-case for this: >> -// - calling get_thread_pc() on the VMThread by the flat-profiler task >> -// that runs in the watcher thread. >> +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: >> +// - Forte Analyzer: AsyncGetCallTrace() >> +// - StackBanging: get_frame_at_stack_banging_point() >> >> I don't see any use of low-level suspend/resume with the two cases you added ?? > > Those cases depend on ?ucontext? being set up using the resume_clear_context()/suspend_save_context() APIs, which are part of the resume/suspend mechanism - I will try to re-do the comment. That comment pertained to actual use of the low-level suspend/resume mechanism which is not used by AGCT or stack-banging. I would just terminate the comment at "within hotspot" and not add any additional text. Thanks, David ----- >> --- >> >> src/os_cpu/linux_s390/vm/thread_linux_s390.hpp >> >> /* >> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. >> >> That's an incorrect copyright update - should be "2016, 2017,? > > Thank you for catching this. > > >> >> --- >> >> src/os/solaris/vm/osThread_solaris.hpp >> >> // *************************************************************** >> - // interrupt support. interrupts (using signals) are used to get >> - // the thread context (get_thread_pc), to set the thread context >> - // (set_thread_pc), and to implement java.lang.Thread.interrupt. >> + // interrupt support. interrupts (using signals) are used to >> + // implement java.lang.Thread.interrupt. >> // *************************************************************** >> >> That entire comment block can be deleted. We haven't used signals for j.l.T.interrupt for years. > > Thank you for catching this. > > > cheers > From glaubitz at physik.fu-berlin.de Thu Aug 17 21:41:17 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 17 Aug 2017 23:41:17 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: On 08/17/2017 11:32 PM, John Paul Adrian Glaubitz wrote: > On linux-sparc, the build currently fails with: > > Building target 'default (exploded-image)' in configuration 'linux-sparcv9-normal-server-release' > Compiling 2901 files for java.base > /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:65:5: error: prototype for ?int VM_Version::platform_features(int)? does > not match any in class ?VM_Version? > int VM_Version::platform_features(int features) { > ^~~~~~~~~~ > In file included from /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:28:0: > /var/lib/buildd/openjdk/hs/hotspot/src/cpu/sparc/vm/vm_version_sparc.hpp:196:15: error: candidate is: static void VM_Version::platform_features() > static void platform_features(); > ^~~~~~~~~~~~~~~~~ > /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:61:13: warning: ?bool detect_blkinit()? defined but not used > [-Wunused-function] > static bool detect_blkinit() { > ^~~~~~~~~~~~~~ > /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:57:13: warning: ?bool detect_M_family()? defined but not used > [-Wunused-function] > static bool detect_M_family() { > ^~~~~~~~~~~~~~~ > /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:53:13: warning: ?bool detect_niagara()? defined but not used > [-Wunused-function] > static bool detect_niagara() { > ^~~~~~~~~~~~~~ > lib/CompileJvm.gmk:208: recipe for target > '/var/lib/buildd/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/vm_version_linux_sparc.o' failed > make[3]: *** [/var/lib/buildd/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/vm_version_linux_sparc.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > > But I'm too tired now to debug this. Ok, it seems that this is just a matter of fixing the declaration for VM_Version::platform_features() in hotspot/src/cpu/sparc/vm/vm_version_sparc.hpp. Will send a patch tomorrow once I have verified that this is all that's needed to fix the build :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Thu Aug 17 21:54:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Aug 2017 07:54:51 +1000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: Hi Gunter, On 18/08/2017 1:01 AM, Haug, Gunter wrote: > Thanks for the review, Aleksey and Thomas > > You?re right, it is much nicer to use the macros. I?ve updated the change accordingly: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 I'm unclear about the logic change here. If you round down then there is a chance you will enter the following if-block where otherwise you would not. 915 *size = align_down(*size, getpagesize()); 916 917 if ((*size) < (DEFAULT_MAIN_THREAD_STACK_PAGES * (size_t)getpagesize())) { Have you verified with a range of aligned and unaligned stack sizes around that threshhold that everything works okay? Some typos in the comment block: alligned -> aligned boundries -> boundaries I round -> We round > @Thomas: os::vm_page_size() is not used in current_stack_region(), I think because of initialization dependencies. I don't see the dependency. It requires that it only be used after os::init() has been called. AFAICS the first time we will use this logic is when we attach the main thread, which happens after os::init(). Thanks, David > Best regards, > Gunter > > From: Thomas St?fe > Date: Thursday, 17. August 2017 at 15:06 > To: "Haug, Gunter" > Cc: "hotspot-dev at openjdk.java.net" > Subject: Re: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly > > Hi Gunter, > > > On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter > wrote: > Hi, > > can I please have reviews and a sponsor fort the following small bug fix: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ > https://bugs.openjdk.java.net/browse/JDK-8186286 > > At least on Mac OS 10.12 we have observed stack sizes of the primary thread not aligned to pages boundries. This can be provoked by e.g. setrlimit() (ulimit -s xxxx in the shell).This voids the computation of the addresses of the guard pages. > > Fix: > Apparently Mac OS actually rounds upwards to next multiple of page size however, it is conservative to round downwards here to be on the safe side. > > Thanks and best regards, > Gunter > > Thanks for the patch! > > Very minor nits: what Alexey wrote (we also have "is_aligned"). Plus, any reason not to use os::vm_page_size()? Initialization dependencies? > > Kind Regards, Thomas > > > From david.holmes at oracle.com Thu Aug 17 21:59:32 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Aug 2017 07:59:32 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: Adrian, FYI the linux-sparc port has somewhat fallen by the wayside so you may find numerous issues on that platform. David On 18/08/2017 7:41 AM, John Paul Adrian Glaubitz wrote: > On 08/17/2017 11:32 PM, John Paul Adrian Glaubitz wrote: >> On linux-sparc, the build currently fails with: >> >> Building target 'default (exploded-image)' in configuration 'linux-sparcv9-normal-server-release' >> Compiling 2901 files for java.base >> /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:65:5: error: prototype for ?int VM_Version::platform_features(int)? does >> not match any in class ?VM_Version? >> int VM_Version::platform_features(int features) { >> ^~~~~~~~~~ >> In file included from /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:28:0: >> /var/lib/buildd/openjdk/hs/hotspot/src/cpu/sparc/vm/vm_version_sparc.hpp:196:15: error: candidate is: static void VM_Version::platform_features() >> static void platform_features(); >> ^~~~~~~~~~~~~~~~~ >> /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:61:13: warning: ?bool detect_blkinit()? defined but not used >> [-Wunused-function] >> static bool detect_blkinit() { >> ^~~~~~~~~~~~~~ >> /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:57:13: warning: ?bool detect_M_family()? defined but not used >> [-Wunused-function] >> static bool detect_M_family() { >> ^~~~~~~~~~~~~~~ >> /var/lib/buildd/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:53:13: warning: ?bool detect_niagara()? defined but not used >> [-Wunused-function] >> static bool detect_niagara() { >> ^~~~~~~~~~~~~~ >> lib/CompileJvm.gmk:208: recipe for target >> '/var/lib/buildd/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/vm_version_linux_sparc.o' failed >> make[3]: *** [/var/lib/buildd/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/vm_version_linux_sparc.o] Error 1 >> make[3]: *** Waiting for unfinished jobs.... >> >> But I'm too tired now to debug this. > > Ok, it seems that this is just a matter of fixing the declaration for > > VM_Version::platform_features() > > in hotspot/src/cpu/sparc/vm/vm_version_sparc.hpp. > > Will send a patch tomorrow once I have verified that this is all that's > needed to fix the build :). > > Adrian > From glaubitz at physik.fu-berlin.de Thu Aug 17 22:20:26 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 18 Aug 2017 00:20:26 +0200 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <9E929AC6-BB17-4730-B731-30E7431A5259@oracle.com> <956DECC8-2833-4C00-80C1-2ED9E424E63D@oracle.com> <9bc11975-6106-6987-2330-1f4bd54407d7@physik.fu-berlin.de> Message-ID: On 08/17/2017 11:59 PM, David Holmes wrote: > FYI the linux-sparc port has somewhat fallen by the wayside so you may find numerous issues on that platform. Yes, I'm aware of that. I have actually contributed three patches to fix the build of linux-sparc. Although I still hope that Oracle will eventually pick up the port again given their official support for Linux on SPARC ;). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Thu Aug 17 23:30:35 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Aug 2017 01:30:35 +0200 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: <2dfdcaf1-13cb-1f03-85ac-91935cded254@oracle.com> Hi Coleen, Could you motivate why you changed is_oop() to a static functions? StefanK On 2017-08-17 19:32, coleen.phillimore at oracle.com wrote: > > Maybe the links would help: > > open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160399 > bug link https://bugs.openjdk.java.net/browse/JDK-8164984 > > > On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >> pointer can be verified >> >> Also included is: >> 8164984: Improper use of is_oop in production code >> >> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >> >> >> I also moved is_oop() to the .cpp file, which reduces the size of >> fastdebug libjvm.so a little, since is_oop is only used for assert >> and verification. >> >> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >> >> Ran all platforms nightly tests (still in progress but no new failures). >> >> Sorry for the boring code review request. >> >> Thanks, >> Coleen > From kim.barrett at oracle.com Thu Aug 17 23:47:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Aug 2017 19:47:18 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <2dfdcaf1-13cb-1f03-85ac-91935cded254@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <2dfdcaf1-13cb-1f03-85ac-91935cded254@oracle.com> Message-ID: <6ACE3C3E-4FAC-48DB-9777-5609F1D766E0@oracle.com> > On Aug 17, 2017, at 7:30 PM, Stefan Karlsson wrote: > > Hi Coleen, > > Could you motivate why you changed is_oop() to a static functions? Quoting myself from a comment in 8160399: For it [is_oop] to fail one has to take a non-oop, make it appear to be an oop, and call an oop member function on that not really an oop. That sounds like UB to me. From serguei.spitsyn at oracle.com Fri Aug 18 00:19:22 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Aug 2017 17:19:22 -0700 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: <0730a41d-10c6-954b-ed1a-4c8f9b2f8069@oracle.com> Hi Coleen, It looks good. Thanks, Serguei On 8/17/17 10:32, coleen.phillimore at oracle.com wrote: > > Maybe the links would help: > > open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160399 > bug link https://bugs.openjdk.java.net/browse/JDK-8164984 > > > On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >> pointer can be verified >> >> Also included is: >> 8164984: Improper use of is_oop in production code >> >> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >> >> >> I also moved is_oop() to the .cpp file, which reduces the size of >> fastdebug libjvm.so a little, since is_oop is only used for assert >> and verification. >> >> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >> >> Ran all platforms nightly tests (still in progress but no new failures). >> >> Sorry for the boring code review request. >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Fri Aug 18 00:48:47 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 20:48:47 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <6ACE3C3E-4FAC-48DB-9777-5609F1D766E0@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <2dfdcaf1-13cb-1f03-85ac-91935cded254@oracle.com> <6ACE3C3E-4FAC-48DB-9777-5609F1D766E0@oracle.com> Message-ID: On 8/17/17 7:47 PM, Kim Barrett wrote: >> On Aug 17, 2017, at 7:30 PM, Stefan Karlsson wrote: >> >> Hi Coleen, >> >> Could you motivate why you changed is_oop() to a static functions? > Quoting myself from a comment in 8160399: > > For it [is_oop] to fail one has to take a non-oop, make it appear to be an oop, and > call an oop member function on that not really an oop. That sounds like UB to me. > > Yes, and there is a linked bug about updating to a new version of gcc that (may have) optimized this undefined behavior. So it's good to get it cleaned up before we go to C++11 or newer compilers. https://bugs.openjdk.java.net/browse/JDK-8160363 thanks, Coleen From coleen.phillimore at oracle.com Fri Aug 18 00:49:05 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Aug 2017 20:49:05 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <0730a41d-10c6-954b-ed1a-4c8f9b2f8069@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <0730a41d-10c6-954b-ed1a-4c8f9b2f8069@oracle.com> Message-ID: <17355e50-8d65-15b0-5a6b-79ffcc2e4915@oracle.com> Thanks Serguei! Coleen On 8/17/17 8:19 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good. > > Thanks, > Serguei > > > On 8/17/17 10:32, coleen.phillimore at oracle.com wrote: >> >> Maybe the links would help: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8160399 >> bug link https://bugs.openjdk.java.net/browse/JDK-8164984 >> >> >> On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >>> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >>> pointer can be verified >>> >>> Also included is: >>> 8164984: Improper use of is_oop in production code >>> >>> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >>> >>> >>> I also moved is_oop() to the .cpp file, which reduces the size of >>> fastdebug libjvm.so a little, since is_oop is only used for assert >>> and verification. >>> >>> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >>> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >>> >>> Ran all platforms nightly tests (still in progress but no new >>> failures). >>> >>> Sorry for the boring code review request. >>> >>> Thanks, >>> Coleen >> > From david.holmes at oracle.com Fri Aug 18 01:31:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Aug 2017 11:31:37 +1000 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> Message-ID: <0bb19a38-7840-fe9e-b2e8-f5c6f96143ef@oracle.com> Hi Coleen, Not that you need another Review but this looks good to me :) One comment below - feel free to ignore. On 18/08/2017 3:32 AM, coleen.phillimore at oracle.com wrote: > > Maybe the links would help: > > open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev src/share/vm/code/dependencies.cpp - assert(result == NULL || result->is_oop(), "must be"); + assert(result == NULL || oopDesc::is_oop(result), "must be"); That could just use oopDesc::is_oop_or_null(result). There are a number of places that could do this. No big deal though. Thanks, David ----- > bug link https://bugs.openjdk.java.net/browse/JDK-8160399 > bug link https://bugs.openjdk.java.net/browse/JDK-8164984 > > > On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >> pointer can be verified >> >> Also included is: >> 8164984: Improper use of is_oop in production code >> >> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >> >> >> I also moved is_oop() to the .cpp file, which reduces the size of >> fastdebug libjvm.so a little, since is_oop is only used for assert and >> verification. >> >> before: -rw-r--r-- 1 cphillim?? 35086408 Aug 17 12:08 libjvm.so >> after: -rw-r--r-- 1 cphillim????? 35073384 Aug 17 12:12 libjvm.so >> >> Ran all platforms nightly tests (still in progress but no new failures). >> >> Sorry for the boring code review request. >> >> Thanks, >> Coleen > From thomas.stuefe at gmail.com Fri Aug 18 03:59:37 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 18 Aug 2017 05:59:37 +0200 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: Hi David, On Thu, Aug 17, 2017 at 11:54 PM, David Holmes wrote: > Hi Gunter, > > On 18/08/2017 1:01 AM, Haug, Gunter wrote: > >> Thanks for the review, Aleksey and Thomas >> >> You?re right, it is much nicer to use the macros. I?ve updated the change >> accordingly: >> http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 >> > > I'm unclear about the logic change here. If you round down then there is a > chance you will enter the following if-block where otherwise you would not. > > 915 *size = align_down(*size, getpagesize()); > 916 > 917 if ((*size) < (DEFAULT_MAIN_THREAD_STACK_PAGES * > (size_t)getpagesize())) { > > I don't see how this could happen? Gunters fix causes the size to snap to the lower page boundary, but never cross it. The code below ensures a lower cap at a page boundary. If size was larger than that cap, after the align_down it will be at most right at that cap. If it was lower than the cap, it stays lower. In both cases behavior is unchanged. Cheers, Thomas Have you verified with a range of aligned and unaligned stack sizes around > that threshhold that everything works okay? > > Some typos in the comment block: > > alligned -> aligned > boundries -> boundaries > I round -> We round > > @Thomas: os::vm_page_size() is not used in current_stack_region(), I think >> because of initialization dependencies. >> > > I don't see the dependency. It requires that it only be used after > os::init() has been called. AFAICS the first time we will use this logic is > when we attach the main thread, which happens after os::init(). Thanks, > David > > Best regards, >> Gunter >> >> From: Thomas St?fe >> Date: Thursday, 17. August 2017 at 15:06 >> To: "Haug, Gunter" >> Cc: "hotspot-dev at openjdk.java.net" >> Subject: Re: RFR(S): 8186286: [BSD] Primary thread's stack size is >> reported incorrectly >> >> Hi Gunter, >> >> >> On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter > > wrote: >> Hi, >> >> can I please have reviews and a sponsor fort the following small bug fix: >> http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ >> https://bugs.openjdk.java.net/browse/JDK-8186286 >> >> At least on Mac OS 10.12 we have observed stack sizes of the primary >> thread not aligned to pages boundries. This can be provoked by e.g. >> setrlimit() (ulimit -s xxxx in the shell).This voids the computation of the >> addresses of the guard pages. >> >> Fix: >> Apparently Mac OS actually rounds upwards to next multiple of page size >> however, it is conservative to round downwards here to be on the safe side. >> >> Thanks and best regards, >> Gunter >> >> Thanks for the patch! >> >> Very minor nits: what Alexey wrote (we also have "is_aligned"). Plus, any >> reason not to use os::vm_page_size()? Initialization dependencies? >> >> Kind Regards, Thomas >> >> >> >> From david.holmes at oracle.com Fri Aug 18 04:18:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Aug 2017 14:18:04 +1000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: Message-ID: <4f0f1741-95d2-5e00-8482-8c102f5d9a3d@oracle.com> Hi Thomas, On 18/08/2017 1:59 PM, Thomas St?fe wrote: > Hi David, > > On Thu, Aug 17, 2017 at 11:54 PM, David Holmes > wrote: > > Hi Gunter, > > On 18/08/2017 1:01 AM, Haug, Gunter wrote: > > Thanks for the review, Aleksey and Thomas > > You?re right, it is much nicer to use the macros. I?ve updated > the change accordingly: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 > > > > I'm unclear about the logic change here. If you round down then > there is a chance you will enter the following if-block where > otherwise you would not. > > ?915? ? ?*size = align_down(*size, getpagesize()); > ?916 > ?917? ? ?if ((*size) < (DEFAULT_MAIN_THREAD_STACK_PAGES * > (size_t)getpagesize())) { > > > I don't see how this could happen? Gunters fix causes the size to snap > to the lower page boundary, but never cross it. The code below ensures a > lower cap at a page boundary. Yes you are right - sorry for the noise. David > If size was larger than that cap, after the align_down it will be at > most right at that cap. If it was lower than the cap, it stays lower. In > both cases behavior ?is unchanged. > > Cheers, Thomas > > Have you verified with a range of aligned and unaligned stack sizes > around that threshhold that everything works okay? > > Some typos in the comment block: > > alligned -> aligned > boundries -> boundaries > I round -> We round > > @Thomas: os::vm_page_size() is not used in > current_stack_region(), I think because of initialization > dependencies. > > > I don't see the dependency. It requires that it only be used after > os::init() has been called. AFAICS the first time we will use this > logic is when we attach the main thread, which happens after > os::init(). > > Thanks, > David > > Best regards, > Gunter > > From: Thomas St?fe > > Date: Thursday, 17. August 2017 at 15:06 > To: "Haug, Gunter" > > Cc: "hotspot-dev at openjdk.java.net > " > > > Subject: Re: RFR(S): 8186286: [BSD] Primary thread's stack size > is reported incorrectly > > Hi Gunter, > > > On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter > >> wrote: > Hi, > > can I please have reviews and a sponsor fort the following small > bug fix: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ > > https://bugs.openjdk.java.net/browse/JDK-8186286 > > > At least on Mac OS 10.12 we have observed stack sizes of the > primary thread not aligned to pages boundries. This can be > provoked by e.g. setrlimit() (ulimit -s xxxx in the shell).This > voids the computation of the addresses of the guard pages. > > Fix: > Apparently Mac OS actually rounds upwards to next multiple of > page size however, it is conservative to round downwards here to > be on the safe side. > > Thanks and best regards, > Gunter > > Thanks for the patch! > > Very minor nits: what Alexey wrote (we also have "is_aligned"). > Plus, any reason not to use os::vm_page_size()? Initialization > dependencies? > > Kind Regards, Thomas > > > > From csjammi at gmail.com Thu Aug 17 23:47:20 2017 From: csjammi at gmail.com (Chandra Shekahr Jammi) Date: Thu, 17 Aug 2017 23:47:20 +0000 Subject: TLAB pointer movement in Hotspot implementation In-Reply-To: <1501836371.2387.21.camel@oracle.com> References: <1501836371.2387.21.camel@oracle.com> Message-ID: Krystal & Thomas, Thanks a lot for your response. That helped a lot. If understand your explanation about lack of synchronization correctly, delay is observed if I read from other threads. But, if the I read ThreadMXBean#getThreadAllocatedBytes(long) from the thread Im asking allocated bytes for, there should be no delay ? Again, thank you for your time. Thanks CJ On Fri, Aug 4, 2017 at 1:46 AM Thomas Schatzl wrote: > Hi, > > On Thu, 2017-08-03 at 23:18 -0700, Krystal Mok wrote: > > Hi CJ, > > > > The JavaThread::_allocated_bytes field is updated every time the > > thread's TLAB is being retired > > (ThreadLocalAllocBuffer::make_parsable()), and also > > when there's a big allocation that goes through the slow path > > (CollectedHeap::common_mem_allocate_noinit()). So, that keeps track > > of the cumulative sum of all GC heap memory allocated from this > > thread. > > This behavior is exactly what the somewhat generic description also > tries to cover: with -XX:UseTLAB (which is by default enabled), you get > allocation information on a TLAB basis, not an object basis. > > > By adding that with the current TLAB's used(), you'd get a fairly > > accurate number of the allocated bytes of a thread. There's no > > intentional delay. The only "delay" would come from the fact that the > > _allocated_bytes field is only loaded with acquire semantics, but not > > written to with release semantics, so there might be a slight gap > > there due to lack of synchronization, by design. > > Due to this unsynchronized access between amount of TLAB space > allocated and current TLAB's used, it might also happen that the > reported number of bytes allocated jumps backwards intermittently. > > E.g. if you have multiple readings of that bean: > > reading-1 = JavaThread::_allocated_bytes (=1000) + TLAB::used() for > TLAB X (=3000) -> 4000 > > reading-2 = JavaThread::_allocated_bytes (=1000) + TLAB::used() for > TLAB X+1 (=0) -> 1000 > > I.e. between the reading of the old value of allocated so far and > reading TLAB's used() the thread retired a TLAB and allocated a new > one. Or the new value for TLAB::used() X+1 just got visible to the CPU > reading the data before the new value of JavaThread::_allocated_bytes. > > Thanks, > Thomas > > From stefan.karlsson at oracle.com Fri Aug 18 06:31:54 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Aug 2017 08:31:54 +0200 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <6ACE3C3E-4FAC-48DB-9777-5609F1D766E0@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <2dfdcaf1-13cb-1f03-85ac-91935cded254@oracle.com> <6ACE3C3E-4FAC-48DB-9777-5609F1D766E0@oracle.com> Message-ID: On 2017-08-18 01:47, Kim Barrett wrote: >> On Aug 17, 2017, at 7:30 PM, Stefan Karlsson wrote: >> >> Hi Coleen, >> >> Could you motivate why you changed is_oop() to a static functions? > > Quoting myself from a comment in 8160399: > > For it [is_oop] to fail one has to take a non-oop, make it appear to be an oop, and > call an oop member function on that not really an oop. That sounds like UB to me. > So, what about the implementation of is_oop(): 536 // used only for asserts and guarantees 537 inline bool oopDesc::is_oop(oop obj, bool ignore_mark_word) { 538 if (!check_obj_alignment(obj)) return false; 539 if (!Universe::heap()->is_in_reserved(obj)) return false; 540 // obj is aligned and accessible in heap 541 if (Universe::heap()->is_in_reserved(obj->klass_or_null())) return false; 542 543 // Header verification: the mark is typically non-NULL. If we're 544 // at a safepoint, it must not be null. 545 // Outside of a safepoint, the header could be changing (for example, 546 // another thread could be inflating a lock on this object). 547 if (ignore_mark_word) { 548 return true; 549 } 550 if (obj->mark() != NULL) { 551 return true; 552 } 553 return !SafepointSynchronize::is_at_safepoint(); 554 } It calls both obj->klass_or_null() and obj->mark(). Shouldn't those calls be considered UB as well? Should we fix those calls? StefanK > From cthalinger at twitter.com Fri Aug 18 07:31:42 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 18 Aug 2017 09:31:42 +0200 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> <1990779c-f3b8-2bbb-5d1a-2a031cb158d9@oracle.com> Message-ID: <7DA6F743-EC44-4AE9-A3DC-B2EDC3744BF4@twitter.com> > On Aug 15, 2017, at 4:56 AM, coleen.phillimore at oracle.com wrote: > > > > On 8/14/17 8:26 PM, David Holmes wrote: >> On 15/08/2017 9:46 AM, coleen.phillimore at oracle.com wrote: >>> >>> Better yet, I removed the _pd field assignment from being cmpxchg/conditional and do it under the metaspace_lock which we take out anyway to add the handle. How is this? >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.03/webrev >> >> I like the fact OopHandle no longer has atomics. :) > > Yes, this solved a bunch of problems. Do you still need this: 32 class outputStream; ? >> >> Sorry I'm being a bit dense today when it comes to this code: >> >> ! void ClassLoaderData::init_handle_locked(OopHandle& dest, Handle h) { >> ! MutexLockerEx ml(metaspace_lock(), Mutex::_no_safepoint_check_flag); >> ! if (dest.resolve() != NULL) { >> ! return; >> ! } else { >> ! dest = _handles.add(h()); >> ! } >> } >> >> I would have expected to see something like dest.set(x). I'm not sure what magic operator= is doing behind the scenes here ?? > > It's doing a bitwise copy. >> >> I did check the code that calls this, and the locking seems safe in that context. >> > > Thanks. It's a lot better now. > Coleen >> Thanks, >> David >> >>> I reran the tests that use this code. >>> >>> thanks, >>> Coleen >>> >>> On 8/14/17 4:36 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 8/13/17 9:04 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Make an OopHandle type to replace jobject to encapsulate these oop pointers in metadata and module entry. >>>>>>> >>>>>>> This replaces places where there's a jobject that doesn't point into the JNIHandles, notably things allocated in ClassLoaderData::_handles. >>>>>>> >>>>>>> There were platform specific changes that I tried to carefully make - can someone test them for s390, aarch64 and ppc? >>>>>>> >>>>>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, monitoring, parallel class loading and g1class unloading tests. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>>>>> >>>>>> Is it possible to put the declaration of MacroAssembler::resolve_oop_handle into the shared macroAssembler.hpp file to avoid the need to add it to the platform specific hpp files? >>>>>> >>>>>> I'm unsure about the OopHandle containing set_atomic. First if it is present then the _obj field should be volatile. But then it also raises the question: if we can race to set this, do we need load-acquire versions of the accessors? Based on the single existing usage I don't think we presently do. But I think it may be cleaner/simpler to not have set_atomic, make the OopHandle immutable, and do the cmpxchg back in the caller code by atomically updating _pd (which should also be volatile even today) with a new OopHandle. >>>>> >>>>> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() to an address of OopHandle since it is not a pointer but a struct. The >>>> >>>> _pd would have to be a pointer. >>>> >>>>> casting would be wrong. So I added a resolve_acquire() for the protection_domain case in ModuleEntry, and some commentary. >>>> >>>> For completeness you may also need ptr_acquire(). >>>> >>>> The _obj field should be volatile. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Coleen From aph at redhat.com Fri Aug 18 13:21:25 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Aug 2017 14:21:25 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: On 14/08/17 03:41, Kim Barrett wrote: > Please review this change to Atomic::cmpxchg, making it a function > template with a per-platform underlying implementation. > > This has been broken out from 8184334: "Generalizing Atomic with > templates", as the originally proposed change there encountered > various objections. This change takes a somewhat different approach > to the same problem. > > One goal is to generalize the API and make it more type-safe, > eliminating (nearly) all need for casts by callers. Another is to > allow more direct per-platform implementations, especially where there > are appropriate compiler intrinsics available. > > If all goes well and this change is accepted, it is intended that the > remainder of Atomic, and later OrderAccess, will be changed in a > similar manner as one or more followups. > > This change to cmpxchg deprecates cmpxchg_ptr. Followup changes will > convert existing uses of cmpxchg_ptr and eventually remove it. > Followup changes will also update uses of cmpxchg that can be > simplified because of the generalized API. > > The cmpxchg function calls private Atomic::CmpxchgImpl, to select > among several cases, based on the argument types. Each case performs > some checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformCmpxchg. The PlatformCmpxchg class > is provided by each platform, and performs additional case analysis to > generate the appropriate code for the platform. > > This change involves modifications to all of the existing platform > implementations of cmpxchg. I've updated all of the platforms, but > only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > New metaprogramming utilities: > integerTypes.hpp > test_integerTypes.cpp > isRegisteredEnum.hpp > test_isRegisteredEnum.cpp > > Change cmpxchg to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > os_bsd.cpp > os_solaris.cpp > aotCodeHeap.cpp > aotCodeHeap.hpp > psParallelCompact.hpp > workgroup.cpp > oopsHierarchy.hpp > os.cpp > > Example updates of cmpxchg_ptr to cmpxchg: > oop.inline.hpp > bitMap.cpp > bitMap.inline.hpp > > Some specific issues: > > - For Solaris (both SPARC and x86), we were using helper functions > defined in corresponding .il files. Using the cmpxchg_using_stub > helper didn't work; passing a "defined in .il" function as a template > parameter didn't work, leading to linker errors. The ideal solution > is to use gcc-style inline assembly, which is now supported by Solaris > Studio. That change was made for SPARC. However, making that change > for x86 ran into related segfaults, so using the .il definition with > direct conversions for now, until that problem can be resolved. > > - I've added the function template Atomic::condition_store_ptr, which > is a cmpxchg for pointer types with a NULL compare_value. That might > not be the best name for it. > > - The name IntegerTypes was retained from the original RFR for > JDK-8184334. However, that name no longer fits the provided > functionality very well, and I think a new name is needed. Something > involving Bitwise, or ValueRepresentation perhaps? I'm open to > suggestions. > > - Issues with casts/conversions provided by IntegerTypes. > > * Conversions between integers and floating point values are > supported. It was suggested during the discussion of the RFR for > JDK-8184334 that this was not needed, as there are no uses of > atomic/ordered floating point values in Hotspot. However, I'm told > VarHandles may include atomic floating point values. I am very strongly opposed to checking unused code into HotSpot. Apart from the obvious obervation that it's impossible to test, it makes far more sense to add it if it is ever needed. > * Conversions between integers and floating point values are presently > implemented using the memcpy technique. While this technique is > correct, it is known to be quite poorly optimized by some compilers. > It may be necessary to use the "union trick" for performance reasons, > even though it is technically undefined behavior. Hotspot already > does this elsewhere (and we should merge some of the different > conversion handling). > > * In the original RFR for JDK-8184334, conversions between different > integral types of the same size (along with enums) were performed > using > > reinterpret_cast(from_value) > > This was based on discussion from several months ago, referring to > C++03 3.10/15. However, re-reading that section in response to > discussion of the RFR for JDK-8184334, I now think that implementation > is not supported in many cases needed here, and indeed invokes > undefined behavior in those cases. In particular, where 3.10/15 says > > "- a type that is the signed or unsigned type corresponding to the > dynamic type of the object," That's true. In general, trying to do type conversion on lvalues is a bad idea. On the other hand, converting rvalues isn't such an awful sin: it has implementation-defined effects on all platforms, but the ones that are well-suited to Java (i.e. byted addressed, native 8-, 16-, 32-, and 64-bit types) have the behaviour we want. Or are you seriously worried that some of them will misbehave? > I interpret this to mean that if the dynamic type of an object is an > integral type of a given rank, the value may be accessed using an > lvalue of an integral type of the same rank and the opposite sign. > (Using the same rank and sign is already permitted, since that's the > same type.) I don't think it allows access using an lvalue of an > integral type with a different rank. That's right, it doesn't. > So, for example, a signed int value may be accessed via an unsigned > int lvalue. But access via a signed long lvalue is not permitted, > even if int and long have the same size. I don't think there is a > good way to perform the integral and enum conversions we need, > without invoking implementation-defined, unspecified, or undefined > behavior. Implementation-defined should be fine, surely. > ** The memcpy technique avoids such problems, but as noted above, is > known to be quite poorly optimized by some compilers. > > ** Using static_cast avoids any undefined behavior, but does have > cases of implementation-defined or unspecified behavior. (When > casting an unsigned value to a signed type, the result may be > implementation defined; 5.2.9/2 and 4.7/3. Right, but do we actually care about any compilers which misbehave when converting between signed and unsigned values of the same rank? More seriously, IMO: accessing a stored pointer to X as though it had been stored as a void* is certainly undefined behaviour, by the rule you point out above. It seems to me that you are worried about some things that are relatively minor, while ignoring things that are serious. If you followed the approach of never converting the type of the pointer to dest to some other point, *but instead converting the types of exchange_value and compare_value* everything would be fine. This whole thing could be done with no UB at all. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 18 13:23:40 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Aug 2017 14:23:40 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> This hunk was missing the parameter declaration of order. Fixed thusly: diff -r 214a94e9366c src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp --- a/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Mon Jul 17 12:11:32 2017 +0000 +++ b/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Fri Aug 18 14:22:19 2017 +0100 @@ -85,9 +85,12 @@ (volatile intptr_t*) dest); } -template T generic_cmpxchg(T exchange_value, volatile T* dest, - T compare_value, cmpxchg_memory_order order) -{ +template +template +inline T Atomic::PlatformCmpxchg::operator()(T exchange_value, + T volatile* dest, + T compare_value, + cmpxchg_memory_order order) const { if (order == memory_order_relaxed) { T value = compare_value; __atomic_compare_exchange(dest, &value, &exchange_value, /*weak*/false, @@ -98,17 +101,6 @@ } } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Aug 18 13:46:44 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Aug 2017 14:46:44 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> References: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> Message-ID: On 18/08/17 14:23, Andrew Haley wrote: > This hunk was missing the parameter declaration of order. Fixed thusly: > > diff -r 214a94e9366c src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp > --- a/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Mon Jul 17 12:11:32 2017 +0000 > +++ b/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Fri Aug 18 14:22:19 2017 +0100 > @@ -85,9 +85,12 @@ > (volatile intptr_t*) dest); > } > > -template T generic_cmpxchg(T exchange_value, volatile T* dest, > - T compare_value, cmpxchg_memory_order order) > -{ > +template > +template > +inline T Atomic::PlatformCmpxchg::operator()(T exchange_value, > + T volatile* dest, > + T compare_value, > + cmpxchg_memory_order order) const { > if (order == memory_order_relaxed) { > T value = compare_value; > __atomic_compare_exchange(dest, &value, &exchange_value, /*weak*/false, > @@ -98,17 +101,6 @@ > } > } I believe that has already been fixed in the latest version of the patch at: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03 regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri Aug 18 13:53:29 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Aug 2017 14:53:29 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> Message-ID: <88a04df0-fe29-3f3b-8cb7-081681dc229d@redhat.com> On 18/08/17 14:46, Andrew Dinn wrote: >> } > I believe that has already been fixed in the latest version of the patch at: > > http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03 You believe wrong! :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 18 14:08:44 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Aug 2017 15:08:44 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: On 18/08/17 14:21, Andrew Haley wrote: > More seriously, IMO: accessing a stored pointer to X as though it had > been stored as a void* is certainly undefined behaviour, by the rule > you point out above. It seems to me that you are worried about some > things that are relatively minor, while ignoring things that are > serious. > > If you followed the approach of never converting the type of the > pointer to dest to some other point, *but instead converting the types > of exchange_value and compare_value* everything would be fine. This > whole thing could be done with no UB at all. Looking at your patch again, I think that I've got this wrong: you're doing it the right way here: struct Atomic::CmpxchgImpl< T*, D*, U*, typename EnableIf::value && IsSame::type, typename RemoveCV::type>::value>::type> VALUE_OBJ_CLASS_SPEC { D* operator()(T* exchange_value, D* volatile* dest, U* compare_value, cmpxchg_memory_order order) const { // Allow derived to base conversion, and adding cv-qualifiers. D* new_value = exchange_value; // Don't care what the CV qualifiers for compare_value are, // but we need to match D* when calling platform support. D* old_value = const_cast(compare_value); My apologies. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Fri Aug 18 14:27:54 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 18 Aug 2017 16:27:54 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds Message-ID: Hi! Zero currently fails to build from source because the definitions from stdint.h are missing: In file included from /tmp/glaubitz/hs/hotspot/test/native/runtime/test_vmStructs.cpp:25:0: /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:71:3: error: ?int32_t? does not name a type int32_t isStatic; // Indicates whether following field is an offset or an address ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:72:3: error: ?uint64_t? does not name a type uint64_t offset; // Offset of field within structure; only used for nonstatic fields ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:81:3: error: ?int32_t? does not name a type int32_t isOopType; // Does this type represent an oop typedef? (i.e., "Method*" or ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:83:3: error: ?int32_t? does not name a type int32_t isIntegerType; // Does this type represent an integer type (of arbitrary size)? ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:84:3: error: ?int32_t? does not name a type int32_t isUnsigned; // If so, is it unsigned? ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:85:3: error: ?uint64_t? does not name a type uint64_t size; // Size, in bytes, of the type ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:90:3: error: ?int32_t? does not name a type int32_t value; // Value of constant ^ /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:95:3: error: ?uint64_t? does not name a type uint64_t value; // Value of constant ^ I'm asking for help because I haven't come up with a proper patch yet to fix this particular issue. It does not affect any of the other CPU targets (tested linux-x86, ppc64el, sparc), so this must be another case of neglected code. A work-around is to patch vmStructs.hpp to include stdint.h to fix the problem: diff -r 9a75c2f7bf06 src/share/vm/runtime/vmStructs.hpp --- a/src/share/vm/runtime/vmStructs.hpp Wed Aug 16 16:00:15 2017 +0200 +++ b/src/share/vm/runtime/vmStructs.hpp Fri Aug 18 16:13:38 2017 +0200 @@ -25,6 +25,8 @@ #ifndef SHARE_VM_RUNTIME_VMSTRUCTS_HPP #define SHARE_VM_RUNTIME_VMSTRUCTS_HPP +#include + #include "utilities/debug.hpp" #ifdef COMPILER1 #include "c1/c1_Runtime1.hpp" But that's obviously not the right fix because that would affect the other CPU targets as well. Any ideas? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From adinn at redhat.com Fri Aug 18 15:00:21 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Aug 2017 16:00:21 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <88a04df0-fe29-3f3b-8cb7-081681dc229d@redhat.com> References: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> <88a04df0-fe29-3f3b-8cb7-081681dc229d@redhat.com> Message-ID: <5968efe0-db62-4638-e60d-82f16812b0ce@redhat.com> On 18/08/17 14:53, Andrew Haley wrote: > On 18/08/17 14:46, Andrew Dinn wrote: >>> } >> I believe that has already been fixed in the latest version of the patch at: >> >> http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03 > > You believe wrong! :-) Indeed I do. I thought I had just successfully built the patched version only I forgot to apply the patch before building! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jesper.wilhelmsson at oracle.com Fri Aug 18 18:28:58 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 18 Aug 2017 20:28:58 +0200 Subject: jdk10/hs is OPEN Message-ID: Hi, jdk10/hs has finally been integrated to jdk10/jdk10. This means jdk10/hs is open for normal operations again. Thanks, /Jesper From kim.barrett at oracle.com Fri Aug 18 18:45:46 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Aug 2017 14:45:46 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> References: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> Message-ID: <33AFA2FF-305E-402A-A810-A055E4475ECF@oracle.com> > On Aug 18, 2017, at 9:23 AM, Andrew Haley wrote: > > This hunk was missing the parameter declaration of order. Fixed thusly: > > diff -r 214a94e9366c src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp > --- a/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Mon Jul 17 12:11:32 2017 +0000 > +++ b/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Fri Aug 18 14:22:19 2017 +0100 > @@ -85,9 +85,12 @@ > (volatile intptr_t*) dest); > } > > -template T generic_cmpxchg(T exchange_value, volatile T* dest, > - T compare_value, cmpxchg_memory_order order) > -{ > +template > +template > +inline T Atomic::PlatformCmpxchg::operator()(T exchange_value, > + T volatile* dest, > + T compare_value, > + cmpxchg_memory_order order) const { > if (order == memory_order_relaxed) { > T value = compare_value; > __atomic_compare_exchange(dest, &value, &exchange_value, /*weak*/false, > @@ -98,17 +101,6 @@ > } > } Drat. Thanks for finding this. It's a nuisance having to send out for review code that I've not been able to test at all. And yes, I know non-Oracle folks trying to deal with jprt have it *much* worse. Some new webrevs: Rename IntegerTypes to PrimitiveConversions. This is the change I said I was going to leave until the end. Looks like I could have done it earlier; webrev did a fine job with the moved file. full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03/ incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03.inc/ linux_aarch fix, rename test_integerTypes.cpp to test_primitiveConversions.cpp. full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.04/ incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.04.inc/ I'm hoping hotspot.04 will be the final version that I'll be handing off to Erik, as he returns from vacation and I start mine. I'm working on a change in a similar style for Atomic::add, and hope to send out an RFR later today. I'll be handing that off to Erik as well. From kim.barrett at oracle.com Fri Aug 18 19:02:26 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Aug 2017 15:02:26 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <1D040D16-DD08-4F89-8CDD-182F0F3CE5D8@oracle.com> > On Aug 18, 2017, at 10:08 AM, Andrew Haley wrote: > > On 18/08/17 14:21, Andrew Haley wrote: >> More seriously, IMO: accessing a stored pointer to X as though it had >> been stored as a void* is certainly undefined behaviour, by the rule >> you point out above. It seems to me that you are worried about some >> things that are relatively minor, while ignoring things that are >> serious. >> >> If you followed the approach of never converting the type of the >> pointer to dest to some other point, *but instead converting the types >> of exchange_value and compare_value* everything would be fine. This >> whole thing could be done with no UB at all. > > Looking at your patch again, I think that I've got this wrong: you're > doing it the right way here: > > struct Atomic::CmpxchgImpl< > T*, D*, U*, > typename EnableIf::value && > IsSame::type, > typename RemoveCV::type>::value>::type> > VALUE_OBJ_CLASS_SPEC > { > D* operator()(T* exchange_value, D* volatile* dest, U* compare_value, > cmpxchg_memory_order order) const { > // Allow derived to base conversion, and adding cv-qualifiers. > D* new_value = exchange_value; > // Don't care what the CV qualifiers for compare_value are, > // but we need to match D* when calling platform support. > D* old_value = const_cast(compare_value); > > My apologies. Thanks. The questionable conversions are now confined to platform-specific code, for those platforms that have made the choice to use a fixed-type out-of-line helper function as the ultimate implementation. For platforms that use type-generic compiler intrinsics (linux_aarch64, for example), or type-generic inline assembler (several), such conversions are not needed. From glaubitz at physik.fu-berlin.de Fri Aug 18 19:47:16 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 18 Aug 2017 21:47:16 +0200 Subject: [RFR]: 8186461: zero: Don't use PowerPC FPU instructions on targets without FPU Message-ID: For 32-Bit PowerPC, zero contains a platform-specific implementation of atomic_copy64() which uses inline-assembly with FPU instructions to perform a 64-bit atomic copy. Unfortunately, the inline assembly with the FPU instructions is unconditionally enabled on all 32-Bit PowerPC machines which means that the code in question will fail to build on 32-Bit PowerPC machines without an FPU. On such systems are for example the PowerPC e500 CPU, gcc will define the macro __NO_FPRS__: root at atlantis:~> echo | gcc -E -dM - |grep -i FPR #define __NO_FPRS__ 1 root at atlantis:~> Thus, in order to make sure zero builds on these systems without problems, we should not just test whether PPC32 is defined but also that __NO_FPRS__ is not defined before enabling the inline assembly with FPU instructions. Bug is described in [1] with an attached patch. Adrian > [1] https://bugs.openjdk.java.net/browse/JDK-8186461 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Fri Aug 18 19:58:14 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Aug 2017 15:58:14 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: > On Aug 18, 2017, at 9:21 AM, Andrew Haley wrote: > > On 14/08/17 03:41, Kim Barrett wrote: >> * Conversions between integers and floating point values are >> supported. It was suggested during the discussion of the RFR for >> JDK-8184334 that this was not needed, as there are no uses of >> atomic/ordered floating point values in Hotspot. However, I'm told >> VarHandles may include atomic floating point values. > > I am very strongly opposed to checking unused code into HotSpot. Apart > from the obvious obervation that it's impossible to test, it makes far > more sense to add it if it is ever needed. Maybe you overlooked this, buried in this long thread? --- I was about to agree to removal of floating point from here. Then I remembered the jmumble_cast suite of functions in globalDefinitions.hpp. Erik and I had discussed a unification, with the jmumble_cast functions built on IntegerTypes. We can't presently do that, because of include dependencies, but that's probably fixable. We see this utility as having application beyond Atomic &etc template reimplementation. --- So the float conversion support in PrimitiveConversions is presently unused. There are some tests for it though (unlike the jmumble_cast functions). And we intend to use it, just haven't gotten there yet. Fixing the include dependencies isn't some completely hand-wavy dream. There's been work done in that direction, and more is intended. globalDefinitions has become (or maybe always was) a dumping ground for lots of random stuff. Because of its place near the root of all includes, that random stuff can't use other things as part of the implementation. I recently flipped the dependency order for debug.hpp and globalDefinitions.hpp so we could finally use the assert macro and friends in globalDefinitions.hpp. The recently created align.hpp and arena.hpp were additional steps along the way. Maybe the jmumble_casts will be treated in a similar fashion. There are presently 27 files out of about 2600 C++ source files in Hotspot that use those functions, which hardly seems like a "global" need. BTW, the conversion technique presently used by the jmumble_cast suite is explicitly called out by gcc documentation as still being undefined behavior, even with the involvement of unions. From gerard.ziemski at oracle.com Fri Aug 18 20:51:51 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 18 Aug 2017 15:51:51 -0500 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <66d3f1b0-3c1e-65c1-8d4d-72b9e52bac08@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> <66d3f1b0-3c1e-65c1-8d4d-72b9e52bac08@oracle.com> Message-ID: <8317EF1E-1321-48A8-9694-C49EBFD9CB9B@oracle.com> Thank you David for clarifications. > On Aug 17, 2017, at 4:38 PM, David Holmes wrote: > > Hi Gerard, > > On 18/08/2017 12:34 AM, Gerard Ziemski wrote: >> hi David, >> Thank you for the review! >>> On Aug 16, 2017, at 8:09 PM, David Holmes wrote: >>> >>> Hi Gerard, >>> >>> On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >>>> hi all, >>>> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >>>> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >>> >>> That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? >> So normally for -XX flags it?s deprecated -> obsolete -> remove, correct? > > Yes. > >> I?m not sure about -X flag either, but it was explained to me that making -Xprof flag work in jdk10 would take considerable amount of effort, so instead of supporting already deprecated flag, we simply remove it - it was officially deprecated in jdk9 using JDK-8176098. > > Obsoleting the flag still allows removal of all the functionality, it just means use of the flag itself doesn't produce an error, but a warning telling you the flag is obsolete and has no effect and will be removed in the future. I have obsoleted the flag, so it?s still accepted, but it will now print a warning ?Ignoring option -Xprof; support was removed in 10.0" > >>>> The changes are XL, but straightforward. >>>> If anyone knows of any other remnants that should still be removed, please let me know. >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >>>> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot >>> >>> There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: >>> >>> src/cpu/sparc/vm/macroAssembler_sparc.cpp >>> >>> - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) >>> + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) >>> >>> Are we still propagating Lmethod here? If so why? Ditto for other places in the file. >> I couldn?t figure out whether we still needed to propagate the Lmethod, and assumed that it was safe to leave it in - the extra code is saving a register, which seems harmless to me and there are other places in the file where we do it. > > This needs to be assessed by compiler folk. If we leave in code that was only needed for flat-profiler but remove all such comments then no-one will know why we are doing something. If this code is needed then the comment should reflect why; if not needed it should be removed. I will ask on the compiler mailing list about it. > >>> In: src/share/vm/runtime/thread.cpp >>> >>> - // eventually timeout, but that takes time. Making this wait a >>> - // suspend-equivalent condition solves that timeout problem. >>> - // >>> Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, >>> Mutex::_as_suspend_equivalent_flag); >>> >>> So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). >> I wasn?t completely sure about this, and was going back and forth on this, but I figured it was safer to leave it in, since there are code paths that still use suspend/resume mechanism, i.e. the deprecated java.lang.Thread.suspend()/resume() APIs. >> Are we sure it?s OK to remove these locks? > > As per other email it is only the use of the flag that could be removed, if it truly only was needed due to flat-profiler interactions. But looking at the full block of code in context it seems that the need to be "suspend equivalent" was already part of this logic and that that was sufficient to fix the flat-profiler issue. So it looks like the code should remain as-is. Left the code alone. > >>> --- >>> >>> I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: >>> >>> -// within hotspot. Now there is a single use-case for this: >>> -// - calling get_thread_pc() on the VMThread by the flat-profiler task >>> -// that runs in the watcher thread. >>> +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: >>> +// - Forte Analyzer: AsyncGetCallTrace() >>> +// - StackBanging: get_frame_at_stack_banging_point() >>> >>> I don't see any use of low-level suspend/resume with the two cases you added ?? >> Those cases depend on ?ucontext? being set up using the resume_clear_context()/suspend_save_context() APIs, which are part of the resume/suspend mechanism - I will try to re-do the comment. > > That comment pertained to actual use of the low-level suspend/resume mechanism which is not used by AGCT or stack-banging. I would just terminate the comment at "within hotspot" and not add any additional text. I would really like to keep my 2nd attempt at the comment in - it identifies who is still using the suspend/resume mechanism, with a note about user context, in case someone is tempted to remove it (like I originally did before realizing it?s still needed) Rev 2 webrev coming up shortly? cheers From gerard.ziemski at oracle.com Fri Aug 18 21:00:28 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 18 Aug 2017 16:00:28 -0500 Subject: RFR 8173715 (rev2): Remove Flat Profiler Message-ID: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> hi all, The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it?s the time to remove the code and obsolete the -Xprof flag. Changes from rev1 to address David?s feedback: - obsoleted the flag (it?s still accepted, but ignored) - fixed copyright year in "src/os_cpu/linux_s390/vm/thread_linux_s390.hpp? - improved comment about the signal based suspend/resume mechanism in "os_*.cpp? files - removed entire comment from "src/os/solaris/vm/osThread_solaris.hpp" issue: https://bugs.openjdk.java.net/browse/JDK-8173715 webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot From david.holmes at oracle.com Fri Aug 18 22:35:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Aug 2017 08:35:59 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: Message-ID: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> Hi Adrian, On 19/08/2017 12:27 AM, John Paul Adrian Glaubitz wrote: > Hi! > > Zero currently fails to build from source because the definitions from > stdint.h are missing: > > In file included from > /tmp/glaubitz/hs/hotspot/test/native/runtime/test_vmStructs.cpp:25:0: > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:71:3: error: > ?int32_t? does not name a type > ?? int32_t isStatic; // Indicates whether following field is an offset > or an address > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:72:3: error: > ?uint64_t? does not name a type > ?? uint64_t offset; // Offset of field within structure; only used for > nonstatic fields > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:81:3: error: > ?int32_t? does not name a type > ?? int32_t isOopType; // Does this type represent an oop typedef? > (i.e., "Method*" or > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:83:3: error: > ?int32_t? does not name a type > ?? int32_t isIntegerType; // Does this type represent an integer type > (of arbitrary size)? > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:84:3: error: > ?int32_t? does not name a type > ?? int32_t isUnsigned; // If so, is it unsigned? > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:85:3: error: > ?uint64_t? does not name a type > ?? uint64_t size; // Size, in bytes, of the type > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:90:3: error: > ?int32_t? does not name a type > ?? int32_t value; // Value of constant > ?? ^ > /tmp/glaubitz/hs/hotspot/src/share/vm/runtime/vmStructs.hpp:95:3: error: > ?uint64_t? does not name a type > ?? uint64_t value; // Value of constant > ?? ^ > > I'm asking for help because I haven't come up with a proper patch yet to > fix this particular issue. > It does not affect any of the other CPU targets (tested linux-x86, > ppc64el, sparc), so this must > be another case of neglected code. > > A work-around is to patch vmStructs.hpp to include stdint.h to fix the > problem: > > diff -r 9a75c2f7bf06 src/share/vm/runtime/vmStructs.hpp > --- a/src/share/vm/runtime/vmStructs.hpp Wed Aug 16 16:00:15 2017 +0200 > +++ b/src/share/vm/runtime/vmStructs.hpp Fri Aug 18 16:13:38 2017 +0200 > @@ -25,6 +25,8 @@ > ?#ifndef SHARE_VM_RUNTIME_VMSTRUCTS_HPP > ?#define SHARE_VM_RUNTIME_VMSTRUCTS_HPP > > +#include > + > ?#include "utilities/debug.hpp" > ?#ifdef COMPILER1 > ?#include "c1/c1_Runtime1.hpp" > > But that's obviously not the right fix because that would affect the > other CPU targets as well. > > Any ideas? There is a bug in the test file: test/native/runtime/test_vmStructs.cpp #include "precompiled.hpp" #include "runtime/vmStructs.hpp" #include "utilities/macros.hpp" #include "unittest.hpp" #if INCLUDE_VM_STRUCTS If we aren't including VM structs then we probably shouldn't be #include'ing vmStructs.hpp! The #include needs to move inside the guard. Cheers, David > Adrian > From david.holmes at oracle.com Fri Aug 18 22:39:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Aug 2017 08:39:49 +1000 Subject: [RFR]: 8186461: zero: Don't use PowerPC FPU instructions on targets without FPU In-Reply-To: References: Message-ID: <1ddedf31-0c3f-e312-3a3b-a5218d769d24@oracle.com> Hi Adrian, On 19/08/2017 5:47 AM, John Paul Adrian Glaubitz wrote: > For 32-Bit PowerPC, zero contains a platform-specific implementation of > atomic_copy64() which uses inline-assembly with FPU instructions to > perform a 64-bit atomic copy. I have a recollection of someone else working on atomic_copy64 very recently ... there may already be a bug for this ... Will try to track it down by Monday. David > Unfortunately, the inline assembly with the FPU instructions is > unconditionally enabled on all 32-Bit PowerPC machines which means that > the code in question will fail to build on 32-Bit PowerPC machines without > an FPU. > > On such systems are for example the PowerPC e500 CPU, gcc will define > the macro __NO_FPRS__: > > root at atlantis:~> echo | gcc -E -dM - |grep -i FPR > #define __NO_FPRS__ 1 > root at atlantis:~> > > Thus, in order to make sure zero builds on these systems without problems, > we should not just test whether PPC32 is defined but also that __NO_FPRS__ > is not defined before enabling the inline assembly with FPU instructions. > > Bug is described in [1] with an attached patch. > > Adrian > >> [1] https://bugs.openjdk.java.net/browse/JDK-8186461 > From glaubitz at physik.fu-berlin.de Fri Aug 18 22:41:15 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 19 Aug 2017 00:41:15 +0200 Subject: [RFR]: 8186461: zero: Don't use PowerPC FPU instructions on targets without FPU In-Reply-To: <1ddedf31-0c3f-e312-3a3b-a5218d769d24@oracle.com> References: <1ddedf31-0c3f-e312-3a3b-a5218d769d24@oracle.com> Message-ID: <84513ccf-e596-be9a-063e-fd55a38fc9a1@physik.fu-berlin.de> On 08/19/2017 12:39 AM, David Holmes wrote: > I have a recollection of someone else working on atomic_copy64 > very recently ... there may already be a bug for this ... Andrew was working on it, see [1]. Adrian > [1] http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/2e969fa1b29c -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri Aug 18 22:49:21 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 19 Aug 2017 00:49:21 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> Message-ID: <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> Hi! On 08/19/2017 12:35 AM, David Holmes wrote: > There is a bug in the test file: > > test/native/runtime/test_vmStructs.cpp > > #include "precompiled.hpp" > #include "runtime/vmStructs.hpp" > #include "utilities/macros.hpp" > #include "unittest.hpp" > > #if INCLUDE_VM_STRUCTS > > If we aren't including VM structs then we probably shouldn't be #include'ing vmStructs.hpp! > > The #include needs to move inside the guard. That didn't help, unfortunately. Still fails with the same problem :(. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Fri Aug 18 23:54:46 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Aug 2017 19:54:46 -0400 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> Message-ID: <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> > On Aug 18, 2017, at 6:49 PM, John Paul Adrian Glaubitz wrote: > > Hi! > > On 08/19/2017 12:35 AM, David Holmes wrote: >> There is a bug in the test file: >> >> test/native/runtime/test_vmStructs.cpp >> >> #include "precompiled.hpp" >> #include "runtime/vmStructs.hpp" >> #include "utilities/macros.hpp" >> #include "unittest.hpp" >> >> #if INCLUDE_VM_STRUCTS >> >> If we aren't including VM structs then we probably shouldn't be #include'ing vmStructs.hpp! >> >> The #include needs to move inside the guard. > > That didn't help, unfortunately. Still fails with the same problem :(. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Presumably that means INCLUDE_VM_STRUCTS is true. The include should still be moved inside the conditional guard. But I think the problem is indeed with vmStructs.hpp itself. vmStructs.hpp has this for #includes: #include "utilities/debug.hpp" #ifdef COMPILER1 #include "c1/c1_Runtime1.hpp" #endif debug.hpp was recently changed to have fairly minimal #includes. In particular, it no longer #includes globalDefinitions.hpp, which is where most of our code gets and the like from. I think zero doesn't define COMPILER1; zero only uses the interpreter, not any of the compilers. So for zero, it used to get indirectly from globalDefinitions.hpp via debug.hpp, but no longer does. And when COMPILER1 is defined (which it normally is, except for zero), I bet there's an indirect include of globalDefinitions.hpp from there. I think adding an #include of to vmStructs.hpp is reasonable. Alternatively, #include globalDefinitions.hpp, though I'm personally not a fan of that file. From kim.barrett at oracle.com Fri Aug 18 23:57:43 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Aug 2017 19:57:43 -0400 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> Message-ID: <69CE1CB3-559B-4773-9963-859816EE688E@oracle.com> > On Aug 18, 2017, at 7:54 PM, Kim Barrett wrote: > I think adding an #include of to vmStructs.hpp is > reasonable. Alternatively, #include globalDefinitions.hpp, though I'm > personally not a fan of that file. #include globalDefinitions.hpp is stylistically consistent with other hotspot code though. So I think you should go with that. From david.holmes at oracle.com Sat Aug 19 00:14:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Aug 2017 10:14:15 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <69CE1CB3-559B-4773-9963-859816EE688E@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <69CE1CB3-559B-4773-9963-859816EE688E@oracle.com> Message-ID: On 19/08/2017 9:57 AM, Kim Barrett wrote: >> On Aug 18, 2017, at 7:54 PM, Kim Barrett wrote: >> I think adding an #include of to vmStructs.hpp is >> reasonable. Alternatively, #include globalDefinitions.hpp, though I'm >> personally not a fan of that file. > > #include globalDefinitions.hpp is stylistically consistent with other hotspot code though. > So I think you should go with that. I was going to support your "I think adding an #include of to vmStructs.hpp is reasonable." :) I think either way is fine. David From glaubitz at physik.fu-berlin.de Sat Aug 19 00:40:36 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 19 Aug 2017 02:40:36 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> Message-ID: <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> On 08/19/2017 01:54 AM, Kim Barrett wrote: > Presumably that means INCLUDE_VM_STRUCTS is true. Right. > The include should still be moved inside the conditional guard. Ok. But that should go into a different bug report then, I guess :-). > But I think the > problem is indeed with vmStructs.hpp itself. > > vmStructs.hpp has this for #includes: > > #include "utilities/debug.hpp" > #ifdef COMPILER1 > #include "c1/c1_Runtime1.hpp" > #endif > > debug.hpp was recently changed to have fairly minimal #includes. In > particular, it no longer #includes globalDefinitions.hpp, which is > where most of our code gets and the like from. Aha. I was already looking where globalDefinitions.hpp was coming from because I had found that globalDefintions.hpp was the place where stdint.h was included but I couldn't find it. > I think zero doesn't define COMPILER1; zero only uses the interpreter, > not any of the compilers. Makes absolutely sense now. Thanks for the quick heads-up. > So for zero, it used to get indirectly from > globalDefinitions.hpp via debug.hpp, but no longer does. And when > COMPILER1 is defined (which it normally is, except for zero), I bet > there's an indirect include of globalDefinitions.hpp from there. > > I think adding an #include of to vmStructs.hpp is > reasonable. Alternatively, #include globalDefinitions.hpp, though I'm > personally not a fan of that file. What about guarding it: diff -r 9a75c2f7bf06 src/share/vm/runtime/vmStructs.hpp --- a/src/share/vm/runtime/vmStructs.hpp Wed Aug 16 16:00:15 2017 +0200 +++ b/src/share/vm/runtime/vmStructs.hpp Sat Aug 19 02:39:41 2017 +0200 @@ -28,6 +28,8 @@ #include "utilities/debug.hpp" #ifdef COMPILER1 #include "c1/c1_Runtime1.hpp" +#else +#include "utilities/globalDefinitions.hpp" #endif // This table encapsulates the debugging information required by the I have verified that zero builds fine with that change. I know the #else is not really necessary here but it might make the code more readable. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Sat Aug 19 02:16:07 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 18 Aug 2017 22:16:07 -0400 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> Message-ID: <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> > On Aug 18, 2017, at 8:40 PM, John Paul Adrian Glaubitz wrote: >> I think adding an #include of to vmStructs.hpp is >> reasonable. Alternatively, #include globalDefinitions.hpp, though I'm >> personally not a fan of that file. > > What about guarding it: > > diff -r 9a75c2f7bf06 src/share/vm/runtime/vmStructs.hpp > --- a/src/share/vm/runtime/vmStructs.hpp Wed Aug 16 16:00:15 2017 +0200 > +++ b/src/share/vm/runtime/vmStructs.hpp Sat Aug 19 02:39:41 2017 +0200 > @@ -28,6 +28,8 @@ > #include "utilities/debug.hpp" > #ifdef COMPILER1 > #include "c1/c1_Runtime1.hpp" > +#else > +#include "utilities/globalDefinitions.hpp" > #endif > > // This table encapsulates the debugging information required by the > > I have verified that zero builds fine with that change. I know the #else > is not really necessary here but it might make the code more readable. I would prefer it be included unconditionally, rather than only if !COMPILER1. That is, don?t depend on COMPILER1 bringing that stuff in. From david.holmes at oracle.com Sat Aug 19 05:02:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Aug 2017 15:02:44 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> Message-ID: <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> On 19/08/2017 12:16 PM, Kim Barrett wrote: >> On Aug 18, 2017, at 8:40 PM, John Paul Adrian Glaubitz wrote: >>> I think adding an #include of to vmStructs.hpp is >>> reasonable. Alternatively, #include globalDefinitions.hpp, though I'm >>> personally not a fan of that file. >> >> What about guarding it: >> >> diff -r 9a75c2f7bf06 src/share/vm/runtime/vmStructs.hpp >> --- a/src/share/vm/runtime/vmStructs.hpp Wed Aug 16 16:00:15 2017 +0200 >> +++ b/src/share/vm/runtime/vmStructs.hpp Sat Aug 19 02:39:41 2017 +0200 >> @@ -28,6 +28,8 @@ >> #include "utilities/debug.hpp" >> #ifdef COMPILER1 >> #include "c1/c1_Runtime1.hpp" >> +#else >> +#include "utilities/globalDefinitions.hpp" >> #endif >> >> // This table encapsulates the debugging information required by the >> >> I have verified that zero builds fine with that change. I know the #else >> is not really necessary here but it might make the code more readable. > > I would prefer it be included unconditionally, rather than only if !COMPILER1. > > That is, don?t depend on COMPILER1 bringing that stuff in. Agreed. Implicit dependencies are bad. Also: >> The include should still be moved inside the conditional guard. > > Ok. But that should go into a different bug report then, I guess :-). It is fine to include it with this change while you are in the area - a lot of cleanups happen that way. Otherwise there is too much overhead in getting things fixed. :) Thanks, David From aph at redhat.com Sat Aug 19 07:57:43 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Aug 2017 08:57:43 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: On 18/08/17 20:58, Kim Barrett wrote: >> On Aug 18, 2017, at 9:21 AM, Andrew Haley wrote: >> >> On 14/08/17 03:41, Kim Barrett wrote: >>> * Conversions between integers and floating point values are >>> supported. It was suggested during the discussion of the RFR for >>> JDK-8184334 that this was not needed, as there are no uses of >>> atomic/ordered floating point values in Hotspot. However, I'm told >>> VarHandles may include atomic floating point values. >> >> I am very strongly opposed to checking unused code into HotSpot. Apart >> from the obvious obervation that it's impossible to test, it makes far >> more sense to add it if it is ever needed. > > Maybe you overlooked this, buried in this long thread? > > --- > I was about to agree to removal of floating point from here. Then I > remembered the jmumble_cast suite of functions in > globalDefinitions.hpp. Erik and I had discussed a unification, with > the jmumble_cast functions built on IntegerTypes. We can't presently > do that, because of include dependencies, but that's probably fixable. > We see this utility as having application beyond Atomic &etc template > reimplementation. > --- > > So the float conversion support in PrimitiveConversions is presently > unused. There are some tests for it though (unlike the jmumble_cast > functions). And we intend to use it, just haven't gotten there yet. Umm, okay. > BTW, the conversion technique presently used by the jmumble_cast suite > is explicitly called out by gcc documentation as still being undefined > behavior, even with the involvement of unions. Umm, what? Can you explain this a little more? I'd have to search for what jumble_cast might be. The union trick is well defined by GCC. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Aug 19 09:22:55 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Aug 2017 10:22:55 +0100 Subject: [RFR]: 8186461: zero: Don't use PowerPC FPU instructions on targets without FPU In-Reply-To: References: Message-ID: <2b3d4224-72dc-9798-9d45-51b279db8807@redhat.com> On 18/08/17 20:47, John Paul Adrian Glaubitz wrote: > Bug is described in [1] with an attached patch. > > Adrian > >> [1] https://bugs.openjdk.java.net/browse/JDK-8186461 That does not look right. Surely we need an alternative implementation? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Sat Aug 19 10:31:44 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 19 Aug 2017 12:31:44 +0200 Subject: [RFR]: 8186461: zero: Don't use PowerPC FPU instructions on targets without FPU In-Reply-To: <2b3d4224-72dc-9798-9d45-51b279db8807@redhat.com> References: <2b3d4224-72dc-9798-9d45-51b279db8807@redhat.com> Message-ID: On 08/19/2017 11:22 AM, Andrew Haley wrote: > That does not look right. Surely we need an alternative > implementation? Those machines in question are usually single-CPU, so we probably don't need any particular inline assembly to perform atomic copy on these machines. However, there are actually machines - I have two of these - which have a dual-core configuration. So, using inline assembly to perform the atomic operation might make sense here. While these CPUs don't actually have an FPU, they have something called SPE instructions which are some sort of FPU replacement. I will have a closer look later to figure out whether I can find something in the data sheet [1]. See [1] and [2]. Adrian > [1] http://www.nxp.com/docs/en/reference-manual/E500CORERM.pdf > [2] https://en.wikipedia.org/wiki/PowerPC_e500 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Sat Aug 19 14:57:33 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 19 Aug 2017 10:57:33 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: > On Aug 19, 2017, at 3:57 AM, Andrew Haley wrote: > > On 18/08/17 20:58, Kim Barrett wrote: >> BTW, the conversion technique presently used by the jmumble_cast suite >> is explicitly called out by gcc documentation as still being undefined >> behavior, even with the involvement of unions. > > Umm, what? Can you explain this a little more? I'd have to search > for what jumble_cast might be. The union trick is well defined by > GCC. jint_cast, jdouble_cast, &etc, in globalDefinitions.hpp around line 520 right now. For example: typedef union { jfloat f; jint i; } FloatIntConv; jint jint_cast(jfloat x) { return ((FloatIntConv*)&x)->i; } That's *not* the union trick. https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Optimize-Options.html#index-fstrict-aliasing Similarly, access by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior, even if the cast uses a union type, e.g.: . From aph at redhat.com Sat Aug 19 15:40:59 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Aug 2017 16:40:59 +0100 Subject: [RFR]: 8186461: zero: Don't use PowerPC FPU instructions on targets without FPU In-Reply-To: References: <2b3d4224-72dc-9798-9d45-51b279db8807@redhat.com> Message-ID: On 19/08/17 11:31, John Paul Adrian Glaubitz wrote: > On 08/19/2017 11:22 AM, Andrew Haley wrote: >> That does not look right. Surely we need an alternative >> implementation? > > Those machines in question are usually single-CPU, so we probably > don't need any particular inline assembly to perform atomic copy > on these machines. I think we do. Can't descheduling happen at any time? > However, there are actually machines - I have two of these - which > have a dual-core configuration. So, using inline assembly to perform > the atomic operation might make sense here. > > While these CPUs don't actually have an FPU, they have something > called SPE instructions which are some sort of FPU replacement. > > I will have a closer look later to figure out whether I can find > something in the data sheet [1]. OK, sounds good. Otherwise we can just use a lock. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Aug 19 16:18:43 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Aug 2017 17:18:43 +0100 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: Message-ID: <41c65cf4-ab84-ac66-76f2-c1bb6cd4f666@redhat.com> On 19/08/17 15:57, Kim Barrett wrote: >> On Aug 19, 2017, at 3:57 AM, Andrew Haley wrote: >> >> On 18/08/17 20:58, Kim Barrett wrote: >>> BTW, the conversion technique presently used by the jmumble_cast suite >>> is explicitly called out by gcc documentation as still being undefined >>> behavior, even with the involvement of unions. >> >> Umm, what? Can you explain this a little more? I'd have to search >> for what jumble_cast might be. The union trick is well defined by >> GCC. > > jint_cast, jdouble_cast, &etc, in globalDefinitions.hpp around line > 520 right now. For example: > > typedef union { jfloat f; jint i; } FloatIntConv; > jint jint_cast(jfloat x) { return ((FloatIntConv*)&x)->i; } > > That's *not* the union trick. Indeed not, that certainly isn't supported. Shame, it's so close... :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Sun Aug 20 06:16:30 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Aug 2017 02:16:30 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates Message-ID: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> Please review this change to Atomic::add, making it a function template with a per-platform underlying implementation. This change is similar to 8186166: "Generalize Atomic::cmpxchg with templates", with similar goals and taking a similar approach. This change deprecates add_ptr. Followup changes will convert existing uses of cmpxchg_ptr and eventually remove it. Followup changes will also update uses of cmpxchg that can be simplified because of the generalized API. Only changes to usage that were required by the new implementation have been made so far. The add function calls private Atomic::AddImpl, to select among several cases, based on the argument types. Each case performs some checking and possibly conversion to reach a standard form of the arguments (or fail and report a compile time error), which are then passed to private Atomic::PlatformAdd. Only safe conversions of the first (add_value) argument are made by the AddImpl layer. add_value must be integral, and is never narrowed. dest's value type must be either integral or a pointer type. When both are integral, they must be of the same signedness. If smaller, add_value will be promited to the same size as dest's value type. The PlatformAdd class is provided by each platform, and performs additional case analysis to generate the appropriate code for the platform. Most PlatformAdd implementations use one of two helper base classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide common parts of the implementation in terms of a support function provided by the derived PlatformAdd, accessed using CRTP. This change involves modifications to all of the existing platform implementations of Atomic::add. I've updated all of the platforms, but only tested those supported by Oracle. I'll need help from the various platform maintainers to check and test my changes. Changes to files can be categorized as follows: [No new metaprogramming tools!] Change add to a template: atomic.hpp Oracle-supported platforms: atomic_bsd_x86.hpp - 64bit only atomic_linux_arm.hpp atomic_linux_x86.hpp atomic_solaris_sparc.hpp solaris_sparc.il atomic_solaris_x86.hpp atomic_windows_x86 Non-Oracle platform changes: atomic_aix_ppc.hpp atomic_bsd_x86.hpp - 32bit atomic_bsd_zero.hpp atomic_linux_aarch.hpp atomic_linux_ppc.hpp atomic_linux_s390.hpp atomic_linux_sparc.hpp atomic_linux_zero.hpp Usage changes required by API change: g1CardLiveData.cpp g1ConcurrentMark.cpp g1HotCardCache.cpp g1HotCardCache.hpp g1RemSet.cpp symbol.cpp mallocTracker.hpp A few specific items: - atomic_linux_arm.hpp Neither add variant has "cc" in the clobbers list, even though the condition codes are modified. That seems like a pre-existing bug. - atomic_linux_sparc.hpp Neither add variant has "cc" in the clobbers list, even though the condition codes are modified. That seems like a pre-existing bug. The 32-bit add was using intptr_t as the rv type. Probably a harmless copy-paste mistake. Now using template parameter type. Uses hard-coded machine registers and assumes the inline-asm processing assigns the values to the corresponding machine registers, even though the given constraints are just generic register requests. I don't understand how this can work. - atomic_solaris_sparc.hpp Atomic::add was implemented using asm code in solaris_sparc.il. I was going to change it to use gcc-style inline-asm, but the linux_sparc version wasn't helpful this time (unlike for cmpxchg) (see above). Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much simpler code, and should be no less efficient, assuming the compiler does it's job. CR: https://bugs.openjdk.java.net/browse/JDK-8186476 Webrev: http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ Testing: Ad hoc hotspot nightly test. From kim.barrett at oracle.com Sun Aug 20 06:19:38 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Aug 2017 02:19:38 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> Message-ID: <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> > On Aug 20, 2017, at 2:16 AM, Kim Barrett wrote: > > Please review this change to Atomic::add, making it a function > template with a per-platform underlying implementation. > > This change is similar to 8186166: "Generalize Atomic::cmpxchg with > templates", with similar goals and taking a similar approach. > > [?] > CR: > https://bugs.openjdk.java.net/browse/JDK-8186476 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ > > Testing: > Ad hoc hotspot nightly test. I forgot to mention that this change is based on the 8186166 hotspot.04 change, which has not yet been pushed. I?m leaving that to Erik, as well as handing this change off to him. From uschindler at apache.org Sun Aug 20 19:55:38 2017 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 20 Aug 2017 21:55:38 +0200 Subject: -Xlog,..,file=filename with absolute path on windows? Message-ID: <026f01d319ee$4e62b940$eb282bc0$@apache.org> Hi, I am currently adapting Apache Solr's startup scripts for Java 9. Linux was already done at the beginning of this year and works perfectly, but Windows brings some problems. I already fixed version number parsing, but I stumbled on the following: In the Windows ".cmd" shell script it uses the following to enable Garbage collection logging to a separate file, if Java 9 is detected: set GC_LOG_OPTS="-Xlog:gc*:file=!SOLR_LOGS_DIR!\solr_gc.log:time,uptime:filecount=9,filesize=20000" The problem is now that "!SOLR_LOGS_DIR!" is already expanded to an absolute Windows Path by the shell and therefore starts with "C:\". The problem is now the colon, which breaks the log parsing. When Java 9 starts it exits with the following parsing error: Invalid -Xlog option '-Xlog:gc*:file=C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr_gc.log:time,uptime:filecount=9,filesize=20000' If I replace with a simple file name, without path/drive letter it works. How to escape the colon in the drive letter correctly, to me this looks like a bummer? Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From david.holmes at oracle.com Mon Aug 21 01:19:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Aug 2017 11:19:51 +1000 Subject: -Xlog,..,file=filename with absolute path on windows? In-Reply-To: <026f01d319ee$4e62b940$eb282bc0$@apache.org> References: <026f01d319ee$4e62b940$eb282bc0$@apache.org> Message-ID: Hi Uwe, On 21/08/2017 5:55 AM, Uwe Schindler wrote: > Hi, > > I am currently adapting Apache Solr's startup scripts for Java 9. Linux was already done at the beginning of this year and works perfectly, but Windows brings some problems. I already fixed version number parsing, but I stumbled on the following: In the Windows ".cmd" shell script it uses the following to enable Garbage collection logging to a separate file, if Java 9 is detected: > set GC_LOG_OPTS="-Xlog:gc*:file=!SOLR_LOGS_DIR!\solr_gc.log:time,uptime:filecount=9,filesize=20000" > > The problem is now that "!SOLR_LOGS_DIR!" is already expanded to an absolute Windows Path by the shell and therefore starts with "C:\". The problem is now the colon, which breaks the log parsing. When Java 9 starts it exits with the following parsing error: > Invalid -Xlog option '-Xlog:gc*:file=C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr_gc.log:time,uptime:filecount=9,filesize=20000' > > If I replace with a simple file name, without path/drive letter it works. How to escape the colon in the drive letter correctly, to me this looks like a bummer? You can fix this by quoting the filename, with shell escapes eg: java -Xlog:gc*:file=\"C:\solr_gc.log\":time,uptime:filecount=9 -version Doing that within an env var may be a bit trickier. David > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > From uschindler at apache.org Mon Aug 21 06:07:07 2017 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 21 Aug 2017 08:07:07 +0200 Subject: -Xlog,..,file=filename with absolute path on windows? In-Reply-To: References: <026f01d319ee$4e62b940$eb282bc0$@apache.org> Message-ID: <034301d31a43$ba5e9c90$2f1bd5b0$@apache.org> Hi David, > Hi Uwe, > > On 21/08/2017 5:55 AM, Uwe Schindler wrote: > > Hi, > > > > I am currently adapting Apache Solr's startup scripts for Java 9. Linux was > already done at the beginning of this year and works perfectly, but Windows > brings some problems. I already fixed version number parsing, but I > stumbled on the following: In the Windows ".cmd" shell script it uses the > following to enable Garbage collection logging to a separate file, if Java 9 is > detected: > > set GC_LOG_OPTS="- > Xlog:gc*:file=!SOLR_LOGS_DIR!\solr_gc.log:time,uptime:filecount=9,filesize=2 > 0000" > > > > The problem is now that "!SOLR_LOGS_DIR!" is already expanded to an > absolute Windows Path by the shell and therefore starts with "C:\". The > problem is now the colon, which breaks the log parsing. When Java 9 starts it > exits with the following parsing error: > > Invalid -Xlog option '-Xlog:gc*:file=C:\Users\Uwe > Schindler\Projects\lucene\trunk- > lusolr1\solr\server\logs\solr_gc.log:time,uptime:filecount=9,filesize=20000' > > > > If I replace with a simple file name, without path/drive letter it works. How > to escape the colon in the drive letter correctly, to me this looks like a > bummer? > > You can fix this by quoting the filename, with shell escapes eg: > > java -Xlog:gc*:file=\"C:\solr_gc.log\":time,uptime:filecount=9 -version > > Doing that within an env var may be a bit trickier. This approach worked quite easy. As Windows shell does not additionally handle quote escaping, so it seems to be passed as is to Java: set GC_LOG_OPTS="-Xlog:gc*:file=\"!SOLR_LOGS_DIR!\solr_gc.log\":time,uptime:filecount=9,filesize=20000" I was not aware that Java's command line parser does some escaping logic on its own, so I have no explanation what really happens internally, but this helps (at least on windows, where filenames may contain colons). It would be good to add this to the documentation, because there is nothing about escaping file names with spaces or colons. Spaces is no problem, if you add shell quoted around the whole arg (see above), as you should always do on all platforms, but the colon is tricky. Finally: Who parses what (cmd.exe, Windows ShellExecute, java)? If anybody knows he/she might explain. Uwe From david.holmes at oracle.com Mon Aug 21 06:54:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Aug 2017 16:54:40 +1000 Subject: -Xlog,..,file=filename with absolute path on windows? In-Reply-To: <034301d31a43$ba5e9c90$2f1bd5b0$@apache.org> References: <026f01d319ee$4e62b940$eb282bc0$@apache.org> <034301d31a43$ba5e9c90$2f1bd5b0$@apache.org> Message-ID: Hi Uwe, On 21/08/2017 4:07 PM, Uwe Schindler wrote: > Hi David, > >> Hi Uwe, >> >> On 21/08/2017 5:55 AM, Uwe Schindler wrote: >>> Hi, >>> >>> I am currently adapting Apache Solr's startup scripts for Java 9. Linux was >> already done at the beginning of this year and works perfectly, but Windows >> brings some problems. I already fixed version number parsing, but I >> stumbled on the following: In the Windows ".cmd" shell script it uses the >> following to enable Garbage collection logging to a separate file, if Java 9 is >> detected: >>> set GC_LOG_OPTS="- >> Xlog:gc*:file=!SOLR_LOGS_DIR!\solr_gc.log:time,uptime:filecount=9,filesize=2 >> 0000" >>> >>> The problem is now that "!SOLR_LOGS_DIR!" is already expanded to an >> absolute Windows Path by the shell and therefore starts with "C:\". The >> problem is now the colon, which breaks the log parsing. When Java 9 starts it >> exits with the following parsing error: >>> Invalid -Xlog option '-Xlog:gc*:file=C:\Users\Uwe >> Schindler\Projects\lucene\trunk- >> lusolr1\solr\server\logs\solr_gc.log:time,uptime:filecount=9,filesize=20000' >>> >>> If I replace with a simple file name, without path/drive letter it works. How >> to escape the colon in the drive letter correctly, to me this looks like a >> bummer? >> >> You can fix this by quoting the filename, with shell escapes eg: >> >> java -Xlog:gc*:file=\"C:\solr_gc.log\":time,uptime:filecount=9 -version >> >> Doing that within an env var may be a bit trickier. > > This approach worked quite easy. As Windows shell does not additionally handle quote escaping, so it seems to be passed as is to Java: > > set GC_LOG_OPTS="-Xlog:gc*:file=\"!SOLR_LOGS_DIR!\solr_gc.log\":time,uptime:filecount=9,filesize=20000" > > I was not aware that Java's command line parser does some escaping logic on its own, so I have no explanation what really happens internally, but this helps (at least on windows, where filenames may contain colons). > > It would be good to add this to the documentation, because there is nothing about escaping file names with spaces or colons. Spaces is no problem, if you add shell quoted around the whole arg (see above), as you should always do on all platforms, but the colon is tricky. I agree. Not sure if this was discussed when the unified logging system went in. > > Finally: Who parses what (cmd.exe, Windows ShellExecute, java)? If anybody knows he/she might explain. Some parsing happens at each level - hence need to quote args with spaces at the shell-level, or to use \ escapes. The -Xlog is passed through to the JVM from the launcher. It is the logging subsystem that allows for values to be quoted e.g x=y or x="y" But only double-quote quoting is supported. David > Uwe > From glaubitz at physik.fu-berlin.de Mon Aug 21 09:06:52 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 21 Aug 2017 11:06:52 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> Message-ID: On 08/19/2017 07:02 AM, David Holmes wrote: > It is fine to include it with this change while you are in the area - a > lot of cleanups happen that way. Otherwise there is too much overhead in > getting things fixed. :) Ok. I still have split up the changes into two patches because otherwise I frankly wouldn't know how to squeeze the information about both changes into a single commit message. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -------------- next part -------------- A non-text attachment was scrubbed... Name: 8186443_part1.patch Type: text/x-patch Size: 726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8186443_part2.patch Type: text/x-patch Size: 945 bytes Desc: not available URL: From glaubitz at physik.fu-berlin.de Mon Aug 21 09:18:17 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 21 Aug 2017 11:18:17 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> Message-ID: On 08/21/2017 11:06 AM, John Paul Adrian Glaubitz wrote: > Ok. I still have split up the changes into two patches because otherwise > I frankly wouldn't know how to squeeze the information about both changes > into a single commit message. I even managed now to use webrev [1] ;-). Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186443/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Mon Aug 21 13:06:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Aug 2017 23:06:48 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> Message-ID: <14d779e7-9b7b-5521-fc74-3692499955b8@oracle.com> On 21/08/2017 7:06 PM, John Paul Adrian Glaubitz wrote: > On 08/19/2017 07:02 AM, David Holmes wrote: >> It is fine to include it with this change while you are in the area - a >> lot of cleanups happen that way. Otherwise there is too much overhead in >> getting things fixed. :) > > Ok. I still have split up the changes into two patches because otherwise > I frankly wouldn't know how to squeeze the information about both changes > into a single commit message. Our commit messages may not be what you are used to. The main commit message is just a reference to the bug - and the bug can contain all the details. A one line summary is also allowed, but not required. David > Adrian > From erik.osterlund at oracle.com Mon Aug 21 13:10:45 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 21 Aug 2017 15:10:45 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> Message-ID: <599ADBD5.6060903@oracle.com> Hi Kim, Thank you for finding an approach that seems to have reached consensus, and rolling the ball forward while I was on vacation. I agree this seems to be a reasonable way of doing things and am delighted about the general approach. When it comes to the proposed Atomic::add implementation, it seems to me like the emulation of Atomic::add on jshort using jint is very similar to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised me a bit that Atomic::add of jshort does not share the same mechanism as the generalized Atomic::cmpxchg of jbyte. In fact, it seems like the proposed implementation does not safely handle CV-qualifiers. For example, if the addend passed in is const qualified, I believe it will not match the AddImpl class specialization, as it is looking for AddImpl instead. Therefore, I would propose dealing with Atomic::add on jshort in one of the following ways (numbered according to my preferences): 1) Remove it. Atomic::add on jshort is only ever used by a reference counter in the Symbol class that can be placed next to the length. I would be surprised if the memory savings of using short instead of int for the reference counter is considerable. 2) Implement it like jbyte cmpxchg. That would entail both calling a generalized AddShortUsingInt function object from the platform layer, and preferrably also using an int CAS loop for emulating the add operation rather than the current emulation using atomic int add, that relies on two short fields being placed next to each other, depending on endianness of the machine, using the ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or may not in fact enforce the intended alignment at compile time. 3) Continue emulating jshort Atomic::add with jint Atomi::add, but turn it into an AddShortUsingInt function object, called from the platform layer, like the similar CmpxchgByteUsingInt operation. So, I am curious if anyone would have loud objections if I was to remove Atomic::add support for jshort, and changed its single use (Symbol::_refcount), to use int instead. And if there are such objections, I wonder if we really want to continue using the ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or it is okay to rewrite it to use an cmpxch loop instead and get rid of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird API). Thanks, /Erik On 2017-08-20 08:19, Kim Barrett wrote: >> On Aug 20, 2017, at 2:16 AM, Kim Barrett wrote: >> >> Please review this change to Atomic::add, making it a function >> template with a per-platform underlying implementation. >> >> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >> templates", with similar goals and taking a similar approach. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8186476 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >> >> Testing: >> Ad hoc hotspot nightly test. > I forgot to mention that this change is based on the 8186166 hotspot.04 change, > which has not yet been pushed. I?m leaving that to Erik, as well as handing this > change off to him. > From kim.barrett at oracle.com Mon Aug 21 14:20:45 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Aug 2017 10:20:45 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <599ADBD5.6060903@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> Message-ID: > On Aug 21, 2017, at 9:10 AM, Erik ?sterlund wrote: > > Hi Kim, > > Thank you for finding an approach that seems to have reached consensus, and rolling the ball forward while I was on vacation. > I agree this seems to be a reasonable way of doing things and am delighted about the general approach. > > When it comes to the proposed Atomic::add implementation, it seems to me like the emulation of Atomic::add on jshort using jint is very similar to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised me a bit that Atomic::add of jshort does not share the same mechanism as the generalized Atomic::cmpxchg of jbyte. In fact, it seems like the proposed implementation does not safely handle CV-qualifiers. For example, if the addend passed in is const qualified, I believe it will not match the AddImpl class specialization, as it is looking for AddImpl instead. That?s incorrect. lvalue-to-rvalue conversion for non-class types drops the const qualifier. > Therefore, I would propose dealing with Atomic::add on jshort in one of the following ways (numbered according to my preferences): > > 1) Remove it. Atomic::add on jshort is only ever used by a reference counter in the Symbol class that can be placed next to the length. I would be surprised if the memory savings of using short instead of int for the reference counter is considerable. I?m fairly sure the runtime folks would say you should be surprised, and would object to such a change. The layout of symbol is carefully constructed, and I think such a change would increase the size of a symbol by 6 byes (not the obvious two) on a 64 bit platform. > 2) Implement it like jbyte cmpxchg. That would entail both calling a generalized AddShortUsingInt function object from the platform layer, and preferrably also using an int CAS loop for emulating the add operation rather than the current emulation using atomic int add, that relies on two short fields being placed next to each other, depending on endianness of the machine, using the ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or may not in fact enforce the intended alignment at compile time. > 3) Continue emulating jshort Atomic::add with jint Atomi::add, but turn it into an AddShortUsingInt function object, called from the platform layer, like the similar CmpxchgByteUsingInt operation. > > So, I am curious if anyone would have loud objections if I was to remove Atomic::add support for jshort, and changed its single use (Symbol::_refcount), to use int instead. And if there are such objections, I wonder if we really want to continue using the ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or it is okay to rewrite it to use an cmpxch loop instead and get rid of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird API). I don?t think it?s worth spending a lot of effort generalizing the short case right now. As you noticed, there is *exactly* one use of it, for the symbol refcount. Reconsider if that ever changes. From erik.osterlund at oracle.com Mon Aug 21 15:57:11 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 21 Aug 2017 17:57:11 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> Message-ID: <599B02D7.2000708@oracle.com> Hi Kim, On 2017-08-21 16:20, Kim Barrett wrote: >> On Aug 21, 2017, at 9:10 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> Thank you for finding an approach that seems to have reached consensus, and rolling the ball forward while I was on vacation. >> I agree this seems to be a reasonable way of doing things and am delighted about the general approach. >> >> When it comes to the proposed Atomic::add implementation, it seems to me like the emulation of Atomic::add on jshort using jint is very similar to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised me a bit that Atomic::add of jshort does not share the same mechanism as the generalized Atomic::cmpxchg of jbyte. In fact, it seems like the proposed implementation does not safely handle CV-qualifiers. For example, if the addend passed in is const qualified, I believe it will not match the AddImpl class specialization, as it is looking for AddImpl instead. > That?s incorrect. lvalue-to-rvalue conversion for non-class types drops the const qualifier. Ah, yes you are right. I suppose that makes passing in const jshort lvalues to Atomic::add fine if using template type inference for the template parameters. If one was to explicitly state the types as Atomic::add(...), it would not work though. But I guess that is okay, as one might argue the user of the API should not be doing that. And again, there is a single use case so might not be worth the hassle. >> Therefore, I would propose dealing with Atomic::add on jshort in one of the following ways (numbered according to my preferences): >> >> 1) Remove it. Atomic::add on jshort is only ever used by a reference counter in the Symbol class that can be placed next to the length. I would be surprised if the memory savings of using short instead of int for the reference counter is considerable. > I?m fairly sure the runtime folks would say you should be surprised, and would object to such a change. The layout of symbol is carefully constructed, and I think such a change would increase the size of a symbol by 6 byes (not the obvious two) on a 64 bit platform. I find that surprising. By making body jbyte[0] instead, it seems to me (after a glance) to be possible to retain the size of the header from 8 bytes to 8 bytes after turning refcount to an int. This leaves only the difference in payload and its effect on the allocator and its alignment, which should seemingly not require 6 extra bytes. But perhaps I have misunderstood something about the layout of Symbol. >> 2) Implement it like jbyte cmpxchg. That would entail both calling a generalized AddShortUsingInt function object from the platform layer, and preferrably also using an int CAS loop for emulating the add operation rather than the current emulation using atomic int add, that relies on two short fields being placed next to each other, depending on endianness of the machine, using the ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or may not in fact enforce the intended alignment at compile time. >> 3) Continue emulating jshort Atomic::add with jint Atomi::add, but turn it into an AddShortUsingInt function object, called from the platform layer, like the similar CmpxchgByteUsingInt operation. >> >> So, I am curious if anyone would have loud objections if I was to remove Atomic::add support for jshort, and changed its single use (Symbol::_refcount), to use int instead. And if there are such objections, I wonder if we really want to continue using the ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or it is okay to rewrite it to use an cmpxch loop instead and get rid of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird API). > I don?t think it?s worth spending a lot of effort generalizing the short case right now. As you noticed, there is *exactly* one use of it, for the symbol refcount. Reconsider if that ever changes. > Okay, I agree. I will drop that for now. This single use case is probably not worth the effort. Thanks, /Erik From kim.barrett at oracle.com Mon Aug 21 21:17:12 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Aug 2017 17:17:12 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <599B02D7.2000708@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> Message-ID: <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> > On Aug 21, 2017, at 11:57 AM, Erik ?sterlund wrote: >> I?m fairly sure the runtime folks would say you should be surprised, and would object to such a change. The layout of symbol is carefully constructed, and I think such a change would increase the size of a symbol by 6 byes (not the obvious two) on a 64 bit platform. > > I find that surprising. By making body jbyte[0] instead, it seems to me (after a glance) to be possible to retain the size of the header from 8 bytes to 8 bytes after turning refcount to an int. This leaves only the difference in payload and its effect on the allocator and its alignment, which should seemingly not require 6 extra bytes. But perhaps I have misunderstood something about the layout of Symbol. No, I misremembered. Yes, that change would cost an average of 2 additional bytes per symbol, assuming symbol name lengths mod 8 are fairly uniformly distributed, which seems likely. That?s still 2 extra bytes per symbol, and I doubt the runtime folks would like that, since they?ve been going to some trouble to reduce the size of symbols: 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes 8087143: Reduce Symbol::_identity_hash to 2 bytes > >>> 2) Implement it like jbyte cmpxchg. That would entail both calling a generalized AddShortUsingInt function object from the platform layer, and preferrably also using an int CAS loop for emulating the add operation rather than the current emulation using atomic int add, that relies on two short fields being placed next to each other, depending on endianness of the machine, using the ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or may not in fact enforce the intended alignment at compile time. >>> 3) Continue emulating jshort Atomic::add with jint Atomi::add, but turn it into an AddShortUsingInt function object, called from the platform layer, like the similar CmpxchgByteUsingInt operation. >>> >>> So, I am curious if anyone would have loud objections if I was to remove Atomic::add support for jshort, and changed its single use (Symbol::_refcount), to use int instead. And if there are such objections, I wonder if we really want to continue using the ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or it is okay to rewrite it to use an cmpxch loop instead and get rid of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird API). >> I don?t think it?s worth spending a lot of effort generalizing the short case right now. As you noticed, there is *exactly* one use of it, for the symbol refcount. Reconsider if that ever changes. >> > > Okay, I agree. I will drop that for now. This single use case is probably not worth the effort. Okay. From david.holmes at oracle.com Tue Aug 22 00:29:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 10:29:28 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> Message-ID: <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> On 21/08/2017 7:18 PM, John Paul Adrian Glaubitz wrote: > On 08/21/2017 11:06 AM, John Paul Adrian Glaubitz wrote: >> Ok. I still have split up the changes into two patches because otherwise >> I frankly wouldn't know how to squeeze the information about both changes >> into a single commit message. > > I even managed now to use webrev [1] ;-). > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186443/webrev.00/ Looks good. Couple of nits test/native/runtime/test_vmStructs.cpp Copyright notice needs updating: "2016," -> "2016, 2017," Please add blank line between these lines: 29 #include "runtime/vmStructs.hpp" 30 TEST(VMStructs, last_entries) { --- src/share/vm/runtime/vmStructs.hpp Please update copyright final year to 2017. --- The commit message format is described here: http://openjdk.java.net/guide/producingChangeset.html In this case: 8186443: Missing stdint.h for zero builds Reviewed-by: kbarratt, dholmes If you make changes, commit and regen webrev I'll grab it from there and sponsor for you. Thanks, David From glaubitz at physik.fu-berlin.de Tue Aug 22 00:32:09 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 22 Aug 2017 02:32:09 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> Message-ID: Hi David! On 08/22/2017 02:29 AM, David Holmes wrote: > Looks good. Couple of nits Thanks for the review! > test/native/runtime/test_vmStructs.cpp > > Copyright notice needs updating: "2016," -> "2016, 2017," Makes sense :-). > Please add blank line between these lines: > > 29 #include "runtime/vmStructs.hpp" > 30 TEST(VMStructs, last_entries) { Ok. I agree, it improves the readability. > --- > > src/share/vm/runtime/vmStructs.hpp > > Please update copyright final year to 2017. Ack. > --- > > The commit message format is described here: > > http://openjdk.java.net/guide/producingChangeset.html > > In this case: > > 8186443: Missing stdint.h for zero builds > Reviewed-by: kbarratt, dholmes Ok. So just squash both changes into one commit? > If you make changes, commit and regen webrev I'll grab it from there and sponsor for you. Great. Thank you! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Tue Aug 22 00:56:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 10:56:03 +1000 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: Surprising lack of response to this. Conservatism will likely dictate we go option #1 if we get no more feedback. Thanks, David On 2/08/2017 2:35 PM, David Holmes wrote: > https://bugs.openjdk.java.net/browse/JDK-8185062 > > Is it time to completely remove runtime optimizations aimed at > uniprocessor systems ie. > > if (os::is_MP()) { > ? x(); > } > > just becomes: > > x(); > > ? > > Does anyone care about uniprocessor systems _and_ care to the extent > that the overhead of things only necessary on MP systems (_lock > prefixes, explicit atomic instructions, memory barriers) would be a > problem? > > As outlined in the "bug" report there are three basic options: > > 1. Switch AssumeMP to be true by default (arguably necessary regardless > due to dynamic container environments) > > 2. Allow non-MP support to be built, but by default only build MP > support ie no runtime means to disable MP support, and compile-time > MP_ONLY/NOT_MP macros. > > 3. Assume the universe is MP and only allow MP to be built > > Cheers, > David > ----- From david.holmes at oracle.com Tue Aug 22 01:07:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 11:07:31 +1000 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> Message-ID: <10a15e52-22fc-a8b6-d1de-82c313d66aa7@oracle.com> Hi Gerard, Sorry for the delay getting back to this. On 19/08/2017 7:00 AM, Gerard Ziemski wrote: > hi all, > > The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it?s the time to remove the code and obsolete the -Xprof flag. > > Changes from rev1 to address David?s feedback: > > - obsoleted the flag (it?s still accepted, but ignored) Ok. > - fixed copyright year in "src/os_cpu/linux_s390/vm/thread_linux_s390.hpp? Ok. > - improved comment about the signal based suspend/resume mechanism in "os_*.cpp? files Not sure we should be referring to JFR here. The other comments I can live with. :) > - removed entire comment from "src/os/solaris/vm/osThread_solaris.hpp" Thanks. > issue: https://bugs.openjdk.java.net/browse/JDK-8173715 > webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot Looks okay. Just clarify the JFR comment situation. Thanks, David ----- From vladimir.kozlov at oracle.com Tue Aug 22 01:08:40 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Aug 2017 18:08:40 -0700 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: On 8/21/17 5:56 PM, David Holmes wrote: > Surprising lack of response to this. You need more? I and Aleksey replied. Vladimir > > Conservatism will likely dictate we go option #1 if we get no more > feedback. > > Thanks, > David > > On 2/08/2017 2:35 PM, David Holmes wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185062 >> >> Is it time to completely remove runtime optimizations aimed at >> uniprocessor systems ie. >> >> if (os::is_MP()) { >> ?? x(); >> } >> >> just becomes: >> >> x(); >> >> ? >> >> Does anyone care about uniprocessor systems _and_ care to the extent >> that the overhead of things only necessary on MP systems (_lock >> prefixes, explicit atomic instructions, memory barriers) would be a >> problem? >> >> As outlined in the "bug" report there are three basic options: >> >> 1. Switch AssumeMP to be true by default (arguably necessary >> regardless due to dynamic container environments) >> >> 2. Allow non-MP support to be built, but by default only build MP >> support ie no runtime means to disable MP support, and compile-time >> MP_ONLY/NOT_MP macros. >> >> 3. Assume the universe is MP and only allow MP to be built >> >> Cheers, >> David >> ----- From kim.barrett at oracle.com Tue Aug 22 01:12:11 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Aug 2017 21:12:11 -0400 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> Message-ID: <6F89ABDC-E4FF-46D0-8B6C-76B326F20A31@oracle.com> > On Aug 21, 2017, at 8:29 PM, David Holmes wrote: > > On 21/08/2017 7:18 PM, John Paul Adrian Glaubitz wrote: >> On 08/21/2017 11:06 AM, John Paul Adrian Glaubitz wrote: >>> Ok. I still have split up the changes into two patches because otherwise >>> I frankly wouldn't know how to squeeze the information about both changes >>> into a single commit message. >> I even managed now to use webrev [1] ;-). >> Adrian >>> [1] http://cr.openjdk.java.net/~glaubitz/8186443/webrev.00/ > > Looks good. Couple of nits I concur with David?s nits. Otherwise, looks good to me too. > 8186443: Missing stdint.h for zero builds > Reviewed-by: kbarratt, dholmes correct spelling is kbarrett From david.holmes at oracle.com Tue Aug 22 01:28:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 11:28:44 +1000 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: <33AFA2FF-305E-402A-A810-A055E4475ECF@oracle.com> References: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> <33AFA2FF-305E-402A-A810-A055E4475ECF@oracle.com> Message-ID: On 19/08/2017 4:45 AM, Kim Barrett wrote: >> On Aug 18, 2017, at 9:23 AM, Andrew Haley wrote: >> >> This hunk was missing the parameter declaration of order. Fixed thusly: >> >> diff -r 214a94e9366c src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp >> --- a/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Mon Jul 17 12:11:32 2017 +0000 >> +++ b/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp Fri Aug 18 14:22:19 2017 +0100 >> @@ -85,9 +85,12 @@ >> (volatile intptr_t*) dest); >> } >> >> -template T generic_cmpxchg(T exchange_value, volatile T* dest, >> - T compare_value, cmpxchg_memory_order order) >> -{ >> +template >> +template >> +inline T Atomic::PlatformCmpxchg::operator()(T exchange_value, >> + T volatile* dest, >> + T compare_value, >> + cmpxchg_memory_order order) const { >> if (order == memory_order_relaxed) { >> T value = compare_value; >> __atomic_compare_exchange(dest, &value, &exchange_value, /*weak*/false, >> @@ -98,17 +101,6 @@ >> } >> } > > > Drat. Thanks for finding this. > > It's a nuisance having to send out for review code that I've not been > able to test at all. And yes, I know non-Oracle folks trying to deal > with jprt have it *much* worse. > > Some new webrevs: > > Rename IntegerTypes to PrimitiveConversions. This is the change I > said I was going to leave until the end. Looks like I could have done > it earlier; webrev did a fine job with the moved file. > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03.inc/ Looks okay justAPityItisSuchALongname :) > linux_aarch fix, rename test_integerTypes.cpp to test_primitiveConversions.cpp. > full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.04/ > incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.04.inc/ > > I'm hoping hotspot.04 will be the final version that I'll be handing > off to Erik, as he returns from vacation and I start mine. > > I'm working on a change in a similar style for Atomic::add, and hope > to send out an RFR later today. I'll be handing that off to Erik as > well. No further comments on this from me. Thanks, David From kim.barrett at oracle.com Tue Aug 22 02:17:22 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Aug 2017 22:17:22 -0400 Subject: RFR: 8186166: Generalize Atomic::cmpxchg with templates In-Reply-To: References: <39e0b939-ab28-c0d2-2e34-40cd37d715d4@redhat.com> <33AFA2FF-305E-402A-A810-A055E4475ECF@oracle.com> Message-ID: <15F001FD-B055-4915-9F64-A8C6456FA738@oracle.com> > On Aug 21, 2017, at 9:28 PM, David Holmes wrote: > > On 19/08/2017 4:45 AM, Kim Barrett wrote: >> Rename IntegerTypes to PrimitiveConversions. This is the change I >> said I was going to leave until the end. Looks like I could have done >> it earlier; webrev did a fine job with the moved file. >> full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.03.inc/ > > Looks okay justAPityItisSuchALongname :) It?s not so often for that to bother me. And I?m used to some of the GC class names. >> linux_aarch fix, rename test_integerTypes.cpp to test_primitiveConversions.cpp. >> full: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.04/ >> incr: http://cr.openjdk.java.net/~kbarrett/8186166/hotspot.04.inc/ >> I'm hoping hotspot.04 will be the final version that I'll be handing >> off to Erik, as he returns from vacation and I start mine. >> I'm working on a change in a similar style for Atomic::add, and hope >> to send out an RFR later today. I'll be handing that off to Erik as >> well. > > No further comments on this from me. Thanks. > > Thanks, > David From david.holmes at oracle.com Tue Aug 22 02:25:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 12:25:09 +1000 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> Message-ID: Hi Kim, On 20/08/2017 4:16 PM, Kim Barrett wrote: > Please review this change to Atomic::add, making it a function > template with a per-platform underlying implementation. > > This change is similar to 8186166: "Generalize Atomic::cmpxchg with > templates", with similar goals and taking a similar approach. So one thing I realized with this change is that the use of the templates now obscures the set of "overloads" that are available for a given operation. Before you could look at atomic.hpp and see that there was no add(jlong, jlong*), but now you only discover the absence of that API when you try to use it. It took me a while to figure out the machinations for PlatformAdd<8> only existing on 64-bit. :) Aside: the 1 -> 1u changes are really irksome. I know you explained it before but it still seem crazy to me that the compiler can't handle this. :( > This change deprecates add_ptr. Followup changes will convert > existing uses of cmpxchg_ptr and eventually remove it. Followup > changes will also update uses of cmpxchg that can be simplified > because of the generalized API. Only changes to usage that were > required by the new implementation have been made so far. > > The add function calls private Atomic::AddImpl, to select among > several cases, based on the argument types. Each case performs some > checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformAdd. > > Only safe conversions of the first (add_value) argument are made by > the AddImpl layer. add_value must be integral, and is never narrowed. > dest's value type must be either integral or a pointer type. When > both are integral, they must be of the same signedness. If smaller, > add_value will be promited to the same size as dest's value type. > > The PlatformAdd class is provided by each platform, and performs > additional case analysis to generate the appropriate code for the > platform. Most PlatformAdd implementations use one of two helper base > classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide > common parts of the implementation in terms of a support function > provided by the derived PlatformAdd, accessed using CRTP. > > This change involves modifications to all of the existing platform > implementations of Atomic::add. I've updated all of the platforms, > but only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > [No new metaprogramming tools!] > > Change add to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > g1CardLiveData.cpp > g1ConcurrentMark.cpp > g1HotCardCache.cpp > g1HotCardCache.hpp > g1RemSet.cpp > symbol.cpp > mallocTracker.hpp > > A few specific items: > > - atomic_linux_arm.hpp > > Neither add variant has "cc" in the clobbers list, even though the > condition codes are modified. That seems like a pre-existing bug. > > - atomic_linux_sparc.hpp > > Neither add variant has "cc" in the clobbers list, even though the > condition codes are modified. That seems like a pre-existing bug. > > The 32-bit add was using intptr_t as the rv type. Probably a harmless > copy-paste mistake. Now using template parameter type. > > Uses hard-coded machine registers and assumes the inline-asm > processing assigns the values to the corresponding machine registers, > even though the given constraints are just generic register requests. > I don't understand how this can work. > > - atomic_solaris_sparc.hpp > > Atomic::add was implemented using asm code in solaris_sparc.il. I was > going to change it to use gcc-style inline-asm, but the linux_sparc > version wasn't helpful this time (unlike for cmpxchg) (see above). > Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much > simpler code, and should be no less efficient, assuming the compiler > does it's job. I was getting ready to object to this until I saw that the asm in the .il file is already a CAS-loop. :) Makes me wonder whether this version should not be in platform independent code ready to be inherited by a platform if needed? > CR: > https://bugs.openjdk.java.net/browse/JDK-8186476 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ Nothing jumped out at me after a few readings :) Thanks, David > Testing: > Ad hoc hotspot nightly test. > > From david.holmes at oracle.com Tue Aug 22 02:32:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 12:32:27 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> Message-ID: <638bdea7-0b67-099c-b802-8d294f86f85d@oracle.com> On 22/08/2017 10:32 AM, John Paul Adrian Glaubitz wrote: > Hi David! > > On 08/22/2017 02:29 AM, David Holmes wrote: >> Looks good. Couple of nits > > Thanks for the review! > >> test/native/runtime/test_vmStructs.cpp >> >> Copyright notice needs updating: "2016," -> "2016, 2017," > > Makes sense :-). > >> Please add blank line between these lines: >> >> 29 #include "runtime/vmStructs.hpp" >> 30 TEST(VMStructs, last_entries) { > > Ok. I agree, it improves the readability. > >> --- >> >> src/share/vm/runtime/vmStructs.hpp >> >> Please update copyright final year to 2017. > > Ack. > >> --- >> >> The commit message format is described here: >> >> http://openjdk.java.net/guide/producingChangeset.html >> >> In this case: >> >> 8186443: Missing stdint.h for zero builds >> Reviewed-by: kbarratt, dholmes > > Ok. So just squash both changes into one commit? Yes. You can only have one changeset per bugID per repo. Thanks, David >> If you make changes, commit and regen webrev I'll grab it from there and sponsor for you. > > Great. Thank you! > > Adrian > From david.holmes at oracle.com Tue Aug 22 02:33:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 12:33:45 +1000 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: On 22/08/2017 11:08 AM, Vladimir Kozlov wrote: > On 8/21/17 5:56 PM, David Holmes wrote: >> Surprising lack of response to this. > > You need more? I and Aleksey replied. So I'm good on feedback quality, just lacking in quantity :) David > Vladimir > >> >> Conservatism will likely dictate we go option #1 if we get no more >> feedback. >> >> Thanks, >> David >> >> On 2/08/2017 2:35 PM, David Holmes wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8185062 >>> >>> Is it time to completely remove runtime optimizations aimed at >>> uniprocessor systems ie. >>> >>> if (os::is_MP()) { >>> ?? x(); >>> } >>> >>> just becomes: >>> >>> x(); >>> >>> ? >>> >>> Does anyone care about uniprocessor systems _and_ care to the extent >>> that the overhead of things only necessary on MP systems (_lock >>> prefixes, explicit atomic instructions, memory barriers) would be a >>> problem? >>> >>> As outlined in the "bug" report there are three basic options: >>> >>> 1. Switch AssumeMP to be true by default (arguably necessary >>> regardless due to dynamic container environments) >>> >>> 2. Allow non-MP support to be built, but by default only build MP >>> support ie no runtime means to disable MP support, and compile-time >>> MP_ONLY/NOT_MP macros. >>> >>> 3. Assume the universe is MP and only allow MP to be built >>> >>> Cheers, >>> David >>> ----- From david.holmes at oracle.com Tue Aug 22 02:34:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 12:34:43 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <6F89ABDC-E4FF-46D0-8B6C-76B326F20A31@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <6F89ABDC-E4FF-46D0-8B6C-76B326F20A31@oracle.com> Message-ID: <7c372813-f0ac-13b8-a759-8c68431bc0fc@oracle.com> On 22/08/2017 11:12 AM, Kim Barrett wrote: >> On Aug 21, 2017, at 8:29 PM, David Holmes wrote: >> >> On 21/08/2017 7:18 PM, John Paul Adrian Glaubitz wrote: >>> On 08/21/2017 11:06 AM, John Paul Adrian Glaubitz wrote: >>>> Ok. I still have split up the changes into two patches because otherwise >>>> I frankly wouldn't know how to squeeze the information about both changes >>>> into a single commit message. >>> I even managed now to use webrev [1] ;-). >>> Adrian >>>> [1] http://cr.openjdk.java.net/~glaubitz/8186443/webrev.00/ >> >> Looks good. Couple of nits > > I concur with David?s nits. Otherwise, looks good to me too. > >> 8186443: Missing stdint.h for zero builds >> Reviewed-by: kbarratt, dholmes > > correct spelling is kbarrett Oops my bad! David > From vladimir.x.ivanov at oracle.com Tue Aug 22 07:59:14 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 22 Aug 2017 10:59:14 +0300 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> Message-ID: <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> Looks good. Best regards, Vladimir Ivanov On 8/19/17 12:00 AM, Gerard Ziemski wrote: > hi all, > > The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it?s the time to remove the code and obsolete the -Xprof flag. > > Changes from rev1 to address David?s feedback: > > - obsoleted the flag (it?s still accepted, but ignored) > - fixed copyright year in "src/os_cpu/linux_s390/vm/thread_linux_s390.hpp? > - improved comment about the signal based suspend/resume mechanism in "os_*.cpp? files > - removed entire comment from "src/os/solaris/vm/osThread_solaris.hpp" > > issue: https://bugs.openjdk.java.net/browse/JDK-8173715 > webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot > From aph at redhat.com Tue Aug 22 08:34:28 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Aug 2017 09:34:28 +0100 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: On 22/08/17 01:56, David Holmes wrote: > Surprising lack of response to this. > > Conservatism will likely dictate we go option #1 if we get no more feedback. Nuke it. Virtualization is the modern world, and a JVM has no way to know when it migrates. Also, the inline tests in x86 needlessly hurt performance. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 22 08:52:01 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Aug 2017 09:52:01 +0100 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> Message-ID: <44a6d9bd-24b6-c8cb-973d-ff40775381c9@redhat.com> On 20/08/17 07:16, Kim Barrett wrote: > - atomic_linux_sparc.hpp > > Neither add variant has "cc" in the clobbers list, even though the > condition codes are modified. That seems like a pre-existing bug. Some targets always clobber the flags. I can't remember whether SPARC is one of them. > The 32-bit add was using intptr_t as the rv type. Probably a harmless > copy-paste mistake. Now using template parameter type. > > Uses hard-coded machine registers and assumes the inline-asm > processing assigns the values to the corresponding machine registers, > even though the given constraints are just generic register requests. > I don't understand how this can work. Looks right to me. 69 __asm__ volatile( 70 "1: \n\t" 71 " ld [%2], %%o2\n\t" 72 " add %1, %%o2, %%o3\n\t" 73 " cas [%2], %%o2, %%o3\n\t" 74 " cmp %%o2, %%o3\n\t" 75 " bne 1b\n\t" 76 " nop\n\t" 77 " add %1, %%o2, %0\n\t" 78 : "=r" (rv) 79 : "r" (add_value), "r" (dest) 80 : "memory", "o2", "o3"); 81 return rv; 82 } o2 and o3 are temps. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 22 09:06:43 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Aug 2017 10:06:43 +0100 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <599ADBD5.6060903@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> Message-ID: On 21/08/17 14:10, Erik ?sterlund wrote: > When it comes to the proposed Atomic::add implementation, it seems to me > like the emulation of Atomic::add on jshort using jint is very similar > to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised > me a bit that Atomic::add of jshort does not share the same mechanism as > the generalized Atomic::cmpxchg of jbyte. Indeed. It also seems rather weird to jump through these hoops on targets which do have support for adds on jshort. Still, as you say it's only used in once place and I guess it doesn't hurt. I don't like the undefined behaviour there, though. It would be nice if there were none on targets with proper support. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Tue Aug 22 09:47:38 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 22 Aug 2017 11:47:38 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> Message-ID: <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> On 08/22/2017 02:32 AM, John Paul Adrian Glaubitz wrote: >> If you make changes, commit and regen webrev I'll grab it from there and sponsor for you. > > Great. Thank you! Should be all fixed now [1]. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186443/webrev.01/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Tue Aug 22 10:13:42 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 22 Aug 2017 12:13:42 +0200 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: Hi David, We opt for option #3. Kind Regards, Thomas On Tue, Aug 22, 2017 at 2:56 AM, David Holmes wrote: > Surprising lack of response to this. > > Conservatism will likely dictate we go option #1 if we get no more > feedback. > > Thanks, > David > > > On 2/08/2017 2:35 PM, David Holmes wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8185062 >> >> Is it time to completely remove runtime optimizations aimed at >> uniprocessor systems ie. >> >> if (os::is_MP()) { >> x(); >> } >> >> just becomes: >> >> x(); >> >> ? >> >> Does anyone care about uniprocessor systems _and_ care to the extent that >> the overhead of things only necessary on MP systems (_lock prefixes, >> explicit atomic instructions, memory barriers) would be a problem? >> >> As outlined in the "bug" report there are three basic options: >> >> 1. Switch AssumeMP to be true by default (arguably necessary regardless >> due to dynamic container environments) >> >> 2. Allow non-MP support to be built, but by default only build MP support >> ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP >> macros. >> >> 3. Assume the universe is MP and only allow MP to be built >> >> Cheers, >> David >> ----- >> > From david.holmes at oracle.com Tue Aug 22 12:40:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 22:40:45 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> Message-ID: On 22/08/2017 7:47 PM, John Paul Adrian Glaubitz wrote: > On 08/22/2017 02:32 AM, John Paul Adrian Glaubitz wrote: >>> If you make changes, commit and regen webrev I'll grab it from there >>> and sponsor for you. >> >> Great. Thank you! > > Should be all fixed now [1]. > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186443/webrev.01/ The patch in the webrev was not the committed changeset, but I created the changeset from it. Currently pushing through JPRT. Cheers, David From glaubitz at physik.fu-berlin.de Tue Aug 22 12:42:58 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 22 Aug 2017 14:42:58 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> Message-ID: Hi David! On 08/22/2017 02:40 PM, David Holmes wrote: > The patch in the webrev was not the committed changeset, > but I created the changeset from it. I'm not sure I understand what you mean? > Currently pushing through JPRT. Thanks. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Tue Aug 22 12:51:32 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 22:51:32 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> Message-ID: On 22/08/2017 10:42 PM, John Paul Adrian Glaubitz wrote: > Hi David! > > On 08/22/2017 02:40 PM, David Holmes wrote: >> The patch in the webrev was not the committed changeset, >> but I created the changeset from it. > > I'm not sure I understand what you mean? Your patch: http://cr.openjdk.java.net/~glaubitz/8186443/webrev.01/hotspot.patch is just a basic patch, containing only the diff for the two files. Yet your webrev shows e.g.: rev 13458 : 8186443: Missing stdint.h for zero builds Reviewed-by: kbarrett, dholmes which is the details of the commit message. If I do a commit and then generate the webrev the patch file is the actual changeset in a format that can be directly imported by "hg import" including the user identity, the bug attribution and reviewers. That's the format I get from others. Cheers, David >> Currently pushing through JPRT. > > Thanks. > From glaubitz at physik.fu-berlin.de Tue Aug 22 12:54:34 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 22 Aug 2017 14:54:34 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> Message-ID: <6b30dd04-5aa8-ccae-c98c-4f716fa80024@physik.fu-berlin.de> On 08/22/2017 02:51 PM, David Holmes wrote: > http://cr.openjdk.java.net/~glaubitz/8186443/webrev.01/hotspot.patch > > is just a basic patch, containing only the diff for the two files. Yet your webrev shows e.g.: > > rev 13458 : 8186443: Missing stdint.h for zero builds > Reviewed-by: kbarrett, dholmes > > which is the details of the commit message. If I do a commit and then generate the > webrev the patch file is the actual changeset in a format that can be directly > imported by "hg import" including the user identity, the bug attribution and reviewers. > That's the format I get from others. Oh, ok. I used "webrev -N -r $REV" to create it. Do I need to pass other options? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Tue Aug 22 13:00:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Aug 2017 23:00:20 +1000 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <6b30dd04-5aa8-ccae-c98c-4f716fa80024@physik.fu-berlin.de> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> <6b30dd04-5aa8-ccae-c98c-4f716fa80024@physik.fu-berlin.de> Message-ID: <97b3ae80-758e-8e23-a122-517b57c153a1@oracle.com> On 22/08/2017 10:54 PM, John Paul Adrian Glaubitz wrote: > On 08/22/2017 02:51 PM, David Holmes wrote: >> http://cr.openjdk.java.net/~glaubitz/8186443/webrev.01/hotspot.patch >> >> is just a basic patch, containing only the diff for the two files. Yet >> your webrev shows e.g.: >> >> rev 13458 : 8186443: Missing stdint.h for zero builds >> Reviewed-by: kbarrett, dholmes >> >> which is the details of the commit message. If I do a commit and then >> generate the >> webrev the patch file is the actual changeset in a format that can be >> directly >> imported by "hg import" including the user identity, the bug >> attribution and reviewers. >> That's the format I get from others. > Oh, ok. I used "webrev -N -r $REV" to create it. Do I need to pass other > options? I think you need to drop the -N, and possibly the -r rev too. I don't pass any specific options, except -m to force mercurial. Cheers, David > Adrian > From glaubitz at physik.fu-berlin.de Tue Aug 22 13:04:44 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 22 Aug 2017 15:04:44 +0200 Subject: [RFH]: 8186443: Missing stdint.h for zero builds In-Reply-To: <97b3ae80-758e-8e23-a122-517b57c153a1@oracle.com> References: <76f69f9b-5955-226d-b963-93822e238003@oracle.com> <135d29e7-8f6e-5885-ff08-1f35ed5cdb1c@physik.fu-berlin.de> <01E3FE7C-B26C-4863-B232-C689DFD895E9@oracle.com> <6021d086-b3ed-5858-8b4d-169a24f8729b@physik.fu-berlin.de> <60EF89AE-B8DF-4097-9E01-777699B39DEB@oracle.com> <6923118f-95dd-9b12-ad1d-64400a96f13f@oracle.com> <3fd02a61-d311-c401-904e-5254d94a05be@oracle.com> <3cec318e-3d2e-f92d-3b8a-b902d5352dc4@physik.fu-berlin.de> <6b30dd04-5aa8-ccae-c98c-4f716fa80024@physik.fu-berlin.de> <97b3ae80-758e-8e23-a122-517b57c153a1@oracle.com> Message-ID: On 08/22/2017 03:00 PM, David Holmes wrote: > I think you need to drop the -N, and possibly the -r rev too. I > don't pass any specific options, except -m to force mercurial. I see. Thanks for the heads-up, I really appreciate that. I will look that up in the documentation and hopefully my next webrev will be correct :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From gerard.ziemski at oracle.com Tue Aug 22 13:33:10 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 22 Aug 2017 08:33:10 -0500 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: <10a15e52-22fc-a8b6-d1de-82c313d66aa7@oracle.com> References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> <10a15e52-22fc-a8b6-d1de-82c313d66aa7@oracle.com> Message-ID: <88C923D4-8BB6-4E90-9265-592163DD4B29@oracle.com> Thank you for the review. > On Aug 21, 2017, at 8:07 PM, David Holmes wrote: > > Hi Gerard, > > Sorry for the delay getting back to this. > > On 19/08/2017 7:00 AM, Gerard Ziemski wrote: >> hi all, >> The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it?s the time to remove the code and obsolete the -Xprof flag. >> Changes from rev1 to address David?s feedback: >> - obsoleted the flag (it?s still accepted, but ignored) > > Ok. > >> - fixed copyright year in "src/os_cpu/linux_s390/vm/thread_linux_s390.hpp? > > Ok. > >> - improved comment about the signal based suspend/resume mechanism in "os_*.cpp? files > > Not sure we should be referring to JFR here. The other comments I can live with. :) > >> - removed entire comment from "src/os/solaris/vm/osThread_solaris.hpp" > > Thanks. > >> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot > > Looks okay. Just clarify the JFR comment situation. Will do. cheers From gerard.ziemski at oracle.com Tue Aug 22 13:33:26 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 22 Aug 2017 08:33:26 -0500 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> Message-ID: <572D510B-6B19-4C20-8302-9BB600EC62EC@oracle.com> Thank you for the review. cheers > On Aug 22, 2017, at 2:59 AM, Vladimir Ivanov wrote: > > Looks good. > > Best regards, > Vladimir Ivanov > > On 8/19/17 12:00 AM, Gerard Ziemski wrote: >> hi all, >> The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it?s the time to remove the code and obsolete the -Xprof flag. >> Changes from rev1 to address David?s feedback: >> - obsoleted the flag (it?s still accepted, but ignored) >> - fixed copyright year in "src/os_cpu/linux_s390/vm/thread_linux_s390.hpp? >> - improved comment about the signal based suspend/resume mechanism in "os_*.cpp? files >> - removed entire comment from "src/os/solaris/vm/osThread_solaris.hpp" >> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot From erik.osterlund at oracle.com Tue Aug 22 14:02:13 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 22 Aug 2017 16:02:13 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> Message-ID: <599C3965.4060000@oracle.com> Hi Andrew, On 2017-08-22 11:06, Andrew Haley wrote: > On 21/08/17 14:10, Erik ?sterlund wrote: >> When it comes to the proposed Atomic::add implementation, it seems to me >> like the emulation of Atomic::add on jshort using jint is very similar >> to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised >> me a bit that Atomic::add of jshort does not share the same mechanism as >> the generalized Atomic::cmpxchg of jbyte. > Indeed. It also seems rather weird to jump through these hoops on > targets which do have support for adds on jshort. Still, as you say > it's only used in once place and I guess it doesn't hurt. I don't > like the undefined behaviour there, though. It would be nice if there > were none on targets with proper support. > Is that a request or are you happy enough with the proposed solution? In case it was really meant as a request, how about something like this? Incremental: http://cr.openjdk.java.net/~eosterlund/8186476/webrev.01/ Full: http://cr.openjdk.java.net/~eosterlund/8186476/webrev.02/ Thanks, /Erik From erik.osterlund at oracle.com Tue Aug 22 14:08:42 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 22 Aug 2017 16:08:42 +0200 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: <315E2B87-91F1-4AD0-9BF9-DFE16CC8B2A1@oracle.com> Hi, I would go with #3. Thanks, /Erik > On 22 Aug 2017, at 04:33, David Holmes wrote: > >> On 22/08/2017 11:08 AM, Vladimir Kozlov wrote: >>> On 8/21/17 5:56 PM, David Holmes wrote: >>> Surprising lack of response to this. >> You need more? I and Aleksey replied. > > So I'm good on feedback quality, just lacking in quantity :) > > David > >> Vladimir >>> >>> Conservatism will likely dictate we go option #1 if we get no more feedback. >>> >>> Thanks, >>> David >>> >>>> On 2/08/2017 2:35 PM, David Holmes wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8185062 >>>> >>>> Is it time to completely remove runtime optimizations aimed at uniprocessor systems ie. >>>> >>>> if (os::is_MP()) { >>>> x(); >>>> } >>>> >>>> just becomes: >>>> >>>> x(); >>>> >>>> ? >>>> >>>> Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would be a problem? >>>> >>>> As outlined in the "bug" report there are three basic options: >>>> >>>> 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container environments) >>>> >>>> 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP macros. >>>> >>>> 3. Assume the universe is MP and only allow MP to be built >>>> >>>> Cheers, >>>> David >>>> ----- From aph at redhat.com Tue Aug 22 14:56:25 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Aug 2017 15:56:25 +0100 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <599C3965.4060000@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599C3965.4060000@oracle.com> Message-ID: <2bba0a39-6dda-3575-27d2-ffe396bc891a@redhat.com> On 22/08/17 15:02, Erik ?sterlund wrote: > Hi Andrew, > > On 2017-08-22 11:06, Andrew Haley wrote: >> On 21/08/17 14:10, Erik ?sterlund wrote: >>> When it comes to the proposed Atomic::add implementation, it seems to me >>> like the emulation of Atomic::add on jshort using jint is very similar >>> to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised >>> me a bit that Atomic::add of jshort does not share the same mechanism as >>> the generalized Atomic::cmpxchg of jbyte. >> Indeed. It also seems rather weird to jump through these hoops on >> targets which do have support for adds on jshort. Still, as you say >> it's only used in once place and I guess it doesn't hurt. I don't >> like the undefined behaviour there, though. It would be nice if there >> were none on targets with proper support. >> > > Is that a request or are you happy enough with the proposed solution? > In case it was really meant as a request, how about something like this? > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8186476/webrev.01/ > > Full: > http://cr.openjdk.java.net/~eosterlund/8186476/webrev.02/ Nope, that cure is worse than the disease, but thank you lots for trying. :-) I'd fix it at the source by merging those two fields and unpacking as required, but I guess there'd be some pushback. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.osterlund at oracle.com Tue Aug 22 17:02:10 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 22 Aug 2017 19:02:10 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <2bba0a39-6dda-3575-27d2-ffe396bc891a@redhat.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599C3965.4060000@oracle.com> <2bba0a39-6dda-3575-27d2-ffe396bc891a@redhat.com> Message-ID: Hi Andrew, > On 22 Aug 2017, at 16:56, Andrew Haley wrote: > >> On 22/08/17 15:02, Erik ?sterlund wrote: >> Hi Andrew, >> >>> On 2017-08-22 11:06, Andrew Haley wrote: >>>> On 21/08/17 14:10, Erik ?sterlund wrote: >>>> When it comes to the proposed Atomic::add implementation, it seems to me >>>> like the emulation of Atomic::add on jshort using jint is very similar >>>> to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised >>>> me a bit that Atomic::add of jshort does not share the same mechanism as >>>> the generalized Atomic::cmpxchg of jbyte. >>> Indeed. It also seems rather weird to jump through these hoops on >>> targets which do have support for adds on jshort. Still, as you say >>> it's only used in once place and I guess it doesn't hurt. I don't >>> like the undefined behaviour there, though. It would be nice if there >>> were none on targets with proper support. >>> >> >> Is that a request or are you happy enough with the proposed solution? >> In case it was really meant as a request, how about something like this? >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8186476/webrev.01/ >> >> Full: >> http://cr.openjdk.java.net/~eosterlund/8186476/webrev.02/ > > Nope, that cure is worse than the disease, but thank you lots for trying. > :-) You are welcome. The pleasure is mine! > I'd fix it at the source by merging those two fields and unpacking as > required, but I guess there'd be some pushback. Then for now I am happy with keeping it the way Kim proposed for now, if you are okay with that. Thanks, /Erik > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alexander.harlap at oracle.com Tue Aug 22 19:18:16 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Tue, 22 Aug 2017 15:18:16 -0400 Subject: Request for review JDK-/8182309 - [TESTBUG] GC locker test fails to allocate heap Message-ID: <4917d60c-26c7-378b-1583-cf7fc12b57fd@oracle.com> Please review change for JDK-8182309 - [TESTBUG] GC locker test fails to allocate heap. Change is located at http://cr.openjdk.java.net/~aharlap/8182309/webrev.00/ Proposition is to decrease required java heap size from 1500m to 1g. Tested by JPRT. Alex From david.holmes at oracle.com Wed Aug 23 02:06:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Aug 2017 12:06:03 +1000 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> Message-ID: <375df370-b935-514f-fbee-aba92a0fde2d@oracle.com> Hi Vladimir, On 22/08/2017 5:59 PM, Vladimir Ivanov wrote: > Looks good. On compiler-dev Gerard specifically asks: Can someone please review the "hotspot/src/cpu/sparc/vm/macroAssembler_sparc.cpp? file to determine whether we still need the three "save_frame_and_mov(0, Lmethod, Lmethod);? calls where the comment said it was needed by -Xprof? Do we leave those save_frame_and_mov() calls as is (and add comment as to why they are still needed), or can we change them into save_frame() calls? --- Can you clarify this please. Thanks, David > Best regards, > Vladimir Ivanov > > On 8/19/17 12:00 AM, Gerard Ziemski wrote: >> hi all, >> >> The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now >> it?s the time to remove the code and obsolete the -Xprof flag. >> >> Changes from rev1 to address David?s feedback: >> >> - obsoleted the flag (it?s still accepted, but ignored) >> - fixed copyright year in >> "src/os_cpu/linux_s390/vm/thread_linux_s390.hpp? >> - improved comment about the signal based suspend/resume mechanism in >> "os_*.cpp? files >> - removed entire comment from "src/os/solaris/vm/osThread_solaris.hpp" >> >> issue:? https://bugs.openjdk.java.net/browse/JDK-8173715 >> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot >> From glaubitz at physik.fu-berlin.de Wed Aug 23 09:19:48 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 23 Aug 2017 11:19:48 +0200 Subject: [RFR]: 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped Message-ID: Hi! While working on hotspot/src/os/linux/vm/os_linux.cpp to add new architectures for Zero, I noticed that the identifier strings for PowerPC 64 and PowerPC 64 LE are swapped: #if defined(VM_LITTLE_ENDIAN) {EM_PPC64, EM_PPC64, ELFCLASS64, ELFDATA2LSB, (char*)"Power PC 64"}, #else {EM_PPC64, EM_PPC64, ELFCLASS64, ELFDATA2MSB, (char*)"Power PC 64 LE"}, #endif The upper entry should have the string "PowerPC 64 LE" and the lower one "PowerPC 64", not vice versa. I already whipped up a patch and pushed the changeset to [1]. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186655/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Wed Aug 23 09:49:52 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 23 Aug 2017 11:49:52 +0200 Subject: [RFR]: 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped In-Reply-To: References: Message-ID: Hi John, Looks fine. Thanks for fixing. Best Regards, Thomas On Wed, Aug 23, 2017 at 11:19 AM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi! > > While working on hotspot/src/os/linux/vm/os_linux.cpp to add new > architectures for Zero, > I noticed that the identifier strings for PowerPC 64 and PowerPC 64 LE are > swapped: > > #if defined(VM_LITTLE_ENDIAN) > {EM_PPC64, EM_PPC64, ELFCLASS64, ELFDATA2LSB, (char*)"Power PC 64"}, > #else > {EM_PPC64, EM_PPC64, ELFCLASS64, ELFDATA2MSB, (char*)"Power PC 64 LE"}, > #endif > > The upper entry should have the string "PowerPC 64 LE" and the lower one > "PowerPC 64", not vice versa. > > I already whipped up a patch and pushed the changeset to [1]. > > Thanks, > Adrian > > [1] http://cr.openjdk.java.net/~glaubitz/8186655/webrev.00/ >> > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From aph at redhat.com Wed Aug 23 09:52:28 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Aug 2017 10:52:28 +0100 Subject: How to enable logging? Message-ID: <84f55db6-f82a-9d9e-2699-ec86a7bdb971@redhat.com> In ParallelSPCleanupTask::work I see: TraceTime timer(name, TRACETIME_LOG(Info, safepoint, cleanup)); How do I enable this log? I've been searching for documentation for the last hour or so. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From claes.redestad at oracle.com Wed Aug 23 09:54:54 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 23 Aug 2017 11:54:54 +0200 Subject: How to enable logging? In-Reply-To: <84f55db6-f82a-9d9e-2699-ec86a7bdb971@redhat.com> References: <84f55db6-f82a-9d9e-2699-ec86a7bdb971@redhat.com> Message-ID: <32c6e02a-e3a1-fc90-5e2c-8856d4115a7a@oracle.com> Try -Xlog:safepoint+cleanup /Claes On 2017-08-23 11:52, Andrew Haley wrote: > In ParallelSPCleanupTask::work I see: > > TraceTime timer(name, TRACETIME_LOG(Info, safepoint, cleanup)); > > How do I enable this log? I've been searching for documentation for the > last hour or so. Thanks. > From aph at redhat.com Wed Aug 23 10:03:18 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Aug 2017 11:03:18 +0100 Subject: How to enable logging? In-Reply-To: <32c6e02a-e3a1-fc90-5e2c-8856d4115a7a@oracle.com> References: <84f55db6-f82a-9d9e-2699-ec86a7bdb971@redhat.com> <32c6e02a-e3a1-fc90-5e2c-8856d4115a7a@oracle.com> Message-ID: <59f9350a-725f-d483-7680-c26aa9f476ea@redhat.com> On 23/08/17 10:54, Claes Redestad wrote: > Try -Xlog:safepoint+cleanup Woot! That seems to work. Is it the case, then, that you need *both* safepoint+cleanup logs to be enabled in order to see that info? Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From claes.redestad at oracle.com Wed Aug 23 10:08:47 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 23 Aug 2017 12:08:47 +0200 Subject: How to enable logging? In-Reply-To: <59f9350a-725f-d483-7680-c26aa9f476ea@redhat.com> References: <84f55db6-f82a-9d9e-2699-ec86a7bdb971@redhat.com> <32c6e02a-e3a1-fc90-5e2c-8856d4115a7a@oracle.com> <59f9350a-725f-d483-7680-c26aa9f476ea@redhat.com> Message-ID: Yes, or use wildcards: -Xlog:cleanup* -Xlog:safepoint* /Claes Andrew Haley skrev: (23 augusti 2017 12:03:18 CEST) >On 23/08/17 10:54, Claes Redestad wrote: >> Try -Xlog:safepoint+cleanup > >Woot! That seems to work. Is it the case, then, that you need *both* >safepoint+cleanup logs to be enabled in order to see that info? >Thanks. > >-- >Andrew Haley >Java Platform Lead Engineer >Red Hat UK Ltd. >EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From coleen.phillimore at oracle.com Wed Aug 23 11:42:34 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 23 Aug 2017 07:42:34 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <0bb19a38-7840-fe9e-b2e8-f5c6f96143ef@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <0bb19a38-7840-fe9e-b2e8-f5c6f96143ef@oracle.com> Message-ID: <2bf2287d-799c-b695-6b04-58d32e09c4af@oracle.com> On 8/17/17 9:31 PM, David Holmes wrote: > Hi Coleen, > > Not that you need another Review but this looks good to me :) > > One comment below - feel free to ignore. > > On 18/08/2017 3:32 AM, coleen.phillimore at oracle.com wrote: >> >> Maybe the links would help: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev > > src/share/vm/code/dependencies.cpp > > - assert(result == NULL || result->is_oop(), "must be"); > + assert(result == NULL || oopDesc::is_oop(result), "must be"); > > That could just use oopDesc::is_oop_or_null(result). There are a > number of places that could do this. No big deal though. Hi David, I did see these too. There were only about 8 obvious cases of these, so I changed them also. 2 were in comments. Thanks, Coleen > > Thanks, > David > ----- > >> bug link https://bugs.openjdk.java.net/browse/JDK-8160399 >> bug link https://bugs.openjdk.java.net/browse/JDK-8164984 >> >> >> On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >>> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >>> pointer can be verified >>> >>> Also included is: >>> 8164984: Improper use of is_oop in production code >>> >>> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >>> >>> >>> I also moved is_oop() to the .cpp file, which reduces the size of >>> fastdebug libjvm.so a little, since is_oop is only used for assert >>> and verification. >>> >>> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >>> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >>> >>> Ran all platforms nightly tests (still in progress but no new >>> failures). >>> >>> Sorry for the boring code review request. >>> >>> Thanks, >>> Coleen >> From glaubitz at physik.fu-berlin.de Wed Aug 23 12:23:48 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 23 Aug 2017 14:23:48 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code Message-ID: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> Hi! Currently, it's not possible to build Zero on linux-sparc as there are two instances in the code where sparc-specific code being included or linked against which is not available in the Zero build builds. The first instance is in src/share/vm/compiler/oopMap.cpp: #ifdef SPARC #include "vmreg_sparc.inline.hpp" #endif As it turns out, the header is not actually required in oooMap.cpp for native builds. None of the symbols defined in there are used in oooMap.cpp and my test builds showed that both on linux-sparc (native) as well as solaris-sparc the header doesn't seem to be necessary. However, while I was able to build on linux-sparc without any problems, I was unable to build on solaris-sparc - with or without the header removed. So, this should be reviewed by a OpenJDK Solaris developer just to be sure. The second instance is in src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: #ifdef SPARC // SPARC requires special handling. See SPARC-specific definition. #else // All others just use memset. inline void memset_with_concurrent_readers(void* to, int value, size_t size) { ::memset(to, value, size); } #endif // End of target dispatch. The definition here comes from ./src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp when compiling on sparc. However, when building Zero, this particular source is not built and hence memset_with_concurrent_readers is not available when building Zero on sparc. In this case, I just decided not to use the sparc version when ZERO is defined. Webrev for the suggested changes in [1]. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Wed Aug 23 12:25:01 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 23 Aug 2017 08:25:01 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: <7DA6F743-EC44-4AE9-A3DC-B2EDC3744BF4@twitter.com> References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> <126f0e3c-d30f-f2da-9bec-9153c4ce3110@oracle.com> <1990779c-f3b8-2bbb-5d1a-2a031cb158d9@oracle.com> <7DA6F743-EC44-4AE9-A3DC-B2EDC3744BF4@twitter.com> Message-ID: On 8/18/17 3:31 AM, Christian Thalinger wrote: > >> On Aug 15, 2017, at 4:56 AM, coleen.phillimore at oracle.com >> wrote: >> >> >> >> On 8/14/17 8:26 PM, David Holmes wrote: >>> On 15/08/2017 9:46 AM,coleen.phillimore at oracle.com >>> wrote: >>>> >>>> Better yet, I removed the _pd field assignment from being >>>> cmpxchg/conditional and do it under the metaspace_lock which we >>>> take out anyway to add the handle. How is this? >>>> >>>> open webrev athttp://cr.openjdk.java.net/~coleenp/8186088.03/webrev >>>> >>> >>> I like the fact OopHandle no longer has atomics. :) >> >> Yes, this solved a bunch of problems. > > Do you still need this: > > 32 class outputStream; No I don't. I may have had a print function at one point. Thanks for having a look. Coleen > > ? > >>> >>> Sorry I'm being a bit dense today when it comes to this code: >>> >>> ! void ClassLoaderData::init_handle_locked(OopHandle& dest, Handle h) { >>> ! MutexLockerEx ml(metaspace_lock(), Mutex::_no_safepoint_check_flag); >>> ! if (dest.resolve() != NULL) { >>> ! return; >>> ! } else { >>> ! dest = _handles.add(h()); >>> ! } >>> } >>> >>> I would have expected to see something like dest.set(x). I'm not >>> sure what magic operator= is doing behind the scenes here ?? >> >> It's doing a bitwise copy. >>> >>> I did check the code that calls this, and the locking seems safe in >>> that context. >>> >> >> Thanks. It's a lot better now. >> Coleen >>> Thanks, >>> David >>> >>>> I reran the tests that use this code. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 8/14/17 4:36 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 15/08/2017 1:38 AM, coleen.phillimore at oracle.com >>>>> wrote: >>>>>> >>>>>> >>>>>> On 8/13/17 9:04 PM, David Holmes wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com >>>>>>> wrote: >>>>>>>> Summary: Make an OopHandle type to replace jobject to >>>>>>>> encapsulate these oop pointers in metadata and module entry. >>>>>>>> >>>>>>>> This replaces places where there's a jobject that doesn't point >>>>>>>> into the JNIHandles, notably things allocated in >>>>>>>> ClassLoaderData::_handles. >>>>>>>> >>>>>>>> There were platform specific changes that I tried to carefully >>>>>>>> make - can someone test them for s390, aarch64 and ppc? >>>>>>>> >>>>>>>> Tested with tier1 testing, JPRT (all oracle platforms), >>>>>>>> nsk.jvmti, monitoring, parallel class loading and g1class >>>>>>>> unloading tests. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>>>>>> >>>>>>> Is it possible to put the declaration of >>>>>>> MacroAssembler::resolve_oop_handle into the shared >>>>>>> macroAssembler.hpp file to avoid the need to add it to the >>>>>>> platform specific hpp files? >>>>>>> >>>>>>> I'm unsure about the OopHandle containing set_atomic. First if >>>>>>> it is present then the _obj field should be volatile. But then >>>>>>> it also raises the question: if we can race to set this, do we >>>>>>> need load-acquire versions of the accessors? Based on the single >>>>>>> existing usage I don't think we presently do. But I think it may >>>>>>> be cleaner/simpler to not have set_atomic, make the OopHandle >>>>>>> immutable, and do the cmpxchg back in the caller code by >>>>>>> atomically updating _pd (which should also be volatile even >>>>>>> today) with a new OopHandle. >>>>>> >>>>>> I couldn't convince the compiler to compile an >>>>>> Atomic::cmpxchg_ptr() to an address of OopHandle since it is not >>>>>> a pointer but a struct. The >>>>> >>>>> _pd would have to be a pointer. >>>>> >>>>>> casting would be wrong. So I added a resolve_acquire() for the >>>>>> protection_domain case in ModuleEntry, and some commentary. >>>>> >>>>> For completeness you may also need ptr_acquire(). >>>>> >>>>> The _obj field should be volatile. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >>>>>> >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen > From coleen.phillimore at oracle.com Wed Aug 23 12:26:15 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 23 Aug 2017 08:26:15 -0400 Subject: RFR (M) 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle In-Reply-To: References: <18d7ff68-3f3f-ebba-dbd2-6c7d3df3ee23@oracle.com> <4e13cb72-2d8c-2aae-6860-a98ceb977f28@oracle.com> Message-ID: <135c4721-50b9-a863-e842-19c0ebff066e@oracle.com> On 8/14/17 4:04 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Looks good. > > http://cr.openjdk.java.net/~coleenp/8186088.02/webrev/src/share/vm/oops/oopHandle.hpp.html > > > There is unneeded space after the const: > > 50 oop resolve() const { return (_obj == NULL) ? (oop)NULL > : *_obj; } Thanks, Serguei. I fixed these spaces. Lining up these functions did not look good. Thanks, Coleen > > > Thanks, > Serguei > > > On 8/14/17 08:38, coleen.phillimore at oracle.com wrote: >> >> >> On 8/13/17 9:04 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 12/08/2017 7:34 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make an OopHandle type to replace jobject to encapsulate >>>> these oop pointers in metadata and module entry. >>>> >>>> This replaces places where there's a jobject that doesn't point >>>> into the JNIHandles, notably things allocated in >>>> ClassLoaderData::_handles. >>>> >>>> There were platform specific changes that I tried to carefully make >>>> - can someone test them for s390, aarch64 and ppc? >>>> >>>> Tested with tier1 testing, JPRT (all oracle platforms), nsk.jvmti, >>>> monitoring, parallel class loading and g1class unloading tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186088 >>> >>> Is it possible to put the declaration of >>> MacroAssembler::resolve_oop_handle into the shared >>> macroAssembler.hpp file to avoid the need to add it to the platform >>> specific hpp files? >>> >>> I'm unsure about the OopHandle containing set_atomic. First if it is >>> present then the _obj field should be volatile. But then it also >>> raises the question: if we can race to set this, do we need >>> load-acquire versions of the accessors? Based on the single existing >>> usage I don't think we presently do. But I think it may be >>> cleaner/simpler to not have set_atomic, make the OopHandle >>> immutable, and do the cmpxchg back in the caller code by atomically >>> updating _pd (which should also be volatile even today) with a new >>> OopHandle. >> >> I couldn't convince the compiler to compile an Atomic::cmpxchg_ptr() >> to an address of OopHandle since it is not a pointer but a struct. >> The casting would be wrong. So I added a resolve_acquire() for the >> protection_domain case in ModuleEntry, and some commentary. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186088.02/webrev >> >> thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> >> > From david.holmes at oracle.com Wed Aug 23 12:35:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Aug 2017 22:35:33 +1000 Subject: [RFR]: 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped In-Reply-To: References: Message-ID: <28e3d564-a400-6520-fd40-f2f58b0f76d9@oracle.com> Looks good. I will sponsor this for you tomorrow. Thanks, David On 23/08/2017 7:19 PM, John Paul Adrian Glaubitz wrote: > Hi! > > While working on hotspot/src/os/linux/vm/os_linux.cpp to add new > architectures for Zero, > I noticed that the identifier strings for PowerPC 64 and PowerPC 64 LE > are swapped: > > #if defined(VM_LITTLE_ENDIAN) > ??? {EM_PPC64, EM_PPC64, ELFCLASS64, ELFDATA2LSB, (char*)"Power PC 64"}, > #else > ??? {EM_PPC64, EM_PPC64, ELFCLASS64, ELFDATA2MSB, (char*)"Power PC 64 > LE"}, > #endif > > The upper entry should have the string "PowerPC 64 LE" and the lower one > "PowerPC 64", not vice versa. > > I already whipped up a patch and pushed the changeset to [1]. > > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186655/webrev.00/ > From david.holmes at oracle.com Wed Aug 23 12:38:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Aug 2017 22:38:54 +1000 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> Message-ID: <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> Hi Adrian, These changes seem fine to me. I will sponsor this for you once we have a second reviewer. If there are any issues with Solaris builds I'll find them and come back to you. :) Thanks, David On 23/08/2017 10:23 PM, John Paul Adrian Glaubitz wrote: > Hi! > > Currently, it's not possible to build Zero on linux-sparc as there are two > instances in the code where sparc-specific code being included or linked > against which is not available in the Zero build builds. > > The first instance is in src/share/vm/compiler/oopMap.cpp: > > ?#ifdef SPARC > ?#include "vmreg_sparc.inline.hpp" > ?#endif > > As it turns out, the header is not actually required in oooMap.cpp for > native builds. None of the symbols defined in there are used in oooMap.cpp > and my test builds showed that both on linux-sparc (native) as well > as solaris-sparc the header doesn't seem to be necessary. However, while > I was able to build on linux-sparc without any problems, I was unable > to build on solaris-sparc - with or without the header removed. So, this > should be reviewed by a OpenJDK Solaris developer just to be sure. > > The second instance is in > src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > > #ifdef SPARC > > // SPARC requires special handling.? See SPARC-specific definition. > > #else > // All others just use memset. > > inline void memset_with_concurrent_readers(void* to, int value, size_t > size) { > ? ::memset(to, value, size); > } > > #endif // End of target dispatch. > > The definition here comes from > ./src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp > when compiling on sparc. However, when building Zero, this particular > source > is not built and hence memset_with_concurrent_readers is not available when > building Zero on sparc. In this case, I just decided not to use the > sparc version when ZERO is defined. > > Webrev for the suggested changes in [1]. > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/ > From glaubitz at physik.fu-berlin.de Wed Aug 23 12:42:34 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 23 Aug 2017 14:42:34 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> Message-ID: <28d14f9f-f011-4fd3-f9e8-d489fa45ee95@physik.fu-berlin.de> Hi David! On 08/23/2017 02:38 PM, David Holmes wrote: > These changes seem fine to me. I will sponsor this for you once we > have a second reviewer. If there are any issues with Solaris builds > I'll find them and come back to you. :) Ok, great. Thank you! For the record, trying to build on Solaris 11.1 with Solaris Studi 12.3 always fails for me with: === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_gtest_objs_gtest-all.o: "/home/sysadmin/hs/test/fmw/gtest/src/gtest-printers.cc", line 268: Error, nomatchoverin: Could not find a match for PrintAsStringLiteralTo needed in testing::internal::PrintCharsAsStringTo(const char*, unsigned long, std::ostream *). "/home/sysadmin/hs/test/fmw/gtest/src/gtest-printers.cc", line 315: Where, temwhileinst: While instantiating "testing::internal::PrintCharsAsStringTo(const char*, unsigned long, std::ostream *)". "/home/sysadmin/hs/test/fmw/gtest/src/gtest-printers.cc", line 315: Where, teminstend: Instantiated from non-template code. 1 Error(s) detected. * All command lines available in /home/sysadmin/hs/build/solaris-sparcv9-normal-server-release/make-support/failure-logs. === End of repeated output === Independent whether I apply this particular changeset or not. I just built with: $ sh ./configure --with-boot-jdk=/home/sysadmin/jdk1.8.0_144/ --with-jvm-variants=server $ gmake Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From gunter.haug at sap.com Wed Aug 23 13:40:00 2017 From: gunter.haug at sap.com (Haug, Gunter) Date: Wed, 23 Aug 2017 13:40:00 +0000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: <4f0f1741-95d2-5e00-8482-8c102f5d9a3d@oracle.com> References: <4f0f1741-95d2-5e00-8482-8c102f5d9a3d@oracle.com> Message-ID: Hi David, Sorry for the late reply! I have corrected the typos and updated the change, here is the new webrev: http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v2 Would you mind sponsoring it? Re not using os::vm_page_size(): You?re right, and I thought the same - it?s certainly correct for the primary thread. However, os::vm_page_size() isn?t used in the function and I think it?s not much of a problem to call getpagesize() in this particular case. Thanks and best regards, Gunter On 18.08.17, 06:18, "David Holmes" wrote: Hi Thomas, On 18/08/2017 1:59 PM, Thomas St?fe wrote: > Hi David, > > On Thu, Aug 17, 2017 at 11:54 PM, David Holmes > wrote: > > Hi Gunter, > > On 18/08/2017 1:01 AM, Haug, Gunter wrote: > > Thanks for the review, Aleksey and Thomas > > You?re right, it is much nicer to use the macros. I?ve updated > the change accordingly: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 > > > > I'm unclear about the logic change here. If you round down then > there is a chance you will enter the following if-block where > otherwise you would not. > > 915 *size = align_down(*size, getpagesize()); > 916 > 917 if ((*size) < (DEFAULT_MAIN_THREAD_STACK_PAGES * > (size_t)getpagesize())) { > > > I don't see how this could happen? Gunters fix causes the size to snap > to the lower page boundary, but never cross it. The code below ensures a > lower cap at a page boundary. Yes you are right - sorry for the noise. David > If size was larger than that cap, after the align_down it will be at > most right at that cap. If it was lower than the cap, it stays lower. In > both cases behavior is unchanged. > > Cheers, Thomas > > Have you verified with a range of aligned and unaligned stack sizes > around that threshhold that everything works okay? > > Some typos in the comment block: > > alligned -> aligned > boundries -> boundaries > I round -> We round > > @Thomas: os::vm_page_size() is not used in > current_stack_region(), I think because of initialization > dependencies. > > > I don't see the dependency. It requires that it only be used after > os::init() has been called. AFAICS the first time we will use this > logic is when we attach the main thread, which happens after > os::init(). > > Thanks, > David > > Best regards, > Gunter > > From: Thomas St?fe > > Date: Thursday, 17. August 2017 at 15:06 > To: "Haug, Gunter" > > Cc: "hotspot-dev at openjdk.java.net > " > > > Subject: Re: RFR(S): 8186286: [BSD] Primary thread's stack size > is reported incorrectly > > Hi Gunter, > > > On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter > >> wrote: > Hi, > > can I please have reviews and a sponsor fort the following small > bug fix: > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ > > https://bugs.openjdk.java.net/browse/JDK-8186286 > > > At least on Mac OS 10.12 we have observed stack sizes of the > primary thread not aligned to pages boundries. This can be > provoked by e.g. setrlimit() (ulimit -s xxxx in the shell).This > voids the computation of the addresses of the guard pages. > > Fix: > Apparently Mac OS actually rounds upwards to next multiple of > page size however, it is conservative to round downwards here to > be on the safe side. > > Thanks and best regards, > Gunter > > Thanks for the patch! > > Very minor nits: what Alexey wrote (we also have "is_aligned"). > Plus, any reason not to use os::vm_page_size()? Initialization > dependencies? > > Kind Regards, Thomas > > > > From volker.simonis at gmail.com Wed Aug 23 15:29:13 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 23 Aug 2017 17:29:13 +0200 Subject: RFR(XXS): 8186667: InterpreterCodeSize overflows on AIX Message-ID: Hi, can somebody please review this tiny fix which only affects the ppc64 platforms: http://cr.openjdk.java.net/~simonis/webrevs/2017/8186667/ https://bugs.openjdk.java.net/browse/JDK-8186667 The fix for JDK-8172020 increased some interpreter entry points (notably the return entry points) considerably because it added special handling for popframe/earlyreturn in cases where debugging is enabled. This was just enough to overflow the current InterpreterCodeSize on AIX/ppc64 which was 230K until now: # Internal Error (interpreter.hpp:105), pid=16449790, tid=258 # guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Apparently we've only done debugging tests on jdk10 (and not jdk10-hs) so we've only noticed this now after jdk10-hs was integrated into jdk10. As solution I propose to set InterpreterCodeSize to 256K on ppc64 to be on the safe side again. Thank you and best regards, Volker From coleen.phillimore at oracle.com Wed Aug 23 16:17:44 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 23 Aug 2017 12:17:44 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: <661e7992-b25c-74fb-d76d-2769675f5998@oracle.com> References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <661e7992-b25c-74fb-d76d-2769675f5998@oracle.com> Message-ID: Thanks George! Coleen On 8/17/17 5:09 PM, George Triantafillou wrote: > Hi Coleen, > > Looks good. > > -George > > On 8/17/2017 1:32 PM, coleen.phillimore at oracle.com wrote: >> >> Maybe the links would help: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160399.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8160399 >> bug link https://bugs.openjdk.java.net/browse/JDK-8164984 >> >> >> On 8/17/17 1:21 PM, coleen.phillimore at oracle.com wrote: >>> Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this >>> pointer can be verified >>> >>> Also included is: >>> 8164984: Improper use of is_oop in production code >>> >>> http://cr.openjdk.java.net/~coleenp/8160399.01/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html >>> >>> >>> I also moved is_oop() to the .cpp file, which reduces the size of >>> fastdebug libjvm.so a little, since is_oop is only used for assert >>> and verification. >>> >>> before: -rw-r--r-- 1 cphillim 35086408 Aug 17 12:08 libjvm.so >>> after: -rw-r--r-- 1 cphillim 35073384 Aug 17 12:12 libjvm.so >>> >>> Ran all platforms nightly tests (still in progress but no new >>> failures). >>> >>> Sorry for the boring code review request. >>> >>> Thanks, >>> Coleen >> > From volker.simonis at gmail.com Wed Aug 23 16:30:04 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 23 Aug 2017 18:30:04 +0200 Subject: RFR(XXS): 8186667: InterpreterCodeSize overflows on AIX In-Reply-To: References: Message-ID: Hi Goetz, thanks for the review. Just pushed the change to jdk10/hs. I'm also forwarding this mail with your review to the corresponding mailing lists as I've just noticed that you've only sent it to me. Regards, Volker On Wed, Aug 23, 2017 at 5:47 PM, Lindenmaier, Goetz wrote: > Hi Volker, > > The change looks good, thanks. > > Best regards, G?tz > >> Am 23.08.2017 um 17:33 schrieb Volker Simonis : >> >> Hi, >> >> can somebody please review this tiny fix which only affects the ppc64 platforms: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8186667/ >> https://bugs.openjdk.java.net/browse/JDK-8186667 >> >> The fix for JDK-8172020 increased some interpreter entry points >> (notably the return entry points) considerably because it added >> special handling for popframe/earlyreturn in cases where debugging is >> enabled. >> >> This was just enough to overflow the current InterpreterCodeSize on >> AIX/ppc64 which was 230K until now: >> >> # Internal Error (interpreter.hpp:105), pid=16449790, tid=258 >> # guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: >> not enough space for interpreter generation >> >> Apparently we've only done debugging tests on jdk10 (and not jdk10-hs) >> so we've only noticed this now after jdk10-hs was integrated into >> jdk10. >> >> As solution I propose to set InterpreterCodeSize to 256K on ppc64 to >> be on the safe side again. >> >> Thank you and best regards, >> Volker From coleen.phillimore at oracle.com Wed Aug 23 17:18:50 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 23 Aug 2017 13:18:50 -0400 Subject: RFR (L, tedious) 8160399: is_oop_or_null involves undefined behavior In-Reply-To: References: <7de77835-fb30-8c3c-039b-456f8eabdd31@oracle.com> <7c451612-183b-7dfa-b69a-dd18ba4b4d03@oracle.com> <2dfdcaf1-13cb-1f03-85ac-91935cded254@oracle.com> <6ACE3C3E-4FAC-48DB-9777-5609F1D766E0@oracle.com> Message-ID: On 8/18/17 2:31 AM, Stefan Karlsson wrote: > On 2017-08-18 01:47, Kim Barrett wrote: >>> On Aug 17, 2017, at 7:30 PM, Stefan Karlsson >>> wrote: >>> >>> Hi Coleen, >>> >>> Could you motivate why you changed is_oop() to a static functions? >> >> Quoting myself from a comment in 8160399: >> >> For it [is_oop] to fail one has to take a non-oop, make it appear to >> be an oop, and >> call an oop member function on that not really an oop. That sounds >> like UB to me. >> > > So, what about the implementation of is_oop(): > > 536 // used only for asserts and guarantees > 537 inline bool oopDesc::is_oop(oop obj, bool ignore_mark_word) { > > 538 if (!check_obj_alignment(obj)) return false; > 539 if (!Universe::heap()->is_in_reserved(obj)) return false; > 540 // obj is aligned and accessible in heap > 541 if (Universe::heap()->is_in_reserved(obj->klass_or_null())) > return false; > 542 > 543 // Header verification: the mark is typically non-NULL. If we're > 544 // at a safepoint, it must not be null. > 545 // Outside of a safepoint, the header could be changing (for > example, > 546 // another thread could be inflating a lock on this object). > 547 if (ignore_mark_word) { > 548 return true; > 549 } > 550 if (obj->mark() != NULL) { > 551 return true; > 552 } > 553 return !SafepointSynchronize::is_at_safepoint(); > 554 } > > It calls both obj->klass_or_null() and obj->mark(). Shouldn't those > calls be considered UB as well? Should we fix those calls? Hm, yes, we should probably fix them to use SafeFetchN(*(obj+8)_ and compare vtable for the address of the Klass pointer. Looking at this code and callers, it seems the test for is_in_reserved(obj) is the most useful part of this code. I could file an RFE to fix this UB inside of oopDesc::is_oop(). I think the usefulness of this change is that the UB isn't at each call site. thanks, Coleen > > StefanK > >> From doug.simon at oracle.com Wed Aug 23 17:40:25 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 23 Aug 2017 19:40:25 +0200 Subject: RFR(XXS): 8186667: InterpreterCodeSize overflows on AIX In-Reply-To: References: Message-ID: We ran into similar problems while developing JVMCI and I suggested that InterpreterCodeSize should be computed: https://bugs.openjdk.java.net/browse/JDK-8166317 Unfortunately, the runtime team closed it with "will not fix". -Doug > On 23 Aug 2017, at 18:30, Volker Simonis wrote: > > Hi Goetz, > > thanks for the review. Just pushed the change to jdk10/hs. > > I'm also forwarding this mail with your review to the corresponding > mailing lists as I've just noticed that you've only sent it to me. > > Regards, > Volker > > > On Wed, Aug 23, 2017 at 5:47 PM, Lindenmaier, Goetz > wrote: >> Hi Volker, >> >> The change looks good, thanks. >> >> Best regards, G?tz >> >>> Am 23.08.2017 um 17:33 schrieb Volker Simonis : >>> >>> Hi, >>> >>> can somebody please review this tiny fix which only affects the ppc64 platforms: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8186667/ >>> https://bugs.openjdk.java.net/browse/JDK-8186667 >>> >>> The fix for JDK-8172020 increased some interpreter entry points >>> (notably the return entry points) considerably because it added >>> special handling for popframe/earlyreturn in cases where debugging is >>> enabled. >>> >>> This was just enough to overflow the current InterpreterCodeSize on >>> AIX/ppc64 which was 230K until now: >>> >>> # Internal Error (interpreter.hpp:105), pid=16449790, tid=258 >>> # guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: >>> not enough space for interpreter generation >>> >>> Apparently we've only done debugging tests on jdk10 (and not jdk10-hs) >>> so we've only noticed this now after jdk10-hs was integrated into >>> jdk10. >>> >>> As solution I propose to set InterpreterCodeSize to 256K on ppc64 to >>> be on the safe side again. >>> >>> Thank you and best regards, >>> Volker From daniel.daugherty at oracle.com Wed Aug 23 19:49:40 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Aug 2017 13:49:40 -0600 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: References: Message-ID: <1aae9d33-2cfb-2428-fb32-0c6e8e44d1a8@oracle.com> Vote: option #3 Dan On 8/21/17 6:56 PM, David Holmes wrote: > Surprising lack of response to this. > > Conservatism will likely dictate we go option #1 if we get no more > feedback. > > Thanks, > David > > On 2/08/2017 2:35 PM, David Holmes wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185062 >> >> Is it time to completely remove runtime optimizations aimed at >> uniprocessor systems ie. >> >> if (os::is_MP()) { >> ?? x(); >> } >> >> just becomes: >> >> x(); >> >> ? >> >> Does anyone care about uniprocessor systems _and_ care to the extent >> that the overhead of things only necessary on MP systems (_lock >> prefixes, explicit atomic instructions, memory barriers) would be a >> problem? >> >> As outlined in the "bug" report there are three basic options: >> >> 1. Switch AssumeMP to be true by default (arguably necessary >> regardless due to dynamic container environments) >> >> 2. Allow non-MP support to be built, but by default only build MP >> support ie no runtime means to disable MP support, and compile-time >> MP_ONLY/NOT_MP macros. >> >> 3. Assume the universe is MP and only allow MP to be built >> >> Cheers, >> David >> ----- From martinrb at google.com Wed Aug 23 21:25:50 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Aug 2017 14:25:50 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8174050 http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer-sign-comparison/ My webrev could go in as is, but better would be for someone to figure out the intent of the nonsensical assert in src/share/vm/opto/loopPredicate.cpp (There is more to be done to support clang, but this is enough to build openjdk without patching source) From vladimir.kozlov at oracle.com Wed Aug 23 22:39:13 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 15:39:13 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: Message-ID: Thank you, Martin Yes, sign compare is bad for pointers. Note, for pointers compare with use NULL instead of 0. Please, use NULL. The assert check in loopPredicate.cpp is simple missing reference to field _lo (low bound of values range): _igvn.type(rng)->is_int()->_lo >= 0 Please, fix it this way. Thanks, Vladimir On 8/23/17 2:25 PM, Martin Buchholz wrote: > https://bugs.openjdk.java.net/browse/JDK-8174050 > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer-sign-comparison/ > > My webrev could go in as is, but better would be for someone to figure out > the intent of the nonsensical assert in > > src/share/vm/opto/loopPredicate.cpp > > (There is more to be done to support clang, but this is enough to build > openjdk without patching source) > From martinrb at google.com Wed Aug 23 23:37:01 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Aug 2017 16:37:01 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: Message-ID: Thanks, Vladimir. Webrev regenerated. I blindly coded - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= 0, "must be");+ assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo >= 0, "must be"); On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov wrote: > Thank you, Martin > > Yes, sign compare is bad for pointers. > > Note, for pointers compare with use NULL instead of 0. Please, use NULL. > > The assert check in loopPredicate.cpp is simple missing reference to field > _lo (low bound of values range): > > _igvn.type(rng)->is_int()->_lo >= 0 > > Please, fix it this way. > > Thanks, > Vladimir > > > On 8/23/17 2:25 PM, Martin Buchholz wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8174050 >> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >> -sign-comparison/ >> >> My webrev could go in as is, but better would be for someone to figure out >> the intent of the nonsensical assert in >> >> src/share/vm/opto/loopPredicate.cpp >> >> (There is more to be done to support clang, but this is enough to build >> openjdk without patching source) >> >> From vladimir.kozlov at oracle.com Wed Aug 23 23:46:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 16:46:17 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: Message-ID: Looks good to me. Thanks, Vladimir On 8/23/17 4:37 PM, Martin Buchholz wrote: > Thanks, Vladimir. > Webrev regenerated. > > I blindly coded > > - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= > 0, "must be"); > + assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo > >= 0, "must be"); > > > > On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov > > wrote: > > Thank you, Martin > > Yes, sign compare is bad for pointers. > > Note, for pointers compare with use NULL instead of 0. Please, use NULL. > > The assert check in loopPredicate.cpp is simple missing reference to > field _lo (low bound of values range): > > ?_igvn.type(rng)->is_int()->_lo >= 0 > > Please, fix it this way. > > Thanks, > Vladimir > > > On 8/23/17 2:25 PM, Martin Buchholz wrote: > > https://bugs.openjdk.java.net/browse/JDK-8174050 > > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer-sign-comparison/ > > > My webrev could go in as is, but better would be for someone to > figure out > the intent of the nonsensical assert in > > src/share/vm/opto/loopPredicate.cpp > > (There is more to be done to support clang, but this is enough > to build > openjdk without patching source) > > From martinrb at google.com Thu Aug 24 00:02:41 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Aug 2017 17:02:41 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: Message-ID: I assume I need a sponsor; if so, please import http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer-sign-comparison/pointer-sign-comparison.patch On Wed, Aug 23, 2017 at 4:46 PM, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 8/23/17 4:37 PM, Martin Buchholz wrote: > >> Thanks, Vladimir. >> Webrev regenerated. >> >> I blindly coded >> >> - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= 0, >> "must be"); >> + assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo >> >= 0, "must be"); >> >> >> >> On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov < >> vladimir.kozlov at oracle.com > wrote: >> >> Thank you, Martin >> >> Yes, sign compare is bad for pointers. >> >> Note, for pointers compare with use NULL instead of 0. Please, use >> NULL. >> >> The assert check in loopPredicate.cpp is simple missing reference to >> field _lo (low bound of values range): >> >> _igvn.type(rng)->is_int()->_lo >= 0 >> >> Please, fix it this way. >> >> Thanks, >> Vladimir >> >> >> On 8/23/17 2:25 PM, Martin Buchholz wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8174050 >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >> -sign-comparison/ >> > r-sign-comparison/> >> >> My webrev could go in as is, but better would be for someone to >> figure out >> the intent of the nonsensical assert in >> >> src/share/vm/opto/loopPredicate.cpp >> >> (There is more to be done to support clang, but this is enough >> to build >> openjdk without patching source) >> >> >> From vladimir.kozlov at oracle.com Thu Aug 24 00:48:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 17:48:45 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: Message-ID: <2f74f72a-92d1-3a04-bb3a-90bacc79b7d8@oracle.com> I submitted pre-integration testing. Vladimir On 8/23/17 5:02 PM, Martin Buchholz wrote: > I assume I need a sponsor; if so, please import > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer-sign-comparison/pointer-sign-comparison.patch > > On Wed, Aug 23, 2017 at 4:46 PM, Vladimir Kozlov > wrote: > >> Looks good to me. >> >> Thanks, >> Vladimir >> >> On 8/23/17 4:37 PM, Martin Buchholz wrote: >> >>> Thanks, Vladimir. >>> Webrev regenerated. >>> >>> I blindly coded >>> >>> - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= 0, >>> "must be"); >>> + assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo >>>> = 0, "must be"); >>> >>> >>> >>> On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov < >>> vladimir.kozlov at oracle.com > wrote: >>> >>> Thank you, Martin >>> >>> Yes, sign compare is bad for pointers. >>> >>> Note, for pointers compare with use NULL instead of 0. Please, use >>> NULL. >>> >>> The assert check in loopPredicate.cpp is simple missing reference to >>> field _lo (low bound of values range): >>> >>> _igvn.type(rng)->is_int()->_lo >= 0 >>> >>> Please, fix it this way. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 8/23/17 2:25 PM, Martin Buchholz wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8174050 >>> >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >>> -sign-comparison/ >>> >> r-sign-comparison/> >>> >>> My webrev could go in as is, but better would be for someone to >>> figure out >>> the intent of the nonsensical assert in >>> >>> src/share/vm/opto/loopPredicate.cpp >>> >>> (There is more to be done to support clang, but this is enough >>> to build >>> openjdk without patching source) >>> >>> >>> From martinrb at google.com Thu Aug 24 02:33:54 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Aug 2017 19:33:54 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: <2f74f72a-92d1-3a04-bb3a-90bacc79b7d8@oracle.com> References: <2f74f72a-92d1-3a04-bb3a-90bacc79b7d8@oracle.com> Message-ID: during ad hoc testing I saw the crash below, so this assert needs more work (but great job on the error reporting here!) [2017-08-23 19:29:22,374] Agent[0]: stdout: # To suppress the following error report, specify this argument [2017-08-23 19:29:22,390] Agent[0]: stdout: # after -XX: or in .hotspotrc: SuppressErrorAt=/loopPredicate.cpp:915 [2017-08-23 19:29:22,391] Agent[0]: stdout: # [2017-08-23 19:29:22,392] Agent[0]: stdout: # A fatal error has been detected by the Java Runtime Environment: [2017-08-23 19:29:22,399] Agent[0]: stdout: # [2017-08-23 19:29:22,400] Agent[0]: stdout: # Internal Error (/home/martin/ws/jdk10-clang-4.0/hotspot/src/share/vm/opto/loopPredicate.cpp:915), pid=31347, tid=31367 [2017-08-23 19:29:22,400] Agent[0]: stdout: # assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo >= 0) failed: must be On Wed, Aug 23, 2017 at 5:48 PM, Vladimir Kozlov wrote: > I submitted pre-integration testing. > > Vladimir > > > On 8/23/17 5:02 PM, Martin Buchholz wrote: > >> I assume I need a sponsor; if so, please import >> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >> -sign-comparison/pointer-sign-comparison.patch >> >> On Wed, Aug 23, 2017 at 4:46 PM, Vladimir Kozlov < >> vladimir.kozlov at oracle.com >> >>> wrote: >>> >> >> Looks good to me. >>> >>> Thanks, >>> Vladimir >>> >>> On 8/23/17 4:37 PM, Martin Buchholz wrote: >>> >>> Thanks, Vladimir. >>>> Webrev regenerated. >>>> >>>> I blindly coded >>>> >>>> - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= >>>> 0, >>>> "must be"); >>>> + assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo >>>> >>>>> = 0, "must be"); >>>>> >>>> >>>> >>>> >>>> On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov < >>>> vladimir.kozlov at oracle.com > wrote: >>>> >>>> Thank you, Martin >>>> >>>> Yes, sign compare is bad for pointers. >>>> >>>> Note, for pointers compare with use NULL instead of 0. Please, use >>>> NULL. >>>> >>>> The assert check in loopPredicate.cpp is simple missing reference >>>> to >>>> field _lo (low bound of values range): >>>> >>>> _igvn.type(rng)->is_int()->_lo >= 0 >>>> >>>> Please, fix it this way. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 8/23/17 2:25 PM, Martin Buchholz wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8174050 >>>> >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >>>> -sign-comparison/ >>>> >>> r-sign-comparison/> >>>> >>>> My webrev could go in as is, but better would be for someone to >>>> figure out >>>> the intent of the nonsensical assert in >>>> >>>> src/share/vm/opto/loopPredicate.cpp >>>> >>>> (There is more to be done to support clang, but this is enough >>>> to build >>>> openjdk without patching source) >>>> >>>> >>>> >>>> From vladimir.kozlov at oracle.com Thu Aug 24 04:16:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 21:16:08 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: <2f74f72a-92d1-3a04-bb3a-90bacc79b7d8@oracle.com> Message-ID: I also hit this failure. The code which guards this assert has additional condition "&& !iff->is_RangeCheck()" due to which no check for positive value happened: http://hg.openjdk.java.net/jdk10/hs/hotspot/file/821ef7c10085/src/share/vm/opto/loopPredicate.cpp#l590 I think we should check for RangeCheck node in assert: assert(rng->Opcode() == Op_LoadRange || iff->is_RangeCheck() || _igvn.type(rng)->is_int() >= 0, "must be"); RangeCheck has dynamic check that range is positive. I think it should be safe to relax this assert. Thanks, Vladimir On 8/23/17 7:33 PM, Martin Buchholz wrote: > during ad hoc testing I saw the crash below, so this assert needs more work > (but great job on the error reporting here!) > > [2017-08-23 19:29:22,374] Agent[0]: stdout: # To suppress the following > error report, specify this argument > [2017-08-23 19:29:22,390] Agent[0]: stdout: # after -XX: or in .hotspotrc: > SuppressErrorAt=/loopPredicate.cpp:915 > [2017-08-23 19:29:22,391] Agent[0]: stdout: # > [2017-08-23 19:29:22,392] Agent[0]: stdout: # A fatal error has been > detected by the Java Runtime Environment: > [2017-08-23 19:29:22,399] Agent[0]: stdout: # > [2017-08-23 19:29:22,400] Agent[0]: stdout: # Internal Error > (/home/martin/ws/jdk10-clang-4.0/hotspot/src/share/vm/opto/loopPredicate.cpp:915), > pid=31347, tid=31367 > [2017-08-23 19:29:22,400] Agent[0]: stdout: # assert(rng->Opcode() == > Op_LoadRange || _igvn.type(rng)->is_int()->_lo >= 0) failed: must be > > > On Wed, Aug 23, 2017 at 5:48 PM, Vladimir Kozlov > wrote: > >> I submitted pre-integration testing. >> >> Vladimir >> >> >> On 8/23/17 5:02 PM, Martin Buchholz wrote: >> >>> I assume I need a sponsor; if so, please import >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >>> -sign-comparison/pointer-sign-comparison.patch >>> >>> On Wed, Aug 23, 2017 at 4:46 PM, Vladimir Kozlov < >>> vladimir.kozlov at oracle.com >>> >>>> wrote: >>>> >>> >>> Looks good to me. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/23/17 4:37 PM, Martin Buchholz wrote: >>>> >>>> Thanks, Vladimir. >>>>> Webrev regenerated. >>>>> >>>>> I blindly coded >>>>> >>>>> - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= >>>>> 0, >>>>> "must be"); >>>>> + assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int()->_lo >>>>> >>>>>> = 0, "must be"); >>>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov < >>>>> vladimir.kozlov at oracle.com > wrote: >>>>> >>>>> Thank you, Martin >>>>> >>>>> Yes, sign compare is bad for pointers. >>>>> >>>>> Note, for pointers compare with use NULL instead of 0. Please, use >>>>> NULL. >>>>> >>>>> The assert check in loopPredicate.cpp is simple missing reference >>>>> to >>>>> field _lo (low bound of values range): >>>>> >>>>> _igvn.type(rng)->is_int()->_lo >= 0 >>>>> >>>>> Please, fix it this way. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 8/23/17 2:25 PM, Martin Buchholz wrote: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8174050 >>>>> >>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >>>>> -sign-comparison/ >>>>> >>>> r-sign-comparison/> >>>>> >>>>> My webrev could go in as is, but better would be for someone to >>>>> figure out >>>>> the intent of the nonsensical assert in >>>>> >>>>> src/share/vm/opto/loopPredicate.cpp >>>>> >>>>> (There is more to be done to support clang, but this is enough >>>>> to build >>>>> openjdk without patching source) >>>>> >>>>> >>>>> >>>>> From thomas.stuefe at gmail.com Thu Aug 24 06:46:16 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Aug 2017 08:46:16 +0200 Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java In-Reply-To: References: Message-ID: Hi Adam, Copying hotspot-dev. Please find my answers inline. On Wed, Aug 23, 2017 at 8:51 PM, Adam Farley8 wrote: > Hi Thomas, > > First, thank you for your time. :) > > The exit hook you recommend sounds like a fine workaround, though I > suggest a return code would make a better long term solution. > > Especially if the exit hook might be broken. :) > > Then it would be better to fix it instead of introducing a new option. > I don't think we can expect new JNI users to be familiar with the exit > hook, Why? It is part of the API. > and having Java designed to use the nuclear option (exit(0)) for a mere > help option seems like overkill. > > From what you're saying, I think you're agreeing that it's better to pass > a negative return code than call exit(#) and catch it, so that the VM can > shut down "cleanly" instead of being suddenly terminated by a random chunk > of internal c code. > I do not understand that sentence :) Neither option (1 - calling exit(2) with the option for the caller to intercept it or 2 - returning a to-be-newly-defined return code from JNI_CreateJavaVM) guarantee a clean VM shutdown. More has to be done for that. All it does is to give the caller the option to run its own cleanup, an option which arguably already exists in the form of the exit hook. > > Does this sound correct? > > Best Regards > > Adam Farley > > P.S I should note that, if we agree to go ahead with the negative return > code, we'll need to modify java.c to ignore it. IMO: Help options should > only return negative return codes to JNI callers, not java executable users. > > Kind Regards, Thomas > > > > From: Thomas St?fe > To: Adam Farley8 > Cc: Java Core Libs > Date: 23/08/2017 18:45 > Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM > can be exited by java > ------------------------------ > > > > Hi Adam, > > would the JNI exit hook not solve your problem (JavaVMOption "exit")? One > could use it to intercept any exit(2) calls. > > However, I am not sure it always fires, and if it does not, whether this > should be considered a bug. The official JNI documentation is pretty sparse > ( > *http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html* > > ). > > Another thing, even if one catches ::exit(), if the VM creation failed the > process can be in an undefined state, because I am not sure we clean up > orderly for every error exit. So, e.g., signal handlers may still be > installed etc. > > Kind Regards, Thomas > > > > > On Wed, Aug 23, 2017 at 5:54 PM, Adam Farley8 <*adam.farley at uk.ibm.com* > > wrote: > Hi All, > > Problem: Several of Java's "c" files call exit(0) if you pass certain > command-line options to JNI_CreateJavaVM, which can terminate the C++ code > JNI users use to initialise the JVM. > > Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses > the option "-agentlib:jdwp=help", Java's c files will print the needed > help output and call exit(0). > > Result: Your C++ code is terminated on this line, and a return code of 0 > is produced. > > Issues: > > Issue 1: The exit(0) prevents your code from doing anything useful after > the JNI_CreateJavaVM call. > Issue 2: The exit(0) indicates to anything monitoring your C++ code that > your code exited normally, even though it was terminated mid-way-through. > Issue 3: This return code is useless to us, as a 0 can indicate the VM > started correctly, or it can indicate the VM was terminated due to one or > more of these command-line options. > Issue 4: Of the other JNI return values (JNI_OK, JNI_ERR, etc) none of > them appear to cover this scenario. > > > Proposed solutions: > > PS1: We should amend the JNI specification to include a "JNI_SILENT_EXIT" > return code, so the C++ code knows a VM was not created, but that it isn't > an error. > PS2: We should identify a list of the command-line options that produce > this behaviour via the JNI. (not all of the "help" options are recognised > by the JNI interface. E.g. -version and -help produce a JNI_ERR and an > "Option not recognised" message) > PS3: We should replace these annoying exit(0) calls with code that returns > "JNI_SILENT_EXIT", so the C++ code has a chance to finish. > > > Best Regards > > Adam Farley > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From glaubitz at physik.fu-berlin.de Thu Aug 24 07:12:46 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 09:12:46 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> Message-ID: <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> Hello! On 08/23/2017 02:38 PM, David Holmes wrote: > These changes seem fine to me. I will sponsor this for you > once we have a second reviewer. Anyone willing to step up as the second reviewer? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Thu Aug 24 08:49:30 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 10:49:30 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux Message-ID: Hello! Please review the following changeset which adds SuperH as a new architecture for linux [1]. This change is required to be able to build linux-zero on SuperH running Linux. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186723/webrev.01/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Thu Aug 24 08:57:45 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Aug 2017 10:57:45 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: Hi Adrian, Out of curiosity, would that not be __sh__ instead of SH? Who defines SH? Also, is LE the norm and BE needs to be mentioned in particular instead of the other way around, like with PowerPC? Regards, Thomas On Thu, Aug 24, 2017 at 10:49 AM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hello! > > Please review the following changeset which adds SuperH as a new > architecture for linux [1]. This change is required to be able to > build linux-zero on SuperH running Linux. > > Thanks, > Adrian > > [1] http://cr.openjdk.java.net/~glaubitz/8186723/webrev.01/ >> > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From david.holmes at oracle.com Thu Aug 24 09:03:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Aug 2017 19:03:06 +1000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: References: <4f0f1741-95d2-5e00-8482-8c102f5d9a3d@oracle.com> Message-ID: <12e3293a-372d-f3ca-f06a-c7240dbdf74c@oracle.com> Hi Gunter, On 23/08/2017 11:40 PM, Haug, Gunter wrote: > Hi David, > > Sorry for the late reply! I have corrected the typos and updated the change, here is the new webrev: > > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v2 The typos are not fixed in that webrev. ?? > Would you mind sponsoring it? Sure. > Re not using os::vm_page_size(): You?re right, and I thought the same - it?s certainly correct for the primary thread. However, os::vm_page_size() isn?t used in the function and I think it?s not much of a problem to call getpagesize() in this particular case. Ok. Thanks, David > Thanks and best regards, > Gunter > > > > On 18.08.17, 06:18, "David Holmes" wrote: > > Hi Thomas, > > On 18/08/2017 1:59 PM, Thomas St?fe wrote: > > Hi David, > > > > On Thu, Aug 17, 2017 at 11:54 PM, David Holmes > > wrote: > > > > Hi Gunter, > > > > On 18/08/2017 1:01 AM, Haug, Gunter wrote: > > > > Thanks for the review, Aleksey and Thomas > > > > You?re right, it is much nicer to use the macros. I?ve updated > > the change accordingly: > > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v1 > > > > > > > > I'm unclear about the logic change here. If you round down then > > there is a chance you will enter the following if-block where > > otherwise you would not. > > > > 915 *size = align_down(*size, getpagesize()); > > 916 > > 917 if ((*size) < (DEFAULT_MAIN_THREAD_STACK_PAGES * > > (size_t)getpagesize())) { > > > > > > I don't see how this could happen? Gunters fix causes the size to snap > > to the lower page boundary, but never cross it. The code below ensures a > > lower cap at a page boundary. > > Yes you are right - sorry for the noise. > > David > > > If size was larger than that cap, after the align_down it will be at > > most right at that cap. If it was lower than the cap, it stays lower. In > > both cases behavior is unchanged. > > > > Cheers, Thomas > > > > Have you verified with a range of aligned and unaligned stack sizes > > around that threshhold that everything works okay? > > > > Some typos in the comment block: > > > > alligned -> aligned > > boundries -> boundaries > > I round -> We round > > > > @Thomas: os::vm_page_size() is not used in > > current_stack_region(), I think because of initialization > > dependencies. > > > > > > I don't see the dependency. It requires that it only be used after > > os::init() has been called. AFAICS the first time we will use this > > logic is when we attach the main thread, which happens after > > os::init(). > > > > Thanks, > > David > > > > Best regards, > > Gunter > > > > From: Thomas St?fe > > > > Date: Thursday, 17. August 2017 at 15:06 > > To: "Haug, Gunter" > > > > Cc: "hotspot-dev at openjdk.java.net > > " > > > > > Subject: Re: RFR(S): 8186286: [BSD] Primary thread's stack size > > is reported incorrectly > > > > Hi Gunter, > > > > > > On Thu, Aug 17, 2017 at 2:24 PM, Haug, Gunter > > > > >> wrote: > > Hi, > > > > can I please have reviews and a sponsor fort the following small > > bug fix: > > http://cr.openjdk.java.net/~ghaug/webrevs/8186286/ > > > > https://bugs.openjdk.java.net/browse/JDK-8186286 > > > > > > At least on Mac OS 10.12 we have observed stack sizes of the > > primary thread not aligned to pages boundries. This can be > > provoked by e.g. setrlimit() (ulimit -s xxxx in the shell).This > > voids the computation of the addresses of the guard pages. > > > > Fix: > > Apparently Mac OS actually rounds upwards to next multiple of > > page size however, it is conservative to round downwards here to > > be on the safe side. > > > > Thanks and best regards, > > Gunter > > > > Thanks for the patch! > > > > Very minor nits: what Alexey wrote (we also have "is_aligned"). > > Plus, any reason not to use os::vm_page_size()? Initialization > > dependencies? > > > > Kind Regards, Thomas > > > > > > > > > > From glaubitz at physik.fu-berlin.de Thu Aug 24 09:18:21 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 11:18:21 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: Hi Thomas! On 08/24/2017 10:57 AM, Thomas St?fe wrote: > Out of curiosity, would that not be __sh__ instead of SH? Who defines SH? This definition comes from common/autoconf/flags.m4: # Setup target CPU $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK \ $OPENJDK_$1_ADD_LP64 \ -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D$OPENJDK_$1_CPU_LEGACY" It's used in the same way for other architectures like SPARC and M68K. Although I am not 100% sure where the uppercase definitions comes from. However, looking at a build log, one finds: ( /usr/bin/sh4-linux-gnu-g++-6 -I/<>/build/hotspot/variant-zero/libjvm/objs/precompiled -std=gnu++98 -D_GNU_SOURCE -D_REENTRANT -fcheck-new -fno-delete-null-pointer-checks -fno-lifetime-dse -DLINUX -pipe -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -DVM_LITTLE_ENDIAN -Wpointer-arith -Wsign-compare -Wunused-function -Wunused-value -Woverloaded-virtual -Wno-format-zero-length -Wtype-limits -Wuninitialized -DPRODUCT -DTARGET_ARCH_zero -DINCLUDE_SUFFIX_OS=_linux -DINCLUDE_SUFFIX_CPU=_zero -DTARGET_COMPILER_gcc -DSH -DHOTSPOT_LIB_ARCH='"sh"' -DDEB_MULTIARCH="\"sh4-linux-gnu\"" -DZERO -DCC_INTERP -DZERO_LIBARCH='"sh"' -DINCLUDE_JVMCI=0 -I/<>/src/hotspot/src/share/vm -I/<>/src/hotspot/src/os/linux/vm -I/<>/src/hotspot/src/os/posix/vm -I/<>/src/hotspot/src/cpu/zero/vm -I/<>/src/hotspot/src/os_cpu/linux_zero/vm -I/<>/build/hotspot/variant-zero/gensrc -I/<>/src/hotspot/src/share/vm/precompiled -I/<>/src/hotspot/src/share/vm/prims -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/<>=. -Wformat -fno-stack-protector -Wno-deprecated-declarations -Wdate-time -D_FORTIFY_SOURCE=2 -g -O3 -DTHIS_FILE='"utf8.cpp"' -c -MMD -MF /<>/build/hotspot/variant-zero/libjvm/objs/utf8.d -o /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o /<>/src/hotspot/src/share/vm/utilities/utf8.cpp > >(/usr/bin/tee /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.log) 2> >(/usr/bin/tee /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.log >&2) || ( exitcode=$? && /bin/cp /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.log /<>/build/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_utf8.o.log && /bin/cp /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.cmdline /<>/build/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_utf8.o.cmdline && exit $exitcode ) ) /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /<>/build/hotspot/variant-zero/libjvm/objs/utf8.d > /<>/build/hotspot/variant-zero/libjvm/objs/utf8.d.targets Compiling verificationType.cpp (for libjvm.so) So, -DSH is passed to the compiler. > Also, is LE the norm and BE needs to be mentioned in particular instead of the other way around, like with PowerPC? Yes. On Linux, the default endianess for SuperH is little-endian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Thu Aug 24 09:44:20 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Aug 2017 11:44:20 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> Message-ID: Hi, 1) removed include seems fine. 2) Are we sure you do not need the special memset_with_concurrent_readers() on Sparc Zero? The issues described at the beginning of memset_with_concurrent_readers_sparc.cpp were important enough to justify an own memset for sparc. Used in several places in the GC. Do the gtests (especially test_memset_with_concurrent_readers.cpp) run through with your patch? Cheers, Thomas On Thu, Aug 24, 2017 at 9:12 AM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hello! > > On 08/23/2017 02:38 PM, David Holmes wrote: > > These changes seem fine to me. I will sponsor this for you > > once we have a second reviewer. > > Anyone willing to step up as the second reviewer? > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From thomas.stuefe at gmail.com Thu Aug 24 09:57:19 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Aug 2017 11:57:19 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: Hi Adrian, On Thu, Aug 24, 2017 at 11:18 AM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi Thomas! > > On 08/24/2017 10:57 AM, Thomas St?fe wrote: > >> Out of curiosity, would that not be __sh__ instead of SH? Who defines SH? >> > > This definition comes from common/autoconf/flags.m4: > > # Setup target CPU > $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK \ > $OPENJDK_$1_ADD_LP64 \ > -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D$OPENJDK_$1_CPU_LEGACY" > > It's used in the same way for other architectures like SPARC and M68K. > > Although I am not 100% sure where the uppercase definitions comes from. > > However, looking at a build log, one finds: > > ( /usr/bin/sh4-linux-gnu-g++-6 -I/<>/build/hotsp > ot/variant-zero/libjvm/objs/precompiled -std=gnu++98 -D_GNU_SOURCE > -D_REENTRANT -fcheck-new -fno-delete-null-pointer-checks > -fno-lifetime-dse -DLINUX -pipe -fPIC -fno-rtti -fno-exceptions > -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer > -DVM_LITTLE_ENDIAN -Wpointer-arith -Wsign-compare -Wunused-function > -Wunused-value -Woverloaded-virtual -Wno-format-zero-length -Wtype-limits > -Wuninitialized -DPRODUCT -DTARGET_ARCH_zero -DINCLUDE_SUFFIX_OS=_linux > -DINCLUDE_SUFFIX_CPU=_zero -DTARGET_COMPILER_gcc -DSH > -DHOTSPOT_LIB_ARCH='"sh"' -DDEB_MULTIARCH="\"sh4-linux-gnu\"" -DZERO > -DCC_INTERP -DZERO_LIBARCH='"sh"' -DINCLUDE_JVMCI=0 > -I/<>/src/hotspot/src/share/vm -I/<>/src/hotspot/src/os/linux/vm > -I/<>/src/hotspot/src/os/posix/vm > -I/<>/src/hotspot/src/cpu/zero/vm > -I/<>/src/hotspot/src/os_cpu/linux_zero/vm > -I/<>/build/hotspot/variant-zero/gensrc > -I/<>/src/hotspot/src/share/vm/precompiled > -I/<>/src/hotspot/src/share/vm/prims -Wdate-time > -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/<>=. -Wformat > -fno-stack-protector -Wno-deprecated-declarations -Wdate-time > -D_FORTIFY_SOURCE=2 -g -O3 -DTHIS_FILE='"utf8.cpp"' -c -MMD -MF > /<>/build/hotspot/variant-zero/libjvm/objs/utf8.d -o > /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o > /<>/src/hotspot/src/share/vm/utilities/utf8.cpp > > >(/usr/bin/tee /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.log) > 2> >(/usr/bin/tee /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.log > >&2) || ( exitcode=$? && /bin/cp /<>/build/hotspot > /variant-zero/libjvm/objs/utf8.o.log /<>/build/make-su > pport/failure-logs/hotspot_variant-zero_libjvm_objs_utf8.o.log && /bin/cp > /<>/build/hotspot/variant-zero/libjvm/objs/utf8.o.cmdline > /<>/build/make-support/failure-logs/hotspot_var > iant-zero_libjvm_objs_utf8.o.cmdline && exit $exitcode ) ) > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ > ]*//' -e '/^$/ d' -e 's/$/ :/' /<>/build/hotspot > /variant-zero/libjvm/objs/utf8.d > /<>/build/hotspot > /variant-zero/libjvm/objs/utf8.d.targets > Compiling verificationType.cpp (for libjvm.so) > > So, -DSH is passed to the compiler. > > Also, is LE the norm and BE needs to be mentioned in particular instead of >> the other way around, like with PowerPC? >> > Yes. On Linux, the default endianess for SuperH is little-endian. > > Ah, I see it. "sh" was introduced by you in JDK-8186313 in platform.m4 (VAR_CPU). I just wondered why this macro was so shortish and whether we would risk potential name clashes with other macros. I am fine with this change. Reviewed. Cheers, Thomas > Adrian > > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From glaubitz at physik.fu-berlin.de Thu Aug 24 10:05:12 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 12:05:12 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: On 08/24/2017 11:57 AM, Thomas St?fe wrote: > Ah, I see it. "sh" was introduced by you in JDK-8186313 in platform.m4 (VAR_CPU). > I just wondered why this macro was so shortish and whether we would risk potential > name clashes with other macros. There are actually name clashes, both on alpha and sh because of this: # Setup target CPU $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK \ $OPENJDK_$1_ADD_LP64 \ -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D$OPENJDK_$1_CPU_LEGACY" There are two instances in the JDK code where variables have the names "alpha" and "sh". In Debian, we work around this issue with the following change: --- jdk9/common/autoconf/flags.m4~ 2017-05-16 14:14:26.000000000 +0200 +++ jdk9/common/autoconf/flags.m4 2017-06-19 16:00:14.998979413 +0200 @@ -967,9 +967,12 @@ $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK -D$OPENJDK_$1_OS_UPPERCASE" # Setup target CPU + case "$OPENJDK_TARGET_CPU_LEGACY" in + alpha*|sh*) uscore=_ + esac $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK \ $OPENJDK_$1_ADD_LP64 \ - -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D$OPENJDK_$1_CPU_LEGACY" + -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D${uscore}$OPENJDK_$1_CPU_LEGACY${uscore}" # Setup debug/release defines if test "x$DEBUG_LEVEL" = xrelease; then I wanted to discuss this in a separate issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Thu Aug 24 10:28:58 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Aug 2017 12:28:58 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: On Thu, Aug 24, 2017 at 12:05 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/24/2017 11:57 AM, Thomas St?fe wrote: > >> Ah, I see it. "sh" was introduced by you in JDK-8186313 in platform.m4 >> (VAR_CPU). >> I just wondered why this macro was so shortish and whether we would risk >> potential >> name clashes with other macros. >> > > There are actually name clashes, both on alpha and sh because of this: > > # Setup target CPU > $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK \ > $OPENJDK_$1_ADD_LP64 \ > -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D$OPENJDK_$1_CPU_LEGACY" > > There are two instances in the JDK code where variables have the names > "alpha" > and "sh". In Debian, we work around this issue with the following change: > > --- jdk9/common/autoconf/flags.m4~ 2017-05-16 14:14:26.000000000 > +0200 > +++ jdk9/common/autoconf/flags.m4 2017-06-19 16:00:14.998979413 +0200 > @@ -967,9 +967,12 @@ > $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK > -D$OPENJDK_$1_OS_UPPERCASE" > # Setup target CPU > + case "$OPENJDK_TARGET_CPU_LEGACY" in > + alpha*|sh*) uscore=_ > + esac > $2COMMON_CCXXFLAGS_JDK="[$]$2COMMON_CCXXFLAGS_JDK \ > $OPENJDK_$1_ADD_LP64 \ > - -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D$OPENJDK_$1_CPU_LEGACY" > + -DARCH='\"$OPENJDK_$1_CPU_LEGACY\"' -D${uscore}$OPENJDK_$1_CPU_LEG > ACY${uscore}" > # Setup debug/release defines > if test "x$DEBUG_LEVEL" = xrelease; then > > I wanted to discuss this in a separate issue. > > > Sure. ..Thomas > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From glaubitz at physik.fu-berlin.de Thu Aug 24 11:21:45 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 13:21:45 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> On 08/24/2017 12:28 PM, Thomas St?fe wrote: > > On Thu, Aug 24, 2017 at 12:05 PM, John Paul Adrian Glaubitz > wrote: > > > On 08/24/2017 11:57 AM, Thomas St?fe wrote: > > Ah, I see it. "sh" was introduced by you in JDK-8186313 in platform.m4 (VAR_CPU). > I just wondered why this macro was so shortish and whether we would risk potential > name clashes with other macros. > > I wanted to discuss this in a separate issue. > > Sure. Ok, so let's continue here as I'm not sure whether this issue should be addressed before merging the above changeset. In my opinion, it's generally rather suboptimal approach to use any global defines without surrounding underscores. But I am currently undecided what would be the best approach to resolve this problem. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From gunter.haug at sap.com Thu Aug 24 12:37:31 2017 From: gunter.haug at sap.com (Haug, Gunter) Date: Thu, 24 Aug 2017 12:37:31 +0000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: <12e3293a-372d-f3ca-f06a-c7240dbdf74c@oracle.com> References: <4f0f1741-95d2-5e00-8482-8c102f5d9a3d@oracle.com> <12e3293a-372d-f3ca-f06a-c7240dbdf74c@oracle.com> Message-ID: <929F0185-C8AB-4873-8683-CFCFCDB4ED3A@sap.com> Sorry David, my bad. Still learning how to use the tools. Now it should be OK! Thanks again, Gunter The typos are not fixed in that webrev. ?? http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v2 From david.holmes at oracle.com Thu Aug 24 12:41:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Aug 2017 22:41:44 +1000 Subject: RFR(S): 8186286: [BSD] Primary thread's stack size is reported incorrectly In-Reply-To: <929F0185-C8AB-4873-8683-CFCFCDB4ED3A@sap.com> References: <4f0f1741-95d2-5e00-8482-8c102f5d9a3d@oracle.com> <12e3293a-372d-f3ca-f06a-c7240dbdf74c@oracle.com> <929F0185-C8AB-4873-8683-CFCFCDB4ED3A@sap.com> Message-ID: Push initiated. David On 24/08/2017 10:37 PM, Haug, Gunter wrote: > Sorry David, my bad. Still learning how to use the tools. Now it should be OK! > > Thanks again, > Gunter > > > The typos are not fixed in that webrev. ?? > > http://cr.openjdk.java.net/~ghaug/webrevs/8186286.v2 > > From glaubitz at physik.fu-berlin.de Thu Aug 24 12:44:30 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 14:44:30 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> Message-ID: On 08/24/2017 01:21 PM, John Paul Adrian Glaubitz wrote: > Ok, so let's continue here as I'm not sure whether this issue should be addressed > before merging the above changeset. In my opinion, it's generally rather suboptimal > approach to use any global defines without surrounding underscores. But I am currently > undecided what would be the best approach to resolve this problem. I think there are three options: a) Use something similar as on x86/x86_64 to rename "alpha" and "sh": # Also store the legacy naming of the cpu. # Ie i586 and amd64 instead of x86 and x86_64 OPENJDK_$1_CPU_LEGACY="$OPENJDK_$1_CPU" if test "x$OPENJDK_$1_CPU" = xx86; then OPENJDK_$1_CPU_LEGACY="i586" elif test "x$OPENJDK_$1_OS" != xmacosx && test "x$OPENJDK_$1_CPU" = xx86_64; then # On all platforms except MacOSX replace x86_64 with amd64. OPENJDK_$1_CPU_LEGACY="amd64" fi AC_SUBST(OPENJDK_$1_CPU_LEGACY) # And the second legacy naming of the cpu. # Ie i386 and amd64 instead of x86 and x86_64. OPENJDK_$1_CPU_LEGACY_LIB="$OPENJDK_$1_CPU" if test "x$OPENJDK_$1_CPU" = xx86; then OPENJDK_$1_CPU_LEGACY_LIB="i386" elif test "x$OPENJDK_$1_CPU" = xx86_64; then OPENJDK_$1_CPU_LEGACY_LIB="amd64" fi AC_SUBST(OPENJDK_$1_CPU_LEGACY_LIB b) Rename VAR_CPU for Alpha and SuperH: alpha => dec_alpha sh => superh c) Pass OPENJDK_$1_CPU_LEGACY with underscores. This one might have ramifications on other targets depending on how OPENJDK_$1_CPU_LEGACY is used throughout the code. Suggestions? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From patric.hedlin at oracle.com Thu Aug 24 13:06:28 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 24 Aug 2017 15:06:28 +0200 Subject: RFR(XXS): 8183119: Resolve 'libkstat' dependency between open and closed part of JDK. Message-ID: <98445d3a-bf15-9f56-dbe8-d63384589798@oracle.com> Dear all, I would like to ask for help to review the following change/update: Issue: https://bugs.openjdk.java.net/browse/JDK-8183119 8183119:Resolve 'libkstat' dependency between open and closed part of JDK. libkstat no longer used in open part (after JDK-8172231). This is the open part. Best regards, Patric -----8<----- --- a/common/autoconf/flags.m4 Tue Aug 22 16:20:29 2017 +0200 +++ b/common/autoconf/flags.m4 Thu Aug 24 11:25:58 2017 +0200 @@ -1358,7 +1358,7 @@ $2SOLARIS_LIBM_LIBS="/usr/lib/sparcv9/libm.so.1" fi $2JVM_LIBS="[$]$2JVM_LIBS -lsocket -lsched -ldl $SOLARIS_LIBM_LIBS -lCrun \ - -lthread -ldoor -lc -ldemangle -lnsl -lkstat -lrt" + -lthread -ldoor -lc -ldemangle -lnsl -lrt" elif test "x$OPENJDK_$1_OS" = xmacosx; then $2JVM_LIBS="[$]$2JVM_LIBS -lm" elif test "x$OPENJDK_$1_OS" = xaix; then From david.holmes at oracle.com Thu Aug 24 13:07:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Aug 2017 23:07:33 +1000 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> Message-ID: On 24/08/2017 9:21 PM, John Paul Adrian Glaubitz wrote: > On 08/24/2017 12:28 PM, Thomas St?fe wrote: >> > On Thu, Aug 24, 2017 at 12:05 PM, John Paul Adrian Glaubitz >> > >> wrote: >> > > On 08/24/2017 11:57 AM, Thomas St?fe wrote: >> >> ??????? Ah, I see it. "sh" was introduced by you in JDK-8186313 in >> platform.m4 (VAR_CPU). >> ??????? I just wondered why this macro was so shortish and whether we >> would risk potential >> ??????? name clashes with other macros. >> >> ??? I wanted to discuss this in a separate issue. >> >> Sure. > > Ok, so let's continue here as I'm not sure whether this issue should be > addressed > before merging the above changeset.? In my opinion, it's generally > rather suboptimal > approach to use any global defines without surrounding underscores. But > I am currently > undecided what would be the best approach to resolve this problem. Sorry I don't have any context here. What is the issue? And is it a hotspot issue or a build issue? Thanks, David > Adrian > From glaubitz at physik.fu-berlin.de Thu Aug 24 13:10:10 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 15:10:10 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> Message-ID: <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> On 08/24/2017 03:07 PM, David Holmes wrote: >> Ok, so let's continue here as I'm not sure whether this issue should be addressed >> before merging the above changeset. In my opinion, it's generally rather suboptimal >> approach to use any global defines without surrounding underscores. But I am currently >> undecided what would be the best approach to resolve this problem. > > Sorry I don't have any context here. What is the issue? And is it a hotspot issue or a build issue? The problem is that autoconf passes the content of VAR_CPU to CFLAGS which means that - on alpha and sh - CFLAGS contain "-Dalpha" and "-Dsh" respectively which results in a naming collision with some source files: === Output from failing command(s) repeated here === /usr/bin/printf "* For target support_native_java.desktop_libmlib_image_mlib_ImageAffine.o:\n" * For target support_native_java.desktop_libmlib_image_mlib_ImageAffine.o: (/bin/grep -v -e "^Note: including file:" < /<>/build/make-support/failure-logs/support_native_java.desktop_libmlib_image_mlib_ImageAffine.o.log || true) | /usr/bin/head -n 12 :0:7: error: expected ';', ',' or ')' before numeric constant /<>/src/jdk/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h:152:50: note: in expansion of macro 'alpha' const mlib_image *alpha); ^~~~~ :0:7: error: expected ';', ',' or ')' before numeric constant /<>/src/jdk/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h:161:58: note: in expansion of macro 'alpha' const mlib_image *alpha); ^~~~~ :0:7: error: expected ';', ',' or ')' before numeric constant /<>/src/jdk/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h:170:55: note: in expansion of macro 'alpha' const mlib_image *alpha); ^~~~~ if test `/usr/bin/wc -l < /<>/build/make-support/failure-logs/support_native_java.desktop_libmlib_image_mlib_ImageAffine.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "\n* All command lines available in /<>/build/make-support/failure-logs.\n" * All command lines available in /<>/build/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Thu Aug 24 13:20:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Aug 2017 23:20:49 +1000 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> Message-ID: <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> On 24/08/2017 11:10 PM, John Paul Adrian Glaubitz wrote: > On 08/24/2017 03:07 PM, David Holmes wrote: >>> Ok, so let's continue here as I'm not sure whether this issue should >>> be addressed >>> before merging the above changeset.? In my opinion, it's generally >>> rather suboptimal >>> approach to use any global defines without surrounding underscores. >>> But I am currently >>> undecided what would be the best approach to resolve this problem. >> >> Sorry I don't have any context here. What is the issue? And is it a >> hotspot issue or a build issue? > > The problem is that autoconf passes the content of VAR_CPU to CFLAGS which > means that - on alpha and sh - CFLAGS contain "-Dalpha" and "-Dsh" > respectively > which results in a naming collision with some source files: Ouch! So I have to wonder whether the raw -D for the cpu arch name is really necessary. There's obviously a lot of legacy usage to consider here though. But I've often assumed/expected that if we tell the compiler to build for a specific cpu then the compiler would provide a suitable define (probably underscored) that we could then use in the code if needed. Short-term solution would be your option (b) and rename alpha and sh to something unlikely to cause a clash. David > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target > support_native_java.desktop_libmlib_image_mlib_ImageAffine.o:\n" > * For target support_native_java.desktop_libmlib_image_mlib_ImageAffine.o: > (/bin/grep -v -e "^Note: including file:" < > /<>/build/make-support/failure-logs/support_native_java.desktop_libmlib_image_mlib_ImageAffine.o.log > || true) | /usr/bin/head -n 12 > :0:7: error: expected ';', ',' or ')' before numeric constant > /<>/src/jdk/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h:152:50: > note: in expansion of macro 'alpha' > ??????????????????????????????? const mlib_image *alpha); > ????????????????????????????????????????????????? ^~~~~ > :0:7: error: expected ';', ',' or ')' before numeric constant > /<>/src/jdk/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h:161:58: > note: in expansion of macro 'alpha' > ??????????????????????????????????????? const mlib_image *alpha); > ????????????????????????????????????????????????????????? ^~~~~ > :0:7: error: expected ';', ',' or ')' before numeric constant > /<>/src/jdk/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h:170:55: > note: in expansion of macro 'alpha' > ???????????????????????????????????? const mlib_image *alpha); > ?????????????????????????????????????????????????????? ^~~~~ > if test `/usr/bin/wc -l < > /<>/build/make-support/failure-logs/support_native_java.desktop_libmlib_image_mlib_ImageAffine.o.log` > -gt 12; then /bin/echo "?? ... (rest of output omitted)" ; fi > ?? ... (rest of output omitted) > /usr/bin/printf "\n* All command lines available in > /<>/build/make-support/failure-logs.\n" > > * All command lines available in > /<>/build/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === > From glaubitz at physik.fu-berlin.de Thu Aug 24 13:22:32 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 15:22:32 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> Message-ID: <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> Hi! On 08/24/2017 11:44 AM, Thomas St?fe wrote: > 2) Are we sure you do not need the special memset_with_concurrent_readers() > on Sparc Zero? The issues described at the beginning of memset_with_concurrent_readers_sparc.cpp > were important enough to justify an own memset for sparc. Used in several places in the GC. I cannot answer this directly but my guess would be that this affects Solaris only? I will ask someone from the SPARC Linux team at Oracle :-). > Do the gtests (especially test_memset_with_concurrent_readers.cpp) run through with your patch? I will run the testsuite in a second and report back. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Thu Aug 24 13:24:55 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 15:24:55 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> Message-ID: <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> On 08/24/2017 03:20 PM, David Holmes wrote: > Ouch! So I have to wonder whether the raw -D for the cpu arch name is really necessary. > There's obviously a lot of legacy usage to consider here though. But I've often assumed/ > expected that if we tell the compiler to build for a specific cpu then the compiler would > provide a suitable define (probably underscored) that we could then use in the code if needed. I agree. The string "LEGACY" in the identifier seems to confirm that. Might be a good idea to open a separate bug for the removal of this identifier. > Short-term solution would be your option (b) and rename alpha and sh to something unlikely to cause a clash. Will do. I guess we can merge 8186723 without any changes then? It doesn't rely on the legacy (lowercase) identifier but on the all-uppercase identifier anyways. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Thu Aug 24 13:51:58 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 Aug 2017 15:51:58 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> Message-ID: <3cb65ceb-c575-e446-bb66-a50c4b02684a@physik.fu-berlin.de> On 08/24/2017 03:22 PM, John Paul Adrian Glaubitz wrote: >> Do the gtests (especially test_memset_with_concurrent_readers.cpp) run through with your patch? > > I will run the testsuite in a second and report back. Ok. I have to admit I don't understand how to run the testsuite out of the build tree. It mentions jtreg which I have installed: glaubitz at deb4g:~$ jtreg -version jtreg, version 4.2 src b07 Installed in /usr/share/java/jtreg.jar Running on platform version 1.8.0_144 from /usr/lib/jvm/java-8-openjdk-sparc64/jre. Built with 1.8.0_131 on Tue, 20 Jun 2017 10:54:14 +0200. Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. glaubitz at deb4g:~$ But the configure script complains about jtreg missing: checking if jtreg failure handler should be built... configure: error: Cannot enable jtreg failure handler without jtreg. configure exiting with result code 1 glaubitz at deb4g:~/openjdk/hs$ I also don't fully understand how the testsuite is run as mentioned in [1]. It talks about jtreg and then about jtreg harness which doesn't have clear build instructions [2]. Adrian > [1] http://download.java.net/openjdk/testresults/8/docs/howtoruntests.html > [2] http://openjdk.java.net/jtreg/build.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Thu Aug 24 15:39:05 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 24 Aug 2017 11:39:05 -0400 Subject: RFR (XL) 8173715: Remove FlatProfiler In-Reply-To: <8317EF1E-1321-48A8-9694-C49EBFD9CB9B@oracle.com> References: <3BB9117A-150E-4F31-9DFB-A310B8D85313@oracle.com> <048913eb-c6b7-05c6-3b7b-f40098a5a54b@oracle.com> <02175503-FCB3-48F8-9842-A1339624A8D8@oracle.com> <66d3f1b0-3c1e-65c1-8d4d-72b9e52bac08@oracle.com> <8317EF1E-1321-48A8-9694-C49EBFD9CB9B@oracle.com> Message-ID: <24b40d60-778f-2e45-5574-6c7af9ee69a3@oracle.com> On 8/18/17 4:51 PM, Gerard Ziemski wrote: > Thank you David for clarifications. > >> On Aug 17, 2017, at 4:38 PM, David Holmes wrote: >> >> Hi Gerard, >> >> On 18/08/2017 12:34 AM, Gerard Ziemski wrote: >>> hi David, >>> Thank you for the review! >>>> On Aug 16, 2017, at 8:09 PM, David Holmes wrote: >>>> >>>> Hi Gerard, >>>> >>>> On 17/08/2017 3:48 AM, Gerard Ziemski wrote: >>>>> hi all, >>>>> (this is hotspot part of the change, the jdk part is being reviewed on jdk10-dev at openjdk.java.net) >>>>> The FlatProfiler (i.e. -Xprof) has been deprecated for a while, and now it?s the time to remove it. >>>> That is fine for removing the support, but shouldn't the actual -Xprof flab be obsoleted before being actually removed? Though this is -X not -XX so I'm not sure what the launcher protocol is for this. ?? >>> So normally for -XX flags it?s deprecated -> obsolete -> remove, correct? >> Yes. >> >>> I?m not sure about -X flag either, but it was explained to me that making -Xprof flag work in jdk10 would take considerable amount of effort, so instead of supporting already deprecated flag, we simply remove it - it was officially deprecated in jdk9 using JDK-8176098. >> Obsoleting the flag still allows removal of all the functionality, it just means use of the flag itself doesn't produce an error, but a warning telling you the flag is obsolete and has no effect and will be removed in the future. > I have obsoleted the flag, so it?s still accepted, but it will now print a warning ?Ignoring option -Xprof; support was removed in 10.0" > > >>>>> The changes are XL, but straightforward. >>>>> If anyone knows of any other remnants that should still be removed, please let me know. >>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8173715 >>>>> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev1_hotspot >>>> There are a few places where you have removed reference to the flat profiler, or -Xprof, but you haven't actually changed the code that only seemed to have existed to support the flat-profiler e.g.: >>>> >>>> src/cpu/sparc/vm/macroAssembler_sparc.cpp >>>> >>>> - save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod for -Xprof) >>>> + save_frame_and_mov(0, Lmethod, Lmethod); // to avoid clobbering O0 (and propagate Lmethod) >>>> >>>> Are we still propagating Lmethod here? If so why? Ditto for other places in the file. >>> I couldn?t figure out whether we still needed to propagate the Lmethod, and assumed that it was safe to leave it in - the extra code is saving a register, which seems harmless to me and there are other places in the file where we do it. >> This needs to be assessed by compiler folk. If we leave in code that was only needed for flat-profiler but remove all such comments then no-one will know why we are doing something. If this code is needed then the comment should reflect why; if not needed it should be removed. > I will ask on the compiler mailing list about it. If this is a small piece of a large change, can we file an RFE to evaluate this and clean it up later? > > >>>> In: src/share/vm/runtime/thread.cpp >>>> >>>> - // eventually timeout, but that takes time. Making this wait a >>>> - // suspend-equivalent condition solves that timeout problem. >>>> - // >>>> Terminator_lock->wait(!Mutex::_no_safepoint_check_flag, 0, >>>> Mutex::_as_suspend_equivalent_flag); >>>> >>>> So we should no longer need the Mutex::_as_suspend_equivalent_flag here (and in another place). >>> I wasn?t completely sure about this, and was going back and forth on this, but I figured it was safer to leave it in, since there are code paths that still use suspend/resume mechanism, i.e. the deprecated java.lang.Thread.suspend()/resume() APIs. >>> Are we sure it?s OK to remove these locks? >> As per other email it is only the use of the flag that could be removed, if it truly only was needed due to flat-profiler interactions. But looking at the full block of code in context it seems that the need to be "suspend equivalent" was already part of this logic and that that was sufficient to fix the flat-profiler issue. So it looks like the code should remain as-is. > Left the code alone. > > >>>> --- >>>> >>>> I'm a little perplexed by the changes to the os_*.cpp file regarding low-level suspend/resume: >>>> >>>> -// within hotspot. Now there is a single use-case for this: >>>> -// - calling get_thread_pc() on the VMThread by the flat-profiler task >>>> -// that runs in the watcher thread. >>>> +// within hotspot. Needed for fetch_frame_from_ucontext(), which is used by: >>>> +// - Forte Analyzer: AsyncGetCallTrace() >>>> +// - StackBanging: get_frame_at_stack_banging_point() >>>> >>>> I don't see any use of low-level suspend/resume with the two cases you added ?? >>> Those cases depend on ?ucontext? being set up using the resume_clear_context()/suspend_save_context() APIs, which are part of the resume/suspend mechanism - I will try to re-do the comment. >> That comment pertained to actual use of the low-level suspend/resume mechanism which is not used by AGCT or stack-banging. I would just terminate the comment at "within hotspot" and not add any additional text. > I would really like to keep my 2nd attempt at the comment in - it identifies who is still using the suspend/resume mechanism, with a note about user context, in case someone is tempted to remove it (like I originally did before realizing it?s still needed) > > Rev 2 webrev coming up shortly? > Looking forward to it. Thanks, Coleen > cheers > From thomas.stuefe at gmail.com Thu Aug 24 16:19:52 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Aug 2017 18:19:52 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <3cb65ceb-c575-e446-bb66-a50c4b02684a@physik.fu-berlin.de> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> <3cb65ceb-c575-e446-bb66-a50c4b02684a@physik.fu-berlin.de> Message-ID: On Thu, Aug 24, 2017 at 3:51 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/24/2017 03:22 PM, John Paul Adrian Glaubitz wrote: > >> Do the gtests (especially test_memset_with_concurrent_readers.cpp) run >>> through with your patch? >>> >> >> I will run the testsuite in a second and report back. >> > > Ok. I have to admit I don't understand how to run the testsuite out of the > build tree. It mentions jtreg which I have installed: > > glaubitz at deb4g:~$ jtreg -version > jtreg, version 4.2 src b07 > Installed in /usr/share/java/jtreg.jar > Running on platform version 1.8.0_144 from /usr/lib/jvm/java-8-openjdk-sp > arc64/jre. > Built with 1.8.0_131 on Tue, 20 Jun 2017 10:54:14 +0200. > Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights > reserved. > Use is subject to license terms. > glaubitz at deb4g:~$ > > But the configure script complains about jtreg missing: > > checking if jtreg failure handler should be built... configure: error: > Cannot enable jtreg failure handler without jtreg. > configure exiting with result code 1 > glaubitz at deb4g:~/openjdk/hs$ > > I also don't fully understand how the testsuite is run as mentioned in > [1]. It > talks about jtreg and then about jtreg harness which doesn't have clear > build > instructions [2]. > > Adrian > Sorry, I should have been more specific. The gtests have nothing to do with the jtreg suite, they are a set of native tests using google test. Just execute (from your build directory): ./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk There is also a way to execute them from the make, but I do not know how. Best Regards, Thomas > > [1] http://download.java.net/openjdk/testresults/8/docs/howtoruntests.html >> [2] http://openjdk.java.net/jtreg/build.html >> > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From martinrb at google.com Thu Aug 24 17:23:54 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Aug 2017 10:23:54 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: <2f74f72a-92d1-3a04-bb3a-90bacc79b7d8@oracle.com> Message-ID: Vladimir, did you mean (reinserting ->_lo) assert(rng->Opcode() == Op_LoadRange || iff->is_RangeCheck() || _igvn.type(rng)->is_int()->_lo >= 0, "must be"); On Wed, Aug 23, 2017 at 9:16 PM, Vladimir Kozlov wrote: > I also hit this failure. > > The code which guards this assert has additional condition "&& > !iff->is_RangeCheck()" due to which no check for positive value happened: > > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/821ef7c1008 > 5/src/share/vm/opto/loopPredicate.cpp#l590 > > I think we should check for RangeCheck node in assert: > > assert(rng->Opcode() == Op_LoadRange || iff->is_RangeCheck() || > _igvn.type(rng)->is_int() >= 0, "must be"); > > RangeCheck has dynamic check that range is positive. > I think it should be safe to relax this assert. > > Thanks, > Vladimir > > > On 8/23/17 7:33 PM, Martin Buchholz wrote: > >> during ad hoc testing I saw the crash below, so this assert needs more >> work >> (but great job on the error reporting here!) >> >> [2017-08-23 19:29:22,374] Agent[0]: stdout: # To suppress the following >> error report, specify this argument >> [2017-08-23 19:29:22,390] Agent[0]: stdout: # after -XX: or in .hotspotrc: >> SuppressErrorAt=/loopPredicate.cpp:915 >> [2017-08-23 19:29:22,391] Agent[0]: stdout: # >> [2017-08-23 19:29:22,392] Agent[0]: stdout: # A fatal error has been >> detected by the Java Runtime Environment: >> [2017-08-23 19:29:22,399] Agent[0]: stdout: # >> [2017-08-23 19:29:22,400] Agent[0]: stdout: # Internal Error >> (/home/martin/ws/jdk10-clang-4.0/hotspot/src/share/vm/opto/l >> oopPredicate.cpp:915), >> pid=31347, tid=31367 >> [2017-08-23 19:29:22,400] Agent[0]: stdout: # assert(rng->Opcode() == >> Op_LoadRange || _igvn.type(rng)->is_int()->_lo >= 0) failed: must be >> >> >> On Wed, Aug 23, 2017 at 5:48 PM, Vladimir Kozlov < >> vladimir.kozlov at oracle.com >> >>> wrote: >>> >> >> I submitted pre-integration testing. >>> >>> Vladimir >>> >>> >>> On 8/23/17 5:02 PM, Martin Buchholz wrote: >>> >>> I assume I need a sponsor; if so, please import >>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >>>> -sign-comparison/pointer-sign-comparison.patch >>>> >>>> On Wed, Aug 23, 2017 at 4:46 PM, Vladimir Kozlov < >>>> vladimir.kozlov at oracle.com >>>> >>>> wrote: >>>>> >>>>> >>>> Looks good to me. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/23/17 4:37 PM, Martin Buchholz wrote: >>>>> >>>>> Thanks, Vladimir. >>>>> >>>>>> Webrev regenerated. >>>>>> >>>>>> I blindly coded >>>>>> >>>>>> - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= >>>>>> 0, >>>>>> "must be"); >>>>>> + assert(rng->Opcode() == Op_LoadRange || >>>>>> _igvn.type(rng)->is_int()->_lo >>>>>> >>>>>> = 0, "must be"); >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov < >>>>>> vladimir.kozlov at oracle.com > >>>>>> wrote: >>>>>> >>>>>> Thank you, Martin >>>>>> >>>>>> Yes, sign compare is bad for pointers. >>>>>> >>>>>> Note, for pointers compare with use NULL instead of 0. Please, >>>>>> use >>>>>> NULL. >>>>>> >>>>>> The assert check in loopPredicate.cpp is simple missing >>>>>> reference >>>>>> to >>>>>> field _lo (low bound of values range): >>>>>> >>>>>> _igvn.type(rng)->is_int()->_lo >= 0 >>>>>> >>>>>> Please, fix it this way. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> On 8/23/17 2:25 PM, Martin Buchholz wrote: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8174050 >>>>>> >>>>>> http://cr.openjdk.java.net/~ma >>>>>> rtin/webrevs/openjdk10/pointer >>>>>> -sign-comparison/ >>>>>> >>>>> artin/webrevs/openjdk10/pointe >>>>>> r-sign-comparison/> >>>>>> >>>>>> My webrev could go in as is, but better would be for >>>>>> someone to >>>>>> figure out >>>>>> the intent of the nonsensical assert in >>>>>> >>>>>> src/share/vm/opto/loopPredicate.cpp >>>>>> >>>>>> (There is more to be done to support clang, but this is >>>>>> enough >>>>>> to build >>>>>> openjdk without patching source) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From vladimir.kozlov at oracle.com Thu Aug 24 17:32:33 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 10:32:33 -0700 Subject: RFR: 8174050: Compilation errors with clang-4.0 In-Reply-To: References: <2f74f72a-92d1-3a04-bb3a-90bacc79b7d8@oracle.com> Message-ID: <45876c3e-b68c-0f04-32cf-4605cd7736fa@oracle.com> Yes, it should have ->_lo. Sorry about that. I am finishing testing with updated assert (and with ->_lo). No new failures so far. Thanks, Vladimir On 8/24/17 10:23 AM, Martin Buchholz wrote: > Vladimir, did you mean (reinserting ->_lo) > > assert(rng->Opcode() == Op_LoadRange || iff->is_RangeCheck() || > _igvn.type(rng)->is_int()->_lo >= 0, "must be"); > > On Wed, Aug 23, 2017 at 9:16 PM, Vladimir Kozlov > wrote: > >> I also hit this failure. >> >> The code which guards this assert has additional condition "&& >> !iff->is_RangeCheck()" due to which no check for positive value happened: >> >> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/821ef7c1008 >> 5/src/share/vm/opto/loopPredicate.cpp#l590 >> >> I think we should check for RangeCheck node in assert: >> >> assert(rng->Opcode() == Op_LoadRange || iff->is_RangeCheck() || >> _igvn.type(rng)->is_int() >= 0, "must be"); >> >> RangeCheck has dynamic check that range is positive. >> I think it should be safe to relax this assert. >> >> Thanks, >> Vladimir >> >> >> On 8/23/17 7:33 PM, Martin Buchholz wrote: >> >>> during ad hoc testing I saw the crash below, so this assert needs more >>> work >>> (but great job on the error reporting here!) >>> >>> [2017-08-23 19:29:22,374] Agent[0]: stdout: # To suppress the following >>> error report, specify this argument >>> [2017-08-23 19:29:22,390] Agent[0]: stdout: # after -XX: or in .hotspotrc: >>> SuppressErrorAt=/loopPredicate.cpp:915 >>> [2017-08-23 19:29:22,391] Agent[0]: stdout: # >>> [2017-08-23 19:29:22,392] Agent[0]: stdout: # A fatal error has been >>> detected by the Java Runtime Environment: >>> [2017-08-23 19:29:22,399] Agent[0]: stdout: # >>> [2017-08-23 19:29:22,400] Agent[0]: stdout: # Internal Error >>> (/home/martin/ws/jdk10-clang-4.0/hotspot/src/share/vm/opto/l >>> oopPredicate.cpp:915), >>> pid=31347, tid=31367 >>> [2017-08-23 19:29:22,400] Agent[0]: stdout: # assert(rng->Opcode() == >>> Op_LoadRange || _igvn.type(rng)->is_int()->_lo >= 0) failed: must be >>> >>> >>> On Wed, Aug 23, 2017 at 5:48 PM, Vladimir Kozlov < >>> vladimir.kozlov at oracle.com >>> >>>> wrote: >>>> >>> >>> I submitted pre-integration testing. >>>> >>>> Vladimir >>>> >>>> >>>> On 8/23/17 5:02 PM, Martin Buchholz wrote: >>>> >>>> I assume I need a sponsor; if so, please import >>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/pointer >>>>> -sign-comparison/pointer-sign-comparison.patch >>>>> >>>>> On Wed, Aug 23, 2017 at 4:46 PM, Vladimir Kozlov < >>>>> vladimir.kozlov at oracle.com >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>> Looks good to me. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 8/23/17 4:37 PM, Martin Buchholz wrote: >>>>>> >>>>>> Thanks, Vladimir. >>>>>> >>>>>>> Webrev regenerated. >>>>>>> >>>>>>> I blindly coded >>>>>>> >>>>>>> - assert(rng->Opcode() == Op_LoadRange || _igvn.type(rng)->is_int() >= >>>>>>> 0, >>>>>>> "must be"); >>>>>>> + assert(rng->Opcode() == Op_LoadRange || >>>>>>> _igvn.type(rng)->is_int()->_lo >>>>>>> >>>>>>> = 0, "must be"); >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 23, 2017 at 3:39 PM, Vladimir Kozlov < >>>>>>> vladimir.kozlov at oracle.com > >>>>>>> wrote: >>>>>>> >>>>>>> Thank you, Martin >>>>>>> >>>>>>> Yes, sign compare is bad for pointers. >>>>>>> >>>>>>> Note, for pointers compare with use NULL instead of 0. Please, >>>>>>> use >>>>>>> NULL. >>>>>>> >>>>>>> The assert check in loopPredicate.cpp is simple missing >>>>>>> reference >>>>>>> to >>>>>>> field _lo (low bound of values range): >>>>>>> >>>>>>> _igvn.type(rng)->is_int()->_lo >= 0 >>>>>>> >>>>>>> Please, fix it this way. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> On 8/23/17 2:25 PM, Martin Buchholz wrote: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8174050 >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ma >>>>>>> rtin/webrevs/openjdk10/pointer >>>>>>> -sign-comparison/ >>>>>>> >>>>>> artin/webrevs/openjdk10/pointe >>>>>>> r-sign-comparison/> >>>>>>> >>>>>>> My webrev could go in as is, but better would be for >>>>>>> someone to >>>>>>> figure out >>>>>>> the intent of the nonsensical assert in >>>>>>> >>>>>>> src/share/vm/opto/loopPredicate.cpp >>>>>>> >>>>>>> (There is more to be done to support clang, but this is >>>>>>> enough >>>>>>> to build >>>>>>> openjdk without patching source) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From vladimir.kozlov at oracle.com Thu Aug 24 21:16:01 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 14:16:01 -0700 Subject: RFR(XXS): 8183119: Resolve 'libkstat' dependency between open and closed part of JDK. In-Reply-To: <98445d3a-bf15-9f56-dbe8-d63384589798@oracle.com> References: <98445d3a-bf15-9f56-dbe8-d63384589798@oracle.com> Message-ID: <71cd35b0-51d0-b56d-3797-27cf8224b508@oracle.com> Good. Thanks, Vladimir On 8/24/17 6:06 AM, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:?? https://bugs.openjdk.java.net/browse/JDK-8183119 > > 8183119:Resolve 'libkstat' dependency between open and closed part of JDK. > > ??? libkstat no longer used in open part (after JDK-8172231). > > > This is the open part. > > Best regards, > Patric > > -----8<----- > > --- a/common/autoconf/flags.m4??? Tue Aug 22 16:20:29 2017 +0200 > +++ b/common/autoconf/flags.m4??? Thu Aug 24 11:25:58 2017 +0200 > @@ -1358,7 +1358,7 @@ > ?????? $2SOLARIS_LIBM_LIBS="/usr/lib/sparcv9/libm.so.1" > ???? fi > ???? $2JVM_LIBS="[$]$2JVM_LIBS -lsocket -lsched -ldl $SOLARIS_LIBM_LIBS > -lCrun \ > -??????? -lthread -ldoor -lc -ldemangle -lnsl -lkstat -lrt" > +??????? -lthread -ldoor -lc -ldemangle -lnsl -lrt" > ?? elif test "x$OPENJDK_$1_OS" = xmacosx; then > ???? $2JVM_LIBS="[$]$2JVM_LIBS -lm" > ?? elif test "x$OPENJDK_$1_OS" = xaix; then > > From coleen.phillimore at oracle.com Thu Aug 24 22:17:58 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 24 Aug 2017 18:17:58 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> Message-ID: <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> On 8/21/17 5:17 PM, Kim Barrett wrote: >> On Aug 21, 2017, at 11:57 AM, Erik ?sterlund wrote: >>> I?m fairly sure the runtime folks would say you should be surprised, and would object to such a change. The layout of symbol is carefully constructed, and I think such a change would increase the size of a symbol by 6 byes (not the obvious two) on a 64 bit platform. >> I find that surprising. By making body jbyte[0] instead, it seems to me (after a glance) to be possible to retain the size of the header from 8 bytes to 8 bytes after turning refcount to an int. This leaves only the difference in payload and its effect on the allocator and its alignment, which should seemingly not require 6 extra bytes. But perhaps I have misunderstood something about the layout of Symbol. > No, I misremembered. Yes, that change would cost an average of 2 additional bytes per symbol, assuming symbol name lengths mod 8 are fairly uniformly distributed, which seems likely. > > That?s still 2 extra bytes per symbol, and I doubt the runtime folks would like that, since they?ve been going to some trouble to reduce the size of symbols: > 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes > 8087143: Reduce Symbol::_identity_hash to 2 bytes Yes, the runtime folks would not like that after going through the trouble to reduce the size of Symbol. There can be lots of symbols. Coleen > >>>> 2) Implement it like jbyte cmpxchg. That would entail both calling a generalized AddShortUsingInt function object from the platform layer, and preferrably also using an int CAS loop for emulating the add operation rather than the current emulation using atomic int add, that relies on two short fields being placed next to each other, depending on endianness of the machine, using the ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or may not in fact enforce the intended alignment at compile time. >>>> 3) Continue emulating jshort Atomic::add with jint Atomi::add, but turn it into an AddShortUsingInt function object, called from the platform layer, like the similar CmpxchgByteUsingInt operation. >>>> >>>> So, I am curious if anyone would have loud objections if I was to remove Atomic::add support for jshort, and changed its single use (Symbol::_refcount), to use int instead. And if there are such objections, I wonder if we really want to continue using the ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or it is okay to rewrite it to use an cmpxch loop instead and get rid of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird API). >>> I don?t think it?s worth spending a lot of effort generalizing the short case right now. As you noticed, there is *exactly* one use of it, for the symbol refcount. Reconsider if that ever changes. >>> >> Okay, I agree. I will drop that for now. This single use case is probably not worth the effort. > Okay. > From david.holmes at oracle.com Fri Aug 25 01:58:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Aug 2017 11:58:51 +1000 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> Message-ID: On 24/08/2017 11:24 PM, John Paul Adrian Glaubitz wrote: > On 08/24/2017 03:20 PM, David Holmes wrote: >> Ouch! So I have to wonder whether the raw -D for the cpu arch name is >> really necessary. >> There's obviously a lot of legacy usage to consider here though. But >> I've often assumed/ >> expected that if we tell the compiler to build for a specific cpu then >> the compiler would >> provide a suitable define (probably underscored) that we could then >> use in the code if needed. > > I agree. The string "LEGACY" in the identifier seems to confirm that. > Might be a good idea > to open a separate bug for the removal of this identifier. Seems usage of these -D values are pervasive throughout the hotspot sources, so they won't be going away. >> Short-term solution would be your option (b) and rename alpha and sh >> to something unlikely to cause a clash. > Will do. > > I guess we can merge 8186723 without any changes then? It doesn't rely > on the legacy > (lowercase) identifier but on the all-uppercase identifier anyways. I guess so. BTW it is odd that this: #error Method os::dll_load requires that one of following is defined:\ AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc is a mix of the configure generated -D values and what are presumably compiler defined ones. It should, for consistency, be using PPC32, PPC64 and SPARC. David > Adrian > From glaubitz at physik.fu-berlin.de Fri Aug 25 09:10:23 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 25 Aug 2017 11:10:23 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> <3cb65ceb-c575-e446-bb66-a50c4b02684a@physik.fu-berlin.de> Message-ID: <95ae4568-fb60-2968-8841-55cd9a6b7e2c@physik.fu-berlin.de> On 08/24/2017 06:19 PM, Thomas St?fe wrote: > Sorry, I should have been more specific. The gtests have nothing to do with the jtreg suite, they are a set of native tests using google test. No problem. I'm still a relatively new to OpenJDK development, that's why I need these heads-ups ;). > Just execute (from your build directory): ./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk Ok, thanks! > There is also a way to execute them from the make, but I do not know how. "make check" doesn't work :(. FWIW, I also talked to Oracle's toolchain guy for Linux SPARC and he told me, the memset implementation in glibc has the same problem on Linux. So, your reservations are actually justified and we should use the SPARC version of memset_with_concurrent_readers on Zero on SPARC as well. The problem is just how to make the code available outside the cpu/sparc tree. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri Aug 25 09:14:02 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 25 Aug 2017 11:14:02 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> Message-ID: On 08/25/2017 03:58 AM, David Holmes wrote: >> I agree. The string "LEGACY" in the identifier seems to confirm that. Might be a good idea >> to open a separate bug for the removal of this identifier. > > Seems usage of these -D values are pervasive throughout the hotspot sources, so they won't be going away. There are two variants though. One with uppercase and one with lowercase. From what I can see, only the uppercase versions are only ever used, i.e. it's "#ifdef(SPARC)" but never "#ifdef(sparc)". >>> Short-term solution would be your option (b) and rename alpha and sh to something unlikely to cause a clash. >> Will do. >> >> I guess we can merge 8186723 without any changes then? It doesn't rely on the legacy >> (lowercase) identifier but on the all-uppercase identifier anyways. > > I guess so. Ok. Then I guess we need a second reviewer? Thomas, any concerns from your side? > BTW it is odd that this: > > #error Method os::dll_load requires that one of following is defined:\ > AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc > > is a mix of the configure generated -D values and what are presumably compiler defined ones. It should, for consistency, be using PPC32, PPC64 and SPARC. Yep, I noticed that as well. I can fix that after merging this one :-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Fri Aug 25 14:05:26 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 25 Aug 2017 10:05:26 -0400 Subject: RFR (M) 8186042: Optimize OopMapCache lookup In-Reply-To: <7c36b086-5959-753b-1626-415817d53525@oracle.com> References: <7c36b086-5959-753b-1626-415817d53525@oracle.com> Message-ID: <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> This was reviewed on hotspot-runtime-dev but it was noticed that the traversal of the interpreter's OopMapCache can be done outside of a safepoint by the graal compiler and by stack walking. This would make reclamation of the "old" cached entries not safe. I have disallowed use of the interpreter OopMapCache in this change by any calls outside of GC. The OopMapCache is an optimization primarily (now exclusively) for GC root walking. open webrev at http://cr.openjdk.java.net/~coleenp/8186042.02/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8186042 Retested with jck tests with -Xlog:interpreter+oopmap=debug, hotspot tier1 which includes the compiler AOT tests that failed, jvmti tests, and stack walking tests in the jdk. Thanks, Coleen On 8/11/17 11:46 AM, coleen.phillimore at oracle.com wrote: > Summary: Use lock free access to oopMapCache > Contributed-by: frederic.parain at oracle.com, coleen.phillimore at oracle.com > > The OopMapCache::lookup() function took out a mutex to protect access > between the GC threads that are running concurrently. See bug for > more info. The function lookup() is run by multiple GC threads > concurrently. If there's a collision in the hashtable, this uses > atomic cmpxchg to add the entry to a list to be cleaned up after the > safepoint is over. GC isn't doing lookup at that point. > > This change is contributed by Frederic Parain, with some cleanup and > logging from me. > > open webrev at http://cr.openjdk.java.net/~coleenp/8186042.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8186042 > > Tested with RBT equivalent of nightly on linux x64. Also ran dacapo > with -Xint -Xlog:interpreter+oopmap=debug to verify. This change also > removes -XX:+TraceOopMapGeneration (not -XX:+TraceNewOopMapGeneration > however) in favor of new logging. A linked CSR request is pending. > > Thanks, > Coleen > From erik.osterlund at oracle.com Fri Aug 25 15:28:08 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 25 Aug 2017 17:28:08 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> Message-ID: <59A04208.70809@oracle.com> Hi Coleen, On 2017-08-25 00:17, coleen.phillimore at oracle.com wrote: > > > On 8/21/17 5:17 PM, Kim Barrett wrote: >>> On Aug 21, 2017, at 11:57 AM, Erik ?sterlund >>> wrote: >>>> I?m fairly sure the runtime folks would say you should be >>>> surprised, and would object to such a change. The layout of symbol >>>> is carefully constructed, and I think such a change would increase >>>> the size of a symbol by 6 byes (not the obvious two) on a 64 bit >>>> platform. >>> I find that surprising. By making body jbyte[0] instead, it seems to >>> me (after a glance) to be possible to retain the size of the header >>> from 8 bytes to 8 bytes after turning refcount to an int. This >>> leaves only the difference in payload and its effect on the >>> allocator and its alignment, which should seemingly not require 6 >>> extra bytes. But perhaps I have misunderstood something about the >>> layout of Symbol. >> No, I misremembered. Yes, that change would cost an average of 2 >> additional bytes per symbol, assuming symbol name lengths mod 8 are >> fairly uniformly distributed, which seems likely. >> >> That?s still 2 extra bytes per symbol, and I doubt the runtime folks >> would like that, since they?ve been going to some trouble to reduce >> the size of symbols: >> 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes >> 8087143: Reduce Symbol::_identity_hash to 2 bytes > > Yes, the runtime folks would not like that after going through the > trouble to reduce the size of Symbol. There can be lots of symbols. Thank you for clarifying that. Perhaps coming from GC, my view on this memory optimization is different. But I will respect your view and not question this decision. In that case, I see no current objections to the solution Kim handed off to me. Are we good to go? Thanks, /Erik > > Coleen > >> >>>>> 2) Implement it like jbyte cmpxchg. That would entail both calling >>>>> a generalized AddShortUsingInt function object from the platform >>>>> layer, and preferrably also using an int CAS loop for emulating >>>>> the add operation rather than the current emulation using atomic >>>>> int add, that relies on two short fields being placed next to each >>>>> other, depending on endianness of the machine, using the >>>>> ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or >>>>> may not in fact enforce the intended alignment at compile time. >>>>> 3) Continue emulating jshort Atomic::add with jint Atomi::add, but >>>>> turn it into an AddShortUsingInt function object, called from the >>>>> platform layer, like the similar CmpxchgByteUsingInt operation. >>>>> >>>>> So, I am curious if anyone would have loud objections if I was to >>>>> remove Atomic::add support for jshort, and changed its single use >>>>> (Symbol::_refcount), to use int instead. And if there are such >>>>> objections, I wonder if we really want to continue using the >>>>> ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or >>>>> it is okay to rewrite it to use an cmpxch loop instead and get rid >>>>> of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird >>>>> API). >>>> I don?t think it?s worth spending a lot of effort generalizing the >>>> short case right now. As you noticed, there is *exactly* one use >>>> of it, for the symbol refcount. Reconsider if that ever changes. >>>> >>> Okay, I agree. I will drop that for now. This single use case is >>> probably not worth the effort. >> Okay. >> > From aph at redhat.com Fri Aug 25 16:23:13 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Aug 2017 17:23:13 +0100 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <59A04208.70809@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> <59A04208.70809@oracle.com> Message-ID: <4c605fa0-e280-26fb-ef6c-72021d1281ab@redhat.com> On 25/08/17 16:28, Erik ?sterlund wrote: > In that case, I see no current objections to the solution Kim handed off > to me. Are we good to go? Yes. I'd rather not do it that way, but instead make the field a 32-bit integer type and unpack it as required, but I totally understand that it would be inconvenient for users of Symbol. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From serguei.spitsyn at oracle.com Sat Aug 26 00:27:16 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 25 Aug 2017 17:27:16 -0700 Subject: RFR (M) 8186042: Optimize OopMapCache lookup In-Reply-To: <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> References: <7c36b086-5959-753b-1626-415817d53525@oracle.com> <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> Message-ID: <881cc9cd-6206-6306-14b2-d1992ed7f4f2@oracle.com> Hi Coleen, The update looks good to me. Thanks, Serguei On 8/25/17 07:05, coleen.phillimore at oracle.com wrote: > > This was reviewed on hotspot-runtime-dev but it was noticed that the > traversal of the interpreter's OopMapCache can be done outside of a > safepoint by the graal compiler and by stack walking. This would > make reclamation of the "old" cached entries not safe. I have > disallowed use of the interpreter OopMapCache in this change by any > calls outside of GC. The OopMapCache is an optimization primarily > (now exclusively) for GC root walking. > > open webrev at http://cr.openjdk.java.net/~coleenp/8186042.02/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8186042 > > Retested with jck tests with -Xlog:interpreter+oopmap=debug, hotspot > tier1 which includes the compiler AOT tests that failed, jvmti tests, > and stack walking tests in the jdk. > > Thanks, > Coleen > > On 8/11/17 11:46 AM, coleen.phillimore at oracle.com wrote: >> Summary: Use lock free access to oopMapCache >> Contributed-by: frederic.parain at oracle.com, coleen.phillimore at oracle.com >> >> The OopMapCache::lookup() function took out a mutex to protect access >> between the GC threads that are running concurrently. See bug for >> more info. The function lookup() is run by multiple GC threads >> concurrently. If there's a collision in the hashtable, this uses >> atomic cmpxchg to add the entry to a list to be cleaned up after the >> safepoint is over. GC isn't doing lookup at that point. >> >> This change is contributed by Frederic Parain, with some cleanup and >> logging from me. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186042 >> >> Tested with RBT equivalent of nightly on linux x64. Also ran dacapo >> with -Xint -Xlog:interpreter+oopmap=debug to verify. This change also >> removes -XX:+TraceOopMapGeneration (not -XX:+TraceNewOopMapGeneration >> however) in favor of new logging. A linked CSR request is pending. >> >> Thanks, >> Coleen >> > From rohitarulraj at gmail.com Sun Aug 27 16:27:18 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Sun, 27 Aug 2017 21:57:18 +0530 Subject: Help with generating library call In-Reply-To: References: <436f03b4-f352-e2df-4afb-a70905d3927e@redhat.com> Message-ID: On Wed, Aug 2, 2017 at 9:02 PM, Rohit Arul Raj wrote: > On Mon, Jul 31, 2017 at 1:48 PM, Andrew Haley wrote: >> On 31/07/17 05:33, Rohit Arul Raj wrote: >>> Can any one point me in the right direction? Any reference to similar >>> implementation of any other C or Math library function will be >>> helpful? Hi All, I got the call to 'memset' working, needed to save xmm0 & xmm1 registers also. Now for object initialization, instead of generating loop code I am using call to 'memset'. To confirm that all the objects gets initialized through 'memset', i tried to print out the objects/array sizes just before the call to memset/loop code. { __ push (rdi); __ push (rsi); __ push (rax); __ push (rdx); __ subptr(rsp, 8); __ movptr (rsi, rdx); __ movb (Address(rsp, 0), 73); __ movb (Address(rsp, 1), 110); __ movb (Address(rsp, 2), 58); __ movb (Address(rsp, 3), 37); __ movb (Address(rsp, 4), 100); __ movb (Address(rsp, 5), 10); __ movb (Address(rsp, 6), 0); __ movptr (rdi, rsp); __ call_VM_leaf (CAST_FROM_FN_PTR(address, printf), rdi, rsi); __ addptr(rsp, 8); __ pop (rdx); __ pop (rax); __ pop (rsi); __ pop (rdi); } I printed the object/array sizes that get initialized from the following functions: a) From the interpreter: src/cpu/x86/vm/templateTable_x86_64.cpp: Function:void TemplateTable::_new() b) From the compiler: src/cpu/x86/vm/c1_MacroAssembler_x86.cpp i) C1_MacroAssembler::initialize_object (const object sizes). ii) C1_MacroAssembler::initialize_body (for arrays and variable object sizes). src/cpu/x86/vm/macroAssembler_x86.cpp iii) void MacroAssembler::clear_mem But the overall total bytes initialized by adding all the above, accounts for only 30% of the total created bytes taken from GC log. Is there anywhere else in the code where the memory gets initialized which I might have missed? Any other suggestions? Thanks in advance, Rohit From david.holmes at oracle.com Sun Aug 27 21:32:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Aug 2017 07:32:12 +1000 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <95ae4568-fb60-2968-8841-55cd9a6b7e2c@physik.fu-berlin.de> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> <3cb65ceb-c575-e446-bb66-a50c4b02684a@physik.fu-berlin.de> <95ae4568-fb60-2968-8841-55cd9a6b7e2c@physik.fu-berlin.de> Message-ID: <1662e0a2-00c0-d992-0678-fe1651984068@oracle.com> On 25/08/2017 7:10 PM, John Paul Adrian Glaubitz wrote: > On 08/24/2017 06:19 PM, Thomas St?fe wrote: >> Sorry, I should have been more specific. The gtests have nothing to do >> with the jtreg suite, they are a set of native tests using google test. > > No problem. I'm still a relatively new to OpenJDK development, that's > why I need these heads-ups ;). > >> Just execute (from your build directory): >> ./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk > > Ok, thanks! > >> There is also a way to execute them from the make, but I do not know how. > > "make check" doesn't work :(. > > FWIW, I also talked to Oracle's toolchain guy for Linux SPARC and he > told me, the memset > implementation in glibc has the same problem on Linux. So, your > reservations are actually > justified and we should use the SPARC version of > memset_with_concurrent_readers on Zero > on SPARC as well. > > The problem is just how to make the code available outside the cpu/sparc > tree. I would be looking at how to include ./src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp in your build. Probably best to ask for help on build-dev - I'm no longer familiar with how that part of the build system operates. :( David > Adrian From glaubitz at physik.fu-berlin.de Sun Aug 27 21:52:24 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sun, 27 Aug 2017 23:52:24 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <1662e0a2-00c0-d992-0678-fe1651984068@oracle.com> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <14f28ddc-6929-dd0d-a77a-1a463c47d40b@oracle.com> <79503f9c-bc57-725e-b8f1-40cb522b9218@physik.fu-berlin.de> <90649da7-48e5-22b1-3118-5861c6bb0e24@physik.fu-berlin.de> <3cb65ceb-c575-e446-bb66-a50c4b02684a@physik.fu-berlin.de> <95ae4568-fb60-2968-8841-55cd9a6b7e2c@physik.fu-berlin.de> <1662e0a2-00c0-d992-0678-fe1651984068@oracle.com> Message-ID: On 08/27/2017 11:32 PM, David Holmes wrote: >> The problem is just how to make the code available outside the cpu/sparc tree. > > I would be looking at how to include ./src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp > in your build. Probably best to ask for help on build-dev - I'm > no longer familiar with how that part of the build system operates. :( No worries. I will come up with a solution, I just haven't looked at it yet since last week (it's still Sunday here :)). In any way, we can be confident now that we definitely need the SPARC- specific implementation even for Zero builds. Not having used it in the past, might explain some of the sporadic segfaults of Zero on Linux SPARC that we have observed, especially on newer SPARC CPUs (T5). Another Debian Developer just posted this earlier today from SPARC T4 Supplement: Block stores execute differently on SPARC T4 than on prior UltraSPARC processors. On previous processors, such as UltraSPARC T2, UltraSPARC T2+, and SPARC T3, block stores fetched the data from memory prior to updating the line with the store data. On SPARC T4, the processor first establishes the line in the L2 cache and zeroes the data, prior to updating the line with the store source data. The block store is helperized into 8 individual block init stores. The first helper establishes the line in the L2 cache, zeroes the line out, then updates the first 8 bytes of the line with the first 8 bytes of the store source data. The remaining seven helpers collectively update the remaining 56 bytes with the remaining 56 bytes of store source data. As a result, it is possible for another process to see the old data, the new data, or a value of zero while the block store is being executed. And since we currently don't use the SPARC-specific implementation on sparc64, this might explain the crashes on SPARC-T5. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sun Aug 27 21:54:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Aug 2017 07:54:54 +1000 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> Message-ID: <59a79a5e-34c3-022f-041f-da36630da231@oracle.com> On 25/08/2017 7:14 PM, John Paul Adrian Glaubitz wrote: > On 08/25/2017 03:58 AM, David Holmes wrote: >>> I agree. The string "LEGACY" in the identifier seems to confirm that. >>> Might be a good idea >>> to open a separate bug for the removal of this identifier. >> >> Seems usage of these -D values are pervasive throughout the >> hotspot sources, so they won't be going away. > > There are two variants though. One with uppercase and one with > lowercase. From what > I can see, only the uppercase versions are only ever used, i.e. it's > "#ifdef(SPARC)" > but never "#ifdef(sparc)". Not clear where the lowercase one is coming from - I don't see it in a solaris sparc build log. ?? (I do see sparcv9 when building tests though) David >>>> Short-term solution would be your option (b) and rename alpha and sh >>>> to something unlikely to cause a clash. >>> Will do. >>> >>> I guess we can merge 8186723 without any changes then? It doesn't >>> rely on the legacy >>> (lowercase) identifier but on the all-uppercase identifier anyways. >> >> I guess so. > > Ok. Then I guess we need a second reviewer? > > Thomas, any concerns from your side? > >> BTW it is odd that this: >> >> ?????? #error Method os::dll_load requires that one of following is >> defined:\ >> ????????? AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, >> PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc >> >> is a mix of the configure generated -D values and what are >> presumably compiler defined ones. It should, for consistency, be using >> PPC32, PPC64 and SPARC. > > Yep, I noticed that as well. I can fix that after merging this one :-). > > Adrian > From glaubitz at physik.fu-berlin.de Sun Aug 27 22:16:43 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 00:16:43 +0200 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: Message-ID: <54c281f0-0423-6679-f9a1-33c08fc4d9b9@physik.fu-berlin.de> Hi! On 08/24/2017 10:49 AM, John Paul Adrian Glaubitz wrote: > Please review the following changeset which adds SuperH as a new > architecture for linux [1]. This change is required to be able to > build linux-zero on SuperH running Linux. > >> [1] http://cr.openjdk.java.net/~glaubitz/8186723/webrev.01/ Are there any objections to this change? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sun Aug 27 23:08:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Aug 2017 09:08:11 +1000 Subject: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <54c281f0-0423-6679-f9a1-33c08fc4d9b9@physik.fu-berlin.de> References: <54c281f0-0423-6679-f9a1-33c08fc4d9b9@physik.fu-berlin.de> Message-ID: As my response got buried in the "name clash" thread ... Reviewed. I will sponsor this with myself and Thomas as reviewers. Thanks, David On 28/08/2017 8:16 AM, John Paul Adrian Glaubitz wrote: > Hi! > > On 08/24/2017 10:49 AM, John Paul Adrian Glaubitz wrote: >> Please review the following changeset which adds SuperH as a new >> architecture for linux [1]. This change is required to be able to >> build linux-zero on SuperH running Linux. >> >>> [1] http://cr.openjdk.java.net/~glaubitz/8186723/webrev.01/ > > Are there any objections to this change? > > Adrian > From david.holmes at oracle.com Mon Aug 28 01:51:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Aug 2017 11:51:44 +1000 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <59A04208.70809@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> <59A04208.70809@oracle.com> Message-ID: <4b72a57e-2c8e-2eb9-2857-ea75c653b97c@oracle.com> On 26/08/2017 1:28 AM, Erik ?sterlund wrote: > Hi Coleen, > > On 2017-08-25 00:17, coleen.phillimore at oracle.com wrote: >> >> >> On 8/21/17 5:17 PM, Kim Barrett wrote: >>>> On Aug 21, 2017, at 11:57 AM, Erik ?sterlund >>>> wrote: >>>>> I?m fairly sure the runtime folks would say you should be >>>>> surprised, and would object to such a change.? The layout of symbol >>>>> is carefully constructed, and I think such a change would increase >>>>> the size of a symbol by 6 byes (not the obvious two) on a 64 bit >>>>> platform. >>>> I find that surprising. By making body jbyte[0] instead, it seems to >>>> me (after a glance) to be possible to retain the size of the header >>>> from 8 bytes to 8 bytes after turning refcount to an int. This >>>> leaves only the difference in payload and its effect on the >>>> allocator and its alignment, which should seemingly not require 6 >>>> extra bytes. But perhaps I have misunderstood something about the >>>> layout of Symbol. >>> No, I misremembered.? Yes, that change would cost an average of 2 >>> additional bytes per symbol, assuming symbol name lengths mod 8 are >>> fairly uniformly distributed, which seems likely. >>> >>> That?s still 2 extra bytes per symbol, and I doubt the runtime folks >>> would like that, since they?ve been going to some trouble to reduce >>> the size of symbols: >>> 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes >>> 8087143: Reduce Symbol::_identity_hash to 2 bytes >> >> Yes, the runtime folks would not like that after going through the >> trouble to reduce the size of Symbol.? There can be lots of symbols. > > Thank you for clarifying that.? Perhaps coming from GC, my view on this > memory optimization is different. But I will respect your view and not > question this decision. > In that case, I see no current objections to the solution Kim handed off > to me. Are we good to go? I think you are good to go. Though I did have some queries buried in my earlier response, in particular in relation to the change in atomic_solaris_sparc.hpp to use a C++ cas-loop I queried: "Makes me wonder whether this version should not be in platform independent code ready to be inherited by a platform if needed? " If that is possible/reasonable it can still be deferred to the next phase. Thanks, David ----- > Thanks, > /Erik > >> >> Coleen >> >>> >>>>>> 2) Implement it like jbyte cmpxchg. That would entail both calling >>>>>> a generalized AddShortUsingInt function object from the platform >>>>>> layer, and preferrably also using an int CAS loop for emulating >>>>>> the add operation rather than the current emulation using atomic >>>>>> int add, that relies on two short fields being placed next to each >>>>>> other, depending on endianness of the machine, using the >>>>>> ATOMIC_SHORT_PAIR macro for declaring the short pair, that may or >>>>>> may not in fact enforce the intended alignment at compile time. >>>>>> 3) Continue emulating jshort Atomic::add with jint Atomi::add, but >>>>>> turn it into an AddShortUsingInt function object, called from the >>>>>> platform layer, like the similar CmpxchgByteUsingInt operation. >>>>>> >>>>>> So, I am curious if anyone would have loud objections if I was to >>>>>> remove Atomic::add support for jshort, and changed its single use >>>>>> (Symbol::_refcount), to use int instead. And if there are such >>>>>> objections, I wonder if we really want to continue using the >>>>>> ATOMIC_SHORT_PAIR macro and emulation using jint Atomic::add, or >>>>>> it is okay to rewrite it to use an cmpxch loop instead and get rid >>>>>> of the ATOMIC_SHORT_PAIR macro (that I find makes for a very weird >>>>>> API). >>>>> I don?t think it?s worth spending a lot of effort generalizing the >>>>> short case right now.? As you noticed, there is *exactly* one use >>>>> of it, for the symbol refcount. Reconsider if that ever changes. >>>>> >>>> Okay, I agree. I will drop that for now. This single use case is >>>> probably not worth the effort. >>> Okay. >>> >> > From david.holmes at oracle.com Mon Aug 28 03:37:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Aug 2017 13:37:12 +1000 Subject: RFR (M) 8186042: Optimize OopMapCache lookup In-Reply-To: <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> References: <7c36b086-5959-753b-1626-415817d53525@oracle.com> <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> Message-ID: Hi Coleen, On 26/08/2017 12:05 AM, coleen.phillimore at oracle.com wrote: > > This was reviewed on hotspot-runtime-dev but it was noticed that the > traversal of the interpreter's OopMapCache can be done outside of a > safepoint by the graal compiler and by stack walking.?? This would make > reclamation of the "old" cached entries not safe.? I have disallowed use > of the interpreter OopMapCache in this change by any calls outside of > GC.?? The OopMapCache is an optimization primarily (now exclusively) for > GC root walking. That seems a very reasonable restriction. This looks good to me. One nit: src/share/vm/oops/method.cpp + // and other uses generate an oopmap but do not save it in the cache. and -> any? Thanks, David ----- > open webrev at http://cr.openjdk.java.net/~coleenp/8186042.02/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8186042 > > Retested with jck tests with -Xlog:interpreter+oopmap=debug, hotspot > tier1 which includes the compiler AOT tests that failed, jvmti tests, > and stack walking tests in the jdk. > > Thanks, > Coleen > > On 8/11/17 11:46 AM, coleen.phillimore at oracle.com wrote: >> Summary: Use lock free access to oopMapCache >> Contributed-by: frederic.parain at oracle.com, coleen.phillimore at oracle.com >> >> The OopMapCache::lookup() function took out a mutex to protect access >> between the GC threads that are running concurrently.? See bug for >> more info.?? The function lookup() is run by multiple GC threads >> concurrently.? If there's a collision in the hashtable, this uses >> atomic cmpxchg to add the entry to a list to be cleaned up after the >> safepoint is over.?? GC isn't doing lookup at that point. >> >> This change is contributed by Frederic Parain, with some cleanup and >> logging from me. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186042 >> >> Tested with RBT equivalent of nightly on linux x64.? Also ran dacapo >> with -Xint -Xlog:interpreter+oopmap=debug to verify.? This change also >> removes -XX:+TraceOopMapGeneration (not -XX:+TraceNewOopMapGeneration >> however) in favor of new logging.? A linked CSR request is pending. >> >> Thanks, >> Coleen >> > From david.holmes at oracle.com Mon Aug 28 05:11:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Aug 2017 15:11:53 +1000 Subject: RFC: 8185062: os::is_MP() sometimes returns false In-Reply-To: <1aae9d33-2cfb-2428-fb32-0c6e8e44d1a8@oracle.com> References: <1aae9d33-2cfb-2428-fb32-0c6e8e44d1a8@oracle.com> Message-ID: <86731b3c-3f02-e11e-c50c-b739ccde1ca0@oracle.com> On 24/08/2017 5:49 AM, Daniel D. Daugherty wrote: > Vote: option #3 Thanks for all the additional input folks - seems option #3 is preferred by hardcore VM folk :) I'll look into this further now. Thanks, David > Dan > > > On 8/21/17 6:56 PM, David Holmes wrote: >> Surprising lack of response to this. >> >> Conservatism will likely dictate we go option #1 if we get no more >> feedback. >> >> Thanks, >> David >> >> On 2/08/2017 2:35 PM, David Holmes wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8185062 >>> >>> Is it time to completely remove runtime optimizations aimed at >>> uniprocessor systems ie. >>> >>> if (os::is_MP()) { >>> ?? x(); >>> } >>> >>> just becomes: >>> >>> x(); >>> >>> ? >>> >>> Does anyone care about uniprocessor systems _and_ care to the extent >>> that the overhead of things only necessary on MP systems (_lock >>> prefixes, explicit atomic instructions, memory barriers) would be a >>> problem? >>> >>> As outlined in the "bug" report there are three basic options: >>> >>> 1. Switch AssumeMP to be true by default (arguably necessary >>> regardless due to dynamic container environments) >>> >>> 2. Allow non-MP support to be built, but by default only build MP >>> support ie no runtime means to disable MP support, and compile-time >>> MP_ONLY/NOT_MP macros. >>> >>> 3. Assume the universe is MP and only allow MP to be built >>> >>> Cheers, >>> David >>> ----- > From erik.joelsson at oracle.com Mon Aug 28 09:05:06 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Aug 2017 11:05:06 +0200 Subject: RFR(XXS): 8183119: Resolve 'libkstat' dependency between open and closed part of JDK. In-Reply-To: <98445d3a-bf15-9f56-dbe8-d63384589798@oracle.com> References: <98445d3a-bf15-9f56-dbe8-d63384589798@oracle.com> Message-ID: <6a2eb952-7998-8bfe-8bad-101d8ebac651@oracle.com> Looks good. /Erik On 2017-08-24 15:06, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8183119 > > 8183119:Resolve 'libkstat' dependency between open and closed part of > JDK. > > libkstat no longer used in open part (after JDK-8172231). > > > This is the open part. > > Best regards, > Patric > > -----8<----- > > --- a/common/autoconf/flags.m4 Tue Aug 22 16:20:29 2017 +0200 > +++ b/common/autoconf/flags.m4 Thu Aug 24 11:25:58 2017 +0200 > @@ -1358,7 +1358,7 @@ > $2SOLARIS_LIBM_LIBS="/usr/lib/sparcv9/libm.so.1" > fi > $2JVM_LIBS="[$]$2JVM_LIBS -lsocket -lsched -ldl > $SOLARIS_LIBM_LIBS -lCrun \ > - -lthread -ldoor -lc -ldemangle -lnsl -lkstat -lrt" > + -lthread -ldoor -lc -ldemangle -lnsl -lrt" > elif test "x$OPENJDK_$1_OS" = xmacosx; then > $2JVM_LIBS="[$]$2JVM_LIBS -lm" > elif test "x$OPENJDK_$1_OS" = xaix; then > > From aph at redhat.com Mon Aug 28 09:23:27 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Aug 2017 10:23:27 +0100 Subject: Help with generating library call In-Reply-To: References: <436f03b4-f352-e2df-4afb-a70905d3927e@redhat.com> Message-ID: On 27/08/17 17:27, Rohit Arul Raj wrote: > Is there anywhere else in the code where the memory gets initialized > which I might have missed? Any other suggestions? I presume you've turned off C2 with -XX:TieredStopAtLevel=1. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rohitarulraj at gmail.com Mon Aug 28 09:42:34 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Mon, 28 Aug 2017 15:12:34 +0530 Subject: Help with generating library call In-Reply-To: References: <436f03b4-f352-e2df-4afb-a70905d3927e@redhat.com> Message-ID: On Mon, Aug 28, 2017 at 2:53 PM, Andrew Haley wrote: > On 27/08/17 17:27, Rohit Arul Raj wrote: >> Is there anywhere else in the code where the memory gets initialized >> which I might have missed? Any other suggestions? > > I presume you've turned off C2 with -XX:TieredStopAtLevel=1. > > -- Thanks Andrew, I have not. I will try with that option. Else with with C2 ON, I will try dumping the object/array cleared by funtion (Node* ClearArrayNode::clear_memory/File:hotspot\src\share\vm\opto\memnode.cpp). Regards, Rohit From aph at redhat.com Mon Aug 28 09:54:04 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Aug 2017 10:54:04 +0100 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> Message-ID: <59ed4643-ce19-e550-6400-36a1bd29231f@redhat.com> On 23/08/17 13:23, John Paul Adrian Glaubitz wrote: > The second instance is in src/share/vm/gc/shared/memset_with_concurrent_readers.hpp: > > #ifdef SPARC > > // SPARC requires special handling. See SPARC-specific definition. > > #else > // All others just use memset. > > inline void memset_with_concurrent_readers(void* to, int value, size_t size) { > ::memset(to, value, size); > } > > #endif // End of target dispatch. It certainly looks like this is wrong. The execution of memset with concurrent readers while the memory is being zeroed is UB, so we need some kind of special handling in the general case. I'm pretty sure this would work: inline void memset_with_concurrent_readers(void* to, int value, size_t size) { volatile char *dest = to; for (int i = 0; i < count; i++) *dest++ = value; } but its performance would be awful. It'd be interesting to try to figure out a portable C++ version which would work everywhere, but I guess that wouldn't be possible without C++11 atomics. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.osterlund at oracle.com Mon Aug 28 10:10:08 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 28 Aug 2017 12:10:08 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <4b72a57e-2c8e-2eb9-2857-ea75c653b97c@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> <59A04208.70809@oracle.com> <4b72a57e-2c8e-2eb9-2857-ea75c653b97c@oracle.com> Message-ID: <59A3EC00.7010907@oracle.com> Hi David, On 2017-08-28 03:51, David Holmes wrote: > On 26/08/2017 1:28 AM, Erik ?sterlund wrote: >> Hi Coleen, >> >> On 2017-08-25 00:17, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 8/21/17 5:17 PM, Kim Barrett wrote: >>>>> On Aug 21, 2017, at 11:57 AM, Erik ?sterlund >>>>> wrote: >>>>>> I?m fairly sure the runtime folks would say you should be >>>>>> surprised, and would object to such a change. The layout of >>>>>> symbol is carefully constructed, and I think such a change would >>>>>> increase the size of a symbol by 6 byes (not the obvious two) on >>>>>> a 64 bit platform. >>>>> I find that surprising. By making body jbyte[0] instead, it seems >>>>> to me (after a glance) to be possible to retain the size of the >>>>> header from 8 bytes to 8 bytes after turning refcount to an int. >>>>> This leaves only the difference in payload and its effect on the >>>>> allocator and its alignment, which should seemingly not require 6 >>>>> extra bytes. But perhaps I have misunderstood something about the >>>>> layout of Symbol. >>>> No, I misremembered. Yes, that change would cost an average of 2 >>>> additional bytes per symbol, assuming symbol name lengths mod 8 are >>>> fairly uniformly distributed, which seems likely. >>>> >>>> That?s still 2 extra bytes per symbol, and I doubt the runtime >>>> folks would like that, since they?ve been going to some trouble to >>>> reduce the size of symbols: >>>> 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes >>>> 8087143: Reduce Symbol::_identity_hash to 2 bytes >>> >>> Yes, the runtime folks would not like that after going through the >>> trouble to reduce the size of Symbol. There can be lots of symbols. >> >> Thank you for clarifying that. Perhaps coming from GC, my view on >> this memory optimization is different. But I will respect your view >> and not question this decision. >> In that case, I see no current objections to the solution Kim handed >> off to me. Are we good to go? > > I think you are good to go. Though I did have some queries buried in > my earlier response, in particular in relation to the change in > atomic_solaris_sparc.hpp to use a C++ cas-loop I queried: > > "Makes me wonder whether this version should not be in platform > independent code ready to be inherited by a platform if needed? " > > If that is possible/reasonable it can still be deferred to the next > phase. Thank you for the clarification. I agree that the CAS loop implementation of Atomic::add on solaris_sparc looks like it could potentially be generalized if needed. But as you say - let's defer that until next phase. Thanks, /Erik > > Thanks, > David > ----- > > >> Thanks, >> /Erik >> >>> >>> Coleen >>> >>>> >>>>>>> 2) Implement it like jbyte cmpxchg. That would entail both >>>>>>> calling a generalized AddShortUsingInt function object from the >>>>>>> platform layer, and preferrably also using an int CAS loop for >>>>>>> emulating the add operation rather than the current emulation >>>>>>> using atomic int add, that relies on two short fields being >>>>>>> placed next to each other, depending on endianness of the >>>>>>> machine, using the ATOMIC_SHORT_PAIR macro for declaring the >>>>>>> short pair, that may or may not in fact enforce the intended >>>>>>> alignment at compile time. >>>>>>> 3) Continue emulating jshort Atomic::add with jint Atomi::add, >>>>>>> but turn it into an AddShortUsingInt function object, called >>>>>>> from the platform layer, like the similar CmpxchgByteUsingInt >>>>>>> operation. >>>>>>> >>>>>>> So, I am curious if anyone would have loud objections if I was >>>>>>> to remove Atomic::add support for jshort, and changed its single >>>>>>> use (Symbol::_refcount), to use int instead. And if there are >>>>>>> such objections, I wonder if we really want to continue using >>>>>>> the ATOMIC_SHORT_PAIR macro and emulation using jint >>>>>>> Atomic::add, or it is okay to rewrite it to use an cmpxch loop >>>>>>> instead and get rid of the ATOMIC_SHORT_PAIR macro (that I find >>>>>>> makes for a very weird API). >>>>>> I don?t think it?s worth spending a lot of effort generalizing >>>>>> the short case right now. As you noticed, there is *exactly* one >>>>>> use of it, for the symbol refcount. Reconsider if that ever changes. >>>>>> >>>>> Okay, I agree. I will drop that for now. This single use case is >>>>> probably not worth the effort. >>>> Okay. >>>> >>> >> From glaubitz at physik.fu-berlin.de Mon Aug 28 10:09:17 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 12:09:17 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <59ed4643-ce19-e550-6400-36a1bd29231f@redhat.com> References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <59ed4643-ce19-e550-6400-36a1bd29231f@redhat.com> Message-ID: On 08/28/2017 11:54 AM, Andrew Haley wrote: > It certainly looks like this is wrong. The execution of memset with concurrent > readers while the memory is being zeroed is UB, so we need some kind of special > handling in the general case. Oh, I'm not saying it's wrong at all. I was just wondering whether it's actually required for performance reasons or whether there are other, more fundamental problems underlying. After talking to Oracle's toolchain guy for Linux SPARC, I now know that we cannot glibc's memset in this case, especially not on newer SPARC CPUs. I'm pretty sure this would work: > > inline void memset_with_concurrent_readers(void* to, int value, size_t size) { > volatile char *dest = to; > for (int i = 0; i < count; i++) > *dest++ = value; > } > > but its performance would be awful. My suggestion would be to move memset_with_concurrent_readers_sparc.cpp into a generic place in the source tree where it can be used for both the server and the zero builds on Linux SPARC. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Mon Aug 28 10:18:39 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Aug 2017 11:18:39 +0100 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: References: <088045c0-efcc-ab7a-a088-e80579a3c12b@physik.fu-berlin.de> <59ed4643-ce19-e550-6400-36a1bd29231f@redhat.com> Message-ID: <92e8896d-e395-3cc0-aaad-4110fa7ae5d9@redhat.com> On 28/08/17 11:09, John Paul Adrian Glaubitz wrote: > On 08/28/2017 11:54 AM, Andrew Haley wrote: >> It certainly looks like this is wrong. The execution of memset with concurrent >> readers while the memory is being zeroed is UB, so we need some kind of special >> handling in the general case. > > Oh, I'm not saying it's wrong at all. No, but I am. > I was just wondering whether it's actually required for performance > reasons or whether there are other, more fundamental problems > underlying. > > After talking to Oracle's toolchain guy for Linux SPARC, I now know > that we cannot glibc's memset in this case, especially not on newer > SPARC CPUs. Right, and we may have similar problems on other targets. > I'm pretty sure this would work: >> >> inline void memset_with_concurrent_readers(void* to, int value, size_t size) { >> volatile char *dest = to; >> for (int i = 0; i < count; i++) >> *dest++ = value; >> } >> >> but its performance would be awful. > > My suggestion would be to move > memset_with_concurrent_readers_sparc.cpp into a generic place in the > source tree where it can be used for both the server and the zero > builds on Linux SPARC. Do you really have to move it, though? Can't you #include it from zero? It very much is machine-dependent code. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Mon Aug 28 11:50:02 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 28 Aug 2017 07:50:02 -0400 Subject: RFR(XXS) 8186797: cardtable_rs in g1CollectedHeap::initialize() defined, but never used Message-ID: Please review this one line cleanup to remove unused cardtable_rs. It seems to be a leftover of refactoring G1RegionToSpaceMapper::create_mapper() to create_aux_memory_mapper(). Bug: https://bugs.openjdk.java.net/browse/JDK-8186797 Webrev: http://cr.openjdk.java.net/~zgu/8186797/webrev.00/ Test: hotspot_gc on Linux x64 with fastdebug and release build Thanks, -Zhengyu From erik.osterlund at oracle.com Mon Aug 28 12:00:36 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 28 Aug 2017 14:00:36 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <4c605fa0-e280-26fb-ef6c-72021d1281ab@redhat.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <24966946-FF24-4C51-A014-8DA1248D2503@oracle.com> <599ADBD5.6060903@oracle.com> <599B02D7.2000708@oracle.com> <21B38B93-DE8A-4AAB-A06E-7F543694CF95@oracle.com> <82bf3884-9479-fc56-c490-40cc058e9cef@oracle.com> <59A04208.70809@oracle.com> <4c605fa0-e280-26fb-ef6c-72021d1281ab@redhat.com> Message-ID: <59A405E4.9030904@oracle.com> Hi Andrew, On 2017-08-25 18:23, Andrew Haley wrote: > On 25/08/17 16:28, Erik ?sterlund wrote: >> In that case, I see no current objections to the solution Kim handed off >> to me. Are we good to go? > Yes. I'd rather not do it that way, but instead make the field a > 32-bit integer type and unpack it as required, but I totally > understand that it would be inconvenient for users of Symbol. > Okay. Thanks for the review. /Erik From coleen.phillimore at oracle.com Mon Aug 28 12:46:00 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Aug 2017 08:46:00 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> Message-ID: http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html Can Atomic::{inc,dec}(volatile jshort* dest) use u2 instead?? And the jshort version of Atomic::add use u2 instead of jshort??? Can it be done as a follow on change, since I thought we were trying to remove the jtypes from this runtime internal code? I was confused, I thought you'd do Atomic::inc() in this change, but I'm in all in favor of limiting changes like this. What is the distinction between FetchAndAdd and AddAndFetch??? Does one assume that the value is in a register and is based on the underlying platform implementation?? Can you put a comment in atomic.hpp why one vs the other?? These platform inconsistencies are really painful since nobody can't test all the platforms.?? I don't need to see another version of this change, the rest looks ok to me. Thanks, Coleen On 8/20/17 2:16 AM, Kim Barrett wrote: > Please review this change to Atomic::add, making it a function > template with a per-platform underlying implementation. > > This change is similar to 8186166: "Generalize Atomic::cmpxchg with > templates", with similar goals and taking a similar approach. > > This change deprecates add_ptr. Followup changes will convert > existing uses of cmpxchg_ptr and eventually remove it. Followup > changes will also update uses of cmpxchg that can be simplified > because of the generalized API. Only changes to usage that were > required by the new implementation have been made so far. > > The add function calls private Atomic::AddImpl, to select among > several cases, based on the argument types. Each case performs some > checking and possibly conversion to reach a standard form of the > arguments (or fail and report a compile time error), which are then > passed to private Atomic::PlatformAdd. > > Only safe conversions of the first (add_value) argument are made by > the AddImpl layer. add_value must be integral, and is never narrowed. > dest's value type must be either integral or a pointer type. When > both are integral, they must be of the same signedness. If smaller, > add_value will be promited to the same size as dest's value type. > > The PlatformAdd class is provided by each platform, and performs > additional case analysis to generate the appropriate code for the > platform. Most PlatformAdd implementations use one of two helper base > classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide > common parts of the implementation in terms of a support function > provided by the derived PlatformAdd, accessed using CRTP. > > This change involves modifications to all of the existing platform > implementations of Atomic::add. I've updated all of the platforms, > but only tested those supported by Oracle. I'll need help from the > various platform maintainers to check and test my changes. > > Changes to files can be categorized as follows: > > [No new metaprogramming tools!] > > Change add to a template: > atomic.hpp > > Oracle-supported platforms: > atomic_bsd_x86.hpp - 64bit only > atomic_linux_arm.hpp > atomic_linux_x86.hpp > atomic_solaris_sparc.hpp > solaris_sparc.il > atomic_solaris_x86.hpp > atomic_windows_x86 > > Non-Oracle platform changes: > atomic_aix_ppc.hpp > atomic_bsd_x86.hpp - 32bit > atomic_bsd_zero.hpp > atomic_linux_aarch.hpp > atomic_linux_ppc.hpp > atomic_linux_s390.hpp > atomic_linux_sparc.hpp > atomic_linux_zero.hpp > > Usage changes required by API change: > g1CardLiveData.cpp > g1ConcurrentMark.cpp > g1HotCardCache.cpp > g1HotCardCache.hpp > g1RemSet.cpp > symbol.cpp > mallocTracker.hpp > > A few specific items: > > - atomic_linux_arm.hpp > > Neither add variant has "cc" in the clobbers list, even though the > condition codes are modified. That seems like a pre-existing bug. > > - atomic_linux_sparc.hpp > > Neither add variant has "cc" in the clobbers list, even though the > condition codes are modified. That seems like a pre-existing bug. > > The 32-bit add was using intptr_t as the rv type. Probably a harmless > copy-paste mistake. Now using template parameter type. > > Uses hard-coded machine registers and assumes the inline-asm > processing assigns the values to the corresponding machine registers, > even though the given constraints are just generic register requests. > I don't understand how this can work. > > - atomic_solaris_sparc.hpp > > Atomic::add was implemented using asm code in solaris_sparc.il. I was > going to change it to use gcc-style inline-asm, but the linux_sparc > version wasn't helpful this time (unlike for cmpxchg) (see above). > Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much > simpler code, and should be no less efficient, assuming the compiler > does it's job. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8186476 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ > > Testing: > Ad hoc hotspot nightly test. > > From coleen.phillimore at oracle.com Mon Aug 28 12:50:42 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Aug 2017 08:50:42 -0400 Subject: RFR (M) 8186042: Optimize OopMapCache lookup In-Reply-To: References: <7c36b086-5959-753b-1626-415817d53525@oracle.com> <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> Message-ID: <52021915-6dc2-24b3-aaa2-6958edd11e24@oracle.com> On 8/27/17 11:37 PM, David Holmes wrote: > Hi Coleen, > > On 26/08/2017 12:05 AM, coleen.phillimore at oracle.com wrote: >> >> This was reviewed on hotspot-runtime-dev but it was noticed that the >> traversal of the interpreter's OopMapCache can be done outside of a >> safepoint by the graal compiler and by stack walking.?? This would >> make reclamation of the "old" cached entries not safe.? I have >> disallowed use of the interpreter OopMapCache in this change by any >> calls outside of GC.?? The OopMapCache is an optimization primarily >> (now exclusively) for GC root walking. > > That seems a very reasonable restriction. This looks good to me. > > One nit: src/share/vm/oops/method.cpp > > +? // and other uses generate an oopmap but do not save it in the cache. > > and -> any? Thank you,? I'll fix that typo. thanks! Coleen > > Thanks, > David > ----- > > >> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.02/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186042 >> >> Retested with jck tests with -Xlog:interpreter+oopmap=debug, hotspot >> tier1 which includes the compiler AOT tests that failed, jvmti tests, >> and stack walking tests in the jdk. >> >> Thanks, >> Coleen >> >> On 8/11/17 11:46 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Use lock free access to oopMapCache >>> Contributed-by: frederic.parain at oracle.com, >>> coleen.phillimore at oracle.com >>> >>> The OopMapCache::lookup() function took out a mutex to protect >>> access between the GC threads that are running concurrently. See bug >>> for more info.?? The function lookup() is run by multiple GC threads >>> concurrently.? If there's a collision in the hashtable, this uses >>> atomic cmpxchg to add the entry to a list to be cleaned up after the >>> safepoint is over.?? GC isn't doing lookup at that point. >>> >>> This change is contributed by Frederic Parain, with some cleanup and >>> logging from me. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8186042 >>> >>> Tested with RBT equivalent of nightly on linux x64.? Also ran dacapo >>> with -Xint -Xlog:interpreter+oopmap=debug to verify. This change >>> also removes -XX:+TraceOopMapGeneration (not >>> -XX:+TraceNewOopMapGeneration however) in favor of new logging.? A >>> linked CSR request is pending. >>> >>> Thanks, >>> Coleen >>> >> From coleen.phillimore at oracle.com Mon Aug 28 12:51:10 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Aug 2017 08:51:10 -0400 Subject: RFR (M) 8186042: Optimize OopMapCache lookup In-Reply-To: <881cc9cd-6206-6306-14b2-d1992ed7f4f2@oracle.com> References: <7c36b086-5959-753b-1626-415817d53525@oracle.com> <37a0af4c-a981-8110-776f-6a97d54fe0a2@oracle.com> <881cc9cd-6206-6306-14b2-d1992ed7f4f2@oracle.com> Message-ID: Thanks Serguei for the re-review. Coleen On 8/25/17 8:27 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The update looks good to me. > > Thanks, > Serguei > > On 8/25/17 07:05, coleen.phillimore at oracle.com wrote: >> >> This was reviewed on hotspot-runtime-dev but it was noticed that the >> traversal of the interpreter's OopMapCache can be done outside of a >> safepoint by the graal compiler and by stack walking.?? This would >> make reclamation of the "old" cached entries not safe.? I have >> disallowed use of the interpreter OopMapCache in this change by any >> calls outside of GC.?? The OopMapCache is an optimization primarily >> (now exclusively) for GC root walking. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.02/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186042 >> >> Retested with jck tests with -Xlog:interpreter+oopmap=debug, hotspot >> tier1 which includes the compiler AOT tests that failed, jvmti tests, >> and stack walking tests in the jdk. >> >> Thanks, >> Coleen >> >> On 8/11/17 11:46 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Use lock free access to oopMapCache >>> Contributed-by: frederic.parain at oracle.com, >>> coleen.phillimore at oracle.com >>> >>> The OopMapCache::lookup() function took out a mutex to protect >>> access between the GC threads that are running concurrently. See bug >>> for more info.?? The function lookup() is run by multiple GC threads >>> concurrently.? If there's a collision in the hashtable, this uses >>> atomic cmpxchg to add the entry to a list to be cleaned up after the >>> safepoint is over.?? GC isn't doing lookup at that point. >>> >>> This change is contributed by Frederic Parain, with some cleanup and >>> logging from me. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186042.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8186042 >>> >>> Tested with RBT equivalent of nightly on linux x64.? Also ran dacapo >>> with -Xint -Xlog:interpreter+oopmap=debug to verify. This change >>> also removes -XX:+TraceOopMapGeneration (not >>> -XX:+TraceNewOopMapGeneration however) in favor of new logging. A >>> linked CSR request is pending. >>> >>> Thanks, >>> Coleen >>> >> > From vladimir.x.ivanov at oracle.com Mon Aug 28 13:49:08 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 28 Aug 2017 16:49:08 +0300 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: <375df370-b935-514f-fbee-aba92a0fde2d@oracle.com> References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> <375df370-b935-514f-fbee-aba92a0fde2d@oracle.com> Message-ID: > On compiler-dev Gerard specifically asks: > > Can someone please review the > "hotspot/src/cpu/sparc/vm/macroAssembler_sparc.cpp? file to determine > whether we still need the three "save_frame_and_mov(0, Lmethod, > Lmethod);? calls where the comment said it was needed by -Xprof? > > Do we leave those save_frame_and_mov() calls as is (and add comment as > to why they are still needed), or can we change them into save_frame() > calls? I don't have a strong opinion, but I'd prefer to keep them as is. Though all 3 usages are in debug code (either guarded by #ifdef ASSERT or VerifyThread), the code is transitively used in template interpreter. So, I suspect dropping Lmethod will break interpreter stack frame attribution (frame::is_interpreted_frame_valid) in those narrow periods when temporary frames are alive and will affect JFR & AsyncGetCallTrace(). Best regards, Vladimir Ivanov From bob.vandette at oracle.com Mon Aug 28 14:40:53 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 28 Aug 2017 10:40:53 -0400 Subject: RFR: 8186248 - Allow more flexibility in selecting Heap % of available RAM Message-ID: <4978B55B-5E2E-4A68-B108-AE70971853A8@oracle.com> Please review this updated webrev with changes suggested by David Holmes. Webrev: http://cr.openjdk.java.net/~bobv/8186248/webrev.02 This CR https://bugs.openjdk.java.net/browse/JDK-8186248 deprecates the MaxRAMFraction, MinRAMFraction and InitialRAMFraction VM options in JDK 10 and adds three new options which allow the user the ability to select a percentage of available memory to be used for the Java Heap. MaxRAMPercentage MinRAMPercentage InitialRMAPercentage Please let me know if anyone objects to the flag name and deprecation as I am in the process of filing a CCC (CSR). Thanks, Bob. From gerard.ziemski at oracle.com Mon Aug 28 14:48:25 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 28 Aug 2017 09:48:25 -0500 Subject: RFR 8173715 (rev2): Remove Flat Profiler In-Reply-To: References: <70CB4645-370D-488F-90ED-9A4ADABF06CF@oracle.com> <945d7c05-1611-1ca7-72f4-1a9858357356@oracle.com> <375df370-b935-514f-fbee-aba92a0fde2d@oracle.com> Message-ID: <46525EAE-AC44-4885-9F3A-93EF7B74B6B9@oracle.com> Thank you! > On Aug 28, 2017, at 8:49 AM, Vladimir Ivanov wrote: > > >> On compiler-dev Gerard specifically asks: >> Can someone please review the "hotspot/src/cpu/sparc/vm/macroAssembler_sparc.cpp? file to determine whether we still need the three "save_frame_and_mov(0, Lmethod, Lmethod);? calls where the comment said it was needed by -Xprof? >> Do we leave those save_frame_and_mov() calls as is (and add comment as to why they are still needed), or can we change them into save_frame() calls? > > I don't have a strong opinion, but I'd prefer to keep them as is. > > Though all 3 usages are in debug code (either guarded by #ifdef ASSERT or VerifyThread), the code is transitively used in template interpreter. > > So, I suspect dropping Lmethod will break interpreter stack frame attribution (frame::is_interpreted_frame_valid) in those narrow periods when temporary frames are alive and will affect JFR & AsyncGetCallTrace(). > > Best regards, > Vladimir Ivanov From thomas.schatzl at oracle.com Mon Aug 28 15:20:14 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Aug 2017 17:20:14 +0200 Subject: RFR(XXS) 8186797: cardtable_rs in g1CollectedHeap::initialize() defined, but never used In-Reply-To: References: Message-ID: <1503933614.2906.2.camel@oracle.com> Hi, On Mon, 2017-08-28 at 07:50 -0400, Zhengyu Gu wrote: > Please review this one line cleanup to remove unused cardtable_rs. > > It seems to be a leftover of refactoring? > G1RegionToSpaceMapper::create_mapper() to create_aux_memory_mapper(). > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186797 > Webrev: http://cr.openjdk.java.net/~zgu/8186797/webrev.00/ > > Test: > > hotspot_gc on Linux x64 with fastdebug and release build ? looks good. Thomas From HORIE at jp.ibm.com Mon Aug 28 15:20:23 2017 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Tue, 29 Aug 2017 00:20:23 +0900 Subject: RFR(M) 8186834:Expanding old area without full GC in parallel GC Message-ID: Dear all, Would you please review the following change? bug: https://bugs.openjdk.java.net/browse/JDK-8186834 webrev: http://cr.openjdk.java.net/~mhorie/8186834/webrev.00/ In parallel GC, old area is expanded only after a full GC occurs. I am wondering if we could give an option to expand old area without full GC. So, I added an option UseAdaptiveGenerationSizePolicyBeforeMajorCollection. Following is a simple micro benchmark I used to see the benefit of this change. As a result, pause time of full GC reduced by 30%. Full GC count reduced by 54%. Elapsed time reduced by 7%. import java.util.HashMap; import java.util.Map; public class HeapExpandTest { static Map map = new HashMap<>(); public static void main(String[] args) throws Exception { long start = System.currentTimeMillis(); for (int i = 0; i < 2200; ++i) { map.put(i, new byte[1024*1024]); // 1MB } System.out.println("elapsed= " + (System.currentTimeMillis() - start)); } } JVM options: -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy -XX:ParallelGCThreads=8 -Xms64m -Xmx3g -XX:+UseAdaptiveGenerationSizePolicyBeforeMajorCollection Best regards, -- Michihiro, IBM Research - Tokyo From erik.osterlund at oracle.com Mon Aug 28 16:33:28 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 28 Aug 2017 18:33:28 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> Message-ID: <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> Hi Coleen, > On 28 Aug 2017, at 14:46, coleen.phillimore at oracle.com wrote: > > > http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html > > Can Atomic::{inc,dec}(volatile jshort* dest) use u2 instead? And the jshort version of Atomic::add use u2 instead of jshort? Can it be done as a follow on change, since I thought we were trying to remove the jtypes from this runtime internal code? Yes. I will file an RFE for that. > I was confused, I thought you'd do Atomic::inc() in this change, but I'm in all in favor of limiting changes like this. I have worked on Atomic::inc/dec in a follow on RFE that I am currently running through testing. > What is the distinction between FetchAndAdd and AddAndFetch? Does one assume that the value is in a register and is based on the underlying platform implementation? Can you put a comment in atomic.hpp why one vs the other? These platform inconsistencies are really painful since nobody can't test all the platforms. I don't need to see another version of this change, the rest looks ok to me. The distinction is whether the platform specialization returns the value before or after the add, i.e., whether whether the returned fetched value corresponds to the old or new value, as indicated by the corresponding name. This is a standard convention used by e.g. GCC intrinsics. Unfortunately I have already pushed the change as David and Andrew said I was good to go. I am sorry about that. I will add a short comment in a subsequent inc/dec patch for you. Thanks for the review. Thanks, /Erik > Thanks, > Coleen > > >> On 8/20/17 2:16 AM, Kim Barrett wrote: >> Please review this change to Atomic::add, making it a function >> template with a per-platform underlying implementation. >> >> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >> templates", with similar goals and taking a similar approach. >> >> This change deprecates add_ptr. Followup changes will convert >> existing uses of cmpxchg_ptr and eventually remove it. Followup >> changes will also update uses of cmpxchg that can be simplified >> because of the generalized API. Only changes to usage that were >> required by the new implementation have been made so far. >> >> The add function calls private Atomic::AddImpl, to select among >> several cases, based on the argument types. Each case performs some >> checking and possibly conversion to reach a standard form of the >> arguments (or fail and report a compile time error), which are then >> passed to private Atomic::PlatformAdd. >> >> Only safe conversions of the first (add_value) argument are made by >> the AddImpl layer. add_value must be integral, and is never narrowed. >> dest's value type must be either integral or a pointer type. When >> both are integral, they must be of the same signedness. If smaller, >> add_value will be promited to the same size as dest's value type. >> >> The PlatformAdd class is provided by each platform, and performs >> additional case analysis to generate the appropriate code for the >> platform. Most PlatformAdd implementations use one of two helper base >> classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide >> common parts of the implementation in terms of a support function >> provided by the derived PlatformAdd, accessed using CRTP. >> >> This change involves modifications to all of the existing platform >> implementations of Atomic::add. I've updated all of the platforms, >> but only tested those supported by Oracle. I'll need help from the >> various platform maintainers to check and test my changes. >> >> Changes to files can be categorized as follows: >> >> [No new metaprogramming tools!] >> >> Change add to a template: >> atomic.hpp >> >> Oracle-supported platforms: >> atomic_bsd_x86.hpp - 64bit only >> atomic_linux_arm.hpp >> atomic_linux_x86.hpp >> atomic_solaris_sparc.hpp >> solaris_sparc.il >> atomic_solaris_x86.hpp >> atomic_windows_x86 >> >> Non-Oracle platform changes: >> atomic_aix_ppc.hpp >> atomic_bsd_x86.hpp - 32bit >> atomic_bsd_zero.hpp >> atomic_linux_aarch.hpp >> atomic_linux_ppc.hpp >> atomic_linux_s390.hpp >> atomic_linux_sparc.hpp >> atomic_linux_zero.hpp >> >> Usage changes required by API change: >> g1CardLiveData.cpp >> g1ConcurrentMark.cpp >> g1HotCardCache.cpp >> g1HotCardCache.hpp >> g1RemSet.cpp >> symbol.cpp >> mallocTracker.hpp >> >> A few specific items: >> >> - atomic_linux_arm.hpp >> >> Neither add variant has "cc" in the clobbers list, even though the >> condition codes are modified. That seems like a pre-existing bug. >> >> - atomic_linux_sparc.hpp >> >> Neither add variant has "cc" in the clobbers list, even though the >> condition codes are modified. That seems like a pre-existing bug. >> >> The 32-bit add was using intptr_t as the rv type. Probably a harmless >> copy-paste mistake. Now using template parameter type. >> >> Uses hard-coded machine registers and assumes the inline-asm >> processing assigns the values to the corresponding machine registers, >> even though the given constraints are just generic register requests. >> I don't understand how this can work. >> >> - atomic_solaris_sparc.hpp >> >> Atomic::add was implemented using asm code in solaris_sparc.il. I was >> going to change it to use gcc-style inline-asm, but the linux_sparc >> version wasn't helpful this time (unlike for cmpxchg) (see above). >> Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much >> simpler code, and should be no less efficient, assuming the compiler >> does it's job. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8186476 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >> >> Testing: >> Ad hoc hotspot nightly test. >> >> > From glaubitz at physik.fu-berlin.de Mon Aug 28 18:50:00 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 20:50:00 +0200 Subject: linux-sparc and linux-zero builds broken Message-ID: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> Hello! One of the recent changes, most likely, 8186476, broke the builds on linux-sparc and linux-zero: /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/runtime/atomic.hpp:342:0, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/memory/allocation.inline.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/oops/array.hpp:29, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/memory/universe.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/code/oopRecorder.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/asm/codeBuffer.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/asm/assembler.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/asm/macroAssembler.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/cpu/sparc/vm/nativeInst_sparc.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/code/nativeInst.hpp:30, from ad_sparc.hpp:32, from ad_sparc_pipeline.cpp:28: if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_adaptiveFreeList.o:\n" * For target hotspot_variant-server_libjvm_objs_adaptiveFreeList.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_adaptiveFreeList.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/runtime/atomic.hpp:342:0, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/memory/allocation.inline.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/utilities/growableArray.hpp:29, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/utilities/histogram.hpp:30, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/runtime/mutex.hpp:30, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/gc/cms/freeChunk.hpp:31, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/gc/cms/adaptiveFreeList.cpp:27: /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp: In member function ?D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = I; D = D; long unsigned int byte_size = 4]?: /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: error: there are no arguments to ?STATIC_CAST? that depend on a template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] STATIC_CAST(4 == sizeof(I)); ^~~~~~~~~~~ /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_adaptiveFreeList.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_adaptiveSizePolicy.o:\n" * For target hotspot_variant-server_libjvm_objs_adaptiveSizePolicy.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_adaptiveSizePolicy.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/runtime/atomic.hpp:342:0, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/memory/allocation.inline.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/runtime/perfData.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/gc/shared/collectedHeap.hpp:32, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/gc/shared/adaptiveSizePolicy.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/gc/shared/adaptiveSizePolicy.cpp:26: /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp: In member function ?D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = I; D = D; long unsigned int byte_size = 4]?: /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: error: there are no arguments to ?STATIC_CAST? that depend on a template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] STATIC_CAST(4 == sizeof(I)); ^~~~~~~~~~~ /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:66:3: error: there are no arguments to ?STATIC_CAST? that depend on a template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_adaptiveSizePolicy.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_addnode.o:\n" * For target hotspot_variant-server_libjvm_objs_addnode.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_addnode.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/runtime/atomic.hpp:342:0, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/memory/allocation.inline.hpp:28, from /home/glaubitz/openjdk/hs/hotspot/src/share/vm/opto/addnode.cpp:26: /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp: In member function ?D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = I; D = D; long unsigned int byte_size = 4]?: /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: error: there are no arguments to ?STATIC_CAST? that depend on a template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] STATIC_CAST(4 == sizeof(I)); ^~~~~~~~~~~ /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:66:3: error: there are no arguments to ?STATIC_CAST? that depend on a template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] STATIC_CAST(4 == sizeof(D)); ^~~~~~~~~~~ /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp: At global scope: if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_addnode.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "\n* All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === if /bin/grep -q "recipe for target .* failed" /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here ===\n" ; /bin/grep "recipe for target .* failed" /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ; /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi === Make failed targets repeated here === lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/adaptiveSizePolicy.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/adaptiveFreeList.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/accessFlags.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/abstractInterpreter_sparc.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/abstractInterpreter.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/addnode.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_peephole.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_pipeline.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_clone.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_format.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_expand.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_misc.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_gen.o' failed lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/ad_sparc.o' failed make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. /usr/bin/printf "Hint: See common/doc/building.html#troubleshooting for assistance.\n\n" Hint: See common/doc/building.html#troubleshooting for assistance. make[2]: Leaving directory '/home/glaubitz/openjdk/hs' /home/glaubitz/openjdk/hs/make/Init.gmk:291: recipe for target 'main' failed make[1]: *** [main] Error 2 make[1]: Leaving directory '/home/glaubitz/openjdk/hs' /home/glaubitz/openjdk/hs/make/Init.gmk:185: recipe for target 'default' failed make: *** [default] Error 2 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Mon Aug 28 19:33:00 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Aug 2017 15:33:00 -0400 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> Message-ID: <5d8c1375-12af-ef75-acd6-264599416c68@oracle.com> On 8/28/17 12:33 PM, Erik Osterlund wrote: > Hi Coleen, > >> On 28 Aug 2017, at 14:46, coleen.phillimore at oracle.com wrote: >> >> >> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html >> >> Can Atomic::{inc,dec}(volatile jshort* dest) use u2 instead? And the jshort version of Atomic::add use u2 instead of jshort? Can it be done as a follow on change, since I thought we were trying to remove the jtypes from this runtime internal code? > Yes. I will file an RFE for that. Thanks! > >> I was confused, I thought you'd do Atomic::inc() in this change, but I'm in all in favor of limiting changes like this. > I have worked on Atomic::inc/dec in a follow on RFE that I am currently running through testing. > >> What is the distinction between FetchAndAdd and AddAndFetch? Does one assume that the value is in a register and is based on the underlying platform implementation? Can you put a comment in atomic.hpp why one vs the other? These platform inconsistencies are really painful since nobody can't test all the platforms. I don't need to see another version of this change, the rest looks ok to me. > The distinction is whether the platform specialization returns the value before or after the add, i.e., whether whether the returned fetched value corresponds to the old or new value, as indicated by the corresponding name. This is a standard convention used by e.g. GCC intrinsics. Oh, I see.? Since nothing generally uses the return value, the inconsistency doesn't matter? > > Unfortunately I have already pushed the change as David and Andrew said I was good to go. I am sorry about that. I will add a short comment in a subsequent inc/dec patch for you. Okay. Coleen > Thanks for the review. > > Thanks, > /Erik > >> Thanks, >> Coleen >> >> >>> On 8/20/17 2:16 AM, Kim Barrett wrote: >>> Please review this change to Atomic::add, making it a function >>> template with a per-platform underlying implementation. >>> >>> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >>> templates", with similar goals and taking a similar approach. >>> >>> This change deprecates add_ptr. Followup changes will convert >>> existing uses of cmpxchg_ptr and eventually remove it. Followup >>> changes will also update uses of cmpxchg that can be simplified >>> because of the generalized API. Only changes to usage that were >>> required by the new implementation have been made so far. >>> >>> The add function calls private Atomic::AddImpl, to select among >>> several cases, based on the argument types. Each case performs some >>> checking and possibly conversion to reach a standard form of the >>> arguments (or fail and report a compile time error), which are then >>> passed to private Atomic::PlatformAdd. >>> >>> Only safe conversions of the first (add_value) argument are made by >>> the AddImpl layer. add_value must be integral, and is never narrowed. >>> dest's value type must be either integral or a pointer type. When >>> both are integral, they must be of the same signedness. If smaller, >>> add_value will be promited to the same size as dest's value type. >>> >>> The PlatformAdd class is provided by each platform, and performs >>> additional case analysis to generate the appropriate code for the >>> platform. Most PlatformAdd implementations use one of two helper base >>> classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide >>> common parts of the implementation in terms of a support function >>> provided by the derived PlatformAdd, accessed using CRTP. >>> >>> This change involves modifications to all of the existing platform >>> implementations of Atomic::add. I've updated all of the platforms, >>> but only tested those supported by Oracle. I'll need help from the >>> various platform maintainers to check and test my changes. >>> >>> Changes to files can be categorized as follows: >>> >>> [No new metaprogramming tools!] >>> >>> Change add to a template: >>> atomic.hpp >>> >>> Oracle-supported platforms: >>> atomic_bsd_x86.hpp - 64bit only >>> atomic_linux_arm.hpp >>> atomic_linux_x86.hpp >>> atomic_solaris_sparc.hpp >>> solaris_sparc.il >>> atomic_solaris_x86.hpp >>> atomic_windows_x86 >>> >>> Non-Oracle platform changes: >>> atomic_aix_ppc.hpp >>> atomic_bsd_x86.hpp - 32bit >>> atomic_bsd_zero.hpp >>> atomic_linux_aarch.hpp >>> atomic_linux_ppc.hpp >>> atomic_linux_s390.hpp >>> atomic_linux_sparc.hpp >>> atomic_linux_zero.hpp >>> >>> Usage changes required by API change: >>> g1CardLiveData.cpp >>> g1ConcurrentMark.cpp >>> g1HotCardCache.cpp >>> g1HotCardCache.hpp >>> g1RemSet.cpp >>> symbol.cpp >>> mallocTracker.hpp >>> >>> A few specific items: >>> >>> - atomic_linux_arm.hpp >>> >>> Neither add variant has "cc" in the clobbers list, even though the >>> condition codes are modified. That seems like a pre-existing bug. >>> >>> - atomic_linux_sparc.hpp >>> >>> Neither add variant has "cc" in the clobbers list, even though the >>> condition codes are modified. That seems like a pre-existing bug. >>> >>> The 32-bit add was using intptr_t as the rv type. Probably a harmless >>> copy-paste mistake. Now using template parameter type. >>> >>> Uses hard-coded machine registers and assumes the inline-asm >>> processing assigns the values to the corresponding machine registers, >>> even though the given constraints are just generic register requests. >>> I don't understand how this can work. >>> >>> - atomic_solaris_sparc.hpp >>> >>> Atomic::add was implemented using asm code in solaris_sparc.il. I was >>> going to change it to use gcc-style inline-asm, but the linux_sparc >>> version wasn't helpful this time (unlike for cmpxchg) (see above). >>> Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much >>> simpler code, and should be no less efficient, assuming the compiler >>> does it's job. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8186476 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >>> >>> Testing: >>> Ad hoc hotspot nightly test. >>> >>> From glaubitz at physik.fu-berlin.de Mon Aug 28 19:53:42 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 21:53:42 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> Message-ID: On 08/28/2017 08:50 PM, John Paul Adrian Glaubitz wrote: > /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: error: there are no arguments to ?STATIC_CAST? that depend on a > template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] > STATIC_CAST(4 == sizeof(I)); > ^~~~~~~~~~~ Odd. STATIC_CAST() doesn't seem to be defined anywhere in the source code and from the context, it rather looks like STATIC_ASSERT() was meant here rather than STATIC_CAST(), wasn't it? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From daniel.daugherty at oracle.com Mon Aug 28 20:09:50 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Aug 2017 14:09:50 -0600 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> Message-ID: <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> Changeset: 9cf835fba355 Author:??? mdoerr Date:????? 2017-08-24 14:56 +0200 URL: http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/9cf835fba355 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg with templates Reviewed-by: goetz ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp Same bug, different platform? Dan On 8/28/17 1:53 PM, John Paul Adrian Glaubitz wrote: > On 08/28/2017 08:50 PM, John Paul Adrian Glaubitz wrote: >> /home/glaubitz/openjdk/hs/hotspot/src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp:65:3: error: there are no arguments to ?STATIC_CAST? that depend on a >> template parameter, so a declaration of ?STATIC_CAST? must be available [-fpermissive] >> STATIC_CAST(4 == sizeof(I)); >> ^~~~~~~~~~~ > Odd. STATIC_CAST() doesn't seem to be defined anywhere in the source code and > from the context, it rather looks like STATIC_ASSERT() was meant here rather > than STATIC_CAST(), wasn't it? > > Adrian > From glaubitz at physik.fu-berlin.de Mon Aug 28 20:12:32 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 22:12:32 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> Message-ID: <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> On 08/28/2017 10:09 PM, Daniel D. Daugherty wrote: > 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg with templates > Reviewed-by: goetz > > Same bug, different platform? Not quite. This regression came after 8186476, not 8186166. But the mistake seems to be the same: s/STATIC_CAST/STATIC_ASSERT/g'. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Mon Aug 28 20:19:01 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 22:19:01 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> Message-ID: <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> On 08/28/2017 10:12 PM, John Paul Adrian Glaubitz wrote: > On 08/28/2017 10:09 PM, Daniel D. Daugherty wrote: >> 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg with templates >> Reviewed-by: goetz >> >> Same bug, different platform? > > Not quite. This regression came after 8186476, not 8186166. FWIW, 8186476 most likely broke the PPC AIX build again, look at [1] and search for STATIC_CAST. It's been again used instead of STATIC_ASSERT. Adrian > [1] http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/d78407f77172 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Mon Aug 28 20:31:21 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 22:31:21 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> Message-ID: <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> On 08/28/2017 10:19 PM, John Paul Adrian Glaubitz wrote: > On 08/28/2017 10:12 PM, John Paul Adrian Glaubitz wrote: >> On 08/28/2017 10:09 PM, Daniel D. Daugherty wrote: >>> 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg with templates >>> Reviewed-by: goetz >>> >>> Same bug, different platform? >> >> Not quite. This regression came after 8186476, not 8186166. > > FWIW, 8186476 most likely broke the PPC AIX build again, look at [1] and search > for STATIC_CAST. It's been again used instead of STATIC_ASSERT. Most likely, the whole patch needs to have s/STATIC_CAST/STATIC_ASSERT/g'. Also, on Linux SPARC, the "template<>" is missing for Atomic::PlatformAdd<8>::add_and_fetch. How shall we fix this? Shall I open bugs for every platform? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Mon Aug 28 20:32:27 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 28 Aug 2017 20:32:27 +0000 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> Message-ID: On Mon 28. Aug 2017 at 22:19, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/28/2017 10:12 PM, John Paul Adrian Glaubitz wrote: > > On 08/28/2017 10:09 PM, Daniel D. Daugherty wrote: > >> 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg > with templates > >> Reviewed-by: goetz > >> > >> Same bug, different platform? > > > > Not quite. This regression came after 8186476, not 8186166. > > FWIW, 8186476 most likely broke the PPC AIX build again, look at [1] and > search > for STATIC_CAST. It's been again used instead of STATIC_ASSERT. > > Adrian > > > [1] http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/d78407f77172 > Thanks for noticing, we will fix it tomorrow for AIX. ..Thomas > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From thomas.stuefe at gmail.com Mon Aug 28 20:38:01 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 28 Aug 2017 20:38:01 +0000 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> Message-ID: On Mon 28. Aug 2017 at 22:31, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/28/2017 10:19 PM, John Paul Adrian Glaubitz wrote: > > On 08/28/2017 10:12 PM, John Paul Adrian Glaubitz wrote: > >> On 08/28/2017 10:09 PM, Daniel D. Daugherty wrote: > >>> 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg > with templates > >>> Reviewed-by: goetz > >>> > >>> Same bug, different platform? > >> > >> Not quite. This regression came after 8186476, not 8186166. > > > > FWIW, 8186476 most likely broke the PPC AIX build again, look at [1] and > search > > for STATIC_CAST. It's been again used instead of STATIC_ASSERT. > > Most likely, the whole patch needs to have s/STATIC_CAST/STATIC_ASSERT/g'. > > Also, on Linux SPARC, the "template<>" is missing for > Atomic::PlatformAdd<8>::add_and_fetch. > > How shall we fix this? Shall I open bugs for every platform? > I would do one single bug for all platforms. ..Thomas > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From glaubitz at physik.fu-berlin.de Mon Aug 28 20:43:42 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 22:43:42 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> Message-ID: <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> On 08/28/2017 10:38 PM, Thomas St?fe wrote: > How shall we fix this? Shall I open bugs for every platform? > > I would do one single bug for all platforms. Ok, I filed 8186855 [1]. I'll whip up a patch shortly. Adrian > [1] https://bugs.openjdk.java.net/browse/JDK-8186855 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Mon Aug 28 21:18:55 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 28 Aug 2017 23:18:55 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> Message-ID: <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> On 08/28/2017 10:43 PM, John Paul Adrian Glaubitz wrote: > On 08/28/2017 10:38 PM, Thomas St?fe wrote: >> How shall we fix this? Shall I open bugs for every platform? >> >> I would do one single bug for all platforms. > > Ok, I filed 8186855 [1]. > > I'll whip up a patch shortly. Hmm, so I just did build tests on Linux/s390x and there is more stuff broken. The overall necessary changes might be more involved and might need attention from IBM people, so we should probably split things up. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From Derek.White at cavium.com Mon Aug 28 22:07:39 2017 From: Derek.White at cavium.com (White, Derek) Date: Mon, 28 Aug 2017 22:07:39 +0000 Subject: 8186248 - Allow more flexibility in selecting Heap % of available RAM In-Reply-To: <4978B55B-5E2E-4A68-B108-AE70971853A8@oracle.com> References: <4978B55B-5E2E-4A68-B108-AE70971853A8@oracle.com> Message-ID: Looks good! > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Bob Vandette > Sent: Monday, August 28, 2017 10:41 AM > To: hotspot-dev Source Developers > Subject: RFR: 8186248 - Allow more flexibility in selecting Heap % of available > RAM > > Please review this updated webrev with changes suggested by David Holmes. > > Webrev: > > http://cr.openjdk.java.net/~bobv/8186248/webrev.02 > > > This CR https://bugs.openjdk.java.net/browse/JDK-8186248 > deprecates the > MaxRAMFraction, MinRAMFraction and InitialRAMFraction VM options in > JDK 10 and adds three new options which allow the user the ability to select > a percentage of available memory to be used for the Java Heap. > > MaxRAMPercentage > MinRAMPercentage > InitialRMAPercentage > > Please let me know if anyone objects to the flag name and deprecation as I > am in the process of filing a CCC (CSR). > > Thanks, > Bob. > > > > > From glaubitz at physik.fu-berlin.de Mon Aug 28 22:24:10 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 00:24:10 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> Message-ID: <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> After regexp-replacing STATIC_CAST with STATIC_ASSERT, I'm confronted with: /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = int; D = int; long unsigned int byte_size = 4]': /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from 'D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = int; D = int; Derived = Atomic::PlatformAdd<4>]' /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: required from 'D Atomic::AddImpl::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type>::operator()(I, volatile D*) const [with I = int; D = int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type = void]' /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: required from 'static D Atomic::add(I, volatile D*) [with I = int; D = int]' /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:405:73: required from here /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:122:6: error: insufficient contextual information to determine type ); ^ /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:137:6: error: insufficient contextual information to determine type ); ^ /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = long unsigned int; D = long unsigned int; long unsigned int byte_size = 8]': /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from 'D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = long unsigned int; D = long unsigned int; Derived = Atomic::PlatformAdd<8>]' /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: required from 'D Atomic::AddImpl::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type>::operator()(I, volatile D*) const [with I = long unsigned int; D = long unsigned int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type = void]' /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: required from 'static D Atomic::add(I, volatile D*) [with I = long unsigned int; D = long unsigned int]' /home/glaubitz/hs/hotspot/src/share/vm/services/mallocTracker.hpp:58:29: required from here /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: error: insufficient contextual information to determine type ); ^ /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:188:6: error: insufficient contextual information to determine type ); ^ lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/hs/build/linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' failed make[3]: *** [/home/glaubitz/hs/build/linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o] Error 1 make[3]: Leaving directory '/home/glaubitz/hs/hotspot/make' make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed make[2]: *** [hotspot-server-libs] Error 2 make[2]: *** Waiting for unfinished jobs.... /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main /home/glaubitz/hs/jdk/make/data/charsetmapping /home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext hkscs '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetmapping/HKSCS.java' Generating jdk.charsets euctw /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the.charsetmapping-hkscs' /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main /home/glaubitz/hs/jdk/make/data/charsetmapping /home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext euctw '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetmapping/EUC_TW.java' Generating support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the.charsetmapping-euctw' /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main '/home/glaubitz/hs/jdk/make/data/charsetmapping/sjis0213.map' '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat' sjis0213 I have been looking at the code for over half an hour but I couldn't find the actual problem. Anyone got an idea? -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From poonam.bajaj at oracle.com Tue Aug 29 01:37:58 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Mon, 28 Aug 2017 18:37:58 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core C4 In-Reply-To: <3f0b16ad-2eeb-4326-bfd2-f94e17422527@default> References: <4768675b-cf31-4351-902a-51ab0a4bd5c7@default> <2d0ca8d5-139e-3b8b-a96d-6daa04d94c7b@oracle.com> <3f0b16ad-2eeb-4326-bfd2-f94e17422527@default> Message-ID: Hello Muthu, The changes look good. One minor nit - please remove '.' at the end of the comment at line 144 in vm_version_sparc.cpp: 144 // Use BIS instruction for TLAB allocation prefetch. 145 // on Niagara plus processors other than those based on CoreS4 Also, please update the copyright year for both the files. Thanks, Poonam > -----Original Message----- > From: Muthusamy Chinnathambi > Sent: Tuesday, July 25, 2017 2:14 AM > To: Vladimir Kozlov; hotspot-dev at openjdk.java.net > Subject: RE: [8u] RFR for backport of JDK-8158012: Use SW prefetch > instructions instead of BIS for allocation prefetches on SPARC Core C4 > > May I please get a second review for this change. > > Thanks, > Muthusamy C > > -----Original Message----- > From: Vladimir Kozlov > Sent: Monday, July 24, 2017 9:52 PM > To: Muthusamy Chinnathambi ; > hotspot-dev at openjdk.java.net > Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch > instructions instead of BIS for allocation prefetches on SPARC Core C4 > > This looks good. > > Thanks, > Vladimir > > On 7/23/17 11:56 PM, Muthusamy Chinnathambi wrote: > > Hi Vladimir, > > > > Thanks for the review. > > Please find the updated webrev at > > http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.01/ > > > > Regards, > > Muthusamy C > > > > -----Original Message----- > > From: Vladimir Kozlov > > Sent: Friday, July 21, 2017 4:38 AM > > To: Muthusamy Chinnathambi ; > > hotspot-dev at openjdk.java.net > > Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch > > instructions instead of BIS for allocation prefetches on SPARC Core > C4 > > > > The indent for next comment line in vm_version_sparc.cpp is off: > > > > // Use BIS instr > > > > And AllocatePrefetchStyle set to 3 should be outside new check > (should > > be set for both cases). In JDK 9 there is following code which set it > > for AllocatePrefetchInstr == 1 which JDK8 does not have: > > > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/eebdc7acebd4/src/cpu > > /sparc/vm/vm_version_sparc.cpp#l126 > > > > thanks, > > Vladimir > > > > On 7/20/17 12:24 AM, Muthusamy Chinnathambi wrote: > >> Hi, > >> > >> Please review the backport of bug: "JDK-8158012: Use SW prefetch > >> instructions instead of BIS for allocation prefetches on SPARC Core > >> C4" to jdk8u-dev > >> > >> Please note that this is not a clean backport due to conflict in > comments and slight re-order of code. > >> > >> > >> Webrev: > http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.00/ > >> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8158012 > >> Original patch pushed to jdk9: > >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/eebdc7acebd4 > >> > >> Test: Ran jprt and jtreg. > >> > >> Regards, > >> Muthusamy C > >> From david.holmes at oracle.com Tue Aug 29 06:04:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 16:04:04 +1000 Subject: [8u] RFR for backport of JDK-8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core C4 In-Reply-To: References: <4768675b-cf31-4351-902a-51ab0a4bd5c7@default> <2d0ca8d5-139e-3b8b-a96d-6daa04d94c7b@oracle.com> <3f0b16ad-2eeb-4326-bfd2-f94e17422527@default> Message-ID: On 29/08/2017 11:37 AM, Poonam Parhar wrote: > Hello Muthu, > > The changes look good. One minor nit - please remove '.' at the end of the comment at line 144 in vm_version_sparc.cpp: > > 144 // Use BIS instruction for TLAB allocation prefetch. > 145 // on Niagara plus processors other than those based on CoreS4 I think it should be moved to the end of L145, as we now have a longer sentence. Cheers, David > Also, please update the copyright year for both the files. > > Thanks, > Poonam > >> -----Original Message----- >> From: Muthusamy Chinnathambi >> Sent: Tuesday, July 25, 2017 2:14 AM >> To: Vladimir Kozlov; hotspot-dev at openjdk.java.net >> Subject: RE: [8u] RFR for backport of JDK-8158012: Use SW prefetch >> instructions instead of BIS for allocation prefetches on SPARC Core C4 >> >> May I please get a second review for this change. >> >> Thanks, >> Muthusamy C >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Monday, July 24, 2017 9:52 PM >> To: Muthusamy Chinnathambi ; >> hotspot-dev at openjdk.java.net >> Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch >> instructions instead of BIS for allocation prefetches on SPARC Core C4 >> >> This looks good. >> >> Thanks, >> Vladimir >> >> On 7/23/17 11:56 PM, Muthusamy Chinnathambi wrote: >>> Hi Vladimir, >>> >>> Thanks for the review. >>> Please find the updated webrev at >>> http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.01/ >>> >>> Regards, >>> Muthusamy C >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Friday, July 21, 2017 4:38 AM >>> To: Muthusamy Chinnathambi ; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch >>> instructions instead of BIS for allocation prefetches on SPARC Core >> C4 >>> >>> The indent for next comment line in vm_version_sparc.cpp is off: >>> >>> // Use BIS instr >>> >>> And AllocatePrefetchStyle set to 3 should be outside new check >> (should >>> be set for both cases). In JDK 9 there is following code which set it >>> for AllocatePrefetchInstr == 1 which JDK8 does not have: >>> >>> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/eebdc7acebd4/src/cpu >>> /sparc/vm/vm_version_sparc.cpp#l126 >>> >>> thanks, >>> Vladimir >>> >>> On 7/20/17 12:24 AM, Muthusamy Chinnathambi wrote: >>>> Hi, >>>> >>>> Please review the backport of bug: "JDK-8158012: Use SW prefetch >>>> instructions instead of BIS for allocation prefetches on SPARC Core >>>> C4" to jdk8u-dev >>>> >>>> Please note that this is not a clean backport due to conflict in >> comments and slight re-order of code. >>>> >>>> >>>> Webrev: >> http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.00/ >>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8158012 >>>> Original patch pushed to jdk9: >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/eebdc7acebd4 >>>> >>>> Test: Ran jprt and jtreg. >>>> >>>> Regards, >>>> Muthusamy C >>>> From thomas.stuefe at gmail.com Tue Aug 29 06:21:38 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 08:21:38 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> Message-ID: Yes, all our nightly ppc and s390 builds are broken. I'm looking at AIX right now. ..Thomas On Tue, Aug 29, 2017 at 12:24 AM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > After regexp-replacing STATIC_CAST with STATIC_ASSERT, I'm confronted with: > > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: > In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, > volatile D*) > const [with I = int; D = int; long unsigned int byte_size = 4]': > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: > required from 'D Atomic::AddAndFetch::operator()(I, volatile > D*) const [with I = > int; D = int; Derived = Atomic::PlatformAdd<4>]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: > required from 'D Atomic::AddImpl::value > && > IsIntegral::value) && (sizeof (I) <= sizeof (D))) && > (IsSigned::value == IsSigned::value))>::type>::operator()(I, > volatile D*) const [with I = int; D = > int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) > && (sizeof (I) <= sizeof (D))) && (IsSigned::value == > IsSigned::value))>::type = > void]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: > required from 'static D Atomic::add(I, volatile D*) [with I = int; D = > int]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:405:73: > required from here > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:122:6: > error: insufficient contextual information to determine type > ); > ^ > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:137:6: > error: insufficient contextual information to determine type > ); > ^ > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: > In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, > volatile D*) > const [with I = long unsigned int; D = long unsigned int; long unsigned > int byte_size = 8]': > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: > required from 'D Atomic::AddAndFetch::operator()(I, volatile > D*) const [with I = > long unsigned int; D = long unsigned int; Derived = > Atomic::PlatformAdd<8>]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: > required from 'D Atomic::AddImpl::value > && > IsIntegral::value) && (sizeof (I) <= sizeof (D))) && > (IsSigned::value == IsSigned::value))>::type>::operator()(I, > volatile D*) const [with I = long > unsigned int; D = long unsigned int; typename EnableIf<(((IsIntegral::value > && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && > (IsSigned::value == > IsSigned::value))>::type = void]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: > required from 'static D Atomic::add(I, volatile D*) [with I = long > unsigned int; D = long > unsigned int]' > /home/glaubitz/hs/hotspot/src/share/vm/services/mallocTracker.hpp:58:29: > required from here > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: > error: insufficient contextual information to determine type > ); > ^ > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:188:6: > error: insufficient contextual information to determine type > ); > ^ > lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/hs/build/ > linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' > failed > make[3]: *** [/home/glaubitz/hs/build/linux-s390x-normal-server- > release/hotspot/variant-server/libjvm/objs/abstractCompiler.o] Error 1 > make[3]: Leaving directory '/home/glaubitz/hs/hotspot/make' > make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed > make[2]: *** [hotspot-server-libs] Error 2 > make[2]: *** Waiting for unfinished jobs.... > /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M > -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes > build.tools.charsetmapping.Main > /home/glaubitz/hs/jdk/make/data/charsetmapping > /home/glaubitz/hs/build/linux-s390x-normal-server-release/ > support/gensrc/jdk.charsets/sun/nio/cs/ext hkscs > '/home/glaubitz/hs/jdk/make/src/classes/build/tools/ > charsetmapping/HKSCS.java' > Generating jdk.charsets euctw > /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server- > release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the. > charsetmapping-hkscs' > /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M > -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes > build.tools.charsetmapping.Main > /home/glaubitz/hs/jdk/make/data/charsetmapping > /home/glaubitz/hs/build/linux-s390x-normal-server-release/ > support/gensrc/jdk.charsets/sun/nio/cs/ext euctw > '/home/glaubitz/hs/jdk/make/src/classes/build/tools/ > charsetmapping/EUC_TW.java' > Generating support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat > /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server- > release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the. > charsetmapping-euctw' > /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M > -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes > build.tools.charsetmapping.Main > '/home/glaubitz/hs/jdk/make/data/charsetmapping/sjis0213.map' > '/home/glaubitz/hs/build/linux-s390x-normal-server- > release/support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat' sjis0213 > > I have been looking at the code for over half an hour but I couldn't find > the actual problem. > > Anyone got an idea? > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From david.holmes at oracle.com Tue Aug 29 06:36:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 16:36:12 +1000 Subject: RFR(M) 8186834:Expanding old area without full GC in parallel GC In-Reply-To: References: Message-ID: Hi Michihiro, Please note that adding a new flag like this requires a Compatibility and Specification Review request (CSR) [1] to be created and approved before any code changes can be pushed. From the bug click "More" and select "Create CSR". Thanks, David [1] https://wiki.openjdk.java.net/display/csr/Main On 29/08/2017 1:20 AM, Michihiro Horie wrote: > > Dear all, > > Would you please review the following change? > bug: https://bugs.openjdk.java.net/browse/JDK-8186834 > webrev: http://cr.openjdk.java.net/~mhorie/8186834/webrev.00/ > > In parallel GC, old area is expanded only after a full GC occurs. > I am wondering if we could give an option to expand old area without full > GC. So, I added an option > UseAdaptiveGenerationSizePolicyBeforeMajorCollection. > > Following is a simple micro benchmark I used to see the benefit of this > change. > As a result, pause time of full GC reduced by 30%. Full GC count reduced by > 54%. > Elapsed time reduced by 7%. > > import java.util.HashMap; > import java.util.Map; > public class HeapExpandTest { > static Map map = new HashMap<>(); > public static void main(String[] args) throws Exception { > long start = System.currentTimeMillis(); > for (int i = 0; i < 2200; ++i) { > map.put(i, new byte[1024*1024]); // 1MB > } > System.out.println("elapsed= " + (System.currentTimeMillis() - start)); > } > } > > JVM options: -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy > -XX:ParallelGCThreads=8 -Xms64m -Xmx3g > -XX:+UseAdaptiveGenerationSizePolicyBeforeMajorCollection > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > From patric.hedlin at oracle.com Tue Aug 29 06:41:20 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 29 Aug 2017 08:41:20 +0200 Subject: JDK10/RFR(M): 8182279: Add HW feature detection support for SPARC Core C5 (on Solaris). Message-ID: <2c3adfc4-3bcb-3cf8-fc18-216602849dcb@oracle.com> Dear all, I would like to ask for help to review the following change/update: Issue: https://bugs.openjdk.java.net/browse/JDK-8182279 Webrev: http://cr.openjdk.java.net/~phedlin/tr8182279/ Note 1. SPARC Core C5 disclosure has been approved for reviewing on this list(s). Note 2. SPARC Core C5 and M8 servers are currently not available to regular testing. Note 3. Core C5 was previously named Core S5. 8182279: Add HW feature detection support for SPARC Core C5 (on Solaris). Updating SPARC feature/capability detection to include support for the SPARC Core C5. Caveat: This update will introduce some redundancies into the code base, features and definitions currently not used, addressed by subsequent bug or feature updates/patches. Fujitsu HW is treated very conservatively. Testing: Mostly tested on JDK9 (jtreg/RBT/hotspot/tier0-comp), RBT on non-M8 only. Testing on JDK10 (jtreg/RBT/hotspot/precheckin-comp), RBT on non-M8 only. Best regards, Patric From david.holmes at oracle.com Tue Aug 29 06:51:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 16:51:34 +1000 Subject: RFR: 8186248 - Allow more flexibility in selecting Heap % of available RAM In-Reply-To: <4978B55B-5E2E-4A68-B108-AE70971853A8@oracle.com> References: <4978B55B-5E2E-4A68-B108-AE70971853A8@oracle.com> Message-ID: <0b7bda4d-6f60-f115-e1a5-8174e1426bfa@oracle.com> Hi Bob, This looks good - thanks. Just to clarify the behaviour - the new percentage flag wins if both new and old flags are specified (and of course use of the old flag gets a deprecation warning). I'm a little surprised these flags don't need special treatment in TestOptionsWithRanges - but if the fraction forms didn't need it then the percentage forms should not either. Once the CSR request is updated and approved this can be finalized. Thanks, David On 29/08/2017 12:40 AM, Bob Vandette wrote: > Please review this updated webrev with changes suggested by David Holmes. > > Webrev: > > http://cr.openjdk.java.net/~bobv/8186248/webrev.02 > > This CR https://bugs.openjdk.java.net/browse/JDK-8186248 deprecates > the MaxRAMFraction, MinRAMFraction and InitialRAMFraction VM options > in JDK 10 and adds three new options which allow the user the ability to > select a percentage of available memory to be used for the Java Heap. > > MaxRAMPercentage > MinRAMPercentage > InitialRMAPercentage > > Please let me know if anyone objects to the flag name and deprecation as I am in > the process of filing a CCC (CSR). > > Thanks, > Bob. > > > > > > From erik.osterlund at oracle.com Tue Aug 29 07:01:48 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Aug 2017 09:01:48 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> Message-ID: <59A5115C.7020100@oracle.com> Hi, First of all, sorry for pushing the change that broke these platforms. I did not spot these problems in Kim's patch, and could not test the code on these platforms. As for what is wrong here, it looks like s/STATIC_CAST/STATIC_ASSERT/g is one of the problems as you noticed, and the local variables have seemingly also been renamed. In particular, it looks like the inline assembly references the variable "inc" that looks like it has been renamed "add_value". Sorry about the inconvenience. Thanks, /Erik On 2017-08-29 00:24, John Paul Adrian Glaubitz wrote: > After regexp-replacing STATIC_CAST with STATIC_ASSERT, I'm confronted with: > > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) > const [with I = int; D = int; long unsigned int byte_size = 4]': > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from 'D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = > int; D = int; Derived = Atomic::PlatformAdd<4>]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: required from 'D Atomic::AddImpl::value && > IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type>::operator()(I, volatile D*) const [with I = int; D = > int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type = > void]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: required from 'static D Atomic::add(I, volatile D*) [with I = int; D = int]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:405:73: required from here > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:122:6: error: insufficient contextual information to determine type > ); > ^ > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:137:6: error: insufficient contextual information to determine type > ); > ^ > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) > const [with I = long unsigned int; D = long unsigned int; long unsigned int byte_size = 8]': > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from 'D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = > long unsigned int; D = long unsigned int; Derived = Atomic::PlatformAdd<8>]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: required from 'D Atomic::AddImpl::value && > IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type>::operator()(I, volatile D*) const [with I = long > unsigned int; D = long unsigned int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == > IsSigned::value))>::type = void]' > /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: required from 'static D Atomic::add(I, volatile D*) [with I = long unsigned int; D = long > unsigned int]' > /home/glaubitz/hs/hotspot/src/share/vm/services/mallocTracker.hpp:58:29: required from here > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: error: insufficient contextual information to determine type > ); > ^ > /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:188:6: error: insufficient contextual information to determine type > ); > ^ > lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/hs/build/linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' failed > make[3]: *** [/home/glaubitz/hs/build/linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o] Error 1 > make[3]: Leaving directory '/home/glaubitz/hs/hotspot/make' > make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed > make[2]: *** [hotspot-server-libs] Error 2 > make[2]: *** Waiting for unfinished jobs.... > /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main > /home/glaubitz/hs/jdk/make/data/charsetmapping /home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext hkscs > '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetmapping/HKSCS.java' > Generating jdk.charsets euctw > /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the.charsetmapping-hkscs' > /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main > /home/glaubitz/hs/jdk/make/data/charsetmapping /home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext euctw > '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetmapping/EUC_TW.java' > Generating support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat > /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the.charsetmapping-euctw' > /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp > /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main > '/home/glaubitz/hs/jdk/make/data/charsetmapping/sjis0213.map' > '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat' sjis0213 > > I have been looking at the code for over half an hour but I couldn't find the actual problem. > > Anyone got an idea? > From david.holmes at oracle.com Tue Aug 29 07:05:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 17:05:30 +1000 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <5d8c1375-12af-ef75-acd6-264599416c68@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> <5d8c1375-12af-ef75-acd6-264599416c68@oracle.com> Message-ID: <5acc86d3-2b6c-1011-5a5e-758b75e56e51@oracle.com> On 29/08/2017 5:33 AM, coleen.phillimore at oracle.com wrote: > On 8/28/17 12:33 PM, Erik Osterlund wrote: >>> On 28 Aug 2017, at 14:46, coleen.phillimore at oracle.com wrote: >>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html >>> >>> Can Atomic::{inc,dec}(volatile jshort* dest) use u2 instead?? And the >>> jshort version of Atomic::add use u2 instead of jshort??? Can it be >>> done as a follow on change, since I thought we were trying to remove >>> the jtypes from this runtime internal code? >> Yes. I will file an RFE for that. > > Thanks! >> >>> I was confused, I thought you'd do Atomic::inc() in this change, but >>> I'm in all in favor of limiting changes like this. >> I have worked on Atomic::inc/dec in a follow on RFE that I am >> currently running through testing. >> >>> What is the distinction between FetchAndAdd and AddAndFetch??? Does >>> one assume that the value is in a register and is based on the >>> underlying platform implementation?? Can you put a comment in >>> atomic.hpp why one vs the other?? These platform inconsistencies are >>> really painful since nobody can't test all the platforms.?? I don't >>> need to see another version of this change, the rest looks ok to me. >> The distinction is whether the platform specialization returns the >> value before or after the add, i.e., whether whether the returned >> fetched value corresponds to the old or new value, as indicated by the >> corresponding name. This is a standard convention used by e.g. GCC >> intrinsics. > > Oh, I see.? Since nothing generally uses the return value, the > inconsistency doesn't matter? The Atomic::add API specifies that the returned value is the updated value. I must confess I'm now a bit confused here as it seems to me that PlatformAdd should always be a "AddAndFetch" to ensure the correct semantics. ??? David ----- >> >> Unfortunately I have already pushed the change as David and Andrew >> said I was good to go. I am sorry about that. I will add a short >> comment in a subsequent inc/dec patch for you. > > Okay. > Coleen > >> Thanks for the review. >> >> Thanks, >> /Erik >> >>> Thanks, >>> Coleen >>> >>> >>>> On 8/20/17 2:16 AM, Kim Barrett wrote: >>>> Please review this change to Atomic::add, making it a function >>>> template with a per-platform underlying implementation. >>>> >>>> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >>>> templates", with similar goals and taking a similar approach. >>>> >>>> This change deprecates add_ptr.? Followup changes will convert >>>> existing uses of cmpxchg_ptr and eventually remove it.? Followup >>>> changes will also update uses of cmpxchg that can be simplified >>>> because of the generalized API.? Only changes to usage that were >>>> required by the new implementation have been made so far. >>>> >>>> The add function calls private Atomic::AddImpl, to select among >>>> several cases, based on the argument types.? Each case performs some >>>> checking and possibly conversion to reach a standard form of the >>>> arguments (or fail and report a compile time error), which are then >>>> passed to private Atomic::PlatformAdd. >>>> >>>> Only safe conversions of the first (add_value) argument are made by >>>> the AddImpl layer.? add_value must be integral, and is never narrowed. >>>> dest's value type must be either integral or a pointer type.? When >>>> both are integral, they must be of the same signedness.? If smaller, >>>> add_value will be promited to the same size as dest's value type. >>>> >>>> The PlatformAdd class is provided by each platform, and performs >>>> additional case analysis to generate the appropriate code for the >>>> platform.? Most PlatformAdd implementations use one of two helper base >>>> classes, Atomic::FetchAndAdd and Atomic::AddAndFetch.? These provide >>>> common parts of the implementation in terms of a support function >>>> provided by the derived PlatformAdd, accessed using CRTP. >>>> >>>> This change involves modifications to all of the existing platform >>>> implementations of Atomic::add.? I've updated all of the platforms, >>>> but only tested those supported by Oracle.? I'll need help from the >>>> various platform maintainers to check and test my changes. >>>> >>>> Changes to files can be categorized as follows: >>>> >>>> [No new metaprogramming tools!] >>>> >>>> Change add to a template: >>>> atomic.hpp >>>> >>>> Oracle-supported platforms: >>>> atomic_bsd_x86.hpp - 64bit only >>>> atomic_linux_arm.hpp >>>> atomic_linux_x86.hpp >>>> atomic_solaris_sparc.hpp >>>> solaris_sparc.il >>>> atomic_solaris_x86.hpp >>>> atomic_windows_x86 >>>> >>>> Non-Oracle platform changes: >>>> atomic_aix_ppc.hpp >>>> atomic_bsd_x86.hpp - 32bit >>>> atomic_bsd_zero.hpp >>>> atomic_linux_aarch.hpp >>>> atomic_linux_ppc.hpp >>>> atomic_linux_s390.hpp >>>> atomic_linux_sparc.hpp >>>> atomic_linux_zero.hpp >>>> >>>> Usage changes required by API change: >>>> g1CardLiveData.cpp >>>> g1ConcurrentMark.cpp >>>> g1HotCardCache.cpp >>>> g1HotCardCache.hpp >>>> g1RemSet.cpp >>>> symbol.cpp >>>> mallocTracker.hpp >>>> >>>> A few specific items: >>>> >>>> - atomic_linux_arm.hpp >>>> >>>> Neither add variant has "cc" in the clobbers list, even though the >>>> condition codes are modified.? That seems like a pre-existing bug. >>>> >>>> - atomic_linux_sparc.hpp >>>> >>>> Neither add variant has "cc" in the clobbers list, even though the >>>> condition codes are modified.? That seems like a pre-existing bug. >>>> >>>> The 32-bit add was using intptr_t as the rv type.? Probably a harmless >>>> copy-paste mistake.? Now using template parameter type. >>>> >>>> Uses hard-coded machine registers and assumes the inline-asm >>>> processing assigns the values to the corresponding machine registers, >>>> even though the given constraints are just generic register requests. >>>> I don't understand how this can work. >>>> >>>> - atomic_solaris_sparc.hpp >>>> >>>> Atomic::add was implemented using asm code in solaris_sparc.il.? I was >>>> going to change it to use gcc-style inline-asm, but the linux_sparc >>>> version wasn't helpful this time (unlike for cmpxchg) (see above). >>>> Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much >>>> simpler code, and should be no less efficient, assuming the compiler >>>> does it's job. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8186476 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >>>> >>>> Testing: >>>> Ad hoc hotspot nightly test. >>>> >>>> > From erik.osterlund at oracle.com Tue Aug 29 07:13:12 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Aug 2017 09:13:12 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <5acc86d3-2b6c-1011-5a5e-758b75e56e51@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> <5d8c1375-12af-ef75-acd6-264599416c68@oracle.com> <5acc86d3-2b6c-1011-5a5e-758b75e56e51@oracle.com> Message-ID: <59A51408.7090204@oracle.com> Hi Coleen, David, On 2017-08-29 09:05, David Holmes wrote: > On 29/08/2017 5:33 AM, coleen.phillimore at oracle.com wrote: >> On 8/28/17 12:33 PM, Erik Osterlund wrote: >>>> On 28 Aug 2017, at 14:46, coleen.phillimore at oracle.com wrote: >>>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/src/share/vm/runtime/atomic.hpp.udiff.html >>>> >>>> Can Atomic::{inc,dec}(volatile jshort* dest) use u2 instead? And >>>> the jshort version of Atomic::add use u2 instead of jshort? Can >>>> it be done as a follow on change, since I thought we were trying to >>>> remove the jtypes from this runtime internal code? >>> Yes. I will file an RFE for that. >> >> Thanks! >>> >>>> I was confused, I thought you'd do Atomic::inc() in this change, >>>> but I'm in all in favor of limiting changes like this. >>> I have worked on Atomic::inc/dec in a follow on RFE that I am >>> currently running through testing. >>> >>>> What is the distinction between FetchAndAdd and AddAndFetch? Does >>>> one assume that the value is in a register and is based on the >>>> underlying platform implementation? Can you put a comment in >>>> atomic.hpp why one vs the other? These platform inconsistencies >>>> are really painful since nobody can't test all the platforms. I >>>> don't need to see another version of this change, the rest looks ok >>>> to me. >>> The distinction is whether the platform specialization returns the >>> value before or after the add, i.e., whether whether the returned >>> fetched value corresponds to the old or new value, as indicated by >>> the corresponding name. This is a standard convention used by e.g. >>> GCC intrinsics. >> >> Oh, I see. Since nothing generally uses the return value, the >> inconsistency doesn't matter? > > The Atomic::add API specifies that the returned value is the updated > value. I must confess I'm now a bit confused here as it seems to me > that PlatformAdd should always be a "AddAndFetch" to ensure the > correct semantics. ??? Yes, you are right that the public API uses add_and_fetch semantics. But AddAndFetch and FetchAndAdd are only adapters to the platform layer for internal use. The platform layer has a specialization that is specified as either FetchAndAdd or AddAndFetch, which is converted to the intended add_and_fetch semantics expected by the public API in Atomic::FetchAndAdd::operator() and Atomic::AddAndFetch::operator() correspondingly. So it is only a helper for the platform layer. Thanks, /Erik > David > ----- > > >>> >>> Unfortunately I have already pushed the change as David and Andrew >>> said I was good to go. I am sorry about that. I will add a short >>> comment in a subsequent inc/dec patch for you. >> >> Okay. >> Coleen >> >>> Thanks for the review. >>> >>> Thanks, >>> /Erik >>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>>> On 8/20/17 2:16 AM, Kim Barrett wrote: >>>>> Please review this change to Atomic::add, making it a function >>>>> template with a per-platform underlying implementation. >>>>> >>>>> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >>>>> templates", with similar goals and taking a similar approach. >>>>> >>>>> This change deprecates add_ptr. Followup changes will convert >>>>> existing uses of cmpxchg_ptr and eventually remove it. Followup >>>>> changes will also update uses of cmpxchg that can be simplified >>>>> because of the generalized API. Only changes to usage that were >>>>> required by the new implementation have been made so far. >>>>> >>>>> The add function calls private Atomic::AddImpl, to select among >>>>> several cases, based on the argument types. Each case performs some >>>>> checking and possibly conversion to reach a standard form of the >>>>> arguments (or fail and report a compile time error), which are then >>>>> passed to private Atomic::PlatformAdd. >>>>> >>>>> Only safe conversions of the first (add_value) argument are made by >>>>> the AddImpl layer. add_value must be integral, and is never >>>>> narrowed. >>>>> dest's value type must be either integral or a pointer type. When >>>>> both are integral, they must be of the same signedness. If smaller, >>>>> add_value will be promited to the same size as dest's value type. >>>>> >>>>> The PlatformAdd class is provided by each platform, and performs >>>>> additional case analysis to generate the appropriate code for the >>>>> platform. Most PlatformAdd implementations use one of two helper >>>>> base >>>>> classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide >>>>> common parts of the implementation in terms of a support function >>>>> provided by the derived PlatformAdd, accessed using CRTP. >>>>> >>>>> This change involves modifications to all of the existing platform >>>>> implementations of Atomic::add. I've updated all of the platforms, >>>>> but only tested those supported by Oracle. I'll need help from the >>>>> various platform maintainers to check and test my changes. >>>>> >>>>> Changes to files can be categorized as follows: >>>>> >>>>> [No new metaprogramming tools!] >>>>> >>>>> Change add to a template: >>>>> atomic.hpp >>>>> >>>>> Oracle-supported platforms: >>>>> atomic_bsd_x86.hpp - 64bit only >>>>> atomic_linux_arm.hpp >>>>> atomic_linux_x86.hpp >>>>> atomic_solaris_sparc.hpp >>>>> solaris_sparc.il >>>>> atomic_solaris_x86.hpp >>>>> atomic_windows_x86 >>>>> >>>>> Non-Oracle platform changes: >>>>> atomic_aix_ppc.hpp >>>>> atomic_bsd_x86.hpp - 32bit >>>>> atomic_bsd_zero.hpp >>>>> atomic_linux_aarch.hpp >>>>> atomic_linux_ppc.hpp >>>>> atomic_linux_s390.hpp >>>>> atomic_linux_sparc.hpp >>>>> atomic_linux_zero.hpp >>>>> >>>>> Usage changes required by API change: >>>>> g1CardLiveData.cpp >>>>> g1ConcurrentMark.cpp >>>>> g1HotCardCache.cpp >>>>> g1HotCardCache.hpp >>>>> g1RemSet.cpp >>>>> symbol.cpp >>>>> mallocTracker.hpp >>>>> >>>>> A few specific items: >>>>> >>>>> - atomic_linux_arm.hpp >>>>> >>>>> Neither add variant has "cc" in the clobbers list, even though the >>>>> condition codes are modified. That seems like a pre-existing bug. >>>>> >>>>> - atomic_linux_sparc.hpp >>>>> >>>>> Neither add variant has "cc" in the clobbers list, even though the >>>>> condition codes are modified. That seems like a pre-existing bug. >>>>> >>>>> The 32-bit add was using intptr_t as the rv type. Probably a harmless >>>>> copy-paste mistake. Now using template parameter type. >>>>> >>>>> Uses hard-coded machine registers and assumes the inline-asm >>>>> processing assigns the values to the corresponding machine registers, >>>>> even though the given constraints are just generic register requests. >>>>> I don't understand how this can work. >>>>> >>>>> - atomic_solaris_sparc.hpp >>>>> >>>>> Atomic::add was implemented using asm code in solaris_sparc.il. I >>>>> was >>>>> going to change it to use gcc-style inline-asm, but the linux_sparc >>>>> version wasn't helpful this time (unlike for cmpxchg) (see above). >>>>> Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much >>>>> simpler code, and should be no less efficient, assuming the compiler >>>>> does it's job. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8186476 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >>>>> >>>>> Testing: >>>>> Ad hoc hotspot nightly test. >>>>> >>>>> >> From david.holmes at oracle.com Tue Aug 29 07:20:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 17:20:41 +1000 Subject: JDK10/RFR(M): 8182279: Add HW feature detection support for SPARC Core C5 (on Solaris). In-Reply-To: <2c3adfc4-3bcb-3cf8-fc18-216602849dcb@oracle.com> References: <2c3adfc4-3bcb-3cf8-fc18-216602849dcb@oracle.com> Message-ID: Hi Patric, On 29/08/2017 4:41 PM, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8182279 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8182279/ I can't comment on the accuracy of the added features of course but structurally etc these changes seem okay. Only odd thing I noticed in vm_version_solaris_sparc.cpp: 410 #ifndef AV2_SPARC_SPARC6 411 #define AV2_SPARC_SPARC6 0x00000200 // REVB*, FPSLL*, RDENTROPY, LDM* and STM* 412 #endif 413 #ifndef AV2_SPARC_DICTUNP 414 #define AV2_SPARC_DICTUNP 0x00002000 // Dictionary unpack instruction why did you leave a gap in the sequence? Thanks, David ----- > Note 1. SPARC Core C5 disclosure has been approved for reviewing on this > list(s). > Note 2. SPARC Core C5 and M8 servers are currently not available to > regular testing. > Note 3. Core C5 was previously named Core S5. > > > 8182279: Add HW feature detection support for SPARC Core C5 (on Solaris). > > ??? Updating SPARC feature/capability detection to include support for > the SPARC Core C5. > > > Caveat: > > ??? This update will introduce some redundancies into the code base, > features and definitions > ??? currently not used, addressed by subsequent bug or feature > updates/patches. Fujitsu HW is > ??? treated very conservatively. > > > Testing: > > ??? Mostly tested on JDK9 (jtreg/RBT/hotspot/tier0-comp), RBT on non-M8 > only. > ??? Testing on JDK10 (jtreg/RBT/hotspot/precheckin-comp), RBT on non-M8 > only. > > > Best regards, > Patric > > From david.holmes at oracle.com Tue Aug 29 07:28:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 17:28:46 +1000 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <59A51408.7090204@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> <5d8c1375-12af-ef75-acd6-264599416c68@oracle.com> <5acc86d3-2b6c-1011-5a5e-758b75e56e51@oracle.com> <59A51408.7090204@oracle.com> Message-ID: <8a256c95-0eae-041b-567d-4e011e18cd86@oracle.com> On 29/08/2017 5:13 PM, Erik ?sterlund wrote: > Hi Coleen, David, > > On 2017-08-29 09:05, David Holmes wrote: >> On 29/08/2017 5:33 AM, coleen.phillimore at oracle.com wrote: >>> On 8/28/17 12:33 PM, Erik Osterlund wrote: >>>>> What is the distinction between FetchAndAdd and AddAndFetch??? Does >>>>> one assume that the value is in a register and is based on the >>>>> underlying platform implementation?? Can you put a comment in >>>>> atomic.hpp why one vs the other?? These platform inconsistencies >>>>> are really painful since nobody can't test all the platforms.?? I >>>>> don't need to see another version of this change, the rest looks ok >>>>> to me. >>>> The distinction is whether the platform specialization returns the >>>> value before or after the add, i.e., whether whether the returned >>>> fetched value corresponds to the old or new value, as indicated by >>>> the corresponding name. This is a standard convention used by e.g. >>>> GCC intrinsics. >>> >>> Oh, I see.? Since nothing generally uses the return value, the >>> inconsistency doesn't matter? >> >> The Atomic::add API specifies that the returned value is the updated >> value. I must confess I'm now a bit confused here as it seems to me >> that PlatformAdd should always be a "AddAndFetch" to ensure the >> correct semantics. ??? > > Yes, you are right that the public API uses add_and_fetch semantics. But > AddAndFetch and FetchAndAdd are only adapters to the platform layer for > internal use. The platform layer has a specialization that is specified > as either FetchAndAdd or AddAndFetch, which is converted to the intended > add_and_fetch semantics expected by the public API in > Atomic::FetchAndAdd::operator() and > Atomic::AddAndFetch::operator() correspondingly. So it is only > a helper for the platform layer. Okay I'm completely lost here - sorry. I'm expecting to see a PlatformAdd that has the semantics of Atomic::add - which does an add_and_fetch. So this looks fine: src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp template struct Atomic::PlatformAdd : Atomic::AddAndFetch > { template D add_and_fetch(I add_value, D volatile* dest) const; }; while this looks wrong: src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp template struct Atomic::PlatformAdd : Atomic::FetchAndAdd > { template D fetch_and_add(I add_value, D volatile* dest) const; }; ??? Thanks, David > Thanks, > /Erik > >> David >> ----- >> >> >>>> >>>> Unfortunately I have already pushed the change as David and Andrew >>>> said I was good to go. I am sorry about that. I will add a short >>>> comment in a subsequent inc/dec patch for you. >>> >>> Okay. >>> Coleen >>> >>>> Thanks for the review. >>>> >>>> Thanks, >>>> /Erik >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>>> On 8/20/17 2:16 AM, Kim Barrett wrote: >>>>>> Please review this change to Atomic::add, making it a function >>>>>> template with a per-platform underlying implementation. >>>>>> >>>>>> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >>>>>> templates", with similar goals and taking a similar approach. >>>>>> >>>>>> This change deprecates add_ptr.? Followup changes will convert >>>>>> existing uses of cmpxchg_ptr and eventually remove it. Followup >>>>>> changes will also update uses of cmpxchg that can be simplified >>>>>> because of the generalized API.? Only changes to usage that were >>>>>> required by the new implementation have been made so far. >>>>>> >>>>>> The add function calls private Atomic::AddImpl, to select among >>>>>> several cases, based on the argument types.? Each case performs some >>>>>> checking and possibly conversion to reach a standard form of the >>>>>> arguments (or fail and report a compile time error), which are then >>>>>> passed to private Atomic::PlatformAdd. >>>>>> >>>>>> Only safe conversions of the first (add_value) argument are made by >>>>>> the AddImpl layer.? add_value must be integral, and is never >>>>>> narrowed. >>>>>> dest's value type must be either integral or a pointer type.? When >>>>>> both are integral, they must be of the same signedness. If smaller, >>>>>> add_value will be promited to the same size as dest's value type. >>>>>> >>>>>> The PlatformAdd class is provided by each platform, and performs >>>>>> additional case analysis to generate the appropriate code for the >>>>>> platform.? Most PlatformAdd implementations use one of two helper >>>>>> base >>>>>> classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide >>>>>> common parts of the implementation in terms of a support function >>>>>> provided by the derived PlatformAdd, accessed using CRTP. >>>>>> >>>>>> This change involves modifications to all of the existing platform >>>>>> implementations of Atomic::add.? I've updated all of the platforms, >>>>>> but only tested those supported by Oracle.? I'll need help from the >>>>>> various platform maintainers to check and test my changes. >>>>>> >>>>>> Changes to files can be categorized as follows: >>>>>> >>>>>> [No new metaprogramming tools!] >>>>>> >>>>>> Change add to a template: >>>>>> atomic.hpp >>>>>> >>>>>> Oracle-supported platforms: >>>>>> atomic_bsd_x86.hpp - 64bit only >>>>>> atomic_linux_arm.hpp >>>>>> atomic_linux_x86.hpp >>>>>> atomic_solaris_sparc.hpp >>>>>> solaris_sparc.il >>>>>> atomic_solaris_x86.hpp >>>>>> atomic_windows_x86 >>>>>> >>>>>> Non-Oracle platform changes: >>>>>> atomic_aix_ppc.hpp >>>>>> atomic_bsd_x86.hpp - 32bit >>>>>> atomic_bsd_zero.hpp >>>>>> atomic_linux_aarch.hpp >>>>>> atomic_linux_ppc.hpp >>>>>> atomic_linux_s390.hpp >>>>>> atomic_linux_sparc.hpp >>>>>> atomic_linux_zero.hpp >>>>>> >>>>>> Usage changes required by API change: >>>>>> g1CardLiveData.cpp >>>>>> g1ConcurrentMark.cpp >>>>>> g1HotCardCache.cpp >>>>>> g1HotCardCache.hpp >>>>>> g1RemSet.cpp >>>>>> symbol.cpp >>>>>> mallocTracker.hpp >>>>>> >>>>>> A few specific items: >>>>>> >>>>>> - atomic_linux_arm.hpp >>>>>> >>>>>> Neither add variant has "cc" in the clobbers list, even though the >>>>>> condition codes are modified.? That seems like a pre-existing bug. >>>>>> >>>>>> - atomic_linux_sparc.hpp >>>>>> >>>>>> Neither add variant has "cc" in the clobbers list, even though the >>>>>> condition codes are modified.? That seems like a pre-existing bug. >>>>>> >>>>>> The 32-bit add was using intptr_t as the rv type. Probably a harmless >>>>>> copy-paste mistake.? Now using template parameter type. >>>>>> >>>>>> Uses hard-coded machine registers and assumes the inline-asm >>>>>> processing assigns the values to the corresponding machine registers, >>>>>> even though the given constraints are just generic register requests. >>>>>> I don't understand how this can work. >>>>>> >>>>>> - atomic_solaris_sparc.hpp >>>>>> >>>>>> Atomic::add was implemented using asm code in solaris_sparc.il.? I >>>>>> was >>>>>> going to change it to use gcc-style inline-asm, but the linux_sparc >>>>>> version wasn't helpful this time (unlike for cmpxchg) (see above). >>>>>> Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much >>>>>> simpler code, and should be no less efficient, assuming the compiler >>>>>> does it's job. >>>>>> >>>>>> CR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8186476 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >>>>>> >>>>>> Testing: >>>>>> Ad hoc hotspot nightly test. >>>>>> >>>>>> >>> > From muthusamy.chinnathambi at oracle.com Tue Aug 29 07:54:42 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Tue, 29 Aug 2017 00:54:42 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core C4 In-Reply-To: References: <4768675b-cf31-4351-902a-51ab0a4bd5c7@default> <2d0ca8d5-139e-3b8b-a96d-6daa04d94c7b@oracle.com> <3f0b16ad-2eeb-4326-bfd2-f94e17422527@default> Message-ID: <1a7170b8-063f-43b8-9187-4b37b80a4376@default> Thanks David and Poonam for the review. Please find the updated webrev with copyright and punctuation changes at http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.02/ Regards, Muthusamy C -----Original Message----- From: David Holmes Sent: Tuesday, August 29, 2017 11:34 AM To: Poonam Parhar ; Muthusamy Chinnathambi ; Vladimir Kozlov ; hotspot-dev at openjdk.java.net Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core C4 On 29/08/2017 11:37 AM, Poonam Parhar wrote: > Hello Muthu, > > The changes look good. One minor nit - please remove '.' at the end of the comment at line 144 in vm_version_sparc.cpp: > > 144 // Use BIS instruction for TLAB allocation prefetch. > 145 // on Niagara plus processors other than those based on CoreS4 I think it should be moved to the end of L145, as we now have a longer sentence. Cheers, David > Also, please update the copyright year for both the files. > > Thanks, > Poonam > >> -----Original Message----- >> From: Muthusamy Chinnathambi >> Sent: Tuesday, July 25, 2017 2:14 AM >> To: Vladimir Kozlov; hotspot-dev at openjdk.java.net >> Subject: RE: [8u] RFR for backport of JDK-8158012: Use SW prefetch >> instructions instead of BIS for allocation prefetches on SPARC Core C4 >> >> May I please get a second review for this change. >> >> Thanks, >> Muthusamy C >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Monday, July 24, 2017 9:52 PM >> To: Muthusamy Chinnathambi ; >> hotspot-dev at openjdk.java.net >> Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch >> instructions instead of BIS for allocation prefetches on SPARC Core C4 >> >> This looks good. >> >> Thanks, >> Vladimir >> >> On 7/23/17 11:56 PM, Muthusamy Chinnathambi wrote: >>> Hi Vladimir, >>> >>> Thanks for the review. >>> Please find the updated webrev at >>> http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.01/ >>> >>> Regards, >>> Muthusamy C >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Friday, July 21, 2017 4:38 AM >>> To: Muthusamy Chinnathambi ; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch >>> instructions instead of BIS for allocation prefetches on SPARC Core >> C4 >>> >>> The indent for next comment line in vm_version_sparc.cpp is off: >>> >>> // Use BIS instr >>> >>> And AllocatePrefetchStyle set to 3 should be outside new check >> (should >>> be set for both cases). In JDK 9 there is following code which set it >>> for AllocatePrefetchInstr == 1 which JDK8 does not have: >>> >>> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/eebdc7acebd4/src/cpu >>> /sparc/vm/vm_version_sparc.cpp#l126 >>> >>> thanks, >>> Vladimir >>> >>> On 7/20/17 12:24 AM, Muthusamy Chinnathambi wrote: >>>> Hi, >>>> >>>> Please review the backport of bug: "JDK-8158012: Use SW prefetch >>>> instructions instead of BIS for allocation prefetches on SPARC Core >>>> C4" to jdk8u-dev >>>> >>>> Please note that this is not a clean backport due to conflict in >> comments and slight re-order of code. >>>> >>>> >>>> Webrev: >> http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.00/ >>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8158012 >>>> Original patch pushed to jdk9: >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/eebdc7acebd4 >>>> >>>> Test: Ran jprt and jtreg. >>>> >>>> Regards, >>>> Muthusamy C >>>> From david.holmes at oracle.com Tue Aug 29 07:58:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 17:58:05 +1000 Subject: [8u] RFR for backport of JDK-8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core C4 In-Reply-To: <1a7170b8-063f-43b8-9187-4b37b80a4376@default> References: <4768675b-cf31-4351-902a-51ab0a4bd5c7@default> <2d0ca8d5-139e-3b8b-a96d-6daa04d94c7b@oracle.com> <3f0b16ad-2eeb-4326-bfd2-f94e17422527@default> <1a7170b8-063f-43b8-9187-4b37b80a4376@default> Message-ID: <4d733dea-2916-8e88-c888-a15bb0f697af@oracle.com> On 29/08/2017 5:54 PM, Muthusamy Chinnathambi wrote: > Thanks David and Poonam for the review. > > Please find the updated webrev with copyright and punctuation changes at http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.02/ Please add a period after "style 3" at: vm_version_sparc.cpp: ! // On CoreS4 processors use prefetch instruction ! // to avoid partial RAW issue, also use prefetch style 3 Thanks. No need for updated webrev. David > Regards, > Muthusamy C > > -----Original Message----- > From: David Holmes > Sent: Tuesday, August 29, 2017 11:34 AM > To: Poonam Parhar ; Muthusamy Chinnathambi ; Vladimir Kozlov ; hotspot-dev at openjdk.java.net > Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core C4 > > On 29/08/2017 11:37 AM, Poonam Parhar wrote: >> Hello Muthu, >> >> The changes look good. One minor nit - please remove '.' at the end of the comment at line 144 in vm_version_sparc.cpp: >> >> 144 // Use BIS instruction for TLAB allocation prefetch. >> 145 // on Niagara plus processors other than those based on CoreS4 > > I think it should be moved to the end of L145, as we now have a longer > sentence. > > Cheers, > David > >> Also, please update the copyright year for both the files. >> >> Thanks, >> Poonam >> >>> -----Original Message----- >>> From: Muthusamy Chinnathambi >>> Sent: Tuesday, July 25, 2017 2:14 AM >>> To: Vladimir Kozlov; hotspot-dev at openjdk.java.net >>> Subject: RE: [8u] RFR for backport of JDK-8158012: Use SW prefetch >>> instructions instead of BIS for allocation prefetches on SPARC Core C4 >>> >>> May I please get a second review for this change. >>> >>> Thanks, >>> Muthusamy C >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Monday, July 24, 2017 9:52 PM >>> To: Muthusamy Chinnathambi ; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch >>> instructions instead of BIS for allocation prefetches on SPARC Core C4 >>> >>> This looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/23/17 11:56 PM, Muthusamy Chinnathambi wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for the review. >>>> Please find the updated webrev at >>>> http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.01/ >>>> >>>> Regards, >>>> Muthusamy C >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> Sent: Friday, July 21, 2017 4:38 AM >>>> To: Muthusamy Chinnathambi ; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: [8u] RFR for backport of JDK-8158012: Use SW prefetch >>>> instructions instead of BIS for allocation prefetches on SPARC Core >>> C4 >>>> >>>> The indent for next comment line in vm_version_sparc.cpp is off: >>>> >>>> // Use BIS instr >>>> >>>> And AllocatePrefetchStyle set to 3 should be outside new check >>> (should >>>> be set for both cases). In JDK 9 there is following code which set it >>>> for AllocatePrefetchInstr == 1 which JDK8 does not have: >>>> >>>> >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/eebdc7acebd4/src/cpu >>>> /sparc/vm/vm_version_sparc.cpp#l126 >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 7/20/17 12:24 AM, Muthusamy Chinnathambi wrote: >>>>> Hi, >>>>> >>>>> Please review the backport of bug: "JDK-8158012: Use SW prefetch >>>>> instructions instead of BIS for allocation prefetches on SPARC Core >>>>> C4" to jdk8u-dev >>>>> >>>>> Please note that this is not a clean backport due to conflict in >>> comments and slight re-order of code. >>>>> >>>>> >>>>> Webrev: >>> http://cr.openjdk.java.net/~shshahma/Muthu/8158012/webrev.00/ >>>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8158012 >>>>> Original patch pushed to jdk9: >>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/eebdc7acebd4 >>>>> >>>>> Test: Ran jprt and jtreg. >>>>> >>>>> Regards, >>>>> Muthusamy C >>>>> From erik.osterlund at oracle.com Tue Aug 29 08:00:44 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 29 Aug 2017 10:00:44 +0200 Subject: RFR: 8186476: Generalize Atomic::add with templates In-Reply-To: <8a256c95-0eae-041b-567d-4e011e18cd86@oracle.com> References: <61346762-D2F9-4B13-934F-280606E3E0F7@oracle.com> <7D634FE6-6E0C-4216-B37E-102E4C932DEE@oracle.com> <5d8c1375-12af-ef75-acd6-264599416c68@oracle.com> <5acc86d3-2b6c-1011-5a5e-758b75e56e51@oracle.com> <59A51408.7090204@oracle.com> <8a256c95-0eae-041b-567d-4e011e18cd86@oracle.com> Message-ID: <59A51F2C.9050508@oracle.com> Hi David, On 2017-08-29 09:28, David Holmes wrote: > > > On 29/08/2017 5:13 PM, Erik ?sterlund wrote: >> Hi Coleen, David, >> >> On 2017-08-29 09:05, David Holmes wrote: >>> On 29/08/2017 5:33 AM, coleen.phillimore at oracle.com wrote: >>>> On 8/28/17 12:33 PM, Erik Osterlund wrote: >>>>>> What is the distinction between FetchAndAdd and AddAndFetch? >>>>>> Does one assume that the value is in a register and is based on >>>>>> the underlying platform implementation? Can you put a comment in >>>>>> atomic.hpp why one vs the other? These platform inconsistencies >>>>>> are really painful since nobody can't test all the platforms. I >>>>>> don't need to see another version of this change, the rest looks >>>>>> ok to me. >>>>> The distinction is whether the platform specialization returns the >>>>> value before or after the add, i.e., whether whether the returned >>>>> fetched value corresponds to the old or new value, as indicated by >>>>> the corresponding name. This is a standard convention used by e.g. >>>>> GCC intrinsics. >>>> >>>> Oh, I see. Since nothing generally uses the return value, the >>>> inconsistency doesn't matter? >>> >>> The Atomic::add API specifies that the returned value is the updated >>> value. I must confess I'm now a bit confused here as it seems to me >>> that PlatformAdd should always be a "AddAndFetch" to ensure the >>> correct semantics. ??? >> >> Yes, you are right that the public API uses add_and_fetch semantics. >> But AddAndFetch and FetchAndAdd are only adapters to the platform >> layer for internal use. The platform layer has a specialization that >> is specified as either FetchAndAdd or AddAndFetch, which is converted >> to the intended add_and_fetch semantics expected by the public API in >> Atomic::FetchAndAdd::operator() and >> Atomic::AddAndFetch::operator() correspondingly. So it is >> only a helper for the platform layer. > > Okay I'm completely lost here - sorry. I'm expecting to see a > PlatformAdd that has the semantics of Atomic::add - which does an > add_and_fetch. So this looks fine: > > src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp > > template > struct Atomic::PlatformAdd > : Atomic::AddAndFetch > > { > template > D add_and_fetch(I add_value, D volatile* dest) const; > }; > > while this looks wrong: > > src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp > > template > struct Atomic::PlatformAdd > : Atomic::FetchAndAdd > > { > template > D fetch_and_add(I add_value, D volatile* dest) const; > }; > > ??? I will try to describe how this work in a hopefully understandable way. 1) Atomic::add calls AddImpl::operator(). 2) AddImpl calls PlatformAdd::operator() that could override to do anything, but for convenience typically uses either the FetchAndAdd or AddAndFetch helper (depending on whether your platform implementation is best expressed as a fetch_and_add or add_and_fetch) 3.a) FetchAndAdd::operator() (in shared code) calls PlatformAdd::fetch_and_add() (in the platform layer) and adds the addend to turn it into add_and_fetch semantics as expected by the public API. 3.b) AddAndFetch::operator() (in shared code) calls PlatformAdd::add_and_fetch() (in the platform layer) without adding the addend as the semantics in the platform layer already matches the expected semantics of the public API. The key point here is that the platform specified fetch_and_add or add_and_fetch member functions are not called directly from AddImpl::operator(), they are called through a helper e.g. FetchAndAdd::operator() that performs the necessary translation of the platform provided intrinsic (in either of the two conventions) to the expected shared API semantics. And of course, the shared API has the exact same semantics on all platforms. Hope this makes sense. Thanks, /Erik > > Thanks, > David > >> Thanks, >> /Erik >> >>> David >>> ----- >>> >>> >>>>> >>>>> Unfortunately I have already pushed the change as David and Andrew >>>>> said I was good to go. I am sorry about that. I will add a short >>>>> comment in a subsequent inc/dec patch for you. >>>> >>>> Okay. >>>> Coleen >>>> >>>>> Thanks for the review. >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>>> On 8/20/17 2:16 AM, Kim Barrett wrote: >>>>>>> Please review this change to Atomic::add, making it a function >>>>>>> template with a per-platform underlying implementation. >>>>>>> >>>>>>> This change is similar to 8186166: "Generalize Atomic::cmpxchg with >>>>>>> templates", with similar goals and taking a similar approach. >>>>>>> >>>>>>> This change deprecates add_ptr. Followup changes will convert >>>>>>> existing uses of cmpxchg_ptr and eventually remove it. Followup >>>>>>> changes will also update uses of cmpxchg that can be simplified >>>>>>> because of the generalized API. Only changes to usage that were >>>>>>> required by the new implementation have been made so far. >>>>>>> >>>>>>> The add function calls private Atomic::AddImpl, to select among >>>>>>> several cases, based on the argument types. Each case performs >>>>>>> some >>>>>>> checking and possibly conversion to reach a standard form of the >>>>>>> arguments (or fail and report a compile time error), which are then >>>>>>> passed to private Atomic::PlatformAdd. >>>>>>> >>>>>>> Only safe conversions of the first (add_value) argument are made by >>>>>>> the AddImpl layer. add_value must be integral, and is never >>>>>>> narrowed. >>>>>>> dest's value type must be either integral or a pointer type. When >>>>>>> both are integral, they must be of the same signedness. If smaller, >>>>>>> add_value will be promited to the same size as dest's value type. >>>>>>> >>>>>>> The PlatformAdd class is provided by each platform, and performs >>>>>>> additional case analysis to generate the appropriate code for the >>>>>>> platform. Most PlatformAdd implementations use one of two >>>>>>> helper base >>>>>>> classes, Atomic::FetchAndAdd and Atomic::AddAndFetch. These provide >>>>>>> common parts of the implementation in terms of a support function >>>>>>> provided by the derived PlatformAdd, accessed using CRTP. >>>>>>> >>>>>>> This change involves modifications to all of the existing platform >>>>>>> implementations of Atomic::add. I've updated all of the platforms, >>>>>>> but only tested those supported by Oracle. I'll need help from the >>>>>>> various platform maintainers to check and test my changes. >>>>>>> >>>>>>> Changes to files can be categorized as follows: >>>>>>> >>>>>>> [No new metaprogramming tools!] >>>>>>> >>>>>>> Change add to a template: >>>>>>> atomic.hpp >>>>>>> >>>>>>> Oracle-supported platforms: >>>>>>> atomic_bsd_x86.hpp - 64bit only >>>>>>> atomic_linux_arm.hpp >>>>>>> atomic_linux_x86.hpp >>>>>>> atomic_solaris_sparc.hpp >>>>>>> solaris_sparc.il >>>>>>> atomic_solaris_x86.hpp >>>>>>> atomic_windows_x86 >>>>>>> >>>>>>> Non-Oracle platform changes: >>>>>>> atomic_aix_ppc.hpp >>>>>>> atomic_bsd_x86.hpp - 32bit >>>>>>> atomic_bsd_zero.hpp >>>>>>> atomic_linux_aarch.hpp >>>>>>> atomic_linux_ppc.hpp >>>>>>> atomic_linux_s390.hpp >>>>>>> atomic_linux_sparc.hpp >>>>>>> atomic_linux_zero.hpp >>>>>>> >>>>>>> Usage changes required by API change: >>>>>>> g1CardLiveData.cpp >>>>>>> g1ConcurrentMark.cpp >>>>>>> g1HotCardCache.cpp >>>>>>> g1HotCardCache.hpp >>>>>>> g1RemSet.cpp >>>>>>> symbol.cpp >>>>>>> mallocTracker.hpp >>>>>>> >>>>>>> A few specific items: >>>>>>> >>>>>>> - atomic_linux_arm.hpp >>>>>>> >>>>>>> Neither add variant has "cc" in the clobbers list, even though the >>>>>>> condition codes are modified. That seems like a pre-existing bug. >>>>>>> >>>>>>> - atomic_linux_sparc.hpp >>>>>>> >>>>>>> Neither add variant has "cc" in the clobbers list, even though the >>>>>>> condition codes are modified. That seems like a pre-existing bug. >>>>>>> >>>>>>> The 32-bit add was using intptr_t as the rv type. Probably a >>>>>>> harmless >>>>>>> copy-paste mistake. Now using template parameter type. >>>>>>> >>>>>>> Uses hard-coded machine registers and assumes the inline-asm >>>>>>> processing assigns the values to the corresponding machine >>>>>>> registers, >>>>>>> even though the given constraints are just generic register >>>>>>> requests. >>>>>>> I don't understand how this can work. >>>>>>> >>>>>>> - atomic_solaris_sparc.hpp >>>>>>> >>>>>>> Atomic::add was implemented using asm code in solaris_sparc.il. >>>>>>> I was >>>>>>> going to change it to use gcc-style inline-asm, but the linux_sparc >>>>>>> version wasn't helpful this time (unlike for cmpxchg) (see above). >>>>>>> Instead, I wrote the CAS-loop in C++, using Atomic::cmpxchg; much >>>>>>> simpler code, and should be no less efficient, assuming the >>>>>>> compiler >>>>>>> does it's job. >>>>>>> >>>>>>> CR: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186476 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~kbarrett/8186476/hotspot.00/ >>>>>>> >>>>>>> Testing: >>>>>>> Ad hoc hotspot nightly test. >>>>>>> >>>>>>> >>>> >> From thomas.stuefe at gmail.com Tue Aug 29 08:25:36 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 10:25:36 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <59A5115C.7020100@oracle.com> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> Message-ID: Hi, I got the libjvm.so to build on linuxppc64 and linuxs390 (AIX builds are still running), see attached patch. @Eric: thank you for the hints! The replacements for STATIC_CAST are trivial. The cause for the second error (renamed function parameter) is too, but for the life of me I could not have guessed it from the error messages I get: priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of ?D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = long int; D = long int; long unsigned int byte_size = 8ul]?: /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from ?D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = long int; D = long int; Derived = Atomic::PlatformAdd<8ul>]? /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:367:49: required from ?D Atomic::AddImpl::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value)) >::type>::operator()(I, volatile D*) const [with I = long int; D = long int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type = void]? /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:353:41: required from ?static D Atomic::add(I, volatile D*) [with I = long int; D = long int]? /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:93:31: required from here /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: error: insufficient contextual information to determine type ); ^ I think this is a bit of a step backward in terms of maintainability. While I see the increased ease of use for the callers of Atomic, I am not yet convinced introducing template metaprogramming is worth the time it takes to figure out these kind of errors. We do not have many developers versed in C++ metaprogramming (which, as a skill set, does not necessarily intersect with low level system programming). Sorry for the rant, and thanks again for the help in figuring this out! Kind Regards, Thomas On Tue, Aug 29, 2017 at 9:01 AM, Erik ?sterlund wrote: > Hi, > > First of all, sorry for pushing the change that broke these platforms. I > did not spot these problems in Kim's patch, and could not test the code on > these platforms. > As for what is wrong here, it looks like s/STATIC_CAST/STATIC_ASSERT/g is > one of the problems as you noticed, and the local variables have seemingly > also been renamed. In particular, it looks like the inline assembly > references the variable "inc" that looks like it has been renamed > "add_value". > > Sorry about the inconvenience. > > Thanks, > /Erik > > > On 2017-08-29 00:24, John Paul Adrian Glaubitz wrote: > >> After regexp-replacing STATIC_CAST with STATIC_ASSERT, I'm confronted >> with: >> >> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: >> In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, >> volatile D*) >> const [with I = int; D = int; long unsigned int byte_size = 4]': >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: >> required from 'D Atomic::AddAndFetch::operator()(I, volatile >> D*) const [with I = >> int; D = int; Derived = Atomic::PlatformAdd<4>]' >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: >> required from 'D Atomic::AddImpl> EnableIf<(((IsIntegral::value && >> IsIntegral::value) && (sizeof (I) <= sizeof (D))) && >> (IsSigned::value == IsSigned::value))>::type>::operator()(I, >> volatile D*) const [with I = int; D = >> int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) >> && (sizeof (I) <= sizeof (D))) && (IsSigned::value == >> IsSigned::value))>::type = >> void]' >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: >> required from 'static D Atomic::add(I, volatile D*) [with I = int; D = >> int]' >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:405:73: >> required from here >> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:122:6: >> error: insufficient contextual information to determine type >> ); >> ^ >> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:137:6: >> error: insufficient contextual information to determine type >> ); >> ^ >> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: >> In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, >> volatile D*) >> const [with I = long unsigned int; D = long unsigned int; long unsigned >> int byte_size = 8]': >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: >> required from 'D Atomic::AddAndFetch::operator()(I, volatile >> D*) const [with I = >> long unsigned int; D = long unsigned int; Derived = >> Atomic::PlatformAdd<8>]' >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: >> required from 'D Atomic::AddImpl> EnableIf<(((IsIntegral::value && >> IsIntegral::value) && (sizeof (I) <= sizeof (D))) && >> (IsSigned::value == IsSigned::value))>::type>::operator()(I, >> volatile D*) const [with I = long >> unsigned int; D = long unsigned int; typename >> EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) >> <= sizeof (D))) && (IsSigned::value == >> IsSigned::value))>::type = void]' >> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: >> required from 'static D Atomic::add(I, volatile D*) [with I = long >> unsigned int; D = long >> unsigned int]' >> /home/glaubitz/hs/hotspot/src/share/vm/services/mallocTracker.hpp:58:29: >> required from here >> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: >> error: insufficient contextual information to determine type >> ); >> ^ >> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:188:6: >> error: insufficient contextual information to determine type >> ); >> ^ >> lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/hs/build/linux >> -s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' >> failed >> make[3]: *** [/home/glaubitz/hs/build/linux-s390x-normal-server-release/ >> hotspot/variant-server/libjvm/objs/abstractCompiler.o] Error 1 >> make[3]: Leaving directory '/home/glaubitz/hs/hotspot/make' >> make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed >> make[2]: *** [hotspot-server-libs] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M >> -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes >> build.tools.charsetmapping.Main >> /home/glaubitz/hs/jdk/make/data/charsetmapping >> /home/glaubitz/hs/build/linux-s390x-normal-server-release/su >> pport/gensrc/jdk.charsets/sun/nio/cs/ext hkscs >> '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetm >> apping/HKSCS.java' >> Generating jdk.charsets euctw >> /usr/bin/touch '/home/glaubitz/hs/build/linux >> -s390x-normal-server-release/support/gensrc/jdk.charsets/ >> sun/nio/cs/ext/_the.charsetmapping-hkscs' >> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M >> -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes >> build.tools.charsetmapping.Main >> /home/glaubitz/hs/jdk/make/data/charsetmapping >> /home/glaubitz/hs/build/linux-s390x-normal-server-release/su >> pport/gensrc/jdk.charsets/sun/nio/cs/ext euctw >> '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetm >> apping/EUC_TW.java' >> Generating support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat >> /usr/bin/touch '/home/glaubitz/hs/build/linux >> -s390x-normal-server-release/support/gensrc/jdk.charsets/ >> sun/nio/cs/ext/_the.charsetmapping-euctw' >> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M >> -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes >> build.tools.charsetmapping.Main >> '/home/glaubitz/hs/jdk/make/data/charsetmapping/sjis0213.map' >> '/home/glaubitz/hs/build/linux-s390x-normal-server-release/ >> support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat' sjis0213 >> >> I have been looking at the code for over half an hour but I couldn't find >> the actual problem. >> >> Anyone got an idea? >> >> > -------------- next part -------------- diff -r a20f0fa4c426 src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp --- a/src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp Mon Aug 28 23:46:22 2017 +0000 +++ b/src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp Tue Aug 29 10:10:46 2017 +0200 @@ -106,8 +106,8 @@ template<> template inline D Atomic::PlatformAdd<4>::add_and_fetch(I add_value, D volatile* dest) const { - STATIC_CAST(4 == sizeof(I)); - STATIC_CAST(4 == sizeof(D)); + STATIC_ASSERT(4 == sizeof(I)); + STATIC_ASSERT(4 == sizeof(D)); D result; @@ -129,8 +129,8 @@ template<> template inline D Atomic::PlatformAdd<8>::add_and_fetch(I add_value, D volatile* dest) const { - STATIC_CAST(8 == sizeof(I)); - STATIC_CAST(8 == sizeof(D)); + STATIC_ASSERT(8 == sizeof(I)); + STATIC_ASSERT(8 == sizeof(D)); D result; diff -r a20f0fa4c426 src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp --- a/src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp Mon Aug 28 23:46:22 2017 +0000 +++ b/src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp Tue Aug 29 10:10:46 2017 +0200 @@ -104,8 +104,8 @@ template<> template inline D Atomic::PlatformAdd<4>::add_and_fetch(I add_value, D volatile* dest) const { - STATIC_CAST(4 == sizeof(I)); - STATIC_CAST(4 == sizeof(D)); + STATIC_ASSERT(4 == sizeof(I)); + STATIC_ASSERT(4 == sizeof(D)); D result; @@ -127,8 +127,8 @@ template<> template inline D Atomic::PlatformAdd<8>::add_and_fetch(I add_value, D volatile* dest) const { - STATIC_CAST(8 == sizeof(I)); - STATIC_CAST(8 == sizeof(D)); + STATIC_ASSERT(8 == sizeof(I)); + STATIC_ASSERT(8 == sizeof(D)); D result; diff -r a20f0fa4c426 src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp --- a/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Mon Aug 28 23:46:22 2017 +0000 +++ b/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Tue Aug 29 10:10:46 2017 +0200 @@ -92,9 +92,9 @@ template<> template -inline D Atomic::PlatformAdd<4>::add_and_fetch(I add_value, D volatile* dest) const { - STATIC_CAST(4 == sizeof(I)); - STATIC_CAST(4 == sizeof(D)); +inline D Atomic::PlatformAdd<4>::add_and_fetch(I inc, D volatile* dest) const { + STATIC_ASSERT(4 == sizeof(I)); + STATIC_ASSERT(4 == sizeof(D)); D old, upd; @@ -143,9 +143,9 @@ template<> template -inline D Atomic::PlatformAdd<8>::add_and_fetch(I add_value, D volatile* dest) const { - STATIC_CAST(8 == sizeof(I)); - STATIC_CAST(8 == sizeof(D)); +inline D Atomic::PlatformAdd<8>::add_and_fetch(I inc, D volatile* dest) const { + STATIC_ASSERT(8 == sizeof(I)); + STATIC_ASSERT(8 == sizeof(D)); D old, upd; From glaubitz at physik.fu-berlin.de Tue Aug 29 08:46:11 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 10:46:11 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> Message-ID: Hi Thomas! Should we squash changes for linux-sparc and linux-zero into your patch? I?m currently not at the computer, but could send them late in the afternoon when I?m back in Germany. Adrian > On Aug 29, 2017, at 10:25 AM, Thomas St?fe wrote: > > Hi, > > I got the libjvm.so to build on linuxppc64 and linuxs390 (AIX builds are still running), see attached patch. > > @Eric: thank you for the hints! > > The replacements for STATIC_CAST are trivial. > The cause for the second error (renamed function parameter) is too, but for the life of me I could not have guessed it from the error messages I get: > > priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of ?D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with I = long int; D = long int; long unsigned int byte_size = 8ul]?: > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from ?D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = long int; D = long int; Derived = Atomic::PlatformAdd<8ul>]? > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:367:49: required from ?D Atomic::AddImpl::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value)) > >::type>::operator()(I, volatile D*) const [with I = long int; D = long int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type = void]? > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:353:41: required from ?static D Atomic::add(I, volatile D*) [with I = long int; D = long int]? > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:93:31: required from here > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: error: insufficient contextual information to determine type > ); > ^ > > I think this is a bit of a step backward in terms of maintainability. While I see the increased ease of use for the callers of Atomic, I am not yet convinced introducing template metaprogramming is worth the time it takes to figure out these kind of errors. We do not have many developers versed in C++ metaprogramming (which, as a skill set, does not necessarily intersect with low level system programming). > > Sorry for the rant, and thanks again for the help in figuring this out! > > Kind Regards, Thomas > > >> On Tue, Aug 29, 2017 at 9:01 AM, Erik ?sterlund wrote: >> Hi, >> >> First of all, sorry for pushing the change that broke these platforms. I did not spot these problems in Kim's patch, and could not test the code on these platforms. >> As for what is wrong here, it looks like s/STATIC_CAST/STATIC_ASSERT/g is one of the problems as you noticed, and the local variables have seemingly also been renamed. In particular, it looks like the inline assembly references the variable "inc" that looks like it has been renamed "add_value". >> >> Sorry about the inconvenience. >> >> Thanks, >> /Erik >> >> >>> On 2017-08-29 00:24, John Paul Adrian Glaubitz wrote: >>> After regexp-replacing STATIC_CAST with STATIC_ASSERT, I'm confronted with: >>> >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) >>> const [with I = int; D = int; long unsigned int byte_size = 4]': >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from 'D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = >>> int; D = int; Derived = Atomic::PlatformAdd<4>]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: required from 'D Atomic::AddImpl::value && >>> IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type>::operator()(I, volatile D*) const [with I = int; D = >>> int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type = >>> void]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: required from 'static D Atomic::add(I, volatile D*) [with I = int; D = int]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:405:73: required from here >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:122:6: error: insufficient contextual information to determine type >>> ); >>> ^ >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:137:6: error: insufficient contextual information to determine type >>> ); >>> ^ >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, volatile D*) >>> const [with I = long unsigned int; D = long unsigned int; long unsigned int byte_size = 8]': >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: required from 'D Atomic::AddAndFetch::operator()(I, volatile D*) const [with I = >>> long unsigned int; D = long unsigned int; Derived = Atomic::PlatformAdd<8>]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: required from 'D Atomic::AddImpl::value && >>> IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == IsSigned::value))>::type>::operator()(I, volatile D*) const [with I = long >>> unsigned int; D = long unsigned int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) <= sizeof (D))) && (IsSigned::value == >>> IsSigned::value))>::type = void]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: required from 'static D Atomic::add(I, volatile D*) [with I = long unsigned int; D = long >>> unsigned int]' >>> /home/glaubitz/hs/hotspot/src/share/vm/services/mallocTracker.hpp:58:29: required from here >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: error: insufficient contextual information to determine type >>> ); >>> ^ >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:188:6: error: insufficient contextual information to determine type >>> ); >>> ^ >>> lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/hs/build/linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' failed >>> make[3]: *** [/home/glaubitz/hs/build/linux-s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o] Error 1 >>> make[3]: Leaving directory '/home/glaubitz/hs/hotspot/make' >>> make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed >>> make[2]: *** [hotspot-server-libs] Error 2 >>> make[2]: *** Waiting for unfinished jobs.... >>> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main >>> /home/glaubitz/hs/jdk/make/data/charsetmapping /home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext hkscs >>> '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetmapping/HKSCS.java' >>> Generating jdk.charsets euctw >>> /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the.charsetmapping-hkscs' >>> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main >>> /home/glaubitz/hs/jdk/make/data/charsetmapping /home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext euctw >>> '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetmapping/EUC_TW.java' >>> Generating support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat >>> /usr/bin/touch '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/_the.charsetmapping-euctw' >>> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes build.tools.charsetmapping.Main >>> '/home/glaubitz/hs/jdk/make/data/charsetmapping/sjis0213.map' >>> '/home/glaubitz/hs/build/linux-s390x-normal-server-release/support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat' sjis0213 >>> >>> I have been looking at the code for over half an hour but I couldn't find the actual problem. >>> >>> Anyone got an idea? >>> >> > > From erik.helin at oracle.com Tue Aug 29 09:04:02 2017 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 29 Aug 2017 11:04:02 +0200 Subject: RFR(XXS) 8186797: cardtable_rs in g1CollectedHeap::initialize() defined, but never used In-Reply-To: References: Message-ID: <80740e83-1b1d-a73c-95b6-fb311f9c096c@oracle.com> On 08/28/2017 01:50 PM, Zhengyu Gu wrote: > Please review this one line cleanup to remove unused cardtable_rs. > > It seems to be a leftover of refactoring > G1RegionToSpaceMapper::create_mapper() to create_aux_memory_mapper(). > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186797 > Webrev: http://cr.openjdk.java.net/~zgu/8186797/webrev.00/ Looks good, Reviewed. I can sponsor this patch for you. Thanks, Erik > Test: > > hotspot_gc on Linux x64 with fastdebug and release build > > > Thanks, > > -Zhengyu From thomas.stuefe at gmail.com Tue Aug 29 09:46:45 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 11:46:45 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> Message-ID: On Tue, Aug 29, 2017 at 10:46 AM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi Thomas! > > Should we squash changes for linux-sparc and linux-zero into your patch? > > I?m currently not at the computer, but could send them late in the > afternoon when I?m back in Germany. > > Adrian > > Sure. Or the other way around, with you as the author. Either way is fine with me. ..Thomas > On Aug 29, 2017, at 10:25 AM, Thomas St?fe > wrote: > > Hi, > > I got the libjvm.so to build on linuxppc64 and linuxs390 (AIX builds are > still running), see attached patch. > > @Eric: thank you for the hints! > > The replacements for STATIC_CAST are trivial. > The cause for the second error (renamed function parameter) is too, but > for the life of me I could not have guessed it from the error messages I > get: > > priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/ > linux_s390/vm/atomic_linux_s390.hpp: In instantiation of ?D > Atomic::PlatformAdd::add_and_fetch(I, volatile D*) const [with > I = long int; D = long int; long unsigned int byte_size = 8ul]?: > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:430:74: > required from ?D Atomic::AddAndFetch::operator()(I, volatile > D*) const [with I = long int; D = long int; Derived = > Atomic::PlatformAdd<8ul>]? > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:367:49: > required from ?D Atomic::AddImpl EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof (I) > <= sizeof (D))) && (IsSigned::value == IsSigned::value)) > >::type>::operator()(I, volatile D*) const [with I = long int; D = long > int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) > && (sizeof (I) <= sizeof (D))) && (IsSigned::value == > IsSigned::value))>::type = void]? > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:353:41: > required from ?static D Atomic::add(I, volatile D*) [with I = long int; D > = long int]? > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/share/vm/runtime/atomic.hpp:93:31: > required from here > /priv/d031900/openjdk/jdk10-hs/source/hotspot/src/os_cpu/ > linux_s390/vm/atomic_linux_s390.hpp:173:6: error: insufficient contextual > information to determine type > ); > ^ > > I think this is a bit of a step backward in terms of maintainability. > While I see the increased ease of use for the callers of Atomic, I am not > yet convinced introducing template metaprogramming is worth the time it > takes to figure out these kind of errors. We do not have many developers > versed in C++ metaprogramming (which, as a skill set, does not necessarily > intersect with low level system programming). > > Sorry for the rant, and thanks again for the help in figuring this out! > > Kind Regards, Thomas > > > On Tue, Aug 29, 2017 at 9:01 AM, Erik ?sterlund > wrote: > >> Hi, >> >> First of all, sorry for pushing the change that broke these platforms. I >> did not spot these problems in Kim's patch, and could not test the code on >> these platforms. >> As for what is wrong here, it looks like s/STATIC_CAST/STATIC_ASSERT/g is >> one of the problems as you noticed, and the local variables have seemingly >> also been renamed. In particular, it looks like the inline assembly >> references the variable "inc" that looks like it has been renamed >> "add_value". >> >> Sorry about the inconvenience. >> >> Thanks, >> /Erik >> >> >> On 2017-08-29 00:24, John Paul Adrian Glaubitz wrote: >> >>> After regexp-replacing STATIC_CAST with STATIC_ASSERT, I'm confronted >>> with: >>> >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: >>> In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, >>> volatile D*) >>> const [with I = int; D = int; long unsigned int byte_size = 4]': >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: >>> required from 'D Atomic::AddAndFetch::operator()(I, volatile >>> D*) const [with I = >>> int; D = int; Derived = Atomic::PlatformAdd<4>]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: >>> required from 'D Atomic::AddImpl>> EnableIf<(((IsIntegral::value && >>> IsIntegral::value) && (sizeof (I) <= sizeof (D))) && >>> (IsSigned::value == IsSigned::value))>::type>::operator()(I, >>> volatile D*) const [with I = int; D = >>> int; typename EnableIf<(((IsIntegral::value && IsIntegral::value) >>> && (sizeof (I) <= sizeof (D))) && (IsSigned::value == >>> IsSigned::value))>::type = >>> void]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: >>> required from 'static D Atomic::add(I, volatile D*) [with I = int; D = >>> int]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:405:73: >>> required from here >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:122:6: >>> error: insufficient contextual information to determine type >>> ); >>> ^ >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:137:6: >>> error: insufficient contextual information to determine type >>> ); >>> ^ >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp: >>> In instantiation of 'D Atomic::PlatformAdd::add_and_fetch(I, >>> volatile D*) >>> const [with I = long unsigned int; D = long unsigned int; long unsigned >>> int byte_size = 8]': >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:430:74: >>> required from 'D Atomic::AddAndFetch::operator()(I, volatile >>> D*) const [with I = >>> long unsigned int; D = long unsigned int; Derived = >>> Atomic::PlatformAdd<8>]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:367:36: >>> required from 'D Atomic::AddImpl>> EnableIf<(((IsIntegral::value && >>> IsIntegral::value) && (sizeof (I) <= sizeof (D))) && >>> (IsSigned::value == IsSigned::value))>::type>::operator()(I, >>> volatile D*) const [with I = long >>> unsigned int; D = long unsigned int; typename >>> EnableIf<(((IsIntegral::value && IsIntegral::value) && (sizeof >>> (I) <= sizeof (D))) && (IsSigned::value == >>> IsSigned::value))>::type = void]' >>> /home/glaubitz/hs/hotspot/src/share/vm/runtime/atomic.hpp:353:25: >>> required from 'static D Atomic::add(I, volatile D*) [with I = long >>> unsigned int; D = long >>> unsigned int]' >>> /home/glaubitz/hs/hotspot/src/share/vm/services/mallocTracker.hpp:58:29: >>> required from here >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:173:6: >>> error: insufficient contextual information to determine type >>> ); >>> ^ >>> /home/glaubitz/hs/hotspot/src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp:188:6: >>> error: insufficient contextual information to determine type >>> ); >>> ^ >>> lib/CompileJvm.gmk:208: recipe for target '/home/glaubitz/hs/build/linux >>> -s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o' >>> failed >>> make[3]: *** [/home/glaubitz/hs/build/linux >>> -s390x-normal-server-release/hotspot/variant-server/libjvm/objs/abstractCompiler.o] >>> Error 1 >>> make[3]: Leaving directory '/home/glaubitz/hs/hotspot/make' >>> make/Main.gmk:263: recipe for target 'hotspot-server-libs' failed >>> make[2]: *** [hotspot-server-libs] Error 2 >>> make[2]: *** Waiting for unfinished jobs.... >>> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M >>> -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes >>> build.tools.charsetmapping.Main >>> /home/glaubitz/hs/jdk/make/data/charsetmapping >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/su >>> pport/gensrc/jdk.charsets/sun/nio/cs/ext hkscs >>> '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetm >>> apping/HKSCS.java' >>> Generating jdk.charsets euctw >>> /usr/bin/touch '/home/glaubitz/hs/build/linux >>> -s390x-normal-server-release/support/gensrc/jdk.charsets/sun >>> /nio/cs/ext/_the.charsetmapping-hkscs' >>> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M >>> -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes >>> build.tools.charsetmapping.Main >>> /home/glaubitz/hs/jdk/make/data/charsetmapping >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/su >>> pport/gensrc/jdk.charsets/sun/nio/cs/ext euctw >>> '/home/glaubitz/hs/jdk/make/src/classes/build/tools/charsetm >>> apping/EUC_TW.java' >>> Generating support/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat >>> /usr/bin/touch '/home/glaubitz/hs/build/linux >>> -s390x-normal-server-release/support/gensrc/jdk.charsets/sun >>> /nio/cs/ext/_the.charsetmapping-euctw' >>> /usr/lib/jvm/java-8-openjdk-s390x/bin/java -XX:+UseSerialGC -Xms32M >>> -Xmx512M -XX:TieredStopAtLevel=1 -Duser.language=en -Duser.country=US -cp >>> /home/glaubitz/hs/build/linux-s390x-normal-server-release/buildtools/jdk_tools_classes >>> build.tools.charsetmapping.Main >>> '/home/glaubitz/hs/jdk/make/data/charsetmapping/sjis0213.map' >>> '/home/glaubitz/hs/build/linux-s390x-normal-server-release/s >>> upport/gensrc/jdk.charsets/sun/nio/cs/ext/sjis0213.dat' sjis0213 >>> >>> I have been looking at the code for over half an hour but I couldn't >>> find the actual problem. >>> >>> Anyone got an idea? >>> >>> >> > > > From patric.hedlin at oracle.com Tue Aug 29 09:51:27 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 29 Aug 2017 11:51:27 +0200 Subject: JDK10/RFR(M): 8182279: Add HW feature detection support for SPARC Core C5 (on Solaris). In-Reply-To: References: <2c3adfc4-3bcb-3cf8-fc18-216602849dcb@oracle.com> Message-ID: Hi David, Thanks for making time to review. On 08/29/2017 09:20 AM, David Holmes wrote: > Hi Patric, > > On 29/08/2017 4:41 PM, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8182279 >> >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8182279/ > > I can't comment on the accuracy of the added features of course but > structurally etc these changes seem okay. Only odd thing I noticed in > vm_version_solaris_sparc.cpp: > > 410 #ifndef AV2_SPARC_SPARC6 > 411 #define AV2_SPARC_SPARC6 0x00000200 // REVB*, FPSLL*, > RDENTROPY, LDM* and STM* > 412 #endif > 413 #ifndef AV2_SPARC_DICTUNP > 414 #define AV2_SPARC_DICTUNP 0x00002000 // Dictionary unpack > instruction > > why did you leave a gap in the sequence? > I have left out the support/definitions for Oracle Numbers: #define AV2_SPARC_ONADDSUB 0x00000400 // Oracle Number add/subtract #define AV2_SPARC_ONMUL 0x00000800 // Oracle Number multiply #define AV2_SPARC_ONDIV 0x00001000 // Oracle Number divide (Which I judged not very useful in the JVM.) Best regards, Patric > Thanks, > David > ----- > >> Note 1. SPARC Core C5 disclosure has been approved for reviewing on >> this list(s). >> Note 2. SPARC Core C5 and M8 servers are currently not available to >> regular testing. >> Note 3. Core C5 was previously named Core S5. >> >> >> 8182279: Add HW feature detection support for SPARC Core C5 (on >> Solaris). >> >> Updating SPARC feature/capability detection to include support >> for the SPARC Core C5. >> >> >> Caveat: >> >> This update will introduce some redundancies into the code base, >> features and definitions >> currently not used, addressed by subsequent bug or feature >> updates/patches. Fujitsu HW is >> treated very conservatively. >> >> >> Testing: >> >> Mostly tested on JDK9 (jtreg/RBT/hotspot/tier0-comp), RBT on >> non-M8 only. >> Testing on JDK10 (jtreg/RBT/hotspot/precheckin-comp), RBT on >> non-M8 only. >> >> >> Best regards, >> Patric From glaubitz at physik.fu-berlin.de Tue Aug 29 11:45:32 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 13:45:32 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> Message-ID: <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> On 08/29/2017 11:46 AM, Thomas St?fe wrote: > Should we squash changes for linux-sparc and linux-zero into your patch? > > I?m currently not at the computer, but could send them late in the afternoon when I?m back in Germany. > > Sure. Or the other way around, with you as the author. Either way is fine with me. Ok, I will push a webrev this evening. I have managed to fix the Linux/s390 build now as well. My patch will address: - linux-zero - linux-sparc - linux-s390 - linux-ppc I assume, for aix-ppc, it's enough to replace STATIC_CAST with STATIC_ASSERT? For BSD, I will need to setup a NetBSD VM instance first. But I will do that as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Tue Aug 29 12:01:34 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 14:01:34 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> Message-ID: On Tue, Aug 29, 2017 at 1:45 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/29/2017 11:46 AM, Thomas St?fe wrote: > > Should we squash changes for linux-sparc and linux-zero into your > patch? > > > > I?m currently not at the computer, but could send them late in the > afternoon when I?m back in Germany. > > > > Sure. Or the other way around, with you as the author. Either way is > fine with me. > > Ok, I will push a webrev this evening. I have managed to fix the Linux/s390 > build now as well. > > My patch will address: > > - linux-zero > - linux-sparc > - linux-s390 > - linux-ppc > > I assume, for aix-ppc, it's enough to replace STATIC_CAST with > STATIC_ASSERT? > > Yes, but you could also just use my patch I attached earlier. > For BSD, I will need to setup a NetBSD VM instance first. But I will do > that > as well. > Great thanks! ..Thomas > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From glaubitz at physik.fu-berlin.de Tue Aug 29 12:08:25 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 14:08:25 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> Message-ID: <07D11E28-A1DA-4BC2-B881-D6EC7E60A56F@physik.fu-berlin.de> Ah, sorry. I missed your patch. I will use it, of course. > On Aug 29, 2017, at 2:01 PM, Thomas St?fe wrote: > > > >> On Tue, Aug 29, 2017 at 1:45 PM, John Paul Adrian Glaubitz wrote: >> On 08/29/2017 11:46 AM, Thomas St?fe wrote: >> > Should we squash changes for linux-sparc and linux-zero into your patch? >> > >> > I?m currently not at the computer, but could send them late in the afternoon when I?m back in Germany. >> > >> > Sure. Or the other way around, with you as the author. Either way is fine with me. >> >> Ok, I will push a webrev this evening. I have managed to fix the Linux/s390 >> build now as well. >> >> My patch will address: >> >> - linux-zero >> - linux-sparc >> - linux-s390 >> - linux-ppc >> >> I assume, for aix-ppc, it's enough to replace STATIC_CAST with STATIC_ASSERT? >> > > Yes, but you could also just use my patch I attached earlier. > >> For BSD, I will need to setup a NetBSD VM instance first. But I will do that >> as well. > > Great thanks! > > ..Thomas > >> >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaubitz at debian.org >> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From zgu at redhat.com Tue Aug 29 12:24:00 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 29 Aug 2017 08:24:00 -0400 Subject: RFR(XXS) 8186797: cardtable_rs in g1CollectedHeap::initialize() defined, but never used In-Reply-To: References: Message-ID: <5741d022-f8ec-e2b1-8510-dc525843ed12@redhat.com> Hi Thomas, I had issues with my email yesterday and lost your reply. Thanks for the review. -Zhengyu On 08/28/2017 07:50 AM, Zhengyu Gu wrote: > Please review this one line cleanup to remove unused cardtable_rs. > > It seems to be a leftover of refactoring > G1RegionToSpaceMapper::create_mapper() to create_aux_memory_mapper(). > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186797 > Webrev: http://cr.openjdk.java.net/~zgu/8186797/webrev.00/ > > Test: > > hotspot_gc on Linux x64 with fastdebug and release build > > > Thanks, > > -Zhengyu From zgu at redhat.com Tue Aug 29 12:31:06 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 29 Aug 2017 08:31:06 -0400 Subject: RFR(XXS) 8186797: cardtable_rs in g1CollectedHeap::initialize() defined, but never used In-Reply-To: <80740e83-1b1d-a73c-95b6-fb311f9c096c@oracle.com> References: <80740e83-1b1d-a73c-95b6-fb311f9c096c@oracle.com> Message-ID: Hi Erik, Thanks for the review and sponsorship. -Zhengyu On 08/29/2017 05:04 AM, Erik Helin wrote: > On 08/28/2017 01:50 PM, Zhengyu Gu wrote: >> Please review this one line cleanup to remove unused cardtable_rs. >> >> It seems to be a leftover of refactoring >> G1RegionToSpaceMapper::create_mapper() to create_aux_memory_mapper(). >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8186797 >> Webrev: http://cr.openjdk.java.net/~zgu/8186797/webrev.00/ > > Looks good, Reviewed. I can sponsor this patch for you. > > Thanks, > Erik > >> Test: >> >> hotspot_gc on Linux x64 with fastdebug and release build >> >> >> Thanks, >> >> -Zhengyu -------------- next part -------------- A non-text attachment was scrubbed... Name: 8186748.patch Type: text/x-patch Size: 1246 bytes Desc: not available URL: From coleen.phillimore at oracle.com Tue Aug 29 14:01:17 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Aug 2017 10:01:17 -0400 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses Message-ID: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> Summary: clear out resolved_reference from ClassLoaderData::_handles See the bug for details. open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8181170 Tested with: tier1 hotspot (includes most hotspot jtreg tests) tonga nsk.jvmti, nsk.jdi (internal tests) jdk/test/java/lang/instrument jdk/test/com/sun/jdi Thanks, Coleen From stefan.karlsson at oracle.com Tue Aug 29 14:52:28 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 29 Aug 2017 16:52:28 +0200 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses In-Reply-To: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> References: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> Message-ID: The addition of the G1 barrier looks good. Thanks, StefanK On 2017-08-29 16:01, coleen.phillimore at oracle.com wrote: > Summary: clear out resolved_reference from ClassLoaderData::_handles > > See the bug for details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8181170 > > Tested with: > tier1 hotspot (includes most hotspot jtreg tests) > tonga nsk.jvmti, nsk.jdi (internal tests) > jdk/test/java/lang/instrument > jdk/test/com/sun/jdi > > Thanks, > Coleen > > From glaubitz at physik.fu-berlin.de Tue Aug 29 16:39:27 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 18:39:27 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> Message-ID: <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: > Ok, I will push a webrev this evening. I have managed to fix the Linux/s390 > build now as well. Here's the first revision of my webrev [1]. I verified: - linux-sparc - linux-zero - linux-s390 - linux-ppc I did not verify: - aix-ppc - bsd-zero I don't have any AIX system available, unfortunately, and I haven't had the time yet to set up a BSD machine, but I will do that within this week. I will then perform test builds on bsd-x86 and bsd-zero and provide patches if necessary. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From jesper.wilhelmsson at oracle.com Tue Aug 29 17:08:56 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 29 Aug 2017 19:08:56 +0200 Subject: Hotspot repository jdk10/hs will close by the end of the week Message-ID: <2081B825-B14B-4846-A1BA-294B4ECC1B5A@oracle.com> Hi, The repository consolidation is approaching and to prepare for that we need to push all new changes from jdk10/hs to jdk10/jdk10. Once that push is done the hotspot repository jdk10/hs will be closed for all pushes until the consolidation is done. The current plan is to integrate 10/hs to 10/10 on Friday/Saturday. The snapshot will be taken at 2pm PST. Pushes not completed before 2pm will be killed and rejected. To increase the likelihood of this proceeding smoothly, please act quickly if a bug is filed due to any change you are pushing this week. The repo consolidation will likely take at least two weeks. The preliminary date for opening 10/hs is September 18. This is subject to change depending on the duration of the consolidation effort. Thanks, /Jesper From jiangli.zhou at Oracle.COM Tue Aug 29 17:13:32 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 29 Aug 2017 10:13:32 -0700 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses In-Reply-To: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> References: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> Message-ID: Hi Coleen, This looks good to me. The InstanceKlass::deallocate_contents() takes care of the shared case and only calls MetadataFactory::free_metadata(loader_data, constants()) if the constants !is_shared(). So, we don?t need to worry about any possible side effect of calling G1SATBCardTableModRefBS::enqueue() on archived resolved_references object. Just to be safe, how about adding an assert in ConstantPoolCache::deallocate_contents() to make sure the current cache is !is_shared()? No need for a new webrev if you decide to add the assert. void InstanceKlass::deallocate_contents(ClassLoaderData* loader_data) { ... if (constants() != NULL) { assert (!constants()->on_stack(), "shouldn't be called if anything is onstack"); if (!constants()->is_shared()) { MetadataFactory::free_metadata(loader_data, constants()); } Thanks, Jiangli > On Aug 29, 2017, at 7:01 AM, coleen.phillimore at oracle.com wrote: > > Summary: clear out resolved_reference from ClassLoaderData::_handles > > See the bug for details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8181170 > > Tested with: > tier1 hotspot (includes most hotspot jtreg tests) > tonga nsk.jvmti, nsk.jdi (internal tests) > jdk/test/java/lang/instrument > jdk/test/com/sun/jdi > > Thanks, > Coleen > > From thomas.stuefe at gmail.com Tue Aug 29 17:17:51 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 19:17:51 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> Message-ID: Hi Adrian, On Tue, Aug 29, 2017 at 6:39 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: > >> Ok, I will push a webrev this evening. I have managed to fix the >> Linux/s390 >> build now as well. >> > Here's the first revision of my webrev [1]. > > I verified: > > - linux-sparc > - linux-zero > - linux-s390 > - linux-ppc > > I did not verify: > > - aix-ppc > - bsd-zero > > I don't have any AIX system available, unfortunately, and I haven't had > the time > yet to set up a BSD machine, but I will do that within this week. I will > then > perform test builds on bsd-x86 and bsd-zero and provide patches if > necessary. > > Adrian > > [1] http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ >> > > Thanks for the fix! AIX builds fine with the patch. I think the bsd zero fixes are fine too (I'd feel confident enough to push the fix without verifying bsd zero, but it is up to you). As neither of us can push this, could someone from Oracle please review and push the fix? Thanks! ..Thomas > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From coleen.phillimore at oracle.com Tue Aug 29 17:28:04 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Aug 2017 13:28:04 -0400 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> Message-ID: <3c863fee-257e-12c9-34b7-9a1690e88933@oracle.com> This seems good to me.? I apologize that I asked for these asserts. I will sponsor.?? Who are the reviewers? Coleen On 8/29/17 1:17 PM, Thomas St?fe wrote: > Hi Adrian, > > On Tue, Aug 29, 2017 at 6:39 PM, John Paul Adrian Glaubitz < > glaubitz at physik.fu-berlin.de> wrote: > >> On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: >> >>> Ok, I will push a webrev this evening. I have managed to fix the >>> Linux/s390 >>> build now as well. >>> >> Here's the first revision of my webrev [1]. >> >> I verified: >> >> - linux-sparc >> - linux-zero >> - linux-s390 >> - linux-ppc >> >> I did not verify: >> >> - aix-ppc >> - bsd-zero >> >> I don't have any AIX system available, unfortunately, and I haven't had >> the time >> yet to set up a BSD machine, but I will do that within this week. I will >> then >> perform test builds on bsd-x86 and bsd-zero and provide patches if >> necessary. >> >> Adrian >> >> [1] http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ >> > Thanks for the fix! > > AIX builds fine with the patch. I think the bsd zero fixes are fine too > (I'd feel confident enough to push the fix without verifying bsd zero, but > it is up to you). > > As neither of us can push this, could someone from Oracle please review and > push the fix? Thanks! > > ..Thomas > > >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaubitz at debian.org >> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> From glaubitz at physik.fu-berlin.de Tue Aug 29 17:28:05 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 19:28:05 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> Message-ID: <81e53aee-dfab-0e2c-f660-88903063725c@physik.fu-berlin.de> On 08/29/2017 07:17 PM, Thomas St?fe wrote: > Thanks for the fix! > > AIX builds fine with the patch. I think the bsd zero fixes are fine too (I'd > feel confident enough to push the fix without verifying bsd zero, but it is > up to you). I think it should be fine merging as-is now. I am sure that bsd-zero has possibly other issues anyway since it probably hasn't been touched for a while. I will perform test builds and provide patches if necessary. > As neither of us can push this, could someone from Oracle please review and push the fix? I concur. Maybe Eric can push it :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Tue Aug 29 17:38:48 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 19:38:48 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <3c863fee-257e-12c9-34b7-9a1690e88933@oracle.com> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <3c863fee-257e-12c9-34b7-9a1690e88933@oracle.com> Message-ID: Hi Coleen, On Tue, Aug 29, 2017 at 7:28 PM, wrote: > > This seems good to me. I apologize that I asked for these asserts. I will > sponsor. Who are the reviewers? > > No need to, mistakes happen. I'm the sole reviewer for now. ..Thomas > Coleen > > > On 8/29/17 1:17 PM, Thomas St?fe wrote: > >> Hi Adrian, >> >> On Tue, Aug 29, 2017 at 6:39 PM, John Paul Adrian Glaubitz < >> glaubitz at physik.fu-berlin.de> wrote: >> >> On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: >>> >>> Ok, I will push a webrev this evening. I have managed to fix the >>>> Linux/s390 >>>> build now as well. >>>> >>>> Here's the first revision of my webrev [1]. >>> >>> I verified: >>> >>> - linux-sparc >>> - linux-zero >>> - linux-s390 >>> - linux-ppc >>> >>> I did not verify: >>> >>> - aix-ppc >>> - bsd-zero >>> >>> I don't have any AIX system available, unfortunately, and I haven't had >>> the time >>> yet to set up a BSD machine, but I will do that within this week. I will >>> then >>> perform test builds on bsd-x86 and bsd-zero and provide patches if >>> necessary. >>> >>> Adrian >>> >>> [1] http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ >>> >>> Thanks for the fix! >> >> AIX builds fine with the patch. I think the bsd zero fixes are fine too >> (I'd feel confident enough to push the fix without verifying bsd zero, but >> it is up to you). >> >> As neither of us can push this, could someone from Oracle please review >> and >> push the fix? Thanks! >> >> ..Thomas >> >> >> -- >>> .''`. John Paul Adrian Glaubitz >>> : :' : Debian Developer - glaubitz at debian.org >>> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >>> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >>> >>> > From coleen.phillimore at oracle.com Tue Aug 29 17:44:06 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Aug 2017 13:44:06 -0400 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <3c863fee-257e-12c9-34b7-9a1690e88933@oracle.com> Message-ID: <9b883e1c-fd25-30b7-ef5b-5a7b0d87be4d@oracle.com> On 8/29/17 1:38 PM, Thomas St?fe wrote: > Hi Coleen, > > On Tue, Aug 29, 2017 at 7:28 PM, > wrote: > > > This seems good to me.? I apologize that I asked for these > asserts. I will sponsor.?? Who are the reviewers? > > > No need to, mistakes happen. I'm the sole reviewer for now. Ok, I'll sponsor.? Erik may be done for the day. Coleen > > ..Thomas > > Coleen > > > On 8/29/17 1:17 PM, Thomas St?fe wrote: > > Hi Adrian, > > On Tue, Aug 29, 2017 at 6:39 PM, John Paul Adrian Glaubitz < > glaubitz at physik.fu-berlin.de > > wrote: > > On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: > > Ok, I will push a webrev this evening. I have managed > to fix the > Linux/s390 > build now as well. > > Here's the first revision of my webrev [1]. > > I verified: > > - linux-sparc > - linux-zero > - linux-s390 > - linux-ppc > > I did not verify: > > - aix-ppc > - bsd-zero > > I don't have any AIX system available, unfortunately, and > I haven't had > the time > yet to set up a BSD machine, but I will do that within > this week. I will > then > perform test builds on bsd-x86 and bsd-zero and provide > patches if > necessary. > > Adrian > > [1] > http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ > > > Thanks for the fix! > > AIX builds fine with the patch. I think the bsd zero fixes are > fine too > (I'd feel confident enough to push the fix without verifying > bsd zero, but > it is up to you). > > As neither of us can push this, could someone from Oracle > please review and > push the fix? Thanks! > > ..Thomas > > > -- > ? .''`.? John Paul Adrian Glaubitz > : :' :? Debian Developer - glaubitz at debian.org > > `. `'? ?Freie Universitaet Berlin - > glaubitz at physik.fu-berlin.de > > ? ?`-? ? GPG: 62FF 8A75 84E0 2956 9546? 0006 7426 3B37 > F5B5 F913 > > > From thomas.stuefe at gmail.com Tue Aug 29 17:59:23 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Aug 2017 17:59:23 +0000 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <9b883e1c-fd25-30b7-ef5b-5a7b0d87be4d@oracle.com> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <3c863fee-257e-12c9-34b7-9a1690e88933@oracle.com> <9b883e1c-fd25-30b7-ef5b-5a7b0d87be4d@oracle.com> Message-ID: On Tue 29. Aug 2017 at 19:44, wrote: > > > On 8/29/17 1:38 PM, Thomas St?fe wrote: > > Hi Coleen, > > On Tue, Aug 29, 2017 at 7:28 PM, wrote: > >> >> This seems good to me. I apologize that I asked for these asserts. I >> will sponsor. Who are the reviewers? >> >> > No need to, mistakes happen. I'm the sole reviewer for now. > > > Ok, I'll sponsor. Erik may be done for the day. > Coleen > Thank you, Coleen! To be clear, I think the asserts are perfectly reasonable. It was just a typo. Best regards, Thomas > > > ..Thomas > > >> Coleen >> >> >> On 8/29/17 1:17 PM, Thomas St?fe wrote: >> >>> Hi Adrian, >>> >>> On Tue, Aug 29, 2017 at 6:39 PM, John Paul Adrian Glaubitz < >>> glaubitz at physik.fu-berlin.de> wrote: >>> >>> On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: >>>> >>>> Ok, I will push a webrev this evening. I have managed to fix the >>>>> Linux/s390 >>>>> build now as well. >>>>> >>>>> Here's the first revision of my webrev [1]. >>>> >>>> I verified: >>>> >>>> - linux-sparc >>>> - linux-zero >>>> - linux-s390 >>>> - linux-ppc >>>> >>>> I did not verify: >>>> >>>> - aix-ppc >>>> - bsd-zero >>>> >>>> I don't have any AIX system available, unfortunately, and I haven't had >>>> the time >>>> yet to set up a BSD machine, but I will do that within this week. I will >>>> then >>>> perform test builds on bsd-x86 and bsd-zero and provide patches if >>>> necessary. >>>> >>>> Adrian >>>> >>>> [1] http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ >>>> >>>> Thanks for the fix! >>> >>> AIX builds fine with the patch. I think the bsd zero fixes are fine too >>> (I'd feel confident enough to push the fix without verifying bsd zero, >>> but >>> it is up to you). >>> >>> As neither of us can push this, could someone from Oracle please review >>> and >>> push the fix? Thanks! >>> >>> ..Thomas >>> >>> >>> -- >>>> .''`. John Paul Adrian Glaubitz >>>> : :' : Debian Developer - glaubitz at debian.org >>>> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >>>> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >>>> >>>> >> > > From coleen.phillimore at oracle.com Tue Aug 29 18:01:41 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Aug 2017 14:01:41 -0400 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <3c863fee-257e-12c9-34b7-9a1690e88933@oracle.com> <9b883e1c-fd25-30b7-ef5b-5a7b0d87be4d@oracle.com> Message-ID: <81f60d9b-a397-0152-b368-ba94255ec4f3@oracle.com> On 8/29/17 1:59 PM, Thomas St?fe wrote: > > On Tue 29. Aug 2017 at 19:44, > wrote: > > > > On 8/29/17 1:38 PM, Thomas St?fe wrote: >> Hi Coleen, >> >> On Tue, Aug 29, 2017 at 7:28 PM, > > wrote: >> >> >> This seems good to me.? I apologize that I asked for these >> asserts. I will sponsor.?? Who are the reviewers? >> >> >> No need to, mistakes happen. I'm the sole reviewer for now. > > Ok, I'll sponsor. Erik may be done for the day. > Coleen > > > Thank you, Coleen! > > To be clear, I think the asserts are perfectly reasonable. It was just > a typo. Yes, understood.? I thought they were a good idea. Coleen > > Best regards, Thomas > > > >> >> ..Thomas >> >> Coleen >> >> >> On 8/29/17 1:17 PM, Thomas St?fe wrote: >> >> Hi Adrian, >> >> On Tue, Aug 29, 2017 at 6:39 PM, John Paul Adrian Glaubitz < >> glaubitz at physik.fu-berlin.de >> > wrote: >> >> On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: >> >> Ok, I will push a webrev this evening. I have >> managed to fix the >> Linux/s390 >> build now as well. >> >> Here's the first revision of my webrev [1]. >> >> I verified: >> >> - linux-sparc >> - linux-zero >> - linux-s390 >> - linux-ppc >> >> I did not verify: >> >> - aix-ppc >> - bsd-zero >> >> I don't have any AIX system available, unfortunately, >> and I haven't had >> the time >> yet to set up a BSD machine, but I will do that >> within this week. I will >> then >> perform test builds on bsd-x86 and bsd-zero and >> provide patches if >> necessary. >> >> Adrian >> >> [1] >> http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ >> >> >> Thanks for the fix! >> >> AIX builds fine with the patch. I think the bsd zero >> fixes are fine too >> (I'd feel confident enough to push the fix without >> verifying bsd zero, but >> it is up to you). >> >> As neither of us can push this, could someone from Oracle >> please review and >> push the fix? Thanks! >> >> ..Thomas >> >> >> -- >> ? .''`.? John Paul Adrian Glaubitz >> : :' :? Debian Developer - glaubitz at debian.org >> >> `. `'? ?Freie Universitaet Berlin - >> glaubitz at physik.fu-berlin.de >> >> ? ?`-? ? GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 >> F5B5 F913 >> >> >> > From coleen.phillimore at oracle.com Tue Aug 29 18:03:38 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Aug 2017 14:03:38 -0400 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses In-Reply-To: References: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> Message-ID: <19a5e35e-69d3-057d-5b27-0970ad2b73d6@oracle.com> Thanks Stefan for the review, explanation and help. Coleen On 8/29/17 10:52 AM, Stefan Karlsson wrote: > The addition of the G1 barrier looks good. > > Thanks, > StefanK > > On 2017-08-29 16:01, coleen.phillimore at oracle.com wrote: >> Summary: clear out resolved_reference from ClassLoaderData::_handles >> >> See the bug for details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8181170 >> >> Tested with: >> tier1 hotspot (includes most hotspot jtreg tests) >> tonga nsk.jvmti, nsk.jdi (internal tests) >> jdk/test/java/lang/instrument >> jdk/test/com/sun/jdi >> >> Thanks, >> Coleen >> >> From coleen.phillimore at oracle.com Tue Aug 29 18:04:21 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Aug 2017 14:04:21 -0400 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses In-Reply-To: References: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> Message-ID: <7b3838fe-dd4b-02e8-5335-d0f5378cc72b@oracle.com> On 8/29/17 1:13 PM, Jiangli Zhou wrote: > Hi Coleen, > > This looks good to me. The?InstanceKlass::deallocate_contents() takes > care of the shared case and only > calls?MetadataFactory::free_metadata(loader_data, constants()) if the > constants !is_shared(). So, we don?t need to worry about any possible > side effect of calling G1SATBCardTableModRefBS::enqueue() on archived > resolved_references object. Just to be safe, how about adding an > assert in ConstantPoolCache::deallocate_contents() to make sure the > current cache is !is_shared()? No need for a new webrev if you decide > to add the assert. Yes, I thought of that too - I'll add it. Thanks for the code review. Coleen > > void InstanceKlass::deallocate_contents(ClassLoaderData* loader_data) { > ... > if (constants() != NULL) { > ? ? assert (!constants()->on_stack(), "shouldn't be called if anything > is onstack"); > if (!constants()->is_shared()) { > ? ? ? MetadataFactory::free_metadata(loader_data, constants()); > ? ? } > > > Thanks, > Jiangli > >> On Aug 29, 2017, at 7:01 AM, coleen.phillimore at oracle.com >> wrote: >> >> Summary: clear out resolved_reference from ClassLoaderData::_handles >> >> See the bug for details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8181170 >> >> Tested with: >> tier1 hotspot (includes most hotspot jtreg tests) >> tonga nsk.jvmti, nsk.jdi (internal tests) >> jdk/test/java/lang/instrument >> jdk/test/com/sun/jdi >> >> Thanks, >> Coleen >> >> > From david.holmes at oracle.com Tue Aug 29 21:46:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Aug 2017 07:46:57 +1000 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> Message-ID: <4998a6b2-cca1-286f-8a7b-21d1b82631a1@oracle.com> I know this has been pushed but just a nit: src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp inline D Atomic::PlatformAdd<4>::add_and_fetch(I inc, D volatile* dest) const { inline D Atomic::PlatformAdd<8>::add_and_fetch(I inc, D volatile* dest) const { On all the other platforms the first parameter is called add_value. So the fix here went in the "wrong direction". David On 30/08/2017 2:39 AM, John Paul Adrian Glaubitz wrote: > On 08/29/2017 01:45 PM, John Paul Adrian Glaubitz wrote: >> Ok, I will push a webrev this evening. I have managed to fix the >> Linux/s390 >> build now as well. > Here's the first revision of my webrev [1]. > > I verified: > > - linux-sparc > - linux-zero > - linux-s390 > - linux-ppc > > I did not verify: > > - aix-ppc > - bsd-zero > > I don't have any AIX system available, unfortunately, and I haven't had > the time > yet to set up a BSD machine, but I will do that within this week. I will > then > perform test builds on bsd-x86 and bsd-zero and provide patches if > necessary. > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186855/webrev.00/ > From glaubitz at physik.fu-berlin.de Tue Aug 29 21:52:14 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 29 Aug 2017 23:52:14 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <4998a6b2-cca1-286f-8a7b-21d1b82631a1@oracle.com> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <4998a6b2-cca1-286f-8a7b-21d1b82631a1@oracle.com> Message-ID: <925820f6-e87b-a330-7f24-f0b7ace05d42@physik.fu-berlin.de> On 08/29/2017 11:46 PM, David Holmes wrote: > I know this has been pushed but just a nit: > > src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp > > inline D Atomic::PlatformAdd<4>::add_and_fetch(I inc, D volatile* dest) const { > inline D Atomic::PlatformAdd<8>::add_and_fetch(I inc, D volatile* dest) const { > > On all the other platforms the first parameter is called add_value. So the fix here went in the "wrong direction". I actually wanted to comment on this, but I went to dinner after pushing the changeset up for web review. This part of the changeset actually came from Thomas and he renamed "add_value" back to "inc" in the signature. I was a bit hesitant about which approach to use myself because renaming "inc" to "add_value" in the inline assembly changed the line width of the changed lines so much that the formatting looked ugly. But, OTOH, as you explained, this fix went into the wrong direction :(. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Aug 29 22:16:41 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 00:16:41 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code Message-ID: <417d82ef-c9f9-bfcc-3e27-03f02e735e23@physik.fu-berlin.de> Hi! Here's my suggested change to fix the Zero build on linux-sparc. The first part of the change removes the unnecessary include of vmreg_sparc.inline.hpp in src/share/vm/compiler/oopMap.cpp. The second change moves src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp into the generic location src/share/vm/gc/shared/memset_with_concurrent_readers_sparc.cpp, so it is picked up both during the Server and Zero builds on linux-sparc. In order to prevent src/share/vm/gc/shared/memset_with_concurrent_readers_sparc.cpp from being built on non-SPARC targets - which would fail because of the inline assembly - I have guarded the entire file's definitions with "#ifdef SPARC #endif". I know the last bit of this changeset might not be the most elegant one, but it's the least intrusive I could come up with and it fully fixes the Zero builds for me on linux-sparc. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From serguei.spitsyn at oracle.com Wed Aug 30 01:15:35 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 29 Aug 2017 18:15:35 -0700 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses In-Reply-To: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> References: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> Message-ID: <947abee3-86d3-39f1-d94e-39b1d6369e58@oracle.com> Hi Coleen, The fix looks good to me. Thank you for fixing this! Thanks, Serguei On 8/29/17 07:01, coleen.phillimore at oracle.com wrote: > Summary: clear out resolved_reference from ClassLoaderData::_handles > > See the bug for details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8181170 > > Tested with: > tier1 hotspot (includes most hotspot jtreg tests) > tonga nsk.jvmti, nsk.jdi (internal tests) > jdk/test/java/lang/instrument > jdk/test/com/sun/jdi > > Thanks, > Coleen > > From david.holmes at oracle.com Wed Aug 30 02:24:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Aug 2017 12:24:47 +1000 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <417d82ef-c9f9-bfcc-3e27-03f02e735e23@physik.fu-berlin.de> References: <417d82ef-c9f9-bfcc-3e27-03f02e735e23@physik.fu-berlin.de> Message-ID: On 30/08/2017 8:16 AM, John Paul Adrian Glaubitz wrote: > Hi! > > Here's my suggested change to fix the Zero build on linux-sparc. > > The first part of the change removes the unnecessary include of > vmreg_sparc.inline.hpp in src/share/vm/compiler/oopMap.cpp. > > The second change moves > src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp > into the generic location > src/share/vm/gc/shared/memset_with_concurrent_readers_sparc.cpp, > so it is picked up both during the Server and Zero builds on linux-sparc. > > In order to prevent > src/share/vm/gc/shared/memset_with_concurrent_readers_sparc.cpp > from being built on non-SPARC targets - which would fail because of the > inline > assembly - I have guarded the entire file's definitions with "#ifdef > SPARC #endif". > > I know the last bit of this changeset might not be the most elegant one, > but > it's the least intrusive I could come up with and it fully fixes the > Zero builds > for me on linux-sparc. Sorry but I don't support putting a sparc specific file in a shared location. Did you look at including src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp in the set of sources used when building zero for sparc? I would ask on build-dev for the best way to deal with this. Unfortunately I don't know my way around the "new" hotspot build well enough to give specific directions. Thanks, David > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/ > From thomas.stuefe at gmail.com Wed Aug 30 04:37:25 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 30 Aug 2017 06:37:25 +0200 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: <925820f6-e87b-a330-7f24-f0b7ace05d42@physik.fu-berlin.de> References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <1954dfd3-08b6-b7c0-183c-4e7018c4439b@oracle.com> <30847f33-5fa5-7c9d-4140-04224cb54db5@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <4998a6b2-cca1-286f-8a7b-21d1b82631a1@oracle.com> <925820f6-e87b-a330-7f24-f0b7ace05d42@physik.fu-berlin.de> Message-ID: On Tue, Aug 29, 2017 at 11:52 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > On 08/29/2017 11:46 PM, David Holmes wrote: > >> I know this has been pushed but just a nit: >> >> src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp >> >> inline D Atomic::PlatformAdd<4>::add_and_fetch(I inc, D volatile* dest) >> const { >> inline D Atomic::PlatformAdd<8>::add_and_fetch(I inc, D volatile* dest) >> const { >> >> On all the other platforms the first parameter is called add_value. So >> the fix here went in the "wrong direction". >> > I actually wanted to comment on this, but I went to dinner after pushing > the changeset > up for web review. This part of the changeset actually came from Thomas > and he renamed > "add_value" back to "inc" in the signature. I was a bit hesitant about > which approach > to use myself because renaming "inc" to "add_value" in the inline assembly > changed > the line width of the changed lines so much that the formatting looked > ugly. But, OTOH, > as you explained, this fix went into the wrong direction :(. > > Adrian > > I do not think it matters much. @David: Would you like us to open a follow up item to fix the variable name on s390? ..Thomas > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From david.holmes at oracle.com Wed Aug 30 05:03:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Aug 2017 15:03:11 +1000 Subject: 8186476: Re: linux-sparc and linux-zero builds broken In-Reply-To: References: <839f7092-283e-dadd-068b-0bf610f74747@physik.fu-berlin.de> <9a6fbcb2-c060-2bf0-44c2-f42a5ef6e888@physik.fu-berlin.de> <5e8368d0-724c-8e5d-9278-8efd70cfa357@physik.fu-berlin.de> <8b54ab13-6ece-1411-4cbe-6862439bbe90@physik.fu-berlin.de> <3cb28a63-450a-f840-057b-914ca478d88f@physik.fu-berlin.de> <9cddea53-c216-3523-1f60-ef477d62aad2@physik.fu-berlin.de> <59A5115C.7020100@oracle.com> <6ac9bce2-427f-7baa-a067-1f6e98533e93@physik.fu-berlin.de> <2929ec56-88bd-d121-a23e-f4882a5109c5@physik.fu-berlin.de> <4998a6b2-cca1-286f-8a7b-21d1b82631a1@oracle.com> <925820f6-e87b-a330-7f24-f0b7ace05d42@physik.fu-berlin.de> Message-ID: <7d4f59a3-cca8-ec21-15d6-67bb87312735@oracle.com> On 30/08/2017 2:37 PM, Thomas St?fe wrote: > On Tue, Aug 29, 2017 at 11:52 PM, John Paul Adrian Glaubitz > > wrote: > > On 08/29/2017 11:46 PM, David Holmes wrote: > > I know this has been pushed but just a nit: > > src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp > > inline D Atomic::PlatformAdd<4>::add_and_fetch(I inc, D > volatile* dest) const { > inline D Atomic::PlatformAdd<8>::add_and_fetch(I inc, D > volatile* dest) const { > > On all the other platforms the first parameter is called > add_value. So the fix here went in the "wrong direction". > > I actually wanted to comment on this, but I went to dinner after > pushing the changeset > up for web review. This part of the changeset actually came from > Thomas and he renamed > "add_value" back to "inc" in the signature. I was a bit hesitant > about which approach > to use myself because renaming "inc" to "add_value" in the inline > assembly changed > the line width of the changed lines so much that the formatting > looked ugly. But, OTOH, > as you explained, this fix went into the wrong direction :(. > > Adrian > > > I do not think it matters much. > @David: Would you like us to open a follow up item to fix the variable > name on s390? Too much overhead. :) May just fix it next time the file is touched. As Adrian noted it does mess up the indentation using a longer name :) Cheers, David > ..Thomas > > > -- > ?.''`.? John Paul Adrian Glaubitz > : :' :? Debian Developer - glaubitz at debian.org > > `. `'? ?Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > ? `-? ? GPG: 62FF 8A75 84E0 2956 9546? 0006 7426 3B37 F5B5 F913 > > From glaubitz at physik.fu-berlin.de Wed Aug 30 07:30:16 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 09:30:16 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: References: <417d82ef-c9f9-bfcc-3e27-03f02e735e23@physik.fu-berlin.de> Message-ID: <5092ab9f-1fbf-c9dd-a72b-c8328a53358e@physik.fu-berlin.de> On 08/30/2017 04:24 AM, David Holmes wrote: > Sorry but I don't support putting a sparc specific file in a shared location. Ok, accepted. > Did you look at including src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp > in the set of sources used when building zero for sparc? I would ask on build-dev > for the best way to deal with this. Unfortunately I don't know my way around the > "new" hotspot build well enough to give specific directions. What about turning it into a header? Would that be acceptable? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Wed Aug 30 10:36:29 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 30 Aug 2017 06:36:29 -0400 Subject: RFR (S) 8181170: resolved_references array leaks for RedefineClasses In-Reply-To: <947abee3-86d3-39f1-d94e-39b1d6369e58@oracle.com> References: <35314469-1623-2226-0acc-cfbeb6853fcf@oracle.com> <947abee3-86d3-39f1-d94e-39b1d6369e58@oracle.com> Message-ID: Thank you for reviewing! Coleen On 8/29/17 9:15 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The fix looks good to me. > Thank you for fixing this! > > Thanks, > Serguei > > > On 8/29/17 07:01, coleen.phillimore at oracle.com wrote: >> Summary: clear out resolved_reference from ClassLoaderData::_handles >> >> See the bug for details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8181170.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8181170 >> >> Tested with: >> tier1 hotspot (includes most hotspot jtreg tests) >> tonga nsk.jvmti, nsk.jdi (internal tests) >> jdk/test/java/lang/instrument >> jdk/test/com/sun/jdi >> >> Thanks, >> Coleen >> >> > From magnus.ihse.bursie at oracle.com Wed Aug 30 13:39:51 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Aug 2017 15:39:51 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> Message-ID: On 2017-08-24 15:24, John Paul Adrian Glaubitz wrote: > On 08/24/2017 03:20 PM, David Holmes wrote: >> Ouch! So I have to wonder whether the raw -D for the cpu arch name is >> really necessary. >> There's obviously a lot of legacy usage to consider here though. But >> I've often assumed/ >> expected that if we tell the compiler to build for a specific cpu >> then the compiler would >> provide a suitable define (probably underscored) that we could then >> use in the code if needed. > > I agree. The string "LEGACY" in the identifier seems to confirm that. > Might be a good idea > to open a separate bug for the removal of this identifier. The platform defines for hotspot does not seem very thought through. As you discovered, the "raw -D" defines are short and likely to clash. In some cases, they overlap with definitions provided by the toolchain/OS includes. I'm happy to help in cleaning this mess up. :) /Magnus > >> Short-term solution would be your option (b) and rename alpha and sh >> to something unlikely to cause a clash. > Will do. > > I guess we can merge 8186723 without any changes then? It doesn't rely > on the legacy > (lowercase) identifier but on the all-uppercase identifier anyways. > > Adrian > From glaubitz at physik.fu-berlin.de Wed Aug 30 13:48:34 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 15:48:34 +0200 Subject: [RFR]: 8186579: VM_Version::platform_features() needs update on linux-sparc Message-ID: Hi! Here's my initial patch to port VM_Version::platform_features() to the new interface on linux-sparc. I have used the solaris-sparc version as a template and implemented most of the detection features for linux-sparc. It's not complete and lacks some additional detects which are present in solaris-sparc version which I have listed in the comments of platform_features() in vm_version_linux_sparc.cpp. I have tested the patch on linux-sparc and it fixes the build for me. Webrev in [1]. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186579/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Aug 30 13:52:46 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 15:52:46 +0200 Subject: [RFR]: 8186579: VM_Version::platform_features() needs update on linux-sparc In-Reply-To: References: Message-ID: On 08/30/2017 03:48 PM, John Paul Adrian Glaubitz wrote: > I have tested the patch on linux-sparc and it fixes the build for me. > > Webrev in [1]. I found some typos in the comments, naturally after sending the mail. Updated webrev in [1]. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186579/webrev.01/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Aug 30 14:43:14 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 16:43:14 +0200 Subject: Name clashes - was: Re: [RFR]: 8186723: Add SuperH as new architecture for linux In-Reply-To: References: <7085bf7e-b419-7a5a-540f-e6d9180af47d@physik.fu-berlin.de> <7c2e39da-63ff-5868-7a2c-432a5a9050fa@physik.fu-berlin.de> <9ee56427-ebda-ecf3-e4d1-c7ec553a6a32@oracle.com> <190d2c2f-f1ee-b8f7-9133-6215cf76f3e2@physik.fu-berlin.de> Message-ID: <86bd513a-a06e-3c7a-da0a-e81717d8b16e@physik.fu-berlin.de> On 08/30/2017 03:39 PM, Magnus Ihse Bursie wrote: > The platform defines for hotspot does not seem very thought through. > As you discovered, the "raw -D" defines are short and likely to clash. > In some cases, they overlap with definitions provided by the toolchain/OS includes. Yep. > I'm happy to help in cleaning this mess up. :) Do you have any suggestion what to do? What about removing the lower-case definitions from CFLAGS completely? I could whip up a patch and test it on all platforms I have access to which is basically everything but AIX (and Windows where I really don't to start building OpenJDK on at the moment). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From patric.hedlin at oracle.com Wed Aug 30 14:46:34 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Wed, 30 Aug 2017 16:46:34 +0200 Subject: [RFR]: 8186579: VM_Version::platform_features() needs update on linux-sparc In-Reply-To: References: Message-ID: <6fb8ba09-97db-19a8-0fc5-3e26b6737bdb@oracle.com> Hi Paul, This seems to be a duplicate of JDK-8172232. Since this is now a community effort/update, perhaps I can offer you the associated patch. Best regards, Patric On 2017-08-30 15:48, John Paul Adrian Glaubitz wrote: > Hi! > > Here's my initial patch to port VM_Version::platform_features() to the > new interface on linux-sparc. I have used the solaris-sparc version as > a template and implemented most of the detection features for > linux-sparc. > > It's not complete and lacks some additional detects which are present in > solaris-sparc version which I have listed in the comments of > platform_features() > in vm_version_linux_sparc.cpp. > > I have tested the patch on linux-sparc and it fixes the build for me. > > Webrev in [1]. > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186579/webrev.00/ > From glaubitz at physik.fu-berlin.de Wed Aug 30 14:50:03 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 16:50:03 +0200 Subject: [RFR]: 8186579: VM_Version::platform_features() needs update on linux-sparc In-Reply-To: <6fb8ba09-97db-19a8-0fc5-3e26b6737bdb@oracle.com> References: <6fb8ba09-97db-19a8-0fc5-3e26b6737bdb@oracle.com> Message-ID: <3e15877b-3d10-86d7-bd98-a5694eb77b0c@physik.fu-berlin.de> Hi Patric! On 08/30/2017 04:46 PM, Patric Hedlin wrote: > This seems to be a duplicate of JDK-8172232. Oh, I wasn't aware that someone from Oracle was working on this. My last information was that Oracle currently doesn't care about linux-sparc. Has this changed now? > Since this is now a community effort/update, perhaps I can offer you the associated patch. If you have already written a patch, why not directly merge it into JDK10? Or is there anything that prevents that from happening? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From patric.hedlin at oracle.com Wed Aug 30 15:48:59 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Wed, 30 Aug 2017 17:48:59 +0200 Subject: [RFR]: 8186579: VM_Version::platform_features() needs update on linux-sparc In-Reply-To: <3e15877b-3d10-86d7-bd98-a5694eb77b0c@physik.fu-berlin.de> References: <6fb8ba09-97db-19a8-0fc5-3e26b6737bdb@oracle.com> <3e15877b-3d10-86d7-bd98-a5694eb77b0c@physik.fu-berlin.de> Message-ID: Hi Paul... Adrian (...sorry, I was in a rush... ;) On 2017-08-30 16:50, John Paul Adrian Glaubitz wrote: > Hi Patric! > > On 08/30/2017 04:46 PM, Patric Hedlin wrote: >> This seems to be a duplicate of JDK-8172232. > > Oh, I wasn't aware that someone from Oracle was working on this. My last > information was that Oracle currently doesn't care about linux-sparc. Has > this changed now? > No. I'm afraid not. But we are still willing to help out. >> Since this is now a community effort/update, perhaps I can offer you >> the associated patch. > If you have already written a patch, why not directly merge it > into JDK10? Or is there anything that prevents that from happening? > There is this little catch around test infrastructure support. We're just a tad reluctant to commit things we cannot fully test on a regular basis. However, if the community (that is officially you now ;) provides some support in keeping the odd bits in shape, we will certainly accept patches and try to help out as best we can. Best regards, Patric > Thanks, > Adrian From glaubitz at physik.fu-berlin.de Wed Aug 30 21:13:05 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 30 Aug 2017 23:13:05 +0200 Subject: [RFR]: 8186579: VM_Version::platform_features() needs update on linux-sparc In-Reply-To: References: <6fb8ba09-97db-19a8-0fc5-3e26b6737bdb@oracle.com> <3e15877b-3d10-86d7-bd98-a5694eb77b0c@physik.fu-berlin.de> Message-ID: <4701db76-6c9e-de48-f800-2091a6fc5fed@physik.fu-berlin.de> On 08/30/2017 05:48 PM, Patric Hedlin wrote: > Hi Paul... Adrian (...sorry, I was in a rush... ;) No worries. You're definitely not the first person to make this mistake :). > On 2017-08-30 16:50, John Paul Adrian Glaubitz wrote: >> On 08/30/2017 04:46 PM, Patric Hedlin wrote: >>> This seems to be a duplicate of JDK-8172232. >> >> Oh, I wasn't aware that someone from Oracle was working on this. My last >> information was that Oracle currently doesn't care about linux-sparc. Has >> this changed now? >> > No. I'm afraid not. But we are still willing to help out. Ok. But is there any foregoing work? You mentioned a patch you can share? >>> Since this is now a community effort/update, perhaps I can offer you the associated patch. >> If you have already written a patch, why not directly merge it >> into JDK10? Or is there anything that prevents that from happening? >> > There is this little catch around test infrastructure support. Well, there is now Oracle Linux for SPARC :-). But, I guess it takes some time. > We're just a tad reluctant to commit things we cannot fully test on a regular > basis. Understandable. > However, if the community (that is officially you now ;) provides some support > in keeping the odd bits in shape, we will certainly accept patches and try to help > out as best we can. Great. Then let's get 8186579 fixed together. We're slowly getting there where the number of patches required to support OpenJDK on all of Debian's architectures is getting to an acceptable level since several patches have already been upstreamed :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From volker.simonis at gmail.com Thu Aug 31 06:54:31 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Aug 2017 08:54:31 +0200 Subject: RFR(M): 8166317: InterpreterCodeSize should be computed Message-ID: Hi, can I please have a review and sponsor for the following change: http://cr.openjdk.java.net/~simonis/webrevs/2017/8166317/ https://bugs.openjdk.java.net/browse/JDK-8166317 The template interpreter is currently created into a compile time constant, fixed sized part of the CodeCache. This constant (i.e. 'TemplateInterpreter::InterpreterCodeSize') is specified per platform in templateInterpreterGenerator_.cpp and may depend on various other compile time configurations like for example JVMCI. Also, this constant is quadrupled for debug builds in order to accommodate for the additional debugging code. The problem with this approach is that we have to 'guess' a good value for 'InterpreterCodeSize'. If the value is too big, we will unnecessarily waste CodeCache because the unused parts of the code cache allocated for the interpreter won't be returned back to the CodeCache. If the value is too small the VM may fail to initialize with "not enough space for interpreter generation". The situation is further complicated by the fact that some dynamic, run-time configuration options like debugging/JVMTI, compressed oops, implicit null checks, etc. may influence the size of the generated interpreter. Currently, the used/wasted ratio for the interpreter part of the code cache (which can be dumped with -XX:+PrintInterpreter) looks as follows for jdk10 on Linux/x86_64: dbg/JVMTI ------------- code size = 475K bytes total space = 1071K bytes wasted space = 596K bytes dbg ------------- code size = 262K bytes total space = 1071K bytes wasted space = 809K bytes opt/JVMTI ------------- code size = 195K bytes total space = 267K bytes wasted space = 72K bytes opt ------------- code size = 124K bytes total space = 267K bytes wasted space = 143K bytes Unfortunately it is not easy to compute the size of the generated interpreter dynamically (we would actually have to generate it two times in order to do that). It is also not easy to create the interpreter into a bigger, temporary buffer and move it into an exactly sized buffer afterwards because the interpreter code is not relocatable (and the assignment of the various entry points is spread out over many code locations). But what we can actually do quite easily is to return the unused part of the initially allocated memory back to the CodeCache. This is possible for two reasons. First, the interpreter codelets and stubs are generated "densely" (see CodeletMark constructor/destructor), i.e. the unused space of the initially allocated memory is located at the end of the reserved memory. Second, te interpreter is generated in a very early stage during VM startup ('interpreter_init()' is called early from 'init_globals()'). During this early stage we're still single threaded and can be sure that nobody else is allocating from the CodeCache while we're generating the interpreter. So I've introduced a new method 'CodeCache::free_unused_tail(CodeBlob* cb, size_t used)' which frees the unused tail of the interpreter CodeBlob. It has a guarantee which makes sure that is only called for the interpreter CodeBlob. 'free_unused_tail()' calls 'CodeHeap::deallocate_tail(void* p, size_t used_size)' on the corresponding CodeHeap which in turn checks (with another guarantee) that there have been no intermediate allocations and returns the unused tail of the corresponding HeapBlock back to the CodeHeap. With this change, theres no more waste in the CodeCache after interpreter generation and the output of -XX:+PrintInterpreter looks as follows: dbg/JVMTI ------------- code size = 475K bytes total space = 475K bytes wasted space = 0K bytes dbg ------------- code size = 262K bytes total space = 262K bytes wasted space = 0K bytes opt/JVMTI ------------- code size = 195K bytes total space = 195K bytes wasted space = 0K bytes opt ------------- code size = 124K bytes total space = 124K bytes wasted space = 0K bytes So in the normal case (product build without debugging) we're saving 143K of CodeCache. While this is not overly impressing I think the major benefit of this change is that we can increase the default value for 'InterpreterCodeSize' in the future without much reasoning (e.g. doubling it if it is too small) because the unused part will be returned back to the CodeCache. I've successfully (with the exception described below) tested the change by running the hotspot JTreg tests with and without SegmentedCodeCache. While working on this, I found another problem which is related to the fix of JDK-8183573 and leads to crashes when executing the JTreg test compiler/codecache/stress/ReturnBlobToWrongHeapTest.java. The problem is that JDK-8183573 replaced virtual bool contains_blob(const CodeBlob* blob) const { return low_boundary() <= (char*) blob && (char*) blob < high(); } by: bool contains_blob(const CodeBlob* blob) const { return contains(blob->code_begin()); } But that my be wrong in the corner case where the size of the CodeBlob's payload is zero (i.e. the CodeBlob consists only of the 'header' - i.e. the C++ object itself) because in that case CodeBlob::code_begin() points right behind the CodeBlob's header which is a memory location which doesn't belong to the CodeBlob anymore. This exact corner case is exercised by ReturnBlobToWrongHeapTest which allocates CodeBlobs of size zero (i.e. zero 'payload') with the help of sun.hotspot.WhiteBox.allocateCodeBlob() until the CodeCache fills up. The test first fills the 'non-profiled nmethods' CodeHeap. If the 'non-profiled nmethods' CodeHeap is full, the VM automatically tries to allocate from the 'profiled nmethods' CodeHeap until that fills up as well. But in the CodeCache the 'profiled nmethods' CodeHeap is located right before the non-profiled nmethods' CodeHeap. So if the last CodeBlob allocated from the 'profiled nmethods' CodeHeap has a payload size of zero and uses all the CodeHeaps remaining size, we will end up with a CodeBlob whose code_begin() address will point right behind the actual CodeHeap (i.e. it will point right at the beginning of the adjacent, 'non-profiled nmethods' CodeHeap). This will result in the following guarantee to fire, when we try to free the last allocated CodeBlob (i.e. the one allocated at the end of the 'profiled nmethods' CodeHeap which has its code_begin() address pointing at the the beginning of the adjacent, 'non-profiled nmethods' CodeHeap) with sun.hotspot.WhiteBox.freeCodeBlob(): # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (heap.cpp:248), pid=27586, tid=27587 # guarantee((char*) b >= _memory.low_boundary() && (char*) b < _memory.high()) failed: The block to be deallocated 0x00007fffe6666f80 is not within the heap starting with 0x00007fffe6667000 and ending with 0x00007fffe6ba000 The fix is trivial so I'll include it into this change: just revert the part of JDK-8183573 mentioned before such that contains_blob() again uses the address of the CodeBlob instead of CodeBlob->code_begin(). Thank you and best regards, Volker From rohitarulraj at gmail.com Thu Aug 31 09:03:02 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Thu, 31 Aug 2017 14:33:02 +0530 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults Message-ID: Hello All, I am Rohit Arul Raj, working at AMD India Pvt Ltd. This is my first contribution to OpenJDK, so please guide me in case I have overlooked any process guidelines. I would like an volunteer to review this patch (openJDK9) which sets flag/ISA defaults for newer AMD 17h (EPYC) processor and help us with the commit process. Webrev: https://www.dropbox.com/sh/08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 I have also attached the patch (hg diff -g) for reference. Note: 1) I have applied for Oracle Contributor Agreement on 30Aug2017. 2) I have applied the changes on top of openJDK9/hotspot: changeset: 12823:b756e7a2ec33 tag: tip user: prr date: Thu Aug 03 18:56:57 2017 +0000 summary: Added tag jdk-9+181 for changeset 4a443796f6f5 3) I have done regression testing using jtreg ($make default) and didnt find any regressions. There was 1 additional failure in the base run (java/util/ServiceLoader/ModulesTest.java), but was not able to reproduce it when I ran the test individually. Base Run: ========== Test results: passed: 4,749; failed: 5; error: 2 Report written to /home/rohit/project/submit/9dev-base/jdk/testoutput/jdk_core/JTreport/html/report.html Results written to /home/rohit/project/submit/9dev-base/jdk/testoutput/jdk_core/JTwork Error: Some tests failed or other problems occurred. Summary: jdk_core FAILED: java/io/BufferedInputStream/CloseStream.java FAILED: java/io/Serializable/unresolvableObjectStreamClass/UnresolvableObjectStreamClass.java FAILED: java/nio/channels/AsyncCloseAndInterrupt.java FAILED: java/util/ServiceLoader/ModulesTest.java FAILED: jdk/internal/reflect/constantPool/ConstantPoolTest.java FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java TEST STATS: name=jdk_core run=4756 pass=4749 fail=7 EXIT CODE: 3 EXIT CODE: 3 ../../test/TestCommon.gmk:398: recipe for target 'jtreg_tests' failed make[2]: *** [jtreg_tests] Error 3 Makefile:43: recipe for target 'jdk_core' failed make[1]: *** [jdk_core] Error 2 Makefile:77: recipe for target 'jdk_core' failed make: *** [jdk_core] Error 2 Patch Run: ========= Test results: passed: 4,750; failed: 4; error: 2 Report written to /home/rohit/project/submit/9dev/jdk/testoutput/jdk_core/JTreport/html/report.html Results written to /home/rohit/project/submit/9dev/jdk/testoutput/jdk_core/JTwork Error: Some tests failed or other problems occurred. Summary: jdk_core FAILED: java/io/BufferedInputStream/CloseStream.java FAILED: java/io/Serializable/unresolvableObjectStreamClass/UnresolvableObjectStreamClass.java FAILED: java/nio/channels/AsyncCloseAndInterrupt.java FAILED: jdk/internal/reflect/constantPool/ConstantPoolTest.java FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java TEST STATS: name=jdk_core run=4756 pass=4750 fail=6 EXIT CODE: 3 EXIT CODE: 3 ../../test/TestCommon.gmk:398: recipe for target 'jtreg_tests' failed make[2]: *** [jtreg_tests] Error 3 Makefile:43: recipe for target 'jdk_core' failed make[1]: *** [jdk_core] Error 2 Makefile:77: recipe for target 'jdk_core' failed make: *** [jdk_core] Error 2 Is there any further testing required? Please let me know your comments. Thanks, Rohit From claes.redestad at oracle.com Thu Aug 31 10:14:07 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 31 Aug 2017 12:14:07 +0200 Subject: RFR(M): 8166317: InterpreterCodeSize should be computed In-Reply-To: References: Message-ID: <50cda0ab-f403-372a-ce51-1a27d8821448@oracle.com> On 2017-08-31 08:54, Volker Simonis wrote: > While working on this, I found another problem which is related to the > fix of JDK-8183573 and leads to crashes when executing the JTreg test > compiler/codecache/stress/ReturnBlobToWrongHeapTest.java. > > The problem is that JDK-8183573 replaced > > virtual bool contains_blob(const CodeBlob* blob) const { return > low_boundary() <= (char*) blob && (char*) blob < high(); } > > by: > > bool contains_blob(const CodeBlob* blob) const { return > contains(blob->code_begin()); } > > But that my be wrong in the corner case where the size of the > CodeBlob's payload is zero (i.e. the CodeBlob consists only of the > 'header' - i.e. the C++ object itself) because in that case > CodeBlob::code_begin() points right behind the CodeBlob's header which > is a memory location which doesn't belong to the CodeBlob anymore. I recall this change was somehow necessary to allow merging AOTCodeHeap::contains_blob and CodeHead::contains_blob into one devirtualized method, so you need to ensure all AOT tests pass with this change (on linux-x64). I can't help to wonder if we'd not be better served by disallowing zero-sized payloads. Is this something that can ever actually happen except by abuse of the white box API? /Claes From david.holmes at oracle.com Thu Aug 31 12:29:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Aug 2017 22:29:04 +1000 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: References: Message-ID: <9016267b-3a6e-b684-4263-2c95b2f630ff@oracle.com> Hi Rohit, On 31/08/2017 7:03 PM, Rohit Arul Raj wrote: > Hello All, > > I am Rohit Arul Raj, working at AMD India Pvt Ltd. > > This is my first contribution to OpenJDK, so please guide me in case I > have overlooked any process guidelines. > I would like an volunteer to review this patch (openJDK9) which sets > flag/ISA defaults for newer AMD 17h (EPYC) processor and help us with > the commit process. > > Webrev: https://www.dropbox.com/sh/08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 Unfortunately patches can not be accepted from systems outside the OpenJDK infrastructure and ... > I have also attached the patch (hg diff -g) for reference. ... unfortunately patches tend to get stripped by the mail servers. If the patch is small please include it inline. Otherwise you will need to find an OpenJDK Author who can host it for you on cr.openjdk.java.net. > Note: > 1) I have applied for Oracle Contributor Agreement on 30Aug2017. Great! Welcome! > 2) I have applied the changes on top of openJDK9/hotspot: You will need to rebase to jdk10/hs/hotspot. JDK 9 is in the final stages of release. > changeset: 12823:b756e7a2ec33 > tag: tip > user: prr > date: Thu Aug 03 18:56:57 2017 +0000 > summary: Added tag jdk-9+181 for changeset 4a443796f6f5 > > 3) I have done regression testing using jtreg ($make default) and > didnt find any regressions. Sounds good, but until I see the patch it is hard to comment on testing requirements. Thanks, David ----- > There was 1 additional failure in the base run > (java/util/ServiceLoader/ModulesTest.java), but was not able to > reproduce it when I ran the test individually. > > Base Run: > ========== > Test results: passed: 4,749; failed: 5; error: 2 > Report written to > /home/rohit/project/submit/9dev-base/jdk/testoutput/jdk_core/JTreport/html/report.html > Results written to > /home/rohit/project/submit/9dev-base/jdk/testoutput/jdk_core/JTwork > Error: Some tests failed or other problems occurred. > Summary: jdk_core > FAILED: java/io/BufferedInputStream/CloseStream.java > FAILED: java/io/Serializable/unresolvableObjectStreamClass/UnresolvableObjectStreamClass.java > FAILED: java/nio/channels/AsyncCloseAndInterrupt.java > FAILED: java/util/ServiceLoader/ModulesTest.java > FAILED: jdk/internal/reflect/constantPool/ConstantPoolTest.java > FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java > FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java > TEST STATS: name=jdk_core run=4756 pass=4749 fail=7 > EXIT CODE: 3 > EXIT CODE: 3 > ../../test/TestCommon.gmk:398: recipe for target 'jtreg_tests' failed > make[2]: *** [jtreg_tests] Error 3 > Makefile:43: recipe for target 'jdk_core' failed > make[1]: *** [jdk_core] Error 2 > Makefile:77: recipe for target 'jdk_core' failed > make: *** [jdk_core] Error 2 > > Patch Run: > ========= > Test results: passed: 4,750; failed: 4; error: 2 > Report written to > /home/rohit/project/submit/9dev/jdk/testoutput/jdk_core/JTreport/html/report.html > Results written to > /home/rohit/project/submit/9dev/jdk/testoutput/jdk_core/JTwork > Error: Some tests failed or other problems occurred. > Summary: jdk_core > FAILED: java/io/BufferedInputStream/CloseStream.java > FAILED: > java/io/Serializable/unresolvableObjectStreamClass/UnresolvableObjectStreamClass.java > FAILED: java/nio/channels/AsyncCloseAndInterrupt.java > FAILED: jdk/internal/reflect/constantPool/ConstantPoolTest.java > FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java > FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java > TEST STATS: name=jdk_core run=4756 pass=4750 fail=6 > EXIT CODE: 3 > EXIT CODE: 3 > ../../test/TestCommon.gmk:398: recipe for target 'jtreg_tests' failed > make[2]: *** [jtreg_tests] Error 3 > Makefile:43: recipe for target 'jdk_core' failed > make[1]: *** [jdk_core] Error 2 > Makefile:77: recipe for target 'jdk_core' failed > make: *** [jdk_core] Error 2 > > Is there any further testing required? > > Please let me know your comments. > > Thanks, > Rohit > From coleen.phillimore at oracle.com Thu Aug 31 12:35:34 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 31 Aug 2017 08:35:34 -0400 Subject: RFR(M): 8166317: InterpreterCodeSize should be computed In-Reply-To: References: Message-ID: <2652bdeb-3986-2b8e-234a-6fde83e00cdb@oracle.com> Hi Volker, Thank you for doing this.? I will review this and sponsor it. Unfortunately the jdk10/hs repository is going to be closed for a few weeks while the consolidation effort is taking place, but that should give plenty of time for reviews. thanks, Coleen On 8/31/17 2:54 AM, Volker Simonis wrote: > Hi, > > can I please have a review and sponsor for the following change: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8166317/ > https://bugs.openjdk.java.net/browse/JDK-8166317 > > The template interpreter is currently created into a compile time > constant, fixed sized part of the CodeCache. This constant (i.e. > 'TemplateInterpreter::InterpreterCodeSize') is specified per platform > in templateInterpreterGenerator_.cpp and may depend on various > other compile time configurations like for example JVMCI. Also, this > constant is quadrupled for debug builds in order to accommodate for > the additional debugging code. > > The problem with this approach is that we have to 'guess' a good value > for 'InterpreterCodeSize'. If the value is too big, we will > unnecessarily waste CodeCache because the unused parts of the code > cache allocated for the interpreter won't be returned back to the > CodeCache. If the value is too small the VM may fail to initialize > with "not enough space for interpreter generation". The situation is > further complicated by the fact that some dynamic, run-time > configuration options like debugging/JVMTI, compressed oops, implicit > null checks, etc. may influence the size of the generated interpreter. > > Currently, the used/wasted ratio for the interpreter part of the code > cache (which can be dumped with -XX:+PrintInterpreter) looks as > follows for jdk10 on Linux/x86_64: > > dbg/JVMTI > ------------- > code size = 475K bytes > total space = 1071K bytes > wasted space = 596K bytes > > dbg > ------------- > code size = 262K bytes > total space = 1071K bytes > wasted space = 809K bytes > > opt/JVMTI > ------------- > code size = 195K bytes > total space = 267K bytes > wasted space = 72K bytes > > opt > ------------- > code size = 124K bytes > total space = 267K bytes > wasted space = 143K bytes > > Unfortunately it is not easy to compute the size of the generated > interpreter dynamically (we would actually have to generate it two > times in order to do that). It is also not easy to create the > interpreter into a bigger, temporary buffer and move it into an > exactly sized buffer afterwards because the interpreter code is not > relocatable (and the assignment of the various entry points is spread > out over many code locations). > > But what we can actually do quite easily is to return the unused part > of the initially allocated memory back to the CodeCache. This is > possible for two reasons. First, the interpreter codelets and stubs > are generated "densely" (see CodeletMark constructor/destructor), i.e. > the unused space of the initially allocated memory is located at the > end of the reserved memory. Second, te interpreter is generated in a > very early stage during VM startup ('interpreter_init()' is called > early from 'init_globals()'). During this early stage we're still > single threaded and can be sure that nobody else is allocating from > the CodeCache while we're generating the interpreter. > > So I've introduced a new method 'CodeCache::free_unused_tail(CodeBlob* > cb, size_t used)' which frees the unused tail of the interpreter > CodeBlob. It has a guarantee which makes sure that is only called for > the interpreter CodeBlob. 'free_unused_tail()' calls > 'CodeHeap::deallocate_tail(void* p, size_t used_size)' on the > corresponding CodeHeap which in turn checks (with another guarantee) > that there have been no intermediate allocations and returns the > unused tail of the corresponding HeapBlock back to the CodeHeap. > > With this change, theres no more waste in the CodeCache after > interpreter generation and the output of -XX:+PrintInterpreter looks > as follows: > > dbg/JVMTI > ------------- > code size = 475K bytes > total space = 475K bytes > wasted space = 0K bytes > > dbg > ------------- > code size = 262K bytes > total space = 262K bytes > wasted space = 0K bytes > > opt/JVMTI > ------------- > code size = 195K bytes > total space = 195K bytes > wasted space = 0K bytes > > opt > ------------- > code size = 124K bytes > total space = 124K bytes > wasted space = 0K bytes > > So in the normal case (product build without debugging) we're saving > 143K of CodeCache. While this is not overly impressing I think the > major benefit of this change is that we can increase the default value > for 'InterpreterCodeSize' in the future without much reasoning (e.g. > doubling it if it is too small) because the unused part will be > returned back to the CodeCache. > > I've successfully (with the exception described below) tested the > change by running the hotspot JTreg tests with and without > SegmentedCodeCache. > > While working on this, I found another problem which is related to the > fix of JDK-8183573 and leads to crashes when executing the JTreg test > compiler/codecache/stress/ReturnBlobToWrongHeapTest.java. > > The problem is that JDK-8183573 replaced > > virtual bool contains_blob(const CodeBlob* blob) const { return > low_boundary() <= (char*) blob && (char*) blob < high(); } > > by: > > bool contains_blob(const CodeBlob* blob) const { return > contains(blob->code_begin()); } > > But that my be wrong in the corner case where the size of the > CodeBlob's payload is zero (i.e. the CodeBlob consists only of the > 'header' - i.e. the C++ object itself) because in that case > CodeBlob::code_begin() points right behind the CodeBlob's header which > is a memory location which doesn't belong to the CodeBlob anymore. > > This exact corner case is exercised by ReturnBlobToWrongHeapTest which > allocates CodeBlobs of size zero (i.e. zero 'payload') with the help > of sun.hotspot.WhiteBox.allocateCodeBlob() until the CodeCache fills > up. The test first fills the 'non-profiled nmethods' CodeHeap. If the > 'non-profiled nmethods' CodeHeap is full, the VM automatically tries > to allocate from the 'profiled nmethods' CodeHeap until that fills up > as well. But in the CodeCache the 'profiled nmethods' CodeHeap is > located right before the non-profiled nmethods' CodeHeap. So if the > last CodeBlob allocated from the 'profiled nmethods' CodeHeap has a > payload size of zero and uses all the CodeHeaps remaining size, we > will end up with a CodeBlob whose code_begin() address will point > right behind the actual CodeHeap (i.e. it will point right at the > beginning of the adjacent, 'non-profiled nmethods' CodeHeap). This > will result in the following guarantee to fire, when we try to free > the last allocated CodeBlob (i.e. the one allocated at the end of the > 'profiled nmethods' CodeHeap which has its code_begin() address > pointing at the the beginning of the adjacent, 'non-profiled nmethods' > CodeHeap) with sun.hotspot.WhiteBox.freeCodeBlob(): > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (heap.cpp:248), pid=27586, tid=27587 > # guarantee((char*) b >= _memory.low_boundary() && (char*) b < > _memory.high()) failed: The block to be deallocated 0x00007fffe6666f80 > is not within the heap starting with 0x00007fffe6667000 and ending > with 0x00007fffe6ba000 > > The fix is trivial so I'll include it into this change: just revert > the part of JDK-8183573 mentioned before such that contains_blob() > again uses the address of the CodeBlob instead of > CodeBlob->code_begin(). > > Thank you and best regards, > Volker From volker.simonis at gmail.com Thu Aug 31 12:43:12 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Aug 2017 14:43:12 +0200 Subject: RFR(M): 8166317: InterpreterCodeSize should be computed In-Reply-To: <50cda0ab-f403-372a-ce51-1a27d8821448@oracle.com> References: <50cda0ab-f403-372a-ce51-1a27d8821448@oracle.com> Message-ID: On Thu, Aug 31, 2017 at 12:14 PM, Claes Redestad wrote: > > > On 2017-08-31 08:54, Volker Simonis wrote: >> >> While working on this, I found another problem which is related to the >> fix of JDK-8183573 and leads to crashes when executing the JTreg test >> compiler/codecache/stress/ReturnBlobToWrongHeapTest.java. >> >> The problem is that JDK-8183573 replaced >> >> virtual bool contains_blob(const CodeBlob* blob) const { return >> low_boundary() <= (char*) blob && (char*) blob < high(); } >> >> by: >> >> bool contains_blob(const CodeBlob* blob) const { return >> contains(blob->code_begin()); } >> >> But that my be wrong in the corner case where the size of the >> CodeBlob's payload is zero (i.e. the CodeBlob consists only of the >> 'header' - i.e. the C++ object itself) because in that case >> CodeBlob::code_begin() points right behind the CodeBlob's header which >> is a memory location which doesn't belong to the CodeBlob anymore. > > > I recall this change was somehow necessary to allow merging > AOTCodeHeap::contains_blob and CodeHead::contains_blob into > one devirtualized method, so you need to ensure all AOT tests > pass with this change (on linux-x64). > All of hotspot/test/aot and hotspot/test/jvmci executed and passed successful. Are there any other tests I should check? That said, it is a little hard to follow the stages of your change. It seems like http://cr.openjdk.java.net/~redestad/scratch/codeheap_contains.00/ was reviewed [1] but then finally the slightly changed version from http://cr.openjdk.java.net/~redestad/scratch/codeheap_contains.01/ was checked in and linked to the bug report. The first, reviewed version of the change still had a correct version of 'CodeHeap::contains_blob(const CodeBlob* blob)' while the second, checked in version has the faulty version of that method. I don't know why you finally did that change to 'contains_blob()' but I don't see any reason why we shouldn't be able to directly use the blob's address for inclusion checking. From what I understand, it should ALWAYS be contained in the corresponding CodeHeap so no reason to mess with 'CodeBlob::code_begin()'. Please let me know if I'm missing something. [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-July/026624.html > I can't help to wonder if we'd not be better served by disallowing > zero-sized payloads. Is this something that can ever actually > happen except by abuse of the white box API? > The corresponding test (ReturnBlobToWrongHeapTest.java) specifically wants to allocate "segment sized" blocks which is most easily achieved by allocation zero-sized CodeBlobs. And I think there's nothing wrong about it if we handle the inclusion tests correctly. Thank you and best regards, Volker > /Claes From erik.osterlund at oracle.com Thu Aug 31 12:45:44 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 31 Aug 2017 14:45:44 +0200 Subject: RFR: 8186838: Generalize Atomic::inc/dec with templates Message-ID: <59A804F8.9000501@oracle.com> Hi everyone, Bug ID: https://bugs.openjdk.java.net/browse/JDK-8186838 Webrev: http://cr.openjdk.java.net/~eosterlund/8186838/webrev.00/ The time has come for the next step in generalizing Atomic with templates. Today I will focus on Atomic::inc/dec. I have tried to mimic the new Kim style that seems to have been universally accepted. Like Atomic::add and Atomic::cmpxchg, the structure looks like this: Layer 1) Atomic::inc/dec calls an IncImpl()/DecImpl() function object that performs some basic type checks. Layer 2) IncImpl/DecImpl calls PlatformInc/PlatformDec that can define the operation arbitrarily for a given platform. The default implementation if not specialized for a platform is to call Atomic::add. So only platforms that want to do something different than that as an optimization have to provide a specialization. Layer 3) Platforms that decide to specialize PlatformInc/PlatformDec to be more optimized may inherit from a helper class IncUsingConstant/DecUsingConstant. This helper helps performing the necessary computation what the increment/decrement should be after pointer scaling using CRTP. The PlatformInc/PlatformDec operation then only needs to define an inc/dec member function, and will then get all the context information necessary to generate a more optimized implementation. Easy peasy. It is worth noticing that the generalized Atomic::dec operation assumes a two's complement integer machine and potentially sends the unary negative of a potentially unsigned type to Atomic::add. I have the following comments about this: 1) We already assume in other code that two's complement integers must be present. 2) A machine that does not have two's complement integers may still simply provide a specialization that solves the problem in a different way. 3) The alternative that does not make assumptions about that would use the good old IntegerTypes::cast_to_signed metaprogramming stuff, and I seem to recall we thought that was a bit too involved and complicated. This is the reason why I have chosen to use unary minus on the potentially unsigned type in the shared helper code that sends the decrement as an addend to Atomic::add. It would also be nice if somebody with access to PPC and s390 machines could try out the relevant changes there so I do not accidentally break those platforms. I have blind-coded the addition of the immediate values passed in to the inline assembly in a way that I think looks like it should work. Testing: RBT hs-tier3, JPRT --testset hotspot Thanks, /Erik From volker.simonis at gmail.com Thu Aug 31 12:59:53 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Aug 2017 14:59:53 +0200 Subject: 8186982: [aix] Garbage output for CPU info in hs-err file In-Reply-To: References: Message-ID: Looks good! Thanks for cleaning this up, Volker On Thu, Aug 31, 2017 at 2:20 PM, Thomas St?fe wrote: > Hi, > > may I please have reviews for this tiny trivial change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186982 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8186982-aix-cpu-info-garbage/webrev.00/webrev/ > > Thank you! > > ..Thomas From thomas.stuefe at gmail.com Thu Aug 31 13:13:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Aug 2017 15:13:03 +0200 Subject: ThreadStackSize includes VM guard pages? Message-ID: Hi all, sorry if this question has already been discussed before. The thread stack size used when creating threads is determined from -Xss/ThreadStackSize resp. the stacksize constructor argument. The various VM guard pages (red, yellow etc) are taken from that size, right? So the usable stack size is ThreadStackSize minus size-of-VM-guard-pages? If that is true, do we want to change this at some point? It is confusing and hurts on platforms where page sizes are larger (e.g. 64K paged stacks on ppc64). I understand that changing this behavior to one where the VM guard areas would come atop of ThreadStackSize would be an incompatible change, because it would suddenly drive up memory consumption of systems which are configured to run smoothly with the old behavior. But for a new java release this could be tolerated, or? Kind Regards, Thomas From thomas.stuefe at gmail.com Thu Aug 31 13:13:18 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Aug 2017 15:13:18 +0200 Subject: 8186982: [aix] Garbage output for CPU info in hs-err file In-Reply-To: References: Message-ID: Thank you Volker! On Thu, Aug 31, 2017 at 2:59 PM, Volker Simonis wrote: > Looks good! > > Thanks for cleaning this up, > Volker > > > On Thu, Aug 31, 2017 at 2:20 PM, Thomas St?fe > wrote: > > Hi, > > > > may I please have reviews for this tiny trivial change: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186982 > > Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8186982-aix- > cpu-info-garbage/webrev.00/webrev/ > > > > Thank you! > > > > ..Thomas > From volker.simonis at gmail.com Thu Aug 31 13:34:46 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Aug 2017 15:34:46 +0200 Subject: RFR(xs): 8187028: [aix] Real thread stack size may be up to 64K smaller than requested one In-Reply-To: References: Message-ID: Hi Thomas, it would be of course interesting to know the real reason for this behavior. Maybe that could be used to predict the variation and fix it more accurately. But for the time being, your fix is acceptable so you can consider it reviewed. Thanks for fixing this, Volker On Thu, Aug 31, 2017 at 12:08 PM, Thomas St?fe wrote: > Hi all, > > please review this change: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8187028 > > change: > http://cr.openjdk.java.net/~stuefe/webrevs/8187028-aix-Real-thread-stack-size-may-be-up-to-64K-smaller-than-requested-one/webrev.00/webrev/ > > The issue is that on AIX, pthread library seems to have a bug where it > sometimes gives us less thread stack space than we requested (a variable > amount, but seems to be 0..64K). This may cause intermittent stack overflow > errors if the stacks are very small to begin with. > > The workaround is to add 64K to the requested stack size to account for the > fact that the OS may give us up to 64K less stack. > > Also, improved logging. > > Thanks, Thomas From rohitarulraj at gmail.com Thu Aug 31 15:11:49 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Thu, 31 Aug 2017 20:41:49 +0530 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: <9016267b-3a6e-b684-4263-2c95b2f630ff@oracle.com> References: <9016267b-3a6e-b684-4263-2c95b2f630ff@oracle.com> Message-ID: On Thu, Aug 31, 2017 at 5:59 PM, David Holmes wrote: > Hi Rohit, > > On 31/08/2017 7:03 PM, Rohit Arul Raj wrote: >> >> I would like an volunteer to review this patch (openJDK9) which sets >> flag/ISA defaults for newer AMD 17h (EPYC) processor and help us with >> the commit process. >> >> Webrev: >> https://www.dropbox.com/sh/08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 > > > Unfortunately patches can not be accepted from systems outside the OpenJDK > infrastructure and ... > >> I have also attached the patch (hg diff -g) for reference. > > > ... unfortunately patches tend to get stripped by the mail servers. If the > patch is small please include it inline. Otherwise you will need to find an > OpenJDK Author who can host it for you on cr.openjdk.java.net. > >> 3) I have done regression testing using jtreg ($make default) and >> didnt find any regressions. > > > Sounds good, but until I see the patch it is hard to comment on testing > requirements. > > Thanks, > David Thanks David, Yes, it's a small patch. diff --git a/src/cpu/x86/vm/vm_version_x86.cpp b/src/cpu/x86/vm/vm_version_x86.cpp --- a/src/cpu/x86/vm/vm_version_x86.cpp +++ b/src/cpu/x86/vm/vm_version_x86.cpp @@ -1051,6 +1051,22 @@ } FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); } + if (supports_sha()) { + if (FLAG_IS_DEFAULT(UseSHA)) { + FLAG_SET_DEFAULT(UseSHA, true); + } + } else if (UseSHA || UseSHA1Intrinsics || UseSHA256Intrinsics || UseSHA512Intrinsics) { + if (!FLAG_IS_DEFAULT(UseSHA) || + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { + warning("SHA instructions are not available on this CPU"); + } + FLAG_SET_DEFAULT(UseSHA, false); + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); + } // some defaults for AMD family 15h if ( cpu_family() == 0x15 ) { @@ -1072,11 +1088,43 @@ } #ifdef COMPILER2 - if (MaxVectorSize > 16) { - // Limit vectors size to 16 bytes on current AMD cpus. + if (cpu_family() < 0x17 && MaxVectorSize > 16) { + // Limit vectors size to 16 bytes on AMD cpus < 17h. FLAG_SET_DEFAULT(MaxVectorSize, 16); } #endif // COMPILER2 + + // Some defaults for AMD family 17h + if ( cpu_family() == 0x17 ) { + // On family 17h processors use XMM and UnalignedLoadStores for Array Copy + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { + UseXMMForArrayCopy = true; + } + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { + UseUnalignedLoadStores = true; + } + if (supports_bmi2() && FLAG_IS_DEFAULT(UseBMI2Instructions)) { + UseBMI2Instructions = true; + } + if (MaxVectorSize > 32) { + FLAG_SET_DEFAULT(MaxVectorSize, 32); + } + if (UseSHA) { + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); + } else if (UseSHA512Intrinsics) { + warning("Intrinsics for SHA-384 and SHA-512 crypto hash functions not available on this CPU."); + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); + } + } +#ifdef COMPILER2 + if (supports_sse4_2()) { + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { + FLAG_SET_DEFAULT(UseFPUForSpilling, true); + } + } +#endif + } } if( is_intel() ) { // Intel cpus specific settings diff --git a/src/cpu/x86/vm/vm_version_x86.hpp b/src/cpu/x86/vm/vm_version_x86.hpp --- a/src/cpu/x86/vm/vm_version_x86.hpp +++ b/src/cpu/x86/vm/vm_version_x86.hpp @@ -513,6 +513,16 @@ result |= CPU_LZCNT; if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != 0) result |= CPU_SSE4A; + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) + result |= CPU_BMI2; + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) + result |= CPU_HT; + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) + result |= CPU_ADX; + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) + result |= CPU_SHA; + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) + result |= CPU_FMA; } // Intel features. if(is_intel()) { Regards, Rohit From coleen.phillimore at oracle.com Thu Aug 31 16:02:37 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 31 Aug 2017 12:02:37 -0400 Subject: RFR (S) 8081323: ConstantPool::_resolved_references is missing in heap dump Message-ID: <915c3300-2528-2b85-2492-0b54a783c622@oracle.com> Summary: Add resolved_references and init_lock as hidden static field in class so root is found. Tested manually with YourKit.? See bug for images.?? Also ran serviceability tests. open webrev at http://cr.openjdk.java.net/~coleenp/8081323.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8081323 Thanks, Coleen From vladimir.kozlov at oracle.com Thu Aug 31 16:05:12 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Aug 2017 09:05:12 -0700 Subject: RFR(M): 8166317: InterpreterCodeSize should be computed In-Reply-To: References: <50cda0ab-f403-372a-ce51-1a27d8821448@oracle.com> Message-ID: Very good change. Thank you, Volker. About contains_blob(). The problem is that AOTCompiledMethod allocated in CHeap and not in aot code section (which is RO): http://hg.openjdk.java.net/jdk10/hs/hotspot/file/8acd232fb52a/src/share/vm/aot/aotCompiledMethod.hpp#l124 It is allocated in CHeap after AOT library is loaded. Its code_begin() points to AOT code section but AOTCompiledMethod* points outside it (to normal malloced space) so you can't use (char*)blob address. There are 2 ways to fix it, I think. One is to add new field to CodeBlobLayout and set it to blob* address for normal CodeCache blobs and to code_begin for AOT code. Second is to use contains(blob->code_end() - 1) assuming that AOT code is never zero. Thanks, Vladimir On 8/31/17 5:43 AM, Volker Simonis wrote: > On Thu, Aug 31, 2017 at 12:14 PM, Claes Redestad > wrote: >> >> >> On 2017-08-31 08:54, Volker Simonis wrote: >>> >>> While working on this, I found another problem which is related to the >>> fix of JDK-8183573 and leads to crashes when executing the JTreg test >>> compiler/codecache/stress/ReturnBlobToWrongHeapTest.java. >>> >>> The problem is that JDK-8183573 replaced >>> >>> virtual bool contains_blob(const CodeBlob* blob) const { return >>> low_boundary() <= (char*) blob && (char*) blob < high(); } >>> >>> by: >>> >>> bool contains_blob(const CodeBlob* blob) const { return >>> contains(blob->code_begin()); } >>> >>> But that my be wrong in the corner case where the size of the >>> CodeBlob's payload is zero (i.e. the CodeBlob consists only of the >>> 'header' - i.e. the C++ object itself) because in that case >>> CodeBlob::code_begin() points right behind the CodeBlob's header which >>> is a memory location which doesn't belong to the CodeBlob anymore. >> >> >> I recall this change was somehow necessary to allow merging >> AOTCodeHeap::contains_blob and CodeHead::contains_blob into >> one devirtualized method, so you need to ensure all AOT tests >> pass with this change (on linux-x64). >> > > All of hotspot/test/aot and hotspot/test/jvmci executed and passed > successful. Are there any other tests I should check? > > That said, it is a little hard to follow the stages of your change. It > seems like http://cr.openjdk.java.net/~redestad/scratch/codeheap_contains.00/ > was reviewed [1] but then finally the slightly changed version from > http://cr.openjdk.java.net/~redestad/scratch/codeheap_contains.01/ was > checked in and linked to the bug report. > > The first, reviewed version of the change still had a correct version > of 'CodeHeap::contains_blob(const CodeBlob* blob)' while the second, > checked in version has the faulty version of that method. > > I don't know why you finally did that change to 'contains_blob()' but > I don't see any reason why we shouldn't be able to directly use the > blob's address for inclusion checking. From what I understand, it > should ALWAYS be contained in the corresponding CodeHeap so no reason > to mess with 'CodeBlob::code_begin()'. > > Please let me know if I'm missing something. > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-July/026624.html > >> I can't help to wonder if we'd not be better served by disallowing >> zero-sized payloads. Is this something that can ever actually >> happen except by abuse of the white box API? >> > > The corresponding test (ReturnBlobToWrongHeapTest.java) specifically > wants to allocate "segment sized" blocks which is most easily achieved > by allocation zero-sized CodeBlobs. And I think there's nothing wrong > about it if we handle the inclusion tests correctly. > > Thank you and best regards, > Volker > >> /Claes From volker.simonis at gmail.com Thu Aug 31 16:35:41 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Aug 2017 18:35:41 +0200 Subject: RFR(M): 8166317: InterpreterCodeSize should be computed In-Reply-To: References: <50cda0ab-f403-372a-ce51-1a27d8821448@oracle.com> Message-ID: On Thu, Aug 31, 2017 at 6:05 PM, Vladimir Kozlov wrote: > Very good change. Thank you, Volker. > > About contains_blob(). The problem is that AOTCompiledMethod allocated in > CHeap and not in aot code section (which is RO): > > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/8acd232fb52a/src/share/vm/aot/aotCompiledMethod.hpp#l124 > > It is allocated in CHeap after AOT library is loaded. Its code_begin() > points to AOT code section but AOTCompiledMethod* points outside it (to > normal malloced space) so you can't use (char*)blob address. > Thanks for the explanation - now I got it. > There are 2 ways to fix it, I think. > One is to add new field to CodeBlobLayout and set it to blob* address for > normal CodeCache blobs and to code_begin for AOT code. > Second is to use contains(blob->code_end() - 1) assuming that AOT code is > never zero. > I'll give it a try tomorrow and will send out a new webrev. Regards, Volker > Thanks, > Vladimir > > > On 8/31/17 5:43 AM, Volker Simonis wrote: >> >> On Thu, Aug 31, 2017 at 12:14 PM, Claes Redestad >> wrote: >>> >>> >>> >>> On 2017-08-31 08:54, Volker Simonis wrote: >>>> >>>> >>>> While working on this, I found another problem which is related to the >>>> fix of JDK-8183573 and leads to crashes when executing the JTreg test >>>> compiler/codecache/stress/ReturnBlobToWrongHeapTest.java. >>>> >>>> The problem is that JDK-8183573 replaced >>>> >>>> virtual bool contains_blob(const CodeBlob* blob) const { return >>>> low_boundary() <= (char*) blob && (char*) blob < high(); } >>>> >>>> by: >>>> >>>> bool contains_blob(const CodeBlob* blob) const { return >>>> contains(blob->code_begin()); } >>>> >>>> But that my be wrong in the corner case where the size of the >>>> CodeBlob's payload is zero (i.e. the CodeBlob consists only of the >>>> 'header' - i.e. the C++ object itself) because in that case >>>> CodeBlob::code_begin() points right behind the CodeBlob's header which >>>> is a memory location which doesn't belong to the CodeBlob anymore. >>> >>> >>> >>> I recall this change was somehow necessary to allow merging >>> AOTCodeHeap::contains_blob and CodeHead::contains_blob into >>> one devirtualized method, so you need to ensure all AOT tests >>> pass with this change (on linux-x64). >>> >> >> All of hotspot/test/aot and hotspot/test/jvmci executed and passed >> successful. Are there any other tests I should check? >> >> That said, it is a little hard to follow the stages of your change. It >> seems like >> http://cr.openjdk.java.net/~redestad/scratch/codeheap_contains.00/ >> was reviewed [1] but then finally the slightly changed version from >> http://cr.openjdk.java.net/~redestad/scratch/codeheap_contains.01/ was >> checked in and linked to the bug report. >> >> The first, reviewed version of the change still had a correct version >> of 'CodeHeap::contains_blob(const CodeBlob* blob)' while the second, >> checked in version has the faulty version of that method. >> >> I don't know why you finally did that change to 'contains_blob()' but >> I don't see any reason why we shouldn't be able to directly use the >> blob's address for inclusion checking. From what I understand, it >> should ALWAYS be contained in the corresponding CodeHeap so no reason >> to mess with 'CodeBlob::code_begin()'. >> >> Please let me know if I'm missing something. >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-July/026624.html >> >>> I can't help to wonder if we'd not be better served by disallowing >>> zero-sized payloads. Is this something that can ever actually >>> happen except by abuse of the white box API? >>> >> >> The corresponding test (ReturnBlobToWrongHeapTest.java) specifically >> wants to allocate "segment sized" blocks which is most easily achieved >> by allocation zero-sized CodeBlobs. And I think there's nothing wrong >> about it if we handle the inclusion tests correctly. >> >> Thank you and best regards, >> Volker >> >>> /Claes From thomas.stuefe at gmail.com Thu Aug 31 17:02:54 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Aug 2017 19:02:54 +0200 Subject: RFR(xs): 8187028: [aix] Real thread stack size may be up to 64K smaller than requested one In-Reply-To: References: Message-ID: Thank you Volker. On Thu, Aug 31, 2017 at 3:34 PM, Volker Simonis wrote: > Hi Thomas, > > it would be of course interesting to know the real reason for this > behavior. Maybe that could be used to predict the variation and fix > it more accurately. > > But for the time being, your fix is acceptable so you can consider it > reviewed. > > Thanks for fixing this, > Volker > > On Thu, Aug 31, 2017 at 12:08 PM, Thomas St?fe > wrote: > > Hi all, > > > > please review this change: > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8187028 > > > > change: > > http://cr.openjdk.java.net/~stuefe/webrevs/8187028-aix- > Real-thread-stack-size-may-be-up-to-64K-smaller-than- > requested-one/webrev.00/webrev/ > > > > The issue is that on AIX, pthread library seems to have a bug where it > > sometimes gives us less thread stack space than we requested (a variable > > amount, but seems to be 0..64K). This may cause intermittent stack > overflow > > errors if the stacks are very small to begin with. > > > > The workaround is to add 64K to the requested stack size to account for > the > > fact that the OS may give us up to 64K less stack. > > > > Also, improved logging. > > > > Thanks, Thomas > From david.holmes at oracle.com Thu Aug 31 21:31:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Sep 2017 07:31:11 +1000 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: References: <9016267b-3a6e-b684-4263-2c95b2f630ff@oracle.com> Message-ID: Hi Rohit, I think the patch needs updating for jdk10 as I already see a lot of logic around UseSHA in vm_version_x86.cpp. Thanks, David On 1/09/2017 1:11 AM, Rohit Arul Raj wrote: > On Thu, Aug 31, 2017 at 5:59 PM, David Holmes wrote: >> Hi Rohit, >> >> On 31/08/2017 7:03 PM, Rohit Arul Raj wrote: >>> >>> I would like an volunteer to review this patch (openJDK9) which sets >>> flag/ISA defaults for newer AMD 17h (EPYC) processor and help us with >>> the commit process. >>> >>> Webrev: >>> https://www.dropbox.com/sh/08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 >> >> >> Unfortunately patches can not be accepted from systems outside the OpenJDK >> infrastructure and ... >> >>> I have also attached the patch (hg diff -g) for reference. >> >> >> ... unfortunately patches tend to get stripped by the mail servers. If the >> patch is small please include it inline. Otherwise you will need to find an >> OpenJDK Author who can host it for you on cr.openjdk.java.net. >> > >>> 3) I have done regression testing using jtreg ($make default) and >>> didnt find any regressions. >> >> >> Sounds good, but until I see the patch it is hard to comment on testing >> requirements. >> >> Thanks, >> David > > Thanks David, > Yes, it's a small patch. > > diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > b/src/cpu/x86/vm/vm_version_x86.cpp > --- a/src/cpu/x86/vm/vm_version_x86.cpp > +++ b/src/cpu/x86/vm/vm_version_x86.cpp > @@ -1051,6 +1051,22 @@ > } > FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > } > + if (supports_sha()) { > + if (FLAG_IS_DEFAULT(UseSHA)) { > + FLAG_SET_DEFAULT(UseSHA, true); > + } > + } else if (UseSHA || UseSHA1Intrinsics || UseSHA256Intrinsics || > UseSHA512Intrinsics) { > + if (!FLAG_IS_DEFAULT(UseSHA) || > + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || > + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || > + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > + warning("SHA instructions are not available on this CPU"); > + } > + FLAG_SET_DEFAULT(UseSHA, false); > + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); > + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); > + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > + } > > // some defaults for AMD family 15h > if ( cpu_family() == 0x15 ) { > @@ -1072,11 +1088,43 @@ > } > > #ifdef COMPILER2 > - if (MaxVectorSize > 16) { > - // Limit vectors size to 16 bytes on current AMD cpus. > + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > + // Limit vectors size to 16 bytes on AMD cpus < 17h. > FLAG_SET_DEFAULT(MaxVectorSize, 16); > } > #endif // COMPILER2 > + > + // Some defaults for AMD family 17h > + if ( cpu_family() == 0x17 ) { > + // On family 17h processors use XMM and UnalignedLoadStores for > Array Copy > + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + UseXMMForArrayCopy = true; > + } > + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + UseUnalignedLoadStores = true; > + } > + if (supports_bmi2() && FLAG_IS_DEFAULT(UseBMI2Instructions)) { > + UseBMI2Instructions = true; > + } > + if (MaxVectorSize > 32) { > + FLAG_SET_DEFAULT(MaxVectorSize, 32); > + } > + if (UseSHA) { > + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > + } else if (UseSHA512Intrinsics) { > + warning("Intrinsics for SHA-384 and SHA-512 crypto hash > functions not available on this CPU."); > + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > + } > + } > +#ifdef COMPILER2 > + if (supports_sse4_2()) { > + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > + } > +#endif > + } > } > > if( is_intel() ) { // Intel cpus specific settings > diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > b/src/cpu/x86/vm/vm_version_x86.hpp > --- a/src/cpu/x86/vm/vm_version_x86.hpp > +++ b/src/cpu/x86/vm/vm_version_x86.hpp > @@ -513,6 +513,16 @@ > result |= CPU_LZCNT; > if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != 0) > result |= CPU_SSE4A; > + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > + result |= CPU_BMI2; > + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) > + result |= CPU_HT; > + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > + result |= CPU_ADX; > + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > + result |= CPU_SHA; > + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > + result |= CPU_FMA; > } > // Intel features. > if(is_intel()) { > > Regards, > Rohit > From david.holmes at oracle.com Thu Aug 31 21:35:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Sep 2017 07:35:07 +1000 Subject: ThreadStackSize includes VM guard pages? In-Reply-To: References: Message-ID: Hi Thomas, On 31/08/2017 11:13 PM, Thomas St?fe wrote: > Hi all, > > sorry if this question has already been discussed before. > > The thread stack size used when creating threads is determined from > -Xss/ThreadStackSize resp. the stacksize constructor argument. The various > VM guard pages (red, yellow etc) are taken from that size, right? So the > usable stack size is ThreadStackSize minus size-of-VM-guard-pages? Yes. > If that is true, do we want to change this at some point? It is confusing > and hurts on platforms where page sizes are larger (e.g. 64K paged stacks > on ppc64). I understand that changing this behavior to one where the VM > guard areas would come atop of ThreadStackSize would be an incompatible > change, because it would suddenly drive up memory consumption of systems > which are configured to run smoothly with the old behavior. But for a new > java release this could be tolerated, or? You're not alone, but I personally think this ship has sailed. See some discussion in: https://bugs.openjdk.java.net/browse/JDK-8173817 Cheers, David > Kind Regards, Thomas > From vladimir.kozlov at oracle.com Thu Aug 31 21:53:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Aug 2017 14:53:38 -0700 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: References: <9016267b-3a6e-b684-4263-2c95b2f630ff@oracle.com> Message-ID: <5f8def30-1554-29a5-dde7-62b9940d0161@oracle.com> Hi Rohit, I am glad to see that AMD continue to work to improve their CPU. But it also mean that AMD will have to do Java testing for this new platform and be responsible for it. In a future we may forward this CPU related problems to you to analyze and fix. Regards, Vladimir On 8/31/17 2:31 PM, David Holmes wrote: > Hi Rohit, > > I think the patch needs updating for jdk10 as I already see a lot of logic around UseSHA in vm_version_x86.cpp. > > Thanks, > David > > On 1/09/2017 1:11 AM, Rohit Arul Raj wrote: >> On Thu, Aug 31, 2017 at 5:59 PM, David Holmes wrote: >>> Hi Rohit, >>> >>> On 31/08/2017 7:03 PM, Rohit Arul Raj wrote: >>>> >>>> I would like an volunteer to review this patch (openJDK9) which sets >>>> flag/ISA defaults for newer AMD 17h (EPYC) processor and help us with >>>> the commit process. >>>> >>>> Webrev: >>>> https://www.dropbox.com/sh/08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 >>> >>> >>> Unfortunately patches can not be accepted from systems outside the OpenJDK >>> infrastructure and ... >>> >>>> I have also attached the patch (hg diff -g) for reference. >>> >>> >>> ... unfortunately patches tend to get stripped by the mail servers. If the >>> patch is small please include it inline. Otherwise you will need to find an >>> OpenJDK Author who can host it for you on cr.openjdk.java.net. >>> >> >>>> 3) I have done regression testing using jtreg ($make default) and >>>> didnt find any regressions. >>> >>> >>> Sounds good, but until I see the patch it is hard to comment on testing >>> requirements. >>> >>> Thanks, >>> David >> >> Thanks David, >> Yes, it's a small patch. >> >> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >> b/src/cpu/x86/vm/vm_version_x86.cpp >> --- a/src/cpu/x86/vm/vm_version_x86.cpp >> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >> @@ -1051,6 +1051,22 @@ >> ??????? } >> ??????? FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); >> ????? } >> +??? if (supports_sha()) { >> +????? if (FLAG_IS_DEFAULT(UseSHA)) { >> +??????? FLAG_SET_DEFAULT(UseSHA, true); >> +????? } >> +??? } else if (UseSHA || UseSHA1Intrinsics || UseSHA256Intrinsics || >> UseSHA512Intrinsics) { >> +????? if (!FLAG_IS_DEFAULT(UseSHA) || >> +????????? !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || >> +????????? !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || >> +????????? !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >> +??????? warning("SHA instructions are not available on this CPU"); >> +????? } >> +????? FLAG_SET_DEFAULT(UseSHA, false); >> +????? FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); >> +????? FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); >> +????? FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >> +??? } >> >> ????? // some defaults for AMD family 15h >> ????? if ( cpu_family() == 0x15 ) { >> @@ -1072,11 +1088,43 @@ >> ????? } >> >> ? #ifdef COMPILER2 >> -??? if (MaxVectorSize > 16) { >> -????? // Limit vectors size to 16 bytes on current AMD cpus. >> +??? if (cpu_family() < 0x17 && MaxVectorSize > 16) { >> +????? // Limit vectors size to 16 bytes on AMD cpus < 17h. >> ??????? FLAG_SET_DEFAULT(MaxVectorSize, 16); >> ????? } >> ? #endif // COMPILER2 >> + >> +??? // Some defaults for AMD family 17h >> +??? if ( cpu_family() == 0x17 ) { >> +????? // On family 17h processors use XMM and UnalignedLoadStores for >> Array Copy >> +????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> +??????? UseXMMForArrayCopy = true; >> +????? } >> +????? if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >> +??????? UseUnalignedLoadStores = true; >> +????? } >> +????? if (supports_bmi2() && FLAG_IS_DEFAULT(UseBMI2Instructions)) { >> +??????? UseBMI2Instructions = true; >> +????? } >> +????? if (MaxVectorSize > 32) { >> +??????? FLAG_SET_DEFAULT(MaxVectorSize, 32); >> +????? } >> +????? if (UseSHA) { >> +??????? if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >> +????????? FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >> +??????? } else if (UseSHA512Intrinsics) { >> +????????? warning("Intrinsics for SHA-384 and SHA-512 crypto hash >> functions not available on this CPU."); >> +????????? FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >> +??????? } >> +????? } >> +#ifdef COMPILER2 >> +????? if (supports_sse4_2()) { >> +??????? if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >> +????????? FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> +??????? } >> +????? } >> +#endif >> +??? } >> ??? } >> >> ??? if( is_intel() ) { // Intel cpus specific settings >> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >> b/src/cpu/x86/vm/vm_version_x86.hpp >> --- a/src/cpu/x86/vm/vm_version_x86.hpp >> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >> @@ -513,6 +513,16 @@ >> ????????? result |= CPU_LZCNT; >> ??????? if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != 0) >> ????????? result |= CPU_SSE4A; >> +????? if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >> +??????? result |= CPU_BMI2; >> +????? if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >> +??????? result |= CPU_HT; >> +????? if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >> +??????? result |= CPU_ADX; >> +????? if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >> +??????? result |= CPU_SHA; >> +????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> +??????? result |= CPU_FMA; >> ????? } >> ????? // Intel features. >> ????? if(is_intel()) { >> >> Regards, >> Rohit >>