From stevenschlansker at gmail.com  Thu Dec  1 00:10:45 2016
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 30 Nov 2016 16:10:45 -0800
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
Message-ID: <E1E4CF48-8B0D-4C8E-AEC4-F6F4BB6C3635@gmail.com>

We run in this configuration and I just want to point out that there's more going
on than simply correctly fixing heap size.  It's a great first start but we also found
that we had to spend a fair amount of time playing with all the other tuneables such
as Metaspace, Code Cache, etc. in order to get our Java apps to run stably
in cgroups.

Not in anyway to argue against this change, just that it'd be nice to get the "big picture"
tackled at some point -- heap is only one part :)

Thanks!
Steven

> On Nov 30, 2016, at 2:53 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
> 
> 
> Out of curiosity, why wouldn?t this be the default behavior? That is, in which cases is it not a good idea to use the cgroup information when sizing the JVM?
> 
> Cheers,
> Mikael
> 
> 
>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>> 
>> 
>> The problem is that when running the JVM inside of a cgroup, such as docker, the JVM bases it's default heap parameters on the size of the whole machine's memory not on the memory available to the container.  This causes errors as discussed on this blog entry.  http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>> 
>> Basically the JVM dies in a non-obvious manner.
>> 
>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the JVM which states that you should look to the CGroup when calculating default heap sizes.
>> 
>> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>> 
>> 
>> Christine
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 


From david.holmes at oracle.com  Thu Dec  1 00:40:38 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Dec 2016 10:40:38 +1000
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
Message-ID: <ff00dc1c-328b-9488-c3fa-0c68cd377067@oracle.com>

Hi Christine,

On 1/12/2016 7:59 AM, Christine Flood wrote:
>
> The problem is that when running the JVM inside of a cgroup, such as docker, the JVM bases it's default heap parameters on the size of the whole machine's memory not on the memory available to the container.  This causes errors as discussed on this blog entry.  http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>
> Basically the JVM dies in a non-obvious manner.
>
> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the JVM which states that you should look to the CGroup when calculating default heap sizes.
>
> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/

We are aware of the problem with Docker - please see:

https://bugs.openjdk.java.net/browse/JDK-8146115

It has been unclear exactly how the Cgroup limits should affect the VM's 
interpretation of what memory is available. Is it as simple as 
pretending memory.limit_in_bytes represents physical memory? I don't 
know for sure - what about the other limits, how might they impact the VM?

There is also the issue that the cgroup file system needs to be loaded 
to enable this to be done - something which has often been lacking in 
Docker environments.

I also agree with Mikael - if we are running in a constrained 
environment like Cgroups then wouldn't we want to do this 
unconditionally? Or at least the default would be to do it?

Thanks,
David

>
> Christine
>
>
>
>
>
>
>

From david.holmes at oracle.com  Thu Dec  1 02:42:25 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Dec 2016 12:42:25 +1000
Subject: RFR(s): 8169206: TemplateInterpreter::_continuation_entry is
	never referenced
In-Reply-To: <583F2F0C.7050206@oracle.com>
References: <583F2F0C.7050206@oracle.com>
Message-ID: <b0bd715c-5d20-5abf-09f6-1c5060feeca7@oracle.com>

Hi Max,

Seems okay.

If you plan top push to 9 please change the "Fix version" in the bug 
first, else a backport for 9 will be created.

Thanks,
David

On 1/12/2016 5:57 AM, Max Ockner wrote:
> Hello everyone!
>
> Please review this small fix which removes some dead code from the
> interpreter. TemplateInterpreter::_continuation_entry table and its
> accessor are never called from anywhere else.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169206
> Webrev: http://cr.openjdk.java.net/~mockner/8169206.01/
>
> Tested with java -version.
>
> Thanks,
> Max
>
>
>
>

From coleen.phillimore at oracle.com  Thu Dec  1 03:09:49 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 30 Nov 2016 22:09:49 -0500
Subject: RFR(s): 8169206: TemplateInterpreter::_continuation_entry is
	never referenced
In-Reply-To: <583F2F0C.7050206@oracle.com>
References: <583F2F0C.7050206@oracle.com>
Message-ID: <c5a9cbe3-81bf-4bfc-09ba-14ba4cbbe8d5@oracle.com>


Hi Max,

You didn't remove the platform specific 
TemplateInterpreterGenerator::generate_continuation_for() methods.

I think from ancient history, these used to be used for reexecuting the 
bytecode after rewriting to the fast version from within 
InterpreterRuntime.  That code's been long dead!

Thanks - this will be a good cleanup for jdk10.
Coleen

On 11/30/16 2:57 PM, Max Ockner wrote:
> Hello everyone!
>
> Please review this small fix which removes some dead code from the 
> interpreter. TemplateInterpreter::_continuation_entry table and its 
> accessor are never called from anywhere else.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169206
> Webrev: http://cr.openjdk.java.net/~mockner/8169206.01/
>
> Tested with java -version.
>
> Thanks,
> Max
>
>
>
>


From kirk at kodewerk.com  Thu Dec  1 04:31:01 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Thu, 1 Dec 2016 05:31:01 +0100
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <E1E4CF48-8B0D-4C8E-AEC4-F6F4BB6C3635@gmail.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
	<E1E4CF48-8B0D-4C8E-AEC4-F6F4BB6C3635@gmail.com>
Message-ID: <2BF68D9B-E474-4923-81D9-D0D9665D61E8@kodewerk.com>

Hi all,

This is a problem that everyone using Docker faces and it is a very common question, how do I configure the JVM when I?m using Docker. The number of parameters that have to be set in order to catch everything is daunting (through probably not necessary). For example, you wouldn?t believe how many people don?t know that there are machine sized resources in the JVM such as the shared F-J thread pool.

Kind regards,
Kirk

> On Dec 1, 2016, at 1:10 AM, Steven Schlansker <stevenschlansker at gmail.com> wrote:
> 
> We run in this configuration and I just want to point out that there's more going
> on than simply correctly fixing heap size.  It's a great first start but we also found
> that we had to spend a fair amount of time playing with all the other tuneables such
> as Metaspace, Code Cache, etc. in order to get our Java apps to run stably
> in cgroups.
> 
> Not in anyway to argue against this change, just that it'd be nice to get the "big picture"
> tackled at some point -- heap is only one part :)
> 
> Thanks!
> Steven
> 
>> On Nov 30, 2016, at 2:53 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>> 
>> 
>> Out of curiosity, why wouldn?t this be the default behavior? That is, in which cases is it not a good idea to use the cgroup information when sizing the JVM?
>> 
>> Cheers,
>> Mikael
>> 
>> 
>>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>>> 
>>> 
>>> The problem is that when running the JVM inside of a cgroup, such as docker, the JVM bases it's default heap parameters on the size of the whole machine's memory not on the memory available to the container.  This causes errors as discussed on this blog entry.  http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>>> 
>>> Basically the JVM dies in a non-obvious manner.
>>> 
>>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the JVM which states that you should look to the CGroup when calculating default heap sizes.
>>> 
>>> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>>> 
>>> 
>>> Christine
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 


From david.holmes at oracle.com  Thu Dec  1 04:35:23 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Dec 2016 14:35:23 +1000
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <2BF68D9B-E474-4923-81D9-D0D9665D61E8@kodewerk.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
	<E1E4CF48-8B0D-4C8E-AEC4-F6F4BB6C3635@gmail.com>
	<2BF68D9B-E474-4923-81D9-D0D9665D61E8@kodewerk.com>
Message-ID: <3f841927-4cd8-a3be-1f1a-f8a393a90add@oracle.com>

Hi Kirk,

On 1/12/2016 2:31 PM, kirk at kodewerk.com wrote:
> Hi all,
>
> This is a problem that everyone using Docker faces and it is a very common question, how do I configure the JVM when I?m using Docker. The number of parameters that have to be set in order to catch everything is daunting (through probably not necessary). For example, you wouldn?t believe how many people don?t know that there are machine sized resources in the JVM such as the shared F-J thread pool.

Note that the CPU issue is fixed in JDK 9 and 8u122.

https://bugs.openjdk.java.net/browse/JDK-6515172

David
-----

> Kind regards,
> Kirk
>
>> On Dec 1, 2016, at 1:10 AM, Steven Schlansker <stevenschlansker at gmail.com> wrote:
>>
>> We run in this configuration and I just want to point out that there's more going
>> on than simply correctly fixing heap size.  It's a great first start but we also found
>> that we had to spend a fair amount of time playing with all the other tuneables such
>> as Metaspace, Code Cache, etc. in order to get our Java apps to run stably
>> in cgroups.
>>
>> Not in anyway to argue against this change, just that it'd be nice to get the "big picture"
>> tackled at some point -- heap is only one part :)
>>
>> Thanks!
>> Steven
>>
>>> On Nov 30, 2016, at 2:53 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>>>
>>>
>>> Out of curiosity, why wouldn?t this be the default behavior? That is, in which cases is it not a good idea to use the cgroup information when sizing the JVM?
>>>
>>> Cheers,
>>> Mikael
>>>
>>>
>>>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>>>>
>>>>
>>>> The problem is that when running the JVM inside of a cgroup, such as docker, the JVM bases it's default heap parameters on the size of the whole machine's memory not on the memory available to the container.  This causes errors as discussed on this blog entry.  http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>>>>
>>>> Basically the JVM dies in a non-obvious manner.
>>>>
>>>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the JVM which states that you should look to the CGroup when calculating default heap sizes.
>>>>
>>>> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>>>>
>>>>
>>>> Christine
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

From kirk at kodewerk.com  Thu Dec  1 04:44:22 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Thu, 1 Dec 2016 05:44:22 +0100
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <3f841927-4cd8-a3be-1f1a-f8a393a90add@oracle.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
	<E1E4CF48-8B0D-4C8E-AEC4-F6F4BB6C3635@gmail.com>
	<2BF68D9B-E474-4923-81D9-D0D9665D61E8@kodewerk.com>
	<3f841927-4cd8-a3be-1f1a-f8a393a90add@oracle.com>
Message-ID: <ADB26EEA-4A91-4954-B464-5B48CDA2A1EA@kodewerk.com>

Hi David,

Thanks, I missed that one. That said, CPU count is but one of the machine sized resources. Another question I ask and rarely get the right answer to is how large is heap if you don?t specify -mx? and so on. It is awesome that the JVM often picks reasonable results for machine sized configurations. It means that people *don?t* have to know the answers to these questions and they?ll still get a reasonable result until the don?t.

Regards,
Kirk

> On Dec 1, 2016, at 5:35 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kirk,
> 
> On 1/12/2016 2:31 PM, kirk at kodewerk.com wrote:
>> Hi all,
>> 
>> This is a problem that everyone using Docker faces and it is a very common question, how do I configure the JVM when I?m using Docker. The number of parameters that have to be set in order to catch everything is daunting (through probably not necessary). For example, you wouldn?t believe how many people don?t know that there are machine sized resources in the JVM such as the shared F-J thread pool.
> 
> Note that the CPU issue is fixed in JDK 9 and 8u122.
> 
> https://bugs.openjdk.java.net/browse/JDK-6515172
> 
> David
> -----
> 
>> Kind regards,
>> Kirk
>> 
>>> On Dec 1, 2016, at 1:10 AM, Steven Schlansker <stevenschlansker at gmail.com> wrote:
>>> 
>>> We run in this configuration and I just want to point out that there's more going
>>> on than simply correctly fixing heap size.  It's a great first start but we also found
>>> that we had to spend a fair amount of time playing with all the other tuneables such
>>> as Metaspace, Code Cache, etc. in order to get our Java apps to run stably
>>> in cgroups.
>>> 
>>> Not in anyway to argue against this change, just that it'd be nice to get the "big picture"
>>> tackled at some point -- heap is only one part :)
>>> 
>>> Thanks!
>>> Steven
>>> 
>>>> On Nov 30, 2016, at 2:53 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>>>> 
>>>> 
>>>> Out of curiosity, why wouldn?t this be the default behavior? That is, in which cases is it not a good idea to use the cgroup information when sizing the JVM?
>>>> 
>>>> Cheers,
>>>> Mikael
>>>> 
>>>> 
>>>>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>>>>> 
>>>>> 
>>>>> The problem is that when running the JVM inside of a cgroup, such as docker, the JVM bases it's default heap parameters on the size of the whole machine's memory not on the memory available to the container.  This causes errors as discussed on this blog entry.  http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>>>>> 
>>>>> Basically the JVM dies in a non-obvious manner.
>>>>> 
>>>>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the JVM which states that you should look to the CGroup when calculating default heap sizes.
>>>>> 
>>>>> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>>>>> 
>>>>> 
>>>>> Christine
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 


From david.holmes at oracle.com  Thu Dec  1 04:57:40 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Dec 2016 14:57:40 +1000
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <ADB26EEA-4A91-4954-B464-5B48CDA2A1EA@kodewerk.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
	<E1E4CF48-8B0D-4C8E-AEC4-F6F4BB6C3635@gmail.com>
	<2BF68D9B-E474-4923-81D9-D0D9665D61E8@kodewerk.com>
	<3f841927-4cd8-a3be-1f1a-f8a393a90add@oracle.com>
	<ADB26EEA-4A91-4954-B464-5B48CDA2A1EA@kodewerk.com>
Message-ID: <64d87f92-2b98-d792-93ca-fa3b00c1d4e1@oracle.com>

Hi Kirk,

On 1/12/2016 2:44 PM, kirk at kodewerk.com wrote:
> Hi David,
>
> Thanks, I missed that one. That said, CPU count is but one of the
> machine sized resources. Another question I ask and rarely get the right
> answer to is how large is heap if you don?t specify -mx? and so on. It
> is awesome that the JVM often picks reasonable results for machine sized
> configurations. It means that people *don?t* have to know the answers to
> these questions and they?ll still get a reasonable result until the don?t

The ergonomics decisions for sizing of various memory related values, 
including heap is not trivial, and may also depend on other runtime factors.

When people develop container technologies like cgroups it would be nice 
if they actually considered how their imposed constraints become visible 
through the API's provided by the OS. Unfortunately OS API's were also 
not written to answer questions that now have 3 or more levels of 
context**: ie how much memory is available to my process; how much is 
available to the virtual environment my process is running on; and how 
much is on the physical machine.

Determining where cgroup memory constraints need to be exposed to the 
JVM is not obvious to me. But we're happy to hear from any cgroup 
experts who can shed light on this. But this work is targeted for JDK 10.

Cheers,
David
-----

** At least for CPUs there are API's to cover the process and "machine" 
cases. But we had to examine all the uses of "processor count" to check 
which ones were interested in the actual available processors, and which 
were concerned with the machine processor count.

.
>
> Regards,
> Kirk
>
>> On Dec 1, 2016, at 5:35 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kirk,
>>
>> On 1/12/2016 2:31 PM, kirk at kodewerk.com wrote:
>>> Hi all,
>>>
>>> This is a problem that everyone using Docker faces and it is a very common question, how do I configure the JVM when I?m using Docker. The number of parameters that have to be set in order to catch everything is daunting (through probably not necessary). For example, you wouldn?t believe how many people don?t know that there are machine sized resources in the JVM such as the shared F-J thread pool.
>>
>> Note that the CPU issue is fixed in JDK 9 and 8u122.
>>
>> https://bugs.openjdk.java.net/browse/JDK-6515172
>>
>> David
>> -----
>>
>>> Kind regards,
>>> Kirk
>>>
>>>> On Dec 1, 2016, at 1:10 AM, Steven Schlansker <stevenschlansker at gmail.com> wrote:
>>>>
>>>> We run in this configuration and I just want to point out that there's more going
>>>> on than simply correctly fixing heap size.  It's a great first start but we also found
>>>> that we had to spend a fair amount of time playing with all the other tuneables such
>>>> as Metaspace, Code Cache, etc. in order to get our Java apps to run stably
>>>> in cgroups.
>>>>
>>>> Not in anyway to argue against this change, just that it'd be nice to get the "big picture"
>>>> tackled at some point -- heap is only one part :)
>>>>
>>>> Thanks!
>>>> Steven
>>>>
>>>>> On Nov 30, 2016, at 2:53 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>>>>>
>>>>>
>>>>> Out of curiosity, why wouldn?t this be the default behavior? That is, in which cases is it not a good idea to use the cgroup information when sizing the JVM?
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>>
>>>>>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>>>>>>
>>>>>>
>>>>>> The problem is that when running the JVM inside of a cgroup, such as docker, the JVM bases it's default heap parameters on the size of the whole machine's memory not on the memory available to the container.  This causes errors as discussed on this blog entry.  http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>>>>>>
>>>>>> Basically the JVM dies in a non-obvious manner.
>>>>>>
>>>>>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the JVM which states that you should look to the CGroup when calculating default heap sizes.
>>>>>>
>>>>>> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>>>>>>
>>>>>>
>>>>>> Christine
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From thomas.stuefe at gmail.com  Thu Dec  1 11:44:13 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2016 12:44:13 +0100
Subject: Ho do I launch hotspot gtests?
Message-ID: <CAA-vtUwr=BJLZOKGJqGG5R4Ee4Y-+8PFL7FXryA4D9+aDoVAdA@mail.gmail.com>

Hi all,

a small question, what is the correct way to execute the hotspot gtests?

I find that I can run <libjvm.so>/gtestLauncher and it will execute the
tests, is that the normal way to go?

But it then always requires a jdk argument, which seems odd considering the
gtest launcher is located right beside the libjvm.so and so should know the
jdk directory.

Also, running the test a second time I get a crash (on windows) in
LogFileOutput.invalid_file_test:

#
#  Internal Error
(c:\d031900\openjdk\jdk9-hs2\source\hotspot\test\native\logging\logTestUtils.inline.hpp:52),
pid=16488, tid=11288
#  assert(!file_exists(name)) failed: can't create directory: tmplogdir
already exists
#

which looks to me that some cleanup steps are missing and that maybe I do
things the wrong way.

Thanks for clarifying,

Thomas

From mikael.gerdin at oracle.com  Thu Dec  1 11:57:11 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 1 Dec 2016 12:57:11 +0100
Subject: Ho do I launch hotspot gtests?
In-Reply-To: <CAA-vtUwr=BJLZOKGJqGG5R4Ee4Y-+8PFL7FXryA4D9+aDoVAdA@mail.gmail.com>
References: <CAA-vtUwr=BJLZOKGJqGG5R4Ee4Y-+8PFL7FXryA4D9+aDoVAdA@mail.gmail.com>
Message-ID: <1546c9ee-d0f3-9538-c031-f6e7a8159d53@oracle.com>

Hi Thomas,



On 2016-12-01 12:44, Thomas St?fe wrote:
> Hi all,
>
> a small question, what is the correct way to execute the hotspot gtests?

The easiest way is to run
$ make test-hotspot-gtest
in the build directory for your configuration

in my case that directory is
jdk9/hs/build/linux-x64/debug
but the name depends on your configure command line.

/Mikael

>
> I find that I can run <libjvm.so>/gtestLauncher and it will execute the
> tests, is that the normal way to go?
>
> But it then always requires a jdk argument, which seems odd considering the
> gtest launcher is located right beside the libjvm.so and so should know the
> jdk directory.
>
> Also, running the test a second time I get a crash (on windows) in
> LogFileOutput.invalid_file_test:
>
> #
> #  Internal Error
> (c:\d031900\openjdk\jdk9-hs2\source\hotspot\test\native\logging\logTestUtils.inline.hpp:52),
> pid=16488, tid=11288
> #  assert(!file_exists(name)) failed: can't create directory: tmplogdir
> already exists
> #
>
> which looks to me that some cleanup steps are missing and that maybe I do
> things the wrong way.
>
> Thanks for clarifying,
>
> Thomas
>

From jcowgill at debian.org  Thu Dec  1 12:03:22 2016
From: jcowgill at debian.org (James Cowgill)
Date: Thu, 1 Dec 2016 12:03:22 +0000
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <CAA-vtUw8BfTfPUgAVhKm8_frbUMFX4Va_AK2OUzwiVk46p2doA@mail.gmail.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<CAA-vtUw8BfTfPUgAVhKm8_frbUMFX4Va_AK2OUzwiVk46p2doA@mail.gmail.com>
Message-ID: <6699188f-5dbd-39d0-aab0-d192a4855726@debian.org>

Hi,

Thanks for looking at my patch!

On 30/11/16 19:33, Thomas St?fe wrote:
> In general I like your patch - we used sigset_t in the AIX port instead
> of masks and this would be a good cleanup for the other platforms too. 
> 
> But in this case, is the problem not that the mips signal.h headers
> fails to define NSIG?
> 
> We have NSIG and _NSIG. _NSIG seems to be the platform dependent max
> including real time signals. NSIG excludes real time signals, and seems
> to be 32 (SIGRTMIN) on all Linux platforms I checked. 

I'm running Ubuntu 16.04 (amd64) and both NSIG and _NSIG are 65 here.

> I may have looked wrong (I searched
> http://lxr.free-electrons.com/ident?v=3.2&i=NSIG), but I found that NSIG
> was missing from signal.h on some architectures, mips being among them.
> I do not know why, but would like to understand the reason. Do you
> define NSIG to be _NSIG?

My reading of glibc's signal.h seems to indicate that all architectures
which use glibc define NSIG = _NSIG. The kernel and glibc headers quite
often disagree (struct stat springs to mind).

The glibc documentation on this also doesn't mention real time signals:

Macro: int NSIG
The value of this symbolic constant is the total number of signals
defined. Since the signal numbers are allocated consecutively, NSIG is
also one greater than the largest defined signal number.

> The VM currently does not use real time signals, so NSIG should be
> sufficient. If NSIG is really missing on mips, then maybe defining it
> locally as SIGRTMIN would be a less invasive change. 

Maybe we could use something other than NSIG as the maximum signal
(although I'm not sure I like it that much)? SIGRTMIN is not a constant
on glibc systems so redefining NSIG isn't going to work as a quick fix.

> If we were to change the hand-written bitmask to sigset_t, we probably
> should also take a look at the arrays of length NSIG (sigact, sigflags,
> pending_signals) and the associated checks. This would be a bigger cleanup.

I think that's a separate bug though. The bug here is that we're _not_
using an array - we're using a fixed sized integer instead.

> ---
> 
> Apart from all that, I'd suggest moving the sigset initialization in
> os_linux.cpp from the "__attribute__((constructor))" function to
> os::signal_init_pd(). I'd suggest a similar move for jsig.c, but do not
> see a suitable initialization function there. Maybe someone else has an
> idea?

Ok I'll do that when I do another patch.

Thanks,
James

> On Wed, Nov 30, 2016 at 6:50 PM, James Cowgill <jcowgill at debian.org
> <mailto:jcowgill at debian.org>> wrote:
> 
>     Hi,
> 
>     Firstly I have never submitted anything to OpenJDK before so apologies
>     if I haven't done things the right way. I also have no bug number
>     for this.
> 
>     OpenJDK 9 does not build on MIPS machines and hasn't for some time. This
>     is due to code in hotspot which assumes NSIG <= 65 which is not the case
>     on MIPS since MIPS has 127 signal numbers.
> 
>     I've attached an initial patch which converts the offending code in
>     hotspot/src/os/linux/vm/jsig.c to use sigset_t instead of an array to
>     store the used signals. I notice the AIX implementation of jsig.c
>     already does this.
> 
>     Originally from: https://bugs.debian.org/841173
> 
>     Thanks,
>     James


From david.holmes at oracle.com  Thu Dec  1 13:20:07 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Dec 2016 23:20:07 +1000
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
Message-ID: <8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>

Hi James,

On 1/12/2016 3:50 AM, James Cowgill wrote:
> Hi,
>
> Firstly I have never submitted anything to OpenJDK before so apologies
> if I haven't done things the right way. I also have no bug number for this.

First let me say thanks for the contribution. Information on 
contributing is here:

http://openjdk.java.net/contribute/

For any non-trivial contribution to be accepted you would need to sign 
the OCA. Though in this case this is arguably a variation of the AIX 
code anyway.

> OpenJDK 9 does not build on MIPS machines and hasn't for some time. This
> is due to code in hotspot which assumes NSIG <= 65 which is not the case
> on MIPS since MIPS has 127 signal numbers.

Given MIPS is not supported and the MIPS porting project seems dormant, 
if not dead, I am surprised if this is the only thing that will prevent 
you from building on MIPS. And even if you do build okay I'm not sure 
what you can run - zero intepreter?

> I've attached an initial patch which converts the offending code in
> hotspot/src/os/linux/vm/jsig.c to use sigset_t instead of an array to
> store the used signals. I notice the AIX implementation of jsig.c
> already does this.

In your patch, as Thomas pointed out, you use 
__attribute__((constructor)) which is not something we use within the 
hotspot code (maybe we should and maybe someday we will, but that day is 
not today). Initialization can be handled as Thomas suggested and as 
already done in the AIX version. Is there any reason for the AIX and 
Linux versions to actually be different?

That said, given that this patch does nothing to fix the supported 
OpenJDK 9 platforms it would have to be considered an enhancement and we 
are closed to new enhancements for JDK 9. The JDK 10 repos will be 
opening very soon though, and I think consolidating the different 
versions of jsig.c might be worthwhile.

Thanks,
David

> Originally from: https://bugs.debian.org/841173
>
> Thanks,
> James
>
>

From doko at ubuntu.com  Thu Dec  1 13:36:46 2016
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 1 Dec 2016 14:36:46 +0100
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
Message-ID: <6ca3fcd2-e08a-2f4d-4884-d539842cbd18@ubuntu.com>

On 01.12.2016 14:20, David Holmes wrote:
> That said, given that this patch does nothing to fix the supported OpenJDK 9

where can I find the list of supported platforms? Is zero a supported platform?

> platforms it would have to be considered an enhancement and we are closed to new
> enhancements for JDK 9. The JDK 10 repos will be opening very soon though,

same here:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004819.html

How can these porting patches find it's way into jdk9?  I see that JEPs for
three new hotspot ports were accepted after September.  Is this the right way to
write a JEP for each zero port, or would these fixes considered for backporting
into jdk9?

Matthias


From thomas.stuefe at gmail.com  Thu Dec  1 13:41:29 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2016 14:41:29 +0100
Subject: Ho do I launch hotspot gtests?
In-Reply-To: <1546c9ee-d0f3-9538-c031-f6e7a8159d53@oracle.com>
References: <CAA-vtUwr=BJLZOKGJqGG5R4Ee4Y-+8PFL7FXryA4D9+aDoVAdA@mail.gmail.com>
	<1546c9ee-d0f3-9538-c031-f6e7a8159d53@oracle.com>
Message-ID: <CAA-vtUxyC0BhPRBd+o9c_8+dXdtWqdc0yCXdMmJzyDtjzsPCRg@mail.gmail.com>

Thank you Mikael!

On Thu, Dec 1, 2016 at 12:57 PM, Mikael Gerdin <mikael.gerdin at oracle.com>
wrote:

> Hi Thomas,
>
>
>
> On 2016-12-01 12:44, Thomas St?fe wrote:
>
>> Hi all,
>>
>> a small question, what is the correct way to execute the hotspot gtests?
>>
>
> The easiest way is to run
> $ make test-hotspot-gtest
> in the build directory for your configuration
>
> in my case that directory is
> jdk9/hs/build/linux-x64/debug
> but the name depends on your configure command line.
>
> /Mikael
>
>
>
>> I find that I can run <libjvm.so>/gtestLauncher and it will execute the
>> tests, is that the normal way to go?
>>
>> But it then always requires a jdk argument, which seems odd considering
>> the
>> gtest launcher is located right beside the libjvm.so and so should know
>> the
>> jdk directory.
>>
>> Also, running the test a second time I get a crash (on windows) in
>> LogFileOutput.invalid_file_test:
>>
>> #
>> #  Internal Error
>> (c:\d031900\openjdk\jdk9-hs2\source\hotspot\test\native\logg
>> ing\logTestUtils.inline.hpp:52),
>> pid=16488, tid=11288
>> #  assert(!file_exists(name)) failed: can't create directory: tmplogdir
>> already exists
>> #
>>
>> which looks to me that some cleanup steps are missing and that maybe I do
>> things the wrong way.
>>
>> Thanks for clarifying,
>>
>> Thomas
>>
>>

From chf at redhat.com  Thu Dec  1 14:50:05 2016
From: chf at redhat.com (Christine Flood)
Date: Thu, 1 Dec 2016 09:50:05 -0500 (EST)
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
Message-ID: <724185737.1372541.1480603805989.JavaMail.zimbra@redhat.com>

Unfortunately, if you aren't actually inside a cgroup, /sys/fs/cgroup/memory/memory.limit_in_bytes still exists and contains an apparently bogus value.  I've got a question in to the docker folks to find out why. 

In the short term, providing a runtime flag gives us a way to protect customers that are running inside a container and not change the current behavior for everyone else.

Christine

----- Original Message -----
> From: "Mikael Vidstedt" <mikael.vidstedt at oracle.com>
> To: "Christine Flood" <chf at redhat.com>
> Cc: hotspot-dev at openjdk.java.net
> Sent: Wednesday, November 30, 2016 5:53:41 PM
> Subject: Re: Java heap size defaults when running with CGroups in Linux.
> 
> 
> Out of curiosity, why wouldn?t this be the default behavior? That is, in
> which cases is it not a good idea to use the cgroup information when sizing
> the JVM?
> 
> Cheers,
> Mikael
> 
> 
> > On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
> > 
> > 
> > The problem is that when running the JVM inside of a cgroup, such as
> > docker, the JVM bases it's default heap parameters on the size of the
> > whole machine's memory not on the memory available to the container.  This
> > causes errors as discussed on this blog entry.
> > http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
> > 
> > Basically the JVM dies in a non-obvious manner.
> > 
> > The solution I propose is to add a parameter -XX:+UseCGroupLimits to the
> > JVM which states that you should look to the CGroup when calculating
> > default heap sizes.
> > 
> > Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
> > 
> > 
> > Christine
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 

From Alan.Bateman at oracle.com  Thu Dec  1 15:05:41 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 1 Dec 2016 15:05:41 +0000
Subject: 8170599: compiler/** tests using ToolProvider.getSystemClassLoader
	failing
Message-ID: <3e634453-20d9-de27-e3fb-c46c98bc35a2@oracle.com>

I need a Reviewer for a trivial change to two tests in 
hotspot/test/compiler/** that are failing in jdk9/dev. We noticed these 
failures while trying to bring the module system into jdk9/dev. The 
failures have been in jdk9/dev since Nov 22 when javax.tool.ToolProvider 
was changed via JDK-8155765 to return null. The impact of that change is 
that these two tests fail with NCDFE as they are attempting to load the 
entry point for the attach API with the null loader (but these classes 
aren't visible via that loader). The change is to use the system class 
loader to load the entry point for the attach API. I've also used the 
opportunity to update the @modules tag to add jdk.attach because that's 
a lurking issue with these tests too. Patch inlined below.

-Alan


$ hg diff -g
diff --git 
a/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java 
b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
--- a/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
+++ b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
@@ -30,6 +30,7 @@
   *          java.compiler
   *          java.instrument
   *          java.management
+ *          jdk.attach
   *
   * @run main/othervm 
compiler.jsr292.RedefineMethodUsedByMultipleMethodHandles
   */
@@ -42,7 +43,6 @@
  import jdk.internal.org.objectweb.asm.MethodVisitor;
  import jdk.internal.org.objectweb.asm.Opcodes;

-import javax.tools.ToolProvider;
  import java.io.FileOutputStream;
  import java.io.IOException;
  import java.io.InputStream;
@@ -132,7 +132,7 @@
          int p = vmName.indexOf('@');
          assert p != -1 : "VM name not in <pid>@<host> format: " + vmName;
          String pid = vmName.substring(0, p);
-        ClassLoader cl = ToolProvider.getSystemToolClassLoader();
+        ClassLoader cl = ClassLoader.getSystemClassLoader();
          Class<?> c = 
Class.forName("com.sun.tools.attach.VirtualMachine", true, cl);
          Method attach = c.getDeclaredMethod("attach", String.class);
          Method loadAgent = c.getDeclaredMethod("loadAgent", String.class);
diff --git 
a/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java 
b/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
--- 
a/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
+++ 
b/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
@@ -27,6 +27,7 @@
   * @library ../../../../../
   * @modules jdk.vm.ci/jdk.vm.ci.meta
   *          jdk.vm.ci/jdk.vm.ci.runtime
+ *          jdk.attach
   *          java.base/jdk.internal.misc
   * @run junit/othervm -XX:+UnlockExperimentalVMOptions 
-XX:+EnableJVMCI jdk.vm.ci.runtime.test.RedefineClassTest
   */
@@ -37,7 +38,6 @@
  import org.junit.Assert;
  import org.junit.Test;

-import javax.tools.ToolProvider;
  import java.io.FileOutputStream;
  import java.io.IOException;
  import java.io.InputStream;
@@ -137,7 +137,7 @@
          int p = vmName.indexOf('@');
          assumeTrue(p != -1);
          String pid = vmName.substring(0, p);
-        ClassLoader cl = ToolProvider.getSystemToolClassLoader();
+        ClassLoader cl = ClassLoader.getSystemClassLoader();
          Class<?> c = 
Class.forName("com.sun.tools.attach.VirtualMachine", true, cl);
          Method attach = c.getDeclaredMethod("attach", String.class);
          Method loadAgent = c.getDeclaredMethod("loadAgent", 
String.class, String.class);


From harold.seigel at oracle.com  Thu Dec  1 15:40:40 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 1 Dec 2016 10:40:40 -0500
Subject: 8170599: compiler/** tests using
	ToolProvider.getSystemClassLoader failing
In-Reply-To: <3e634453-20d9-de27-e3fb-c46c98bc35a2@oracle.com>
References: <3e634453-20d9-de27-e3fb-c46c98bc35a2@oracle.com>
Message-ID: <0ca056b3-a96f-e042-f5d4-131d9dec2a9d@oracle.com>

Hi Alan,

The changes look good.

Thanks, Harold


On 12/1/2016 10:05 AM, Alan Bateman wrote:
> I need a Reviewer for a trivial change to two tests in 
> hotspot/test/compiler/** that are failing in jdk9/dev. We noticed 
> these failures while trying to bring the module system into jdk9/dev. 
> The failures have been in jdk9/dev since Nov 22 when 
> javax.tool.ToolProvider was changed via JDK-8155765 to return null. 
> The impact of that change is that these two tests fail with NCDFE as 
> they are attempting to load the entry point for the attach API with 
> the null loader (but these classes aren't visible via that loader). 
> The change is to use the system class loader to load the entry point 
> for the attach API. I've also used the opportunity to update the 
> @modules tag to add jdk.attach because that's a lurking issue with 
> these tests too. Patch inlined below.
>
> -Alan
>
>
> $ hg diff -g
> diff --git 
> a/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java 
> b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
> --- a/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
> +++ b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
> @@ -30,6 +30,7 @@
>   *          java.compiler
>   *          java.instrument
>   *          java.management
> + *          jdk.attach
>   *
>   * @run main/othervm 
> compiler.jsr292.RedefineMethodUsedByMultipleMethodHandles
>   */
> @@ -42,7 +43,6 @@
>  import jdk.internal.org.objectweb.asm.MethodVisitor;
>  import jdk.internal.org.objectweb.asm.Opcodes;
>
> -import javax.tools.ToolProvider;
>  import java.io.FileOutputStream;
>  import java.io.IOException;
>  import java.io.InputStream;
> @@ -132,7 +132,7 @@
>          int p = vmName.indexOf('@');
>          assert p != -1 : "VM name not in <pid>@<host> format: " + 
> vmName;
>          String pid = vmName.substring(0, p);
> -        ClassLoader cl = ToolProvider.getSystemToolClassLoader();
> +        ClassLoader cl = ClassLoader.getSystemClassLoader();
>          Class<?> c = 
> Class.forName("com.sun.tools.attach.VirtualMachine", true, cl);
>          Method attach = c.getDeclaredMethod("attach", String.class);
>          Method loadAgent = c.getDeclaredMethod("loadAgent", 
> String.class);
> diff --git 
> a/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java 
> b/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java 
>
> --- 
> a/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
> +++ 
> b/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
> @@ -27,6 +27,7 @@
>   * @library ../../../../../
>   * @modules jdk.vm.ci/jdk.vm.ci.meta
>   *          jdk.vm.ci/jdk.vm.ci.runtime
> + *          jdk.attach
>   *          java.base/jdk.internal.misc
>   * @run junit/othervm -XX:+UnlockExperimentalVMOptions 
> -XX:+EnableJVMCI jdk.vm.ci.runtime.test.RedefineClassTest
>   */
> @@ -37,7 +38,6 @@
>  import org.junit.Assert;
>  import org.junit.Test;
>
> -import javax.tools.ToolProvider;
>  import java.io.FileOutputStream;
>  import java.io.IOException;
>  import java.io.InputStream;
> @@ -137,7 +137,7 @@
>          int p = vmName.indexOf('@');
>          assumeTrue(p != -1);
>          String pid = vmName.substring(0, p);
> -        ClassLoader cl = ToolProvider.getSystemToolClassLoader();
> +        ClassLoader cl = ClassLoader.getSystemClassLoader();
>          Class<?> c = 
> Class.forName("com.sun.tools.attach.VirtualMachine", true, cl);
>          Method attach = c.getDeclaredMethod("attach", String.class);
>          Method loadAgent = c.getDeclaredMethod("loadAgent", 
> String.class, String.class);
>


From mandy.chung at oracle.com  Thu Dec  1 15:57:24 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 1 Dec 2016 07:57:24 -0800
Subject: 8170599: compiler/** tests using
	ToolProvider.getSystemClassLoader failing
In-Reply-To: <3e634453-20d9-de27-e3fb-c46c98bc35a2@oracle.com>
References: <3e634453-20d9-de27-e3fb-c46c98bc35a2@oracle.com>
Message-ID: <FC41B4CE-49CB-41EF-9D2F-6F6ED04BE863@oracle.com>

Looks good.

Mandy

> On Dec 1, 2016, at 7:05 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> I need a Reviewer for a trivial change to two tests in hotspot/test/compiler/** that are failing in jdk9/dev. We noticed these failures while trying to bring the module system into jdk9/dev. The failures have been in jdk9/dev since Nov 22 when javax.tool.ToolProvider was changed via JDK-8155765 to return null. The impact of that change is that these two tests fail with NCDFE as they are attempting to load the entry point for the attach API with the null loader (but these classes aren't visible via that loader). The change is to use the system class loader to load the entry point for the attach API. I've also used the opportunity to update the @modules tag to add jdk.attach because that's a lurking issue with these tests too. Patch inlined below.
> 
> -Alan
> 
> 
> $ hg diff -g
> diff --git a/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
> --- a/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
> +++ b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java
> @@ -30,6 +30,7 @@
>  *          java.compiler
>  *          java.instrument
>  *          java.management
> + *          jdk.attach
>  *
>  * @run main/othervm compiler.jsr292.RedefineMethodUsedByMultipleMethodHandles
>  */
> @@ -42,7 +43,6 @@
> import jdk.internal.org.objectweb.asm.MethodVisitor;
> import jdk.internal.org.objectweb.asm.Opcodes;
> 
> -import javax.tools.ToolProvider;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> @@ -132,7 +132,7 @@
>         int p = vmName.indexOf('@');
>         assert p != -1 : "VM name not in <pid>@<host> format: " + vmName;
>         String pid = vmName.substring(0, p);
> -        ClassLoader cl = ToolProvider.getSystemToolClassLoader();
> +        ClassLoader cl = ClassLoader.getSystemClassLoader();
>         Class<?> c = Class.forName("com.sun.tools.attach.VirtualMachine", true, cl);
>         Method attach = c.getDeclaredMethod("attach", String.class);
>         Method loadAgent = c.getDeclaredMethod("loadAgent", String.class);
> diff --git a/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java b/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
> --- a/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
> +++ b/test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
> @@ -27,6 +27,7 @@
>  * @library ../../../../../
>  * @modules jdk.vm.ci/jdk.vm.ci.meta
>  *          jdk.vm.ci/jdk.vm.ci.runtime
> + *          jdk.attach
>  *          java.base/jdk.internal.misc
>  * @run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI jdk.vm.ci.runtime.test.RedefineClassTest
>  */
> @@ -37,7 +38,6 @@
> import org.junit.Assert;
> import org.junit.Test;
> 
> -import javax.tools.ToolProvider;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.InputStream;
> @@ -137,7 +137,7 @@
>         int p = vmName.indexOf('@');
>         assumeTrue(p != -1);
>         String pid = vmName.substring(0, p);
> -        ClassLoader cl = ToolProvider.getSystemToolClassLoader();
> +        ClassLoader cl = ClassLoader.getSystemClassLoader();
>         Class<?> c = Class.forName("com.sun.tools.attach.VirtualMachine", true, cl);
>         Method attach = c.getDeclaredMethod("attach", String.class);
>         Method loadAgent = c.getDeclaredMethod("loadAgent", String.class, String.class);
> 


From thomas.stuefe at gmail.com  Thu Dec  1 18:48:48 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2016 19:48:48 +0100
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
Message-ID: <CAA-vtUzD+FxEXhnkUhTvE-ZhTuhgh-0aon0r8wu4gTx-gT=89w@mail.gmail.com>

On Thu, Dec 1, 2016 at 2:20 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi James,
>
> On 1/12/2016 3:50 AM, James Cowgill wrote:
>
>> Hi,
>>
>> Firstly I have never submitted anything to OpenJDK before so apologies
>> if I haven't done things the right way. I also have no bug number for
>> this.
>>
>
> First let me say thanks for the contribution. Information on contributing
> is here:
>
> http://openjdk.java.net/contribute/
>
> For any non-trivial contribution to be accepted you would need to sign the
> OCA. Though in this case this is arguably a variation of the AIX code
> anyway.
>
> OpenJDK 9 does not build on MIPS machines and hasn't for some time. This
>> is due to code in hotspot which assumes NSIG <= 65 which is not the case
>> on MIPS since MIPS has 127 signal numbers.
>>
>
> Given MIPS is not supported and the MIPS porting project seems dormant, if
> not dead, I am surprised if this is the only thing that will prevent you
> from building on MIPS. And even if you do build okay I'm not sure what you
> can run - zero intepreter?
>
> I've attached an initial patch which converts the offending code in
>> hotspot/src/os/linux/vm/jsig.c to use sigset_t instead of an array to
>> store the used signals. I notice the AIX implementation of jsig.c
>> already does this.
>>
>
> In your patch, as Thomas pointed out, you use __attribute__((constructor))
> which is not something we use within the hotspot code (maybe we should and
> maybe someday we will, but that day is not today). Initialization can be
> handled as Thomas suggested and as already done in the AIX version. Is
> there any reason for the AIX and Linux versions to actually be different?
>

For the AIX port we used sigset_t over the handcoded bitmask. I think the
reason was the same, that we ran into the NSIG>64 problem James faces. It
is been a while though, so I am not sure, it may have been just aesthetic
considerations. I can check on the history if you are interested.

There is no technical reason for the implementations to be different. We
should use sigset_t on all Posix platforms. The reason is probably the same
as for all the other differences between AIX and the rest, that it is
sometimes easier to do AIX-local changes without changing shared sources.
But we try to consolidate this wherever possible.


> That said, given that this patch does nothing to fix the supported OpenJDK
> 9 platforms it would have to be considered an enhancement and we are closed
> to new enhancements for JDK 9. The JDK 10 repos will be opening very soon
> though, and I think consolidating the different versions of jsig.c might be
> worthwhile.
>
>
Not only jsig, we also use sigset_t in os_aix.cpp where the other platforms
use the hand-coded bitmask. Consolidation would make sense here.

But to address James' concern, it would probably be possible to backport
this change from 10 to 9, or?

Kind Regards, Thomas

Thanks,
> David
>
>
> Originally from: https://bugs.debian.org/841173
>>
>> Thanks,
>> James
>>
>>
>>

From thomas.stuefe at gmail.com  Thu Dec  1 19:08:58 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2016 20:08:58 +0100
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <6ca3fcd2-e08a-2f4d-4884-d539842cbd18@ubuntu.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
	<6ca3fcd2-e08a-2f4d-4884-d539842cbd18@ubuntu.com>
Message-ID: <CAA-vtUz90ghciheBqaCT_TXKM6_ZiiuXXPq_RJd7uRoWMx1eQQ@mail.gmail.com>

On Thu, Dec 1, 2016 at 2:36 PM, Matthias Klose <doko at ubuntu.com> wrote:

> On 01.12.2016 14:20, David Holmes wrote:
> > That said, given that this patch does nothing to fix the supported
> OpenJDK 9
>
> where can I find the list of supported platforms? Is zero a supported
> platform?
>
>
Well, there is that:

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

But this seems to be a bit outdated, I do not see arm nor the new s390
port. Should this be updated? If yes, should this be updated by the port
maintainers?


> > platforms it would have to be considered an enhancement and we are
> closed to new
> > enhancements for JDK 9. The JDK 10 repos will be opening very soon
> though,
>
> same here:
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004819.html
>
> How can these porting patches find it's way into jdk9?  I see that JEPs for
> three new hotspot ports were accepted after September.  Is this the right
> way to
> write a JEP for each zero port, or would these fixes considered for
> backporting
> into jdk9?
>
>
I always thought the point of the zero port was to just work on any
platform with a C++ compiler, and therefore does not constitute a real
porting platform. So, any error on zero for any architecture would be
handled as just a bug. I may be wrong here, so please correct me if I am
wrong.

..Thomas


> Matthias
>
>

From max.ockner at oracle.com  Thu Dec  1 20:04:59 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 01 Dec 2016 15:04:59 -0500
Subject: RFR(s): 8169206: TemplateInterpreter::_continuation_entry is
	never referenced
In-Reply-To: <b0bd715c-5d20-5abf-09f6-1c5060feeca7@oracle.com>
References: <583F2F0C.7050206@oracle.com>
	<b0bd715c-5d20-5abf-09f6-1c5060feeca7@oracle.com>
Message-ID: <5840826A.8060901@oracle.com>

David,
I will not push this to 9.
Max

On 11/30/2016 9:42 PM, David Holmes wrote:
> Hi Max,
>
> Seems okay.
>
> If you plan top push to 9 please change the "Fix version" in the bug 
> first, else a backport for 9 will be created.
>
> Thanks,
> David
>
> On 1/12/2016 5:57 AM, Max Ockner wrote:
>> Hello everyone!
>>
>> Please review this small fix which removes some dead code from the
>> interpreter. TemplateInterpreter::_continuation_entry table and its
>> accessor are never called from anywhere else.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169206
>> Webrev: http://cr.openjdk.java.net/~mockner/8169206.01/
>>
>> Tested with java -version.
>>
>> Thanks,
>> Max
>>
>>
>>
>>


From max.ockner at oracle.com  Thu Dec  1 20:21:34 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 01 Dec 2016 15:21:34 -0500
Subject: RFR(s): 8169206: TemplateInterpreter::_continuation_entry is
	never referenced
In-Reply-To: <c5a9cbe3-81bf-4bfc-09ba-14ba4cbbe8d5@oracle.com>
References: <583F2F0C.7050206@oracle.com>
	<c5a9cbe3-81bf-4bfc-09ba-14ba4cbbe8d5@oracle.com>
Message-ID: <5840864E.2070503@oracle.com>

I have removed the 
TemplateInterpreterGenerator::generate_continuation_for() methods for 
each platform.
New webrev: http://cr.openjdk.java.net/~mockner/8169206.02/

Thanks,
Max

On 11/30/2016 10:09 PM, Coleen Phillimore wrote:
>
> Hi Max,
>
> You didn't remove the platform specific 
> TemplateInterpreterGenerator::generate_continuation_for() methods.
>
> I think from ancient history, these used to be used for reexecuting 
> the bytecode after rewriting to the fast version from within 
> InterpreterRuntime.  That code's been long dead!
>
> Thanks - this will be a good cleanup for jdk10.
> Coleen
>
> On 11/30/16 2:57 PM, Max Ockner wrote:
>> Hello everyone!
>>
>> Please review this small fix which removes some dead code from the 
>> interpreter. TemplateInterpreter::_continuation_entry table and its 
>> accessor are never called from anywhere else.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169206
>> Webrev: http://cr.openjdk.java.net/~mockner/8169206.01/
>>
>> Tested with java -version.
>>
>> Thanks,
>> Max
>>
>>
>>
>>
>


From coleen.phillimore at oracle.com  Thu Dec  1 20:27:26 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 1 Dec 2016 15:27:26 -0500
Subject: RFR(s): 8169206: TemplateInterpreter::_continuation_entry is
	never referenced
In-Reply-To: <5840864E.2070503@oracle.com>
References: <583F2F0C.7050206@oracle.com>
	<c5a9cbe3-81bf-4bfc-09ba-14ba4cbbe8d5@oracle.com>
	<5840864E.2070503@oracle.com>
Message-ID: <f43d7eec-44e9-1213-6a78-f9c02d0a82fa@oracle.com>

Looks great!   It can be the first cleanup of jdk10!
Coleen

On 12/1/16 3:21 PM, Max Ockner wrote:
> I have removed the 
> TemplateInterpreterGenerator::generate_continuation_for() methods for 
> each platform.
> New webrev: http://cr.openjdk.java.net/~mockner/8169206.02/
>
> Thanks,
> Max
>
> On 11/30/2016 10:09 PM, Coleen Phillimore wrote:
>>
>> Hi Max,
>>
>> You didn't remove the platform specific 
>> TemplateInterpreterGenerator::generate_continuation_for() methods.
>>
>> I think from ancient history, these used to be used for reexecuting 
>> the bytecode after rewriting to the fast version from within 
>> InterpreterRuntime.  That code's been long dead!
>>
>> Thanks - this will be a good cleanup for jdk10.
>> Coleen
>>
>> On 11/30/16 2:57 PM, Max Ockner wrote:
>>> Hello everyone!
>>>
>>> Please review this small fix which removes some dead code from the 
>>> interpreter. TemplateInterpreter::_continuation_entry table and its 
>>> accessor are never called from anywhere else.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169206
>>> Webrev: http://cr.openjdk.java.net/~mockner/8169206.01/
>>>
>>> Tested with java -version.
>>>
>>> Thanks,
>>> Max
>>>
>>>
>>>
>>>
>>
>


From david.holmes at oracle.com  Fri Dec  2 01:05:08 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Dec 2016 11:05:08 +1000
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <CAA-vtUz90ghciheBqaCT_TXKM6_ZiiuXXPq_RJd7uRoWMx1eQQ@mail.gmail.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
	<6ca3fcd2-e08a-2f4d-4884-d539842cbd18@ubuntu.com>
	<CAA-vtUz90ghciheBqaCT_TXKM6_ZiiuXXPq_RJd7uRoWMx1eQQ@mail.gmail.com>
Message-ID: <1e2656b9-3b9c-75c5-5e02-23c71de44e06@oracle.com>

FYI I have filed an enhancement request for this:

https://bugs.openjdk.java.net/browse/JDK-8170639

On 2/12/2016 5:08 AM, Thomas St?fe wrote:
> On Thu, Dec 1, 2016 at 2:36 PM, Matthias Klose <doko at ubuntu.com
> <mailto:doko at ubuntu.com>> wrote:
>
>     On 01.12.2016 14:20, David Holmes wrote:
>     > That said, given that this patch does nothing to fix the supported OpenJDK 9
>
>     where can I find the list of supported platforms? Is zero a
>     supported platform?
>
>
> Well, there is that:
>
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>
> But this seems to be a bit outdated, I do not see arm nor the new s390
> port. Should this be updated? If yes, should this be updated by the port
> maintainers?

The Build Group owns that wiki so they would have to update it. And of 
course the set of build platforms is not the same as the set of execute 
platforms. But yes Aarch64 and S390 should be added.

There doesn't seem to be a list of official OpenJDK runtime platforms, 
but it can be inferred by looking at the various Port projects, their 
JEPS and status.

>>     > platforms it would have to be considered an enhancement and we are closed to new
>>     > enhancements for JDK 9. The JDK 10 repos will be opening very soon though,
>>
>>     same here:
>>     http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004819.html
>>     <http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004819.html>
>>
>> How can these porting patches find it's way into jdk9? I see that
>> JEPs for three new hotspot ports were accepted after September.

The JDK 9 schedule was modified after that post [1] and we did not in 
fact enter RDP1 at that time. Additional features were allowed to be 
added under an extension mechanism, the deadline for completion of such 
is Dec 22. However that is for final code to reach the master forest and 
so we are effectively "closed" in the hotspot forest in terms of 
starting anything new. It may not be impossible but it would require 
significant justification and very quick work.

>> Is
>> this the right way to write a JEP for each zero port, or would these
>> fixes considered for backporting into jdk9?>
>
> I always thought the point of the zero port was to just work on any
> platform with a C++ compiler, and therefore does not constitute a real
> porting platform. So, any error on zero for any architecture would be
> handled as just a bug. I may be wrong here, so please correct me if I am
> wrong.

Zero "ports" are not considered OpenJDK ports so do not normally need 
JEPs (unless Zero itself is undergoing some major enhancement to support 
a new platform).

For the most part we rely on the Zero maintainers to report any issues 
that other changes cause with Zero, or where Zero needs to be updated to 
support platform X and we do work together to get things fixed. That 
said, if someone tries to build Zero for platform X, and that in turn 
requires changes to platform specific VM code unrelated to Zero itself, 
then that is a different matter.

A change, like has been requested, which simply changes to using more 
standard mechanisms is obviously an acceptable request (unfortunately 
just not now for JDK 9) - however if it required an "ifdef MIPS" then 
that would not be acceptable.

The question of "backporting to 9" can't be answered until there is a "9 
update" project and it defines what its back porting policy is.

Thanks,
David
-----

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005092.html

> ..Thomas
>
>
>     Matthias
>
>

From david.holmes at oracle.com  Fri Dec  2 01:29:36 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Dec 2016 11:29:36 +1000
Subject: RFR(s): 8169206: TemplateInterpreter::_continuation_entry is
	never referenced
In-Reply-To: <5840864E.2070503@oracle.com>
References: <583F2F0C.7050206@oracle.com>
	<c5a9cbe3-81bf-4bfc-09ba-14ba4cbbe8d5@oracle.com>
	<5840864E.2070503@oracle.com>
Message-ID: <d1a6a81e-2767-55ad-92ab-c58a77447ecf@oracle.com>

Looks good.

Thanks,
David

On 2/12/2016 6:21 AM, Max Ockner wrote:
> I have removed the
> TemplateInterpreterGenerator::generate_continuation_for() methods for
> each platform.
> New webrev: http://cr.openjdk.java.net/~mockner/8169206.02/
>
> Thanks,
> Max
>
> On 11/30/2016 10:09 PM, Coleen Phillimore wrote:
>>
>> Hi Max,
>>
>> You didn't remove the platform specific
>> TemplateInterpreterGenerator::generate_continuation_for() methods.
>>
>> I think from ancient history, these used to be used for reexecuting
>> the bytecode after rewriting to the fast version from within
>> InterpreterRuntime.  That code's been long dead!
>>
>> Thanks - this will be a good cleanup for jdk10.
>> Coleen
>>
>> On 11/30/16 2:57 PM, Max Ockner wrote:
>>> Hello everyone!
>>>
>>> Please review this small fix which removes some dead code from the
>>> interpreter. TemplateInterpreter::_continuation_entry table and its
>>> accessor are never called from anywhere else.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169206
>>> Webrev: http://cr.openjdk.java.net/~mockner/8169206.01/
>>>
>>> Tested with java -version.
>>>
>>> Thanks,
>>> Max
>>>
>>>
>>>
>>>
>>
>

From david.holmes at oracle.com  Fri Dec  2 01:57:00 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Dec 2016 11:57:00 +1000
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <724185737.1372541.1480603805989.JavaMail.zimbra@redhat.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
	<724185737.1372541.1480603805989.JavaMail.zimbra@redhat.com>
Message-ID: <3bf1cdf8-a2f4-ba32-ea79-7815e9abd20a@oracle.com>

On 2/12/2016 12:50 AM, Christine Flood wrote:
> Unfortunately, if you aren't actually inside a cgroup, /sys/fs/cgroup/memory/memory.limit_in_bytes still exists and contains an apparently bogus value.  I've got a question in to the docker folks to find out why.

Is that the "unlimited" value that you get even if running in a cgroup 
but without setting a memory limit?

As I wrote in the bug report when initially investigating this there 
seem to be a lot of issues with even knowing what to read:

"/sys/fs/cgroup/ is the recommended location for cgroup hierarchies, but 
it is not a standard. If a tool or library is trying to read from it, 
and be portable across multiple container implementations, it would need 
to discover the location first by parsing /proc/self/cgroup and 
/proc/self/mountinfo. Further, /sys/fs/cgroup is just an umbrella for 
all cgroup hierarchies, there is no recommendation or standard for my 
own cgroup location."

https://fabiokung.com/2014/03/13/memory-inside-linux-containers/

> In the short term, providing a runtime flag gives us a way to protect customers that are running inside a container and not change the current behavior for everyone else.

Ok - at best this enhancement would be an experimental flag that users 
would have to opt in to.

But the enhancement door is barely still open for JDK 9.

David
-----

> Christine
>
> ----- Original Message -----
>> From: "Mikael Vidstedt" <mikael.vidstedt at oracle.com>
>> To: "Christine Flood" <chf at redhat.com>
>> Cc: hotspot-dev at openjdk.java.net
>> Sent: Wednesday, November 30, 2016 5:53:41 PM
>> Subject: Re: Java heap size defaults when running with CGroups in Linux.
>>
>>
>> Out of curiosity, why wouldn?t this be the default behavior? That is, in
>> which cases is it not a good idea to use the cgroup information when sizing
>> the JVM?
>>
>> Cheers,
>> Mikael
>>
>>
>>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>>>
>>>
>>> The problem is that when running the JVM inside of a cgroup, such as
>>> docker, the JVM bases it's default heap parameters on the size of the
>>> whole machine's memory not on the memory available to the container.  This
>>> causes errors as discussed on this blog entry.
>>> http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>>>
>>> Basically the JVM dies in a non-obvious manner.
>>>
>>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to the
>>> JVM which states that you should look to the CGroup when calculating
>>> default heap sizes.
>>>
>>> Webrev is here:  http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>>>
>>>
>>> Christine
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>

From david.holmes at oracle.com  Fri Dec  2 05:51:00 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Dec 2016 15:51:00 +1000
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
Message-ID: <e91de716-f607-1530-b009-70c411e9c6de@oracle.com>

Investigating this further the history is quite complex, especially when 
we start looking at other platforms. E.g. see

https://bugs.openjdk.java.net/browse/JDK-6269555

Solaris actually hard-wires an 8MB limit for the primordial thread.

I'm very tempted to do the same on Linux.

David
-----

On 30/11/2016 6:46 PM, David Holmes wrote:
> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>
>>         I just realized I overlooked the case where ThreadStackSize=0
>>         and the
>>         stack is unlimited. In that case it isn't clear where the guard
>>         pages
>>         will get inserted - I do know that I don't get a stackoverflow
>>         error.
>>
>>         This needs further investigation.
>>
>>
>>     So what happens here is that the massive stack-size causes
>>     stack-bottom to be higher than stack-top! So we will set a
>>     guard-page goodness knows where, and we can consume the current
>>     stack until such time as we hit an unmapped or protected region at
>>     which point we are killed.
>>
>>     I'm not sure what to do here. My gut feel is that in such a case we
>>     should not attempt to create a guard page in the initial thread.
>>     That would require using a sentinel value for the stack-size. Though
>>     it also presents a problem for stack-bottom - which is implicitly
>>     zero. It may also give false positives in the is_initial_thread()
>> check!
>>
>>     Thoughts? Suggestions?
>>
>>
>> Maybe I am overlooking something, but should
>> os::capture_initial_thread() not call pthread_getattr_np() first to
>> handle the case where the VM was created on a pthread which is not the
>> primordial thread and may have a different stack size than what
>> getrlimit returns? And fall back to getrlimit only if
>> pthread_getattr_np() fails?
>
> My understanding of the problem (which likely no longer exists) is that
> pthread_getattr_np didn't fail as such but returned bogus values - so
> the problem was not detectable and so we just had to not use
> pthread_getattr_np.
>
>> And then we also should handle
>> RLIM_INFINITY. For that case, I also think not setting guard pages would
>> be safest.
>>
>> We also may just refuse to run in that case, because the workaround for
>> the user is easy - just set the limit before process start. Note that on
>> AIX, we currently refuse to run on the primordial thread because it may
>> have different page sizes than pthreads and it is impossible to get the
>> exact stack locations.
>
> I was wondering why the AIX set up seemed so simple in comparison :)
>
> Thanks,
> David
>
>>
>> Thomas
>>
>>
>>
>>         David
>>
>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>
>>             Hi Thomas,
>>
>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>
>>                 Hi David,
>>
>>                 thanks for the good explanation. Change looks good, I
>>                 really like the
>>                 comment in capture_initial_stack().
>>
>>                 Question, with -Xss given and being smaller than current
>>                 thread stack
>>                 size, guard pages may appear in the middle of the
>>                 invoking thread stack?
>>                 I always thought this is a bit dangerous. If your model
>>                 is to have the
>>                 VM created from the main thread, which then goes off to
>>                 do different
>>                 things, and have other threads then attach and run java
>>                 code, main
>>                 thread later may crash in unrelated native code just
>>                 because it reached
>>                 the stack depth of the hava threads? Or am I
>>                 misunderstanding something?
>>
>>
>>             There is no change to the general behaviour other than
>>             allowing a
>>             primordial process thread that launches the VM, to now not
>>             have an
>>             effective stack limited at 2MB. The current logic will
>>             insert guard
>>             pages where ever -Xss states (as long as less than 2MB else
>>             2MB), while
>>             with the fix the guard pages will be inserted above 2MB - as
>>             dictated by
>>             -Xss.
>>
>>             David
>>             -----
>>
>>                 Thanks, Thomas
>>
>>
>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>                 <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>                 <mailto:david.holmes at oracle.com
>>                 <mailto:david.holmes at oracle.com>>> wrote:
>>
>>                     Bug:
>>                 https://bugs.openjdk.java.net/browse/JDK-8170307
>>                 <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>                     <https://bugs.openjdk.java.net/browse/JDK-8170307
>>                 <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>
>>                     The bug is not public unfortunately for
>>                 non-technical reasons - but
>>                     see my eval below.
>>
>>                     Background: if you load the JVM from the primordial
>>                 thread of a
>>                     process (not done by the java launcher since JDK 6),
>>                 there is an
>>                     artificial stack limit imposed on the initial thread
>>                 (by sticking
>>                     the guard page at the limit position of the actual
>>                 stack) of the
>>                     minimum of the -Xss setting and 2M. So if you set
>>                 -Xss to > 2M it is
>>                     ignored for the main thread even if the true stack
>>                 is, say, 8M. This
>>                     limitation dates back 10-15 years and is no longer
>>                 relevant today
>>                     and should be removed (see below). I've also added
>>                 additional
>>                     explanatory notes.
>>
>>                     webrev:
>>                 http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>                 <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>                     <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>                 <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>
>>                     Testing was manually done by modifying the launcher
>>                 to not run the
>>                     VM in a new thread, and checking the resulting stack
>>                 size used.
>>
>>                     This change will only affect hosted JVMs launched
>>                 with a -Xss value
>>                     > 2M.
>>
>>                     Thanks,
>>                     David
>>                     -----
>>
>>                     Bug eval:
>>
>>                     JDK-4441425 limits the stack to 8M as a safeguard
>>                 against an
>>                     unlimited value from getrlimit in 1.3.1, but further
>>                 constrained
>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>
>>                     By 1.4.2 we have the basic form of the current
>>                 problematic code:
>>
>>                     #ifndef IA64
>>                       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur = 2 *
>>                 K * K;
>>                     #else
>>                       // Problem still exists RH7.2 (IA64 anyway) but
>>                 2MB is a little
>>                 small
>>                       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur = 4 *
>>                 K * K;
>>                     #endif
>>
>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>                 ~(page_size() - 1);
>>
>>                       if (max_size && _initial_thread_stack_size >
>>                 max_size) {
>>                          _initial_thread_stack_size = max_size;
>>                       }
>>
>>                     This was added by JDK-4678676 to allow the stack of
>>                 the main thread
>>                     to be _reduced_ below the default 2M/4M if the -Xss
>>                 value was
>>                     smaller than that.** There was no intent to allow
>>                 the stack size to
>>                     follow -Xss arbitrarily due to the operational
>>                 constraints imposed
>>                     by the OS/glibc at the time when dealing with the
>>                 primordial process
>>                     thread.
>>
>>                     ** It could not actually change the actual stack
>>                 size of course, but
>>                     set the guard pages to limit use to the expected
>>                 stack size.
>>
>>                     In JDK 6, under JDK-6316197, the launcher was
>>                 changed to create the
>>                     JVM in a new thread, so that it was not limited by
>> the
>>                     idiosyncracies of the OS or thread library
>>                 primordial thread
>>                     handling. However, the stack size limitations
>>                 remained in place in
>>                     case the VM was launched from the primordial thread
>>                 of a user
>>                     application via the JNI invocation API.
>>
>>                     I believe it should be safe to remove the 2M
>>                 limitation now.
>>
>>
>>

From magnus.ihse.bursie at oracle.com  Fri Dec  2 09:24:28 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2016 10:24:28 +0100
Subject: RFR: JDK-8170629 Remove code duplication in test makefiles
Message-ID: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>

There is a lot of common code that has been duplicated in 
*/test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code in 
the corresponding files are identical. (The odd-man-out is langtools 
which is quite different.)

These files should be unified to share a single code base, to facilitate 
further improvements to the test makefiles.

The intent of this bug is a pure refactoring. The duplication should go, 
but all functionality should remain exactly the same. This will leave 
room for some future improvements to the code, but sets a clear limit 
for this first step. The consolidated code base thus contains a fair 
amount of if-blocks, but I hope to be able to address most of these 
later on, by adjusting the individual component to adhere more to the 
standard behavior.

To minimize the amount of ifdefs in the shared code, I allowed for a few 
changes in behavior. I do not believe these will cause any changes in 
the real world, and to the extent that they do, they could be considered 
bug fixes.

Behavior that have changed due to unification:
* jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
* jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
* jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
* hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists.
* hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.

Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01

/Magnus

From erik.joelsson at oracle.com  Fri Dec  2 11:56:58 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 2 Dec 2016 12:56:58 +0100
Subject: RFR: JDK-8170629 Remove code duplication in test makefiles
In-Reply-To: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
References: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
Message-ID: <5d130cb7-794f-9fec-51aa-6ecd432847da@oracle.com>

Looks good.

/Erik

On 2016-12-02 10:24, Magnus Ihse Bursie wrote:
> There is a lot of common code that has been duplicated in 
> */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code 
> in the corresponding files are identical. (The odd-man-out is 
> langtools which is quite different.)
>
> These files should be unified to share a single code base, to 
> facilitate further improvements to the test makefiles.
>
> The intent of this bug is a pure refactoring. The duplication should 
> go, but all functionality should remain exactly the same. This will 
> leave room for some future improvements to the code, but sets a clear 
> limit for this first step. The consolidated code base thus contains a 
> fair amount of if-blocks, but I hope to be able to address most of 
> these later on, by adjusting the individual component to adhere more 
> to the standard behavior.
>
> To minimize the amount of ifdefs in the shared code, I allowed for a 
> few changes in behavior. I do not believe these will cause any changes 
> in the real world, and to the extent that they do, they could be 
> considered bug fixes.
>
> Behavior that have changed due to unification:
> * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
> * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
> * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
> * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists.
> * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01
>
> /Magnus


From trevor.d.watson at oracle.com  Fri Dec  2 14:23:35 2016
From: trevor.d.watson at oracle.com (Trevor Watson)
Date: Fri, 2 Dec 2016 14:23:35 +0000
Subject: RFR: 8162865 Implementation of SPARC lzcnt
In-Reply-To: <583F262E.9020604@oracle.com>
References: <ee7dcf6d-f22f-ad4a-d751-7592a2463471@oracle.com>
	<1f9581e5-3bed-dec3-ec4b-81b5e3e6d478@oracle.com>
	<8e47a2d0-c823-4d74-89bf-831c08a8f10d@oracle.com>
	<583F262E.9020604@oracle.com>
Message-ID: <a2dd55c0-9443-2c65-bf27-d99615375fdb@oracle.com>

Hey Vladimir,

Sorry I missed the copyright thing. Too much copying of files ;)
I updated that and also tweaked the implementation of lzcnt for Integer 
to remove the use of the temp register after another reviewer suggested 
it could be done.

Revised code review is in the same place as the original.

I'll wait until JDK 10 repo is open before asking for a sponsor.

Cheers,
Trevor

On 30/11/16 19:19, Vladimir Kozlov wrote:
> Looks good. Only one small issue - new tests files should have only 2016
> year:
>
> * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
>
> Changes have to wait when JDK 10 repo is open. It is Enhancement and we
> done with new features in JDK 9 already.
>
> Thanks,
> Vladimir
>
> On 11/30/16 7:29 AM, Trevor Watson wrote:
>> Hi Vladimir,
>>
>> Thanks for the review. Comments inline below...
>>
>> On 22/11/16 20:04, Vladimir Kozlov wrote:
>>> Do you have performance numbers?
>>
>> I've spent a lot of time looking at performance and it's proving
>> verify difficult to precisely quantify either on a T5 or an S7.
>> However, overall, it would appear that using the native lzcnt
>> instruction is around 10% quicker than the current implementation
>> which uses POPC.
>>
>>> UseVIS is too wide flag to control only these instructions generation.
>>>
>>> To be consistent with x86 code please add
>>> UseCountLeadingZerosInstruction flag to globals_sparc.hpp and its
>>> setting in vm_version_sparc.cpp (based on has_vis3()) similar to what is
>>> done for x86.
>>
>> I've done this and it actually proved useful in testing as I was able
>> to turn off lzcnt and use popc and vice-versa :)
>>
>>> May be name new instructions *ZerosIvis instead of *ZerosI1 to be clear
>>> that VIS is used.
>>
>> Done.
>>
>>> Indention in the new test is all over place. Please, fix.
>>
>> I've fixed it (I hope) and broken the test up into separate Integer
>> and Long tests to be consistent with the rest of the BMI tests in that
>> directory.
>>
>> I've run the jtreg bmi tests on Solaris 12 SPARC and x86 and am
>> awaiting the results of a jprt (hotspot) run on all platforms.
>>
>> The code review is in the same place as before:
>>>> http://cr.openjdk.java.net/~alanbur/8162865/
>>
>> Thanks,
>> Trevor

From igor.ignatyev at oracle.com  Fri Dec  2 19:27:36 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 2 Dec 2016 22:27:36 +0300
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
Message-ID: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
> 115 lines changed: 97 ins; 17 del; 1 mod;

Hi all,

could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?

a bit of background:
there are two cases when one wants to remove a test from test execution:
 - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
 - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.

in two words, @ignore to exclude, ProblemList to quarantine.

webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8078450

Thanks,
? Igor

From bob.vandette at oracle.com  Fri Dec  2 20:28:41 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 2 Dec 2016 15:28:41 -0500
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
Message-ID: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>

Please review the proposed changes to be integrated under JEP 297.

Summary:

This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.

This changeset also removes the support for the pregenerated interpreter since
this is no longer supported.

The addition of arm64 does not replace the existing aarch64 port.  A new configure 
option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the 
64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.

JEP 297:

https://bugs.openjdk.java.net/browse/JDK-8168503

Webrev:

http://cr.openjdk.java.net/~bobv/8168503


Note:

A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264

Thanks,
Bob Vandette


From daniel.daugherty at oracle.com  Fri Dec  2 23:12:52 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 2 Dec 2016 16:12:52 -0700
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
Message-ID: <07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>

On 12/1/16 10:51 PM, David Holmes wrote:
> Investigating this further the history is quite complex, especially 
> when we start looking at other platforms. E.g. see
>
> https://bugs.openjdk.java.net/browse/JDK-6269555
>
> Solaris actually hard-wires an 8MB limit for the primordial thread.
>
> I'm very tempted to do the same on Linux.

Vote: yes

This latest problem only comes up with -XX:ThreadStackSize=0 when the
stack is unlimited right?

When -XX:ThreadStackSize=0 is specified, is taking the smaller of
8MB or the ulimit a viable option?

Also, it looks like Hui had some things to say about not setting the
red/yellow zone pages on the primordial thread when we aren't using the
'java' launcher because we don't know the environment of the code that
is using the JNI invocation API...

Dan


>
> David
> -----
>
> On 30/11/2016 6:46 PM, David Holmes wrote:
>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>
>>>         I just realized I overlooked the case where ThreadStackSize=0
>>>         and the
>>>         stack is unlimited. In that case it isn't clear where the guard
>>>         pages
>>>         will get inserted - I do know that I don't get a stackoverflow
>>>         error.
>>>
>>>         This needs further investigation.
>>>
>>>
>>>     So what happens here is that the massive stack-size causes
>>>     stack-bottom to be higher than stack-top! So we will set a
>>>     guard-page goodness knows where, and we can consume the current
>>>     stack until such time as we hit an unmapped or protected region at
>>>     which point we are killed.
>>>
>>>     I'm not sure what to do here. My gut feel is that in such a case we
>>>     should not attempt to create a guard page in the initial thread.
>>>     That would require using a sentinel value for the stack-size. 
>>> Though
>>>     it also presents a problem for stack-bottom - which is implicitly
>>>     zero. It may also give false positives in the is_initial_thread()
>>> check!
>>>
>>>     Thoughts? Suggestions?
>>>
>>>
>>> Maybe I am overlooking something, but should
>>> os::capture_initial_thread() not call pthread_getattr_np() first to
>>> handle the case where the VM was created on a pthread which is not the
>>> primordial thread and may have a different stack size than what
>>> getrlimit returns? And fall back to getrlimit only if
>>> pthread_getattr_np() fails?
>>
>> My understanding of the problem (which likely no longer exists) is that
>> pthread_getattr_np didn't fail as such but returned bogus values - so
>> the problem was not detectable and so we just had to not use
>> pthread_getattr_np.
>>
>>> And then we also should handle
>>> RLIM_INFINITY. For that case, I also think not setting guard pages 
>>> would
>>> be safest.
>>>
>>> We also may just refuse to run in that case, because the workaround for
>>> the user is easy - just set the limit before process start. Note 
>>> that on
>>> AIX, we currently refuse to run on the primordial thread because it may
>>> have different page sizes than pthreads and it is impossible to get the
>>> exact stack locations.
>>
>> I was wondering why the AIX set up seemed so simple in comparison :)
>>
>> Thanks,
>> David
>>
>>>
>>> Thomas
>>>
>>>
>>>
>>>         David
>>>
>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>
>>>             Hi Thomas,
>>>
>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>
>>>                 Hi David,
>>>
>>>                 thanks for the good explanation. Change looks good, I
>>>                 really like the
>>>                 comment in capture_initial_stack().
>>>
>>>                 Question, with -Xss given and being smaller than 
>>> current
>>>                 thread stack
>>>                 size, guard pages may appear in the middle of the
>>>                 invoking thread stack?
>>>                 I always thought this is a bit dangerous. If your model
>>>                 is to have the
>>>                 VM created from the main thread, which then goes off to
>>>                 do different
>>>                 things, and have other threads then attach and run java
>>>                 code, main
>>>                 thread later may crash in unrelated native code just
>>>                 because it reached
>>>                 the stack depth of the hava threads? Or am I
>>>                 misunderstanding something?
>>>
>>>
>>>             There is no change to the general behaviour other than
>>>             allowing a
>>>             primordial process thread that launches the VM, to now not
>>>             have an
>>>             effective stack limited at 2MB. The current logic will
>>>             insert guard
>>>             pages where ever -Xss states (as long as less than 2MB else
>>>             2MB), while
>>>             with the fix the guard pages will be inserted above 2MB 
>>> - as
>>>             dictated by
>>>             -Xss.
>>>
>>>             David
>>>             -----
>>>
>>>                 Thanks, Thomas
>>>
>>>
>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>                 <david.holmes at oracle.com 
>>> <mailto:david.holmes at oracle.com>
>>>                 <mailto:david.holmes at oracle.com
>>>                 <mailto:david.holmes at oracle.com>>> wrote:
>>>
>>>                     Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>
>>>                     The bug is not public unfortunately for
>>>                 non-technical reasons - but
>>>                     see my eval below.
>>>
>>>                     Background: if you load the JVM from the primordial
>>>                 thread of a
>>>                     process (not done by the java launcher since JDK 
>>> 6),
>>>                 there is an
>>>                     artificial stack limit imposed on the initial 
>>> thread
>>>                 (by sticking
>>>                     the guard page at the limit position of the actual
>>>                 stack) of the
>>>                     minimum of the -Xss setting and 2M. So if you set
>>>                 -Xss to > 2M it is
>>>                     ignored for the main thread even if the true stack
>>>                 is, say, 8M. This
>>>                     limitation dates back 10-15 years and is no longer
>>>                 relevant today
>>>                     and should be removed (see below). I've also added
>>>                 additional
>>>                     explanatory notes.
>>>
>>>                     webrev:
>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>
>>>                     Testing was manually done by modifying the launcher
>>>                 to not run the
>>>                     VM in a new thread, and checking the resulting 
>>> stack
>>>                 size used.
>>>
>>>                     This change will only affect hosted JVMs launched
>>>                 with a -Xss value
>>>                     > 2M.
>>>
>>>                     Thanks,
>>>                     David
>>>                     -----
>>>
>>>                     Bug eval:
>>>
>>>                     JDK-4441425 limits the stack to 8M as a safeguard
>>>                 against an
>>>                     unlimited value from getrlimit in 1.3.1, but 
>>> further
>>>                 constrained
>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>
>>>                     By 1.4.2 we have the basic form of the current
>>>                 problematic code:
>>>
>>>                     #ifndef IA64
>>>                       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur = 
>>> 2 *
>>>                 K * K;
>>>                     #else
>>>                       // Problem still exists RH7.2 (IA64 anyway) but
>>>                 2MB is a little
>>>                 small
>>>                       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur = 
>>> 4 *
>>>                 K * K;
>>>                     #endif
>>>
>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>                 ~(page_size() - 1);
>>>
>>>                       if (max_size && _initial_thread_stack_size >
>>>                 max_size) {
>>>                          _initial_thread_stack_size = max_size;
>>>                       }
>>>
>>>                     This was added by JDK-4678676 to allow the stack of
>>>                 the main thread
>>>                     to be _reduced_ below the default 2M/4M if the -Xss
>>>                 value was
>>>                     smaller than that.** There was no intent to allow
>>>                 the stack size to
>>>                     follow -Xss arbitrarily due to the operational
>>>                 constraints imposed
>>>                     by the OS/glibc at the time when dealing with the
>>>                 primordial process
>>>                     thread.
>>>
>>>                     ** It could not actually change the actual stack
>>>                 size of course, but
>>>                     set the guard pages to limit use to the expected
>>>                 stack size.
>>>
>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>                 changed to create the
>>>                     JVM in a new thread, so that it was not limited by
>>> the
>>>                     idiosyncracies of the OS or thread library
>>>                 primordial thread
>>>                     handling. However, the stack size limitations
>>>                 remained in place in
>>>                     case the VM was launched from the primordial thread
>>>                 of a user
>>>                     application via the JNI invocation API.
>>>
>>>                     I believe it should be safe to remove the 2M
>>>                 limitation now.
>>>
>>>
>>>


From serguei.spitsyn at oracle.com  Sat Dec  3 00:57:23 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 2 Dec 2016 16:57:23 -0800
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
Message-ID: <390edb70-47e3-9754-d8da-1260d8b655b9@oracle.com>

Hi Igor,

It looks good to me.
Thank you for taking care about this.

One minor question on the comment:

http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/test/Makefile.udiff.html 


+# convert list of directories to *dos* paths What does "dos" mean here?


Thanks,
Serguei


On 12/2/16 11:27, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>> 115 lines changed: 97 ins; 17 del; 1 mod;
> Hi all,
>
> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>
> a bit of background:
> there are two cases when one wants to remove a test from test execution:
>   - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>   - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>
> in two words, @ignore to exclude, ProblemList to quarantine.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>
> Thanks,
> ? Igor


From vladimir.kozlov at oracle.com  Sat Dec  3 01:04:53 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 2 Dec 2016 17:04:53 -0800
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
Message-ID: <58421A35.5070706@oracle.com>

hi Bob,

I would suggest to have separate webrevs for different repositories because different groups should look on them.

For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net

Why do you need cahnges in SA libproc.h?

I saw Hotspot changes before and I think they are fine (did not dive deep).

Thanks,
Vladimir

On 12/2/16 12:28 PM, Bob Vandette wrote:
> Please review the proposed changes to be integrated under JEP 297.
>
> Summary:
>
> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>
> This changeset also removes the support for the pregenerated interpreter since
> this is no longer supported.
>
> The addition of arm64 does not replace the existing aarch64 port.  A new configure
> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>
> JEP 297:
>
> https://bugs.openjdk.java.net/browse/JDK-8168503
>
> Webrev:
>
> http://cr.openjdk.java.net/~bobv/8168503
>
>
> Note:
>
> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>
> Thanks,
> Bob Vandette
>

From david.holmes at oracle.com  Sat Dec  3 04:11:08 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 3 Dec 2016 14:11:08 +1000
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
Message-ID: <1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>

On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
> On 12/1/16 10:51 PM, David Holmes wrote:
>> Investigating this further the history is quite complex, especially
>> when we start looking at other platforms. E.g. see
>>
>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>
>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>
>> I'm very tempted to do the same on Linux.
>
> Vote: yes

Excellent! Other votes?

> This latest problem only comes up with -XX:ThreadStackSize=0 when the
> stack is unlimited right?

Right.

> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
> 8MB or the ulimit a viable option?

I think so.

> Also, it looks like Hui had some things to say about not setting the
> red/yellow zone pages on the primordial thread when we aren't using the
> 'java' launcher because we don't know the environment of the code that
> is using the JNI invocation API...

Yeah but those comments seem a bit confused to me. They suggest we 
shouldn't add guard pages but in fact we do add guard pages. And to me 
it is no different in the primordial thread than any other natively 
attached thread ie why should the initially attached thread be treated 
differently to any other?** I suspect if I keep researching on this I 
will find bugs regarding such differences in behaviour (eg the fact that 
-Xss wasn't working on the main thread).

** There are arguments both ways as to how natively attached threads 
should behave. The main argument against guard page insertion is that we 
don't know how far down the existing stack we actually are - we could be 
past the depth where the guard page would be inserted! The main argument 
for (which seems to have won the day) is so that we don't get arbitrary 
differences in behaviour between threads created and attached by 
application native code; and threads created direct from application 
Java code.

Anyway, simply upping the 2M limit on Linux to 8M seems a simple 
solution - assuming it addresses the needs of the folk that ran into 
this problem.

Thanks,
David

> Dan
>
>
>>
>> David
>> -----
>>
>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>
>>>>         I just realized I overlooked the case where ThreadStackSize=0
>>>>         and the
>>>>         stack is unlimited. In that case it isn't clear where the guard
>>>>         pages
>>>>         will get inserted - I do know that I don't get a stackoverflow
>>>>         error.
>>>>
>>>>         This needs further investigation.
>>>>
>>>>
>>>>     So what happens here is that the massive stack-size causes
>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>     guard-page goodness knows where, and we can consume the current
>>>>     stack until such time as we hit an unmapped or protected region at
>>>>     which point we are killed.
>>>>
>>>>     I'm not sure what to do here. My gut feel is that in such a case we
>>>>     should not attempt to create a guard page in the initial thread.
>>>>     That would require using a sentinel value for the stack-size.
>>>> Though
>>>>     it also presents a problem for stack-bottom - which is implicitly
>>>>     zero. It may also give false positives in the is_initial_thread()
>>>> check!
>>>>
>>>>     Thoughts? Suggestions?
>>>>
>>>>
>>>> Maybe I am overlooking something, but should
>>>> os::capture_initial_thread() not call pthread_getattr_np() first to
>>>> handle the case where the VM was created on a pthread which is not the
>>>> primordial thread and may have a different stack size than what
>>>> getrlimit returns? And fall back to getrlimit only if
>>>> pthread_getattr_np() fails?
>>>
>>> My understanding of the problem (which likely no longer exists) is that
>>> pthread_getattr_np didn't fail as such but returned bogus values - so
>>> the problem was not detectable and so we just had to not use
>>> pthread_getattr_np.
>>>
>>>> And then we also should handle
>>>> RLIM_INFINITY. For that case, I also think not setting guard pages
>>>> would
>>>> be safest.
>>>>
>>>> We also may just refuse to run in that case, because the workaround for
>>>> the user is easy - just set the limit before process start. Note
>>>> that on
>>>> AIX, we currently refuse to run on the primordial thread because it may
>>>> have different page sizes than pthreads and it is impossible to get the
>>>> exact stack locations.
>>>
>>> I was wondering why the AIX set up seemed so simple in comparison :)
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>         David
>>>>
>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>
>>>>             Hi Thomas,
>>>>
>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>
>>>>                 Hi David,
>>>>
>>>>                 thanks for the good explanation. Change looks good, I
>>>>                 really like the
>>>>                 comment in capture_initial_stack().
>>>>
>>>>                 Question, with -Xss given and being smaller than
>>>> current
>>>>                 thread stack
>>>>                 size, guard pages may appear in the middle of the
>>>>                 invoking thread stack?
>>>>                 I always thought this is a bit dangerous. If your model
>>>>                 is to have the
>>>>                 VM created from the main thread, which then goes off to
>>>>                 do different
>>>>                 things, and have other threads then attach and run java
>>>>                 code, main
>>>>                 thread later may crash in unrelated native code just
>>>>                 because it reached
>>>>                 the stack depth of the hava threads? Or am I
>>>>                 misunderstanding something?
>>>>
>>>>
>>>>             There is no change to the general behaviour other than
>>>>             allowing a
>>>>             primordial process thread that launches the VM, to now not
>>>>             have an
>>>>             effective stack limited at 2MB. The current logic will
>>>>             insert guard
>>>>             pages where ever -Xss states (as long as less than 2MB else
>>>>             2MB), while
>>>>             with the fix the guard pages will be inserted above 2MB
>>>> - as
>>>>             dictated by
>>>>             -Xss.
>>>>
>>>>             David
>>>>             -----
>>>>
>>>>                 Thanks, Thomas
>>>>
>>>>
>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>                 <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>>                 <mailto:david.holmes at oracle.com
>>>>                 <mailto:david.holmes at oracle.com>>> wrote:
>>>>
>>>>                     Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>
>>>>                     The bug is not public unfortunately for
>>>>                 non-technical reasons - but
>>>>                     see my eval below.
>>>>
>>>>                     Background: if you load the JVM from the primordial
>>>>                 thread of a
>>>>                     process (not done by the java launcher since JDK
>>>> 6),
>>>>                 there is an
>>>>                     artificial stack limit imposed on the initial
>>>> thread
>>>>                 (by sticking
>>>>                     the guard page at the limit position of the actual
>>>>                 stack) of the
>>>>                     minimum of the -Xss setting and 2M. So if you set
>>>>                 -Xss to > 2M it is
>>>>                     ignored for the main thread even if the true stack
>>>>                 is, say, 8M. This
>>>>                     limitation dates back 10-15 years and is no longer
>>>>                 relevant today
>>>>                     and should be removed (see below). I've also added
>>>>                 additional
>>>>                     explanatory notes.
>>>>
>>>>                     webrev:
>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>
>>>>                     Testing was manually done by modifying the launcher
>>>>                 to not run the
>>>>                     VM in a new thread, and checking the resulting
>>>> stack
>>>>                 size used.
>>>>
>>>>                     This change will only affect hosted JVMs launched
>>>>                 with a -Xss value
>>>>                     > 2M.
>>>>
>>>>                     Thanks,
>>>>                     David
>>>>                     -----
>>>>
>>>>                     Bug eval:
>>>>
>>>>                     JDK-4441425 limits the stack to 8M as a safeguard
>>>>                 against an
>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>> further
>>>>                 constrained
>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>
>>>>                     By 1.4.2 we have the basic form of the current
>>>>                 problematic code:
>>>>
>>>>                     #ifndef IA64
>>>>                       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur =
>>>> 2 *
>>>>                 K * K;
>>>>                     #else
>>>>                       // Problem still exists RH7.2 (IA64 anyway) but
>>>>                 2MB is a little
>>>>                 small
>>>>                       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur =
>>>> 4 *
>>>>                 K * K;
>>>>                     #endif
>>>>
>>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>>                 ~(page_size() - 1);
>>>>
>>>>                       if (max_size && _initial_thread_stack_size >
>>>>                 max_size) {
>>>>                          _initial_thread_stack_size = max_size;
>>>>                       }
>>>>
>>>>                     This was added by JDK-4678676 to allow the stack of
>>>>                 the main thread
>>>>                     to be _reduced_ below the default 2M/4M if the -Xss
>>>>                 value was
>>>>                     smaller than that.** There was no intent to allow
>>>>                 the stack size to
>>>>                     follow -Xss arbitrarily due to the operational
>>>>                 constraints imposed
>>>>                     by the OS/glibc at the time when dealing with the
>>>>                 primordial process
>>>>                     thread.
>>>>
>>>>                     ** It could not actually change the actual stack
>>>>                 size of course, but
>>>>                     set the guard pages to limit use to the expected
>>>>                 stack size.
>>>>
>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>                 changed to create the
>>>>                     JVM in a new thread, so that it was not limited by
>>>> the
>>>>                     idiosyncracies of the OS or thread library
>>>>                 primordial thread
>>>>                     handling. However, the stack size limitations
>>>>                 remained in place in
>>>>                     case the VM was launched from the primordial thread
>>>>                 of a user
>>>>                     application via the JNI invocation API.
>>>>
>>>>                     I believe it should be safe to remove the 2M
>>>>                 limitation now.
>>>>
>>>>
>>>>
>

From igor.ignatyev at oracle.com  Sat Dec  3 10:15:38 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sat, 3 Dec 2016 13:15:38 +0300
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <390edb70-47e3-9754-d8da-1260d8b655b9@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
	<390edb70-47e3-9754-d8da-1260d8b655b9@oracle.com>
Message-ID: <5AB62D48-DBE8-4A29-83BA-55929B0288B1@oracle.com>

Hi Serguei,

thank you for reviewing this.

> +# convert list of directories to *dos* paths What does "dos" mean here?
I?ve copied/pasted that part from jdk/test/Makefile[1], so it will be easy to consolidate them in future. I assume _dos_ here means disk operation system, DOS. 

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/ed6586330575/test/Makefile#l281

Thanks,
? Igor

> On Dec 3, 2016, at 3:57 AM, serguei.spitsyn at oracle.com wrote:
> 
> Hi Igor,
> 
> It looks good to me.
> Thank you for taking care about this.
> 
> One minor question on the comment:
> 
> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/test/Makefile.udiff.html 
> 
> +# convert list of directories to *dos* paths What does "dos" mean here?
> 
> 
> Thanks,
> Serguei
> 
> 
> On 12/2/16 11:27, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>> 115 lines changed: 97 ins; 17 del; 1 mod;
>> Hi all,
>> 
>> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>> 
>> a bit of background:
>> there are two cases when one wants to remove a test from test execution:
>>  - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>>  - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
>> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>> 
>> in two words, @ignore to exclude, ProblemList to quarantine.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>> 
>> Thanks,
>> ? Igor
> 


From serguei.spitsyn at oracle.com  Sat Dec  3 11:35:49 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Sat, 3 Dec 2016 03:35:49 -0800
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <5AB62D48-DBE8-4A29-83BA-55929B0288B1@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
	<390edb70-47e3-9754-d8da-1260d8b655b9@oracle.com>
	<5AB62D48-DBE8-4A29-83BA-55929B0288B1@oracle.com>
Message-ID: <fbd5bf0c-d7bf-3c4e-931e-7bf3fc10442b@oracle.com>

Hi Igor,


On 12/3/16 02:15, Igor Ignatyev wrote:
> Hi Serguei,
>
> thank you for reviewing this.
>
>> +# convert list of directories to *dos* paths What does "dos" mean here?
> I?ve copied/pasted that part from jdk/test/Makefile[1], so it will be easy to consolidate them in future. I assume _dos_ here means disk operation system, DOS.

Thank you for explanation.

Thanks,
Serguei


>   
>
> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/ed6586330575/test/Makefile#l281
>
> Thanks,
> ? Igor
>
>> On Dec 3, 2016, at 3:57 AM, serguei.spitsyn at oracle.com wrote:
>>
>> Hi Igor,
>>
>> It looks good to me.
>> Thank you for taking care about this.
>>
>> One minor question on the comment:
>>
>> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/test/Makefile.udiff.html
>>
>> +# convert list of directories to *dos* paths What does "dos" mean here?
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 12/2/16 11:27, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>>> 115 lines changed: 97 ins; 17 del; 1 mod;
>>> Hi all,
>>>
>>> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>>>
>>> a bit of background:
>>> there are two cases when one wants to remove a test from test execution:
>>>   - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>>>   - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
>>> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>>>
>>> in two words, @ignore to exclude, ProblemList to quarantine.
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>>>
>>> Thanks,
>>> ? Igor


From david.holmes at oracle.com  Mon Dec  5 04:02:48 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 5 Dec 2016 14:02:48 +1000
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
Message-ID: <79eb3395-ea8b-96a1-5337-84db4962e831@oracle.com>

Hi Igor,

Seems okay on principle.

The previously undefined JTREG_EXTENSIONS is passed to jtreg via the 
Makefile jtreg_tests target. Is that target used by JPRT when running 
jtreg tests? What about rbt etc?

When running jtreg standalone/locally we now have to remember to add 
potentially two --exclude options. That needs a bit of a "heads up" 
email beyond this RFR in my opinion.

Nit: The new ProblemList.txt should have a single year, 2016, in its 
copyright header.

+# Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights 
reserved.

Thanks,
David

On 3/12/2016 5:27 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>> 115 lines changed: 97 ins; 17 del; 1 mod;
>
> Hi all,
>
> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>
> a bit of background:
> there are two cases when one wants to remove a test from test execution:
>  - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>  - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>
> in two words, @ignore to exclude, ProblemList to quarantine.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>
> Thanks,
> ? Igor
>

From david.holmes at oracle.com  Mon Dec  5 04:34:32 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 5 Dec 2016 14:34:32 +1000
Subject: RFR: JDK-8170629 Remove code duplication in test makefiles
In-Reply-To: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
References: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
Message-ID: <4507d02a-681f-331f-e01e-069857da2a27@oracle.com>

<trimmed to build-dev and hotspot-dev>

Hi Magnus,

Some independent changes are going to collide here. :)

hotspot/make/test/JtregNative.gmk

This change has already happened in hs repo - JDK-8169261.

---

hotspot/test/Makefile

33 USE_JTREG_VERSION := 4.1

Aside: - Jigsaw bumped this to 4.2 (and I think that was a while ago). I 
don't think anything we do with jtreg relies on the JT_HOME setting 
currently set in hotspot/test/Makefile. So we should bump this after 
your refactor.

41 # hotspot currently do not use ProblemList.txt
42 NO_EXCLUDES := true

Igor is adding this right now:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html

Otherwise looks good.

Thanks,
David
-----

On 2/12/2016 7:24 PM, Magnus Ihse Bursie wrote:
> There is a lot of common code that has been duplicated in
> */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code in
> the corresponding files are identical. (The odd-man-out is langtools
> which is quite different.)
>
> These files should be unified to share a single code base, to facilitate
> further improvements to the test makefiles.
>
> The intent of this bug is a pure refactoring. The duplication should go,
> but all functionality should remain exactly the same. This will leave
> room for some future improvements to the code, but sets a clear limit
> for this first step. The consolidated code base thus contains a fair
> amount of if-blocks, but I hope to be able to address most of these
> later on, by adjusting the individual component to adhere more to the
> standard behavior.
>
> To minimize the amount of ifdefs in the shared code, I allowed for a few
> changes in behavior. I do not believe these will cause any changes in
> the real world, and to the extent that they do, they could be considered
> bug fixes.
>
> Behavior that have changed due to unification:
> * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
> * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
> * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
> * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists.
> * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01
>
>
> /Magnus

From aoqi at loongson.cn  Mon Dec  5 07:10:57 2016
From: aoqi at loongson.cn (Ao Qi)
Date: Mon, 5 Dec 2016 15:10:57 +0800
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <1e2656b9-3b9c-75c5-5e02-23c71de44e06@oracle.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
	<6ca3fcd2-e08a-2f4d-4884-d539842cbd18@ubuntu.com>
	<CAA-vtUz90ghciheBqaCT_TXKM6_ZiiuXXPq_RJd7uRoWMx1eQQ@mail.gmail.com>
	<1e2656b9-3b9c-75c5-5e02-23c71de44e06@oracle.com>
Message-ID: <CALjzQn7UNu50JAXjiqUCCOPHHEFmQqah-gcF=YumW-OF8p=7vw@mail.gmail.com>

Hi James,

I have the same questions with David. "I am surprised if this is the only
thing that will prevent you from building on MIPS. And even if you do build
okay I'm not sure what you can run - zero intepreter?" In addition, could I
know your build environment and configure parameters? I want to do some
test.

FYI I am working on OpenJDK 8 MIPS Port [1], and glad to hear that someone
is also doing work related to MIPS:)

[1] http://mail.openjdk.java.net/pipermail/porters-dev/2016-May/000544.html

Thanks,
Ao Qi


2016-12-02 9:05 GMT+08:00 David Holmes <david.holmes at oracle.com>:

> FYI I have filed an enhancement request for this:
>
> https://bugs.openjdk.java.net/browse/JDK-8170639
>
> On 2/12/2016 5:08 AM, Thomas St?fe wrote:
>
>> On Thu, Dec 1, 2016 at 2:36 PM, Matthias Klose <doko at ubuntu.com
>> <mailto:doko at ubuntu.com>> wrote:
>>
>>     On 01.12.2016 14:20, David Holmes wrote:
>>     > That said, given that this patch does nothing to fix the supported
>> OpenJDK 9
>>
>>     where can I find the list of supported platforms? Is zero a
>>     supported platform?
>>
>>
>> Well, there is that:
>>
>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>
>> But this seems to be a bit outdated, I do not see arm nor the new s390
>> port. Should this be updated? If yes, should this be updated by the port
>> maintainers?
>>
>
> The Build Group owns that wiki so they would have to update it. And of
> course the set of build platforms is not the same as the set of execute
> platforms. But yes Aarch64 and S390 should be added.
>
> There doesn't seem to be a list of official OpenJDK runtime platforms, but
> it can be inferred by looking at the various Port projects, their JEPS and
> status.
>
>     > platforms it would have to be considered an enhancement and we are
>>> closed to new
>>>     > enhancements for JDK 9. The JDK 10 repos will be opening very soon
>>> though,
>>>
>>>     same here:
>>>     http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-Septemb
>>> er/004819.html
>>>     <http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-Septem
>>> ber/004819.html>
>>>
>>> How can these porting patches find it's way into jdk9? I see that
>>> JEPs for three new hotspot ports were accepted after September.
>>>
>>
> The JDK 9 schedule was modified after that post [1] and we did not in fact
> enter RDP1 at that time. Additional features were allowed to be added under
> an extension mechanism, the deadline for completion of such is Dec 22.
> However that is for final code to reach the master forest and so we are
> effectively "closed" in the hotspot forest in terms of starting anything
> new. It may not be impossible but it would require significant
> justification and very quick work.
>
> Is
>>> this the right way to write a JEP for each zero port, or would these
>>> fixes considered for backporting into jdk9?>
>>>
>>
>> I always thought the point of the zero port was to just work on any
>> platform with a C++ compiler, and therefore does not constitute a real
>> porting platform. So, any error on zero for any architecture would be
>> handled as just a bug. I may be wrong here, so please correct me if I am
>> wrong.
>>
>
> Zero "ports" are not considered OpenJDK ports so do not normally need JEPs
> (unless Zero itself is undergoing some major enhancement to support a new
> platform).
>
> For the most part we rely on the Zero maintainers to report any issues
> that other changes cause with Zero, or where Zero needs to be updated to
> support platform X and we do work together to get things fixed. That said,
> if someone tries to build Zero for platform X, and that in turn requires
> changes to platform specific VM code unrelated to Zero itself, then that is
> a different matter.
>
> A change, like has been requested, which simply changes to using more
> standard mechanisms is obviously an acceptable request (unfortunately just
> not now for JDK 9) - however if it required an "ifdef MIPS" then that would
> not be acceptable.
>
> The question of "backporting to 9" can't be answered until there is a "9
> update" project and it defines what its back porting policy is.
>
> Thanks,
> David
> -----
>
> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October
> /005092.html
>
> ..Thomas
>>
>>
>>     Matthias
>>
>>
>>

From dmitry.fazunenko at oracle.com  Mon Dec  5 13:35:39 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Mon, 5 Dec 2016 16:35:39 +0300
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
Message-ID: <bc1e6b8e-9dbe-171d-06dd-b4c8a6ec7621@oracle.com>

Hi Igor,

Thank you for doing that long-awaited change!
The fix looks good, but I have a few minor questions/comments:

1) Have you moved all the tests which are currently @ignored to the 
problem list or some of them intentionally left @ignored?

2) Copyrights

# Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved.
-->
# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.


3) Would you consider correction in wording:

# List of quarantined tests -- tests that should not be run by default, because
# they introduce noise in test results.
-->
# List of problematic tests -- tests that should not be run by default, because
# they may fail due to known reason. The reason (CR#) must be mandatory specified.

4) Would you consider to use the same formatting as jdk does:

compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all
compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all
compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 generic-all
compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 generic-all
compiler/startup/SmallCodeCacheStartup.java 8134286 generic-all
compiler/tiered/LevelTransitionTest.java 8067651 generic-all
compiler/types/correctness/CorrectnessTest.java 8066173 generic-all
compiler/types/correctness/OffTest.java 8066173 generic-all
-->
compiler/codecache/stress/OverloadCompileQueueTest.java             8166554 generic-all

compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java     8140405 generic-all

compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java            8158860 generic-all

compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java        8163894 generic-all

compiler/startup/SmallCodeCacheStartup.java                         8134286 generic-all

compiler/tiered/LevelTransitionTest.java                            8067651 generic-all

compiler/types/correctness/CorrectnessTest.java                     8066173 generic-all
compiler/types/correctness/OffTest.java                             8066173 generic-all


Thanks,
Dima

On 02.12.2016 22:27, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>> 115 lines changed: 97 ins; 17 del; 1 mod;
> Hi all,
>
> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>
> a bit of background:
> there are two cases when one wants to remove a test from test execution:
>   - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>   - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>
> in two words, @ignore to exclude, ProblemList to quarantine.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>
> Thanks,
> ? Igor


From bob.vandette at oracle.com  Mon Dec  5 15:23:50 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 5 Dec 2016 10:23:50 -0500
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <58421A35.5070706@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
Message-ID: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>


> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> hi Bob,
> 
> I would suggest to have separate webrevs for different repositories because different groups should look on them.

There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.

> 
> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net
> 
> Why do you need cahnges in SA libproc.h?

The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.

I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:

#if defined(arm) || defined(arm64)
#define user_regs_struct user_regs
#endif

This change would result  in the exact same declaration based on the number of registers
derived from the structure in user.h. 

Bob.


> 
> I saw Hotspot changes before and I think they are fine (did not dive deep).
> 
> Thanks,
> Vladimir
> 
> On 12/2/16 12:28 PM, Bob Vandette wrote:
>> Please review the proposed changes to be integrated under JEP 297.
>> 
>> Summary:
>> 
>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>> 
>> This changeset also removes the support for the pregenerated interpreter since
>> this is no longer supported.
>> 
>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>> 
>> JEP 297:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8168503
>> 
>> Webrev:
>> 
>> http://cr.openjdk.java.net/~bobv/8168503
>> 
>> 
>> Note:
>> 
>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>> 
>> Thanks,
>> Bob Vandette
>> 


From coleen.phillimore at oracle.com  Mon Dec  5 16:12:31 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 5 Dec 2016 11:12:31 -0500
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
	<35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
Message-ID: <2b5d9549-6857-797a-fa60-de6d7ce234d0@oracle.com>


The interpreter and runtime parts of this change look good to me, and I 
spot checked the arm code.
Coleen


On 12/5/16 10:23 AM, Bob Vandette wrote:
>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> hi Bob,
>>
>> I would suggest to have separate webrevs for different repositories because different groups should look on them.
> There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.
>
>> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net
>>
>> Why do you need cahnges in SA libproc.h?
> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.
>
> I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:
>
> #if defined(arm) || defined(arm64)
> #define user_regs_struct user_regs
> #endif
>
> This change would result  in the exact same declaration based on the number of registers
> derived from the structure in user.h.
>
> Bob.
>
>
>> I saw Hotspot changes before and I think they are fine (did not dive deep).
>>
>> Thanks,
>> Vladimir
>>
>> On 12/2/16 12:28 PM, Bob Vandette wrote:
>>> Please review the proposed changes to be integrated under JEP 297.
>>>
>>> Summary:
>>>
>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>>>
>>> This changeset also removes the support for the pregenerated interpreter since
>>> this is no longer supported.
>>>
>>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>>>
>>> JEP 297:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8168503
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~bobv/8168503
>>>
>>>
>>> Note:
>>>
>>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>>>
>>> Thanks,
>>> Bob Vandette
>>>


From edward.nevill at gmail.com  Mon Dec  5 17:09:15 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Mon, 05 Dec 2016 17:09:15 +0000
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
Message-ID: <1480957755.10998.11.camel@gmail.com>

On Fri, 2016-12-02 at 15:28 -0500, Bob Vandette wrote:
> Please review the proposed changes to be integrated under JEP 297.
>?

Looks good. I have run it through JTreg on x86, arm32 and arm64 systems. Results below. The repo I used was the 'hs' repo.

On x86 I did two runs, original repo and patched with your webrev. For arm64 I did two runs, one the arm64 unified build (ie the webrev below) and one, the existing aarch64 build.

All builds were release builds.

For the jdk tests I used the options -k:\!headful\&\!intermittant\&\!randomness to suppress any tests requiring X11.

I will append these results to a comment in the issue and start running jcstress.

All the best,
Ed.

x86(original):

hotspot: passed: 1,337; failed: 5; error: 44 (0 fatal errors)*
langtools: passed: 3,757; failed: 5; error: 8 (0 fatal errors)
jdk: passed: 6,348; failed: 194; error: 11 (1 fatal error)

x86(patched):

hotspot: passed: 1,337; failed: 5; error: 44 (0 fatal errors)
langtools: passed: 3,757; failed: 5; error: 8 (0 fatal errors)
jdk: passed: 6,346; failed: 196; error: 10 (0 fatal errors)

arm32

hotspot: passed: 1,244; failed: 5; error: 44 (0 fatal errors)
langtools: passed: 3,761; failed: 1; error: 8 (0 fatal errors)
jdk: passed: 6,339; failed: 197; error: 11 (0 fatal errors)

aarch64

hotspot: passed: 1,325; failed: 9; error: 44 (0 fatal errors)
langtools: passed: 3,757; failed: 2; error: 8 (0 fatal errors)
jdk: passed: 6,389; failed: 155; error: 9 (0 fatal errors)

arm64

hotspot: passed: 1,327; failed: 7; error: 44 (0 fatal errors)
langtools: passed 3,760; failed: 1; error: 8 (0 fatal errors)
jdk: passed: 6,408; failed: 136; error: 9 (0 fatal errors)

* 'fatal' errors are those where the test failed with the message "A fatal error has been detected" in the .jtr file.


From vladimir.kozlov at oracle.com  Mon Dec  5 17:24:55 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 5 Dec 2016 09:24:55 -0800
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
	<35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
Message-ID: <5845A2E7.8050203@oracle.com>

On 12/5/16 7:23 AM, Bob Vandette wrote:
>
>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> hi Bob,
>>
>> I would suggest to have separate webrevs for different repositories because different groups should look on them.
>
> There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.

+3 Hotspot makefile cahnges. + new jvm.cfg

But you are right that makefiles changes are first in the webrev and easy to find/review.

>
>>
>> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net
>>
>> Why do you need cahnges in SA libproc.h?
>
> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.
>
> I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:
>
> #if defined(arm) || defined(arm64)
> #define user_regs_struct user_regs
> #endif
>
> This change would result  in the exact same declaration based on the number of registers
> derived from the structure in user.h.

Please, do this.

Thanks,
Vladimir

>
> Bob.
>
>
>>
>> I saw Hotspot changes before and I think they are fine (did not dive deep).
>>
>> Thanks,
>> Vladimir
>>
>> On 12/2/16 12:28 PM, Bob Vandette wrote:
>>> Please review the proposed changes to be integrated under JEP 297.
>>>
>>> Summary:
>>>
>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>>>
>>> This changeset also removes the support for the pregenerated interpreter since
>>> this is no longer supported.
>>>
>>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>>>
>>> JEP 297:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8168503
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~bobv/8168503
>>>
>>>
>>> Note:
>>>
>>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>>>
>>> Thanks,
>>> Bob Vandette
>>>
>

From magnus.ihse.bursie at oracle.com  Tue Dec  6 10:15:01 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Dec 2016 11:15:01 +0100
Subject: RFR: JDK-8170629 Remove code duplication in test makefiles
In-Reply-To: <4507d02a-681f-331f-e01e-069857da2a27@oracle.com>
References: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
	<4507d02a-681f-331f-e01e-069857da2a27@oracle.com>
Message-ID: <b4464f01-5479-f751-e944-5a10e7060846@oracle.com>

On 2016-12-05 05:34, David Holmes wrote:
> <trimmed to build-dev and hotspot-dev>
>
> Hi Magnus,
>
> Some independent changes are going to collide here. :)
>
> hotspot/make/test/JtregNative.gmk
>
> This change has already happened in hs repo - JDK-8169261.
Ok, I removed that fix from my patch.
>
> ---
>
> hotspot/test/Makefile
>
> 33 USE_JTREG_VERSION := 4.1
>
> Aside: - Jigsaw bumped this to 4.2 (and I think that was a while ago). 
> I don't think anything we do with jtreg relies on the JT_HOME setting 
> currently set in hotspot/test/Makefile. So we should bump this after 
> your refactor.

I think so too.

>
> 41 # hotspot currently do not use ProblemList.txt
> 42 NO_EXCLUDES := true
>
> Igor is adding this right now:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html 
>

I removed the NO_EXCLUDES statement from Hotspot. This does not have any 
effect as long as no ProblemList.txt is present (in fact, had I thought 
a bit more on this before, I would not even have needed to add that 
guard for hotspot), but will facilitate merging with Igor's patch.
>
> Otherwise looks good.

I discovered a few other issues in the Hotspot file (it turned out I 
didn't run the hotspot tests before with my jprt command :() which I 
also have fixed.

New webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.02

/Magnus


>
> Thanks,
> David
> -----
>
> On 2/12/2016 7:24 PM, Magnus Ihse Bursie wrote:
>> There is a lot of common code that has been duplicated in
>> */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code in
>> the corresponding files are identical. (The odd-man-out is langtools
>> which is quite different.)
>>
>> These files should be unified to share a single code base, to facilitate
>> further improvements to the test makefiles.
>>
>> The intent of this bug is a pure refactoring. The duplication should go,
>> but all functionality should remain exactly the same. This will leave
>> room for some future improvements to the code, but sets a clear limit
>> for this first step. The consolidated code base thus contains a fair
>> amount of if-blocks, but I hope to be able to address most of these
>> later on, by adjusting the individual component to adhere more to the
>> standard behavior.
>>
>> To minimize the amount of ifdefs in the shared code, I allowed for a few
>> changes in behavior. I do not believe these will cause any changes in
>> the real world, and to the extent that they do, they could be considered
>> bug fixes.
>>
>> Behavior that have changed due to unification:
>> * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
>> * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
>> * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
>> * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists.
>> * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01 
>>
>>
>>
>> /Magnus


From jcowgill at debian.org  Tue Dec  6 10:38:59 2016
From: jcowgill at debian.org (James Cowgill)
Date: Tue, 6 Dec 2016 10:38:59 +0000
Subject: JDK 9 fails to build on MIPS
In-Reply-To: <CALjzQn7UNu50JAXjiqUCCOPHHEFmQqah-gcF=YumW-OF8p=7vw@mail.gmail.com>
References: <53391318-5ee3-28d4-b7bd-a51037de6032@debian.org>
	<8e53e8f5-b706-41ae-d39c-aea75eb820be@oracle.com>
	<6ca3fcd2-e08a-2f4d-4884-d539842cbd18@ubuntu.com>
	<CAA-vtUz90ghciheBqaCT_TXKM6_ZiiuXXPq_RJd7uRoWMx1eQQ@mail.gmail.com>
	<1e2656b9-3b9c-75c5-5e02-23c71de44e06@oracle.com>
	<CALjzQn7UNu50JAXjiqUCCOPHHEFmQqah-gcF=YumW-OF8p=7vw@mail.gmail.com>
Message-ID: <ca845682-f429-76cd-a62b-75cb5fa769d4@debian.org>

Hi,

On 05/12/16 07:10, Ao Qi wrote:
> Hi James,
> 
> I have the same questions with David. "I am surprised if this is the
> only thing that will prevent you from building on MIPS. And even if you
> do build okay I'm not sure what you can run - zero intepreter?" In
> addition, could I know your build environment and configure parameters?
> I want to do some test.

This was originally for Debian's copy of openjdk-9 with all its
patches. I've done a native compile from the main JDK repository and
after applying my patch and one extra patch from Debian[1], the JDK
builds and seems to work ok on mips (although obviously it's very slow).

I configured it with this:
CC=gcc-5 CXX=g++-5 bash ../configure --enable-debug --enable-headless-only --disable-warnings-as-errors --with-jvm-variants=zero

I expect headless to work as well - I just wanted to reduce the build
time a bit.

[1] https://sources.debian.net/src/openjdk-9/9%7Eb147-1/debian/patches/zero-architectures.diff/

> FYI I am working on OpenJDK 8 MIPS Port [1], and glad to hear that
> someone is also doing work related to MIPS:)
> 
> [1] http://mail.openjdk.java.net/pipermail/porters-dev/2016-May/000544.html

A real MIPS hotspot port would be great for mips, although something
this big has to be in the main upstream repositories before Debian
could use it.

Thanks,
James


From igor.ignatyev at oracle.com  Tue Dec  6 12:07:48 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 6 Dec 2016 15:07:48 +0300
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <bc1e6b8e-9dbe-171d-06dd-b4c8a6ec7621@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
	<bc1e6b8e-9dbe-171d-06dd-b4c8a6ec7621@oracle.com>
Message-ID: <A24A7B9D-2AD3-4C2E-AFA0-DE4A73C7A44F@oracle.com>

Dima,

thank you for your review and comments, please see my answers inline.

http://cr.openjdk.java.net/~iignatyev///8078450/webrev.01 is the updated webrev.

Cheers,
? Igor

> On Dec 5, 2016, at 4:35 PM, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
> 
> Hi Igor,
> 
> Thank you for doing that long-awaited change!
> The fix looks good, but I have a few minor questions/comments:
> 
> 1) Have you moved all the tests which are currently @ignored to the problem list or some of them intentionally left @ignored?
I've moved all tests, at least all which were in the repo when I created a patch. to me, all of them seem quarantined tests, not excluded.
have I missed some? or do you think some of them should be excluded?

> 2) Copyrights
fixed
> 
> 3) Would you consider correction in wording:
> 
> # List of quarantined tests -- tests that should not be run by default, because
> # they introduce noise in test results.
> -->
> # List of problematic tests -- tests that should not be run by default, because
> # they may fail due to known reason. The reason (CR#) must be mandatory specified.
I?d stick w/ quarantined, since we have been using "quarantined? in that meaning for a while, and besides ?problematic? is too generic, it?s also a new work, and I?d prefer not to pollute our dictionary w/ another type of failing tests.

> 4) Would you consider to use the same formatting as jdk does:
I?d rather not, having such alignment doesn?t add much value, but costs a lot, because almost each change would modify number of lines around.

> Thanks,
> Dima
> 
> On 02.12.2016 22:27, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>> 115 lines changed: 97 ins; 17 del; 1 mod;
>> Hi all,
>> 
>> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>> 
>> a bit of background:
>> there are two cases when one wants to remove a test from test execution:
>>  - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>>  - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
>> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>> 
>> in two words, @ignore to exclude, ProblemList to quarantine.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>> 
>> Thanks,
>> ? Igor
> 


From igor.ignatyev at oracle.com  Tue Dec  6 12:10:18 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 6 Dec 2016 15:10:18 +0300
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <79eb3395-ea8b-96a1-5337-84db4962e831@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
	<79eb3395-ea8b-96a1-5337-84db4962e831@oracle.com>
Message-ID: <C1871B8A-B5EA-4C8D-AD5A-43B0EAAC1F8C@oracle.com>

Hi David,

thank you for your review.

> Is that target used by JPRT when running jtreg tests? What about rbt etc?
all our test execution systems either use jtreg_tests target or check if ProblemList files exist add corresponding -exclude options explicitly.

> That needs a bit of a "heads up? email
sure, I?ll send an email w/ explanations how to run only stable hotspot tests.

Thanks,
? Igor

> On Dec 5, 2016, at 7:02 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Igor,
> 
> Seems okay on principle.
> 
> The previously undefined JTREG_EXTENSIONS is passed to jtreg via the Makefile jtreg_tests target. Is that target used by JPRT when running jtreg tests? What about rbt etc?
> 
> When running jtreg standalone/locally we now have to remember to add potentially two --exclude options. That needs a bit of a "heads up" email beyond this RFR in my opinion.
> 
> Nit: The new ProblemList.txt should have a single year, 2016, in its copyright header.
> 
> +# Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved.
> 
> Thanks,
> David
> 
> On 3/12/2016 5:27 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>> 115 lines changed: 97 ins; 17 del; 1 mod;
>> 
>> Hi all,
>> 
>> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>> 
>> a bit of background:
>> there are two cases when one wants to remove a test from test execution:
>> - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>> - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
>> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>> 
>> in two words, @ignore to exclude, ProblemList to quarantine.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>> 
>> Thanks,
>> ? Igor
>> 


From dmitry.fazunenko at oracle.com  Tue Dec  6 12:29:22 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Tue, 6 Dec 2016 15:29:22 +0300
Subject: RFR(S) : 8078450 : Implement consistent process for quarantine of
	tests
In-Reply-To: <A24A7B9D-2AD3-4C2E-AFA0-DE4A73C7A44F@oracle.com>
References: <248E35DD-1417-4209-888C-359A0878CA10@oracle.com>
	<bc1e6b8e-9dbe-171d-06dd-b4c8a6ec7621@oracle.com>
	<A24A7B9D-2AD3-4C2E-AFA0-DE4A73C7A44F@oracle.com>
Message-ID: <7dd309b4-0ea8-8541-0c41-28e65757c63a@oracle.com>

Igor,

New version looks good to me.
See a few comments inlined

On 06.12.2016 15:07, Igor Ignatyev wrote:
> Dima,
>
> thank you for your review and comments, please see my answers inline.
>
> http://cr.openjdk.java.net/~iignatyev///8078450/webrev.01 is the updated webrev.
>
> Cheers,
> ? Igor
>
>> On Dec 5, 2016, at 4:35 PM, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>>
>> Hi Igor,
>>
>> Thank you for doing that long-awaited change!
>> The fix looks good, but I have a few minor questions/comments:
>>
>> 1) Have you moved all the tests which are currently @ignored to the problem list or some of them intentionally left @ignored?
> I've moved all tests, at least all which were in the repo when I created a patch. to me, all of them seem quarantined tests, not excluded.
> have I missed some? or do you think some of them should be excluded?
Good. It means no 'excluded' tests for the time being.


>
>> 2) Copyrights
> fixed
>> 3) Would you consider correction in wording:
>>
>> # List of quarantined tests -- tests that should not be run by default, because
>> # they introduce noise in test results.
>> -->
>> # List of problematic tests -- tests that should not be run by default, because
>> # they may fail due to known reason. The reason (CR#) must be mandatory specified.
> I?d stick w/ quarantined, since we have been using "quarantined? in that meaning for a while, and besides ?problematic? is too generic, it?s also a new work, and I?d prefer not to pollute our dictionary w/ another type of failing tests.
Fine by me.

>
>> 4) Would you consider to use the same formatting as jdk does:
> I?d rather not, having such alignment doesn?t add much value, but costs a lot, because almost each change would modify number of lines around.
No objection, formatting is just a matter of taste.

Thanks,
Dima

>
>> Thanks,
>> Dima
>>
>> On 02.12.2016 22:27, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>>> 115 lines changed: 97 ins; 17 del; 1 mod;
>>> Hi all,
>>>
>>> could you please review this small changeset which introduces ProblemList for quarantining hotspot test and adds all currently quarantined tests to it?
>>>
>>> a bit of background:
>>> there are two cases when one wants to remove a test from test execution:
>>>   - a test sporadically fails, but there is still a value in running this test, e.g. it can fail in some other way and reveal another problem within the product. we want to run such tests, but we don?t want to have noise from these tests. to get both, we are going to _quarantine_ these tests and run them separately.
>>>   - a test always fails or can break other tests or host. running such tests makes more harm than good, so they should be _excluded_ from test execution completely.
>>> jtreg provides two exclusion mechanisms: @ignore tag and ProblemList. ProblemList gives a possibility to remove a test from execution on a specific OS, arch, and since the expectation is to have more quarantined tests than excluded, it was decided to use ProblemList to quarantine and @ignore to exclude, another reason is to have consistent process for hotspot and jdk tests.
>>>
>>> in two words, @ignore to exclude, ProblemList to quarantine.
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8078450/webrev.00/
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8078450
>>>
>>> Thanks,
>>> ? Igor


From erik.joelsson at oracle.com  Tue Dec  6 12:33:21 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 6 Dec 2016 13:33:21 +0100
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
	<35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
Message-ID: <87dd5a84-f307-d8e9-11f3-35dc379f1fb5@oracle.com>

Build changes look ok to me.

/Erik


On 2016-12-05 16:23, Bob Vandette wrote:
>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> hi Bob,
>>
>> I would suggest to have separate webrevs for different repositories because different groups should look on them.
> There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.
>
>> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net
>>
>> Why do you need cahnges in SA libproc.h?
> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.
>
> I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:
>
> #if defined(arm) || defined(arm64)
> #define user_regs_struct user_regs
> #endif
>
> This change would result  in the exact same declaration based on the number of registers
> derived from the structure in user.h.
>
> Bob.
>
>
>> I saw Hotspot changes before and I think they are fine (did not dive deep).
>>
>> Thanks,
>> Vladimir
>>
>> On 12/2/16 12:28 PM, Bob Vandette wrote:
>>> Please review the proposed changes to be integrated under JEP 297.
>>>
>>> Summary:
>>>
>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>>>
>>> This changeset also removes the support for the pregenerated interpreter since
>>> this is no longer supported.
>>>
>>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>>>
>>> JEP 297:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8168503
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~bobv/8168503
>>>
>>>
>>> Note:
>>>
>>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>>>
>>> Thanks,
>>> Bob Vandette
>>>


From david.holmes at oracle.com  Wed Dec  7 02:11:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 7 Dec 2016 12:11:29 +1000
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
Message-ID: <a444c7ea-acdd-efc0-593e-14a408b81af5@oracle.com>

This all looks good to me Bob!

Thanks.

David

On 3/12/2016 6:28 AM, Bob Vandette wrote:
> Please review the proposed changes to be integrated under JEP 297.
>
> Summary:
>
> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>
> This changeset also removes the support for the pregenerated interpreter since
> this is no longer supported.
>
> The addition of arm64 does not replace the existing aarch64 port.  A new configure
> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>
> JEP 297:
>
> https://bugs.openjdk.java.net/browse/JDK-8168503
>
> Webrev:
>
> http://cr.openjdk.java.net/~bobv/8168503
>
>
> Note:
>
> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>
> Thanks,
> Bob Vandette
>

From david.holmes at oracle.com  Wed Dec  7 07:32:49 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 7 Dec 2016 17:32:49 +1000
Subject: RFR: JDK-8170629 Remove code duplication in test makefiles
In-Reply-To: <b4464f01-5479-f751-e944-5a10e7060846@oracle.com>
References: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
	<4507d02a-681f-331f-e01e-069857da2a27@oracle.com>
	<b4464f01-5479-f751-e944-5a10e7060846@oracle.com>
Message-ID: <718059c2-a36c-9385-0ce4-810418c8ba5a@oracle.com>

No further comments on the hotspot changes.

Thanks,
David

On 6/12/2016 8:15 PM, Magnus Ihse Bursie wrote:
> On 2016-12-05 05:34, David Holmes wrote:
>> <trimmed to build-dev and hotspot-dev>
>>
>> Hi Magnus,
>>
>> Some independent changes are going to collide here. :)
>>
>> hotspot/make/test/JtregNative.gmk
>>
>> This change has already happened in hs repo - JDK-8169261.
> Ok, I removed that fix from my patch.
>>
>> ---
>>
>> hotspot/test/Makefile
>>
>> 33 USE_JTREG_VERSION := 4.1
>>
>> Aside: - Jigsaw bumped this to 4.2 (and I think that was a while ago).
>> I don't think anything we do with jtreg relies on the JT_HOME setting
>> currently set in hotspot/test/Makefile. So we should bump this after
>> your refactor.
>
> I think so too.
>
>>
>> 41 # hotspot currently do not use ProblemList.txt
>> 42 NO_EXCLUDES := true
>>
>> Igor is adding this right now:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html
>>
>
> I removed the NO_EXCLUDES statement from Hotspot. This does not have any
> effect as long as no ProblemList.txt is present (in fact, had I thought
> a bit more on this before, I would not even have needed to add that
> guard for hotspot), but will facilitate merging with Igor's patch.
>>
>> Otherwise looks good.
>
> I discovered a few other issues in the Hotspot file (it turned out I
> didn't run the hotspot tests before with my jprt command :() which I
> also have fixed.
>
> New webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.02
>
> /Magnus
>
>
>>
>> Thanks,
>> David
>> -----
>>
>> On 2/12/2016 7:24 PM, Magnus Ihse Bursie wrote:
>>> There is a lot of common code that has been duplicated in
>>> */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code in
>>> the corresponding files are identical. (The odd-man-out is langtools
>>> which is quite different.)
>>>
>>> These files should be unified to share a single code base, to facilitate
>>> further improvements to the test makefiles.
>>>
>>> The intent of this bug is a pure refactoring. The duplication should go,
>>> but all functionality should remain exactly the same. This will leave
>>> room for some future improvements to the code, but sets a clear limit
>>> for this first step. The consolidated code base thus contains a fair
>>> amount of if-blocks, but I hope to be able to address most of these
>>> later on, by adjusting the individual component to adhere more to the
>>> standard behavior.
>>>
>>> To minimize the amount of ifdefs in the shared code, I allowed for a few
>>> changes in behavior. I do not believe these will cause any changes in
>>> the real world, and to the extent that they do, they could be considered
>>> bug fixes.
>>>
>>> Behavior that have changed due to unification:
>>> * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
>>> * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
>>> * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
>>> * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists.
>>> * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01
>>>
>>>
>>>
>>> /Magnus
>

From magnus.ihse.bursie at oracle.com  Wed Dec  7 08:44:31 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 7 Dec 2016 09:44:31 +0100
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
	<35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
Message-ID: <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>

On 2016-12-05 16:23, Bob Vandette wrote:
>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> hi Bob,
>>
>> I would suggest to have separate webrevs for different repositories because different groups should look on them.
> There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.

Build changes mostly look good. A few comments:

* We try to use the autoconf defined "$with_opt" variables only when 
checking and verifying arguments. In hotspot.m4, please let 
SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. 
OPENJDK_TARGET_CPU_PORT, and use that to do the check in 
HOTSPOT_SETUP_JVM_FEATURES.

* In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks 
OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU 
instead, since explicitly checking the CPU_ARCH variable seems to 
indicate that we want to test more than a single CPU, but for arm there 
is only one. (At first, I thought this was a test for "arm64" as well. 
If this was the intention, then the code is broken.)

* In CompileJvm.gmk, you might want to rephrase the comment, since from 
now on both the original aarch64 and the new arm64 port are "open". What 
the code does is in fact to select between the two different aarch64 ports.

/Magnus


>
>> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net
>>
>> Why do you need cahnges in SA libproc.h?
> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.
>
> I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:
>
> #if defined(arm) || defined(arm64)
> #define user_regs_struct user_regs
> #endif
>
> This change would result  in the exact same declaration based on the number of registers
> derived from the structure in user.h.
>
> Bob.
>
>
>> I saw Hotspot changes before and I think they are fine (did not dive deep).
>>
>> Thanks,
>> Vladimir
>>
>> On 12/2/16 12:28 PM, Bob Vandette wrote:
>>> Please review the proposed changes to be integrated under JEP 297.
>>>
>>> Summary:
>>>
>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>>>
>>> This changeset also removes the support for the pregenerated interpreter since
>>> this is no longer supported.
>>>
>>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>>>
>>> JEP 297:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8168503
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~bobv/8168503
>>>
>>>
>>> Note:
>>>
>>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>>>
>>> Thanks,
>>> Bob Vandette
>>>


From erik.joelsson at oracle.com  Wed Dec  7 09:32:11 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 7 Dec 2016 10:32:11 +0100
Subject: RFR: JDK-8170629 Remove code duplication in test makefiles
In-Reply-To: <b4464f01-5479-f751-e944-5a10e7060846@oracle.com>
References: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com>
	<4507d02a-681f-331f-e01e-069857da2a27@oracle.com>
	<b4464f01-5479-f751-e944-5a10e7060846@oracle.com>
Message-ID: <bf3eef48-5287-4c26-5001-276e431e9d31@oracle.com>

Looks good to me.

/Erik


On 2016-12-06 11:15, Magnus Ihse Bursie wrote:
> On 2016-12-05 05:34, David Holmes wrote:
>> <trimmed to build-dev and hotspot-dev>
>>
>> Hi Magnus,
>>
>> Some independent changes are going to collide here. :)
>>
>> hotspot/make/test/JtregNative.gmk
>>
>> This change has already happened in hs repo - JDK-8169261.
> Ok, I removed that fix from my patch.
>>
>> ---
>>
>> hotspot/test/Makefile
>>
>> 33 USE_JTREG_VERSION := 4.1
>>
>> Aside: - Jigsaw bumped this to 4.2 (and I think that was a while 
>> ago). I don't think anything we do with jtreg relies on the JT_HOME 
>> setting currently set in hotspot/test/Makefile. So we should bump 
>> this after your refactor.
>
> I think so too.
>
>>
>> 41 # hotspot currently do not use ProblemList.txt
>> 42 NO_EXCLUDES := true
>>
>> Igor is adding this right now:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html 
>>
>
> I removed the NO_EXCLUDES statement from Hotspot. This does not have 
> any effect as long as no ProblemList.txt is present (in fact, had I 
> thought a bit more on this before, I would not even have needed to add 
> that guard for hotspot), but will facilitate merging with Igor's patch.
>>
>> Otherwise looks good.
>
> I discovered a few other issues in the Hotspot file (it turned out I 
> didn't run the hotspot tests before with my jprt command :() which I 
> also have fixed.
>
> New webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.02
>
> /Magnus
>
>
>>
>> Thanks,
>> David
>> -----
>>
>> On 2/12/2016 7:24 PM, Magnus Ihse Bursie wrote:
>>> There is a lot of common code that has been duplicated in
>>> */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the 
>>> code in
>>> the corresponding files are identical. (The odd-man-out is langtools
>>> which is quite different.)
>>>
>>> These files should be unified to share a single code base, to 
>>> facilitate
>>> further improvements to the test makefiles.
>>>
>>> The intent of this bug is a pure refactoring. The duplication should 
>>> go,
>>> but all functionality should remain exactly the same. This will leave
>>> room for some future improvements to the code, but sets a clear limit
>>> for this first step. The consolidated code base thus contains a fair
>>> amount of if-blocks, but I hope to be able to address most of these
>>> later on, by adjusting the individual component to adhere more to the
>>> standard behavior.
>>>
>>> To minimize the amount of ifdefs in the shared code, I allowed for a 
>>> few
>>> changes in behavior. I do not believe these will cause any changes in
>>> the real world, and to the extent that they do, they could be 
>>> considered
>>> bug fixes.
>>>
>>> Behavior that have changed due to unification:
>>> * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
>>> * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
>>> * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
>>> * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it 
>>> exists.
>>> * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01 
>>>
>>>
>>>
>>> /Magnus
>


From thomas.stuefe at gmail.com  Wed Dec  7 10:52:43 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 7 Dec 2016 11:52:43 +0100
Subject: Gtest: CreateVM is not called when isolated tests are run?
Message-ID: <CAA-vtUzMCKzAC-N_mPUncNCmmer7ZD=w56HS18jSN-Cc7YGvWg@mail.gmail.com>

Hi all,

I am writing a metaspace-related gtest and was noticing my test to assert
in Thread::current() because the test thread was not attached to the VM.
When executed together with all other tests, it works.

Some other tests are affected as well, e.g. LogStream tests:

./hotspot/variant-server/libjvm/gtest/gtestLauncher.exe -jdk ./images/jdk/
--gtest_filter=LogStream*

[ RUN      ] LogStreamTest.from_log
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\runtime/thread.hpp:662
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(c:\d031900\openjdk\jdk9-hs2\source\hotspot\src\share\vm\runtime/thread.hpp:662),
pid=17512, tid=7260
#  assert(current != 0LL) failed: Thread::current() called on detached
thread

Did anyone else notice this behaviour?

I see that when I run all tests (when omitting the filter argument),
Thread::create_vm is called, but not when the test is run isolated. So, the
VM is not initialized and all but the most primitive tests will fail.

Is this intended or would this be a bug?

Kind Regards, Thomas

From aph at redhat.com  Wed Dec  7 11:08:01 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 7 Dec 2016 11:08:01 +0000
Subject: How to get reference processing logging?
Message-ID: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>

I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.

I want to see this output:

  log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: " SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
                     stats.soft_count(), stats.weak_count(), stats.final_count(), stats.phantom_count());
  log_develop_trace(gc, ref)("JNI Weak Reference count: " SIZE_FORMAT, count_jni_refs());


I tried -Xlog:help and searc hed on the web for information about the
-Xlog syntax, but no luck.

Thanks,

Andrew.


From thomas.schatzl at oracle.com  Wed Dec  7 11:15:12 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 07 Dec 2016 12:15:12 +0100
Subject: How to get reference processing logging?
In-Reply-To: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
References: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
Message-ID: <1481109312.2684.4.camel@oracle.com>

Hi,

On Wed, 2016-12-07 at 11:08 +0000, Andrew Haley wrote:
> I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.

"-Xlog:gc+ref=debug"

> 
> I want to see this output:
> 
> ? log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: "
> SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
> ?????????????????????stats.soft_count(), stats.weak_count(),
> stats.final_count(), stats.phantom_count());
> ? log_develop_trace(gc, ref)("JNI Weak Reference count: "
> SIZE_FORMAT, count_jni_refs());
> 
> 
> I tried -Xlog:help and searc hed on the web for information about the
> -Xlog syntax, but no luck.

-Xlog:help gives a pretty comprehensive output with BNF syntax
description here. It also includes a lot of examples.

Particularly the sentence below the BNF string gives an explanation of
"what" should be.

Maybe you have some suggestions to improve the text?

Thanks,
? Thomas


From aph at redhat.com  Wed Dec  7 11:26:07 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 7 Dec 2016 11:26:07 +0000
Subject: How to get reference processing logging?
In-Reply-To: <1481109312.2684.4.camel@oracle.com>
References: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
	<1481109312.2684.4.camel@oracle.com>
Message-ID: <b5de4a39-7a92-dff9-761b-4c0b128d0e5c@redhat.com>

On 07/12/16 11:15, Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2016-12-07 at 11:08 +0000, Andrew Haley wrote:
>> I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.
> 
> "-Xlog:gc+ref=debug"
> 
>>
>> I want to see this output:
>>
>>   log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: "
>> SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
>>                      stats.soft_count(), stats.weak_count(),
>> stats.final_count(), stats.phantom_count());
>>   log_develop_trace(gc, ref)("JNI Weak Reference count: "
>> SIZE_FORMAT, count_jni_refs());
>>
>>
>> I tried -Xlog:help and searc hed on the web for information about the
>> -Xlog syntax, but no luck.
> 
> -Xlog:help gives a pretty comprehensive output with BNF syntax
> description here. It also includes a lot of examples.

Perhaps, but none of the examples actually contain "+".

> Particularly the sentence below the BNF string gives an explanation of
> "what" should be.
> 
> Maybe you have some suggestions to improve the text?

Indeed I do.  An example which contains the crucial "+" would be a start.
Like this:

-Xlog:gc+ref=debug
	 Log messages tagged with 'gc' and 'ref' tags using 'debug' level to stdout, with default decorations.

The crucial I didn't realize was that in

  log_debug(gc, ref)

both "gc" and "ref" are tags.  It's not obvious, but I suppose if I'd
studied the way the logging framework is called it would have been
clearer.  Nonethless, you shouldn't have to be a developer who knows
the logging API just in order to get some log output, and the syntax
is very obscure.

Is this stuff documented anywhere?

Thanks,

Andrew.

From thomas.schatzl at oracle.com  Wed Dec  7 12:20:15 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 07 Dec 2016 13:20:15 +0100
Subject: How to get reference processing logging?
In-Reply-To: <b5de4a39-7a92-dff9-761b-4c0b128d0e5c@redhat.com>
References: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
	<1481109312.2684.4.camel@oracle.com>
	<b5de4a39-7a92-dff9-761b-4c0b128d0e5c@redhat.com>
Message-ID: <1481113215.2684.16.camel@oracle.com>

Hi,

On Wed, 2016-12-07 at 11:26 +0000, Andrew Haley wrote:
> On 07/12/16 11:15, Thomas Schatzl wrote:
> > 
> > Hi,
> > 
> > On Wed, 2016-12-07 at 11:08 +0000, Andrew Haley wrote:
> > > 
> > > I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.
> > "-Xlog:gc+ref=debug"
> > 
> > > 
> > > 
> > > I want to see this output:
> > > 
> > > ? log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: "
> > > SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
> > > ?????????????????????stats.soft_count(), stats.weak_count(),
> > > stats.final_count(), stats.phantom_count());
> > > ? log_develop_trace(gc, ref)("JNI Weak Reference count: "
> > > SIZE_FORMAT, count_jni_refs());
> > > 
> > > 
> > > I tried -Xlog:help and searc hed on the web for information about
> > > the
> > > -Xlog syntax, but no luck.
> > -Xlog:help gives a pretty comprehensive output with BNF syntax
> > description here. It also includes a lot of examples.
> Perhaps, but none of the examples actually contain "+".
> 

http://openjdk.java.net/jeps/158?contains even more comprehensive
examples :)

I filed JDK-8170855, you are right.

> > Particularly the sentence below the BNF string gives an explanation
> > of "what" should be.
> > 
> > Maybe you have some suggestions to improve the text?
> Indeed I do.??An example which contains the crucial "+" would be a
> start.
> Like this:
> 
> -Xlog:gc+ref=debug
> 	 Log messages tagged with 'gc' and 'ref' tags using 'debug'
> level to stdout, with default decorations.
> 
> The crucial I didn't realize was that in
> 
> ? log_debug(gc, ref)
> 
> both "gc" and "ref" are tags.??It's not obvious, but I suppose if I'd
> studied the way the logging framework is called it would have been
> clearer.??Nonethless, you shouldn't have to be a developer who knows
> the logging API just in order to get some log output, and the syntax
> is very obscure.
> 

I think in this case looking at the use in the sources maybe
contributed to the confusion. I.e. you might come to the conclusion
that "gc" is not a tag?

The usage string seems clear in that "what" is "... a combination of
tags and levels on [I think this is a typo] the form
tag1[+tag2][*]=level", with a set of available tags further below.

> Is this stuff documented anywhere?

Somebody from the serviceability team can probably tell you more about
the location of a official documentation.

As for documentation of the various tags, and what they print in
particular, I do not think there is one (apart from the sources). Maybe
somebody else can give you more insights.

My suggestion is to start off with e.g. gc*=debug/all=debug and from
that create a set of messages you need (or if you are a dev look at the
source code for the message you want).

Thanks,
? Thomas


From igor.ignatyev at oracle.com  Wed Dec  7 12:20:33 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 7 Dec 2016 15:20:33 +0300
Subject: Gtest: CreateVM is not called when isolated tests are run?
In-Reply-To: <CAA-vtUzMCKzAC-N_mPUncNCmmer7ZD=w56HS18jSN-Cc7YGvWg@mail.gmail.com>
References: <CAA-vtUzMCKzAC-N_mPUncNCmmer7ZD=w56HS18jSN-Cc7YGvWg@mail.gmail.com>
Message-ID: <3AD8CE0C-F194-4F5B-A523-71424AB0CD89@oracle.com>

Dear Thomas,

I guess you are using TEST macro to define your tests. TEST is meant to be used for normal unit tests which does not depend on JVM, hence we do not call CreateVM, and your tests fail. you should use either TEST_VM or, if a test changes JVM state so it can?t be reused by other tests, TEST_OTHER_VM.

regarding LogStream tests, it?s a bug. these tests depend on JVM and should be changed to TEST_VM.

Thanks,
? Igor

> On Dec 7, 2016, at 1:52 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi all,
> 
> I am writing a metaspace-related gtest and was noticing my test to assert
> in Thread::current() because the test thread was not attached to the VM.
> When executed together with all other tests, it works.
> 
> Some other tests are affected as well, e.g. LogStream tests:
> 
> ./hotspot/variant-server/libjvm/gtest/gtestLauncher.exe -jdk ./images/jdk/
> --gtest_filter=LogStream*
> 
> [ RUN      ] LogStreamTest.from_log
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=\runtime/thread.hpp:662
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error
> (c:\d031900\openjdk\jdk9-hs2\source\hotspot\src\share\vm\runtime/thread.hpp:662),
> pid=17512, tid=7260
> #  assert(current != 0LL) failed: Thread::current() called on detached
> thread
> 
> Did anyone else notice this behaviour?
> 
> I see that when I run all tests (when omitting the filter argument),
> Thread::create_vm is called, but not when the test is run isolated. So, the
> VM is not initialized and all but the most primitive tests will fail.
> 
> Is this intended or would this be a bug?
> 
> Kind Regards, Thomas


From stefan.karlsson at oracle.com  Wed Dec  7 12:32:41 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 7 Dec 2016 13:32:41 +0100
Subject: How to get reference processing logging?
In-Reply-To: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
References: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
Message-ID: <341ea381-520c-8931-5dc8-6796a918887f@oracle.com>

Hi Andrew,

On 2016-12-07 12:08, Andrew Haley wrote:
> I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.
>
> I want to see this output:
>
>   log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: " SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
>                      stats.soft_count(), stats.weak_count(), stats.final_count(), stats.phantom_count());
>   log_develop_trace(gc, ref)("JNI Weak Reference count: " SIZE_FORMAT, count_jni_refs());
>
>
> I tried -Xlog:help and searc hed on the web for information about the
> -Xlog syntax, but no luck.

 From -Xlog:help::
"-Xlog Usage: -Xlog[:[what][:[output][:[decorators][:output-options]]]]
	 where 'what' is a combination of tags and levels on the form 
tag1[+tag2...][*][=level][,...]
	 Unless wildcard (*) is specified, only log messages tagged with 
exactly the tags specified will be matched."

With:
  tag1 = gc
  tag2 = ref
  level = trace

you get -Xlog:gc+ref=trace.

hth,
StefanK

>
> Thanks,
>
> Andrew.
>

From mikael.gerdin at oracle.com  Wed Dec  7 12:50:50 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 7 Dec 2016 13:50:50 +0100
Subject: How to get reference processing logging?
In-Reply-To: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
References: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
Message-ID: <24d32432-bd87-012d-6d70-c63ea1da6d42@oracle.com>

Hi Andrew,

On 2016-12-07 12:08, Andrew Haley wrote:
> I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.
>
> I want to see this output:
>
>   log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: " SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
>                      stats.soft_count(), stats.weak_count(), stats.final_count(), stats.phantom_count());
>   log_develop_trace(gc, ref)("JNI Weak Reference count: " SIZE_FORMAT, count_jni_refs());
>
>
> I tried -Xlog:help and searc hed on the web for information about the
> -Xlog syntax, but no luck.

The -Xlog:help output probably needs an example to cover this case.
The command line you want is
-Xlog:gc+ref=debug
and
-Xlog:gc+ref=trace
respectively.

The tag syntax also allows wildcards, so if you want to see all the 
reference processing logging you could use
-Xlog:ref*=trace

Hope this clarifies it a bit
/Mikael

>
> Thanks,
>
> Andrew.
>

From sgehwolf at redhat.com  Wed Dec  7 12:57:17 2016
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 07 Dec 2016 13:57:17 +0100
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
Message-ID: <1481115437.3024.9.camel@redhat.com>

Hi,

Could somebody please review this Zero only change? The problem was
there before, but only the fix for JDK-8169711 brought it to the
surface. The returned method kind for
java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
in abstractInterpreter.cpp

The fix is to generate stub entries for
java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?

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

Thanks,
Severin

From thomas.stuefe at gmail.com  Wed Dec  7 13:23:43 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 7 Dec 2016 14:23:43 +0100
Subject: Gtest: CreateVM is not called when isolated tests are run?
In-Reply-To: <3AD8CE0C-F194-4F5B-A523-71424AB0CD89@oracle.com>
References: <CAA-vtUzMCKzAC-N_mPUncNCmmer7ZD=w56HS18jSN-Cc7YGvWg@mail.gmail.com>
	<3AD8CE0C-F194-4F5B-A523-71424AB0CD89@oracle.com>
Message-ID: <CAA-vtUzK3G0aCfv4=FT0OdMWxZjQD-cOwonXyO1_DsgF9HU=Og@mail.gmail.com>

Hi Igor,

excellent, thank you, that helped! Had to use TEST_VM_F because I am using
a fixture.

About TEST_VM and TEST_OTHER_VM, when using a fixture holding resources, as
long as I cleanup those resources in TearDown() it should be fine sharing
the VM with others, right?

Kind Regards, Thomas


On Wed, Dec 7, 2016 at 1:20 PM, Igor Ignatyev <igor.ignatyev at oracle.com>
wrote:

> Dear Thomas,
>
> I guess you are using TEST macro to define your tests. TEST is meant to be
> used for normal unit tests which does not depend on JVM, hence we do not
> call CreateVM, and your tests fail. you should use either TEST_VM or, if a
> test changes JVM state so it can?t be reused by other tests, TEST_OTHER_VM.
>
> regarding LogStream tests, it?s a bug. these tests depend on JVM and
> should be changed to TEST_VM.
>
> Thanks,
> ? Igor
>
> > On Dec 7, 2016, at 1:52 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Hi all,
> >
> > I am writing a metaspace-related gtest and was noticing my test to assert
> > in Thread::current() because the test thread was not attached to the VM.
> > When executed together with all other tests, it works.
> >
> > Some other tests are affected as well, e.g. LogStream tests:
> >
> > ./hotspot/variant-server/libjvm/gtest/gtestLauncher.exe -jdk
> ./images/jdk/
> > --gtest_filter=LogStream*
> >
> > [ RUN      ] LogStreamTest.from_log
> > # To suppress the following error report, specify this argument
> > # after -XX: or in .hotspotrc:  SuppressErrorAt=\runtime/thread.hpp:662
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error
> > (c:\d031900\openjdk\jdk9-hs2\source\hotspot\src\share\vm\
> runtime/thread.hpp:662),
> > pid=17512, tid=7260
> > #  assert(current != 0LL) failed: Thread::current() called on detached
> > thread
> >
> > Did anyone else notice this behaviour?
> >
> > I see that when I run all tests (when omitting the filter argument),
> > Thread::create_vm is called, but not when the test is run isolated. So,
> the
> > VM is not initialized and all but the most primitive tests will fail.
> >
> > Is this intended or would this be a bug?
> >
> > Kind Regards, Thomas
>
>

From igor.ignatyev at oracle.com  Wed Dec  7 13:29:21 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 7 Dec 2016 16:29:21 +0300
Subject: Gtest: CreateVM is not called when isolated tests are run?
In-Reply-To: <CAA-vtUzK3G0aCfv4=FT0OdMWxZjQD-cOwonXyO1_DsgF9HU=Og@mail.gmail.com>
References: <CAA-vtUzMCKzAC-N_mPUncNCmmer7ZD=w56HS18jSN-Cc7YGvWg@mail.gmail.com>
	<3AD8CE0C-F194-4F5B-A523-71424AB0CD89@oracle.com>
	<CAA-vtUzK3G0aCfv4=FT0OdMWxZjQD-cOwonXyO1_DsgF9HU=Og@mail.gmail.com>
Message-ID: <7C714655-8934-44EB-A549-44F80C318BEB@oracle.com>

Hi Thomas,

I?m glad that helped. when I wrote TEST/TEST_VM, I actually meant the whole macro family: TEST, TEST_F, TEST_P etc, sorry if it confused you.

if TearDown function cleans up resources and restores JVM?s global state, e.g. flags, TEST_VM macro family is fine.

Thanks,
? Igor

> On Dec 7, 2016, at 4:23 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi Igor,
> 
> excellent, thank you, that helped! Had to use TEST_VM_F because I am using a fixture.
> 
> About TEST_VM and TEST_OTHER_VM, when using a fixture holding resources, as long as I cleanup those resources in TearDown() it should be fine sharing the VM with others, right?
> 
> Kind Regards, Thomas
> 
> 
> On Wed, Dec 7, 2016 at 1:20 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> Dear Thomas,
> 
> I guess you are using TEST macro to define your tests. TEST is meant to be used for normal unit tests which does not depend on JVM, hence we do not call CreateVM, and your tests fail. you should use either TEST_VM or, if a test changes JVM state so it can?t be reused by other tests, TEST_OTHER_VM.
> 
> regarding LogStream tests, it?s a bug. these tests depend on JVM and should be changed to TEST_VM.
> 
> Thanks,
> ? Igor
> 
> > On Dec 7, 2016, at 1:52 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> >
> > Hi all,
> >
> > I am writing a metaspace-related gtest and was noticing my test to assert
> > in Thread::current() because the test thread was not attached to the VM.
> > When executed together with all other tests, it works.
> >
> > Some other tests are affected as well, e.g. LogStream tests:
> >
> > ./hotspot/variant-server/libjvm/gtest/gtestLauncher.exe -jdk ./images/jdk/
> > --gtest_filter=LogStream*
> >
> > [ RUN      ] LogStreamTest.from_log
> > # To suppress the following error report, specify this argument
> > # after -XX: or in .hotspotrc:  SuppressErrorAt=\runtime/thread.hpp:662
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error
> > (c:\d031900\openjdk\jdk9-hs2\source\hotspot\src\share\vm\runtime/thread.hpp:662),
> > pid=17512, tid=7260
> > #  assert(current != 0LL) failed: Thread::current() called on detached
> > thread
> >
> > Did anyone else notice this behaviour?
> >
> > I see that when I run all tests (when omitting the filter argument),
> > Thread::create_vm is called, but not when the test is run isolated. So, the
> > VM is not initialized and all but the most primitive tests will fail.
> >
> > Is this intended or would this be a bug?
> >
> > Kind Regards, Thomas
> 
> 


From thomas.stuefe at gmail.com  Wed Dec  7 13:31:07 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 7 Dec 2016 14:31:07 +0100
Subject: Gtest: CreateVM is not called when isolated tests are run?
In-Reply-To: <7C714655-8934-44EB-A549-44F80C318BEB@oracle.com>
References: <CAA-vtUzMCKzAC-N_mPUncNCmmer7ZD=w56HS18jSN-Cc7YGvWg@mail.gmail.com>
	<3AD8CE0C-F194-4F5B-A523-71424AB0CD89@oracle.com>
	<CAA-vtUzK3G0aCfv4=FT0OdMWxZjQD-cOwonXyO1_DsgF9HU=Og@mail.gmail.com>
	<7C714655-8934-44EB-A549-44F80C318BEB@oracle.com>
Message-ID: <CAA-vtUxOBBCYBmE8UZ2ja5Lkfq5ZuioECq=XPsjNrY-d0Yv7YQ@mail.gmail.com>

Thanks again! This was quick and helpful :)

..Thomas

On Wed, Dec 7, 2016 at 2:29 PM, Igor Ignatyev <igor.ignatyev at oracle.com>
wrote:

> Hi Thomas,
>
> I?m glad that helped. when I wrote TEST/TEST_VM, I actually meant the
> whole macro family: TEST, TEST_F, TEST_P etc, sorry if it confused you.
>
> if TearDown function cleans up resources and restores JVM?s global state,
> e.g. flags, TEST_VM macro family is fine.
>
> Thanks,
> ? Igor
>
> > On Dec 7, 2016, at 4:23 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Hi Igor,
> >
> > excellent, thank you, that helped! Had to use TEST_VM_F because I am
> using a fixture.
> >
> > About TEST_VM and TEST_OTHER_VM, when using a fixture holding resources,
> as long as I cleanup those resources in TearDown() it should be fine
> sharing the VM with others, right?
> >
> > Kind Regards, Thomas
> >
> >
> > On Wed, Dec 7, 2016 at 1:20 PM, Igor Ignatyev <igor.ignatyev at oracle.com>
> wrote:
> > Dear Thomas,
> >
> > I guess you are using TEST macro to define your tests. TEST is meant to
> be used for normal unit tests which does not depend on JVM, hence we do not
> call CreateVM, and your tests fail. you should use either TEST_VM or, if a
> test changes JVM state so it can?t be reused by other tests, TEST_OTHER_VM.
> >
> > regarding LogStream tests, it?s a bug. these tests depend on JVM and
> should be changed to TEST_VM.
> >
> > Thanks,
> > ? Igor
> >
> > > On Dec 7, 2016, at 1:52 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > I am writing a metaspace-related gtest and was noticing my test to
> assert
> > > in Thread::current() because the test thread was not attached to the
> VM.
> > > When executed together with all other tests, it works.
> > >
> > > Some other tests are affected as well, e.g. LogStream tests:
> > >
> > > ./hotspot/variant-server/libjvm/gtest/gtestLauncher.exe -jdk
> ./images/jdk/
> > > --gtest_filter=LogStream*
> > >
> > > [ RUN      ] LogStreamTest.from_log
> > > # To suppress the following error report, specify this argument
> > > # after -XX: or in .hotspotrc:  SuppressErrorAt=\runtime/
> thread.hpp:662
> > > #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  Internal Error
> > > (c:\d031900\openjdk\jdk9-hs2\source\hotspot\src\share\vm\
> runtime/thread.hpp:662),
> > > pid=17512, tid=7260
> > > #  assert(current != 0LL) failed: Thread::current() called on detached
> > > thread
> > >
> > > Did anyone else notice this behaviour?
> > >
> > > I see that when I run all tests (when omitting the filter argument),
> > > Thread::create_vm is called, but not when the test is run isolated.
> So, the
> > > VM is not initialized and all but the most primitive tests will fail.
> > >
> > > Is this intended or would this be a bug?
> > >
> > > Kind Regards, Thomas
> >
> >
>
>

From marcus.larsson at oracle.com  Wed Dec  7 14:34:06 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 7 Dec 2016 15:34:06 +0100
Subject: How to get reference processing logging?
In-Reply-To: <1481113215.2684.16.camel@oracle.com>
References: <55135ba6-f97e-1793-7587-6150b70d1e90@redhat.com>
	<1481109312.2684.4.camel@oracle.com>
	<b5de4a39-7a92-dff9-761b-4c0b128d0e5c@redhat.com>
	<1481113215.2684.16.camel@oracle.com>
Message-ID: <a66b65c8-1315-635f-9986-45344f2b857e@oracle.com>

Hi,


On 12/07/2016 01:20 PM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2016-12-07 at 11:26 +0000, Andrew Haley wrote:
>> On 07/12/16 11:15, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2016-12-07 at 11:08 +0000, Andrew Haley wrote:
>>>> I've tried "-Xlog:gc::ref" and "-Xlog:gc=ref" but neither works.
>>> "-Xlog:gc+ref=debug"
>>>
>>>>
>>>> I want to see this output:
>>>>
>>>>    log_debug(gc, ref)("Ref Counts: Soft: " SIZE_FORMAT " Weak: "
>>>> SIZE_FORMAT " Final: " SIZE_FORMAT " Phantom: " SIZE_FORMAT,
>>>>                       stats.soft_count(), stats.weak_count(),
>>>> stats.final_count(), stats.phantom_count());
>>>>    log_develop_trace(gc, ref)("JNI Weak Reference count: "
>>>> SIZE_FORMAT, count_jni_refs());
>>>>
>>>>
>>>> I tried -Xlog:help and searc hed on the web for information about
>>>> the
>>>> -Xlog syntax, but no luck.
>>> -Xlog:help gives a pretty comprehensive output with BNF syntax
>>> description here. It also includes a lot of examples.
>> Perhaps, but none of the examples actually contain "+".
>>
> http://openjdk.java.net/jeps/158 contains even more comprehensive
> examples :)
>
> I filed JDK-8170855, you are right.

Good point! We should have that as an example.

>
>>> Particularly the sentence below the BNF string gives an explanation
>>> of "what" should be.
>>>
>>> Maybe you have some suggestions to improve the text?
>> Indeed I do.  An example which contains the crucial "+" would be a
>> start.
>> Like this:
>>
>> -Xlog:gc+ref=debug
>> 	 Log messages tagged with 'gc' and 'ref' tags using 'debug'
>> level to stdout, with default decorations.
>>
>> The crucial I didn't realize was that in
>>
>>    log_debug(gc, ref)
>>
>> both "gc" and "ref" are tags.  It's not obvious, but I suppose if I'd
>> studied the way the logging framework is called it would have been
>> clearer.  Nonethless, you shouldn't have to be a developer who knows
>> the logging API just in order to get some log output, and the syntax
>> is very obscure.
>>
> I think in this case looking at the use in the sources maybe
> contributed to the confusion. I.e. you might come to the conclusion
> that "gc" is not a tag?
>
> The usage string seems clear in that "what" is "... a combination of
> tags and levels on [I think this is a typo] the form
> tag1[+tag2][*]=level", with a set of available tags further below.
>
>> Is this stuff documented anywhere?
> Somebody from the serviceability team can probably tell you more about
> the location of a official documentation.

The UL JEP is probably the best documentation ATM. There will be a 
section for the new framework in the docs for JDK 9, but I don't think 
there's any preview of that available right now.

>
> As for documentation of the various tags, and what they print in
> particular, I do not think there is one (apart from the sources). Maybe
> somebody else can give you more insights.

Tags are typically too general by themselves to have a description. 
What's interesting is the combination of tags.

>
> My suggestion is to start off with e.g. gc*=debug/all=debug and from
> that create a set of messages you need (or if you are a dev look at the
> source code for the message you want).

+1

Thanks,
Marcus

>
> Thanks,
>    Thomas
>


From igor.ignatyev at oracle.com  Wed Dec  7 15:17:06 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 7 Dec 2016 18:17:06 +0300
Subject: [heads-up] changes in quarantine/exclusion of hotspot jtreg tests
Message-ID: <FD5C62B5-0772-41E9-9091-07B4BA598A44@oracle.com>

Hi everyone,

I would like to give you a heads-up about the recent changes[1] in how we quarantine and exclude jtreg tests in hotspot and possible impact of these changes.

in two words:
1. To quarantine a hotspot jtreg test please update ProblemList, do not use @ignore (use @ignore only to never execute a test until the problem is fixed).
2. If you use RBT or 'make test', you do not need to change anything.
3. If you use jtreg directly, please add '-exclude:$WS/hotspot/test/ProblemList.txt -exclude:$WS/hotspot/test/closed/ProblemList.txt' not to run quarantined tests.

in more details:
The current processes enact us to exclude a failing test from regular execution if we can not fix the problem which causes the test to fail. As you may know, we differentiate two types of failing tests basing on the value of their running: "quarantined" and ?excluded". A quarantined test is a test which sporadically fails, but there is still a value in running this test. An excluded test is a test which always fails or can break other tests or execution environment. The changes[1] unify handling failing jdk and hotspot jtreg tests: quarantined tests should be put into ProblemList.txt, excluded tests should be marked by @ignore. You can find more details on that decision in bug descriptions[1-2] and RFR[3].
So as of today, a quarantined hotspot jtreg test must be put to ProblemList, please stop using @ignore for that.

No matter which exclusion mechanism is used, id of the bug causing a problem must be provided. This must be the bug which will fix the problem, not the one used to remove a test from execution. In case of excluded tests, one must specify a space separated list of bug ids after @ignore tag in test's description[4]. In ProblemList.txt, a quarantined testname(test filename) must be followed by a comma separated list of bug ids[5]. The one who fixes a bug is responsible for cleaning ProblemList/@ignore.

The makefiles and scripts are adjusted to the fix, therefore for RBT, JPRT users and those who run tests by 'make test? these changes are absolutely transparent, neither quarantine nor excluded tests will be run by default. The changes affect only those who run tests using jtreg directly. To skip running quarantined tests, which now listed in ProblemList.txt, an extra '-exclude:<full-path-to-ProblemList.txt>' jtreg flag should be specified, if there is more than one ProblemList, e.g. open and closed, one should specify '-exclude' option several times. To skip running excluded tests, '-ignore:quite' flag should be given (otherwise such tests will be reported as errors).

The following are examples for three main use-cases ($WS is a full path to the root of workspace):
1. run only stable tests (skip quarantined and excluded tests): 
$ jtreg -dir:$WS/hotspot/test -ignore:quite -exclude:$WS/hotspot/test/ProblemList.txt -exclude:$WS/hotspot/test/closed/ProblemList.txt :hotspot_all
or if you do not have closed part:
$ jtreg -dir:$WS/hotspot/test -ignore:quite -exclude:$WS/hotspot/test/ProblemList.txt :hotspot_all
2. run stable and quarantined tests:
$ jtreg -dir:$WS/hotspot/test -ignore:quite :hotspot_all
3. run all tests:
$ jtreg -dir:$WS/hotspot/test -ignore:run :hotspot_all

Thanks,
? Igor

[1] https://bugs.openjdk.java.net/browse/JDK-8078450
[2] https://bugs.openjdk.java.net/browse/JDK-8145079
[3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html
[4] test/bar/TestFoo.java:
/**
 * @test TestFoo
 * @ignore 1234567 2345678
 */
[5] test/ProblemList.txt:
test/bar/TestBaz.java 7654321,8765432 generic-all


From jesper.wilhelmsson at oracle.com  Wed Dec  7 15:51:42 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 7 Dec 2016 16:51:42 +0100
Subject: jdk9/hs will close tonight
Message-ID: <5cebd810-6c7f-88b3-a764-5e796cde62e9@oracle.com>

Hi,

To allow for the jdk9/hs repository to stabilize before we need to 
integrate up this Friday, we will close hs for any and all changes not 
explicitly approved.

We close tonight when the nightly snapshot is being taken, at 7 pm PT.

This concerns all code that is being tested and released by Oracle. 
Platform specific code that is not maintained by Oracle is not affected 
by this lock-down.

We expect to open hs again after the integration snapshot has been taken 
this weekend or early next week.

Thank you for your co-operation!
/Jesper

From igor.ignatyev at oracle.com  Wed Dec  7 18:07:21 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 7 Dec 2016 21:07:21 +0300
Subject: [heads-up] changes in quarantine/exclusion of hotspot jtreg tests
In-Reply-To: <FD5C62B5-0772-41E9-9091-07B4BA598A44@oracle.com>
References: <FD5C62B5-0772-41E9-9091-07B4BA598A44@oracle.com>
Message-ID: <AEA7B6CF-4966-4149-A3A2-4770ACEBD72B@oracle.com>

it seems I made a typo in -ignore syntax. in all occurrences it should be '-ignore:quiet', not '-ignore:quite?. thanks for Dan Daugherty who noticed that.

? Igor

> On Dec 7, 2016, at 6:17 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Hi everyone,
> 
> I would like to give you a heads-up about the recent changes[1] in how we quarantine and exclude jtreg tests in hotspot and possible impact of these changes.
> 
> in two words:
> 1. To quarantine a hotspot jtreg test please update ProblemList, do not use @ignore (use @ignore only to never execute a test until the problem is fixed).
> 2. If you use RBT or 'make test', you do not need to change anything.
> 3. If you use jtreg directly, please add '-exclude:$WS/hotspot/test/ProblemList.txt -exclude:$WS/hotspot/test/closed/ProblemList.txt' not to run quarantined tests.
> 
> in more details:
> The current processes enact us to exclude a failing test from regular execution if we can not fix the problem which causes the test to fail. As you may know, we differentiate two types of failing tests basing on the value of their running: "quarantined" and ?excluded". A quarantined test is a test which sporadically fails, but there is still a value in running this test. An excluded test is a test which always fails or can break other tests or execution environment. The changes[1] unify handling failing jdk and hotspot jtreg tests: quarantined tests should be put into ProblemList.txt, excluded tests should be marked by @ignore. You can find more details on that decision in bug descriptions[1-2] and RFR[3].
> So as of today, a quarantined hotspot jtreg test must be put to ProblemList, please stop using @ignore for that.
> 
> No matter which exclusion mechanism is used, id of the bug causing a problem must be provided. This must be the bug which will fix the problem, not the one used to remove a test from execution. In case of excluded tests, one must specify a space separated list of bug ids after @ignore tag in test's description[4]. In ProblemList.txt, a quarantined testname(test filename) must be followed by a comma separated list of bug ids[5]. The one who fixes a bug is responsible for cleaning ProblemList/@ignore.
> 
> The makefiles and scripts are adjusted to the fix, therefore for RBT, JPRT users and those who run tests by 'make test? these changes are absolutely transparent, neither quarantine nor excluded tests will be run by default. The changes affect only those who run tests using jtreg directly. To skip running quarantined tests, which now listed in ProblemList.txt, an extra '-exclude:<full-path-to-ProblemList.txt>' jtreg flag should be specified, if there is more than one ProblemList, e.g. open and closed, one should specify '-exclude' option several times. To skip running excluded tests, '-ignore:quite' flag should be given (otherwise such tests will be reported as errors).
> 
> The following are examples for three main use-cases ($WS is a full path to the root of workspace):
> 1. run only stable tests (skip quarantined and excluded tests): 
> $ jtreg -dir:$WS/hotspot/test -ignore:quite -exclude:$WS/hotspot/test/ProblemList.txt -exclude:$WS/hotspot/test/closed/ProblemList.txt :hotspot_all
> or if you do not have closed part:
> $ jtreg -dir:$WS/hotspot/test -ignore:quite -exclude:$WS/hotspot/test/ProblemList.txt :hotspot_all
> 2. run stable and quarantined tests:
> $ jtreg -dir:$WS/hotspot/test -ignore:quite :hotspot_all
> 3. run all tests:
> $ jtreg -dir:$WS/hotspot/test -ignore:run :hotspot_all
> 
> Thanks,
> ? Igor
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8078450
> [2] https://bugs.openjdk.java.net/browse/JDK-8145079
> [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html
> [4] test/bar/TestFoo.java:
> /**
> * @test TestFoo
> * @ignore 1234567 2345678
> */
> [5] test/ProblemList.txt:
> test/bar/TestBaz.java 7654321,8765432 generic-all
> 


From bob.vandette at oracle.com  Wed Dec  7 18:51:45 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 7 Dec 2016 13:51:45 -0500
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
	<35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
	<84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
Message-ID: <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>

Thanks Magnus,  see comments below ..

> On Dec 7, 2016, at 3:44 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2016-12-05 16:23, Bob Vandette wrote:
>>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> <mailto:vladimir.kozlov at oracle.com> wrote:
>>> 
>>> hi Bob,
>>> 
>>> I would suggest to have separate webrevs for different repositories because different groups should look on them.
>> There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.
> 
> Build changes mostly look good. A few comments:
> 
> * We try to use the autoconf defined "$with_opt" variables only when checking and verifying arguments. In hotspot.m4, please let SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. OPENJDK_TARGET_CPU_PORT, and use that to do the check in HOTSPOT_SETUP_JVM_FEATURES.

I think it should be called HOTSPOT_TARGET_CPU_PORT since this variable only impact which directory hotspot uses for it build.
I also removed a redundant if test "x$with_cpu_port" != x; in SETUP_HOTSPOT_TARGET_CPU_PORT.

+  # Override hotspot cpu definitions for ARM platforms
+  if test "x$OPENJDK_TARGET_CPU" = xarm; then
+    HOTSPOT_TARGET_CPU=arm_32
+    HOTSPOT_TARGET_CPU_DEFINE="ARM32"
+    JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char"
+    JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char"
+  elif test "x$OPENJDK_TARGET_CPU" = xaarch64 && test "x$HOTSPOT_TARGET_CPU_PORT" = xarm64; then
+    HOTSPOT_TARGET_CPU=arm_64
+    HOTSPOT_TARGET_CPU_ARCH=arm
+    JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char"
+    JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char"
+  fi
+

+AC_DEFUN([SETUP_HOTSPOT_TARGET_CPU_PORT],
+[
+  AC_ARG_WITH(cpu-port, [AS_HELP_STRING([--with-cpu-port],
+      [specify sources to use for Hotspot 64-bit ARM port (arm64,aarch64) @<:@aarch64@:>@ ])])
+
+  if test "x$with_cpu_port" != x; then
+    if test "x$OPENJDK_TARGET_CPU" != xaarch64; then
+      AC_MSG_ERROR([--with-cpu-port only available on aarch64])
+    fi
+    if test "x$with_cpu_port" != xarm64 && \
+        test "x$with_cpu_port" != xaarch64; then
+      AC_MSG_ERROR([--with-cpu-port must specify arm64 or aarch64])
+    fi
+    HOTSPOT_TARGET_CPU_PORT = $with_cpu_port
+  fi
+])
+
+

> 
> * In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU instead, since explicitly checking the CPU_ARCH variable seems to indicate that we want to test more than a single CPU, but for arm there is only one. (At first, I thought this was a test for "arm64" as well. If this was the intention, then the code is broken.)
> 
Ok.

> * In CompileJvm.gmk, you might want to rephrase the comment, since from now on both the original aarch64 and the new arm64 port are "open". What the code does is in fact to select between the two different aarch64 ports.

Done.  I also found another comment that needed to be updated.

diff --git a/make/lib/CompileJvm.gmk b/make/lib/CompileJvm.gmk
--- a/make/lib/CompileJvm.gmk
+++ b/make/lib/CompileJvm.gmk
@@ -63,8 +63,8 @@
 # INCLUDE_SUFFIX_* is only meant for including the proper
 # platform files. Don't use it to guard code. Use the value of
 # HOTSPOT_TARGET_CPU_DEFINE etc. instead.
-# Remaining TARGET_ARCH_* is needed to distinguish closed and open
-# 64-bit ARM ports (also called AARCH64).
+# Remaining TARGET_ARCH_* is needed to select the cpu specific 
+# sources for 64-bit ARM ports (arm versus aarch64).
 JVM_CFLAGS_TARGET_DEFINES += \
     -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) \
     -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \
@@ -139,6 +139,20 @@
 ################################################################################
 # Platform specific setup
 
+# ARM source selection
+
+ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-arm)
+  JVM_EXCLUDE_PATTERNS += arm_64
+
+else ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-aarch64)
+  # For 64-bit arm builds, we use the 64 bit hotspot/src/cpu/arm 
+  # hotspot sources if HOTSPOT_TARGET_CPU_ARCH is set to arm.
+  # Exclude the aarch64 and 32 bit arm files for this build.
+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), arm)
+    JVM_EXCLUDE_PATTERNS += arm_32 aarch64
+  endif
+endif
+

Bob.


> 
> /Magnus
> 
> 
>> 
>>> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>
>>> 
>>> Why do you need cahnges in SA libproc.h?
>> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.
>> 
>> I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:
>> 
>> #if defined(arm) || defined(arm64)
>> #define user_regs_struct user_regs
>> #endif
>> 
>> This change would result  in the exact same declaration based on the number of registers
>> derived from the structure in user.h. 
>> 
>> Bob.
>> 
>> 
>>> I saw Hotspot changes before and I think they are fine (did not dive deep).
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 12/2/16 12:28 PM, Bob Vandette wrote:
>>>> Please review the proposed changes to be integrated under JEP 297.
>>>> 
>>>> Summary:
>>>> 
>>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>>>> 
>>>> This changeset also removes the support for the pregenerated interpreter since
>>>> this is no longer supported.
>>>> 
>>>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>>>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>>>> 
>>>> JEP 297:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8168503 <https://bugs.openjdk.java.net/browse/JDK-8168503>
>>>> 
>>>> Webrev:
>>>> 
>>>> http://cr.openjdk.java.net/~bobv/8168503 <http://cr.openjdk.java.net/~bobv/8168503>
>>>> 
>>>> 
>>>> Note:
>>>> 
>>>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264>
>>>> 
>>>> Thanks,
>>>> Bob Vandette
>>>> 
> 


From gromero at linux.vnet.ibm.com  Wed Dec  7 19:51:13 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 7 Dec 2016 17:51:13 -0200
Subject: [8u] Request for approval for 8170873 - PPC64: Poor StrictMath
	performance due to non-optimized compilation
Message-ID: <58486831.3030903@linux.vnet.ibm.com>

Hi,

Could you please approve the backport to jdk8u-dev of the following fix:

8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized
compilation

Bug       : https://bugs.openjdk.java.net/browse/JDK-8170153
Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/
Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/
Review    : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html
URL 1/2   : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c
URL 2/2   : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8

The original change affects s390x and aarch64 as well but since both
architectures  are not present on 8u I propose a new webrev which just excludes
them turning it a ppc-only fix on 8u:

Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/
Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170873/jdk/

I also need a sponsor for pushing that change if the approval is granted.

Thank you.


Best regards,
Gustavo


From gromero at linux.vnet.ibm.com  Wed Dec  7 19:55:21 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 7 Dec 2016 17:55:21 -0200
Subject: [8u] Request for approval for 8170873 - PPC64: Poor StrictMath
	performance due to non-optimized compilation
In-Reply-To: <58486831.3030903@linux.vnet.ibm.com>
References: <58486831.3030903@linux.vnet.ibm.com>
Message-ID: <58486929.1050006@linux.vnet.ibm.com>

I'm sorry. I included hotspot-dev by mistake. Please ignore that mistake.

Regards,
Gustavo

On 07-12-2016 17:51, Gustavo Romero wrote:
> Hi,
> 
> Could you please approve the backport to jdk8u-dev of the following fix:
> 
> 8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized
> compilation
> 
> Bug       : https://bugs.openjdk.java.net/browse/JDK-8170153
> Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/
> Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/
> Review    : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025348.html
> URL 1/2   : http://hg.openjdk.java.net/jdk9/dev/rev/3c7b02f5fa7c
> URL 2/2   : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b6bad6302dc8
> 
> The original change affects s390x and aarch64 as well but since both
> architectures  are not present on 8u I propose a new webrev which just excludes
> them turning it a ppc-only fix on 8u:
> 
> Webrev 1/2: http://cr.openjdk.java.net/~gromero/8170873/
> Webreb 2/2: http://cr.openjdk.java.net/~gromero/8170873/jdk/
> 
> I also need a sponsor for pushing that change if the approval is granted.
> 
> Thank you.
> 
> 
> Best regards,
> Gustavo
> 


From brent.christian at oracle.com  Wed Dec  7 21:56:58 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 07 Dec 2016 13:56:58 -0800
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
Message-ID: <584885AA.9060202@oracle.com>

Hi,

Please review my fix for 8169389.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8169389
Webrev:
http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/

The addition of classloader names (JDK-6749237) updated the format of 
StackTraceElement.toString().  A field was added to store the 
"[[class-loader-name]/[module-name[@module-version]]]" portion of the 
returned String.

Instead of storing a String, we can cut down on footprint by using a 
bitfield to indicate which fields to include in the toString() output.

Looking at the heap usage of a simple test case indicates ~25% reduction 
in space used by Throwable's StackTraceElement[].  (Of course this could 
vary quite a bit, depending on the specifics of the call stack.)

The additional byte field does not increase the instance size of a 
StackTraceElement; it is within space already lost for alignment (per 
linux_x64 w/ CompressedOops).

While working on this, it was noticed that with the new toString() 
format, there are circumstances in which two StackTraceElements can be 
equals(), but return different values from toString().  I thought it was 
worth updating the JavaDoc to call out this unusual possibility.

Likewise, there can be information reflected in the StackTraceElement 
getter methods that is not reflected in the toString() value.  I updated 
the test code to check for this.

Thanks,
-Brent


From vladimir.kozlov at oracle.com  Wed Dec  7 22:10:15 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 7 Dec 2016 14:10:15 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler
Message-ID: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8166417

It is part of JEP 295: Ahead-of-Time Compilation
https://bugs.openjdk.java.net/browse/JDK-8166089

http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/

This is formal review request for integration Graal-core sources into 
OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to 
integrated Graal-core sources into JDK and add build changes to build 
Graal module.

Note, changes are based on latest jdk9/hs sources which do not have 
latest jigsaw update yet. With jigsaw update small changes will be done 
to module-info.java.extra in java.base:

   exports jdk.internal.misc to jdk.vm.compiler;
+ opens jdk.internal.misc to jdk.vm.compiler;

- exports com.sun.crypto.provider to jdk.vm.compiler;
+ opens com.sun.crypto.provider to jdk.vm.compiler;

And changes in top make/GensrcModuleInfo.gmk will not be needed.



Graal is a dynamic compiler written in Java that integrates with the 
HotSpot JVM. It has a focus on high performance and extensibility. In 
addition, it provides optimized performance for Truffle based languages 
running on the JVM.

https://github.com/graalvm/graal-core

Oracle Labs is developing and maintaining it.

Here are people who contributed into Graal development (sorry if someone 
is missing or misspelled, please speak):

~70k LOC: Douglas Simon
~60k LOC: Lukas Stadler
~30k LOC: Thomas Wuerthinger
~30k LOC: Tom Rodriguez
~30k LOC: Roland Schatz
~30k LOC: Josef Eisl
~30k LOC: Christian Wimmer
~16k LOC: Chris Thalinger
~13k LOC: Gilles Duboscq
~11k LOC: David Leopoldseder
~ 8k LOC: Stefan Anzinger
~ 8k LOC: Christian Humer

Other contributors >100 LOC in approximate order of contribution size:
Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos 
Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, 
Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef 
Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, 
Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.


Thanks,
Vladimir

From gromero at linux.vnet.ibm.com  Wed Dec  7 22:14:35 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 7 Dec 2016 20:14:35 -0200
Subject: PPC64: JVM crash on Hadoop + Terasort
Message-ID: <584889CB.7080004@linux.vnet.ibm.com>

Hi,

We are experiencing some JVM crashes on 8 when trying to load
a large Terasort data set (1 TiB) into Hadoop on PPC64.

Please refer to the following hs_err log:
http://paste.fedoraproject.org/501254/48114364/raw/

The crash seems to be due to an indexed doubleword store in
libjvm.so:

0x85aeb4:	2a 49 e8 7e 	stdx    r23,r8,r9

that by its turn is generated from

<CardTableModRefBS::process_stride(Space*, MemRegion, int, int, OopsInGenClosure*, CardTableRS*, signed char**, unsigned long, unsigned long)+468>:	stdx    r23,r8,r9

present in Parallel GC code hotspot/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp

259	  } else {
260	    // In this case we can help our neighbour by just asking them
261	    // to stop at our first card (even though it may not be dirty).
262	    NOISY(tty->print_cr(" LNC: first block is not a non-array object; setting LNC to first card of current chunk");)
263	    assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter");
264	    jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start());
265	    lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk;
266	  }

0x85aeb4: 2a 49 e8 7e stdx r23,r8,r9 is generated from parCardTableModRefBS.cpp:265 more precisely.

I'm not able to reproduce that yet on 9 and create a test case but
I would like to ask if someone know some issue potentially related to that
one and already reported to the JBS. I could not find any recent ones.

Also, what could be a good code or JVM configuration to exercise intensively that code,
i.e. the else branch parCardTableModRefBS.cpp:259-265.

Thank you very much.


Regards,
Gustavo


From gromero at linux.vnet.ibm.com  Wed Dec  7 22:20:37 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 7 Dec 2016 20:20:37 -0200
Subject: PPC64: JVM crash on Hadoop + Terasort
In-Reply-To: <584889CB.7080004@linux.vnet.ibm.com>
References: <584889CB.7080004@linux.vnet.ibm.com>
Message-ID: <58488B35.7040307@linux.vnet.ibm.com>

Also - I forgot to mention - the problem seems to disappear if OpenJDK 8 tag
65-b17 is used instead.

On 07-12-2016 20:14, Gustavo Romero wrote:
> Hi,
> 
> We are experiencing some JVM crashes on 8 when trying to load
> a large Terasort data set (1 TiB) into Hadoop on PPC64.
> 
> Please refer to the following hs_err log:
> http://paste.fedoraproject.org/501254/48114364/raw/
> 
> The crash seems to be due to an indexed doubleword store in
> libjvm.so:
> 
> 0x85aeb4:	2a 49 e8 7e 	stdx    r23,r8,r9
> 
> that by its turn is generated from
> 
> <CardTableModRefBS::process_stride(Space*, MemRegion, int, int, OopsInGenClosure*, CardTableRS*, signed char**, unsigned long, unsigned long)+468>:	stdx    r23,r8,r9
> 
> present in Parallel GC code hotspot/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
> 
> 259	  } else {
> 260	    // In this case we can help our neighbour by just asking them
> 261	    // to stop at our first card (even though it may not be dirty).
> 262	    NOISY(tty->print_cr(" LNC: first block is not a non-array object; setting LNC to first card of current chunk");)
> 263	    assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter");
> 264	    jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start());
> 265	    lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk;
> 266	  }
> 
> 0x85aeb4: 2a 49 e8 7e stdx r23,r8,r9 is generated from parCardTableModRefBS.cpp:265 more precisely.
> 
> I'm not able to reproduce that yet on 9 and create a test case but
> I would like to ask if someone know some issue potentially related to that
> one and already reported to the JBS. I could not find any recent ones.
> 
> Also, what could be a good code or JVM configuration to exercise intensively that code,
> i.e. the else branch parCardTableModRefBS.cpp:259-265.
> 
> Thank you very much.
> 
> 
> Regards,
> Gustavo
> 


From igor.veresov at oracle.com  Wed Dec  7 22:21:47 2016
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 7 Dec 2016 14:21:47 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
Message-ID: <502C698D-88CC-4874-A8F3-799E823ABE5E@oracle.com>

Perfect. :) Reviewed.

igor

> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8166417
> 
> It is part of JEP 295: Ahead-of-Time Compilation
> https://bugs.openjdk.java.net/browse/JDK-8166089
> 
> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
> 
> This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module.
> 
> Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base:
> 
>  exports jdk.internal.misc to jdk.vm.compiler;
> + opens jdk.internal.misc to jdk.vm.compiler;
> 
> - exports com.sun.crypto.provider to jdk.vm.compiler;
> + opens com.sun.crypto.provider to jdk.vm.compiler;
> 
> And changes in top make/GensrcModuleInfo.gmk will not be needed.
> 
> 
> 
> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM.
> 
> https://github.com/graalvm/graal-core
> 
> Oracle Labs is developing and maintaining it.
> 
> Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak):
> 
> ~70k LOC: Douglas Simon
> ~60k LOC: Lukas Stadler
> ~30k LOC: Thomas Wuerthinger
> ~30k LOC: Tom Rodriguez
> ~30k LOC: Roland Schatz
> ~30k LOC: Josef Eisl
> ~30k LOC: Christian Wimmer
> ~16k LOC: Chris Thalinger
> ~13k LOC: Gilles Duboscq
> ~11k LOC: David Leopoldseder
> ~ 8k LOC: Stefan Anzinger
> ~ 8k LOC: Christian Humer
> 
> Other contributors >100 LOC in approximate order of contribution size:
> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
> 
> 
> Thanks,
> Vladimir


From coleen.phillimore at oracle.com  Wed Dec  7 23:16:03 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 7 Dec 2016 18:16:03 -0500
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
Message-ID: <7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>


Hi,

Out of curiosity, why do you have this redundancy in the paths of new 
code files?  Is this because of modules?

*src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test
*
Thanks,
Coleen

On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8166417
>
> It is part of JEP 295: Ahead-of-Time Compilation
> https://bugs.openjdk.java.net/browse/JDK-8166089
>
> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>
> This is formal review request for integration Graal-core sources into 
> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to 
> integrated Graal-core sources into JDK and add build changes to build 
> Graal module.
>
> Note, changes are based on latest jdk9/hs sources which do not have 
> latest jigsaw update yet. With jigsaw update small changes will be 
> done to module-info.java.extra in java.base:
>
>   exports jdk.internal.misc to jdk.vm.compiler;
> + opens jdk.internal.misc to jdk.vm.compiler;
>
> - exports com.sun.crypto.provider to jdk.vm.compiler;
> + opens com.sun.crypto.provider to jdk.vm.compiler;
>
> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>
>
>
> Graal is a dynamic compiler written in Java that integrates with the 
> HotSpot JVM. It has a focus on high performance and extensibility. In 
> addition, it provides optimized performance for Truffle based 
> languages running on the JVM.
>
> https://github.com/graalvm/graal-core
>
> Oracle Labs is developing and maintaining it.
>
> Here are people who contributed into Graal development (sorry if 
> someone is missing or misspelled, please speak):
>
> ~70k LOC: Douglas Simon
> ~60k LOC: Lukas Stadler
> ~30k LOC: Thomas Wuerthinger
> ~30k LOC: Tom Rodriguez
> ~30k LOC: Roland Schatz
> ~30k LOC: Josef Eisl
> ~30k LOC: Christian Wimmer
> ~16k LOC: Chris Thalinger
> ~13k LOC: Gilles Duboscq
> ~11k LOC: David Leopoldseder
> ~ 8k LOC: Stefan Anzinger
> ~ 8k LOC: Christian Humer
>
> Other contributors >100 LOC in approximate order of contribution size:
> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos 
> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, 
> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef 
> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, 
> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>
>
> Thanks,
> Vladimir


From vladimir.kozlov at oracle.com  Wed Dec  7 23:32:59 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 7 Dec 2016 15:32:59 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
Message-ID: <9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>

jdk.vm.compiler is only one jigsaw module.

It is the project based layout (each directory is separate Java IDE 
project) :

Tom Rodriguez wrote:
 > Having the file structure follow the project structure is kind of the 
only sane way to organize it. It's really to be Java IDE friendly.

Thanks,
Vladimir

On 12/7/16 3:16 PM, Coleen Phillimore wrote:
>
> Hi,
>
> Out of curiosity, why do you have this redundancy in the paths of new
> code files?  Is this because of modules?
>
> *src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test
>
> *
> Thanks,
> Coleen
>
> On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>
>> It is part of JEP 295: Ahead-of-Time Compilation
>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>
>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>
>> This is formal review request for integration Graal-core sources into
>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>> integrated Graal-core sources into JDK and add build changes to build
>> Graal module.
>>
>> Note, changes are based on latest jdk9/hs sources which do not have
>> latest jigsaw update yet. With jigsaw update small changes will be
>> done to module-info.java.extra in java.base:
>>
>>   exports jdk.internal.misc to jdk.vm.compiler;
>> + opens jdk.internal.misc to jdk.vm.compiler;
>>
>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>
>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>
>>
>>
>> Graal is a dynamic compiler written in Java that integrates with the
>> HotSpot JVM. It has a focus on high performance and extensibility. In
>> addition, it provides optimized performance for Truffle based
>> languages running on the JVM.
>>
>> https://github.com/graalvm/graal-core
>>
>> Oracle Labs is developing and maintaining it.
>>
>> Here are people who contributed into Graal development (sorry if
>> someone is missing or misspelled, please speak):
>>
>> ~70k LOC: Douglas Simon
>> ~60k LOC: Lukas Stadler
>> ~30k LOC: Thomas Wuerthinger
>> ~30k LOC: Tom Rodriguez
>> ~30k LOC: Roland Schatz
>> ~30k LOC: Josef Eisl
>> ~30k LOC: Christian Wimmer
>> ~16k LOC: Chris Thalinger
>> ~13k LOC: Gilles Duboscq
>> ~11k LOC: David Leopoldseder
>> ~ 8k LOC: Stefan Anzinger
>> ~ 8k LOC: Christian Humer
>>
>> Other contributors >100 LOC in approximate order of contribution size:
>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>
>>
>> Thanks,
>> Vladimir
>

From mandy.chung at oracle.com  Thu Dec  8 00:05:09 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 7 Dec 2016 16:05:09 -0800
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
In-Reply-To: <584885AA.9060202@oracle.com>
References: <584885AA.9060202@oracle.com>
Message-ID: <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>


> On Dec 7, 2016, at 1:56 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi,
> 
> Please review my fix for 8169389.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8169389
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/
> :

Thanks for making this good change. Claes would be happy with the footprint saving.

I suggest to add two utility methods rather than the has method:
  boolean dropClassLoaderName()
  boolean dropModuleVersion()

 430    if (m != null && m.isNamed() &&
 431          (isHashedInJavaBase(m) || !m.getDescriptor().version().isPresent())) {
 432        bits |= JDK_NON_UPGRADEABLE_MODULE;
 433    }

I think this should simply be:
   if (isHashedInJavaBase(m)) {..}

Can you retain the javadoc of toLoaderModuleClassName, revised if appropriate, in the computeFormat method?

line 322-325: what about:

The toString method may return two different values on two 
StackTraceElement instances that are equal for example when
one created via the constructor and one obtained from Throwable 
or StackFrame where an implementation may choose to omit some
element in the returned string.

Is @apiNote in equals necessary?  Maybe the one added in toString is adequate?

Mandy

From coleen.phillimore at oracle.com  Thu Dec  8 03:58:28 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 7 Dec 2016 22:58:28 -0500
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <1481115437.3024.9.camel@redhat.com>
References: <1481115437.3024.9.camel@redhat.com>
Message-ID: <54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>


This looks good and I can sponsor this for you.  I haven't built Zero in 
a while.
Thanks,
Coleen

On 12/7/16 7:57 AM, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review this Zero only change? The problem was
> there before, but only the fix for JDK-8169711 brought it to the
> surface. The returned method kind for
> java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
> in abstractInterpreter.cpp
>
> The fix is to generate stub entries for
> java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8170767
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/webrev.01/
>
> Thanks,
> Severin


From david.holmes at oracle.com  Thu Dec  8 07:25:58 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 8 Dec 2016 17:25:58 +1000
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
	<9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
Message-ID: <0e1d5633-755f-338e-9390-f86f1dc1b4ae@oracle.com>

On 8/12/2016 9:32 AM, Vladimir Kozlov wrote:
> jdk.vm.compiler is only one jigsaw module.
>
> It is the project based layout (each directory is separate Java IDE
> project) :

Why does each directory need to be a separate IDE project? This naming 
looks awful to me.

David

> Tom Rodriguez wrote:
>> Having the file structure follow the project structure is kind of the
> only sane way to organize it. It's really to be Java IDE friendly.
>
> Thanks,
> Vladimir
>
> On 12/7/16 3:16 PM, Coleen Phillimore wrote:
>>
>> Hi,
>>
>> Out of curiosity, why do you have this redundancy in the paths of new
>> code files?  Is this because of modules?
>>
>> *src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test
>>
>>
>> *
>> Thanks,
>> Coleen
>>
>> On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>
>>> It is part of JEP 295: Ahead-of-Time Compilation
>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>
>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>
>>> This is formal review request for integration Graal-core sources into
>>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>>> integrated Graal-core sources into JDK and add build changes to build
>>> Graal module.
>>>
>>> Note, changes are based on latest jdk9/hs sources which do not have
>>> latest jigsaw update yet. With jigsaw update small changes will be
>>> done to module-info.java.extra in java.base:
>>>
>>>   exports jdk.internal.misc to jdk.vm.compiler;
>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>
>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>
>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>
>>>
>>>
>>> Graal is a dynamic compiler written in Java that integrates with the
>>> HotSpot JVM. It has a focus on high performance and extensibility. In
>>> addition, it provides optimized performance for Truffle based
>>> languages running on the JVM.
>>>
>>> https://github.com/graalvm/graal-core
>>>
>>> Oracle Labs is developing and maintaining it.
>>>
>>> Here are people who contributed into Graal development (sorry if
>>> someone is missing or misspelled, please speak):
>>>
>>> ~70k LOC: Douglas Simon
>>> ~60k LOC: Lukas Stadler
>>> ~30k LOC: Thomas Wuerthinger
>>> ~30k LOC: Tom Rodriguez
>>> ~30k LOC: Roland Schatz
>>> ~30k LOC: Josef Eisl
>>> ~30k LOC: Christian Wimmer
>>> ~16k LOC: Chris Thalinger
>>> ~13k LOC: Gilles Duboscq
>>> ~11k LOC: David Leopoldseder
>>> ~ 8k LOC: Stefan Anzinger
>>> ~ 8k LOC: Christian Humer
>>>
>>> Other contributors >100 LOC in approximate order of contribution size:
>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>>
>>>
>>> Thanks,
>>> Vladimir
>>

From david.holmes at oracle.com  Thu Dec  8 07:44:24 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 8 Dec 2016 17:44:24 +1000
Subject: Java heap size defaults when running with CGroups in Linux.
In-Reply-To: <3bf1cdf8-a2f4-ba32-ea79-7815e9abd20a@oracle.com>
References: <321822099.1218801.1480543196266.JavaMail.zimbra@redhat.com>
	<D8C99DDD-61EB-41EF-9C3C-E24665659D1A@oracle.com>
	<724185737.1372541.1480603805989.JavaMail.zimbra@redhat.com>
	<3bf1cdf8-a2f4-ba32-ea79-7815e9abd20a@oracle.com>
Message-ID: <349e845e-211c-74d4-a9ec-134b9047df37@oracle.com>

I have filed:

https://bugs.openjdk.java.net/browse/JDK-8170888

"[linux] Experimental support for cgroup memory limits in container (ie 
Docker) environments"

to try and get this into 9. Will try to test tomorrow and send out RFR, 
while we await approval (or not).

Proposed flag name is now: UseCGroupMemoryLimitForHeap

Thanks,
David

On 2/12/2016 11:57 AM, David Holmes wrote:
> On 2/12/2016 12:50 AM, Christine Flood wrote:
>> Unfortunately, if you aren't actually inside a cgroup,
>> /sys/fs/cgroup/memory/memory.limit_in_bytes still exists and contains
>> an apparently bogus value.  I've got a question in to the docker folks
>> to find out why.
>
> Is that the "unlimited" value that you get even if running in a cgroup
> but without setting a memory limit?
>
> As I wrote in the bug report when initially investigating this there
> seem to be a lot of issues with even knowing what to read:
>
> "/sys/fs/cgroup/ is the recommended location for cgroup hierarchies, but
> it is not a standard. If a tool or library is trying to read from it,
> and be portable across multiple container implementations, it would need
> to discover the location first by parsing /proc/self/cgroup and
> /proc/self/mountinfo. Further, /sys/fs/cgroup is just an umbrella for
> all cgroup hierarchies, there is no recommendation or standard for my
> own cgroup location."
>
> https://fabiokung.com/2014/03/13/memory-inside-linux-containers/
>
>> In the short term, providing a runtime flag gives us a way to protect
>> customers that are running inside a container and not change the
>> current behavior for everyone else.
>
> Ok - at best this enhancement would be an experimental flag that users
> would have to opt in to.
>
> But the enhancement door is barely still open for JDK 9.
>
> David
> -----
>
>> Christine
>>
>> ----- Original Message -----
>>> From: "Mikael Vidstedt" <mikael.vidstedt at oracle.com>
>>> To: "Christine Flood" <chf at redhat.com>
>>> Cc: hotspot-dev at openjdk.java.net
>>> Sent: Wednesday, November 30, 2016 5:53:41 PM
>>> Subject: Re: Java heap size defaults when running with CGroups in Linux.
>>>
>>>
>>> Out of curiosity, why wouldn?t this be the default behavior? That is, in
>>> which cases is it not a good idea to use the cgroup information when
>>> sizing
>>> the JVM?
>>>
>>> Cheers,
>>> Mikael
>>>
>>>
>>>> On Nov 30, 2016, at 1:59 PM, Christine Flood <chf at redhat.com> wrote:
>>>>
>>>>
>>>> The problem is that when running the JVM inside of a cgroup, such as
>>>> docker, the JVM bases it's default heap parameters on the size of the
>>>> whole machine's memory not on the memory available to the
>>>> container.  This
>>>> causes errors as discussed on this blog entry.
>>>> http://matthewkwilliams.com/index.php/2016/03/17/docker-cgroups-memory-constraints-and-java-cautionary-tale/
>>>>
>>>>
>>>> Basically the JVM dies in a non-obvious manner.
>>>>
>>>> The solution I propose is to add a parameter -XX:+UseCGroupLimits to
>>>> the
>>>> JVM which states that you should look to the CGroup when calculating
>>>> default heap sizes.
>>>>
>>>> Webrev is here:
>>>> http://cr.openjdk.java.net/~andrew/rh1390708/webrev.01/
>>>>
>>>>
>>>> Christine
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>

From doug.simon at oracle.com  Thu Dec  8 09:04:51 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 8 Dec 2016 10:04:51 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <0e1d5633-755f-338e-9390-f86f1dc1b4ae@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
	<9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
	<0e1d5633-755f-338e-9390-f86f1dc1b4ae@oracle.com>
Message-ID: <A4CF3BFF-E902-4E85-83E5-7667F5E73FEF@oracle.com>


> On 8 Dec 2016, at 08:25, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 8/12/2016 9:32 AM, Vladimir Kozlov wrote:
>> jdk.vm.compiler is only one jigsaw module.
>> 
>> It is the project based layout (each directory is separate Java IDE
>> project) :
> 
> Why does each directory need to be a separate IDE project? This naming looks awful to me.

We?ve gone through this same discussion with JVMCI.

We?ve organized the Graal (and JVMCI) source code into fine grained units of logic, each of which is a separate IDE project. The granularity of Graal modules allows downstream clients (e.g., AOT, SubstrateVM) to depend on some pieces of Graal without depending on the whole thing. Ideally, we?d like to represent each project/directory in the Graal sources as a separate JDK module but have been informed that would be too many modules. Maybe in the JDK10 timeframe we can start to refactor the Graal projects to be JDK modules. In that process, we may compromise on the granularity if there are good reasons to do so.

-Doug

> 
>> Tom Rodriguez wrote:
>>> Having the file structure follow the project structure is kind of the
>> only sane way to organize it. It's really to be Java IDE friendly.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 12/7/16 3:16 PM, Coleen Phillimore wrote:
>>> 
>>> Hi,
>>> 
>>> Out of curiosity, why do you have this redundancy in the paths of new
>>> code files?  Is this because of modules?
>>> 
>>> *src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test
>>> 
>>> 
>>> *
>>> Thanks,
>>> Coleen
>>> 
>>> On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>> 
>>>> It is part of JEP 295: Ahead-of-Time Compilation
>>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>> 
>>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>> 
>>>> This is formal review request for integration Graal-core sources into
>>>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>>>> integrated Graal-core sources into JDK and add build changes to build
>>>> Graal module.
>>>> 
>>>> Note, changes are based on latest jdk9/hs sources which do not have
>>>> latest jigsaw update yet. With jigsaw update small changes will be
>>>> done to module-info.java.extra in java.base:
>>>> 
>>>>  exports jdk.internal.misc to jdk.vm.compiler;
>>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>> 
>>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>> 
>>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>> 
>>>> 
>>>> 
>>>> Graal is a dynamic compiler written in Java that integrates with the
>>>> HotSpot JVM. It has a focus on high performance and extensibility. In
>>>> addition, it provides optimized performance for Truffle based
>>>> languages running on the JVM.
>>>> 
>>>> https://github.com/graalvm/graal-core
>>>> 
>>>> Oracle Labs is developing and maintaining it.
>>>> 
>>>> Here are people who contributed into Graal development (sorry if
>>>> someone is missing or misspelled, please speak):
>>>> 
>>>> ~70k LOC: Douglas Simon
>>>> ~60k LOC: Lukas Stadler
>>>> ~30k LOC: Thomas Wuerthinger
>>>> ~30k LOC: Tom Rodriguez
>>>> ~30k LOC: Roland Schatz
>>>> ~30k LOC: Josef Eisl
>>>> ~30k LOC: Christian Wimmer
>>>> ~16k LOC: Chris Thalinger
>>>> ~13k LOC: Gilles Duboscq
>>>> ~11k LOC: David Leopoldseder
>>>> ~ 8k LOC: Stefan Anzinger
>>>> ~ 8k LOC: Christian Humer
>>>> 
>>>> Other contributors >100 LOC in approximate order of contribution size:
>>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>>>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>>>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>>> 
>>>> 
>>>> Thanks,
>>>> Vladimir
>>> 


From martin.doerr at sap.com  Thu Dec  8 09:39:57 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 8 Dec 2016 09:39:57 +0000
Subject: PPC64: JVM crash on Hadoop + Terasort
In-Reply-To: <58488B35.7040307@linux.vnet.ibm.com>
References: <584889CB.7080004@linux.vnet.ibm.com>
	<58488B35.7040307@linux.vnet.ibm.com>
Message-ID: <26a1bafc59f347938201d168a12600d0@dewdfe13de06.global.corp.sap>

Hi Gustavo,

seems to be the bug which was recently fixed in 9 but not downported to 8:
8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries

Best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero
Sent: Mittwoch, 7. Dezember 2016 23:21
To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
Subject: Re: PPC64: JVM crash on Hadoop + Terasort

Also - I forgot to mention - the problem seems to disappear if OpenJDK 8 tag
65-b17 is used instead.

On 07-12-2016 20:14, Gustavo Romero wrote:
> Hi,
> 
> We are experiencing some JVM crashes on 8 when trying to load a large 
> Terasort data set (1 TiB) into Hadoop on PPC64.
> 
> Please refer to the following hs_err log:
> http://paste.fedoraproject.org/501254/48114364/raw/
> 
> The crash seems to be due to an indexed doubleword store in
> libjvm.so:
> 
> 0x85aeb4:	2a 49 e8 7e 	stdx    r23,r8,r9
> 
> that by its turn is generated from
> 
> <CardTableModRefBS::process_stride(Space*, MemRegion, int, int, OopsInGenClosure*, CardTableRS*, signed char**, unsigned long, unsigned long)+468>:	stdx    r23,r8,r9
> 
> present in Parallel GC code 
> hotspot/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
> 
> 259	  } else {
> 260	    // In this case we can help our neighbour by just asking them
> 261	    // to stop at our first card (even though it may not be dirty).
> 262	    NOISY(tty->print_cr(" LNC: first block is not a non-array object; setting LNC to first card of current chunk");)
> 263	    assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter");
> 264	    jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start());
> 265	    lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk;
> 266	  }
> 
> 0x85aeb4: 2a 49 e8 7e stdx r23,r8,r9 is generated from parCardTableModRefBS.cpp:265 more precisely.
> 
> I'm not able to reproduce that yet on 9 and create a test case but I 
> would like to ask if someone know some issue potentially related to 
> that one and already reported to the JBS. I could not find any recent ones.
> 
> Also, what could be a good code or JVM configuration to exercise 
> intensively that code, i.e. the else branch parCardTableModRefBS.cpp:259-265.
> 
> Thank you very much.
> 
> 
> Regards,
> Gustavo
> 


From erik.joelsson at oracle.com  Thu Dec  8 10:12:41 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Dec 2016 11:12:41 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
Message-ID: <b3634e49-231a-a6c1-3c05-b8a6d06a3973@oracle.com>

Hello,

The file hotspot/make/Tools.gmk is dead code at this point and should be 
removed. Also stop including it from Gensrc-jdk.vm.compiler.gmk.

Otherwise it looks ok to me.

/Erik

On 2016-12-07 23:10, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8166417
>
> It is part of JEP 295: Ahead-of-Time Compilation
> https://bugs.openjdk.java.net/browse/JDK-8166089
>
> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>
> This is formal review request for integration Graal-core sources into 
> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to 
> integrated Graal-core sources into JDK and add build changes to build 
> Graal module.
>
> Note, changes are based on latest jdk9/hs sources which do not have 
> latest jigsaw update yet. With jigsaw update small changes will be 
> done to module-info.java.extra in java.base:
>
>   exports jdk.internal.misc to jdk.vm.compiler;
> + opens jdk.internal.misc to jdk.vm.compiler;
>
> - exports com.sun.crypto.provider to jdk.vm.compiler;
> + opens com.sun.crypto.provider to jdk.vm.compiler;
>
> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>
>
>
> Graal is a dynamic compiler written in Java that integrates with the 
> HotSpot JVM. It has a focus on high performance and extensibility. In 
> addition, it provides optimized performance for Truffle based 
> languages running on the JVM.
>
> https://github.com/graalvm/graal-core
>
> Oracle Labs is developing and maintaining it.
>
> Here are people who contributed into Graal development (sorry if 
> someone is missing or misspelled, please speak):
>
> ~70k LOC: Douglas Simon
> ~60k LOC: Lukas Stadler
> ~30k LOC: Thomas Wuerthinger
> ~30k LOC: Tom Rodriguez
> ~30k LOC: Roland Schatz
> ~30k LOC: Josef Eisl
> ~30k LOC: Christian Wimmer
> ~16k LOC: Chris Thalinger
> ~13k LOC: Gilles Duboscq
> ~11k LOC: David Leopoldseder
> ~ 8k LOC: Stefan Anzinger
> ~ 8k LOC: Christian Humer
>
> Other contributors >100 LOC in approximate order of contribution size:
> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos 
> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, 
> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef 
> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, 
> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>
>
> Thanks,
> Vladimir


From magnus.ihse.bursie at oracle.com  Thu Dec  8 10:32:28 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 8 Dec 2016 11:32:28 +0100
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
	<58421A35.5070706@oracle.com>
	<35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
	<84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
	<530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
Message-ID: <78f05033-1d85-61a6-8401-40fffaeb2baa@oracle.com>

On 2016-12-07 19:51, Bob Vandette wrote:
> Thanks Magnus,  see comments below ..
Your fixes look good. I'm ok with the build part of the patch now.

/Magnus
>
>> On Dec 7, 2016, at 3:44 AM, Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com 
>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>
>> On 2016-12-05 16:23, Bob Vandette wrote:
>>>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov<vladimir.kozlov at oracle.com>  wrote:
>>>>
>>>> hi Bob,
>>>>
>>>> I would suggest to have separate webrevs for different repositories because different groups should look on them.
>>> There are only 3 non hotspot files and they are on top.  Forwarding to build-dev for their review.
>>
>> Build changes mostly look good. A few comments:
>>
>> * We try to use the autoconf defined "$with_opt" variables only when 
>> checking and verifying arguments. In hotspot.m4, please let 
>> SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. 
>> OPENJDK_TARGET_CPU_PORT, and use that to do the check in 
>> HOTSPOT_SETUP_JVM_FEATURES.
>
> I think it should be called HOTSPOT_TARGET_CPU_PORT since this 
> variable only impact which directory hotspot uses for it build.
> I also removed a redundant if test "x$with_cpu_port" != x; in 
> SETUP_HOTSPOT_TARGET_CPU_PORT.
>
> +  # Override hotspot cpu definitions for ARM platforms
> +  if test "x$OPENJDK_TARGET_CPU" = xarm; then
> +    HOTSPOT_TARGET_CPU=arm_32
> +    HOTSPOT_TARGET_CPU_DEFINE="ARM32"
> +    JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char"
> +    JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char"
> +  elif test "x$OPENJDK_TARGET_CPU" = xaarch64 && test 
> *"x$HOTSPOT_TARGET_CPU_PORT"* = xarm64; then
> +    HOTSPOT_TARGET_CPU=arm_64
> +    HOTSPOT_TARGET_CPU_ARCH=arm
> +    JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char"
> +    JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char"
> +  fi
> +
>
> +AC_DEFUN([SETUP_HOTSPOT_TARGET_CPU_PORT],
> +[
> +  AC_ARG_WITH(cpu-port, [AS_HELP_STRING([--with-cpu-port],
> +      [specify sources to use for Hotspot 64-bit ARM port 
> (arm64,aarch64) @<:@aarch64@:>@ ])])
> +
> +  if test "x$with_cpu_port" != x; then
> +    if test "x$OPENJDK_TARGET_CPU" != xaarch64; then
> +      AC_MSG_ERROR([--with-cpu-port only available on aarch64])
> +    fi
> +    if test "x$with_cpu_port" != xarm64 && \
> +        test "x$with_cpu_port" != xaarch64; then
> +      AC_MSG_ERROR([--with-cpu-port must specify arm64 or aarch64])
> +    fi
> *+    HOTSPOT_TARGET_CPU_PORT = $with_cpu_port*
> +  fi
> +])
> +
> +
>
>>
>> * In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks 
>> OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU 
>> instead, since explicitly checking the CPU_ARCH variable seems to 
>> indicate that we want to test more than a single CPU, but for arm 
>> there is only one. (At first, I thought this was a test for "arm64" 
>> as well. If this was the intention, then the code is broken.)
>>
> Ok.
>
>> * In CompileJvm.gmk, you might want to rephrase the comment, since 
>> from now on both the original aarch64 and the new arm64 port are 
>> "open". What the code does is in fact to select between the two 
>> different aarch64 ports.
>
> Done.  I also found another comment that needed to be updated.
>
> diff --git a/make/lib/CompileJvm.gmk b/make/lib/CompileJvm.gmk
> --- a/make/lib/CompileJvm.gmk
> +++ b/make/lib/CompileJvm.gmk
> @@ -63,8 +63,8 @@
>  # INCLUDE_SUFFIX_* is only meant for including the proper
>  # platform files. Don't use it to guard code. Use the value of
>  # HOTSPOT_TARGET_CPU_DEFINE etc. instead.
> -# Remaining TARGET_ARCH_* is needed to distinguish closed and open
> -# 64-bit ARM ports (also called AARCH64).
> +# Remaining TARGET_ARCH_* is needed to select the cpu specific
> +# sources for 64-bit ARM ports (arm versus aarch64).
>  JVM_CFLAGS_TARGET_DEFINES += \
>      -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) \
>      -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \
> @@ -139,6 +139,20 @@
>  ################################################################################
>  # Platform specific setup
>
>
> +# ARM source selection
> +
> +ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-arm)
> +  JVM_EXCLUDE_PATTERNS += arm_64
> +
> +else ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-aarch64)
> +  # For 64-bit arm builds, we use the 64 bit hotspot/src/cpu/arm
> +  # hotspot sources if HOTSPOT_TARGET_CPU_ARCH is set to arm.
> +  # Exclude the aarch64 and 32 bit arm files for this build.
> +  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), arm)
> +    JVM_EXCLUDE_PATTERNS += arm_32 aarch64
> +  endif
> +endif
> +
>
> Bob.
>
>
>>
>> /Magnus
>>
>>
>>>> For example, top repository and makefiles changes should be also reviewed onbuild-dev at openjdk.java.net
>>>>
>>>> Why do you need cahnges in SA libproc.h?
>>> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs.
>>>
>>> I just looked again and there is a definition of struct user_regs in user.h.  I might be able to change the code to:
>>>
>>> #if defined(arm) || defined(arm64)
>>> #define user_regs_struct user_regs
>>> #endif
>>>
>>> This change would result  in the exact same declaration based on the number of registers
>>> derived from the structure in user.h.
>>>
>>> Bob.
>>>
>>>
>>>> I saw Hotspot changes before and I think they are fine (did not dive deep).
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 12/2/16 12:28 PM, Bob Vandette wrote:
>>>>> Please review the proposed changes to be integrated under JEP 297.
>>>>>
>>>>> Summary:
>>>>>
>>>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.
>>>>>
>>>>> This changeset also removes the support for the pregenerated interpreter since
>>>>> this is no longer supported.
>>>>>
>>>>> The addition of arm64 does not replace the existing aarch64 port.  A new configure
>>>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the
>>>>> 64-bit arm64 support being added via this JEP.  Please refer to the JEP for more details.
>>>>>
>>>>> JEP 297:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8168503
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~bobv/8168503
>>>>>
>>>>>
>>>>> Note:
>>>>>
>>>>> A complete build-able forest containing these changes is located here:http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264
>>>>>
>>>>> Thanks,
>>>>> Bob Vandette
>>>>>
>>
>


From sgehwolf at redhat.com  Thu Dec  8 11:36:42 2016
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 08 Dec 2016 12:36:42 +0100
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
References: <1481115437.3024.9.camel@redhat.com>
	<54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
Message-ID: <1481197002.4114.14.camel@redhat.com>

On Wed, 2016-12-07 at 22:58 -0500, Coleen Phillimore wrote:
> This looks good and I can sponsor this for you.??I haven't built Zero in?
> a while.

Thanks for the review Coleen! It still doesn't build (for me) after
this fix, but that's a separate issue.

The exported changeset is here:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/JDK-8170767.export.patch

Cheers,
Severin

> Thanks,
> Coleen
> 
> On 12/7/16 7:57 AM, Severin Gehwolf wrote:
> > 
> > Hi,
> > 
> > Could somebody please review this Zero only change? The problem was
> > there before, but only the fix for JDK-8169711 brought it to the
> > surface. The returned method kind for
> > java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
> > in abstractInterpreter.cpp
> > 
> > The fix is to generate stub entries for
> > java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?
> > 
> > bug: https://bugs.openjdk.java.net/browse/JDK-8170767
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/webrev.01/
> > 
> > Thanks,
> > Severin
> 


From magnus.ihse.bursie at oracle.com  Thu Dec  8 12:50:38 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 8 Dec 2016 13:50:38 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
Message-ID: <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com>

On 2016-12-07 23:10, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8166417
>
> It is part of JEP 295: Ahead-of-Time Compilation
> https://bugs.openjdk.java.net/browse/JDK-8166089
>
> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/

* In CompileJavaModules.gmk, there is an *extreme* list of excludes. I 
note that most of them end in ".test". The proper solution to this is to 
move the test code to the test/ directory instead of the src/ directory. 
Also, four of them are the javac processor build tools. These should 
move to make/src, as other build tools.

* In hotspot.m4: AC_MSG_CHECKING must always be matched by a 
AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will be 
garbled.

* In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is 
incorrect. It only tests for the default value, not for the explicitely 
set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)).

* The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), 
true)" will never evaluate to true). But on the other hand, it is not 
needed, and should just be removed. :-)

* The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems 
a bit dangling. Is this supposed to be included in some Javadoc 
generation? The html file refers to a projects.jpg and projects.html 
that does not exist. Maybe it should just be removed?

* Finally, just for the record, I too think the source should be 
structured according to the OpenJDK praxis. (But I won't fight about this.)

/Magnus
>
> This is formal review request for integration Graal-core sources into 
> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to 
> integrated Graal-core sources into JDK and add build changes to build 
> Graal module.
>
> Note, changes are based on latest jdk9/hs sources which do not have 
> latest jigsaw update yet. With jigsaw update small changes will be 
> done to module-info.java.extra in java.base:
>
>   exports jdk.internal.misc to jdk.vm.compiler;
> + opens jdk.internal.misc to jdk.vm.compiler;
>
> - exports com.sun.crypto.provider to jdk.vm.compiler;
> + opens com.sun.crypto.provider to jdk.vm.compiler;
>
> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>
>
>
> Graal is a dynamic compiler written in Java that integrates with the 
> HotSpot JVM. It has a focus on high performance and extensibility. In 
> addition, it provides optimized performance for Truffle based 
> languages running on the JVM.
>
> https://github.com/graalvm/graal-core
>
> Oracle Labs is developing and maintaining it.
>
> Here are people who contributed into Graal development (sorry if 
> someone is missing or misspelled, please speak):
>
> ~70k LOC: Douglas Simon
> ~60k LOC: Lukas Stadler
> ~30k LOC: Thomas Wuerthinger
> ~30k LOC: Tom Rodriguez
> ~30k LOC: Roland Schatz
> ~30k LOC: Josef Eisl
> ~30k LOC: Christian Wimmer
> ~16k LOC: Chris Thalinger
> ~13k LOC: Gilles Duboscq
> ~11k LOC: David Leopoldseder
> ~ 8k LOC: Stefan Anzinger
> ~ 8k LOC: Christian Humer
>
> Other contributors >100 LOC in approximate order of contribution size:
> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos 
> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, 
> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef 
> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, 
> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>
>
> Thanks,
> Vladimir


From doug.simon at oracle.com  Thu Dec  8 13:08:01 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 8 Dec 2016 14:08:01 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com>
Message-ID: <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com>


> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2016-12-07 23:10, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8166417
>> 
>> It is part of JEP 295: Ahead-of-Time Compilation
>> https://bugs.openjdk.java.net/browse/JDK-8166089
>> 
>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
> 
> * In CompileJavaModules.gmk, there is an *extreme* list of excludes. I note that most of them end in ".test". The proper solution to this is to move the test code to the test/ directory instead of the src/ directory. Also, four of them are the javac processor build tools. These should move to make/src, as other build tools.

Keeping like it is simplifies pulling changes from https://github.com/graalvm/graal-core. It's possible to write a more sophisticated tool for pulling changes in from the github and places the sources into more openjdk compatible locations. It's up to the HotSpot compiler team whether investing in such a tool makes sense.

> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will be garbled.
> 
> * In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is incorrect. It only tests for the default value, not for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)).
> 
> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), true)" will never evaluate to true). But on the other hand, it is not needed, and should just be removed. :-)
> 
> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems a bit dangling. Is this supposed to be included in some Javadoc generation? The html file refers to a projects.jpg and projects.html that does not exist. Maybe it should just be removed?

I would recommend omitting all graal-core overview.html files in OpenJDK.

> * Finally, just for the record, I too think the source should be structured according to the OpenJDK praxis. (But I won't fight about this.)

-Doug

>> 
>> This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module.
>> 
>> Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base:
>> 
>>  exports jdk.internal.misc to jdk.vm.compiler;
>> + opens jdk.internal.misc to jdk.vm.compiler;
>> 
>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>> 
>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>> 
>> 
>> 
>> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM.
>> 
>> https://github.com/graalvm/graal-core
>> 
>> Oracle Labs is developing and maintaining it.
>> 
>> Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak):
>> 
>> ~70k LOC: Douglas Simon
>> ~60k LOC: Lukas Stadler
>> ~30k LOC: Thomas Wuerthinger
>> ~30k LOC: Tom Rodriguez
>> ~30k LOC: Roland Schatz
>> ~30k LOC: Josef Eisl
>> ~30k LOC: Christian Wimmer
>> ~16k LOC: Chris Thalinger
>> ~13k LOC: Gilles Duboscq
>> ~11k LOC: David Leopoldseder
>> ~ 8k LOC: Stefan Anzinger
>> ~ 8k LOC: Christian Humer
>> 
>> Other contributors >100 LOC in approximate order of contribution size:
>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>> 
>> 
>> Thanks,
>> Vladimir
> 


From kirill.zhaldybin at oracle.com  Thu Dec  8 13:32:48 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Thu, 8 Dec 2016 16:32:48 +0300
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
Message-ID: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>

Dear all,

Could you please review this fix for 8170919?

Since the tests use Resource Mark they should be run with TEST_VM not TEST.

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

Thank you.

Regards, Kirill

From gromero at linux.vnet.ibm.com  Thu Dec  8 13:49:23 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 8 Dec 2016 11:49:23 -0200
Subject: PPC64: JVM crash on Hadoop + Terasort
In-Reply-To: <26a1bafc59f347938201d168a12600d0@dewdfe13de06.global.corp.sap>
References: <584889CB.7080004@linux.vnet.ibm.com>
	<58488B35.7040307@linux.vnet.ibm.com>
	<26a1bafc59f347938201d168a12600d0@dewdfe13de06.global.corp.sap>
Message-ID: <584964E3.8050807@linux.vnet.ibm.com>

Hi Martin,

ah! Yup, it really seems to be the same problem, a memory ordering issue... very interesting!

I backported to 8 and I'll do some additional tests on Hadoop + Terasort and let
you know about the results:

http://cr.openjdk.java.net/~gromero/8170409/

Does SAP plan to backport to 8u?

Thank you very much!


Best regards,
Gustavo

On 08-12-2016 07:39, Doerr, Martin wrote:
> Hi Gustavo,
> 
> seems to be the bug which was recently fixed in 9 but not downported to 8:
> 8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries
> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero
> Sent: Mittwoch, 7. Dezember 2016 23:21
> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> Subject: Re: PPC64: JVM crash on Hadoop + Terasort
> 
> Also - I forgot to mention - the problem seems to disappear if OpenJDK 8 tag
> 65-b17 is used instead.
> 
> On 07-12-2016 20:14, Gustavo Romero wrote:
>> Hi,
>>
>> We are experiencing some JVM crashes on 8 when trying to load a large 
>> Terasort data set (1 TiB) into Hadoop on PPC64.
>>
>> Please refer to the following hs_err log:
>> http://paste.fedoraproject.org/501254/48114364/raw/
>>
>> The crash seems to be due to an indexed doubleword store in
>> libjvm.so:
>>
>> 0x85aeb4:	2a 49 e8 7e 	stdx    r23,r8,r9
>>
>> that by its turn is generated from
>>
>> <CardTableModRefBS::process_stride(Space*, MemRegion, int, int, OopsInGenClosure*, CardTableRS*, signed char**, unsigned long, unsigned long)+468>:	stdx    r23,r8,r9
>>
>> present in Parallel GC code 
>> hotspot/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
>>
>> 259	  } else {
>> 260	    // In this case we can help our neighbour by just asking them
>> 261	    // to stop at our first card (even though it may not be dirty).
>> 262	    NOISY(tty->print_cr(" LNC: first block is not a non-array object; setting LNC to first card of current chunk");)
>> 263	    assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter");
>> 264	    jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start());
>> 265	    lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk;
>> 266	  }
>>
>> 0x85aeb4: 2a 49 e8 7e stdx r23,r8,r9 is generated from parCardTableModRefBS.cpp:265 more precisely.
>>
>> I'm not able to reproduce that yet on 9 and create a test case but I 
>> would like to ask if someone know some issue potentially related to 
>> that one and already reported to the JBS. I could not find any recent ones.
>>
>> Also, what could be a good code or JVM configuration to exercise 
>> intensively that code, i.e. the else branch parCardTableModRefBS.cpp:259-265.
>>
>> Thank you very much.
>>
>>
>> Regards,
>> Gustavo
>>
> 


From jesper.wilhelmsson at oracle.com  Thu Dec  8 14:03:01 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 8 Dec 2016 15:03:01 +0100
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
Message-ID: <bd7b59ec-dc11-62dd-9e0e-705b5f685dc9@oracle.com>

Looks good!
/Jesper

Den 8/12/16 kl. 14:32, skrev Kirill Zhaldybin:
> Dear all,
>
> Could you please review this fix for 8170919?
>
> Since the tests use Resource Mark they should be run with TEST_VM not TEST.
>
> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>
> Thank you.
>
> Regards, Kirill

From marcus.larsson at oracle.com  Thu Dec  8 14:08:53 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 8 Dec 2016 15:08:53 +0100
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
Message-ID: <2e8e47b9-4923-ff5c-ab50-1d7a3761cf8b@oracle.com>

Hi,


On 2016-12-08 14:32, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please review this fix for 8170919?
>
> Since the tests use Resource Mark they should be run with TEST_VM not 
> TEST.
>
> WebRev: 
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/webrev.00/

Looks good.

Marcus

> CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>
> Thank you.
>
> Regards, Kirill


From kirill.zhaldybin at oracle.com  Thu Dec  8 14:40:22 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Thu, 8 Dec 2016 17:40:22 +0300
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <bd7b59ec-dc11-62dd-9e0e-705b5f685dc9@oracle.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
	<bd7b59ec-dc11-62dd-9e0e-705b5f685dc9@oracle.com>
Message-ID: <b74d3135-d2cb-c10f-5397-ee6c33482f37@oracle.com>

Jesper,

Thank you for review!

Regards, Kirill

On 08.12.2016 17:03, Jesper Wilhelmsson wrote:
> Looks good!
> /Jesper
>
> Den 8/12/16 kl. 14:32, skrev Kirill Zhaldybin:
>> Dear all,
>>
>> Could you please review this fix for 8170919?
>>
>> Since the tests use Resource Mark they should be run with TEST_VM not 
>> TEST.
>>
>> WebRev: 
>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/webrev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>>
>> Thank you.
>>
>> Regards, Kirill


From kirill.zhaldybin at oracle.com  Thu Dec  8 14:41:03 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Thu, 8 Dec 2016 17:41:03 +0300
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <2e8e47b9-4923-ff5c-ab50-1d7a3761cf8b@oracle.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
	<2e8e47b9-4923-ff5c-ab50-1d7a3761cf8b@oracle.com>
Message-ID: <ff2a0b56-0650-96e7-0fae-6ad04f0b0602@oracle.com>

Marcus,

Thank you for review!

Regards, Kirill

On 08.12.2016 17:08, Marcus Larsson wrote:
> Hi,
>
>
> On 2016-12-08 14:32, Kirill Zhaldybin wrote:
>> Dear all,
>>
>> Could you please review this fix for 8170919?
>>
>> Since the tests use Resource Mark they should be run with TEST_VM not 
>> TEST.
>>
>> WebRev: 
>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/webrev.00/
>
> Looks good.
>
> Marcus
>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>>
>> Thank you.
>>
>> Regards, Kirill
>


From volker.simonis at gmail.com  Thu Dec  8 14:48:30 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 8 Dec 2016 15:48:30 +0100
Subject: PPC64: JVM crash on Hadoop + Terasort
In-Reply-To: <584964E3.8050807@linux.vnet.ibm.com>
References: <584889CB.7080004@linux.vnet.ibm.com>
	<58488B35.7040307@linux.vnet.ibm.com>
	<26a1bafc59f347938201d168a12600d0@dewdfe13de06.global.corp.sap>
	<584964E3.8050807@linux.vnet.ibm.com>
Message-ID: <CA+3eh11fC4GGOb9GWWZa_DsQJBHZD=Z5kQpSR28+B2J=zHtRcA@mail.gmail.com>

Hi Gustavo,

I can do the downport.

It would be good tough if you could confirm that the fix solves your
Hadoop/Terasort problem.

Regards,
Volker


On Thu, Dec 8, 2016 at 2:49 PM, Gustavo Romero
<gromero at linux.vnet.ibm.com> wrote:
> Hi Martin,
>
> ah! Yup, it really seems to be the same problem, a memory ordering issue... very interesting!
>
> I backported to 8 and I'll do some additional tests on Hadoop + Terasort and let
> you know about the results:
>
> http://cr.openjdk.java.net/~gromero/8170409/
>
> Does SAP plan to backport to 8u?
>
> Thank you very much!
>
>
> Best regards,
> Gustavo
>
> On 08-12-2016 07:39, Doerr, Martin wrote:
>> Hi Gustavo,
>>
>> seems to be the bug which was recently fixed in 9 but not downported to 8:
>> 8170409: CMS: Crash in CardTableModRefBSForCTRS::process_chunk_boundaries
>>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Romero
>> Sent: Mittwoch, 7. Dezember 2016 23:21
>> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
>> Subject: Re: PPC64: JVM crash on Hadoop + Terasort
>>
>> Also - I forgot to mention - the problem seems to disappear if OpenJDK 8 tag
>> 65-b17 is used instead.
>>
>> On 07-12-2016 20:14, Gustavo Romero wrote:
>>> Hi,
>>>
>>> We are experiencing some JVM crashes on 8 when trying to load a large
>>> Terasort data set (1 TiB) into Hadoop on PPC64.
>>>
>>> Please refer to the following hs_err log:
>>> http://paste.fedoraproject.org/501254/48114364/raw/
>>>
>>> The crash seems to be due to an indexed doubleword store in
>>> libjvm.so:
>>>
>>> 0x85aeb4:    2a 49 e8 7e     stdx    r23,r8,r9
>>>
>>> that by its turn is generated from
>>>
>>> <CardTableModRefBS::process_stride(Space*, MemRegion, int, int, OopsInGenClosure*, CardTableRS*, signed char**, unsigned long, unsigned long)+468>:  stdx    r23,r8,r9
>>>
>>> present in Parallel GC code
>>> hotspot/src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
>>>
>>> 259    } else {
>>> 260      // In this case we can help our neighbour by just asking them
>>> 261      // to stop at our first card (even though it may not be dirty).
>>> 262      NOISY(tty->print_cr(" LNC: first block is not a non-array object; setting LNC to first card of current chunk");)
>>> 263      assert(lowest_non_clean[cur_chunk_index] == NULL, "Write once : value should be stable hereafter");
>>> 264      jbyte* first_card_of_cur_chunk = byte_for(chunk_mr.start());
>>> 265      lowest_non_clean[cur_chunk_index] = first_card_of_cur_chunk;
>>> 266    }
>>>
>>> 0x85aeb4: 2a 49 e8 7e stdx r23,r8,r9 is generated from parCardTableModRefBS.cpp:265 more precisely.
>>>
>>> I'm not able to reproduce that yet on 9 and create a test case but I
>>> would like to ask if someone know some issue potentially related to
>>> that one and already reported to the JBS. I could not find any recent ones.
>>>
>>> Also, what could be a good code or JVM configuration to exercise
>>> intensively that code, i.e. the else branch parCardTableModRefBS.cpp:259-265.
>>>
>>> Thank you very much.
>>>
>>>
>>> Regards,
>>> Gustavo
>>>
>>
>

From coleen.phillimore at oracle.com  Thu Dec  8 15:05:04 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 8 Dec 2016 10:05:04 -0500
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
	<9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
Message-ID: <ea1090ea-8d2b-5860-fa67-9d8d71dccf6f@oracle.com>



On 12/7/16 6:32 PM, Vladimir Kozlov wrote:
> jdk.vm.compiler is only one jigsaw module.
>
> It is the project based layout (each directory is separate Java IDE 
> project) :
>
> Tom Rodriguez wrote:
> > Having the file structure follow the project structure is kind of 
> the only sane way to organize it. It's really to be Java IDE friendly.

Which IDE are they using?  I assume you can't really work on this code 
without an IDE.  As long as nobody has to type these paths ... Are there 
project files in each of the leaf directories?

thanks,
Coleen
>
> Thanks,
> Vladimir
>
> On 12/7/16 3:16 PM, Coleen Phillimore wrote:
>>
>> Hi,
>>
>> Out of curiosity, why do you have this redundancy in the paths of new
>> code files?  Is this because of modules?
>>
>> *src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test 
>>
>>
>> *
>> Thanks,
>> Coleen
>>
>> On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>
>>> It is part of JEP 295: Ahead-of-Time Compilation
>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>
>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>
>>> This is formal review request for integration Graal-core sources into
>>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>>> integrated Graal-core sources into JDK and add build changes to build
>>> Graal module.
>>>
>>> Note, changes are based on latest jdk9/hs sources which do not have
>>> latest jigsaw update yet. With jigsaw update small changes will be
>>> done to module-info.java.extra in java.base:
>>>
>>>   exports jdk.internal.misc to jdk.vm.compiler;
>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>
>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>
>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>
>>>
>>>
>>> Graal is a dynamic compiler written in Java that integrates with the
>>> HotSpot JVM. It has a focus on high performance and extensibility. In
>>> addition, it provides optimized performance for Truffle based
>>> languages running on the JVM.
>>>
>>> https://github.com/graalvm/graal-core
>>>
>>> Oracle Labs is developing and maintaining it.
>>>
>>> Here are people who contributed into Graal development (sorry if
>>> someone is missing or misspelled, please speak):
>>>
>>> ~70k LOC: Douglas Simon
>>> ~60k LOC: Lukas Stadler
>>> ~30k LOC: Thomas Wuerthinger
>>> ~30k LOC: Tom Rodriguez
>>> ~30k LOC: Roland Schatz
>>> ~30k LOC: Josef Eisl
>>> ~30k LOC: Christian Wimmer
>>> ~16k LOC: Chris Thalinger
>>> ~13k LOC: Gilles Duboscq
>>> ~11k LOC: David Leopoldseder
>>> ~ 8k LOC: Stefan Anzinger
>>> ~ 8k LOC: Christian Humer
>>>
>>> Other contributors >100 LOC in approximate order of contribution size:
>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>>
>>>
>>> Thanks,
>>> Vladimir
>>


From thomas.stuefe at gmail.com  Thu Dec  8 15:09:51 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 8 Dec 2016 16:09:51 +0100
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <ff2a0b56-0650-96e7-0fae-6ad04f0b0602@oracle.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
	<2e8e47b9-4923-ff5c-ab50-1d7a3761cf8b@oracle.com>
	<ff2a0b56-0650-96e7-0fae-6ad04f0b0602@oracle.com>
Message-ID: <CAA-vtUw6HVi8-xN2PjY9-5BO3eTFvvQD2bvSXR6paO9k4JAy+g@mail.gmail.com>

Hi,

I wonder whether the test should use TEST_OTHER_VM?

If I understand the coding in LogTestFixture correctly, it changes the log
configuration and does not restore it to its original value but to a
default state. So, logging would not be possible for follow up tests in the
same VM.

So, test should either run in an own VM or LogTextFixture should snapshot
and restore the original log configuration.

Kind Regards, Thomas


On Thu, Dec 8, 2016 at 3:41 PM, Kirill Zhaldybin <
kirill.zhaldybin at oracle.com> wrote:

> Marcus,
>
> Thank you for review!
>
> Regards, Kirill
>
> On 08.12.2016 17:08, Marcus Larsson wrote:
>
>> Hi,
>>
>>
>> On 2016-12-08 14:32, Kirill Zhaldybin wrote:
>>
>>> Dear all,
>>>
>>> Could you please review this fix for 8170919?
>>>
>>> Since the tests use Resource Mark they should be run with TEST_VM not
>>> TEST.
>>>
>>> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/web
>>> rev.00/
>>>
>>
>> Looks good.
>>
>> Marcus
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>>>
>>> Thank you.
>>>
>>> Regards, Kirill
>>>
>>
>>
>

From doug.simon at oracle.com  Thu Dec  8 15:39:08 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 8 Dec 2016 16:39:08 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <ea1090ea-8d2b-5860-fa67-9d8d71dccf6f@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
	<9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
	<ea1090ea-8d2b-5860-fa67-9d8d71dccf6f@oracle.com>
Message-ID: <7D0CB45C-97E3-46B3-BB21-E6F4867A15DE@oracle.com>


> On 8 Dec 2016, at 16:05, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> 
> On 12/7/16 6:32 PM, Vladimir Kozlov wrote:
>> jdk.vm.compiler is only one jigsaw module.
>> 
>> It is the project based layout (each directory is separate Java IDE project) :
>> 
>> Tom Rodriguez wrote:
>> > Having the file structure follow the project structure is kind of the only sane way to organize it. It's really to be Java IDE friendly.
> 
> Which IDE are they using?

We are using Eclipse, NetBeans and Intellij.

>  I assume you can't really work on this code without an IDE.

Can one work on any code without an IDE? ;-)

>  As long as nobody has to type these paths ... Are there project files in each of the leaf directories?

The IDE configuration files are generated by mx (https://github.com/graalvm/graal-core/blob/master/README.md#ide-configuration).

-Doug

> 
> thanks,
> Coleen
>> 
>> Thanks,
>> Vladimir
>> 
>> On 12/7/16 3:16 PM, Coleen Phillimore wrote:
>>> 
>>> Hi,
>>> 
>>> Out of curiosity, why do you have this redundancy in the paths of new
>>> code files?  Is this because of modules?
>>> 
>>> *src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test 
>>> 
>>> *
>>> Thanks,
>>> Coleen
>>> 
>>> On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>> 
>>>> It is part of JEP 295: Ahead-of-Time Compilation
>>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>> 
>>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>> 
>>>> This is formal review request for integration Graal-core sources into
>>>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>>>> integrated Graal-core sources into JDK and add build changes to build
>>>> Graal module.
>>>> 
>>>> Note, changes are based on latest jdk9/hs sources which do not have
>>>> latest jigsaw update yet. With jigsaw update small changes will be
>>>> done to module-info.java.extra in java.base:
>>>> 
>>>>  exports jdk.internal.misc to jdk.vm.compiler;
>>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>> 
>>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>> 
>>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>> 
>>>> 
>>>> 
>>>> Graal is a dynamic compiler written in Java that integrates with the
>>>> HotSpot JVM. It has a focus on high performance and extensibility. In
>>>> addition, it provides optimized performance for Truffle based
>>>> languages running on the JVM.
>>>> 
>>>> https://github.com/graalvm/graal-core
>>>> 
>>>> Oracle Labs is developing and maintaining it.
>>>> 
>>>> Here are people who contributed into Graal development (sorry if
>>>> someone is missing or misspelled, please speak):
>>>> 
>>>> ~70k LOC: Douglas Simon
>>>> ~60k LOC: Lukas Stadler
>>>> ~30k LOC: Thomas Wuerthinger
>>>> ~30k LOC: Tom Rodriguez
>>>> ~30k LOC: Roland Schatz
>>>> ~30k LOC: Josef Eisl
>>>> ~30k LOC: Christian Wimmer
>>>> ~16k LOC: Chris Thalinger
>>>> ~13k LOC: Gilles Duboscq
>>>> ~11k LOC: David Leopoldseder
>>>> ~ 8k LOC: Stefan Anzinger
>>>> ~ 8k LOC: Christian Humer
>>>> 
>>>> Other contributors >100 LOC in approximate order of contribution size:
>>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>>>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>>>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>>> 
>>>> 
>>>> Thanks,
>>>> Vladimir
>>> 
> 


From gromero at linux.vnet.ibm.com  Thu Dec  8 15:40:18 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 8 Dec 2016 13:40:18 -0200
Subject: PPC64: JVM crash on Hadoop + Terasort
In-Reply-To: <CA+3eh11fC4GGOb9GWWZa_DsQJBHZD=Z5kQpSR28+B2J=zHtRcA@mail.gmail.com>
References: <584889CB.7080004@linux.vnet.ibm.com>
	<58488B35.7040307@linux.vnet.ibm.com>
	<26a1bafc59f347938201d168a12600d0@dewdfe13de06.global.corp.sap>
	<584964E3.8050807@linux.vnet.ibm.com>
	<CA+3eh11fC4GGOb9GWWZa_DsQJBHZD=Z5kQpSR28+B2J=zHtRcA@mail.gmail.com>
Message-ID: <58497EE2.1020702@linux.vnet.ibm.com>

Hi Volker,

On 08-12-2016 12:48, Volker Simonis wrote:
> I can do the downport.
> 
> It would be good tough if you could confirm that the fix solves your
> Hadoop/Terasort problem.

Sure, I'm confirming if that solves our Hadoop / Terasort problem.

Thanks a lot!


Best regards,
Gustavo


From aph at redhat.com  Thu Dec  8 15:45:30 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 8 Dec 2016 15:45:30 +0000
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <7D0CB45C-97E3-46B3-BB21-E6F4867A15DE@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<7cf3e68f-cdbd-d1ff-cd69-69c53ebccf40@oracle.com>
	<9f5114b8-6328-3c41-e469-dec7a1408915@oracle.com>
	<ea1090ea-8d2b-5860-fa67-9d8d71dccf6f@oracle.com>
	<7D0CB45C-97E3-46B3-BB21-E6F4867A15DE@oracle.com>
Message-ID: <650db804-3e6b-01b5-9157-ed8eb0d6f38e@redhat.com>

On 08/12/16 15:39, Doug Simon wrote:
> Can one work on any code without an IDE? ;-)

If the source tree is arranged like that, no.

Andrew.


From max.ockner at oracle.com  Thu Dec  8 22:11:02 2016
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 08 Dec 2016 17:11:02 -0500
Subject: RFR(xxs): 8157271: Avoid extra copy of NativeCallStack
Message-ID: <5849DA76.30607@oracle.com>

Hello,

Please review this one line enhancement. We formerly passed a copy of a 
NativeCallStack into MallocSiteHashtableEntry. We now pass a reference 
instead.

bug: https://bugs.openjdk.java.net/browse/JDK-8157271
webrev: http://cr.openjdk.java.net/~mockner/8157271.01/

tested with runtime/NMT jtreg tests.

Thanks,
Max

From zgu at redhat.com  Thu Dec  8 22:16:22 2016
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 8 Dec 2016 17:16:22 -0500
Subject: RFR(xxs): 8157271: Avoid extra copy of NativeCallStack
In-Reply-To: <5849DA76.30607@oracle.com>
References: <5849DA76.30607@oracle.com>
Message-ID: <ccd23a93-0dd9-87cb-f734-0932be85892b@redhat.com>

Look good to me.

-Zhengyu


On 12/08/2016 05:11 PM, Max Ockner wrote:
> Hello,
>
> Please review this one line enhancement. We formerly passed a copy of 
> a NativeCallStack into MallocSiteHashtableEntry. We now pass a 
> reference instead.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8157271
> webrev: http://cr.openjdk.java.net/~mockner/8157271.01/
>
> tested with runtime/NMT jtreg tests.
>
> Thanks,
> Max


From vladimir.kozlov at oracle.com  Thu Dec  8 22:49:46 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 8 Dec 2016 14:49:46 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <b3634e49-231a-a6c1-3c05-b8a6d06a3973@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<b3634e49-231a-a6c1-3c05-b8a6d06a3973@oracle.com>
Message-ID: <d0b3f364-6bbe-1ca4-5856-70ca469fbbc4@oracle.com>

Thank you, Erik

It was accident - I forgot to replace ENABLE_AOT with INCLUDE_GRAAL.
But it is very good accident :)  It showed that Tools.gmk is not needed 
- nice.

Removed and verified that combined AOT+Graal code is still built as before.

Thanks,
Vladimir

On 12/8/16 2:12 AM, Erik Joelsson wrote:
> Hello,
>
> The file hotspot/make/Tools.gmk is dead code at this point and should be
> removed. Also stop including it from Gensrc-jdk.vm.compiler.gmk.
>
> Otherwise it looks ok to me.
>
> /Erik
>
> On 2016-12-07 23:10, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>
>> It is part of JEP 295: Ahead-of-Time Compilation
>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>
>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>
>> This is formal review request for integration Graal-core sources into
>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>> integrated Graal-core sources into JDK and add build changes to build
>> Graal module.
>>
>> Note, changes are based on latest jdk9/hs sources which do not have
>> latest jigsaw update yet. With jigsaw update small changes will be
>> done to module-info.java.extra in java.base:
>>
>>   exports jdk.internal.misc to jdk.vm.compiler;
>> + opens jdk.internal.misc to jdk.vm.compiler;
>>
>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>
>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>
>>
>>
>> Graal is a dynamic compiler written in Java that integrates with the
>> HotSpot JVM. It has a focus on high performance and extensibility. In
>> addition, it provides optimized performance for Truffle based
>> languages running on the JVM.
>>
>> https://github.com/graalvm/graal-core
>>
>> Oracle Labs is developing and maintaining it.
>>
>> Here are people who contributed into Graal development (sorry if
>> someone is missing or misspelled, please speak):
>>
>> ~70k LOC: Douglas Simon
>> ~60k LOC: Lukas Stadler
>> ~30k LOC: Thomas Wuerthinger
>> ~30k LOC: Tom Rodriguez
>> ~30k LOC: Roland Schatz
>> ~30k LOC: Josef Eisl
>> ~30k LOC: Christian Wimmer
>> ~16k LOC: Chris Thalinger
>> ~13k LOC: Gilles Duboscq
>> ~11k LOC: David Leopoldseder
>> ~ 8k LOC: Stefan Anzinger
>> ~ 8k LOC: Christian Humer
>>
>> Other contributors >100 LOC in approximate order of contribution size:
>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>
>>
>> Thanks,
>> Vladimir
>

From serguei.spitsyn at oracle.com  Thu Dec  8 23:07:10 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 8 Dec 2016 15:07:10 -0800
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <1481115437.3024.9.camel@redhat.com>
References: <1481115437.3024.9.camel@redhat.com>
Message-ID: <37b66409-7ec2-edec-924d-ce9e6d0a526b@oracle.com>

Hi Severin,

It looks good.

Thanks,
Serguei


On 12/7/16 04:57, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review this Zero only change? The problem was
> there before, but only the fix for JDK-8169711 brought it to the
> surface. The returned method kind for
> java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
> in abstractInterpreter.cpp
>
> The fix is to generate stub entries for
> java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8170767
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/webrev.01/
>
> Thanks,
> Severin


From serguei.spitsyn at oracle.com  Thu Dec  8 23:13:11 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 8 Dec 2016 15:13:11 -0800
Subject: RFR(xxs): 8157271: Avoid extra copy of NativeCallStack
In-Reply-To: <5849DA76.30607@oracle.com>
References: <5849DA76.30607@oracle.com>
Message-ID: <c7d060d0-7c41-328e-fb87-d54a889f8978@oracle.com>

Hi Max,

It looks good.

Thanks,
Serguei


On 12/8/16 14:11, Max Ockner wrote:
> Hello,
>
> Please review this one line enhancement. We formerly passed a copy of 
> a NativeCallStack into MallocSiteHashtableEntry. We now pass a 
> reference instead.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8157271
> webrev: http://cr.openjdk.java.net/~mockner/8157271.01/
>
> tested with runtime/NMT jtreg tests.
>
> Thanks,
> Max


From david.holmes at oracle.com  Fri Dec  9 02:59:20 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 9 Dec 2016 12:59:20 +1000
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory limits
	in container (ie Docker) environments
Message-ID: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8170888

webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/

Adapted from the original submission here:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025404.html

and continuing:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025406.html

Christine: who should get original contribution credit - you or Andrew 
or both?

The change adds an experimental flag, -XX:+UseCGroupMemoryLimitForHeap, 
to opt-in to using the cgroup memory limit value as the value to use for 
"physical memory" when doing heap sizing. This is determined solely by 
the presence of, and then content of, the file 
/sys/fs/cgroup/memory/memory.limit_in_bytes. More extensive support will 
be investigated for JDK 10.

As the flag is opt-in, and we don't expect people to use it unless they 
expect there to be active cgroups, we warn if the file can not be found, 
or the memory limit value can not be parsed.

I considered making the flag linux-only and ifdef'ing the logic, but 
thought it might be useful to be able to pretend that a memory limit 
exists on other platforms just by creating this marker file (even though 
you'd need the right perms to create it).

Testing: manual - see below for output

Thanks,
David
-----

Here's an example run in a container with memory limited to 256M. First 
without using the flag:

root at 2f2664c92737:/# ./jdk-9/fastdebug/bin/java -XX:+PrintFlagsFinal 
-version | grep MaxHeap
    uintx MaxHeapFreeRatio = 70 {manageable} {default}
    size_t MaxHeapSize = 16873684992 {product} {ergonomic}
java version "9-internal"
Java(TM) SE Runtime Environment (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)

And then with:

root at 2f2664c92737:/# ./jdk-9/fastdebug/bin/java -XX:+PrintFlagsFinal 
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap 
-version | grep MaxHeap
     uintx MaxHeapFreeRatio = 70 {manageable} {default}
    size_t MaxHeapSize = 132120576 {product} {ergonomic}
java version "9-internal"
Java(TM) SE Runtime Environment (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)

so we can see the affect on the heap size.

Example of logging output:

root at e3f0f811cd91:/# ./jdk-9/fastdebug/bin/java 
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap 
-Xlog:gc+heap -version
[0.003s][info][gc,heap] Setting phys_mem to the min of cgroup limit 
(128MB) and initial phys_mem (64353MB)
[0.016s][info][gc,heap] Heap region size: 1M
java version "9-internal"
Java(TM) SE Runtime Environment (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)

Example of enabling the flag on a system with no cgroups:

 > ./build/linux-x64-debug/images/jdk/bin/java 
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version
Java HotSpot(TM) 64-Bit Server VM warning: Unable to open cgroup memory 
limit file /sys/fs/cgroup/memory/memory.limit_in_bytes (No such file or 
directory)
java version "9-internal"
Java(TM) SE Runtime Environment (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)

Example logging output when running unlimited:

  ./jdk-9/fastdebug/bin/java -XX:+UnlockExperimentalVMOptions 
-XX:+UseCGroupMemoryLimitForHeap -Xlog:gc+heap -version
[0.002s][info][gc,heap] Setting phys_mem to the min of cgroup limit 
(8796093022207MB) and initial phys_mem (64353MB)
[0.016s][info][gc,heap] Heap region size: 4M
java version "9-internal"
Java(TM) SE Runtime Environment (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)

From mandy.chung at oracle.com  Fri Dec  9 03:46:00 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 8 Dec 2016 19:46:00 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
Message-ID: <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>


> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8166417
> 
> It is part of JEP 295: Ahead-of-Time Compilation
> https://bugs.openjdk.java.net/browse/JDK-8166089
> 
> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/

I reviewed module-info.java.*.

src/java.base/share/classes/module-info.java.extra

Now I realized jdk.vm.compiler may be excluded from JDK time at 
build/configure time.  That explains why you can?t add these
qualified exports to module-info.java.

As we discussed offline, you can move this file to unix/classes
and if jdk.vm.compiler is not included in the JDK build, the build
tool that generates gensrc/java.base/module-info.java would filter
out these qualified exports.

Related to the use of jdk.internal.misc.VM, you mentioned separately
that Graal uses jdk.internal.misc.VM.savedProps to find properties with
GRAAL_OPTION_PROPERTY_PREFIX.  Why can?t you use System.getProperties?
savedProps stores the properties that are removed from system properties.
Are Graal?s properties not in system properties?


> 
> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/

src/jdk.vm.compiler/share/classes/module-info.java

jdk.management requires transitive java.management and so line 28 is
not strictly necessary but no harm to have it:
  28     requires java.management;

make/gensrc/Gensrc-jdk.vm.compiler.gmk

 131         for i in $$($(FIND) $(GENSRC_DIR) -name '*_OptionDescriptors.java'); do \
 132             c=$$($(ECHO) $$i | $(SED) 's:.*/jdk\.vm\.compiler/\(.*\)\.java:\1:' | $(TR) '/' '.'); \
 133             $(ECHO) "provides org.graalvm.compiler.options.OptionDescriptors with $$c;" >> $@; \
 134         done

The new syntax for provides is to have one `provides` clause of the same SPI
with comma-separated implementation classes (see [1] for reference)

The build tool temporarily allows multiple `provides` of the same SPI just
for transition.  Is it easy to change the above to generate one single `provides`
clauses?  I?m okay if you want to file a JBS issue to follow up this separately
after the integration.
 
Mandy
[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.desktop/share/classes/module-info.java


From vladimir.kozlov at oracle.com  Fri Dec  9 07:07:05 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 8 Dec 2016 23:07:05 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
Message-ID: <c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>

Thank you, Mandy

On 12/8/16 7:46 PM, Mandy Chung wrote:
>
>> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>
>> It is part of JEP 295: Ahead-of-Time Compilation
>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>
>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>
> I reviewed module-info.java.*.
>
> src/java.base/share/classes/module-info.java.extra
>
> Now I realized jdk.vm.compiler may be excluded from JDK time at
> build/configure time.  That explains why you can?t add these
> qualified exports to module-info.java.
>
> As we discussed offline, you can move this file to unix/classes
> and if jdk.vm.compiler is not included in the JDK build, the build
> tool that generates gensrc/java.base/module-info.java would filter
> out these qualified exports.

Done. And it works.

>
> Related to the use of jdk.internal.misc.VM, you mentioned separately
> that Graal uses jdk.internal.misc.VM.savedProps to find properties with
> GRAAL_OPTION_PROPERTY_PREFIX.  Why can?t you use System.getProperties?
> savedProps stores the properties that are removed from system properties.
> Are Graal?s properties not in system properties?

I asked Graal guys. May be Doug can answer.

>
>
>>
>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>
> src/jdk.vm.compiler/share/classes/module-info.java
>
> jdk.management requires transitive java.management and so line 28 is
> not strictly necessary but no harm to have it:
>   28     requires java.management;

Then I will keep it.

>
> make/gensrc/Gensrc-jdk.vm.compiler.gmk
>
>  131         for i in $$($(FIND) $(GENSRC_DIR) -name '*_OptionDescriptors.java'); do \
>  132             c=$$($(ECHO) $$i | $(SED) 's:.*/jdk\.vm\.compiler/\(.*\)\.java:\1:' | $(TR) '/' '.'); \
>  133             $(ECHO) "provides org.graalvm.compiler.options.OptionDescriptors with $$c;" >> $@; \
>  134         done
>
> The new syntax for provides is to have one `provides` clause of the same SPI
> with comma-separated implementation classes (see [1] for reference)

Previous loop in this makefile also produces multiple `provides` of the 
same SPI. I fixed it too. The output is next for example:

provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with
     org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory,
     org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory,
     ;

Looks like build tools excepts ; after ,
If you are fine with it I will make this change.

Thanks,
Vladimir

>
> The build tool temporarily allows multiple `provides` of the same SPI just
> for transition.  Is it easy to change the above to generate one single `provides`
> clauses?  I?m okay if you want to file a JBS issue to follow up this separately
> after the integration.
>
> Mandy
> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.desktop/share/classes/module-info.java
>

From doug.simon at oracle.com  Fri Dec  9 08:25:40 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 9 Dec 2016 09:25:40 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
	<c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
Message-ID: <14EDCB93-1A23-4232-96C8-FD2C5A8ADDA5@oracle.com>


> On 9 Dec 2016, at 08:07, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Thank you, Mandy
> 
> On 12/8/16 7:46 PM, Mandy Chung wrote:
>> 
>>> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>> 
>>> It is part of JEP 295: Ahead-of-Time Compilation
>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>> 
>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>> 
>> I reviewed module-info.java.*.
>> 
>> src/java.base/share/classes/module-info.java.extra
>> 
>> Now I realized jdk.vm.compiler may be excluded from JDK time at
>> build/configure time.  That explains why you can?t add these
>> qualified exports to module-info.java.
>> 
>> As we discussed offline, you can move this file to unix/classes
>> and if jdk.vm.compiler is not included in the JDK build, the build
>> tool that generates gensrc/java.base/module-info.java would filter
>> out these qualified exports.
> 
> Done. And it works.
> 
>> 
>> Related to the use of jdk.internal.misc.VM, you mentioned separately
>> that Graal uses jdk.internal.misc.VM.savedProps to find properties with
>> GRAAL_OPTION_PROPERTY_PREFIX.  Why can?t you use System.getProperties?
>> savedProps stores the properties that are removed from system properties.
>> Are Graal?s properties not in system properties?
> 
> I asked Graal guys. May be Doug can answer.


The reason we use VM.savedProps is that initialization of JVMCI and Graal is lazy (to avoid impacting VM startup) and can take place after application code has been executed. As such, we want to avoid the possibility of tampering with the system properties that configure JVMCI and Graal (i.e., all ?jvmci.*? and ?graal.*? properties).

-Doug

From kirill.zhaldybin at oracle.com  Fri Dec  9 08:33:56 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Fri, 9 Dec 2016 11:33:56 +0300
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <CAA-vtUw6HVi8-xN2PjY9-5BO3eTFvvQD2bvSXR6paO9k4JAy+g@mail.gmail.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
	<2e8e47b9-4923-ff5c-ab50-1d7a3761cf8b@oracle.com>
	<ff2a0b56-0650-96e7-0fae-6ad04f0b0602@oracle.com>
	<CAA-vtUw6HVi8-xN2PjY9-5BO3eTFvvQD2bvSXR6paO9k4JAy+g@mail.gmail.com>
Message-ID: <584A6C74.1000901@oracle.com>

Thomas,

Thank you for noticing this!

I filed JDK-8170976 for this issue.
I think we should fix it but since we do not support running gtests with 
external flags I do not think it is a big issue for now.

Regards, Kirill

On 08.12.2016 18:09, Thomas St?fe wrote:
> Hi,
>
> I wonder whether the test should use TEST_OTHER_VM?
>
> If I understand the coding in LogTestFixture correctly, it changes the
> log configuration and does not restore it to its original value but to a
> default state. So, logging would not be possible for follow up tests in
> the same VM.
>
> So, test should either run in an own VM or LogTextFixture should
> snapshot and restore the original log configuration.
>
> Kind Regards, Thomas
>
>
> On Thu, Dec 8, 2016 at 3:41 PM, Kirill Zhaldybin
> <kirill.zhaldybin at oracle.com <mailto:kirill.zhaldybin at oracle.com>> wrote:
>
>     Marcus,
>
>     Thank you for review!
>
>     Regards, Kirill
>
>     On 08.12.2016 17:08, Marcus Larsson wrote:
>
>         Hi,
>
>
>         On 2016-12-08 14:32, Kirill Zhaldybin wrote:
>
>             Dear all,
>
>             Could you please review this fix for 8170919?
>
>             Since the tests use Resource Mark they should be run with
>             TEST_VM not TEST.
>
>             WebRev:
>             http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/webrev.00/
>             <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/webrev.00/>
>
>
>         Looks good.
>
>         Marcus
>
>             CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>             <https://bugs.openjdk.java.net/browse/JDK-8170919>
>
>             Thank you.
>
>             Regards, Kirill
>
>
>
>


From vladimir.kozlov at oracle.com  Fri Dec  9 09:13:24 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 9 Dec 2016 01:13:24 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com>
	<637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com>
Message-ID: <f67090f7-32c0-9448-a356-7c73de565f21@oracle.com>

Thank you, Magnus, for review.

I updated webrevs with merge from latest jdk9/hs which now has Jigsaw 
update.

http://cr.openjdk.java.net/~kvn/8166417.v2/top.webrev/
http://cr.openjdk.java.net/~kvn/8166417.v2/jdk.webrev/
http://cr.openjdk.java.net/~kvn/8166417.v2/hotspot.webrev/

Removed hotspot/make/Tools.gmk

Removed all overview.html files in graal sources.

Fixed hotspot.m4 and changed condition in hotspot.m4 to build graal only 
on linux-x64. The condition will be changed to check ENABLE_AOT when 
merged with AOT changes later.

Moved module-info.java.extra from share/classes to unix/classes per 
Mandy suggestion since we will build graal only for AOT.

I have to modify make/Javadoc.gmk to avoid next JPRT failure:

javadoc: error - No source files for package 
org.graalvm.compiler.api.collections.src.org.graalvm.compiler.api.collections
make[3]: *** 
[/scratch/opt/jprt/T/P1/232453.vkozlov/s/build/linux-x64/images/docs/api/index.html] 
Error 1

We did not generate docs for Graal before because its package was 
com.oracle.graal. I think it is fine to not generate it now too.
Please, help if you think make/Javadoc.gmk should be fixed other way.

By Mandy request changed code in 
hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk to produce 
module-info.java.extra with one `provides` clause of the same SPI like next:

provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with
     org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory,
     org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory,
     ;


About moving preprocessors .java files into make/src and .test files 
into hotspot/test.

First, they are unit tests and not jtreg. Second, we did experiment 
during AOT development with tests move but found that it is merge (from 
graal-core) nightmare and tests execution problems.

For now we want sources in JDK exactly match sources in 
https://github.com/graalvm/graal-core

Oracle Labs continue Graal development very actively and we want to be 
in sync with them without big merge overhead.

Thanks,
Vladimir

On 12/8/16 5:08 AM, Doug Simon wrote:
>
>> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> On 2016-12-07 23:10, Vladimir Kozlov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>
>>> It is part of JEP 295: Ahead-of-Time Compilation
>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>
>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>
>> * In CompileJavaModules.gmk, there is an *extreme* list of excludes. I note that most of them end in ".test". The proper solution to this is to move the test code to the test/ directory instead of the src/ directory. Also, four of them are the javac processor build tools. These should move to make/src, as other build tools.
>
> Keeping like it is simplifies pulling changes from https://github.com/graalvm/graal-core. It's possible to write a more sophisticated tool for pulling changes in from the github and places the sources into more openjdk compatible locations. It's up to the HotSpot compiler team whether investing in such a tool makes sense.
>
>> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will be garbled.
>>
>> * In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is incorrect. It only tests for the default value, not for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)).
>>
>> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), true)" will never evaluate to true). But on the other hand, it is not needed, and should just be removed. :-)
>>
>> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems a bit dangling. Is this supposed to be included in some Javadoc generation? The html file refers to a projects.jpg and projects.html that does not exist. Maybe it should just be removed?
>
> I would recommend omitting all graal-core overview.html files in OpenJDK.
>
>> * Finally, just for the record, I too think the source should be structured according to the OpenJDK praxis. (But I won't fight about this.)
>
> -Doug
>
>>>
>>> This is formal review request for integration Graal-core sources into OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to integrated Graal-core sources into JDK and add build changes to build Graal module.
>>>
>>> Note, changes are based on latest jdk9/hs sources which do not have latest jigsaw update yet. With jigsaw update small changes will be done to module-info.java.extra in java.base:
>>>
>>>  exports jdk.internal.misc to jdk.vm.compiler;
>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>
>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>
>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>
>>>
>>>
>>> Graal is a dynamic compiler written in Java that integrates with the HotSpot JVM. It has a focus on high performance and extensibility. In addition, it provides optimized performance for Truffle based languages running on the JVM.
>>>
>>> https://github.com/graalvm/graal-core
>>>
>>> Oracle Labs is developing and maintaining it.
>>>
>>> Here are people who contributed into Graal development (sorry if someone is missing or misspelled, please speak):
>>>
>>> ~70k LOC: Douglas Simon
>>> ~60k LOC: Lukas Stadler
>>> ~30k LOC: Thomas Wuerthinger
>>> ~30k LOC: Tom Rodriguez
>>> ~30k LOC: Roland Schatz
>>> ~30k LOC: Josef Eisl
>>> ~30k LOC: Christian Wimmer
>>> ~16k LOC: Chris Thalinger
>>> ~13k LOC: Gilles Duboscq
>>> ~11k LOC: David Leopoldseder
>>> ~ 8k LOC: Stefan Anzinger
>>> ~ 8k LOC: Christian Humer
>>>
>>> Other contributors >100 LOC in approximate order of contribution size:
>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>>
>>>
>>> Thanks,
>>> Vladimir
>>
>

From edward.nevill at gmail.com  Fri Dec  9 11:33:28 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Fri, 09 Dec 2016 11:33:28 +0000
Subject: RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
Message-ID: <1481283208.12942.22.camel@gmail.com>

On Fri, 2016-12-02 at 15:28 -0500, Bob Vandette wrote:
> 
> JEP 297:
> 
> https://bugs.openjdk.java.net/browse/JDK-8168503
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~bobv/8168503
> 

I have added the results of JCStress testing as a comment to the JEP.

Basically 100% pass with some 'formally acceptable but surprising' results.

Thanks to Stuart Monteith for helping with the arm32 testing.

All the best,
Ed.


From karen.kinnear at oracle.com  Fri Dec  9 15:34:09 2016
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 9 Dec 2016 10:34:09 -0500
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
Message-ID: <CAF1C2A9-D526-4C27-8285-A92D4877FDD2@oracle.com>

David,

Looks good. Thank you for printing the sample output.
And I like the scoping of the experimental flag name.

thanks,
Karen

> On Dec 8, 2016, at 9:59 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
> 
> webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/
> 
> Adapted from the original submission here:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025404.html
> 
> and continuing:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025406.html
> 
> Christine: who should get original contribution credit - you or Andrew or both?
> 
> The change adds an experimental flag, -XX:+UseCGroupMemoryLimitForHeap, to opt-in to using the cgroup memory limit value as the value to use for "physical memory" when doing heap sizing. This is determined solely by the presence of, and then content of, the file /sys/fs/cgroup/memory/memory.limit_in_bytes. More extensive support will be investigated for JDK 10.
> 
> As the flag is opt-in, and we don't expect people to use it unless they expect there to be active cgroups, we warn if the file can not be found, or the memory limit value can not be parsed.
> 
> I considered making the flag linux-only and ifdef'ing the logic, but thought it might be useful to be able to pretend that a memory limit exists on other platforms just by creating this marker file (even though you'd need the right perms to create it).
> 
> Testing: manual - see below for output
> 
> Thanks,
> David
> -----
> 
> Here's an example run in a container with memory limited to 256M. First without using the flag:
> 
> root at 2f2664c92737:/# ./jdk-9/fastdebug/bin/java -XX:+PrintFlagsFinal -version | grep MaxHeap
>   uintx MaxHeapFreeRatio = 70 {manageable} {default}
>   size_t MaxHeapSize = 16873684992 {product} {ergonomic}
> java version "9-internal"
> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
> 
> And then with:
> 
> root at 2f2664c92737:/# ./jdk-9/fastdebug/bin/java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version | grep MaxHeap
>    uintx MaxHeapFreeRatio = 70 {manageable} {default}
>   size_t MaxHeapSize = 132120576 {product} {ergonomic}
> java version "9-internal"
> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
> 
> so we can see the affect on the heap size.
> 
> Example of logging output:
> 
> root at e3f0f811cd91:/# ./jdk-9/fastdebug/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Xlog:gc+heap -version
> [0.003s][info][gc,heap] Setting phys_mem to the min of cgroup limit (128MB) and initial phys_mem (64353MB)
> [0.016s][info][gc,heap] Heap region size: 1M
> java version "9-internal"
> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
> 
> Example of enabling the flag on a system with no cgroups:
> 
> > ./build/linux-x64-debug/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version
> Java HotSpot(TM) 64-Bit Server VM warning: Unable to open cgroup memory limit file /sys/fs/cgroup/memory/memory.limit_in_bytes (No such file or directory)
> java version "9-internal"
> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
> 
> Example logging output when running unlimited:
> 
> ./jdk-9/fastdebug/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Xlog:gc+heap -version
> [0.002s][info][gc,heap] Setting phys_mem to the min of cgroup limit (8796093022207MB) and initial phys_mem (64353MB)
> [0.016s][info][gc,heap] Heap region size: 4M
> java version "9-internal"
> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)


From mandy.chung at oracle.com  Fri Dec  9 16:36:46 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 9 Dec 2016 08:36:46 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <14EDCB93-1A23-4232-96C8-FD2C5A8ADDA5@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
	<c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
	<14EDCB93-1A23-4232-96C8-FD2C5A8ADDA5@oracle.com>
Message-ID: <DC41DB5D-E453-406B-9481-218FF77BBB8D@oracle.com>


> On Dec 9, 2016, at 12:25 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> The reason we use VM.savedProps is that initialization of JVMCI and Graal is lazy (to avoid impacting VM startup) and can take place after application code has been executed. As such, we want to avoid the possibility of tampering with the system properties that configure JVMCI and Graal (i.e., all ?jvmci.*? and ?graal.*? properties).

You may want to re-examine this as a future follow-up issue that may remove this qualified `opens`. There is no magic with savedProps but it does not have security permission check.

Mandy


From mandy.chung at oracle.com  Fri Dec  9 16:40:04 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 9 Dec 2016 08:40:04 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
	<c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
Message-ID: <B762111E-8751-4E2C-80D8-1430CF5A3E78@oracle.com>


> On Dec 8, 2016, at 11:07 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> 
>> The new syntax for provides is to have one `provides` clause of the same SPI
>> with comma-separated implementation classes (see [1] for reference)
> 
> Previous loop in this makefile also produces multiple `provides` of the same SPI. I fixed it too. The output is next for example:
> 
> provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with
>    org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory,
>    org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory,
>    ;
> 
> Looks like build tools excepts ; after ,
> If you are fine with it I will make this change.

It?s a bug in the build tool and I will file a bug. 

Is it easy to drop last comma?  If not, we could fix this makefile when the build tool is fixed.

Mandy

From vladimir.kozlov at oracle.com  Fri Dec  9 18:40:56 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 9 Dec 2016 10:40:56 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <B762111E-8751-4E2C-80D8-1430CF5A3E78@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
	<c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
	<B762111E-8751-4E2C-80D8-1430CF5A3E78@oracle.com>
Message-ID: <9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com>

On 12/9/16 8:40 AM, Mandy Chung wrote:
>
>> On Dec 8, 2016, at 11:07 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>>>
>>> The new syntax for provides is to have one `provides` clause of the same SPI
>>> with comma-separated implementation classes (see [1] for reference)
>>
>> Previous loop in this makefile also produces multiple `provides` of the same SPI. I fixed it too. The output is next for example:
>>
>> provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with
>>    org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory,
>>    org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory,
>>    ;
>>
>> Looks like build tools excepts ; after ,
>> If you are fine with it I will make this change.
>
> It?s a bug in the build tool and I will file a bug.
>
> Is it easy to drop last comma?  If not, we could fix this makefile when the build tool is fixed.

It is very hard to drop the last comma from makefile code. I don't know 
how to do that. Please, don't fix this in tool and allow such output.

Otherwise I will have to return back to produces multiple `provides` of 
the same SPI.

Vladimir

>
> Mandy
>

From mandy.chung at oracle.com  Fri Dec  9 19:00:00 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 9 Dec 2016 11:00:00 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
	<c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
	<B762111E-8751-4E2C-80D8-1430CF5A3E78@oracle.com>
	<9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com>
Message-ID: <522D0DEF-CB64-4B47-84B1-3756C90C8876@oracle.com>


> On Dec 9, 2016, at 10:40 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> 
> It is very hard to drop the last comma from makefile code. I don't know how to do that. Please, don't fix this in tool and allow such output.
> 
> Otherwise I will have to return back to produces multiple `provides` of the same SPI.

OK.  What I meant is that the alternative is to clean this up in the future together when the build tool enforces this check. 

I?m okay with your patch.

Mandy


From vladimir.kozlov at oracle.com  Fri Dec  9 19:15:34 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 9 Dec 2016 11:15:34 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <522D0DEF-CB64-4B47-84B1-3756C90C8876@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<51713578-102F-40C8-9F8A-79988D7674B0@oracle.com>
	<c981ff37-8f34-5ff6-f7c4-a5e794d1e0d9@oracle.com>
	<B762111E-8751-4E2C-80D8-1430CF5A3E78@oracle.com>
	<9f4e7c10-e9c5-3039-688c-877487d71724@oracle.com>
	<522D0DEF-CB64-4B47-84B1-3756C90C8876@oracle.com>
Message-ID: <48cbd8cd-66f5-3e09-7a99-793916f6bde6@oracle.com>

Thank you, Mandy

Vladimir

On 12/9/16 11:00 AM, Mandy Chung wrote:
>
>> On Dec 9, 2016, at 10:40 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>>
>> It is very hard to drop the last comma from makefile code. I don't know how to do that. Please, don't fix this in tool and allow such output.
>>
>> Otherwise I will have to return back to produces multiple `provides` of the same SPI.
>
> OK.  What I meant is that the alternative is to clean this up in the future together when the build tool enforces this check.
>
> I?m okay with your patch.
>
> Mandy
>

From david.holmes at oracle.com  Fri Dec  9 22:49:02 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 10 Dec 2016 08:49:02 +1000
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <CAF1C2A9-D526-4C27-8285-A92D4877FDD2@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<CAF1C2A9-D526-4C27-8285-A92D4877FDD2@oracle.com>
Message-ID: <1b39700f-c50c-429f-e414-bee2d55335f5@oracle.com>

Thanks Karen!

David

On 10/12/2016 1:34 AM, Karen Kinnear wrote:
> David,
>
> Looks good. Thank you for printing the sample output.
> And I like the scoping of the experimental flag name.
>
> thanks,
> Karen
>
>> On Dec 8, 2016, at 9:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/
>>
>> Adapted from the original submission here:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025404.html
>>
>> and continuing:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025406.html
>>
>> Christine: who should get original contribution credit - you or Andrew or both?
>>
>> The change adds an experimental flag, -XX:+UseCGroupMemoryLimitForHeap, to opt-in to using the cgroup memory limit value as the value to use for "physical memory" when doing heap sizing. This is determined solely by the presence of, and then content of, the file /sys/fs/cgroup/memory/memory.limit_in_bytes. More extensive support will be investigated for JDK 10.
>>
>> As the flag is opt-in, and we don't expect people to use it unless they expect there to be active cgroups, we warn if the file can not be found, or the memory limit value can not be parsed.
>>
>> I considered making the flag linux-only and ifdef'ing the logic, but thought it might be useful to be able to pretend that a memory limit exists on other platforms just by creating this marker file (even though you'd need the right perms to create it).
>>
>> Testing: manual - see below for output
>>
>> Thanks,
>> David
>> -----
>>
>> Here's an example run in a container with memory limited to 256M. First without using the flag:
>>
>> root at 2f2664c92737:/# ./jdk-9/fastdebug/bin/java -XX:+PrintFlagsFinal -version | grep MaxHeap
>>   uintx MaxHeapFreeRatio = 70 {manageable} {default}
>>   size_t MaxHeapSize = 16873684992 {product} {ergonomic}
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
>>
>> And then with:
>>
>> root at 2f2664c92737:/# ./jdk-9/fastdebug/bin/java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version | grep MaxHeap
>>    uintx MaxHeapFreeRatio = 70 {manageable} {default}
>>   size_t MaxHeapSize = 132120576 {product} {ergonomic}
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
>>
>> so we can see the affect on the heap size.
>>
>> Example of logging output:
>>
>> root at e3f0f811cd91:/# ./jdk-9/fastdebug/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Xlog:gc+heap -version
>> [0.003s][info][gc,heap] Setting phys_mem to the min of cgroup limit (128MB) and initial phys_mem (64353MB)
>> [0.016s][info][gc,heap] Heap region size: 1M
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
>>
>> Example of enabling the flag on a system with no cgroups:
>>
>>> ./build/linux-x64-debug/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version
>> Java HotSpot(TM) 64-Bit Server VM warning: Unable to open cgroup memory limit file /sys/fs/cgroup/memory/memory.limit_in_bytes (No such file or directory)
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
>>
>> Example logging output when running unlimited:
>>
>> ./jdk-9/fastdebug/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Xlog:gc+heap -version
>> [0.002s][info][gc,heap] Setting phys_mem to the min of cgroup limit (8796093022207MB) and initial phys_mem (64353MB)
>> [0.016s][info][gc,heap] Heap region size: 4M
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-12-07-202859.daholme.jdk9-hs-dev2, mixed mode)
>

From kim.barrett at oracle.com  Sat Dec 10 00:22:10 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 9 Dec 2016 19:22:10 -0500
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
Message-ID: <F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>

> On Dec 8, 2016, at 9:59 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
> 
> webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/

------------------------------------------------------------------------------
src/share/vm/runtime/arguments.cpp 
2050       fscanf(fp, JULONG_FORMAT, &cgroup_max);
2051       if (cgroup_max > 0) {

Missing check of fscanf result.  I don't see anything in the doc for
fscanf that promises an argument won't be clobbered if there are match
failures, errors, or fewer inputs than specified in the format string.
Even if that no such clobbering happens, as written we have a really
rare failure mode -- in cgroup context, but inopportune EINTR -- that
gets reported as a parse failure warning and ignoring the cgroup limit.

------------------------------------------------------------------------------
src/share/vm/runtime/arguments.cpp 
2054         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("

log_info seems a little noisy, especially considering that we
ultimately announce the final ergonomic (Min|Max)HeapSize with
log_trace.

------------------------------------------------------------------------------ 
src/share/vm/runtime/arguments.cpp 

Trivial style nit:

2058       }
2059       else {

2063     }
2064     else {

should be "  } else {"

------------------------------------------------------------------------------


From brent.christian at oracle.com  Sat Dec 10 01:16:58 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 09 Dec 2016 17:16:58 -0800
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
In-Reply-To: <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>
References: <584885AA.9060202@oracle.com>
	<53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>
Message-ID: <584B578A.1030508@oracle.com>

On 12/07/2016 04:05 PM, Mandy Chung wrote:
>
> I suggest to add two utility methods rather than the has method:
>    boolean dropClassLoaderName()
>    boolean dropModuleVersion()

Done.

>   430    if (m != null && m.isNamed() &&
>   431          (isHashedInJavaBase(m) || !m.getDescriptor().version().isPresent())) {
>   432        bits |= JDK_NON_UPGRADEABLE_MODULE;
>   433    }
>
> I think this should simply be:
>     if (isHashedInJavaBase(m)) {..}
>

Done.

> Can you retain the javadoc of toLoaderModuleClassName, revised if appropriate, in the computeFormat method?

Updated.

> line 322-325: what about:
>
> The toString method may return two different values on two
> StackTraceElement instances that are equal for example when
> one created via the constructor and one obtained from Throwable
> or StackFrame where an implementation may choose to omit some
> element in the returned string.

That sounds good.

> Is @apiNote in equals necessary?  Maybe the one added in toString is adequate?

I'm fine without it - removed.


I also fixed test code for a case which only works with the images build.

Updated webrev:
http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/

-Brent

From david.holmes at oracle.com  Sat Dec 10 01:24:03 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 10 Dec 2016 11:24:03 +1000
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
Message-ID: <e8046420-466c-0e57-c18f-e661846847c7@oracle.com>

Hi Kim,

Thanks for looking at this.

On 10/12/2016 10:22 AM, Kim Barrett wrote:
>> On Dec 8, 2016, at 9:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/
>
> ------------------------------------------------------------------------------
> src/share/vm/runtime/arguments.cpp
> 2050       fscanf(fp, JULONG_FORMAT, &cgroup_max);
> 2051       if (cgroup_max > 0) {
>
> Missing check of fscanf result.  I don't see anything in the doc for
> fscanf that promises an argument won't be clobbered if there are match
> failures, errors, or fewer inputs than specified in the format string.
> Even if that no such clobbering happens, as written we have a really
> rare failure mode -- in cgroup context, but inopportune EINTR -- that
> gets reported as a parse failure warning and ignoring the cgroup limit.

Hmmm okay I was trying to keep it simple. I will check rc==0 as well, 
else give the warning, including reporting errno if non-zero.

> ------------------------------------------------------------------------------
> src/share/vm/runtime/arguments.cpp
> 2054         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
>
> log_info seems a little noisy, especially considering that we
> ultimately announce the final ergonomic (Min|Max)HeapSize with
> log_trace.

I figure if you want to use the cgroup limit then you want to clearly 
see the result of doing so. I don't think hiding that info at the lowest 
tracing level would be helpful to the user.

> ------------------------------------------------------------------------------
> src/share/vm/runtime/arguments.cpp
>
> Trivial style nit:
>
> 2058       }
> 2059       else {
>
> 2063     }
> 2064     else {
>
> should be "  } else {"
>
> ------------------------------------------------------------------------------

Ok.

I'll do the updates and try to retest over the weekend - then post 
updated webrev.

Thanks,
David


From mandy.chung at oracle.com  Sat Dec 10 01:31:16 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 9 Dec 2016 17:31:16 -0800
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
In-Reply-To: <584B578A.1030508@oracle.com>
References: <584885AA.9060202@oracle.com>
	<53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>
	<584B578A.1030508@oracle.com>
Message-ID: <FB532085-9104-4BBD-B59E-15FBEE3232A4@oracle.com>


> On Dec 9, 2016, at 5:16 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Updated webrev:
> http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/

Looks good.

Mandy


From jesper.wilhelmsson at oracle.com  Sat Dec 10 02:23:18 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Sat, 10 Dec 2016 03:23:18 +0100
Subject: RFR(xs): JDK-8171046 - Quarantine TestStressG1Humongous.java until
	JDK-8171045 is fixed
Message-ID: <5ddd1009-1482-5d0a-a72d-66f770c983b0@oracle.com>

Hi,

Please review this tiny change to quarantine a test that is failing in the 
hotspot nightly.

Bug: https://bugs.openjdk.java.net/browse/JDK-8171046
Webrev: http://cr.openjdk.java.net/~jwilhelm/8171046/webrev.00/

Thanks,
/Jesper

From vladimir.kozlov at oracle.com  Sat Dec 10 02:33:11 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 9 Dec 2016 18:33:11 -0800
Subject: RFR(xs): JDK-8171046 - Quarantine TestStressG1Humongous.java
	until JDK-8171045 is fixed
In-Reply-To: <5ddd1009-1482-5d0a-a72d-66f770c983b0@oracle.com>
References: <5ddd1009-1482-5d0a-a72d-66f770c983b0@oracle.com>
Message-ID: <25ab94e5-c486-5433-df09-acb22f1d8884@oracle.com>

Looks good.

Vladimir

On 12/9/16 6:23 PM, Jesper Wilhelmsson wrote:
> Hi,
>
> Please review this tiny change to quarantine a test that is failing in
> the hotspot nightly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171046
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8171046/webrev.00/
>
> Thanks,
> /Jesper

From jesper.wilhelmsson at oracle.com  Sat Dec 10 02:51:32 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Sat, 10 Dec 2016 03:51:32 +0100
Subject: RFR(xs): JDK-8171046 - Quarantine TestStressG1Humongous.java
	until JDK-8171045 is fixed
In-Reply-To: <25ab94e5-c486-5433-df09-acb22f1d8884@oracle.com>
References: <5ddd1009-1482-5d0a-a72d-66f770c983b0@oracle.com>
	<25ab94e5-c486-5433-df09-acb22f1d8884@oracle.com>
Message-ID: <8d31c44b-1505-69ed-411c-b2ba5ba88255@oracle.com>

Thanks Vladimir!
/Jesper

Den 10/12/16 kl. 03:33, skrev Vladimir Kozlov:
> Looks good.
>
> Vladimir
>
> On 12/9/16 6:23 PM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> Please review this tiny change to quarantine a test that is failing in
>> the hotspot nightly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171046
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8171046/webrev.00/
>>
>> Thanks,
>> /Jesper

From kim.barrett at oracle.com  Sat Dec 10 05:00:10 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 10 Dec 2016 00:00:10 -0500
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
	<e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
Message-ID: <2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>

> On Dec 9, 2016, at 8:24 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,
> 
> Thanks for looking at this.
> 
> On 10/12/2016 10:22 AM, Kim Barrett wrote:
>>> On Dec 8, 2016, at 9:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>> 
>>> webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/
>> 
>> ------------------------------------------------------------------------------
>> src/share/vm/runtime/arguments.cpp
>> 2050       fscanf(fp, JULONG_FORMAT, &cgroup_max);
>> 2051       if (cgroup_max > 0) {
>> 
>> Missing check of fscanf result.  I don't see anything in the doc for
>> fscanf that promises an argument won't be clobbered if there are match
>> failures, errors, or fewer inputs than specified in the format string.
>> Even if that no such clobbering happens, as written we have a really
>> rare failure mode -- in cgroup context, but inopportune EINTR -- that
>> gets reported as a parse failure warning and ignoring the cgroup limit.
> 
> Hmmm okay I was trying to keep it simple. I will check rc==0 as well, else give the warning, including reporting errno if non-zero.

Okay.

>> ------------------------------------------------------------------------------
>> src/share/vm/runtime/arguments.cpp
>> 2054         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
>> 
>> log_info seems a little noisy, especially considering that we
>> ultimately announce the final ergonomic (Min|Max)HeapSize with
>> log_trace.
> 
> I figure if you want to use the cgroup limit then you want to clearly see the result of doing so. I don't think hiding that info at the lowest tracing level would be helpful to the user.

That?s a good rationale.  Leave the logging as is.



From erik.joelsson at oracle.com  Sat Dec 10 07:42:35 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Sat, 10 Dec 2016 08:42:35 +0100
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <f67090f7-32c0-9448-a356-7c73de565f21@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com>
	<637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com>
	<f67090f7-32c0-9448-a356-7c73de565f21@oracle.com>
Message-ID: <201e1454-22e4-22fd-0b43-36ffbc83e4d9@oracle.com>

This looks ok to me.

/Erik


On 2016-12-09 10:13, Vladimir Kozlov wrote:
> Thank you, Magnus, for review.
>
> I updated webrevs with merge from latest jdk9/hs which now has Jigsaw 
> update.
>
> http://cr.openjdk.java.net/~kvn/8166417.v2/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417.v2/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/8166417.v2/hotspot.webrev/
>
> Removed hotspot/make/Tools.gmk
>
> Removed all overview.html files in graal sources.
>
> Fixed hotspot.m4 and changed condition in hotspot.m4 to build graal 
> only on linux-x64. The condition will be changed to check ENABLE_AOT 
> when merged with AOT changes later.
>
> Moved module-info.java.extra from share/classes to unix/classes per 
> Mandy suggestion since we will build graal only for AOT.
>
> I have to modify make/Javadoc.gmk to avoid next JPRT failure:
>
> javadoc: error - No source files for package 
> org.graalvm.compiler.api.collections.src.org.graalvm.compiler.api.collections
> make[3]: *** 
> [/scratch/opt/jprt/T/P1/232453.vkozlov/s/build/linux-x64/images/docs/api/index.html] 
> Error 1
>
> We did not generate docs for Graal before because its package was 
> com.oracle.graal. I think it is fine to not generate it now too.
> Please, help if you think make/Javadoc.gmk should be fixed other way.
>
> By Mandy request changed code in 
> hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk to produce 
> module-info.java.extra with one `provides` clause of the same SPI like 
> next:
>
> provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with
>     org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory,
> org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory,
>     ;
>
>
> About moving preprocessors .java files into make/src and .test files 
> into hotspot/test.
>
> First, they are unit tests and not jtreg. Second, we did experiment 
> during AOT development with tests move but found that it is merge 
> (from graal-core) nightmare and tests execution problems.
>
> For now we want sources in JDK exactly match sources in 
> https://github.com/graalvm/graal-core
>
> Oracle Labs continue Graal development very actively and we want to be 
> in sync with them without big merge overhead.
>
> Thanks,
> Vladimir
>
> On 12/8/16 5:08 AM, Doug Simon wrote:
>>
>>> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> On 2016-12-07 23:10, Vladimir Kozlov wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>>
>>>> It is part of JEP 295: Ahead-of-Time Compilation
>>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>>
>>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>
>>> * In CompileJavaModules.gmk, there is an *extreme* list of excludes. 
>>> I note that most of them end in ".test". The proper solution to this 
>>> is to move the test code to the test/ directory instead of the src/ 
>>> directory. Also, four of them are the javac processor build tools. 
>>> These should move to make/src, as other build tools.
>>
>> Keeping like it is simplifies pulling changes from 
>> https://github.com/graalvm/graal-core. It's possible to write a more 
>> sophisticated tool for pulling changes in from the github and places 
>> the sources into more openjdk compatible locations. It's up to the 
>> HotSpot compiler team whether investing in such a tool makes sense.
>>
>>> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a 
>>> AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will 
>>> be garbled.
>>>
>>> * In hotspot.m4: The test to determine if we should set 
>>> INCLUDE_GRAAL is incorrect. It only tests for the default value, not 
>>> for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)).
>>>
>>> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), 
>>> true)" will never evaluate to true). But on the other hand, it is 
>>> not needed, and should just be removed. :-)
>>>
>>> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html 
>>> seems a bit dangling. Is this supposed to be included in some 
>>> Javadoc generation? The html file refers to a projects.jpg and 
>>> projects.html that does not exist. Maybe it should just be removed?
>>
>> I would recommend omitting all graal-core overview.html files in 
>> OpenJDK.
>>
>>> * Finally, just for the record, I too think the source should be 
>>> structured according to the OpenJDK praxis. (But I won't fight about 
>>> this.)
>>
>> -Doug
>>
>>>>
>>>> This is formal review request for integration Graal-core sources 
>>>> into OpenJDK. AOT compiler uses Graal-core as backend compiler. We 
>>>> need to integrated Graal-core sources into JDK and add build 
>>>> changes to build Graal module.
>>>>
>>>> Note, changes are based on latest jdk9/hs sources which do not have 
>>>> latest jigsaw update yet. With jigsaw update small changes will be 
>>>> done to module-info.java.extra in java.base:
>>>>
>>>>  exports jdk.internal.misc to jdk.vm.compiler;
>>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>>
>>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>>
>>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>>
>>>>
>>>>
>>>> Graal is a dynamic compiler written in Java that integrates with 
>>>> the HotSpot JVM. It has a focus on high performance and 
>>>> extensibility. In addition, it provides optimized performance for 
>>>> Truffle based languages running on the JVM.
>>>>
>>>> https://github.com/graalvm/graal-core
>>>>
>>>> Oracle Labs is developing and maintaining it.
>>>>
>>>> Here are people who contributed into Graal development (sorry if 
>>>> someone is missing or misspelled, please speak):
>>>>
>>>> ~70k LOC: Douglas Simon
>>>> ~60k LOC: Lukas Stadler
>>>> ~30k LOC: Thomas Wuerthinger
>>>> ~30k LOC: Tom Rodriguez
>>>> ~30k LOC: Roland Schatz
>>>> ~30k LOC: Josef Eisl
>>>> ~30k LOC: Christian Wimmer
>>>> ~16k LOC: Chris Thalinger
>>>> ~13k LOC: Gilles Duboscq
>>>> ~11k LOC: David Leopoldseder
>>>> ~ 8k LOC: Stefan Anzinger
>>>> ~ 8k LOC: Christian Humer
>>>>
>>>> Other contributors >100 LOC in approximate order of contribution size:
>>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos 
>>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, 
>>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, 
>>>> Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, 
>>>> Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth, 
>>>> Benoit Daloze.
>>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>
>>


From daniel.fuchs at oracle.com  Sat Dec 10 14:51:48 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 10 Dec 2016 14:51:48 +0000
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
In-Reply-To: <584B578A.1030508@oracle.com>
References: <584885AA.9060202@oracle.com>
	<53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>
	<584B578A.1030508@oracle.com>
Message-ID: <12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com>

Hi Brent,

This looks really good now!

best regards,

-- daniel

On 10/12/16 01:16, Brent Christian wrote:
> On 12/07/2016 04:05 PM, Mandy Chung wrote:
>>
>> I suggest to add two utility methods rather than the has method:
>>    boolean dropClassLoaderName()
>>    boolean dropModuleVersion()
>
> Done.
>
>>   430    if (m != null && m.isNamed() &&
>>   431          (isHashedInJavaBase(m) ||
>> !m.getDescriptor().version().isPresent())) {
>>   432        bits |= JDK_NON_UPGRADEABLE_MODULE;
>>   433    }
>>
>> I think this should simply be:
>>     if (isHashedInJavaBase(m)) {..}
>>
>
> Done.
>
>> Can you retain the javadoc of toLoaderModuleClassName, revised if
>> appropriate, in the computeFormat method?
>
> Updated.
>
>> line 322-325: what about:
>>
>> The toString method may return two different values on two
>> StackTraceElement instances that are equal for example when
>> one created via the constructor and one obtained from Throwable
>> or StackFrame where an implementation may choose to omit some
>> element in the returned string.
>
> That sounds good.
>
>> Is @apiNote in equals necessary?  Maybe the one added in toString is
>> adequate?
>
> I'm fine without it - removed.
>
>
> I also fixed test code for a case which only works with the images build.
>
> Updated webrev:
> http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/
>
> -Brent


From vladimir.kozlov at oracle.com  Sat Dec 10 18:07:32 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sat, 10 Dec 2016 10:07:32 -0800
Subject: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT
	compiler
In-Reply-To: <201e1454-22e4-22fd-0b43-36ffbc83e4d9@oracle.com>
References: <8507e841-13ce-2df4-6369-76bd427622eb@oracle.com>
	<957e584a-a283-bfda-2b75-1474bbcac7ae@oracle.com>
	<637554AA-0A53-4002-A1EA-78F10FCF88CB@oracle.com>
	<f67090f7-32c0-9448-a356-7c73de565f21@oracle.com>
	<201e1454-22e4-22fd-0b43-36ffbc83e4d9@oracle.com>
Message-ID: <eaf48f4a-6162-5948-0dd9-3cb71bbcdbbe@oracle.com>

Thank you, Erik

Vladimir

On 12/9/16 11:42 PM, Erik Joelsson wrote:
> This looks ok to me.
>
> /Erik
>
>
> On 2016-12-09 10:13, Vladimir Kozlov wrote:
>> Thank you, Magnus, for review.
>>
>> I updated webrevs with merge from latest jdk9/hs which now has Jigsaw
>> update.
>>
>> http://cr.openjdk.java.net/~kvn/8166417.v2/top.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417.v2/jdk.webrev/
>> http://cr.openjdk.java.net/~kvn/8166417.v2/hotspot.webrev/
>>
>> Removed hotspot/make/Tools.gmk
>>
>> Removed all overview.html files in graal sources.
>>
>> Fixed hotspot.m4 and changed condition in hotspot.m4 to build graal
>> only on linux-x64. The condition will be changed to check ENABLE_AOT
>> when merged with AOT changes later.
>>
>> Moved module-info.java.extra from share/classes to unix/classes per
>> Mandy suggestion since we will build graal only for AOT.
>>
>> I have to modify make/Javadoc.gmk to avoid next JPRT failure:
>>
>> javadoc: error - No source files for package
>> org.graalvm.compiler.api.collections.src.org.graalvm.compiler.api.collections
>>
>> make[3]: ***
>> [/scratch/opt/jprt/T/P1/232453.vkozlov/s/build/linux-x64/images/docs/api/index.html]
>> Error 1
>>
>> We did not generate docs for Graal before because its package was
>> com.oracle.graal. I think it is fine to not generate it now too.
>> Please, help if you think make/Javadoc.gmk should be fixed other way.
>>
>> By Mandy request changed code in
>> hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk to produce
>> module-info.java.extra with one `provides` clause of the same SPI like
>> next:
>>
>> provides org.graalvm.compiler.hotspot.CompilerConfigurationFactory with
>>     org.graalvm.compiler.hotspot.CoreCompilerConfigurationFactory,
>> org.graalvm.compiler.hotspot.EconomyCompilerConfigurationFactory,
>>     ;
>>
>>
>> About moving preprocessors .java files into make/src and .test files
>> into hotspot/test.
>>
>> First, they are unit tests and not jtreg. Second, we did experiment
>> during AOT development with tests move but found that it is merge
>> (from graal-core) nightmare and tests execution problems.
>>
>> For now we want sources in JDK exactly match sources in
>> https://github.com/graalvm/graal-core
>>
>> Oracle Labs continue Graal development very actively and we want to be
>> in sync with them without big merge overhead.
>>
>> Thanks,
>> Vladimir
>>
>> On 12/8/16 5:08 AM, Doug Simon wrote:
>>>
>>>> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>>
>>>> On 2016-12-07 23:10, Vladimir Kozlov wrote:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>>>
>>>>> It is part of JEP 295: Ahead-of-Time Compilation
>>>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>>>
>>>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>>
>>>> * In CompileJavaModules.gmk, there is an *extreme* list of excludes.
>>>> I note that most of them end in ".test". The proper solution to this
>>>> is to move the test code to the test/ directory instead of the src/
>>>> directory. Also, four of them are the javac processor build tools.
>>>> These should move to make/src, as other build tools.
>>>
>>> Keeping like it is simplifies pulling changes from
>>> https://github.com/graalvm/graal-core. It's possible to write a more
>>> sophisticated tool for pulling changes in from the github and places
>>> the sources into more openjdk compatible locations. It's up to the
>>> HotSpot compiler team whether investing in such a tool makes sense.
>>>
>>>> * In hotspot.m4: AC_MSG_CHECKING must always be matched by a
>>>> AC_MSG_RESULT, even before AC_MSG_ERROR, otherwise the output will
>>>> be garbled.
>>>>
>>>> * In hotspot.m4: The test to determine if we should set
>>>> INCLUDE_GRAAL is incorrect. It only tests for the default value, not
>>>> for the explicitely set (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)).
>>>>
>>>> * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT),
>>>> true)" will never evaluate to true). But on the other hand, it is
>>>> not needed, and should just be removed. :-)
>>>>
>>>> * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html
>>>> seems a bit dangling. Is this supposed to be included in some
>>>> Javadoc generation? The html file refers to a projects.jpg and
>>>> projects.html that does not exist. Maybe it should just be removed?
>>>
>>> I would recommend omitting all graal-core overview.html files in
>>> OpenJDK.
>>>
>>>> * Finally, just for the record, I too think the source should be
>>>> structured according to the OpenJDK praxis. (But I won't fight about
>>>> this.)
>>>
>>> -Doug
>>>
>>>>>
>>>>> This is formal review request for integration Graal-core sources
>>>>> into OpenJDK. AOT compiler uses Graal-core as backend compiler. We
>>>>> need to integrated Graal-core sources into JDK and add build
>>>>> changes to build Graal module.
>>>>>
>>>>> Note, changes are based on latest jdk9/hs sources which do not have
>>>>> latest jigsaw update yet. With jigsaw update small changes will be
>>>>> done to module-info.java.extra in java.base:
>>>>>
>>>>>  exports jdk.internal.misc to jdk.vm.compiler;
>>>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>>>
>>>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>>>
>>>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>>>
>>>>>
>>>>>
>>>>> Graal is a dynamic compiler written in Java that integrates with
>>>>> the HotSpot JVM. It has a focus on high performance and
>>>>> extensibility. In addition, it provides optimized performance for
>>>>> Truffle based languages running on the JVM.
>>>>>
>>>>> https://github.com/graalvm/graal-core
>>>>>
>>>>> Oracle Labs is developing and maintaining it.
>>>>>
>>>>> Here are people who contributed into Graal development (sorry if
>>>>> someone is missing or misspelled, please speak):
>>>>>
>>>>> ~70k LOC: Douglas Simon
>>>>> ~60k LOC: Lukas Stadler
>>>>> ~30k LOC: Thomas Wuerthinger
>>>>> ~30k LOC: Tom Rodriguez
>>>>> ~30k LOC: Roland Schatz
>>>>> ~30k LOC: Josef Eisl
>>>>> ~30k LOC: Christian Wimmer
>>>>> ~16k LOC: Chris Thalinger
>>>>> ~13k LOC: Gilles Duboscq
>>>>> ~11k LOC: David Leopoldseder
>>>>> ~ 8k LOC: Stefan Anzinger
>>>>> ~ 8k LOC: Christian Humer
>>>>>
>>>>> Other contributors >100 LOC in approximate order of contribution size:
>>>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>>>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>>>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein,
>>>>> Josef Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz,
>>>>> Jaroslav Tulach, Chris Seaton, Peter B. Kessler, Christian Wirth,
>>>>> Benoit Daloze.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>
>>>
>

From david.holmes at oracle.com  Sat Dec 10 22:14:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 11 Dec 2016 08:14:29 +1000
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
	<e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
	<2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>
Message-ID: <4ca4b79f-1da7-6f88-dce7-497ad98f18a3@oracle.com>

Updated webrev at:

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

Now checks fscanf ret code. Plus fixed 'else' formatting.

Thanks,
David
-----

+       int ret = fscanf(fp, JULONG_FORMAT, &cgroup_max);
+       if (ret == 1 && cgroup_max > 0) {
+         // If unlimited, cgroup_max will be a very large, but unspecified
+         // value, so use initial phys_mem as a limit
+         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
+                            JULONG_FORMAT "MB) and initial phys_mem ("
+                            JULONG_FORMAT "MB)", cgroup_max/M, phys_mem/M);
+         phys_mem = MIN2(cgroup_max, phys_mem);
+       } else {
+         warning("Unable to read/parse cgroup memory limit from %s: %s",
+                 lim_file, errno != 0 ? strerror(errno) : "unknown error");
+       }



On 10/12/2016 3:00 PM, Kim Barrett wrote:
>> On Dec 9, 2016, at 8:24 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> Thanks for looking at this.
>>
>> On 10/12/2016 10:22 AM, Kim Barrett wrote:
>>>> On Dec 8, 2016, at 9:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>>>
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev/
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 2050       fscanf(fp, JULONG_FORMAT, &cgroup_max);
>>> 2051       if (cgroup_max > 0) {
>>>
>>> Missing check of fscanf result.  I don't see anything in the doc for
>>> fscanf that promises an argument won't be clobbered if there are match
>>> failures, errors, or fewer inputs than specified in the format string.
>>> Even if that no such clobbering happens, as written we have a really
>>> rare failure mode -- in cgroup context, but inopportune EINTR -- that
>>> gets reported as a parse failure warning and ignoring the cgroup limit.
>>
>> Hmmm okay I was trying to keep it simple. I will check rc==0 as well, else give the warning, including reporting errno if non-zero.
>
> Okay.
>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 2054         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
>>>
>>> log_info seems a little noisy, especially considering that we
>>> ultimately announce the final ergonomic (Min|Max)HeapSize with
>>> log_trace.
>>
>> I figure if you want to use the cgroup limit then you want to clearly see the result of doing so. I don't think hiding that info at the lowest tracing level would be helpful to the user.
>
> That?s a good rationale.  Leave the logging as is.
>
>

From mandrikov at gmail.com  Sun Dec 11 21:58:11 2016
From: mandrikov at gmail.com (Evgeny Mandrikov)
Date: Sun, 11 Dec 2016 21:58:11 +0000
Subject: Why JDK-8157181 conditional in JDK 9 EA ?
Message-ID: <CAEPFu68f7SsPawFrEoB+OnaK9=ErBOZmtzKpMJPZyR2zju2jxg@mail.gmail.com>

Hi,

Rory O'Donnell gave me an advice [1] to provide our concerns about
JDK-8157181 [2] here. But excuse me if this is wrong place or too late.

In JaCoCo project [3] we accidentally discovered JDK-8157181 [2], which
revealed that we were generating bytecode that violates JVMLS [4]. What was
a bit surprising - is a conditional behavior of verifier based on bytecode
version. At a time of discovery we had no ability to compile into bytecode
version 9 given the state of tools in build stack (minifiers, verifiers,
etc) and had only ability to execute with JDK 9 EA. I guess that many
projects might relatively easily start testing 9 EA just as runtime
environment, while change of a target still might require bigger investment
as was the case for us. From there, I wonder why this logic was was not
made unconditional as was discussed in JDK-8157181 [2], especially in
presence of tickets for backporting [5]. Or maybe this happened, but we
just didn't noticed since bug on our side was fixed? The verification
itself is great and IMO might reveal bugs in tools that generate bytecode.

Best regards,
Evgeny Mandrikov

[1] https://groups.google.com/d/msg/jacoco-dev/sRXi8TD96js/w4T8DpffAwAJ
[2] https://bugs.openjdk.java.net/browse/JDK-8157181
[3] http://www.jacoco.org/jacoco/index.html
[4] https://github.com/jacoco/jacoco/pull/434
[5] https://bugs.openjdk.java.net/browse/JDK-8161987

From david.holmes at oracle.com  Sun Dec 11 22:28:08 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Dec 2016 08:28:08 +1000
Subject: Why JDK-8157181 conditional in JDK 9 EA ?
In-Reply-To: <CAEPFu68f7SsPawFrEoB+OnaK9=ErBOZmtzKpMJPZyR2zju2jxg@mail.gmail.com>
References: <CAEPFu68f7SsPawFrEoB+OnaK9=ErBOZmtzKpMJPZyR2zju2jxg@mail.gmail.com>
Message-ID: <4e3949a8-31f6-3c81-c0f9-a51dde8d8074@oracle.com>

Hi Evgeny,

On 12/12/2016 7:58 AM, Evgeny Mandrikov wrote:
> Hi,
>
> Rory O'Donnell gave me an advice [1] to provide our concerns about
> JDK-8157181 [2] here. But excuse me if this is wrong place or too late.
>
> In JaCoCo project [3] we accidentally discovered JDK-8157181 [2], which
> revealed that we were generating bytecode that violates JVMLS [4]. What was
> a bit surprising - is a conditional behavior of verifier based on bytecode
> version. At a time of discovery we had no ability to compile into bytecode
> version 9 given the state of tools in build stack (minifiers, verifiers,
> etc) and had only ability to execute with JDK 9 EA. I guess that many
> projects might relatively easily start testing 9 EA just as runtime
> environment, while change of a target still might require bigger investment
> as was the case for us. From there, I wonder why this logic was was not
> made unconditional as was discussed in JDK-8157181 [2], especially in
> presence of tickets for backporting [5]. Or maybe this happened, but we
> just didn't noticed since bug on our side was fixed? The verification
> itself is great and IMO might reveal bugs in tools that generate bytecode.

My comment in the bug report sums up the situation:

"If this is a long standing non-compliance with the JVMS then its impact 
can not be considered high. The longer the VM and spec do not match the 
more likely we adjust the spec to match the VM behaviour. When that is 
not feasible then the usual approach is to enforce the correct rules as 
of the current classfile version, otherwise we risk introducing 
compatibility issues. Even if we make the correct behaviour the default, 
we will usually provide a flag to enable the old behaviour for 
compatibility purposes. Only if this is a security concern would we 
force the change to the new behaviour. "

After much (mostly internal) discussion the compatibility argument won 
out. The backports exist to put in the change that causes the JIT to 
detect the "illegal" assignments and disable aggressive optimization of 
the final field.

Regards
David

> Best regards,
> Evgeny Mandrikov
>
> [1] https://groups.google.com/d/msg/jacoco-dev/sRXi8TD96js/w4T8DpffAwAJ
> [2] https://bugs.openjdk.java.net/browse/JDK-8157181
> [3] http://www.jacoco.org/jacoco/index.html
> [4] https://github.com/jacoco/jacoco/pull/434
> [5] https://bugs.openjdk.java.net/browse/JDK-8161987
>

From kim.barrett at oracle.com  Mon Dec 12 07:41:40 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 12 Dec 2016 02:41:40 -0500
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <4ca4b79f-1da7-6f88-dce7-497ad98f18a3@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
	<e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
	<2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>
	<4ca4b79f-1da7-6f88-dce7-497ad98f18a3@oracle.com>
Message-ID: <29067037-B2EE-4BD2-9C41-BAA12B10F78B@oracle.com>

> On Dec 10, 2016, at 5:14 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Updated webrev at:
> 
> http://cr.openjdk.java.net/~dholmes/8170888/webrev.v2/
> 
> Now checks fscanf ret code. Plus fixed 'else' formatting.
> 
> Thanks,
> David
> -----
> 
> +       int ret = fscanf(fp, JULONG_FORMAT, &cgroup_max);
> +       if (ret == 1 && cgroup_max > 0) {
> +         // If unlimited, cgroup_max will be a very large, but unspecified
> +         // value, so use initial phys_mem as a limit
> +         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
> +                            JULONG_FORMAT "MB) and initial phys_mem ("
> +                            JULONG_FORMAT "MB)", cgroup_max/M, phys_mem/M);
> +         phys_mem = MIN2(cgroup_max, phys_mem);
> +       } else {
> +         warning("Unable to read/parse cgroup memory limit from %s: %s",
> +                 lim_file, errno != 0 ? strerror(errno) : "unknown error");
> +       }
> 

Looks good.


From david.holmes at oracle.com  Mon Dec 12 08:37:49 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Dec 2016 18:37:49 +1000
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <29067037-B2EE-4BD2-9C41-BAA12B10F78B@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
	<e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
	<2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>
	<4ca4b79f-1da7-6f88-dce7-497ad98f18a3@oracle.com>
	<29067037-B2EE-4BD2-9C41-BAA12B10F78B@oracle.com>
Message-ID: <80a0eacc-2a82-0ca3-cfe3-7b2889f838a4@oracle.com>

Thanks Kim!

Just need Karen to re-affirm.

David

On 12/12/2016 5:41 PM, Kim Barrett wrote:
>> On Dec 10, 2016, at 5:14 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Updated webrev at:
>>
>> http://cr.openjdk.java.net/~dholmes/8170888/webrev.v2/
>>
>> Now checks fscanf ret code. Plus fixed 'else' formatting.
>>
>> Thanks,
>> David
>> -----
>>
>> +       int ret = fscanf(fp, JULONG_FORMAT, &cgroup_max);
>> +       if (ret == 1 && cgroup_max > 0) {
>> +         // If unlimited, cgroup_max will be a very large, but unspecified
>> +         // value, so use initial phys_mem as a limit
>> +         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
>> +                            JULONG_FORMAT "MB) and initial phys_mem ("
>> +                            JULONG_FORMAT "MB)", cgroup_max/M, phys_mem/M);
>> +         phys_mem = MIN2(cgroup_max, phys_mem);
>> +       } else {
>> +         warning("Unable to read/parse cgroup memory limit from %s: %s",
>> +                 lim_file, errno != 0 ? strerror(errno) : "unknown error");
>> +       }
>>
>
> Looks good.
>

From thomas.stuefe at gmail.com  Mon Dec 12 09:45:08 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 12 Dec 2016 10:45:08 +0100
Subject: RFR(XS): 8170919: LogStreamTest tests crash if they are run first
In-Reply-To: <584A6C74.1000901@oracle.com>
References: <6aeded4a-a4d1-c65c-ea61-e174e19cdc9f@oracle.com>
	<2e8e47b9-4923-ff5c-ab50-1d7a3761cf8b@oracle.com>
	<ff2a0b56-0650-96e7-0fae-6ad04f0b0602@oracle.com>
	<CAA-vtUw6HVi8-xN2PjY9-5BO3eTFvvQD2bvSXR6paO9k4JAy+g@mail.gmail.com>
	<584A6C74.1000901@oracle.com>
Message-ID: <CAA-vtUyphL6PGcvGG+6YCN8Zn=v4ogNoJw_m3ceFD25TjP-ZJw@mail.gmail.com>

Thank you Kirill!

Kind Regards, Thomas

On Fri, Dec 9, 2016 at 9:33 AM, Kirill Zhaldybin <
kirill.zhaldybin at oracle.com> wrote:

> Thomas,
>
> Thank you for noticing this!
>
> I filed JDK-8170976 for this issue.
> I think we should fix it but since we do not support running gtests with
> external flags I do not think it is a big issue for now.
>
> Regards, Kirill
>
> On 08.12.2016 18:09, Thomas St?fe wrote:
>
>> Hi,
>>
>> I wonder whether the test should use TEST_OTHER_VM?
>>
>> If I understand the coding in LogTestFixture correctly, it changes the
>> log configuration and does not restore it to its original value but to a
>> default state. So, logging would not be possible for follow up tests in
>> the same VM.
>>
>> So, test should either run in an own VM or LogTextFixture should
>> snapshot and restore the original log configuration.
>>
>> Kind Regards, Thomas
>>
>>
>> On Thu, Dec 8, 2016 at 3:41 PM, Kirill Zhaldybin
>> <kirill.zhaldybin at oracle.com <mailto:kirill.zhaldybin at oracle.com>> wrote:
>>
>>     Marcus,
>>
>>     Thank you for review!
>>
>>     Regards, Kirill
>>
>>     On 08.12.2016 17:08, Marcus Larsson wrote:
>>
>>         Hi,
>>
>>
>>         On 2016-12-08 14:32, Kirill Zhaldybin wrote:
>>
>>             Dear all,
>>
>>             Could you please review this fix for 8170919?
>>
>>             Since the tests use Resource Mark they should be run with
>>             TEST_VM not TEST.
>>
>>             WebRev:
>>             http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/web
>> rev.00/
>>             <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170919/we
>> brev.00/>
>>
>>
>>         Looks good.
>>
>>         Marcus
>>
>>             CR: https://bugs.openjdk.java.net/browse/JDK-8170919
>>             <https://bugs.openjdk.java.net/browse/JDK-8170919>
>>
>>             Thank you.
>>
>>             Regards, Kirill
>>
>>
>>
>>
>>
>

From kirill.zhaldybin at oracle.com  Mon Dec 12 13:27:49 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Mon, 12 Dec 2016 16:27:49 +0300
Subject: RFR(S): 8171090: Convert VMStruct_test to GTest
Message-ID: <f3d8548a-d25b-9256-4214-3c5fa36ff1f9@oracle.com>

Dear all,

Could you please review this fix for 8171090?

I added accessors to get arrays' lengths since they were defined in cpp 
file and separated the test into to two scenarios.

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

Thank you.

Regards, Kirill

From karen.kinnear at oracle.com  Mon Dec 12 16:00:21 2016
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 12 Dec 2016 11:00:21 -0500
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <80a0eacc-2a82-0ca3-cfe3-7b2889f838a4@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
	<e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
	<2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>
	<4ca4b79f-1da7-6f88-dce7-497ad98f18a3@oracle.com>
	<29067037-B2EE-4BD2-9C41-BAA12B10F78B@oracle.com>
	<80a0eacc-2a82-0ca3-cfe3-7b2889f838a4@oracle.com>
Message-ID: <660A6266-99C1-479E-BEDF-5BD1BFD6E3C7@oracle.com>

Ship it.

thank you David,
Karen

> On Dec 12, 2016, at 3:37 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Thanks Kim!
> 
> Just need Karen to re-affirm.
> 
> David
> 
> On 12/12/2016 5:41 PM, Kim Barrett wrote:
>>> On Dec 10, 2016, at 5:14 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Updated webrev at:
>>> 
>>> http://cr.openjdk.java.net/~dholmes/8170888/webrev.v2/
>>> 
>>> Now checks fscanf ret code. Plus fixed 'else' formatting.
>>> 
>>> Thanks,
>>> David
>>> -----
>>> 
>>> +       int ret = fscanf(fp, JULONG_FORMAT, &cgroup_max);
>>> +       if (ret == 1 && cgroup_max > 0) {
>>> +         // If unlimited, cgroup_max will be a very large, but unspecified
>>> +         // value, so use initial phys_mem as a limit
>>> +         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
>>> +                            JULONG_FORMAT "MB) and initial phys_mem ("
>>> +                            JULONG_FORMAT "MB)", cgroup_max/M, phys_mem/M);
>>> +         phys_mem = MIN2(cgroup_max, phys_mem);
>>> +       } else {
>>> +         warning("Unable to read/parse cgroup memory limit from %s: %s",
>>> +                 lim_file, errno != 0 ? strerror(errno) : "unknown error");
>>> +       }
>>> 
>> 
>> Looks good.
>> 


From kirill.zhaldybin at oracle.com  Mon Dec 12 16:31:10 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Mon, 12 Dec 2016 19:31:10 +0300
Subject: RFR(XS): 8171097: Convert TestReservedSpace_test to Gtest
Message-ID: <281bd401-30a9-9142-bfc2-fb5cf11d52bd@oracle.com>

Dear all,

Could you please review this fix for 8171097?

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

Thank you.

Regards, Kirill

From david.holmes at oracle.com  Mon Dec 12 20:14:43 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Dec 2016 06:14:43 +1000
Subject: RFR: 8170888: [linux] Experimental support for cgroup memory
	limits in container (ie Docker) environments
In-Reply-To: <660A6266-99C1-479E-BEDF-5BD1BFD6E3C7@oracle.com>
References: <410b9f2b-be8f-d2a7-2610-dd3a76a47c30@oracle.com>
	<F8631003-BFBF-49F0-8275-E944A1561FFA@oracle.com>
	<e8046420-466c-0e57-c18f-e661846847c7@oracle.com>
	<2AC7BDC9-30CD-41CD-86B2-EBF5337E5F71@oracle.com>
	<4ca4b79f-1da7-6f88-dce7-497ad98f18a3@oracle.com>
	<29067037-B2EE-4BD2-9C41-BAA12B10F78B@oracle.com>
	<80a0eacc-2a82-0ca3-cfe3-7b2889f838a4@oracle.com>
	<660A6266-99C1-479E-BEDF-5BD1BFD6E3C7@oracle.com>
Message-ID: <5dd57d78-e97b-f8e0-25cc-782f9fd50885@oracle.com>

Thanks Karen!

David

On 13/12/2016 2:00 AM, Karen Kinnear wrote:
> Ship it.
>
> thank you David,
> Karen
>
>> On Dec 12, 2016, at 3:37 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Thanks Kim!
>>
>> Just need Karen to re-affirm.
>>
>> David
>>
>> On 12/12/2016 5:41 PM, Kim Barrett wrote:
>>>> On Dec 10, 2016, at 5:14 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Updated webrev at:
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8170888/webrev.v2/
>>>>
>>>> Now checks fscanf ret code. Plus fixed 'else' formatting.
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>> +       int ret = fscanf(fp, JULONG_FORMAT, &cgroup_max);
>>>> +       if (ret == 1 && cgroup_max > 0) {
>>>> +         // If unlimited, cgroup_max will be a very large, but unspecified
>>>> +         // value, so use initial phys_mem as a limit
>>>> +         log_info(gc, heap)("Setting phys_mem to the min of cgroup limit ("
>>>> +                            JULONG_FORMAT "MB) and initial phys_mem ("
>>>> +                            JULONG_FORMAT "MB)", cgroup_max/M, phys_mem/M);
>>>> +         phys_mem = MIN2(cgroup_max, phys_mem);
>>>> +       } else {
>>>> +         warning("Unable to read/parse cgroup memory limit from %s: %s",
>>>> +                 lim_file, errno != 0 ? strerror(errno) : "unknown error");
>>>> +       }
>>>>
>>>
>>> Looks good.
>>>
>

From gromero at linux.vnet.ibm.com  Mon Dec 12 21:50:45 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 12 Dec 2016 19:50:45 -0200
Subject: RTM/HTM jtreg test regression
Message-ID: <584F1BB5.4020907@linux.vnet.ibm.com>

Hi,

After 8160851 [1] removed the -XaddExports option it deprecated the use of
-XaddExports in the RTM jtreg tests introduced in 8164987 [2].

As a consequence all tests on POWER8 (and possible on x64 with RTM support)
under compiler/rtm/locking/* are failing as reported in [2].

The following simple change is proposed to fix that issue:

diff -r 91ef517cb13e test/compiler/testlibrary/rtm/RTMTestBase.java
--- a/test/compiler/testlibrary/rtm/RTMTestBase.java    Mon Dec 12 21:18:54 2016 +0300
+++ b/test/compiler/testlibrary/rtm/RTMTestBase.java    Mon Dec 12 16:42:27 2016 -0500
@@ -241,7 +241,7 @@
                 CommandLineOptionTest.UNLOCK_DIAGNOSTIC_VM_OPTIONS,
                 CommandLineOptionTest.UNLOCK_EXPERIMENTAL_VM_OPTIONS,
                 "-Xbootclasspath/a:.", "-XX:+WhiteBoxAPI",
-                "-XaddExports:java.base/jdk.internal.misc=ALL-UNNAMED");
+                "--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED");

         if (test != null) {
             for (String method : test.getMethodsToCompileNames()) {


Could I open a bug to fix that on 9?

Thank you.


Regards,
Gustavo

[1] https://bugs.openjdk.java.net/browse/JDK-8160851
[2] https://bugs.openjdk.java.net/browse/JDK-8164987


From david.holmes at oracle.com  Tue Dec 13 04:41:37 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Dec 2016 14:41:37 +1000
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
Message-ID: <308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>

Okay here's the updated webrev complete with nice logging:

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

The stack size will be the smaller of the rlimit stack and the 
-Xss/ThreadStackSize value. If the rlimit stack is unlimited and 
ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you 
can now get whatever primordial thread stack size you want by using 
ulimit and -Xss appropriately.

Thanks,
David

On 3/12/2016 2:11 PM, David Holmes wrote:
> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>> On 12/1/16 10:51 PM, David Holmes wrote:
>>> Investigating this further the history is quite complex, especially
>>> when we start looking at other platforms. E.g. see
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>
>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>
>>> I'm very tempted to do the same on Linux.
>>
>> Vote: yes
>
> Excellent! Other votes?
>
>> This latest problem only comes up with -XX:ThreadStackSize=0 when the
>> stack is unlimited right?
>
> Right.
>
>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>> 8MB or the ulimit a viable option?
>
> I think so.
>
>> Also, it looks like Hui had some things to say about not setting the
>> red/yellow zone pages on the primordial thread when we aren't using the
>> 'java' launcher because we don't know the environment of the code that
>> is using the JNI invocation API...
>
> Yeah but those comments seem a bit confused to me. They suggest we
> shouldn't add guard pages but in fact we do add guard pages. And to me
> it is no different in the primordial thread than any other natively
> attached thread ie why should the initially attached thread be treated
> differently to any other?** I suspect if I keep researching on this I
> will find bugs regarding such differences in behaviour (eg the fact that
> -Xss wasn't working on the main thread).
>
> ** There are arguments both ways as to how natively attached threads
> should behave. The main argument against guard page insertion is that we
> don't know how far down the existing stack we actually are - we could be
> past the depth where the guard page would be inserted! The main argument
> for (which seems to have won the day) is so that we don't get arbitrary
> differences in behaviour between threads created and attached by
> application native code; and threads created direct from application
> Java code.
>
> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
> solution - assuming it addresses the needs of the folk that ran into
> this problem.
>
> Thanks,
> David
>
>> Dan
>>
>>
>>>
>>> David
>>> -----
>>>
>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes <david.holmes at oracle.com
>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>
>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>
>>>>>         I just realized I overlooked the case where ThreadStackSize=0
>>>>>         and the
>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>> guard
>>>>>         pages
>>>>>         will get inserted - I do know that I don't get a stackoverflow
>>>>>         error.
>>>>>
>>>>>         This needs further investigation.
>>>>>
>>>>>
>>>>>     So what happens here is that the massive stack-size causes
>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>     guard-page goodness knows where, and we can consume the current
>>>>>     stack until such time as we hit an unmapped or protected region at
>>>>>     which point we are killed.
>>>>>
>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>> case we
>>>>>     should not attempt to create a guard page in the initial thread.
>>>>>     That would require using a sentinel value for the stack-size.
>>>>> Though
>>>>>     it also presents a problem for stack-bottom - which is implicitly
>>>>>     zero. It may also give false positives in the is_initial_thread()
>>>>> check!
>>>>>
>>>>>     Thoughts? Suggestions?
>>>>>
>>>>>
>>>>> Maybe I am overlooking something, but should
>>>>> os::capture_initial_thread() not call pthread_getattr_np() first to
>>>>> handle the case where the VM was created on a pthread which is not the
>>>>> primordial thread and may have a different stack size than what
>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>> pthread_getattr_np() fails?
>>>>
>>>> My understanding of the problem (which likely no longer exists) is that
>>>> pthread_getattr_np didn't fail as such but returned bogus values - so
>>>> the problem was not detectable and so we just had to not use
>>>> pthread_getattr_np.
>>>>
>>>>> And then we also should handle
>>>>> RLIM_INFINITY. For that case, I also think not setting guard pages
>>>>> would
>>>>> be safest.
>>>>>
>>>>> We also may just refuse to run in that case, because the workaround
>>>>> for
>>>>> the user is easy - just set the limit before process start. Note
>>>>> that on
>>>>> AIX, we currently refuse to run on the primordial thread because it
>>>>> may
>>>>> have different page sizes than pthreads and it is impossible to get
>>>>> the
>>>>> exact stack locations.
>>>>
>>>> I was wondering why the AIX set up seemed so simple in comparison :)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>         David
>>>>>
>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>
>>>>>             Hi Thomas,
>>>>>
>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>
>>>>>                 Hi David,
>>>>>
>>>>>                 thanks for the good explanation. Change looks good, I
>>>>>                 really like the
>>>>>                 comment in capture_initial_stack().
>>>>>
>>>>>                 Question, with -Xss given and being smaller than
>>>>> current
>>>>>                 thread stack
>>>>>                 size, guard pages may appear in the middle of the
>>>>>                 invoking thread stack?
>>>>>                 I always thought this is a bit dangerous. If your
>>>>> model
>>>>>                 is to have the
>>>>>                 VM created from the main thread, which then goes
>>>>> off to
>>>>>                 do different
>>>>>                 things, and have other threads then attach and run
>>>>> java
>>>>>                 code, main
>>>>>                 thread later may crash in unrelated native code just
>>>>>                 because it reached
>>>>>                 the stack depth of the hava threads? Or am I
>>>>>                 misunderstanding something?
>>>>>
>>>>>
>>>>>             There is no change to the general behaviour other than
>>>>>             allowing a
>>>>>             primordial process thread that launches the VM, to now not
>>>>>             have an
>>>>>             effective stack limited at 2MB. The current logic will
>>>>>             insert guard
>>>>>             pages where ever -Xss states (as long as less than 2MB
>>>>> else
>>>>>             2MB), while
>>>>>             with the fix the guard pages will be inserted above 2MB
>>>>> - as
>>>>>             dictated by
>>>>>             -Xss.
>>>>>
>>>>>             David
>>>>>             -----
>>>>>
>>>>>                 Thanks, Thomas
>>>>>
>>>>>
>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>                 <david.holmes at oracle.com
>>>>> <mailto:david.holmes at oracle.com>
>>>>>                 <mailto:david.holmes at oracle.com
>>>>>                 <mailto:david.holmes at oracle.com>>> wrote:
>>>>>
>>>>>                     Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>
>>>>>                     The bug is not public unfortunately for
>>>>>                 non-technical reasons - but
>>>>>                     see my eval below.
>>>>>
>>>>>                     Background: if you load the JVM from the
>>>>> primordial
>>>>>                 thread of a
>>>>>                     process (not done by the java launcher since JDK
>>>>> 6),
>>>>>                 there is an
>>>>>                     artificial stack limit imposed on the initial
>>>>> thread
>>>>>                 (by sticking
>>>>>                     the guard page at the limit position of the actual
>>>>>                 stack) of the
>>>>>                     minimum of the -Xss setting and 2M. So if you set
>>>>>                 -Xss to > 2M it is
>>>>>                     ignored for the main thread even if the true stack
>>>>>                 is, say, 8M. This
>>>>>                     limitation dates back 10-15 years and is no longer
>>>>>                 relevant today
>>>>>                     and should be removed (see below). I've also added
>>>>>                 additional
>>>>>                     explanatory notes.
>>>>>
>>>>>                     webrev:
>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>
>>>>>                     Testing was manually done by modifying the
>>>>> launcher
>>>>>                 to not run the
>>>>>                     VM in a new thread, and checking the resulting
>>>>> stack
>>>>>                 size used.
>>>>>
>>>>>                     This change will only affect hosted JVMs launched
>>>>>                 with a -Xss value
>>>>>                     > 2M.
>>>>>
>>>>>                     Thanks,
>>>>>                     David
>>>>>                     -----
>>>>>
>>>>>                     Bug eval:
>>>>>
>>>>>                     JDK-4441425 limits the stack to 8M as a safeguard
>>>>>                 against an
>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>> further
>>>>>                 constrained
>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>
>>>>>                     By 1.4.2 we have the basic form of the current
>>>>>                 problematic code:
>>>>>
>>>>>                     #ifndef IA64
>>>>>                       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur =
>>>>> 2 *
>>>>>                 K * K;
>>>>>                     #else
>>>>>                       // Problem still exists RH7.2 (IA64 anyway) but
>>>>>                 2MB is a little
>>>>>                 small
>>>>>                       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur =
>>>>> 4 *
>>>>>                 K * K;
>>>>>                     #endif
>>>>>
>>>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>>>                 ~(page_size() - 1);
>>>>>
>>>>>                       if (max_size && _initial_thread_stack_size >
>>>>>                 max_size) {
>>>>>                          _initial_thread_stack_size = max_size;
>>>>>                       }
>>>>>
>>>>>                     This was added by JDK-4678676 to allow the
>>>>> stack of
>>>>>                 the main thread
>>>>>                     to be _reduced_ below the default 2M/4M if the
>>>>> -Xss
>>>>>                 value was
>>>>>                     smaller than that.** There was no intent to allow
>>>>>                 the stack size to
>>>>>                     follow -Xss arbitrarily due to the operational
>>>>>                 constraints imposed
>>>>>                     by the OS/glibc at the time when dealing with the
>>>>>                 primordial process
>>>>>                     thread.
>>>>>
>>>>>                     ** It could not actually change the actual stack
>>>>>                 size of course, but
>>>>>                     set the guard pages to limit use to the expected
>>>>>                 stack size.
>>>>>
>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>                 changed to create the
>>>>>                     JVM in a new thread, so that it was not limited by
>>>>> the
>>>>>                     idiosyncracies of the OS or thread library
>>>>>                 primordial thread
>>>>>                     handling. However, the stack size limitations
>>>>>                 remained in place in
>>>>>                     case the VM was launched from the primordial
>>>>> thread
>>>>>                 of a user
>>>>>                     application via the JNI invocation API.
>>>>>
>>>>>                     I believe it should be safe to remove the 2M
>>>>>                 limitation now.
>>>>>
>>>>>
>>>>>
>>

From sgehwolf at redhat.com  Tue Dec 13 09:38:21 2016
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 13 Dec 2016 10:38:21 +0100
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
References: <1481115437.3024.9.camel@redhat.com>
	<54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
Message-ID: <1481621901.2892.3.camel@redhat.com>

On Wed, 2016-12-07 at 22:58 -0500, Coleen Phillimore wrote:
> This looks good and I can sponsor this for you.??I haven't built Zero in?
> a while.

Hi Coleen,

Is it OK for me to push this change? I'm not entirely clear on which
changes need to go through JPRT. In theory I should be able to push
this change with my new committer powers ;-)

Thanks,
Severin

> On 12/7/16 7:57 AM, Severin Gehwolf wrote:
> > 
> > Hi,
> > 
> > Could somebody please review this Zero only change? The problem was
> > there before, but only the fix for JDK-8169711 brought it to the
> > surface. The returned method kind for
> > java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
> > in abstractInterpreter.cpp
> > 
> > The fix is to generate stub entries for
> > java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?
> > 
> > bug: https://bugs.openjdk.java.net/browse/JDK-8170767
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/webrev.01/
> > 
> > Thanks,
> > Severin
> 


From jesper.wilhelmsson at oracle.com  Tue Dec 13 10:50:37 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2016 11:50:37 +0100
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <1481621901.2892.3.camel@redhat.com>
References: <1481115437.3024.9.camel@redhat.com>
	<54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
	<1481621901.2892.3.camel@redhat.com>
Message-ID: <e5cd8067-d74b-f1a1-ec55-7d2217df3683@oracle.com>

This is a change in shared VM code. It should go through jprt.

(Please do not interpret this mail as an approval to push. jdk9/hs is still closed.)
/Jesper

Den 13/12/16 kl. 10:38, skrev Severin Gehwolf:
> On Wed, 2016-12-07 at 22:58 -0500, Coleen Phillimore wrote:
>> This looks good and I can sponsor this for you.  I haven't built Zero in
>> a while.
>
> Hi Coleen,
>
> Is it OK for me to push this change? I'm not entirely clear on which
> changes need to go through JPRT. In theory I should be able to push
> this change with my new committer powers ;-)
>
> Thanks,
> Severin
>
>> On 12/7/16 7:57 AM, Severin Gehwolf wrote:
>>>
>>> Hi,
>>>
>>> Could somebody please review this Zero only change? The problem was
>>> there before, but only the fix for JDK-8169711 brought it to the
>>> surface. The returned method kind for
>>> java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
>>> in abstractInterpreter.cpp
>>>
>>> The fix is to generate stub entries for
>>> java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170767
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/webrev.01/
>>>
>>> Thanks,
>>> Severin
>>
>

From sgehwolf at redhat.com  Tue Dec 13 11:02:27 2016
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 13 Dec 2016 12:02:27 +0100
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <e5cd8067-d74b-f1a1-ec55-7d2217df3683@oracle.com>
References: <1481115437.3024.9.camel@redhat.com>
	<54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
	<1481621901.2892.3.camel@redhat.com>
	<e5cd8067-d74b-f1a1-ec55-7d2217df3683@oracle.com>
Message-ID: <1481626947.2892.10.camel@redhat.com>

On Tue, 2016-12-13 at 11:50 +0100, Jesper Wilhelmsson wrote:
> This is a change in shared VM code. It should go through jprt.
> 
> (Please do not interpret this mail as an approval to push. jdk9/hs is
> still closed.)

OK, thanks!

Cheers,
Severin

> /Jesper
> 
> Den 13/12/16 kl. 10:38, skrev Severin Gehwolf:
> > 
> > On Wed, 2016-12-07 at 22:58 -0500, Coleen Phillimore wrote:
> > > 
> > > This looks good and I can sponsor this for you.??I haven't built
> > > Zero in
> > > a while.
> > 
> > Hi Coleen,
> > 
> > Is it OK for me to push this change? I'm not entirely clear on
> > which
> > changes need to go through JPRT. In theory I should be able to push
> > this change with my new committer powers ;-)
> > 
> > Thanks,
> > Severin
> > 
> > > 
> > > On 12/7/16 7:57 AM, Severin Gehwolf wrote:
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Could somebody please review this Zero only change? The problem
> > > > was
> > > > there before, but only the fix for JDK-8169711 brought it to
> > > > the
> > > > surface. The returned method kind for
> > > > java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by
> > > > UseFMA
> > > > in abstractInterpreter.cpp
> > > > 
> > > > The fix is to generate stub entries for
> > > > java_lang_math_fmaD/java_lang_math_fmaF which were missing.
> > > > Thoughts?
> > > > 
> > > > bug: https://bugs.openjdk.java.net/browse/JDK-8170767
> > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-817076
> > > > 7/webrev.01/
> > > > 
> > > > Thanks,
> > > > Severin
> > > 
> > 


From zoltan.majo at oracle.com  Tue Dec 13 11:35:35 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Tue, 13 Dec 2016 12:35:35 +0100
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
Message-ID: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>

Hi,


please review the fix for 8171155.

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

The JVM assumes the field it's looking for always exists. As a result, 
the JVM processes uninitialized data if the field does not exists, which 
results in a crash. The suggested fix is to check if the field exists 
before processing it. Please find more details in the bug description.

I found the bug while JPRT-testing the 8u-backport of

8157181: Compilers accept modification of final fields outside 
initializer methods

I was not able to reproduce the issue with 9, but (judging from the 
code) JDK 9 is likely to be affected as well. So I'd prefer to fix this 
problem in JDK 9 as well (and then backport the fix to 8u) instead of 
pushing the fix only into 8u.

Thank you!

Best regards,


Zoltan


From magnus.ihse.bursie at oracle.com  Tue Dec 13 12:48:33 2016
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 13 Dec 2016 13:48:33 +0100
Subject: RFR: JDK-8171163 Merge 9de6a70d5d81 broke test/Makefile
Message-ID: <11ac55dc-63b8-2c72-e5c0-f0e2fd539bf8@oracle.com>

The merge 9de6a70d5d81 (in jdk9/hs) reintroduced code that was deleted 
in JDK-8170629.

The result of this is that the target jtreg_tests is declared two times, 
which causes make to protest.

Note that the broken merge is in jdk9/hs, so this is where the fix needs 
to go.

Bug: https://bugs.openjdk.java.net/browse/JDK-8171163
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8171163-borked-merge-on-test-Makefile/webrev.01

/Magnus

From stanislav.smirnov at oracle.com  Tue Dec 13 12:53:30 2016
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Tue, 13 Dec 2016 15:53:30 +0300
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
In-Reply-To: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
References: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
Message-ID: <506170D1-9CEF-4DF8-936A-AA58B4546F7D@oracle.com>

Hi Zoltan,

changes look good, although I am not a reviewer.

Best regards,
Stanislav Smirnov





> On 13 Dec 2016, at 14:35, Zolt?n Maj? <zoltan.majo at oracle.com> wrote:
> 
> Hi,
> 
> 
> please review the fix for 8171155.
> 
> https://bugs.openjdk.java.net/browse/JDK-8171155
> http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/
> 
> The JVM assumes the field it's looking for always exists. As a result, the JVM processes uninitialized data if the field does not exists, which results in a crash. The suggested fix is to check if the field exists before processing it. Please find more details in the bug description.
> 
> I found the bug while JPRT-testing the 8u-backport of
> 
> 8157181: Compilers accept modification of final fields outside initializer methods
> 
> I was not able to reproduce the issue with 9, but (judging from the code) JDK 9 is likely to be affected as well. So I'd prefer to fix this problem in JDK 9 as well (and then backport the fix to 8u) instead of pushing the fix only into 8u.
> 
> Thank you!
> 
> Best regards,
> 
> 
> Zoltan
> 


From erik.joelsson at oracle.com  Tue Dec 13 12:59:01 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 13 Dec 2016 13:59:01 +0100
Subject: RFR: JDK-8171163 Merge 9de6a70d5d81 broke test/Makefile
In-Reply-To: <11ac55dc-63b8-2c72-e5c0-f0e2fd539bf8@oracle.com>
References: <11ac55dc-63b8-2c72-e5c0-f0e2fd539bf8@oracle.com>
Message-ID: <90158cfe-1eb5-c7c5-ef6d-458295368fb7@oracle.com>

Looks good.

/Erik


On 2016-12-13 13:48, Magnus Ihse Bursie wrote:
> The merge 9de6a70d5d81 (in jdk9/hs) reintroduced code that was deleted 
> in JDK-8170629.
>
> The result of this is that the target jtreg_tests is declared two 
> times, which causes make to protest.
>
> Note that the broken merge is in jdk9/hs, so this is where the fix 
> needs to go.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171163
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8171163-borked-merge-on-test-Makefile/webrev.01
>
> /Magnus


From zoltan.majo at oracle.com  Tue Dec 13 13:08:23 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Tue, 13 Dec 2016 14:08:23 +0100
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
In-Reply-To: <506170D1-9CEF-4DF8-936A-AA58B4546F7D@oracle.com>
References: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
	<506170D1-9CEF-4DF8-936A-AA58B4546F7D@oracle.com>
Message-ID: <74d34214-e163-7751-7d2c-2b9963216103@oracle.com>

Thank you, Stas, for the review!

Best regards,


Zoltan


On 12/13/2016 01:53 PM, Stanislav Smirnov wrote:
> Hi Zoltan,
>
> changes look good, although I am not a reviewer.
>
> Best regards,
> Stanislav Smirnov
>
>
>
>
>
>> On 13 Dec 2016, at 14:35, Zolt?n Maj? <zoltan.majo at oracle.com 
>> <mailto:zoltan.majo at oracle.com>> wrote:
>>
>> Hi,
>>
>>
>> please review the fix for 8171155.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8171155
>> http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/
>>
>> The JVM assumes the field it's looking for always exists. As a 
>> result, the JVM processes uninitialized data if the field does not 
>> exists, which results in a crash. The suggested fix is to check if 
>> the field exists before processing it. Please find more details in 
>> the bug description.
>>
>> I found the bug while JPRT-testing the 8u-backport of
>>
>> 8157181: Compilers accept modification of final fields outside 
>> initializer methods
>>
>> I was not able to reproduce the issue with 9, but (judging from the 
>> code) JDK 9 is likely to be affected as well. So I'd prefer to fix 
>> this problem in JDK 9 as well (and then backport the fix to 8u) 
>> instead of pushing the fix only into 8u.
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>


From goetz.lindenmaier at sap.com  Tue Dec 13 13:19:02 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 13 Dec 2016 13:19:02 +0000
Subject: RTM/HTM jtreg test regression
In-Reply-To: <584F1BB5.4020907@linux.vnet.ibm.com>
References: <584F1BB5.4020907@linux.vnet.ibm.com>
Message-ID: <776b57b646a04f96a69357d7ddb8eb31@DEROTE13DE08.global.corp.sap>

Hi Gustave, 

Yes, this seems necessary.

Best regards,
  Goetz

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
> Of Gustavo Romero
> Sent: Montag, 12. Dezember 2016 22:51
> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
> Subject: RTM/HTM jtreg test regression
> 
> Hi,
> 
> After 8160851 [1] removed the -XaddExports option it deprecated the use of
> -XaddExports in the RTM jtreg tests introduced in 8164987 [2].
> 
> As a consequence all tests on POWER8 (and possible on x64 with RTM support)
> under compiler/rtm/locking/* are failing as reported in [2].
> 
> The following simple change is proposed to fix that issue:
> 
> diff -r 91ef517cb13e test/compiler/testlibrary/rtm/RTMTestBase.java
> --- a/test/compiler/testlibrary/rtm/RTMTestBase.java    Mon Dec 12 21:18:54
> 2016 +0300
> +++ b/test/compiler/testlibrary/rtm/RTMTestBase.java    Mon Dec 12 16:42:27
> 2016 -0500
> @@ -241,7 +241,7 @@
>                  CommandLineOptionTest.UNLOCK_DIAGNOSTIC_VM_OPTIONS,
>                  CommandLineOptionTest.UNLOCK_EXPERIMENTAL_VM_OPTIONS,
>                  "-Xbootclasspath/a:.", "-XX:+WhiteBoxAPI",
> -                "-XaddExports:java.base/jdk.internal.misc=ALL-UNNAMED");
> +                "--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED");
> 
>          if (test != null) {
>              for (String method : test.getMethodsToCompileNames()) {
> 
> 
> Could I open a bug to fix that on 9?
> 
> Thank you.
> 
> 
> Regards,
> Gustavo
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8160851
> [2] https://bugs.openjdk.java.net/browse/JDK-8164987


From vladimir.x.ivanov at oracle.com  Tue Dec 13 13:47:28 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 13 Dec 2016 16:47:28 +0300
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
In-Reply-To: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
References: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
Message-ID: <feed87a3-3d38-4bc3-2a69-45d6d7a20719@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 12/13/16 2:35 PM, Zolt?n Maj? wrote:
> Hi,
>
>
> please review the fix for 8171155.
>
> https://bugs.openjdk.java.net/browse/JDK-8171155
> http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/
>
> The JVM assumes the field it's looking for always exists. As a result,
> the JVM processes uninitialized data if the field does not exists, which
> results in a crash. The suggested fix is to check if the field exists
> before processing it. Please find more details in the bug description.
>
> I found the bug while JPRT-testing the 8u-backport of
>
> 8157181: Compilers accept modification of final fields outside
> initializer methods
>
> I was not able to reproduce the issue with 9, but (judging from the
> code) JDK 9 is likely to be affected as well. So I'd prefer to fix this
> problem in JDK 9 as well (and then backport the fix to 8u) instead of
> pushing the fix only into 8u.
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>

From thomas.stuefe at gmail.com  Tue Dec 13 13:52:32 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 13 Dec 2016 14:52:32 +0100
Subject: 32bit windows VM cannot be started with 1GB heap?
Message-ID: <CAA-vtUzRvXLueGHorVVbRLAMqPFxU=Yq40H72H6V9_sriSURmA@mail.gmail.com>

Hi all,

I try to build a 32bit VM (from the jdk9/hs repository) on Windows.

The build fails when it tries to run the freshly built VM during the build:

/cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/configure-support/bin/fixpath.exe
-c /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/jdk/bin/java -Xms64M
-Xmx1024M -XX:ThreadStackSize=768 -esa -ea -cp
/cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/buildtools/tools_jigsaw_classes
--add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED
build.tools.jigsaw.ModuleSummary -o
/cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/images/gengraphs/module-summary.html
--module-path /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/images/jmods
Error occurred during initialization of VM
Could not reserve enough space for 1048576KB object heap

Basically, the VM under <output>/jdk cannot be started with 1GB heap. I
assume the same would be true for the build result VM, but cannot verify
this as the build does not finish.

Drilling down I found that when trying to allocate the java heap,
VirtualAlloc fails with ERROR_NOT_ENOUGH_MEMORY.

Drilling further down I found - when looking at the address space with
VMMap - that there is indeed no adress space hole large enough to hold 1GB.
But no culprit stands out immediately.

Does anyone else experience similar problems? Would it be ok to reduce the
-Xmx setting for the 32bit build on windows?

Thank you, Thomas

From zoltan.majo at oracle.com  Tue Dec 13 14:02:37 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Tue, 13 Dec 2016 15:02:37 +0100
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
In-Reply-To: <feed87a3-3d38-4bc3-2a69-45d6d7a20719@oracle.com>
References: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
	<feed87a3-3d38-4bc3-2a69-45d6d7a20719@oracle.com>
Message-ID: <105ca6c3-9274-7797-a3a6-8b7de08a5938@oracle.com>

Thank you, Vladimir, for the review!

Best regards,


Zoltan

On 12/13/2016 02:47 PM, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 12/13/16 2:35 PM, Zolt?n Maj? wrote:
>> Hi,
>>
>>
>> please review the fix for 8171155.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8171155
>> http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/
>>
>> The JVM assumes the field it's looking for always exists. As a result,
>> the JVM processes uninitialized data if the field does not exists, which
>> results in a crash. The suggested fix is to check if the field exists
>> before processing it. Please find more details in the bug description.
>>
>> I found the bug while JPRT-testing the 8u-backport of
>>
>> 8157181: Compilers accept modification of final fields outside
>> initializer methods
>>
>> I was not able to reproduce the issue with 9, but (judging from the
>> code) JDK 9 is likely to be affected as well. So I'd prefer to fix this
>> problem in JDK 9 as well (and then backport the fix to 8u) instead of
>> pushing the fix only into 8u.
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>


From claes.redestad at oracle.com  Tue Dec 13 14:28:45 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 13 Dec 2016 15:28:45 +0100
Subject: 32bit windows VM cannot be started with 1GB heap?
In-Reply-To: <CAA-vtUzRvXLueGHorVVbRLAMqPFxU=Yq40H72H6V9_sriSURmA@mail.gmail.com>
References: <CAA-vtUzRvXLueGHorVVbRLAMqPFxU=Yq40H72H6V9_sriSURmA@mail.gmail.com>
Message-ID: <51c2e8f5-7e12-3406-d4f9-91093c9e69d0@oracle.com>

Hi Thomas,

do you configure the build with the client or server VM?

The former is not going to be supported by Oracle in JDK 9 and the 
latter is
known to have issues with allocating too many threads and using too much
memory for code cache etc on large machines, effectively starving the
available space for the java heap.

A solution to this is actively being worked on, see 
https://bugs.openjdk.java.net/browse/JDK-8166002

Thanks!

/Claes

On 12/13/2016 02:52 PM, Thomas St?fe wrote:
> Hi all,
>
> I try to build a 32bit VM (from the jdk9/hs repository) on Windows.
>
> The build fails when it tries to run the freshly built VM during the build:
>
> /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/configure-support/bin/fixpath.exe
> -c /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/jdk/bin/java -Xms64M
> -Xmx1024M -XX:ThreadStackSize=768 -esa -ea -cp
> /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/buildtools/tools_jigsaw_classes
> --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED
> build.tools.jigsaw.ModuleSummary -o
> /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/images/gengraphs/module-summary.html
> --module-path /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/images/jmods
> Error occurred during initialization of VM
> Could not reserve enough space for 1048576KB object heap
>
> Basically, the VM under <output>/jdk cannot be started with 1GB heap. I
> assume the same would be true for the build result VM, but cannot verify
> this as the build does not finish.
>
> Drilling down I found that when trying to allocate the java heap,
> VirtualAlloc fails with ERROR_NOT_ENOUGH_MEMORY.
>
> Drilling further down I found - when looking at the address space with
> VMMap - that there is indeed no adress space hole large enough to hold 1GB.
> But no culprit stands out immediately.
>
> Does anyone else experience similar problems? Would it be ok to reduce the
> -Xmx setting for the 32bit build on windows?
>
> Thank you, Thomas


From christian.tornqvist at oracle.com  Tue Dec 13 15:05:14 2016
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 13 Dec 2016 10:05:14 -0500
Subject: JDK-8171163 Merge 9de6a70d5d81 broke test/Makefile
In-Reply-To: <11ac55dc-63b8-2c72-e5c0-f0e2fd539bf8@oracle.com>
References: <11ac55dc-63b8-2c72-e5c0-f0e2fd539bf8@oracle.com>
Message-ID: <085701d25552$4f31d1f0$ed9575d0$@oracle.com>

Hi Magnus, 

This looks good, thanks for fixing this.

Thanks,
Christian

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie
Sent: Tuesday, December 13, 2016 7:49 AM
To: build-dev <build-dev at openjdk.java.net>; hotspot-dev <hotspot-dev at openjdk.java.net>
Subject: RFR: JDK-8171163 Merge 9de6a70d5d81 broke test/Makefile

The merge 9de6a70d5d81 (in jdk9/hs) reintroduced code that was deleted in JDK-8170629.

The result of this is that the target jtreg_tests is declared two times, which causes make to protest.

Note that the broken merge is in jdk9/hs, so this is where the fix needs to go.

Bug: https://bugs.openjdk.java.net/browse/JDK-8171163
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8171163-borked-merge-on-test-Makefile/webrev.01

/Magnus


From thomas.stuefe at gmail.com  Tue Dec 13 15:06:52 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 13 Dec 2016 16:06:52 +0100
Subject: 32bit windows VM cannot be started with 1GB heap?
In-Reply-To: <51c2e8f5-7e12-3406-d4f9-91093c9e69d0@oracle.com>
References: <CAA-vtUzRvXLueGHorVVbRLAMqPFxU=Yq40H72H6V9_sriSURmA@mail.gmail.com>
	<51c2e8f5-7e12-3406-d4f9-91093c9e69d0@oracle.com>
Message-ID: <CAA-vtUwJyyinfKQyBHE=OuvZkFC84oyW9gGvo736kyhjGkWewg@mail.gmail.com>

Hi Claes,

On Tue, Dec 13, 2016 at 3:28 PM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi Thomas,
>
> do you configure the build with the client or server VM?
>
>
I do not explicitly specify anything on the configure line, so I use the
default, which seems to be the server VM. At least I see the jvm.dll from
the server directory in the address space.

The former is not going to be supported by Oracle in JDK 9 and the latter is
> known to have issues with allocating too many threads and using too much
> memory for code cache etc on large machines, effectively starving the
> available space for the java heap.
>
> A solution to this is actively being worked on, see
> https://bugs.openjdk.java.net/browse/JDK-8166002
>
>
Good to know that a solution is in work, but I am not sure this would help
in my case. Just saw that right in the middle of the address space a Virus
scanner placed his dll. Without this dll the address hole would be *just*
enough to place a 1gb heap. However, unfortunately I cannot easily disable
the scanner on this machine. I think this problem may be common on 32bit
windows, unfortunately, and if the dll is placed badly enough, reducing the
memory footprint of the VM may not be enough.

Note that my immediate problem is solved - I just wanted to execute some
gtests on 32bit to make sure they run on 32bit. I found out that I can run
the gtests on the jdk in the output directory and do not need to have a
complete image directory built sucessfully.

Thank you for helping!

Thomas



> Thanks!
>
> /Claes
>
>
> On 12/13/2016 02:52 PM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> I try to build a 32bit VM (from the jdk9/hs repository) on Windows.
>>
>> The build fails when it tries to run the freshly built VM during the
>> build:
>>
>> /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/configure-
>> support/bin/fixpath.exe
>> -c /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/jdk/bin/java -Xms64M
>> -Xmx1024M -XX:ThreadStackSize=768 -esa -ea -cp
>> /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/buildtools
>> /tools_jigsaw_classes
>> --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED
>> build.tools.jigsaw.ModuleSummary -o
>> /cygdrive/c/d031900/openjdk/jdk9-hs2/output-32bit/images/gen
>> graphs/module-summary.html
>> --module-path /cygdrive/c/d031900/openjdk/jd
>> k9-hs2/output-32bit/images/jmods
>> Error occurred during initialization of VM
>> Could not reserve enough space for 1048576KB object heap
>>
>> Basically, the VM under <output>/jdk cannot be started with 1GB heap. I
>> assume the same would be true for the build result VM, but cannot verify
>> this as the build does not finish.
>>
>> Drilling down I found that when trying to allocate the java heap,
>> VirtualAlloc fails with ERROR_NOT_ENOUGH_MEMORY.
>>
>> Drilling further down I found - when looking at the address space with
>> VMMap - that there is indeed no adress space hole large enough to hold
>> 1GB.
>> But no culprit stands out immediately.
>>
>> Does anyone else experience similar problems? Would it be ok to reduce the
>> -Xmx setting for the 32bit build on windows?
>>
>> Thank you, Thomas
>>
>
>

From coleen.phillimore at oracle.com  Tue Dec 13 16:08:54 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 13 Dec 2016 11:08:54 -0500
Subject: RFR(S): 8170767: Zero fastdebug build triggers assertion
In-Reply-To: <e5cd8067-d74b-f1a1-ec55-7d2217df3683@oracle.com>
References: <1481115437.3024.9.camel@redhat.com>
	<54c75144-1575-fcc4-8c73-6702d5535f44@oracle.com>
	<1481621901.2892.3.camel@redhat.com>
	<e5cd8067-d74b-f1a1-ec55-7d2217df3683@oracle.com>
Message-ID: <7d0e106d-f753-51c1-d532-0abd3eb856da@oracle.com>

Severin,  I'm waiting for hs to open and I'll push your change.
Coleen

On 12/13/16 5:50 AM, Jesper Wilhelmsson wrote:
> This is a change in shared VM code. It should go through jprt.
>
> (Please do not interpret this mail as an approval to push. jdk9/hs is 
> still closed.)
> /Jesper
>
> Den 13/12/16 kl. 10:38, skrev Severin Gehwolf:
>> On Wed, 2016-12-07 at 22:58 -0500, Coleen Phillimore wrote:
>>> This looks good and I can sponsor this for you.  I haven't built 
>>> Zero in
>>> a while.
>>
>> Hi Coleen,
>>
>> Is it OK for me to push this change? I'm not entirely clear on which
>> changes need to go through JPRT. In theory I should be able to push
>> this change with my new committer powers ;-)
>>
>> Thanks,
>> Severin
>>
>>> On 12/7/16 7:57 AM, Severin Gehwolf wrote:
>>>>
>>>> Hi,
>>>>
>>>> Could somebody please review this Zero only change? The problem was
>>>> there before, but only the fix for JDK-8169711 brought it to the
>>>> surface. The returned method kind for
>>>> java_lang_math_fmaD/java_lang_math_fmaF is no longer guarded by UseFMA
>>>> in abstractInterpreter.cpp
>>>>
>>>> The fix is to generate stub entries for
>>>> java_lang_math_fmaD/java_lang_math_fmaF which were missing. Thoughts?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8170767
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8170767/webrev.01/
>>>>
>>>> Thanks,
>>>> Severin
>>>
>>


From daniel.daugherty at oracle.com  Tue Dec 13 17:12:43 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 13 Dec 2016 10:12:43 -0700
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
	<308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
Message-ID: <f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>

On 12/12/16 9:41 PM, David Holmes wrote:
> Okay here's the updated webrev complete with nice logging:
>
> http://cr.openjdk.java.net/~dholmes/8170307/webrev.v2/

src/os/linux/vm/os_linux.cpp
     L936:   // a user-specified value known to be greater than the 
minimum needed.
         Perhaps: ... known to be at least the minimum needed.

         As enforced by this code in os::Posix::set_minimum_stack_sizes():

         _java_thread_min_stack_allowed = 
MAX2(_java_thread_min_stack_allowed,
JavaThread::stack_guard_zone_size() +
JavaThread::stack_shadow_zone_size() +
                                               (4 * BytesPerWord 
COMPILER2_PRESENT(+ 2)) * 4 * K);

         _java_thread_min_stack_allowed = 
align_size_up(_java_thread_min_stack_allowed, vm_page_size());

         size_t stack_size_in_bytes = ThreadStackSize * K;
         if (stack_size_in_bytes != 0 &&
             stack_size_in_bytes < _java_thread_min_stack_allowed) {
           // The '-Xss' and '-XX:ThreadStackSize=N' options both set
           // ThreadStackSize so we go with "Java thread stack size" instead
           // of "ThreadStackSize" to be more friendly.
           tty->print_cr("\nThe Java thread stack size specified is too 
small. "
                         "Specify at least " SIZE_FORMAT "k",
                         _java_thread_min_stack_allowed / K);
           return JNI_ERR;
         }

     L932:   // can not do anything to emulate a larger stack than what 
has been provided by
         Typo: 'can not' -> 'cannot'

     L936:   // Mamimum stack size is the easy part, get it from 
RLIMIT_STACK
         Typo: 'Mamimum' -> 'Maximum'
         nit - please add a '.' to the end.

     L1125:                          SIZE_FORMAT "K, top=" INTPTR_FORMAT 
", bottom=" INTPTR_FORMAT "\n",
         Does the logging subsystem convert the "\n" into the proper
         output for non-*NIX platforms, e.g., Windows?

     L1126:                          primordial ? "Primordial" : "User", 
max_size/K,  _initial_thread_stack_size/K,
         Please add spaces around the div operator.

         Any particular reason that "Primordial" and "User" start with 
upper case?

Thumbs up!

I don't need to see a new webrev if you decide to make the
minor edits above.

Dan


>
> The stack size will be the smaller of the rlimit stack and the 
> -Xss/ThreadStackSize value. If the rlimit stack is unlimited and 
> ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you 
> can now get whatever primordial thread stack size you want by using 
> ulimit and -Xss appropriately.
>
> Thanks,
> David
>
> On 3/12/2016 2:11 PM, David Holmes wrote:
>> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>>> On 12/1/16 10:51 PM, David Holmes wrote:
>>>> Investigating this further the history is quite complex, especially
>>>> when we start looking at other platforms. E.g. see
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>>
>>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>>
>>>> I'm very tempted to do the same on Linux.
>>>
>>> Vote: yes
>>
>> Excellent! Other votes?
>>
>>> This latest problem only comes up with -XX:ThreadStackSize=0 when the
>>> stack is unlimited right?
>>
>> Right.
>>
>>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>>> 8MB or the ulimit a viable option?
>>
>> I think so.
>>
>>> Also, it looks like Hui had some things to say about not setting the
>>> red/yellow zone pages on the primordial thread when we aren't using the
>>> 'java' launcher because we don't know the environment of the code that
>>> is using the JNI invocation API...
>>
>> Yeah but those comments seem a bit confused to me. They suggest we
>> shouldn't add guard pages but in fact we do add guard pages. And to me
>> it is no different in the primordial thread than any other natively
>> attached thread ie why should the initially attached thread be treated
>> differently to any other?** I suspect if I keep researching on this I
>> will find bugs regarding such differences in behaviour (eg the fact that
>> -Xss wasn't working on the main thread).
>>
>> ** There are arguments both ways as to how natively attached threads
>> should behave. The main argument against guard page insertion is that we
>> don't know how far down the existing stack we actually are - we could be
>> past the depth where the guard page would be inserted! The main argument
>> for (which seems to have won the day) is so that we don't get arbitrary
>> differences in behaviour between threads created and attached by
>> application native code; and threads created direct from application
>> Java code.
>>
>> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
>> solution - assuming it addresses the needs of the folk that ran into
>> this problem.
>>
>> Thanks,
>> David
>>
>>> Dan
>>>
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes 
>>>>>> <david.holmes at oracle.com
>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>
>>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>>
>>>>>>         I just realized I overlooked the case where 
>>>>>> ThreadStackSize=0
>>>>>>         and the
>>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>>> guard
>>>>>>         pages
>>>>>>         will get inserted - I do know that I don't get a 
>>>>>> stackoverflow
>>>>>>         error.
>>>>>>
>>>>>>         This needs further investigation.
>>>>>>
>>>>>>
>>>>>>     So what happens here is that the massive stack-size causes
>>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>>     guard-page goodness knows where, and we can consume the current
>>>>>>     stack until such time as we hit an unmapped or protected 
>>>>>> region at
>>>>>>     which point we are killed.
>>>>>>
>>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>>> case we
>>>>>>     should not attempt to create a guard page in the initial thread.
>>>>>>     That would require using a sentinel value for the stack-size.
>>>>>> Though
>>>>>>     it also presents a problem for stack-bottom - which is 
>>>>>> implicitly
>>>>>>     zero. It may also give false positives in the 
>>>>>> is_initial_thread()
>>>>>> check!
>>>>>>
>>>>>>     Thoughts? Suggestions?
>>>>>>
>>>>>>
>>>>>> Maybe I am overlooking something, but should
>>>>>> os::capture_initial_thread() not call pthread_getattr_np() first to
>>>>>> handle the case where the VM was created on a pthread which is 
>>>>>> not the
>>>>>> primordial thread and may have a different stack size than what
>>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>>> pthread_getattr_np() fails?
>>>>>
>>>>> My understanding of the problem (which likely no longer exists) is 
>>>>> that
>>>>> pthread_getattr_np didn't fail as such but returned bogus values - so
>>>>> the problem was not detectable and so we just had to not use
>>>>> pthread_getattr_np.
>>>>>
>>>>>> And then we also should handle
>>>>>> RLIM_INFINITY. For that case, I also think not setting guard pages
>>>>>> would
>>>>>> be safest.
>>>>>>
>>>>>> We also may just refuse to run in that case, because the workaround
>>>>>> for
>>>>>> the user is easy - just set the limit before process start. Note
>>>>>> that on
>>>>>> AIX, we currently refuse to run on the primordial thread because it
>>>>>> may
>>>>>> have different page sizes than pthreads and it is impossible to get
>>>>>> the
>>>>>> exact stack locations.
>>>>>
>>>>> I was wondering why the AIX set up seemed so simple in comparison :)
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>         David
>>>>>>
>>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>>
>>>>>>             Hi Thomas,
>>>>>>
>>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>>
>>>>>>                 Hi David,
>>>>>>
>>>>>>                 thanks for the good explanation. Change looks 
>>>>>> good, I
>>>>>>                 really like the
>>>>>>                 comment in capture_initial_stack().
>>>>>>
>>>>>>                 Question, with -Xss given and being smaller than
>>>>>> current
>>>>>>                 thread stack
>>>>>>                 size, guard pages may appear in the middle of the
>>>>>>                 invoking thread stack?
>>>>>>                 I always thought this is a bit dangerous. If your
>>>>>> model
>>>>>>                 is to have the
>>>>>>                 VM created from the main thread, which then goes
>>>>>> off to
>>>>>>                 do different
>>>>>>                 things, and have other threads then attach and run
>>>>>> java
>>>>>>                 code, main
>>>>>>                 thread later may crash in unrelated native code just
>>>>>>                 because it reached
>>>>>>                 the stack depth of the hava threads? Or am I
>>>>>>                 misunderstanding something?
>>>>>>
>>>>>>
>>>>>>             There is no change to the general behaviour other than
>>>>>>             allowing a
>>>>>>             primordial process thread that launches the VM, to 
>>>>>> now not
>>>>>>             have an
>>>>>>             effective stack limited at 2MB. The current logic will
>>>>>>             insert guard
>>>>>>             pages where ever -Xss states (as long as less than 2MB
>>>>>> else
>>>>>>             2MB), while
>>>>>>             with the fix the guard pages will be inserted above 2MB
>>>>>> - as
>>>>>>             dictated by
>>>>>>             -Xss.
>>>>>>
>>>>>>             David
>>>>>>             -----
>>>>>>
>>>>>>                 Thanks, Thomas
>>>>>>
>>>>>>
>>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>>                 <david.holmes at oracle.com
>>>>>> <mailto:david.holmes at oracle.com>
>>>>>>                 <mailto:david.holmes at oracle.com
>>>>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>>>>
>>>>>>                     Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>>
>>>>>>                     The bug is not public unfortunately for
>>>>>>                 non-technical reasons - but
>>>>>>                     see my eval below.
>>>>>>
>>>>>>                     Background: if you load the JVM from the
>>>>>> primordial
>>>>>>                 thread of a
>>>>>>                     process (not done by the java launcher since JDK
>>>>>> 6),
>>>>>>                 there is an
>>>>>>                     artificial stack limit imposed on the initial
>>>>>> thread
>>>>>>                 (by sticking
>>>>>>                     the guard page at the limit position of the 
>>>>>> actual
>>>>>>                 stack) of the
>>>>>>                     minimum of the -Xss setting and 2M. So if you 
>>>>>> set
>>>>>>                 -Xss to > 2M it is
>>>>>>                     ignored for the main thread even if the true 
>>>>>> stack
>>>>>>                 is, say, 8M. This
>>>>>>                     limitation dates back 10-15 years and is no 
>>>>>> longer
>>>>>>                 relevant today
>>>>>>                     and should be removed (see below). I've also 
>>>>>> added
>>>>>>                 additional
>>>>>>                     explanatory notes.
>>>>>>
>>>>>>                     webrev:
>>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>>
>>>>>>                     Testing was manually done by modifying the
>>>>>> launcher
>>>>>>                 to not run the
>>>>>>                     VM in a new thread, and checking the resulting
>>>>>> stack
>>>>>>                 size used.
>>>>>>
>>>>>>                     This change will only affect hosted JVMs 
>>>>>> launched
>>>>>>                 with a -Xss value
>>>>>>                     > 2M.
>>>>>>
>>>>>>                     Thanks,
>>>>>>                     David
>>>>>>                     -----
>>>>>>
>>>>>>                     Bug eval:
>>>>>>
>>>>>>                     JDK-4441425 limits the stack to 8M as a 
>>>>>> safeguard
>>>>>>                 against an
>>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>>> further
>>>>>>                 constrained
>>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>>
>>>>>>                     By 1.4.2 we have the basic form of the current
>>>>>>                 problematic code:
>>>>>>
>>>>>>                     #ifndef IA64
>>>>>>                       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur =
>>>>>> 2 *
>>>>>>                 K * K;
>>>>>>                     #else
>>>>>>                       // Problem still exists RH7.2 (IA64 anyway) 
>>>>>> but
>>>>>>                 2MB is a little
>>>>>>                 small
>>>>>>                       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur =
>>>>>> 4 *
>>>>>>                 K * K;
>>>>>>                     #endif
>>>>>>
>>>>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>>>>                 ~(page_size() - 1);
>>>>>>
>>>>>>                       if (max_size && _initial_thread_stack_size >
>>>>>>                 max_size) {
>>>>>>                          _initial_thread_stack_size = max_size;
>>>>>>                       }
>>>>>>
>>>>>>                     This was added by JDK-4678676 to allow the
>>>>>> stack of
>>>>>>                 the main thread
>>>>>>                     to be _reduced_ below the default 2M/4M if the
>>>>>> -Xss
>>>>>>                 value was
>>>>>>                     smaller than that.** There was no intent to 
>>>>>> allow
>>>>>>                 the stack size to
>>>>>>                     follow -Xss arbitrarily due to the operational
>>>>>>                 constraints imposed
>>>>>>                     by the OS/glibc at the time when dealing with 
>>>>>> the
>>>>>>                 primordial process
>>>>>>                     thread.
>>>>>>
>>>>>>                     ** It could not actually change the actual stack
>>>>>>                 size of course, but
>>>>>>                     set the guard pages to limit use to the expected
>>>>>>                 stack size.
>>>>>>
>>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>>                 changed to create the
>>>>>>                     JVM in a new thread, so that it was not 
>>>>>> limited by
>>>>>> the
>>>>>>                     idiosyncracies of the OS or thread library
>>>>>>                 primordial thread
>>>>>>                     handling. However, the stack size limitations
>>>>>>                 remained in place in
>>>>>>                     case the VM was launched from the primordial
>>>>>> thread
>>>>>>                 of a user
>>>>>>                     application via the JNI invocation API.
>>>>>>
>>>>>>                     I believe it should be safe to remove the 2M
>>>>>>                 limitation now.
>>>>>>
>>>>>>
>>>>>>
>>>


From bob.vandette at oracle.com  Tue Dec 13 18:16:08 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 13 Dec 2016 13:16:08 -0500
Subject: JEP 297: Unified arm32/arm64 Port latest Merge
Message-ID: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com>

Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest.

I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday. 

http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/>
http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/>
http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/>

I?m not planning on updating the jdk9-arm3264 forest since I?m trying to maintain a single
collection of changesets to be used to integrate into jdk9/dev, assuming I get the go ahead.

Bob.


From vladimir.kozlov at oracle.com  Tue Dec 13 18:29:03 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 Dec 2016 10:29:03 -0800
Subject: JEP 297: Unified arm32/arm64 Port latest Merge
In-Reply-To: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com>
References: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com>
Message-ID: <0746f552-7a19-8159-493d-dc5f12df72a1@oracle.com>

On 12/13/16 10:16 AM, Bob Vandette wrote:
> Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest.
>
> I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday.

Good.

>
> http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/>
> http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/>
> http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/>
>
> I?m not planning on updating the jdk9-arm3264 forest since I?m trying to maintain a single
> collection of changesets to be used to integrate into jdk9/dev, assuming I get the go ahead.

Fine with me.

Thanks,
Vladimir

>
> Bob.
>

From coleen.phillimore at oracle.com  Tue Dec 13 20:07:21 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 13 Dec 2016 15:07:21 -0500
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
In-Reply-To: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
References: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
Message-ID: <9c8f0c8e-803a-226a-90c3-55f68ab77d87@oracle.com>

Zoltan,

This fix looks good.

Thanks!
Coleen

On 12/13/16 6:35 AM, Zolt?n Maj? wrote:
> Hi,
>
>
> please review the fix for 8171155.
>
> https://bugs.openjdk.java.net/browse/JDK-8171155
> http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/
>
> The JVM assumes the field it's looking for always exists. As a result, 
> the JVM processes uninitialized data if the field does not exists, 
> which results in a crash. The suggested fix is to check if the field 
> exists before processing it. Please find more details in the bug 
> description.
>
> I found the bug while JPRT-testing the 8u-backport of
>
> 8157181: Compilers accept modification of final fields outside 
> initializer methods
>
> I was not able to reproduce the issue with 9, but (judging from the 
> code) JDK 9 is likely to be affected as well. So I'd prefer to fix 
> this problem in JDK 9 as well (and then backport the fix to 8u) 
> instead of pushing the fix only into 8u.
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>


From brent.christian at oracle.com  Tue Dec 13 20:53:01 2016
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 13 Dec 2016 12:53:01 -0800
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
In-Reply-To: <12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com>
References: <584885AA.9060202@oracle.com>
	<53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>
	<584B578A.1030508@oracle.com>
	<12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com>
Message-ID: <58505FAD.6060404@oracle.com>

Thank you, Mandy and Daniel.

As a point of interest, automated testing uncovered a couple things I 
had to change before pushing:

http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/accf1676e416

* Updated the CHECK_OFFSET line, so fastdebug builds

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ddc8f2ae290b

* In the test case, only check for a classloader named 'app' if we are 
using the system classloader.  This is usually the case, but not when 
running regtests using the 'make' target (URLClassLoader).

Thanks,
-Brent
On 12/10/2016 06:51 AM, Daniel Fuchs wrote:
> Hi Brent,
>
> This looks really good now!
>
> best regards,
>
> -- daniel
>
> On 10/12/16 01:16, Brent Christian wrote:
>> On 12/07/2016 04:05 PM, Mandy Chung wrote:
>>>
>>> I suggest to add two utility methods rather than the has method:
>>>    boolean dropClassLoaderName()
>>>    boolean dropModuleVersion()
>>
>> Done.
>>
>>>   430    if (m != null && m.isNamed() &&
>>>   431          (isHashedInJavaBase(m) ||
>>> !m.getDescriptor().version().isPresent())) {
>>>   432        bits |= JDK_NON_UPGRADEABLE_MODULE;
>>>   433    }
>>>
>>> I think this should simply be:
>>>     if (isHashedInJavaBase(m)) {..}
>>>
>>
>> Done.
>>
>>> Can you retain the javadoc of toLoaderModuleClassName, revised if
>>> appropriate, in the computeFormat method?
>>
>> Updated.
>>
>>> line 322-325: what about:
>>>
>>> The toString method may return two different values on two
>>> StackTraceElement instances that are equal for example when
>>> one created via the constructor and one obtained from Throwable
>>> or StackFrame where an implementation may choose to omit some
>>> element in the returned string.
>>
>> That sounds good.
>>
>>> Is @apiNote in equals necessary?  Maybe the one added in toString is
>>> adequate?
>>
>> I'm fine without it - removed.
>>
>>
>> I also fixed test code for a case which only works with the images build.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/
>>
>> -Brent
>


From mandy.chung at oracle.com  Wed Dec 14 04:10:15 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 13 Dec 2016 20:10:15 -0800
Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString
	format and save footprint
In-Reply-To: <58505FAD.6060404@oracle.com>
References: <584885AA.9060202@oracle.com>
	<53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com>
	<584B578A.1030508@oracle.com>
	<12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com>
	<58505FAD.6060404@oracle.com>
Message-ID: <FEEF371F-2B1E-43E4-A6F0-0C11B21F304D@oracle.com>


> On Dec 13, 2016, at 12:53 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Thank you, Mandy and Daniel.
> 
> As a point of interest, automated testing uncovered a couple things I had to change before pushing:
> 
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/accf1676e416
> 
> * Updated the CHECK_OFFSET line, so fastdebug builds
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ddc8f2ae290b
> 
> * In the test case, only check for a classloader named 'app' if we are using the system classloader.  This is usually the case, but not when running regtests using the 'make' target (URLClassLoader).

Thanks for the update.  Looks fine to me.

Mandy

From david.holmes at oracle.com  Wed Dec 14 05:49:04 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 14 Dec 2016 15:49:04 +1000
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
	<308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
	<f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>
Message-ID: <99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>

Hi Dan,

Thanks for the re-review. I apologize for losing the edits you 
previously suggested.

More inline ...

On 14/12/2016 3:12 AM, Daniel D. Daugherty wrote:
> On 12/12/16 9:41 PM, David Holmes wrote:
>> Okay here's the updated webrev complete with nice logging:
>>
>> http://cr.openjdk.java.net/~dholmes/8170307/webrev.v2/
>
> src/os/linux/vm/os_linux.cpp
>     L936:   // a user-specified value known to be greater than the
> minimum needed.
>         Perhaps: ... known to be at least the minimum needed.

Changed.

>     L932:   // can not do anything to emulate a larger stack than what
> has been provided by
>         Typo: 'can not' -> 'cannot'

Changed.

>     L936:   // Mamimum stack size is the easy part, get it from
> RLIMIT_STACK
>         Typo: 'Mamimum' -> 'Maximum'
>         nit - please add a '.' to the end.

Fixed.

>
>     L1125:                          SIZE_FORMAT "K, top=" INTPTR_FORMAT
> ", bottom=" INTPTR_FORMAT "\n",
>         Does the logging subsystem convert the "\n" into the proper
>         output for non-*NIX platforms, e.g., Windows?

No idea :) But that was leftover from when this was a ::printf (I wasn't 
sure logging would work this early in VM init - but it does).

Removed.


>     L1126:                          primordial ? "Primordial" : "User",
> max_size/K,  _initial_thread_stack_size/K,
>         Please add spaces around the div operator.

Changed.

>         Any particular reason that "Primordial" and "User" start with
> upper case?

They used to be the first things printed. :) Fixed.

> Thumbs up!
>
> I don't need to see a new webrev if you decide to make the
> minor edits above.

Updated in place for the second reviewer (whomever they may be).

Thanks,
David
-----

> Dan
>
>
>>
>> The stack size will be the smaller of the rlimit stack and the
>> -Xss/ThreadStackSize value. If the rlimit stack is unlimited and
>> ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you
>> can now get whatever primordial thread stack size you want by using
>> ulimit and -Xss appropriately.
>>
>> Thanks,
>> David
>>
>> On 3/12/2016 2:11 PM, David Holmes wrote:
>>> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>>>> On 12/1/16 10:51 PM, David Holmes wrote:
>>>>> Investigating this further the history is quite complex, especially
>>>>> when we start looking at other platforms. E.g. see
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>>>
>>>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>>>
>>>>> I'm very tempted to do the same on Linux.
>>>>
>>>> Vote: yes
>>>
>>> Excellent! Other votes?
>>>
>>>> This latest problem only comes up with -XX:ThreadStackSize=0 when the
>>>> stack is unlimited right?
>>>
>>> Right.
>>>
>>>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>>>> 8MB or the ulimit a viable option?
>>>
>>> I think so.
>>>
>>>> Also, it looks like Hui had some things to say about not setting the
>>>> red/yellow zone pages on the primordial thread when we aren't using the
>>>> 'java' launcher because we don't know the environment of the code that
>>>> is using the JNI invocation API...
>>>
>>> Yeah but those comments seem a bit confused to me. They suggest we
>>> shouldn't add guard pages but in fact we do add guard pages. And to me
>>> it is no different in the primordial thread than any other natively
>>> attached thread ie why should the initially attached thread be treated
>>> differently to any other?** I suspect if I keep researching on this I
>>> will find bugs regarding such differences in behaviour (eg the fact that
>>> -Xss wasn't working on the main thread).
>>>
>>> ** There are arguments both ways as to how natively attached threads
>>> should behave. The main argument against guard page insertion is that we
>>> don't know how far down the existing stack we actually are - we could be
>>> past the depth where the guard page would be inserted! The main argument
>>> for (which seems to have won the day) is so that we don't get arbitrary
>>> differences in behaviour between threads created and attached by
>>> application native code; and threads created direct from application
>>> Java code.
>>>
>>> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
>>> solution - assuming it addresses the needs of the folk that ran into
>>> this problem.
>>>
>>> Thanks,
>>> David
>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes
>>>>>>> <david.holmes at oracle.com
>>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>
>>>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>>>
>>>>>>>         I just realized I overlooked the case where
>>>>>>> ThreadStackSize=0
>>>>>>>         and the
>>>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>>>> guard
>>>>>>>         pages
>>>>>>>         will get inserted - I do know that I don't get a
>>>>>>> stackoverflow
>>>>>>>         error.
>>>>>>>
>>>>>>>         This needs further investigation.
>>>>>>>
>>>>>>>
>>>>>>>     So what happens here is that the massive stack-size causes
>>>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>>>     guard-page goodness knows where, and we can consume the current
>>>>>>>     stack until such time as we hit an unmapped or protected
>>>>>>> region at
>>>>>>>     which point we are killed.
>>>>>>>
>>>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>>>> case we
>>>>>>>     should not attempt to create a guard page in the initial thread.
>>>>>>>     That would require using a sentinel value for the stack-size.
>>>>>>> Though
>>>>>>>     it also presents a problem for stack-bottom - which is
>>>>>>> implicitly
>>>>>>>     zero. It may also give false positives in the
>>>>>>> is_initial_thread()
>>>>>>> check!
>>>>>>>
>>>>>>>     Thoughts? Suggestions?
>>>>>>>
>>>>>>>
>>>>>>> Maybe I am overlooking something, but should
>>>>>>> os::capture_initial_thread() not call pthread_getattr_np() first to
>>>>>>> handle the case where the VM was created on a pthread which is
>>>>>>> not the
>>>>>>> primordial thread and may have a different stack size than what
>>>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>>>> pthread_getattr_np() fails?
>>>>>>
>>>>>> My understanding of the problem (which likely no longer exists) is
>>>>>> that
>>>>>> pthread_getattr_np didn't fail as such but returned bogus values - so
>>>>>> the problem was not detectable and so we just had to not use
>>>>>> pthread_getattr_np.
>>>>>>
>>>>>>> And then we also should handle
>>>>>>> RLIM_INFINITY. For that case, I also think not setting guard pages
>>>>>>> would
>>>>>>> be safest.
>>>>>>>
>>>>>>> We also may just refuse to run in that case, because the workaround
>>>>>>> for
>>>>>>> the user is easy - just set the limit before process start. Note
>>>>>>> that on
>>>>>>> AIX, we currently refuse to run on the primordial thread because it
>>>>>>> may
>>>>>>> have different page sizes than pthreads and it is impossible to get
>>>>>>> the
>>>>>>> exact stack locations.
>>>>>>
>>>>>> I was wondering why the AIX set up seemed so simple in comparison :)
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>         David
>>>>>>>
>>>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>>>
>>>>>>>             Hi Thomas,
>>>>>>>
>>>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>>>
>>>>>>>                 Hi David,
>>>>>>>
>>>>>>>                 thanks for the good explanation. Change looks
>>>>>>> good, I
>>>>>>>                 really like the
>>>>>>>                 comment in capture_initial_stack().
>>>>>>>
>>>>>>>                 Question, with -Xss given and being smaller than
>>>>>>> current
>>>>>>>                 thread stack
>>>>>>>                 size, guard pages may appear in the middle of the
>>>>>>>                 invoking thread stack?
>>>>>>>                 I always thought this is a bit dangerous. If your
>>>>>>> model
>>>>>>>                 is to have the
>>>>>>>                 VM created from the main thread, which then goes
>>>>>>> off to
>>>>>>>                 do different
>>>>>>>                 things, and have other threads then attach and run
>>>>>>> java
>>>>>>>                 code, main
>>>>>>>                 thread later may crash in unrelated native code just
>>>>>>>                 because it reached
>>>>>>>                 the stack depth of the hava threads? Or am I
>>>>>>>                 misunderstanding something?
>>>>>>>
>>>>>>>
>>>>>>>             There is no change to the general behaviour other than
>>>>>>>             allowing a
>>>>>>>             primordial process thread that launches the VM, to
>>>>>>> now not
>>>>>>>             have an
>>>>>>>             effective stack limited at 2MB. The current logic will
>>>>>>>             insert guard
>>>>>>>             pages where ever -Xss states (as long as less than 2MB
>>>>>>> else
>>>>>>>             2MB), while
>>>>>>>             with the fix the guard pages will be inserted above 2MB
>>>>>>> - as
>>>>>>>             dictated by
>>>>>>>             -Xss.
>>>>>>>
>>>>>>>             David
>>>>>>>             -----
>>>>>>>
>>>>>>>                 Thanks, Thomas
>>>>>>>
>>>>>>>
>>>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>>>                 <david.holmes at oracle.com
>>>>>>> <mailto:david.holmes at oracle.com>
>>>>>>>                 <mailto:david.holmes at oracle.com
>>>>>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>>>>>
>>>>>>>                     Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>>>
>>>>>>>                     The bug is not public unfortunately for
>>>>>>>                 non-technical reasons - but
>>>>>>>                     see my eval below.
>>>>>>>
>>>>>>>                     Background: if you load the JVM from the
>>>>>>> primordial
>>>>>>>                 thread of a
>>>>>>>                     process (not done by the java launcher since JDK
>>>>>>> 6),
>>>>>>>                 there is an
>>>>>>>                     artificial stack limit imposed on the initial
>>>>>>> thread
>>>>>>>                 (by sticking
>>>>>>>                     the guard page at the limit position of the
>>>>>>> actual
>>>>>>>                 stack) of the
>>>>>>>                     minimum of the -Xss setting and 2M. So if you
>>>>>>> set
>>>>>>>                 -Xss to > 2M it is
>>>>>>>                     ignored for the main thread even if the true
>>>>>>> stack
>>>>>>>                 is, say, 8M. This
>>>>>>>                     limitation dates back 10-15 years and is no
>>>>>>> longer
>>>>>>>                 relevant today
>>>>>>>                     and should be removed (see below). I've also
>>>>>>> added
>>>>>>>                 additional
>>>>>>>                     explanatory notes.
>>>>>>>
>>>>>>>                     webrev:
>>>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>>>
>>>>>>>                     Testing was manually done by modifying the
>>>>>>> launcher
>>>>>>>                 to not run the
>>>>>>>                     VM in a new thread, and checking the resulting
>>>>>>> stack
>>>>>>>                 size used.
>>>>>>>
>>>>>>>                     This change will only affect hosted JVMs
>>>>>>> launched
>>>>>>>                 with a -Xss value
>>>>>>>                     > 2M.
>>>>>>>
>>>>>>>                     Thanks,
>>>>>>>                     David
>>>>>>>                     -----
>>>>>>>
>>>>>>>                     Bug eval:
>>>>>>>
>>>>>>>                     JDK-4441425 limits the stack to 8M as a
>>>>>>> safeguard
>>>>>>>                 against an
>>>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>>>> further
>>>>>>>                 constrained
>>>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>>>
>>>>>>>                     By 1.4.2 we have the basic form of the current
>>>>>>>                 problematic code:
>>>>>>>
>>>>>>>                     #ifndef IA64
>>>>>>>                       if (rlim.rlim_cur > 2 * K * K) rlim.rlim_cur =
>>>>>>> 2 *
>>>>>>>                 K * K;
>>>>>>>                     #else
>>>>>>>                       // Problem still exists RH7.2 (IA64 anyway)
>>>>>>> but
>>>>>>>                 2MB is a little
>>>>>>>                 small
>>>>>>>                       if (rlim.rlim_cur > 4 * K * K) rlim.rlim_cur =
>>>>>>> 4 *
>>>>>>>                 K * K;
>>>>>>>                     #endif
>>>>>>>
>>>>>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>>>>>                 ~(page_size() - 1);
>>>>>>>
>>>>>>>                       if (max_size && _initial_thread_stack_size >
>>>>>>>                 max_size) {
>>>>>>>                          _initial_thread_stack_size = max_size;
>>>>>>>                       }
>>>>>>>
>>>>>>>                     This was added by JDK-4678676 to allow the
>>>>>>> stack of
>>>>>>>                 the main thread
>>>>>>>                     to be _reduced_ below the default 2M/4M if the
>>>>>>> -Xss
>>>>>>>                 value was
>>>>>>>                     smaller than that.** There was no intent to
>>>>>>> allow
>>>>>>>                 the stack size to
>>>>>>>                     follow -Xss arbitrarily due to the operational
>>>>>>>                 constraints imposed
>>>>>>>                     by the OS/glibc at the time when dealing with
>>>>>>> the
>>>>>>>                 primordial process
>>>>>>>                     thread.
>>>>>>>
>>>>>>>                     ** It could not actually change the actual stack
>>>>>>>                 size of course, but
>>>>>>>                     set the guard pages to limit use to the expected
>>>>>>>                 stack size.
>>>>>>>
>>>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>>>                 changed to create the
>>>>>>>                     JVM in a new thread, so that it was not
>>>>>>> limited by
>>>>>>> the
>>>>>>>                     idiosyncracies of the OS or thread library
>>>>>>>                 primordial thread
>>>>>>>                     handling. However, the stack size limitations
>>>>>>>                 remained in place in
>>>>>>>                     case the VM was launched from the primordial
>>>>>>> thread
>>>>>>>                 of a user
>>>>>>>                     application via the JNI invocation API.
>>>>>>>
>>>>>>>                     I believe it should be safe to remove the 2M
>>>>>>>                 limitation now.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>

From zoltan.majo at oracle.com  Wed Dec 14 07:28:11 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Wed, 14 Dec 2016 08:28:11 +0100
Subject: [9] RFR (XS): 8171155: Scanning method file for initialized final
	field updates can fail for non-existent fields
In-Reply-To: <9c8f0c8e-803a-226a-90c3-55f68ab77d87@oracle.com>
References: <a5dc5367-875e-fe67-be0c-be883a16d951@oracle.com>
	<9c8f0c8e-803a-226a-90c3-55f68ab77d87@oracle.com>
Message-ID: <a8026b27-d766-775c-4add-e56281960c2d@oracle.com>

Hi Coleen,


On 12/13/2016 09:07 PM, Coleen Phillimore wrote:
> Zoltan,
>
> This fix looks good.

thank you for the review! I'll push the fix once the repository is open.

Best regards,


Zoltan

>
> Thanks!
> Coleen
>
> On 12/13/16 6:35 AM, Zolt?n Maj? wrote:
>> Hi,
>>
>>
>> please review the fix for 8171155.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8171155
>> http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/
>>
>> The JVM assumes the field it's looking for always exists. As a 
>> result, the JVM processes uninitialized data if the field does not 
>> exists, which results in a crash. The suggested fix is to check if 
>> the field exists before processing it. Please find more details in 
>> the bug description.
>>
>> I found the bug while JPRT-testing the 8u-backport of
>>
>> 8157181: Compilers accept modification of final fields outside 
>> initializer methods
>>
>> I was not able to reproduce the issue with 9, but (judging from the 
>> code) JDK 9 is likely to be affected as well. So I'd prefer to fix 
>> this problem in JDK 9 as well (and then backport the fix to 8u) 
>> instead of pushing the fix only into 8u.
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>


From gromero at linux.vnet.ibm.com  Wed Dec 14 13:39:11 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 14 Dec 2016 11:39:11 -0200
Subject: RTM/HTM jtreg test regression
In-Reply-To: <776b57b646a04f96a69357d7ddb8eb31@DEROTE13DE08.global.corp.sap>
References: <584F1BB5.4020907@linux.vnet.ibm.com>
	<776b57b646a04f96a69357d7ddb8eb31@DEROTE13DE08.global.corp.sap>
Message-ID: <58514B7F.4030305@linux.vnet.ibm.com>

Hi Goetz,

On 13-12-2016 11:19, Lindenmaier, Goetz wrote:
> Hi Gustave, 
> 
> Yes, this seems necessary.

Thanks for advising. I filed a bug:
https://bugs.openjdk.java.net/browse/JDK-8171236

Regards,
Gustavo


From gromero at linux.vnet.ibm.com  Wed Dec 14 13:43:45 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 14 Dec 2016 11:43:45 -0200
Subject: RFR(XXS): 8171236: RTM/HTM jtreg tests regression after transition to
	the new GNU-style options
Message-ID: <58514C91.5060505@linux.vnet.ibm.com>

Hi,

Could the following small change by reviewed please?

webrev: http://cr.openjdk.java.net/~gromero/8171236/
bug   : https://bugs.openjdk.java.net/browse/JDK-8171236

Thank you and best regards,
Gustavo


From daniel.daugherty at oracle.com  Wed Dec 14 14:59:42 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 14 Dec 2016 07:59:42 -0700
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
	<308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
	<f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>
	<99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>
Message-ID: <87685856-eba6-4c2f-380f-b9489960a90d@oracle.com>

On 12/13/16 10:49 PM, David Holmes wrote:
> Hi Dan,
>
> Thanks for the re-review. I apologize for losing the edits you 
> previously suggested.

No worries. This fix was quite the slog through the swamp and it was
hard to keep track of all the history and gory details.

Glad you found an acceptable solution...

Dan


>
> More inline ...
>
> On 14/12/2016 3:12 AM, Daniel D. Daugherty wrote:
>> On 12/12/16 9:41 PM, David Holmes wrote:
>>> Okay here's the updated webrev complete with nice logging:
>>>
>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev.v2/
>>
>> src/os/linux/vm/os_linux.cpp
>>     L936:   // a user-specified value known to be greater than the
>> minimum needed.
>>         Perhaps: ... known to be at least the minimum needed.
>
> Changed.
>
>>     L932:   // can not do anything to emulate a larger stack than what
>> has been provided by
>>         Typo: 'can not' -> 'cannot'
>
> Changed.
>
>>     L936:   // Mamimum stack size is the easy part, get it from
>> RLIMIT_STACK
>>         Typo: 'Mamimum' -> 'Maximum'
>>         nit - please add a '.' to the end.
>
> Fixed.
>
>>
>>     L1125:                          SIZE_FORMAT "K, top=" INTPTR_FORMAT
>> ", bottom=" INTPTR_FORMAT "\n",
>>         Does the logging subsystem convert the "\n" into the proper
>>         output for non-*NIX platforms, e.g., Windows?
>
> No idea :) But that was leftover from when this was a ::printf (I 
> wasn't sure logging would work this early in VM init - but it does).
>
> Removed.
>
>
>>     L1126: primordial ? "Primordial" : "User",
>> max_size/K,  _initial_thread_stack_size/K,
>>         Please add spaces around the div operator.
>
> Changed.
>
>>         Any particular reason that "Primordial" and "User" start with
>> upper case?
>
> They used to be the first things printed. :) Fixed.
>
>> Thumbs up!
>>
>> I don't need to see a new webrev if you decide to make the
>> minor edits above.
>
> Updated in place for the second reviewer (whomever they may be).
>
> Thanks,
> David
> -----
>
>> Dan
>>
>>
>>>
>>> The stack size will be the smaller of the rlimit stack and the
>>> -Xss/ThreadStackSize value. If the rlimit stack is unlimited and
>>> ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you
>>> can now get whatever primordial thread stack size you want by using
>>> ulimit and -Xss appropriately.
>>>
>>> Thanks,
>>> David
>>>
>>> On 3/12/2016 2:11 PM, David Holmes wrote:
>>>> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>>>>> On 12/1/16 10:51 PM, David Holmes wrote:
>>>>>> Investigating this further the history is quite complex, especially
>>>>>> when we start looking at other platforms. E.g. see
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>>>>
>>>>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>>>>
>>>>>> I'm very tempted to do the same on Linux.
>>>>>
>>>>> Vote: yes
>>>>
>>>> Excellent! Other votes?
>>>>
>>>>> This latest problem only comes up with -XX:ThreadStackSize=0 when the
>>>>> stack is unlimited right?
>>>>
>>>> Right.
>>>>
>>>>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>>>>> 8MB or the ulimit a viable option?
>>>>
>>>> I think so.
>>>>
>>>>> Also, it looks like Hui had some things to say about not setting the
>>>>> red/yellow zone pages on the primordial thread when we aren't 
>>>>> using the
>>>>> 'java' launcher because we don't know the environment of the code 
>>>>> that
>>>>> is using the JNI invocation API...
>>>>
>>>> Yeah but those comments seem a bit confused to me. They suggest we
>>>> shouldn't add guard pages but in fact we do add guard pages. And to me
>>>> it is no different in the primordial thread than any other natively
>>>> attached thread ie why should the initially attached thread be treated
>>>> differently to any other?** I suspect if I keep researching on this I
>>>> will find bugs regarding such differences in behaviour (eg the fact 
>>>> that
>>>> -Xss wasn't working on the main thread).
>>>>
>>>> ** There are arguments both ways as to how natively attached threads
>>>> should behave. The main argument against guard page insertion is 
>>>> that we
>>>> don't know how far down the existing stack we actually are - we 
>>>> could be
>>>> past the depth where the guard page would be inserted! The main 
>>>> argument
>>>> for (which seems to have won the day) is so that we don't get 
>>>> arbitrary
>>>> differences in behaviour between threads created and attached by
>>>> application native code; and threads created direct from application
>>>> Java code.
>>>>
>>>> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
>>>> solution - assuming it addresses the needs of the folk that ran into
>>>> this problem.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes
>>>>>>>> <david.holmes at oracle.com
>>>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>>
>>>>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>>>>
>>>>>>>>         I just realized I overlooked the case where
>>>>>>>> ThreadStackSize=0
>>>>>>>>         and the
>>>>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>>>>> guard
>>>>>>>>         pages
>>>>>>>>         will get inserted - I do know that I don't get a
>>>>>>>> stackoverflow
>>>>>>>>         error.
>>>>>>>>
>>>>>>>>         This needs further investigation.
>>>>>>>>
>>>>>>>>
>>>>>>>>     So what happens here is that the massive stack-size causes
>>>>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>>>>     guard-page goodness knows where, and we can consume the 
>>>>>>>> current
>>>>>>>>     stack until such time as we hit an unmapped or protected
>>>>>>>> region at
>>>>>>>>     which point we are killed.
>>>>>>>>
>>>>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>>>>> case we
>>>>>>>>     should not attempt to create a guard page in the initial 
>>>>>>>> thread.
>>>>>>>>     That would require using a sentinel value for the stack-size.
>>>>>>>> Though
>>>>>>>>     it also presents a problem for stack-bottom - which is
>>>>>>>> implicitly
>>>>>>>>     zero. It may also give false positives in the
>>>>>>>> is_initial_thread()
>>>>>>>> check!
>>>>>>>>
>>>>>>>>     Thoughts? Suggestions?
>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe I am overlooking something, but should
>>>>>>>> os::capture_initial_thread() not call pthread_getattr_np() 
>>>>>>>> first to
>>>>>>>> handle the case where the VM was created on a pthread which is
>>>>>>>> not the
>>>>>>>> primordial thread and may have a different stack size than what
>>>>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>>>>> pthread_getattr_np() fails?
>>>>>>>
>>>>>>> My understanding of the problem (which likely no longer exists) is
>>>>>>> that
>>>>>>> pthread_getattr_np didn't fail as such but returned bogus values 
>>>>>>> - so
>>>>>>> the problem was not detectable and so we just had to not use
>>>>>>> pthread_getattr_np.
>>>>>>>
>>>>>>>> And then we also should handle
>>>>>>>> RLIM_INFINITY. For that case, I also think not setting guard pages
>>>>>>>> would
>>>>>>>> be safest.
>>>>>>>>
>>>>>>>> We also may just refuse to run in that case, because the 
>>>>>>>> workaround
>>>>>>>> for
>>>>>>>> the user is easy - just set the limit before process start. Note
>>>>>>>> that on
>>>>>>>> AIX, we currently refuse to run on the primordial thread 
>>>>>>>> because it
>>>>>>>> may
>>>>>>>> have different page sizes than pthreads and it is impossible to 
>>>>>>>> get
>>>>>>>> the
>>>>>>>> exact stack locations.
>>>>>>>
>>>>>>> I was wondering why the AIX set up seemed so simple in 
>>>>>>> comparison :)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         David
>>>>>>>>
>>>>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>>>>
>>>>>>>>             Hi Thomas,
>>>>>>>>
>>>>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>>>>
>>>>>>>>                 Hi David,
>>>>>>>>
>>>>>>>>                 thanks for the good explanation. Change looks
>>>>>>>> good, I
>>>>>>>>                 really like the
>>>>>>>>                 comment in capture_initial_stack().
>>>>>>>>
>>>>>>>>                 Question, with -Xss given and being smaller than
>>>>>>>> current
>>>>>>>>                 thread stack
>>>>>>>>                 size, guard pages may appear in the middle of the
>>>>>>>>                 invoking thread stack?
>>>>>>>>                 I always thought this is a bit dangerous. If your
>>>>>>>> model
>>>>>>>>                 is to have the
>>>>>>>>                 VM created from the main thread, which then goes
>>>>>>>> off to
>>>>>>>>                 do different
>>>>>>>>                 things, and have other threads then attach and run
>>>>>>>> java
>>>>>>>>                 code, main
>>>>>>>>                 thread later may crash in unrelated native code 
>>>>>>>> just
>>>>>>>>                 because it reached
>>>>>>>>                 the stack depth of the hava threads? Or am I
>>>>>>>>                 misunderstanding something?
>>>>>>>>
>>>>>>>>
>>>>>>>>             There is no change to the general behaviour other than
>>>>>>>>             allowing a
>>>>>>>>             primordial process thread that launches the VM, to
>>>>>>>> now not
>>>>>>>>             have an
>>>>>>>>             effective stack limited at 2MB. The current logic will
>>>>>>>>             insert guard
>>>>>>>>             pages where ever -Xss states (as long as less than 2MB
>>>>>>>> else
>>>>>>>>             2MB), while
>>>>>>>>             with the fix the guard pages will be inserted above 
>>>>>>>> 2MB
>>>>>>>> - as
>>>>>>>>             dictated by
>>>>>>>>             -Xss.
>>>>>>>>
>>>>>>>>             David
>>>>>>>>             -----
>>>>>>>>
>>>>>>>>                 Thanks, Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>>>>                 <david.holmes at oracle.com
>>>>>>>> <mailto:david.holmes at oracle.com>
>>>>>>>>                 <mailto:david.holmes at oracle.com
>>>>>>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>>>>>>
>>>>>>>>                     Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>>>>
>>>>>>>>                     The bug is not public unfortunately for
>>>>>>>>                 non-technical reasons - but
>>>>>>>>                     see my eval below.
>>>>>>>>
>>>>>>>>                     Background: if you load the JVM from the
>>>>>>>> primordial
>>>>>>>>                 thread of a
>>>>>>>>                     process (not done by the java launcher 
>>>>>>>> since JDK
>>>>>>>> 6),
>>>>>>>>                 there is an
>>>>>>>>                     artificial stack limit imposed on the initial
>>>>>>>> thread
>>>>>>>>                 (by sticking
>>>>>>>>                     the guard page at the limit position of the
>>>>>>>> actual
>>>>>>>>                 stack) of the
>>>>>>>>                     minimum of the -Xss setting and 2M. So if you
>>>>>>>> set
>>>>>>>>                 -Xss to > 2M it is
>>>>>>>>                     ignored for the main thread even if the true
>>>>>>>> stack
>>>>>>>>                 is, say, 8M. This
>>>>>>>>                     limitation dates back 10-15 years and is no
>>>>>>>> longer
>>>>>>>>                 relevant today
>>>>>>>>                     and should be removed (see below). I've also
>>>>>>>> added
>>>>>>>>                 additional
>>>>>>>>                     explanatory notes.
>>>>>>>>
>>>>>>>>                     webrev:
>>>>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>>>>
>>>>>>>>                     Testing was manually done by modifying the
>>>>>>>> launcher
>>>>>>>>                 to not run the
>>>>>>>>                     VM in a new thread, and checking the resulting
>>>>>>>> stack
>>>>>>>>                 size used.
>>>>>>>>
>>>>>>>>                     This change will only affect hosted JVMs
>>>>>>>> launched
>>>>>>>>                 with a -Xss value
>>>>>>>>                     > 2M.
>>>>>>>>
>>>>>>>>                     Thanks,
>>>>>>>>                     David
>>>>>>>>                     -----
>>>>>>>>
>>>>>>>>                     Bug eval:
>>>>>>>>
>>>>>>>>                     JDK-4441425 limits the stack to 8M as a
>>>>>>>> safeguard
>>>>>>>>                 against an
>>>>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>>>>> further
>>>>>>>>                 constrained
>>>>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>>>>
>>>>>>>>                     By 1.4.2 we have the basic form of the current
>>>>>>>>                 problematic code:
>>>>>>>>
>>>>>>>>                     #ifndef IA64
>>>>>>>>                       if (rlim.rlim_cur > 2 * K * K) 
>>>>>>>> rlim.rlim_cur =
>>>>>>>> 2 *
>>>>>>>>                 K * K;
>>>>>>>>                     #else
>>>>>>>>                       // Problem still exists RH7.2 (IA64 anyway)
>>>>>>>> but
>>>>>>>>                 2MB is a little
>>>>>>>>                 small
>>>>>>>>                       if (rlim.rlim_cur > 4 * K * K) 
>>>>>>>> rlim.rlim_cur =
>>>>>>>> 4 *
>>>>>>>>                 K * K;
>>>>>>>>                     #endif
>>>>>>>>
>>>>>>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>>>>>>                 ~(page_size() - 1);
>>>>>>>>
>>>>>>>>                       if (max_size && _initial_thread_stack_size >
>>>>>>>>                 max_size) {
>>>>>>>>                          _initial_thread_stack_size = max_size;
>>>>>>>>                       }
>>>>>>>>
>>>>>>>>                     This was added by JDK-4678676 to allow the
>>>>>>>> stack of
>>>>>>>>                 the main thread
>>>>>>>>                     to be _reduced_ below the default 2M/4M if the
>>>>>>>> -Xss
>>>>>>>>                 value was
>>>>>>>>                     smaller than that.** There was no intent to
>>>>>>>> allow
>>>>>>>>                 the stack size to
>>>>>>>>                     follow -Xss arbitrarily due to the operational
>>>>>>>>                 constraints imposed
>>>>>>>>                     by the OS/glibc at the time when dealing with
>>>>>>>> the
>>>>>>>>                 primordial process
>>>>>>>>                     thread.
>>>>>>>>
>>>>>>>>                     ** It could not actually change the actual 
>>>>>>>> stack
>>>>>>>>                 size of course, but
>>>>>>>>                     set the guard pages to limit use to the 
>>>>>>>> expected
>>>>>>>>                 stack size.
>>>>>>>>
>>>>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>>>>                 changed to create the
>>>>>>>>                     JVM in a new thread, so that it was not
>>>>>>>> limited by
>>>>>>>> the
>>>>>>>>                     idiosyncracies of the OS or thread library
>>>>>>>>                 primordial thread
>>>>>>>>                     handling. However, the stack size limitations
>>>>>>>>                 remained in place in
>>>>>>>>                     case the VM was launched from the primordial
>>>>>>>> thread
>>>>>>>>                 of a user
>>>>>>>>                     application via the JNI invocation API.
>>>>>>>>
>>>>>>>>                     I believe it should be safe to remove the 2M
>>>>>>>>                 limitation now.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>


From vladimir.kozlov at oracle.com  Wed Dec 14 17:33:54 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 Dec 2016 09:33:54 -0800
Subject: RFR(XXS): 8171236: RTM/HTM jtreg tests regression after
	transition to the new GNU-style options
In-Reply-To: <58514C91.5060505@linux.vnet.ibm.com>
References: <58514C91.5060505@linux.vnet.ibm.com>
Message-ID: <8a217a2d-d97d-698a-ba67-4727e6198201@oracle.com>

Looks good. Thank you, Gustavo, for fixing it. I will sponsor it when jdk9/hs is open for pushes.

Vladimir

On 12/14/16 5:43 AM, Gustavo Romero wrote:
> Hi,
>
> Could the following small change by reviewed please?
>
> webrev: http://cr.openjdk.java.net/~gromero/8171236/
> bug   : https://bugs.openjdk.java.net/browse/JDK-8171236
>
> Thank you and best regards,
> Gustavo
>

From gromero at linux.vnet.ibm.com  Wed Dec 14 17:50:56 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 14 Dec 2016 15:50:56 -0200
Subject: RFR(XXS): 8171236: RTM/HTM jtreg tests regression after
	transition to the new GNU-style options
In-Reply-To: <8a217a2d-d97d-698a-ba67-4727e6198201@oracle.com>
References: <58514C91.5060505@linux.vnet.ibm.com>
	<8a217a2d-d97d-698a-ba67-4727e6198201@oracle.com>
Message-ID: <58518680.9080902@linux.vnet.ibm.com>

Thanks Vladimir for reviewing and sponsoring it.

Regards,
Gustavo

On 14-12-2016 15:33, Vladimir Kozlov wrote:
> Looks good. Thank you, Gustavo, for fixing it. I will sponsor it when jdk9/hs is open for pushes.
> 
> Vladimir
> 
> On 12/14/16 5:43 AM, Gustavo Romero wrote:
>> Hi,
>>
>> Could the following small change by reviewed please?
>>
>> webrev: http://cr.openjdk.java.net/~gromero/8171236/
>> bug   : https://bugs.openjdk.java.net/browse/JDK-8171236
>>
>> Thank you and best regards,
>> Gustavo
>>
> 


From david.holmes at oracle.com  Wed Dec 14 21:06:17 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Dec 2016 07:06:17 +1000
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
	<308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
	<f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>
	<99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>
Message-ID: <ab985fc3-bf32-6578-f7b2-258cb086f0ce@oracle.com>

Can I get a second review please!

Thanks,
David

On 14/12/2016 3:49 PM, David Holmes wrote:
> Hi Dan,
>
> Thanks for the re-review. I apologize for losing the edits you
> previously suggested.
>
> More inline ...
>
> On 14/12/2016 3:12 AM, Daniel D. Daugherty wrote:
>> On 12/12/16 9:41 PM, David Holmes wrote:
>>> Okay here's the updated webrev complete with nice logging:
>>>
>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev.v2/
>>
>> src/os/linux/vm/os_linux.cpp
>>     L936:   // a user-specified value known to be greater than the
>> minimum needed.
>>         Perhaps: ... known to be at least the minimum needed.
>
> Changed.
>
>>     L932:   // can not do anything to emulate a larger stack than what
>> has been provided by
>>         Typo: 'can not' -> 'cannot'
>
> Changed.
>
>>     L936:   // Mamimum stack size is the easy part, get it from
>> RLIMIT_STACK
>>         Typo: 'Mamimum' -> 'Maximum'
>>         nit - please add a '.' to the end.
>
> Fixed.
>
>>
>>     L1125:                          SIZE_FORMAT "K, top=" INTPTR_FORMAT
>> ", bottom=" INTPTR_FORMAT "\n",
>>         Does the logging subsystem convert the "\n" into the proper
>>         output for non-*NIX platforms, e.g., Windows?
>
> No idea :) But that was leftover from when this was a ::printf (I wasn't
> sure logging would work this early in VM init - but it does).
>
> Removed.
>
>
>>     L1126:                          primordial ? "Primordial" : "User",
>> max_size/K,  _initial_thread_stack_size/K,
>>         Please add spaces around the div operator.
>
> Changed.
>
>>         Any particular reason that "Primordial" and "User" start with
>> upper case?
>
> They used to be the first things printed. :) Fixed.
>
>> Thumbs up!
>>
>> I don't need to see a new webrev if you decide to make the
>> minor edits above.
>
> Updated in place for the second reviewer (whomever they may be).
>
> Thanks,
> David
> -----
>
>> Dan
>>
>>
>>>
>>> The stack size will be the smaller of the rlimit stack and the
>>> -Xss/ThreadStackSize value. If the rlimit stack is unlimited and
>>> ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you
>>> can now get whatever primordial thread stack size you want by using
>>> ulimit and -Xss appropriately.
>>>
>>> Thanks,
>>> David
>>>
>>> On 3/12/2016 2:11 PM, David Holmes wrote:
>>>> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>>>>> On 12/1/16 10:51 PM, David Holmes wrote:
>>>>>> Investigating this further the history is quite complex, especially
>>>>>> when we start looking at other platforms. E.g. see
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>>>>
>>>>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>>>>
>>>>>> I'm very tempted to do the same on Linux.
>>>>>
>>>>> Vote: yes
>>>>
>>>> Excellent! Other votes?
>>>>
>>>>> This latest problem only comes up with -XX:ThreadStackSize=0 when the
>>>>> stack is unlimited right?
>>>>
>>>> Right.
>>>>
>>>>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>>>>> 8MB or the ulimit a viable option?
>>>>
>>>> I think so.
>>>>
>>>>> Also, it looks like Hui had some things to say about not setting the
>>>>> red/yellow zone pages on the primordial thread when we aren't using
>>>>> the
>>>>> 'java' launcher because we don't know the environment of the code that
>>>>> is using the JNI invocation API...
>>>>
>>>> Yeah but those comments seem a bit confused to me. They suggest we
>>>> shouldn't add guard pages but in fact we do add guard pages. And to me
>>>> it is no different in the primordial thread than any other natively
>>>> attached thread ie why should the initially attached thread be treated
>>>> differently to any other?** I suspect if I keep researching on this I
>>>> will find bugs regarding such differences in behaviour (eg the fact
>>>> that
>>>> -Xss wasn't working on the main thread).
>>>>
>>>> ** There are arguments both ways as to how natively attached threads
>>>> should behave. The main argument against guard page insertion is
>>>> that we
>>>> don't know how far down the existing stack we actually are - we
>>>> could be
>>>> past the depth where the guard page would be inserted! The main
>>>> argument
>>>> for (which seems to have won the day) is so that we don't get arbitrary
>>>> differences in behaviour between threads created and attached by
>>>> application native code; and threads created direct from application
>>>> Java code.
>>>>
>>>> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
>>>> solution - assuming it addresses the needs of the folk that ran into
>>>> this problem.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes
>>>>>>>> <david.holmes at oracle.com
>>>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>>
>>>>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>>>>
>>>>>>>>         I just realized I overlooked the case where
>>>>>>>> ThreadStackSize=0
>>>>>>>>         and the
>>>>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>>>>> guard
>>>>>>>>         pages
>>>>>>>>         will get inserted - I do know that I don't get a
>>>>>>>> stackoverflow
>>>>>>>>         error.
>>>>>>>>
>>>>>>>>         This needs further investigation.
>>>>>>>>
>>>>>>>>
>>>>>>>>     So what happens here is that the massive stack-size causes
>>>>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>>>>     guard-page goodness knows where, and we can consume the current
>>>>>>>>     stack until such time as we hit an unmapped or protected
>>>>>>>> region at
>>>>>>>>     which point we are killed.
>>>>>>>>
>>>>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>>>>> case we
>>>>>>>>     should not attempt to create a guard page in the initial
>>>>>>>> thread.
>>>>>>>>     That would require using a sentinel value for the stack-size.
>>>>>>>> Though
>>>>>>>>     it also presents a problem for stack-bottom - which is
>>>>>>>> implicitly
>>>>>>>>     zero. It may also give false positives in the
>>>>>>>> is_initial_thread()
>>>>>>>> check!
>>>>>>>>
>>>>>>>>     Thoughts? Suggestions?
>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe I am overlooking something, but should
>>>>>>>> os::capture_initial_thread() not call pthread_getattr_np() first to
>>>>>>>> handle the case where the VM was created on a pthread which is
>>>>>>>> not the
>>>>>>>> primordial thread and may have a different stack size than what
>>>>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>>>>> pthread_getattr_np() fails?
>>>>>>>
>>>>>>> My understanding of the problem (which likely no longer exists) is
>>>>>>> that
>>>>>>> pthread_getattr_np didn't fail as such but returned bogus values
>>>>>>> - so
>>>>>>> the problem was not detectable and so we just had to not use
>>>>>>> pthread_getattr_np.
>>>>>>>
>>>>>>>> And then we also should handle
>>>>>>>> RLIM_INFINITY. For that case, I also think not setting guard pages
>>>>>>>> would
>>>>>>>> be safest.
>>>>>>>>
>>>>>>>> We also may just refuse to run in that case, because the workaround
>>>>>>>> for
>>>>>>>> the user is easy - just set the limit before process start. Note
>>>>>>>> that on
>>>>>>>> AIX, we currently refuse to run on the primordial thread because it
>>>>>>>> may
>>>>>>>> have different page sizes than pthreads and it is impossible to get
>>>>>>>> the
>>>>>>>> exact stack locations.
>>>>>>>
>>>>>>> I was wondering why the AIX set up seemed so simple in comparison :)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         David
>>>>>>>>
>>>>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>>>>
>>>>>>>>             Hi Thomas,
>>>>>>>>
>>>>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>>>>
>>>>>>>>                 Hi David,
>>>>>>>>
>>>>>>>>                 thanks for the good explanation. Change looks
>>>>>>>> good, I
>>>>>>>>                 really like the
>>>>>>>>                 comment in capture_initial_stack().
>>>>>>>>
>>>>>>>>                 Question, with -Xss given and being smaller than
>>>>>>>> current
>>>>>>>>                 thread stack
>>>>>>>>                 size, guard pages may appear in the middle of the
>>>>>>>>                 invoking thread stack?
>>>>>>>>                 I always thought this is a bit dangerous. If your
>>>>>>>> model
>>>>>>>>                 is to have the
>>>>>>>>                 VM created from the main thread, which then goes
>>>>>>>> off to
>>>>>>>>                 do different
>>>>>>>>                 things, and have other threads then attach and run
>>>>>>>> java
>>>>>>>>                 code, main
>>>>>>>>                 thread later may crash in unrelated native code
>>>>>>>> just
>>>>>>>>                 because it reached
>>>>>>>>                 the stack depth of the hava threads? Or am I
>>>>>>>>                 misunderstanding something?
>>>>>>>>
>>>>>>>>
>>>>>>>>             There is no change to the general behaviour other than
>>>>>>>>             allowing a
>>>>>>>>             primordial process thread that launches the VM, to
>>>>>>>> now not
>>>>>>>>             have an
>>>>>>>>             effective stack limited at 2MB. The current logic will
>>>>>>>>             insert guard
>>>>>>>>             pages where ever -Xss states (as long as less than 2MB
>>>>>>>> else
>>>>>>>>             2MB), while
>>>>>>>>             with the fix the guard pages will be inserted above 2MB
>>>>>>>> - as
>>>>>>>>             dictated by
>>>>>>>>             -Xss.
>>>>>>>>
>>>>>>>>             David
>>>>>>>>             -----
>>>>>>>>
>>>>>>>>                 Thanks, Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>>>>                 <david.holmes at oracle.com
>>>>>>>> <mailto:david.holmes at oracle.com>
>>>>>>>>                 <mailto:david.holmes at oracle.com
>>>>>>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>>>>>>
>>>>>>>>                     Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>>>>
>>>>>>>>                     The bug is not public unfortunately for
>>>>>>>>                 non-technical reasons - but
>>>>>>>>                     see my eval below.
>>>>>>>>
>>>>>>>>                     Background: if you load the JVM from the
>>>>>>>> primordial
>>>>>>>>                 thread of a
>>>>>>>>                     process (not done by the java launcher since
>>>>>>>> JDK
>>>>>>>> 6),
>>>>>>>>                 there is an
>>>>>>>>                     artificial stack limit imposed on the initial
>>>>>>>> thread
>>>>>>>>                 (by sticking
>>>>>>>>                     the guard page at the limit position of the
>>>>>>>> actual
>>>>>>>>                 stack) of the
>>>>>>>>                     minimum of the -Xss setting and 2M. So if you
>>>>>>>> set
>>>>>>>>                 -Xss to > 2M it is
>>>>>>>>                     ignored for the main thread even if the true
>>>>>>>> stack
>>>>>>>>                 is, say, 8M. This
>>>>>>>>                     limitation dates back 10-15 years and is no
>>>>>>>> longer
>>>>>>>>                 relevant today
>>>>>>>>                     and should be removed (see below). I've also
>>>>>>>> added
>>>>>>>>                 additional
>>>>>>>>                     explanatory notes.
>>>>>>>>
>>>>>>>>                     webrev:
>>>>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>>>>
>>>>>>>>                     Testing was manually done by modifying the
>>>>>>>> launcher
>>>>>>>>                 to not run the
>>>>>>>>                     VM in a new thread, and checking the resulting
>>>>>>>> stack
>>>>>>>>                 size used.
>>>>>>>>
>>>>>>>>                     This change will only affect hosted JVMs
>>>>>>>> launched
>>>>>>>>                 with a -Xss value
>>>>>>>>                     > 2M.
>>>>>>>>
>>>>>>>>                     Thanks,
>>>>>>>>                     David
>>>>>>>>                     -----
>>>>>>>>
>>>>>>>>                     Bug eval:
>>>>>>>>
>>>>>>>>                     JDK-4441425 limits the stack to 8M as a
>>>>>>>> safeguard
>>>>>>>>                 against an
>>>>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>>>>> further
>>>>>>>>                 constrained
>>>>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>>>>
>>>>>>>>                     By 1.4.2 we have the basic form of the current
>>>>>>>>                 problematic code:
>>>>>>>>
>>>>>>>>                     #ifndef IA64
>>>>>>>>                       if (rlim.rlim_cur > 2 * K * K)
>>>>>>>> rlim.rlim_cur =
>>>>>>>> 2 *
>>>>>>>>                 K * K;
>>>>>>>>                     #else
>>>>>>>>                       // Problem still exists RH7.2 (IA64 anyway)
>>>>>>>> but
>>>>>>>>                 2MB is a little
>>>>>>>>                 small
>>>>>>>>                       if (rlim.rlim_cur > 4 * K * K)
>>>>>>>> rlim.rlim_cur =
>>>>>>>> 4 *
>>>>>>>>                 K * K;
>>>>>>>>                     #endif
>>>>>>>>
>>>>>>>>                       _initial_thread_stack_size = rlim.rlim_cur &
>>>>>>>>                 ~(page_size() - 1);
>>>>>>>>
>>>>>>>>                       if (max_size && _initial_thread_stack_size >
>>>>>>>>                 max_size) {
>>>>>>>>                          _initial_thread_stack_size = max_size;
>>>>>>>>                       }
>>>>>>>>
>>>>>>>>                     This was added by JDK-4678676 to allow the
>>>>>>>> stack of
>>>>>>>>                 the main thread
>>>>>>>>                     to be _reduced_ below the default 2M/4M if the
>>>>>>>> -Xss
>>>>>>>>                 value was
>>>>>>>>                     smaller than that.** There was no intent to
>>>>>>>> allow
>>>>>>>>                 the stack size to
>>>>>>>>                     follow -Xss arbitrarily due to the operational
>>>>>>>>                 constraints imposed
>>>>>>>>                     by the OS/glibc at the time when dealing with
>>>>>>>> the
>>>>>>>>                 primordial process
>>>>>>>>                     thread.
>>>>>>>>
>>>>>>>>                     ** It could not actually change the actual
>>>>>>>> stack
>>>>>>>>                 size of course, but
>>>>>>>>                     set the guard pages to limit use to the
>>>>>>>> expected
>>>>>>>>                 stack size.
>>>>>>>>
>>>>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>>>>                 changed to create the
>>>>>>>>                     JVM in a new thread, so that it was not
>>>>>>>> limited by
>>>>>>>> the
>>>>>>>>                     idiosyncracies of the OS or thread library
>>>>>>>>                 primordial thread
>>>>>>>>                     handling. However, the stack size limitations
>>>>>>>>                 remained in place in
>>>>>>>>                     case the VM was launched from the primordial
>>>>>>>> thread
>>>>>>>>                 of a user
>>>>>>>>                     application via the JNI invocation API.
>>>>>>>>
>>>>>>>>                     I believe it should be safe to remove the 2M
>>>>>>>>                 limitation now.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>

From thomas.stuefe at gmail.com  Thu Dec 15 06:43:22 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 15 Dec 2016 07:43:22 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
Message-ID: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>

Hi all,

please review this small change. It fixes the gtest build on AIX and
enables it by default.

Note that even though this is a fix for AIX, a cast needed to be added to
shared test coding. This is because xlC struggles with certain template
expansions and I had to help it by providing an explicit cast.

Because linker options were changed as well, this unfortunately this
spreads over two forest parts, so two webrevs were needed.

Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
Webrevs:
(hotspot)
http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
(top level)
http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/

Note that the toplevel change contains the newly generated configure.sh. I
was not sure if that was needed, but it is included for convenience.

Kind Regards, Thomas

From erik.joelsson at oracle.com  Thu Dec 15 09:00:14 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Dec 2016 10:00:14 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
Message-ID: <6d5037fc-e3ae-9327-cc02-18ecf819d8c6@oracle.com>

Hello Thomas,

Build changes look ok. Please note that the configure changes requires 
synchronized changes in Oracle closed configure so will need an Oracle 
sponsor to push. I assume this is intended for jdk9/hs. I will be happy 
to push it for you once the change has been cleared to go in.

/Erik

On 2016-12-15 07:43, Thomas St?fe wrote:
> Hi all,
>
> please review this small change. It fixes the gtest build on AIX and
> enables it by default.
>
> Note that even though this is a fix for AIX, a cast needed to be added to
> shared test coding. This is because xlC struggles with certain template
> expansions and I had to help it by providing an explicit cast.
>
> Because linker options were changed as well, this unfortunately this
> spreads over two forest parts, so two webrevs were needed.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
> Webrevs:
> (hotspot)
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
> (top level)
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/
>
> Note that the toplevel change contains the newly generated configure.sh. I
> was not sure if that was needed, but it is included for convenience.
>
> Kind Regards, Thomas


From kavitha.natarajan at linaro.org  Thu Dec 15 09:55:42 2016
From: kavitha.natarajan at linaro.org (Kavitha Natarajan)
Date: Thu, 15 Dec 2016 15:25:42 +0530
Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified
	along with GC options
Message-ID: <CAFtQRoL8EgUk-MJJy9a3SUNf9us6_05ZsQ8QTfyZGXa6SLqveA@mail.gmail.com>

Hi,

I am re-posting the review request on hotspot-dev which I had missed
earlier.

The below bug fix was already posted in aarch64-port-dev and
hotspot-compiler-dev mailing lists.

The following are the jtreg test cases that fail with SIGSEGV on aarch64
when "-XX:+ZeroTLAB" is specified along with a GC option:

hotspot/test/compiler/stringopts/TestStringObjectInitialization.java
hotspot/test/gc/TestSystemGC.java
hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java
hotspot/test/gc/cms/TestBubbleUpRef.java
hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java
hotspot/test/gc/parallel/TestDynShrinkHeap.java
hotspot/test/gc/stress/TestGCOld.java

Bug fix for JDK-8086053
<https://bugs.openjdk.java.net/browse/JDK-8086053> (Address
inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc.
This fix has been ported to aarch64 and the above test cases now pass on
aarch64 as well.

Below is the webrev for the aarch64 changes:

http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/

Derek White and Andrew Haley had done the review and suggested to use
zero_memory() only in C1 and zero_words() in C2. However, zero_words itself
need to be enhanced before its been used. So currenly zero_memory() is only
used for both C1 and C2.

A separate enhancement request has been raised for zero_words().

https://bugs.openjdk.java.net/browse/JDK-8171237

Please review and approve.

Thanks,
Kavitha

From thomas.stuefe at gmail.com  Thu Dec 15 10:06:38 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 15 Dec 2016 11:06:38 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <6d5037fc-e3ae-9327-cc02-18ecf819d8c6@oracle.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<6d5037fc-e3ae-9327-cc02-18ecf819d8c6@oracle.com>
Message-ID: <CAA-vtUzHZV1OVop0Agq2qL7Uf9CeNfNQdZCtCXwLbwk_hm-_QA@mail.gmail.com>

Hi Erik,

thank you! I would have needed a sponsor for the hotspot change in any
case, would sponsor this too?

Thomas

On Thu, Dec 15, 2016 at 10:00 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello Thomas,
>
> Build changes look ok. Please note that the configure changes requires
> synchronized changes in Oracle closed configure so will need an Oracle
> sponsor to push. I assume this is intended for jdk9/hs. I will be happy to
> push it for you once the change has been cleared to go in.
>
> /Erik
>
>
> On 2016-12-15 07:43, Thomas St?fe wrote:
>
>> Hi all,
>>
>> please review this small change. It fixes the gtest build on AIX and
>> enables it by default.
>>
>> Note that even though this is a fix for AIX, a cast needed to be added to
>> shared test coding. This is because xlC struggles with certain template
>> expansions and I had to help it by providing an explicit cast.
>>
>> Because linker options were changed as well, this unfortunately this
>> spreads over two forest parts, so two webrevs were needed.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
>> Webrevs:
>> (hotspot)
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>> -gtests/webrev.00/webrev/
>> (top level)
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>> -gtests/toplevel-webrev.00/webrev/
>>
>> Note that the toplevel change contains the newly generated configure.sh. I
>> was not sure if that was needed, but it is included for convenience.
>>
>> Kind Regards, Thomas
>>
>
>

From erik.joelsson at oracle.com  Thu Dec 15 10:18:04 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Dec 2016 11:18:04 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUzHZV1OVop0Agq2qL7Uf9CeNfNQdZCtCXwLbwk_hm-_QA@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<6d5037fc-e3ae-9327-cc02-18ecf819d8c6@oracle.com>
	<CAA-vtUzHZV1OVop0Agq2qL7Uf9CeNfNQdZCtCXwLbwk_hm-_QA@mail.gmail.com>
Message-ID: <e913158e-d17f-4666-94a2-6b2e6d53a675@oracle.com>

Yes, naturally.

/Erik


On 2016-12-15 11:06, Thomas St?fe wrote:
> Hi Erik,
>
> thank you! I would have needed a sponsor for the hotspot change in any 
> case, would sponsor this too?
>
> Thomas
>
> On Thu, Dec 15, 2016 at 10:00 AM, Erik Joelsson 
> <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>
>     Hello Thomas,
>
>     Build changes look ok. Please note that the configure changes
>     requires synchronized changes in Oracle closed configure so will
>     need an Oracle sponsor to push. I assume this is intended for
>     jdk9/hs. I will be happy to push it for you once the change has
>     been cleared to go in.
>
>     /Erik
>
>
>     On 2016-12-15 07:43, Thomas St?fe wrote:
>
>         Hi all,
>
>         please review this small change. It fixes the gtest build on
>         AIX and
>         enables it by default.
>
>         Note that even though this is a fix for AIX, a cast needed to
>         be added to
>         shared test coding. This is because xlC struggles with certain
>         template
>         expansions and I had to help it by providing an explicit cast.
>
>         Because linker options were changed as well, this
>         unfortunately this
>         spreads over two forest parts, so two webrevs were needed.
>
>         Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
>         <https://bugs.openjdk.java.net/browse/JDK-8171225>
>         Webrevs:
>         (hotspot)
>         http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/>
>         (top level)
>         http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/>
>
>         Note that the toplevel change contains the newly generated
>         configure.sh. I
>         was not sure if that was needed, but it is included for
>         convenience.
>
>         Kind Regards, Thomas
>
>
>


From edward.nevill at gmail.com  Thu Dec 15 10:23:44 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Thu, 15 Dec 2016 10:23:44 +0000
Subject: JEP 297: Unified arm32/arm64 Port latest Merge
In-Reply-To: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com>
References: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com>
Message-ID: <1481797424.2342.8.camel@gmail.com>

On Tue, 2016-12-13 at 13:16 -0500, Bob Vandette wrote:
> Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest.
> 
> I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday.?
> 
> http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/>
> http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/>
> http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/>
> 

Looks good. I have built the hs repo with these patches and run jtreg on x86, arm64 and arm32. Here is a summary of the results.

x86:

hotspot: passed: 1,372; failed: 30; error: 55
langtools: 3,773; failed: 12; error: 9
jdk: passed: 6,378; failed: 202; error: 10

arm64:

hotspot: passed: 1,315; failed: 31; error: 49
langtools: 3,772; failed: 10; error: 10
jdk: passed: 6,433; failed: 148; error: 8

arm32:

hotspot: 1,212; failed: 50; error: 48
langtools: passed: 3,771; failed: 14; error: 9
jdk: passed: 6,043; failed: 442; error: 18

There were no failures due to fatal errors (ie, SEGV, ABORT, assert/guarantee failure etc).

Currently running jcstress, results in approx 10 hours.

All the best,
Ed.


From david.holmes at oracle.com  Thu Dec 15 10:26:49 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Dec 2016 20:26:49 +1000
Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is
	specified along with GC options
In-Reply-To: <CAFtQRoL8EgUk-MJJy9a3SUNf9us6_05ZsQ8QTfyZGXa6SLqveA@mail.gmail.com>
References: <CAFtQRoL8EgUk-MJJy9a3SUNf9us6_05ZsQ8QTfyZGXa6SLqveA@mail.gmail.com>
Message-ID: <feca5b0c-1304-72dd-6889-8e368c8d9ae8@oracle.com>

Hi Kavitha,

Please note that is a requirement that all contributions be hosted on 
openjdk systems (cr.openjdk.java.net) or else included in-line with 
openjdk email. They can not be taken directly from external systems like 
people.linaro.org.

Thanks,
David

On 15/12/2016 7:55 PM, Kavitha Natarajan wrote:
> Hi,
>
> I am re-posting the review request on hotspot-dev which I had missed
> earlier.
>
> The below bug fix was already posted in aarch64-port-dev and
> hotspot-compiler-dev mailing lists.
>
> The following are the jtreg test cases that fail with SIGSEGV on aarch64
> when "-XX:+ZeroTLAB" is specified along with a GC option:
>
> hotspot/test/compiler/stringopts/TestStringObjectInitialization.java
> hotspot/test/gc/TestSystemGC.java
> hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java
> hotspot/test/gc/cms/TestBubbleUpRef.java
> hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java
> hotspot/test/gc/parallel/TestDynShrinkHeap.java
> hotspot/test/gc/stress/TestGCOld.java
>
> Bug fix for JDK-8086053
> <https://bugs.openjdk.java.net/browse/JDK-8086053> (Address
> inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc.
> This fix has been ported to aarch64 and the above test cases now pass on
> aarch64 as well.
>
> Below is the webrev for the aarch64 changes:
>
> http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/
>
> Derek White and Andrew Haley had done the review and suggested to use
> zero_memory() only in C1 and zero_words() in C2. However, zero_words itself
> need to be enhanced before its been used. So currenly zero_memory() is only
> used for both C1 and C2.
>
> A separate enhancement request has been raised for zero_words().
>
> https://bugs.openjdk.java.net/browse/JDK-8171237
>
> Please review and approve.
>
> Thanks,
> Kavitha
>

From david.holmes at oracle.com  Thu Dec 15 10:33:16 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Dec 2016 20:33:16 +1000
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
Message-ID: <160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>

Hi Thomas,

On 15/12/2016 4:43 PM, Thomas St?fe wrote:
> Hi all,
>
> please review this small change. It fixes the gtest build on AIX and
> enables it by default.
>
> Note that even though this is a fix for AIX, a cast needed to be added to
> shared test coding. This is because xlC struggles with certain template
> expansions and I had to help it by providing an explicit cast.

These kind of problems have been reported in the past. The way we chose 
to address them was to convert to use ASSERT_TRUE(i == NULL) rather than 
apply casts to make the ASSERT_EQ(i, NULL) compile.

Thanks,
David

> Because linker options were changed as well, this unfortunately this
> spreads over two forest parts, so two webrevs were needed.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
> Webrevs:
> (hotspot)
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
> (top level)
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/
>
> Note that the toplevel change contains the newly generated configure.sh. I
> was not sure if that was needed, but it is included for convenience.
>
> Kind Regards, Thomas
>

From serguei.spitsyn at oracle.com  Thu Dec 15 10:47:27 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 15 Dec 2016 02:47:27 -0800
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <ab985fc3-bf32-6578-f7b2-258cb086f0ce@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
	<308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
	<f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>
	<99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>
	<ab985fc3-bf32-6578-f7b2-258cb086f0ce@oracle.com>
Message-ID: <4754d399-dd1e-d967-0261-c98425b1ffbe@oracle.com>

David,


I kind of late at for review but the fix looks good to me.

Nit - no need to cast to intptr_t:

   1087 uintptr_t stack_top;
   . . .
1122 intptr_t(&rlim) < intptr_t(stack_top);

   But you probably added the cast intentionally to underline the values 
are of the same type.

Thanks,
Serguei





On 12/14/16 13:06, David Holmes wrote:
> Can I get a second review please!
>
> Thanks,
> David
>
> On 14/12/2016 3:49 PM, David Holmes wrote:
>> Hi Dan,
>>
>> Thanks for the re-review. I apologize for losing the edits you
>> previously suggested.
>>
>> More inline ...
>>
>> On 14/12/2016 3:12 AM, Daniel D. Daugherty wrote:
>>> On 12/12/16 9:41 PM, David Holmes wrote:
>>>> Okay here's the updated webrev complete with nice logging:
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev.v2/
>>>
>>> src/os/linux/vm/os_linux.cpp
>>>     L936:   // a user-specified value known to be greater than the
>>> minimum needed.
>>>         Perhaps: ... known to be at least the minimum needed.
>>
>> Changed.
>>
>>>     L932:   // can not do anything to emulate a larger stack than what
>>> has been provided by
>>>         Typo: 'can not' -> 'cannot'
>>
>> Changed.
>>
>>>     L936:   // Mamimum stack size is the easy part, get it from
>>> RLIMIT_STACK
>>>         Typo: 'Mamimum' -> 'Maximum'
>>>         nit - please add a '.' to the end.
>>
>> Fixed.
>>
>>>
>>>     L1125:                          SIZE_FORMAT "K, top=" INTPTR_FORMAT
>>> ", bottom=" INTPTR_FORMAT "\n",
>>>         Does the logging subsystem convert the "\n" into the proper
>>>         output for non-*NIX platforms, e.g., Windows?
>>
>> No idea :) But that was leftover from when this was a ::printf (I wasn't
>> sure logging would work this early in VM init - but it does).
>>
>> Removed.
>>
>>
>>>     L1126: primordial ? "Primordial" : "User",
>>> max_size/K,  _initial_thread_stack_size/K,
>>>         Please add spaces around the div operator.
>>
>> Changed.
>>
>>>         Any particular reason that "Primordial" and "User" start with
>>> upper case?
>>
>> They used to be the first things printed. :) Fixed.
>>
>>> Thumbs up!
>>>
>>> I don't need to see a new webrev if you decide to make the
>>> minor edits above.
>>
>> Updated in place for the second reviewer (whomever they may be).
>>
>> Thanks,
>> David
>> -----
>>
>>> Dan
>>>
>>>
>>>>
>>>> The stack size will be the smaller of the rlimit stack and the
>>>> -Xss/ThreadStackSize value. If the rlimit stack is unlimited and
>>>> ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you
>>>> can now get whatever primordial thread stack size you want by using
>>>> ulimit and -Xss appropriately.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 3/12/2016 2:11 PM, David Holmes wrote:
>>>>> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>>>>>> On 12/1/16 10:51 PM, David Holmes wrote:
>>>>>>> Investigating this further the history is quite complex, especially
>>>>>>> when we start looking at other platforms. E.g. see
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>>>>>
>>>>>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>>>>>
>>>>>>> I'm very tempted to do the same on Linux.
>>>>>>
>>>>>> Vote: yes
>>>>>
>>>>> Excellent! Other votes?
>>>>>
>>>>>> This latest problem only comes up with -XX:ThreadStackSize=0 when 
>>>>>> the
>>>>>> stack is unlimited right?
>>>>>
>>>>> Right.
>>>>>
>>>>>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>>>>>> 8MB or the ulimit a viable option?
>>>>>
>>>>> I think so.
>>>>>
>>>>>> Also, it looks like Hui had some things to say about not setting the
>>>>>> red/yellow zone pages on the primordial thread when we aren't using
>>>>>> the
>>>>>> 'java' launcher because we don't know the environment of the code 
>>>>>> that
>>>>>> is using the JNI invocation API...
>>>>>
>>>>> Yeah but those comments seem a bit confused to me. They suggest we
>>>>> shouldn't add guard pages but in fact we do add guard pages. And 
>>>>> to me
>>>>> it is no different in the primordial thread than any other natively
>>>>> attached thread ie why should the initially attached thread be 
>>>>> treated
>>>>> differently to any other?** I suspect if I keep researching on this I
>>>>> will find bugs regarding such differences in behaviour (eg the fact
>>>>> that
>>>>> -Xss wasn't working on the main thread).
>>>>>
>>>>> ** There are arguments both ways as to how natively attached threads
>>>>> should behave. The main argument against guard page insertion is
>>>>> that we
>>>>> don't know how far down the existing stack we actually are - we
>>>>> could be
>>>>> past the depth where the guard page would be inserted! The main
>>>>> argument
>>>>> for (which seems to have won the day) is so that we don't get 
>>>>> arbitrary
>>>>> differences in behaviour between threads created and attached by
>>>>> application native code; and threads created direct from application
>>>>> Java code.
>>>>>
>>>>> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
>>>>> solution - assuming it addresses the needs of the folk that ran into
>>>>> this problem.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>>>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes
>>>>>>>>> <david.holmes at oracle.com
>>>>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>>>>>
>>>>>>>>>         I just realized I overlooked the case where
>>>>>>>>> ThreadStackSize=0
>>>>>>>>>         and the
>>>>>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>>>>>> guard
>>>>>>>>>         pages
>>>>>>>>>         will get inserted - I do know that I don't get a
>>>>>>>>> stackoverflow
>>>>>>>>>         error.
>>>>>>>>>
>>>>>>>>>         This needs further investigation.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     So what happens here is that the massive stack-size causes
>>>>>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>>>>>     guard-page goodness knows where, and we can consume the 
>>>>>>>>> current
>>>>>>>>>     stack until such time as we hit an unmapped or protected
>>>>>>>>> region at
>>>>>>>>>     which point we are killed.
>>>>>>>>>
>>>>>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>>>>>> case we
>>>>>>>>>     should not attempt to create a guard page in the initial
>>>>>>>>> thread.
>>>>>>>>>     That would require using a sentinel value for the stack-size.
>>>>>>>>> Though
>>>>>>>>>     it also presents a problem for stack-bottom - which is
>>>>>>>>> implicitly
>>>>>>>>>     zero. It may also give false positives in the
>>>>>>>>> is_initial_thread()
>>>>>>>>> check!
>>>>>>>>>
>>>>>>>>>     Thoughts? Suggestions?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe I am overlooking something, but should
>>>>>>>>> os::capture_initial_thread() not call pthread_getattr_np() 
>>>>>>>>> first to
>>>>>>>>> handle the case where the VM was created on a pthread which is
>>>>>>>>> not the
>>>>>>>>> primordial thread and may have a different stack size than what
>>>>>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>>>>>> pthread_getattr_np() fails?
>>>>>>>>
>>>>>>>> My understanding of the problem (which likely no longer exists) is
>>>>>>>> that
>>>>>>>> pthread_getattr_np didn't fail as such but returned bogus values
>>>>>>>> - so
>>>>>>>> the problem was not detectable and so we just had to not use
>>>>>>>> pthread_getattr_np.
>>>>>>>>
>>>>>>>>> And then we also should handle
>>>>>>>>> RLIM_INFINITY. For that case, I also think not setting guard 
>>>>>>>>> pages
>>>>>>>>> would
>>>>>>>>> be safest.
>>>>>>>>>
>>>>>>>>> We also may just refuse to run in that case, because the 
>>>>>>>>> workaround
>>>>>>>>> for
>>>>>>>>> the user is easy - just set the limit before process start. Note
>>>>>>>>> that on
>>>>>>>>> AIX, we currently refuse to run on the primordial thread 
>>>>>>>>> because it
>>>>>>>>> may
>>>>>>>>> have different page sizes than pthreads and it is impossible 
>>>>>>>>> to get
>>>>>>>>> the
>>>>>>>>> exact stack locations.
>>>>>>>>
>>>>>>>> I was wondering why the AIX set up seemed so simple in 
>>>>>>>> comparison :)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         David
>>>>>>>>>
>>>>>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>>>>>
>>>>>>>>>             Hi Thomas,
>>>>>>>>>
>>>>>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>>>>>
>>>>>>>>>                 Hi David,
>>>>>>>>>
>>>>>>>>>                 thanks for the good explanation. Change looks
>>>>>>>>> good, I
>>>>>>>>>                 really like the
>>>>>>>>>                 comment in capture_initial_stack().
>>>>>>>>>
>>>>>>>>>                 Question, with -Xss given and being smaller than
>>>>>>>>> current
>>>>>>>>>                 thread stack
>>>>>>>>>                 size, guard pages may appear in the middle of the
>>>>>>>>>                 invoking thread stack?
>>>>>>>>>                 I always thought this is a bit dangerous. If your
>>>>>>>>> model
>>>>>>>>>                 is to have the
>>>>>>>>>                 VM created from the main thread, which then goes
>>>>>>>>> off to
>>>>>>>>>                 do different
>>>>>>>>>                 things, and have other threads then attach and 
>>>>>>>>> run
>>>>>>>>> java
>>>>>>>>>                 code, main
>>>>>>>>>                 thread later may crash in unrelated native code
>>>>>>>>> just
>>>>>>>>>                 because it reached
>>>>>>>>>                 the stack depth of the hava threads? Or am I
>>>>>>>>>                 misunderstanding something?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             There is no change to the general behaviour other 
>>>>>>>>> than
>>>>>>>>>             allowing a
>>>>>>>>>             primordial process thread that launches the VM, to
>>>>>>>>> now not
>>>>>>>>>             have an
>>>>>>>>>             effective stack limited at 2MB. The current logic 
>>>>>>>>> will
>>>>>>>>>             insert guard
>>>>>>>>>             pages where ever -Xss states (as long as less than 
>>>>>>>>> 2MB
>>>>>>>>> else
>>>>>>>>>             2MB), while
>>>>>>>>>             with the fix the guard pages will be inserted 
>>>>>>>>> above 2MB
>>>>>>>>> - as
>>>>>>>>>             dictated by
>>>>>>>>>             -Xss.
>>>>>>>>>
>>>>>>>>>             David
>>>>>>>>>             -----
>>>>>>>>>
>>>>>>>>>                 Thanks, Thomas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>>>>>                 <david.holmes at oracle.com
>>>>>>>>> <mailto:david.holmes at oracle.com>
>>>>>>>>>                 <mailto:david.holmes at oracle.com
>>>>>>>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>>>>>>>
>>>>>>>>>                     Bug:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>>>>>
>>>>>>>>>                     The bug is not public unfortunately for
>>>>>>>>>                 non-technical reasons - but
>>>>>>>>>                     see my eval below.
>>>>>>>>>
>>>>>>>>>                     Background: if you load the JVM from the
>>>>>>>>> primordial
>>>>>>>>>                 thread of a
>>>>>>>>>                     process (not done by the java launcher since
>>>>>>>>> JDK
>>>>>>>>> 6),
>>>>>>>>>                 there is an
>>>>>>>>>                     artificial stack limit imposed on the initial
>>>>>>>>> thread
>>>>>>>>>                 (by sticking
>>>>>>>>>                     the guard page at the limit position of the
>>>>>>>>> actual
>>>>>>>>>                 stack) of the
>>>>>>>>>                     minimum of the -Xss setting and 2M. So if you
>>>>>>>>> set
>>>>>>>>>                 -Xss to > 2M it is
>>>>>>>>>                     ignored for the main thread even if the true
>>>>>>>>> stack
>>>>>>>>>                 is, say, 8M. This
>>>>>>>>>                     limitation dates back 10-15 years and is no
>>>>>>>>> longer
>>>>>>>>>                 relevant today
>>>>>>>>>                     and should be removed (see below). I've also
>>>>>>>>> added
>>>>>>>>>                 additional
>>>>>>>>>                     explanatory notes.
>>>>>>>>>
>>>>>>>>>                     webrev:
>>>>>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>>>>>
>>>>>>>>>                     Testing was manually done by modifying the
>>>>>>>>> launcher
>>>>>>>>>                 to not run the
>>>>>>>>>                     VM in a new thread, and checking the 
>>>>>>>>> resulting
>>>>>>>>> stack
>>>>>>>>>                 size used.
>>>>>>>>>
>>>>>>>>>                     This change will only affect hosted JVMs
>>>>>>>>> launched
>>>>>>>>>                 with a -Xss value
>>>>>>>>>                     > 2M.
>>>>>>>>>
>>>>>>>>>                     Thanks,
>>>>>>>>>                     David
>>>>>>>>>                     -----
>>>>>>>>>
>>>>>>>>>                     Bug eval:
>>>>>>>>>
>>>>>>>>>                     JDK-4441425 limits the stack to 8M as a
>>>>>>>>> safeguard
>>>>>>>>>                 against an
>>>>>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>>>>>> further
>>>>>>>>>                 constrained
>>>>>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>>>>>
>>>>>>>>>                     By 1.4.2 we have the basic form of the 
>>>>>>>>> current
>>>>>>>>>                 problematic code:
>>>>>>>>>
>>>>>>>>>                     #ifndef IA64
>>>>>>>>>                       if (rlim.rlim_cur > 2 * K * K)
>>>>>>>>> rlim.rlim_cur =
>>>>>>>>> 2 *
>>>>>>>>>                 K * K;
>>>>>>>>>                     #else
>>>>>>>>>                       // Problem still exists RH7.2 (IA64 anyway)
>>>>>>>>> but
>>>>>>>>>                 2MB is a little
>>>>>>>>>                 small
>>>>>>>>>                       if (rlim.rlim_cur > 4 * K * K)
>>>>>>>>> rlim.rlim_cur =
>>>>>>>>> 4 *
>>>>>>>>>                 K * K;
>>>>>>>>>                     #endif
>>>>>>>>>
>>>>>>>>>                       _initial_thread_stack_size = 
>>>>>>>>> rlim.rlim_cur &
>>>>>>>>>                 ~(page_size() - 1);
>>>>>>>>>
>>>>>>>>>                       if (max_size && 
>>>>>>>>> _initial_thread_stack_size >
>>>>>>>>>                 max_size) {
>>>>>>>>> _initial_thread_stack_size = max_size;
>>>>>>>>>                       }
>>>>>>>>>
>>>>>>>>>                     This was added by JDK-4678676 to allow the
>>>>>>>>> stack of
>>>>>>>>>                 the main thread
>>>>>>>>>                     to be _reduced_ below the default 2M/4M if 
>>>>>>>>> the
>>>>>>>>> -Xss
>>>>>>>>>                 value was
>>>>>>>>>                     smaller than that.** There was no intent to
>>>>>>>>> allow
>>>>>>>>>                 the stack size to
>>>>>>>>>                     follow -Xss arbitrarily due to the 
>>>>>>>>> operational
>>>>>>>>>                 constraints imposed
>>>>>>>>>                     by the OS/glibc at the time when dealing with
>>>>>>>>> the
>>>>>>>>>                 primordial process
>>>>>>>>>                     thread.
>>>>>>>>>
>>>>>>>>>                     ** It could not actually change the actual
>>>>>>>>> stack
>>>>>>>>>                 size of course, but
>>>>>>>>>                     set the guard pages to limit use to the
>>>>>>>>> expected
>>>>>>>>>                 stack size.
>>>>>>>>>
>>>>>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>>>>>                 changed to create the
>>>>>>>>>                     JVM in a new thread, so that it was not
>>>>>>>>> limited by
>>>>>>>>> the
>>>>>>>>>                     idiosyncracies of the OS or thread library
>>>>>>>>>                 primordial thread
>>>>>>>>>                     handling. However, the stack size limitations
>>>>>>>>>                 remained in place in
>>>>>>>>>                     case the VM was launched from the primordial
>>>>>>>>> thread
>>>>>>>>>                 of a user
>>>>>>>>>                     application via the JNI invocation API.
>>>>>>>>>
>>>>>>>>>                     I believe it should be safe to remove the 2M
>>>>>>>>>                 limitation now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>


From volker.simonis at gmail.com  Thu Dec 15 11:24:54 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 15 Dec 2016 12:24:54 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
Message-ID: <CA+3eh132sUhb1BU6r4zfhr4t3gbib+Y8ZnRKyuu1E8hiPTV__g@mail.gmail.com>

Hi Thomas,

can you please try to fix the TOC issues for the gtest build only. I
don't like that we have to build everything with '-qpic=large
-bbigtoc' just because of gtest.

Isn't it possible to just set these parameters in
hotspot/make/lib/CompileGtest.gmk by using CFLAGS_aix/LDFALGS_aix?

Thanks,
Volker


On Thu, Dec 15, 2016 at 7:43 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi all,
>
> please review this small change. It fixes the gtest build on AIX and enables
> it by default.
>
> Note that even though this is a fix for AIX, a cast needed to be added to
> shared test coding. This is because xlC struggles with certain template
> expansions and I had to help it by providing an explicit cast.
>
> Because linker options were changed as well, this unfortunately this spreads
> over two forest parts, so two webrevs were needed.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
> Webrevs:
> (hotspot)
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
> (top level)
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/
>
> Note that the toplevel change contains the newly generated configure.sh. I
> was not sure if that was needed, but it is included for convenience.
>
> Kind Regards, Thomas

From gromero at linux.vnet.ibm.com  Thu Dec 15 21:03:30 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 15 Dec 2016 19:03:30 -0200
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
Message-ID: <58530522.3030102@linux.vnet.ibm.com>

Hi,

Could the following change be reviewed please?

webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
bug   : https://bugs.openjdk.java.net/browse/JDK-8171266

Thank you.


Regards,
Gustavo


From david.holmes at oracle.com  Thu Dec 15 23:14:50 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 16 Dec 2016 09:14:50 +1000
Subject: RFR: 8170307: Stack size option -Xss is ignored
In-Reply-To: <4754d399-dd1e-d967-0261-c98425b1ffbe@oracle.com>
References: <e71bee88-fc90-4556-1a43-2423c446e1af@oracle.com>
	<CAA-vtUxJfRgXkpJUqqQ170BSC0a9G6M4pZn28y7dRqXdL5dCFQ@mail.gmail.com>
	<1b894e26-011e-05e4-6e24-91bebd4d465c@oracle.com>
	<9daf1211-d1f9-7a1c-bee4-19612766a269@oracle.com>
	<52c86d04-ff44-a720-f376-a2a34d091b02@oracle.com>
	<CAA-vtUxe7O-ry0Lr4YHsXOmZgDJ0Lu1U==WR=T54iwwqswNDeg@mail.gmail.com>
	<d9cde803-14a1-a3ed-005b-485691eef018@oracle.com>
	<e91de716-f607-1530-b009-70c411e9c6de@oracle.com>
	<07519d5f-7bd7-a20d-1c1d-5dc1aa2409e7@oracle.com>
	<1feedf21-5b45-0ae3-94bf-c93d43db0b06@oracle.com>
	<308cbd4c-c69b-f7d7-ad86-69243cd57051@oracle.com>
	<f47e01b4-cfaf-2f22-a6ef-b00912109483@oracle.com>
	<99f9c2a8-261b-0d70-ca31-8ffa5af53d65@oracle.com>
	<ab985fc3-bf32-6578-f7b2-258cb086f0ce@oracle.com>
	<4754d399-dd1e-d967-0261-c98425b1ffbe@oracle.com>
Message-ID: <2636f22d-5385-453c-f720-e5b685c3a6a7@oracle.com>

On 15/12/2016 8:47 PM, serguei.spitsyn at oracle.com wrote:
> David,
>
>
> I kind of late at for review but the fix looks good to me.

Thanks Serguei! Never too late when you still need a review :)

> Nit - no need to cast to intptr_t:
>
>   1087 uintptr_t stack_top;
>   . . .
> 1122 intptr_t(&rlim) < intptr_t(stack_top);
>
>   But you probably added the cast intentionally to underline the values
> are of the same type.

Yes but I picked intptr_t arbitrarily. Have switched to uintptr_t and 
dropped the cast on stack_top.

Thanks,
David

> Thanks,
> Serguei
>
>
>
>
>
> On 12/14/16 13:06, David Holmes wrote:
>> Can I get a second review please!
>>
>> Thanks,
>> David
>>
>> On 14/12/2016 3:49 PM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> Thanks for the re-review. I apologize for losing the edits you
>>> previously suggested.
>>>
>>> More inline ...
>>>
>>> On 14/12/2016 3:12 AM, Daniel D. Daugherty wrote:
>>>> On 12/12/16 9:41 PM, David Holmes wrote:
>>>>> Okay here's the updated webrev complete with nice logging:
>>>>>
>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev.v2/
>>>>
>>>> src/os/linux/vm/os_linux.cpp
>>>>     L936:   // a user-specified value known to be greater than the
>>>> minimum needed.
>>>>         Perhaps: ... known to be at least the minimum needed.
>>>
>>> Changed.
>>>
>>>>     L932:   // can not do anything to emulate a larger stack than what
>>>> has been provided by
>>>>         Typo: 'can not' -> 'cannot'
>>>
>>> Changed.
>>>
>>>>     L936:   // Mamimum stack size is the easy part, get it from
>>>> RLIMIT_STACK
>>>>         Typo: 'Mamimum' -> 'Maximum'
>>>>         nit - please add a '.' to the end.
>>>
>>> Fixed.
>>>
>>>>
>>>>     L1125:                          SIZE_FORMAT "K, top=" INTPTR_FORMAT
>>>> ", bottom=" INTPTR_FORMAT "\n",
>>>>         Does the logging subsystem convert the "\n" into the proper
>>>>         output for non-*NIX platforms, e.g., Windows?
>>>
>>> No idea :) But that was leftover from when this was a ::printf (I wasn't
>>> sure logging would work this early in VM init - but it does).
>>>
>>> Removed.
>>>
>>>
>>>>     L1126: primordial ? "Primordial" : "User",
>>>> max_size/K,  _initial_thread_stack_size/K,
>>>>         Please add spaces around the div operator.
>>>
>>> Changed.
>>>
>>>>         Any particular reason that "Primordial" and "User" start with
>>>> upper case?
>>>
>>> They used to be the first things printed. :) Fixed.
>>>
>>>> Thumbs up!
>>>>
>>>> I don't need to see a new webrev if you decide to make the
>>>> minor edits above.
>>>
>>> Updated in place for the second reviewer (whomever they may be).
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> The stack size will be the smaller of the rlimit stack and the
>>>>> -Xss/ThreadStackSize value. If the rlimit stack is unlimited and
>>>>> ThreadStackSize==0 then we clamp it at 8MB as we do on Solaris. So you
>>>>> can now get whatever primordial thread stack size you want by using
>>>>> ulimit and -Xss appropriately.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 3/12/2016 2:11 PM, David Holmes wrote:
>>>>>> On 3/12/2016 9:12 AM, Daniel D. Daugherty wrote:
>>>>>>> On 12/1/16 10:51 PM, David Holmes wrote:
>>>>>>>> Investigating this further the history is quite complex, especially
>>>>>>>> when we start looking at other platforms. E.g. see
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6269555
>>>>>>>>
>>>>>>>> Solaris actually hard-wires an 8MB limit for the primordial thread.
>>>>>>>>
>>>>>>>> I'm very tempted to do the same on Linux.
>>>>>>>
>>>>>>> Vote: yes
>>>>>>
>>>>>> Excellent! Other votes?
>>>>>>
>>>>>>> This latest problem only comes up with -XX:ThreadStackSize=0 when
>>>>>>> the
>>>>>>> stack is unlimited right?
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>>> When -XX:ThreadStackSize=0 is specified, is taking the smaller of
>>>>>>> 8MB or the ulimit a viable option?
>>>>>>
>>>>>> I think so.
>>>>>>
>>>>>>> Also, it looks like Hui had some things to say about not setting the
>>>>>>> red/yellow zone pages on the primordial thread when we aren't using
>>>>>>> the
>>>>>>> 'java' launcher because we don't know the environment of the code
>>>>>>> that
>>>>>>> is using the JNI invocation API...
>>>>>>
>>>>>> Yeah but those comments seem a bit confused to me. They suggest we
>>>>>> shouldn't add guard pages but in fact we do add guard pages. And
>>>>>> to me
>>>>>> it is no different in the primordial thread than any other natively
>>>>>> attached thread ie why should the initially attached thread be
>>>>>> treated
>>>>>> differently to any other?** I suspect if I keep researching on this I
>>>>>> will find bugs regarding such differences in behaviour (eg the fact
>>>>>> that
>>>>>> -Xss wasn't working on the main thread).
>>>>>>
>>>>>> ** There are arguments both ways as to how natively attached threads
>>>>>> should behave. The main argument against guard page insertion is
>>>>>> that we
>>>>>> don't know how far down the existing stack we actually are - we
>>>>>> could be
>>>>>> past the depth where the guard page would be inserted! The main
>>>>>> argument
>>>>>> for (which seems to have won the day) is so that we don't get
>>>>>> arbitrary
>>>>>> differences in behaviour between threads created and attached by
>>>>>> application native code; and threads created direct from application
>>>>>> Java code.
>>>>>>
>>>>>> Anyway, simply upping the 2M limit on Linux to 8M seems a simple
>>>>>> solution - assuming it addresses the needs of the folk that ran into
>>>>>> this problem.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>> On 30/11/2016 6:46 PM, David Holmes wrote:
>>>>>>>>> On 30/11/2016 6:17 PM, Thomas St?fe wrote:
>>>>>>>>>> On Wed, Nov 30, 2016 at 8:35 AM, David Holmes
>>>>>>>>>> <david.holmes at oracle.com
>>>>>>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>     On 29/11/2016 10:25 PM, David Holmes wrote:
>>>>>>>>>>
>>>>>>>>>>         I just realized I overlooked the case where
>>>>>>>>>> ThreadStackSize=0
>>>>>>>>>>         and the
>>>>>>>>>>         stack is unlimited. In that case it isn't clear where the
>>>>>>>>>> guard
>>>>>>>>>>         pages
>>>>>>>>>>         will get inserted - I do know that I don't get a
>>>>>>>>>> stackoverflow
>>>>>>>>>>         error.
>>>>>>>>>>
>>>>>>>>>>         This needs further investigation.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     So what happens here is that the massive stack-size causes
>>>>>>>>>>     stack-bottom to be higher than stack-top! So we will set a
>>>>>>>>>>     guard-page goodness knows where, and we can consume the
>>>>>>>>>> current
>>>>>>>>>>     stack until such time as we hit an unmapped or protected
>>>>>>>>>> region at
>>>>>>>>>>     which point we are killed.
>>>>>>>>>>
>>>>>>>>>>     I'm not sure what to do here. My gut feel is that in such a
>>>>>>>>>> case we
>>>>>>>>>>     should not attempt to create a guard page in the initial
>>>>>>>>>> thread.
>>>>>>>>>>     That would require using a sentinel value for the stack-size.
>>>>>>>>>> Though
>>>>>>>>>>     it also presents a problem for stack-bottom - which is
>>>>>>>>>> implicitly
>>>>>>>>>>     zero. It may also give false positives in the
>>>>>>>>>> is_initial_thread()
>>>>>>>>>> check!
>>>>>>>>>>
>>>>>>>>>>     Thoughts? Suggestions?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe I am overlooking something, but should
>>>>>>>>>> os::capture_initial_thread() not call pthread_getattr_np()
>>>>>>>>>> first to
>>>>>>>>>> handle the case where the VM was created on a pthread which is
>>>>>>>>>> not the
>>>>>>>>>> primordial thread and may have a different stack size than what
>>>>>>>>>> getrlimit returns? And fall back to getrlimit only if
>>>>>>>>>> pthread_getattr_np() fails?
>>>>>>>>>
>>>>>>>>> My understanding of the problem (which likely no longer exists) is
>>>>>>>>> that
>>>>>>>>> pthread_getattr_np didn't fail as such but returned bogus values
>>>>>>>>> - so
>>>>>>>>> the problem was not detectable and so we just had to not use
>>>>>>>>> pthread_getattr_np.
>>>>>>>>>
>>>>>>>>>> And then we also should handle
>>>>>>>>>> RLIM_INFINITY. For that case, I also think not setting guard
>>>>>>>>>> pages
>>>>>>>>>> would
>>>>>>>>>> be safest.
>>>>>>>>>>
>>>>>>>>>> We also may just refuse to run in that case, because the
>>>>>>>>>> workaround
>>>>>>>>>> for
>>>>>>>>>> the user is easy - just set the limit before process start. Note
>>>>>>>>>> that on
>>>>>>>>>> AIX, we currently refuse to run on the primordial thread
>>>>>>>>>> because it
>>>>>>>>>> may
>>>>>>>>>> have different page sizes than pthreads and it is impossible
>>>>>>>>>> to get
>>>>>>>>>> the
>>>>>>>>>> exact stack locations.
>>>>>>>>>
>>>>>>>>> I was wondering why the AIX set up seemed so simple in
>>>>>>>>> comparison :)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         David
>>>>>>>>>>
>>>>>>>>>>         On 29/11/2016 9:59 PM, David Holmes wrote:
>>>>>>>>>>
>>>>>>>>>>             Hi Thomas,
>>>>>>>>>>
>>>>>>>>>>             On 29/11/2016 8:39 PM, Thomas St?fe wrote:
>>>>>>>>>>
>>>>>>>>>>                 Hi David,
>>>>>>>>>>
>>>>>>>>>>                 thanks for the good explanation. Change looks
>>>>>>>>>> good, I
>>>>>>>>>>                 really like the
>>>>>>>>>>                 comment in capture_initial_stack().
>>>>>>>>>>
>>>>>>>>>>                 Question, with -Xss given and being smaller than
>>>>>>>>>> current
>>>>>>>>>>                 thread stack
>>>>>>>>>>                 size, guard pages may appear in the middle of the
>>>>>>>>>>                 invoking thread stack?
>>>>>>>>>>                 I always thought this is a bit dangerous. If your
>>>>>>>>>> model
>>>>>>>>>>                 is to have the
>>>>>>>>>>                 VM created from the main thread, which then goes
>>>>>>>>>> off to
>>>>>>>>>>                 do different
>>>>>>>>>>                 things, and have other threads then attach and
>>>>>>>>>> run
>>>>>>>>>> java
>>>>>>>>>>                 code, main
>>>>>>>>>>                 thread later may crash in unrelated native code
>>>>>>>>>> just
>>>>>>>>>>                 because it reached
>>>>>>>>>>                 the stack depth of the hava threads? Or am I
>>>>>>>>>>                 misunderstanding something?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>             There is no change to the general behaviour other
>>>>>>>>>> than
>>>>>>>>>>             allowing a
>>>>>>>>>>             primordial process thread that launches the VM, to
>>>>>>>>>> now not
>>>>>>>>>>             have an
>>>>>>>>>>             effective stack limited at 2MB. The current logic
>>>>>>>>>> will
>>>>>>>>>>             insert guard
>>>>>>>>>>             pages where ever -Xss states (as long as less than
>>>>>>>>>> 2MB
>>>>>>>>>> else
>>>>>>>>>>             2MB), while
>>>>>>>>>>             with the fix the guard pages will be inserted
>>>>>>>>>> above 2MB
>>>>>>>>>> - as
>>>>>>>>>>             dictated by
>>>>>>>>>>             -Xss.
>>>>>>>>>>
>>>>>>>>>>             David
>>>>>>>>>>             -----
>>>>>>>>>>
>>>>>>>>>>                 Thanks, Thomas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                 On Fri, Nov 25, 2016 at 11:38 AM, David Holmes
>>>>>>>>>>                 <david.holmes at oracle.com
>>>>>>>>>> <mailto:david.holmes at oracle.com>
>>>>>>>>>>                 <mailto:david.holmes at oracle.com
>>>>>>>>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>>>>>>>>
>>>>>>>>>>                     Bug:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8170307>>
>>>>>>>>>>
>>>>>>>>>>                     The bug is not public unfortunately for
>>>>>>>>>>                 non-technical reasons - but
>>>>>>>>>>                     see my eval below.
>>>>>>>>>>
>>>>>>>>>>                     Background: if you load the JVM from the
>>>>>>>>>> primordial
>>>>>>>>>>                 thread of a
>>>>>>>>>>                     process (not done by the java launcher since
>>>>>>>>>> JDK
>>>>>>>>>> 6),
>>>>>>>>>>                 there is an
>>>>>>>>>>                     artificial stack limit imposed on the initial
>>>>>>>>>> thread
>>>>>>>>>>                 (by sticking
>>>>>>>>>>                     the guard page at the limit position of the
>>>>>>>>>> actual
>>>>>>>>>>                 stack) of the
>>>>>>>>>>                     minimum of the -Xss setting and 2M. So if you
>>>>>>>>>> set
>>>>>>>>>>                 -Xss to > 2M it is
>>>>>>>>>>                     ignored for the main thread even if the true
>>>>>>>>>> stack
>>>>>>>>>>                 is, say, 8M. This
>>>>>>>>>>                     limitation dates back 10-15 years and is no
>>>>>>>>>> longer
>>>>>>>>>>                 relevant today
>>>>>>>>>>                     and should be removed (see below). I've also
>>>>>>>>>> added
>>>>>>>>>>                 additional
>>>>>>>>>>                     explanatory notes.
>>>>>>>>>>
>>>>>>>>>>                     webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>
>>>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/
>>>>>>>>>> <http://cr.openjdk.java.net/~dholmes/8170307/webrev/>>
>>>>>>>>>>
>>>>>>>>>>                     Testing was manually done by modifying the
>>>>>>>>>> launcher
>>>>>>>>>>                 to not run the
>>>>>>>>>>                     VM in a new thread, and checking the
>>>>>>>>>> resulting
>>>>>>>>>> stack
>>>>>>>>>>                 size used.
>>>>>>>>>>
>>>>>>>>>>                     This change will only affect hosted JVMs
>>>>>>>>>> launched
>>>>>>>>>>                 with a -Xss value
>>>>>>>>>>                     > 2M.
>>>>>>>>>>
>>>>>>>>>>                     Thanks,
>>>>>>>>>>                     David
>>>>>>>>>>                     -----
>>>>>>>>>>
>>>>>>>>>>                     Bug eval:
>>>>>>>>>>
>>>>>>>>>>                     JDK-4441425 limits the stack to 8M as a
>>>>>>>>>> safeguard
>>>>>>>>>>                 against an
>>>>>>>>>>                     unlimited value from getrlimit in 1.3.1, but
>>>>>>>>>> further
>>>>>>>>>>                 constrained
>>>>>>>>>>                     that to 2M in 1.4.0 due to JDK-4466587.
>>>>>>>>>>
>>>>>>>>>>                     By 1.4.2 we have the basic form of the
>>>>>>>>>> current
>>>>>>>>>>                 problematic code:
>>>>>>>>>>
>>>>>>>>>>                     #ifndef IA64
>>>>>>>>>>                       if (rlim.rlim_cur > 2 * K * K)
>>>>>>>>>> rlim.rlim_cur =
>>>>>>>>>> 2 *
>>>>>>>>>>                 K * K;
>>>>>>>>>>                     #else
>>>>>>>>>>                       // Problem still exists RH7.2 (IA64 anyway)
>>>>>>>>>> but
>>>>>>>>>>                 2MB is a little
>>>>>>>>>>                 small
>>>>>>>>>>                       if (rlim.rlim_cur > 4 * K * K)
>>>>>>>>>> rlim.rlim_cur =
>>>>>>>>>> 4 *
>>>>>>>>>>                 K * K;
>>>>>>>>>>                     #endif
>>>>>>>>>>
>>>>>>>>>>                       _initial_thread_stack_size =
>>>>>>>>>> rlim.rlim_cur &
>>>>>>>>>>                 ~(page_size() - 1);
>>>>>>>>>>
>>>>>>>>>>                       if (max_size &&
>>>>>>>>>> _initial_thread_stack_size >
>>>>>>>>>>                 max_size) {
>>>>>>>>>> _initial_thread_stack_size = max_size;
>>>>>>>>>>                       }
>>>>>>>>>>
>>>>>>>>>>                     This was added by JDK-4678676 to allow the
>>>>>>>>>> stack of
>>>>>>>>>>                 the main thread
>>>>>>>>>>                     to be _reduced_ below the default 2M/4M if
>>>>>>>>>> the
>>>>>>>>>> -Xss
>>>>>>>>>>                 value was
>>>>>>>>>>                     smaller than that.** There was no intent to
>>>>>>>>>> allow
>>>>>>>>>>                 the stack size to
>>>>>>>>>>                     follow -Xss arbitrarily due to the
>>>>>>>>>> operational
>>>>>>>>>>                 constraints imposed
>>>>>>>>>>                     by the OS/glibc at the time when dealing with
>>>>>>>>>> the
>>>>>>>>>>                 primordial process
>>>>>>>>>>                     thread.
>>>>>>>>>>
>>>>>>>>>>                     ** It could not actually change the actual
>>>>>>>>>> stack
>>>>>>>>>>                 size of course, but
>>>>>>>>>>                     set the guard pages to limit use to the
>>>>>>>>>> expected
>>>>>>>>>>                 stack size.
>>>>>>>>>>
>>>>>>>>>>                     In JDK 6, under JDK-6316197, the launcher was
>>>>>>>>>>                 changed to create the
>>>>>>>>>>                     JVM in a new thread, so that it was not
>>>>>>>>>> limited by
>>>>>>>>>> the
>>>>>>>>>>                     idiosyncracies of the OS or thread library
>>>>>>>>>>                 primordial thread
>>>>>>>>>>                     handling. However, the stack size limitations
>>>>>>>>>>                 remained in place in
>>>>>>>>>>                     case the VM was launched from the primordial
>>>>>>>>>> thread
>>>>>>>>>>                 of a user
>>>>>>>>>>                     application via the JNI invocation API.
>>>>>>>>>>
>>>>>>>>>>                     I believe it should be safe to remove the 2M
>>>>>>>>>>                 limitation now.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>
>

From kavitha.natarajan at linaro.org  Fri Dec 16 12:17:10 2016
From: kavitha.natarajan at linaro.org (Kavitha Natarajan)
Date: Fri, 16 Dec 2016 17:47:10 +0530
Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is
	specified along with GC options
In-Reply-To: <CACc5Y6Rnajis70BhbxPrgOuZX5ZvxaEdg3=bwX-zEFvLcJhvug@mail.gmail.com>
References: <CAFtQRoL8EgUk-MJJy9a3SUNf9us6_05ZsQ8QTfyZGXa6SLqveA@mail.gmail.com>
	<d51b56ec-a45a-0ea3-5b8a-2052590e6aaa@redhat.com>
	<CAFtQRoJ28=BUAxO=qHRbZWKX4XJaD0OoO+LNk7aZ6CinWhhQaA@mail.gmail.com>
	<CACc5Y6Rnajis70BhbxPrgOuZX5ZvxaEdg3=bwX-zEFvLcJhvug@mail.gmail.com>
Message-ID: <CAFtQRoLdN87ww=vHN73C1MESgPhe7vPDQA3y-H0zXh736M6FnQ@mail.gmail.com>

Thanks a lot Felix for creating the patch, as I do not have access to this
system.

Regards,
Kavitha

On 16 December 2016 at 17:29, Felix Yang <felix.yang at linaro.org> wrote:

> Hi,
>
>     Thanks for fixing the bug.  New webrev created on behalf of Kavitha:
>     http://cr.openjdk.java.net/~fyang/8169177/webrev.01/
>     Tested again with JTreg hotspot, no regressions.  OK to push?
>
> Thanks for your help,
> Felix
>
> On 16 December 2016 at 18:28, Kavitha Natarajan <
> kavitha.natarajan at linaro.org> wrote:
>
>> Thanks Andrew.
>>
>> Regards,
>> Kavitha
>>
>> On 15 December 2016 at 15:34, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 15/12/16 09:55, Kavitha Natarajan wrote:
>>> > Below is the webrev for the aarch64 changes:
>>> >
>>> > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/
>>>
>>> This is OK.
>>>
>>> Andrew.
>>>
>>>
>>
>

From staffan.larsen at oracle.com  Fri Dec 16 13:45:07 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 16 Dec 2016 14:45:07 +0100
Subject: RFR: 8171366 macOS: Do not run failure handler commands that require
	Developer mode access
Message-ID: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>

The failure handler (test/failure_handler) runs a number of commands when it detects a timeout in one of the tests. On OS X some of these commands require "Developer mode" (like getting a core file). If "Developer mode" is not enabled, the tools will open a modal dialog. This is problematic when running automated test. The dialog will also prevent other tests from completing. 

This patch changes the Failure handler to check if "Developer mode" is enabled before running commands that require it. It also includes the output of "DevToolsSecurity ?status? which is used to check for ?Developer mode?.

Please review the webrev below,
/Staffan


bug: https://bugs.openjdk.java.net/browse/JDK-8171366
webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/

From erik.joelsson at oracle.com  Fri Dec 16 14:05:18 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 16 Dec 2016 15:05:18 +0100
Subject: RFR: 8171366 macOS: Do not run failure handler commands that
	require Developer mode access
In-Reply-To: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>
References: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>
Message-ID: <a447544a-e0ec-860f-e29d-5eee1dd695de@oracle.com>

I would recommend using the -q flag to grep instead of piping to 
/dev/null. Otherwise I think this looks ok.

/Erik


On 2016-12-16 14:45, Staffan Larsen wrote:
> The failure handler (test/failure_handler) runs a number of commands when it detects a timeout in one of the tests. On OS X some of these commands require "Developer mode" (like getting a core file). If "Developer mode" is not enabled, the tools will open a modal dialog. This is problematic when running automated test. The dialog will also prevent other tests from completing.
>
> This patch changes the Failure handler to check if "Developer mode" is enabled before running commands that require it. It also includes the output of "DevToolsSecurity ?status? which is used to check for ?Developer mode?.
>
> Please review the webrev below,
> /Staffan
>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/


From staffan.larsen at oracle.com  Fri Dec 16 14:10:16 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 16 Dec 2016 15:10:16 +0100
Subject: RFR: 8171366 macOS: Do not run failure handler commands that
	require Developer mode access
In-Reply-To: <a447544a-e0ec-860f-e29d-5eee1dd695de@oracle.com>
References: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>
	<a447544a-e0ec-860f-e29d-5eee1dd695de@oracle.com>
Message-ID: <83A7F286-F62C-4D47-AF6C-56EBB3734DE1@oracle.com>

Good point. New webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.01/ <http://cr.openjdk.java.net/~sla/8171366/webrev.01/>

Thanks!

> On 16 Dec 2016, at 15:05, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> I would recommend using the -q flag to grep instead of piping to /dev/null. Otherwise I think this looks ok.
> 
> /Erik
> 
> 
> On 2016-12-16 14:45, Staffan Larsen wrote:
>> The failure handler (test/failure_handler) runs a number of commands when it detects a timeout in one of the tests. On OS X some of these commands require "Developer mode" (like getting a core file). If "Developer mode" is not enabled, the tools will open a modal dialog. This is problematic when running automated test. The dialog will also prevent other tests from completing.
>> 
>> This patch changes the Failure handler to check if "Developer mode" is enabled before running commands that require it. It also includes the output of "DevToolsSecurity ?status? which is used to check for ?Developer mode?.
>> 
>> Please review the webrev below,
>> /Staffan
>> 
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
>> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/
> 


From erik.joelsson at oracle.com  Fri Dec 16 16:12:01 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 16 Dec 2016 17:12:01 +0100
Subject: RFR: 8171366 macOS: Do not run failure handler commands that
	require Developer mode access
In-Reply-To: <83A7F286-F62C-4D47-AF6C-56EBB3734DE1@oracle.com>
References: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>
	<a447544a-e0ec-860f-e29d-5eee1dd695de@oracle.com>
	<83A7F286-F62C-4D47-AF6C-56EBB3734DE1@oracle.com>
Message-ID: <6aa231bc-66b1-ec62-4e0b-c420f592e924@oracle.com>

Looks good.

/Erik


On 2016-12-16 15:10, Staffan Larsen wrote:
> Good point. New webrev: 
> http://cr.openjdk.java.net/~sla/8171366/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esla/8171366/webrev.01/>
>
> Thanks!
>
>> On 16 Dec 2016, at 15:05, Erik Joelsson <erik.joelsson at oracle.com 
>> <mailto:erik.joelsson at oracle.com>> wrote:
>>
>> I would recommend using the -q flag to grep instead of piping to 
>> /dev/null. Otherwise I think this looks ok.
>>
>> /Erik
>>
>>
>> On 2016-12-16 14:45, Staffan Larsen wrote:
>>> The failure handler (test/failure_handler) runs a number of commands 
>>> when it detects a timeout in one of the tests. On OS X some of these 
>>> commands require "Developer mode" (like getting a core file). If 
>>> "Developer mode" is not enabled, the tools will open a modal dialog. 
>>> This is problematic when running automated test. The dialog will 
>>> also prevent other tests from completing.
>>>
>>> This patch changes the Failure handler to check if "Developer mode" 
>>> is enabled before running commands that require it. It also includes 
>>> the output of "DevToolsSecurity ?status? which is used to check for 
>>> ?Developer mode?.
>>>
>>> Please review the webrev below,
>>> /Staffan
>>>
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
>>> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Esla/8171366/webrev.00/>
>>
>


From igor.ignatyev at oracle.com  Fri Dec 16 18:45:03 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 16 Dec 2016 21:45:03 +0300
Subject: RFR: 8171366 macOS: Do not run failure handler commands that
	require Developer mode access
In-Reply-To: <83A7F286-F62C-4D47-AF6C-56EBB3734DE1@oracle.com>
References: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>
	<a447544a-e0ec-860f-e29d-5eee1dd695de@oracle.com>
	<83A7F286-F62C-4D47-AF6C-56EBB3734DE1@oracle.com>
Message-ID: <139814C6-7F52-4645-9EEC-50B01C61AA9C@oracle.com>

Looks good to me.

Thanks,
? Igor

> On Dec 16, 2016, at 5:10 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> Good point. New webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.01/ <http://cr.openjdk.java.net/~sla/8171366/webrev.01/>
> 
> Thanks!
> 
>> On 16 Dec 2016, at 15:05, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> 
>> I would recommend using the -q flag to grep instead of piping to /dev/null. Otherwise I think this looks ok.
>> 
>> /Erik
>> 
>> 
>> On 2016-12-16 14:45, Staffan Larsen wrote:
>>> The failure handler (test/failure_handler) runs a number of commands when it detects a timeout in one of the tests. On OS X some of these commands require "Developer mode" (like getting a core file). If "Developer mode" is not enabled, the tools will open a modal dialog. This is problematic when running automated test. The dialog will also prevent other tests from completing.
>>> 
>>> This patch changes the Failure handler to check if "Developer mode" is enabled before running commands that require it. It also includes the output of "DevToolsSecurity ?status? which is used to check for ?Developer mode?.
>>> 
>>> Please review the webrev below,
>>> /Staffan
>>> 
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
>>> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/
>> 
> 


From thomas.stuefe at gmail.com  Sun Dec 18 08:23:16 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 18 Dec 2016 09:23:16 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
Message-ID: <CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>

Hi David,

thanks for your review, your suggestion makes sense. Will incorporate it
into the next webrev; but first I have to try and meet Volkers linker
demands :)

Thanks, Thomas

On Thu, Dec 15, 2016 at 11:33 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 15/12/2016 4:43 PM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> please review this small change. It fixes the gtest build on AIX and
>> enables it by default.
>>
>> Note that even though this is a fix for AIX, a cast needed to be added to
>> shared test coding. This is because xlC struggles with certain template
>> expansions and I had to help it by providing an explicit cast.
>>
>
> These kind of problems have been reported in the past. The way we chose to
> address them was to convert to use ASSERT_TRUE(i == NULL) rather than apply
> casts to make the ASSERT_EQ(i, NULL) compile.
>
> Thanks,
> David
>
>
> Because linker options were changed as well, this unfortunately this
>> spreads over two forest parts, so two webrevs were needed.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
>> Webrevs:
>> (hotspot)
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>> -gtests/webrev.00/webrev/
>> (top level)
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>> -gtests/toplevel-webrev.00/webrev/
>>
>> Note that the toplevel change contains the newly generated configure.sh. I
>> was not sure if that was needed, but it is included for convenience.
>>
>> Kind Regards, Thomas
>>
>>

From thomas.stuefe at gmail.com  Sun Dec 18 12:13:36 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 18 Dec 2016 13:13:36 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
	<CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
Message-ID: <CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>

HI all,

after investigating I see a number of issues preventing gtest from running
on AIX, so I decided to get the fix for the wrong assert in the hotspot out
of the way and open follow up issues for the other problems.

So, this is just the fixed assert, fixed in the fashion David suggested.
All other issues I will fix separately later.

http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-fix-gtest-assert-compile-error/webrev.01

(Hope the link is correct, the website seems down at the moment).

Thank you for reviewing,

Thomas


On Sun, Dec 18, 2016 at 9:23 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> thanks for your review, your suggestion makes sense. Will incorporate it
> into the next webrev; but first I have to try and meet Volkers linker
> demands :)
>
> Thanks, Thomas
>
> On Thu, Dec 15, 2016 at 11:33 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> On 15/12/2016 4:43 PM, Thomas St?fe wrote:
>>
>>> Hi all,
>>>
>>> please review this small change. It fixes the gtest build on AIX and
>>> enables it by default.
>>>
>>> Note that even though this is a fix for AIX, a cast needed to be added to
>>> shared test coding. This is because xlC struggles with certain template
>>> expansions and I had to help it by providing an explicit cast.
>>>
>>
>> These kind of problems have been reported in the past. The way we chose
>> to address them was to convert to use ASSERT_TRUE(i == NULL) rather than
>> apply casts to make the ASSERT_EQ(i, NULL) compile.
>>
>> Thanks,
>> David
>>
>>
>> Because linker options were changed as well, this unfortunately this
>>> spreads over two forest parts, so two webrevs were needed.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
>>> Webrevs:
>>> (hotspot)
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>>> -gtests/webrev.00/webrev/
>>> (top level)
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>>> -gtests/toplevel-webrev.00/webrev/
>>>
>>> Note that the toplevel change contains the newly generated configure.sh.
>>> I
>>> was not sure if that was needed, but it is included for convenience.
>>>
>>> Kind Regards, Thomas
>>>
>>>
>

From thomas.stuefe at gmail.com  Sun Dec 18 12:14:38 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 18 Dec 2016 13:14:38 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CA+3eh132sUhb1BU6r4zfhr4t3gbib+Y8ZnRKyuu1E8hiPTV__g@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<CA+3eh132sUhb1BU6r4zfhr4t3gbib+Y8ZnRKyuu1E8hiPTV__g@mail.gmail.com>
Message-ID: <CAA-vtUzqHzEtnTXVXf206YaO+YcYcVbzbf-pc1ibd7kePT6Qxg@mail.gmail.com>

Hi Volker,

Thank you for reviewing. I'll do the TOC issue this in a follow up change.

Kind Regards, Thomas

On Thu, Dec 15, 2016 at 12:24 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> can you please try to fix the TOC issues for the gtest build only. I
> don't like that we have to build everything with '-qpic=large
> -bbigtoc' just because of gtest.
>
> Isn't it possible to just set these parameters in
> hotspot/make/lib/CompileGtest.gmk by using CFLAGS_aix/LDFALGS_aix?
>
> Thanks,
> Volker
>
>
> On Thu, Dec 15, 2016 at 7:43 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> > Hi all,
> >
> > please review this small change. It fixes the gtest build on AIX and
> enables
> > it by default.
> >
> > Note that even though this is a fix for AIX, a cast needed to be added to
> > shared test coding. This is because xlC struggles with certain template
> > expansions and I had to help it by providing an explicit cast.
> >
> > Because linker options were changed as well, this unfortunately this
> spreads
> > over two forest parts, so two webrevs were needed.
> >
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
> > Webrevs:
> > (hotspot)
> > http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-
> build-gtests/webrev.00/webrev/
> > (top level)
> > http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-
> build-gtests/toplevel-webrev.00/webrev/
> >
> > Note that the toplevel change contains the newly generated configure.sh.
> I
> > was not sure if that was needed, but it is included for convenience.
> >
> > Kind Regards, Thomas
>

From thomas.stuefe at gmail.com  Sun Dec 18 12:50:53 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 18 Dec 2016 13:50:53 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest libjvm.so
Message-ID: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>

Hi all,

please take a look at this small fix. In short, on AIX when linking the
gtest version of libjvm.so, the TOC overflows.

So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
regular libjvm.so, which has no problems and can keep using a small TOC.

Also, I compile all gtest objects with -qpic=large. Note that this only
affects the gtest objects. The regular objects - which the gtest libjvm.so
shares with the regular libjvm.so - I left at -qpic[=small]. This means we
pay a bit of a performance overhead in the gtest libjvm.so but leave the
regular libjvm.so at its optimal linker settings.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8171408

Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/

(Hope the webrev link works, the webserver is still down).

Kind Regards, Thomas

From mandrikov at gmail.com  Mon Dec 19 00:39:13 2016
From: mandrikov at gmail.com (Evgeny Mandrikov)
Date: Mon, 19 Dec 2016 00:39:13 +0000
Subject: Why JDK-8157181 conditional in JDK 9 EA ?
In-Reply-To: <4e3949a8-31f6-3c81-c0f9-a51dde8d8074@oracle.com>
References: <CAEPFu68f7SsPawFrEoB+OnaK9=ErBOZmtzKpMJPZyR2zju2jxg@mail.gmail.com>
	<4e3949a8-31f6-3c81-c0f9-a51dde8d8074@oracle.com>
Message-ID: <CAEPFu68+ZoR3g+TL-NmEvV3xCvB3PW-R2DETz_snvOGiJMMkrQ@mail.gmail.com>

David, thank you for the explanations.

Regards,
Evgeny

On Sun, Dec 11, 2016 at 11:28 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Evgeny,
>
> On 12/12/2016 7:58 AM, Evgeny Mandrikov wrote:
> > Hi,
> >
> > Rory O'Donnell gave me an advice [1] to provide our concerns about
> > JDK-8157181 [2] here. But excuse me if this is wrong place or too late.
> >
> > In JaCoCo project [3] we accidentally discovered JDK-8157181 [2], which
> > revealed that we were generating bytecode that violates JVMLS [4]. What
> was
> > a bit surprising - is a conditional behavior of verifier based on
> bytecode
> > version. At a time of discovery we had no ability to compile into
> bytecode
> > version 9 given the state of tools in build stack (minifiers, verifiers,
> > etc) and had only ability to execute with JDK 9 EA. I guess that many
> > projects might relatively easily start testing 9 EA just as runtime
> > environment, while change of a target still might require bigger
> investment
> > as was the case for us. From there, I wonder why this logic was was not
> > made unconditional as was discussed in JDK-8157181 [2], especially in
> > presence of tickets for backporting [5]. Or maybe this happened, but we
> > just didn't noticed since bug on our side was fixed? The verification
> > itself is great and IMO might reveal bugs in tools that generate
> bytecode.
>
> My comment in the bug report sums up the situation:
>
> "If this is a long standing non-compliance with the JVMS then its impact
> can not be considered high. The longer the VM and spec do not match the
> more likely we adjust the spec to match the VM behaviour. When that is
> not feasible then the usual approach is to enforce the correct rules as
> of the current classfile version, otherwise we risk introducing
> compatibility issues. Even if we make the correct behaviour the default,
> we will usually provide a flag to enable the old behaviour for
> compatibility purposes. Only if this is a security concern would we
> force the change to the new behaviour. "
>
> After much (mostly internal) discussion the compatibility argument won
> out. The backports exist to put in the change that causes the JIT to
> detect the "illegal" assignments and disable aggressive optimization of
> the final field.
>
> Regards
> David
>
> > Best regards,
> > Evgeny Mandrikov
> >
> > [1] https://groups.google.com/d/msg/jacoco-dev/sRXi8TD96js/w4T8DpffAwAJ
> > [2] https://bugs.openjdk.java.net/browse/JDK-8157181
> > [3] http://www.jacoco.org/jacoco/index.html
> > [4] https://github.com/jacoco/jacoco/pull/434
> > [5] https://bugs.openjdk.java.net/browse/JDK-8161987
> >
>

From thomas.stuefe at gmail.com  Mon Dec 19 08:24:40 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 19 Dec 2016 09:24:40 +0100
Subject: cr.openjdk.java.net down
Message-ID: <CAA-vtUxiLF_N6kP0Tk9jywVO763qyV4WwsJmqFWACadMzUapLQ@mail.gmail.com>

Hi all,

cr.openjdk.java.net is not reachable at least from Germany since yesterday,
does anyone know when it will be available again? Or who we should contact?

Sorry if this is the wrong list.

Thanks, Thomas

From mikael.gerdin at oracle.com  Mon Dec 19 08:35:32 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 19 Dec 2016 09:35:32 +0100
Subject: cr.openjdk.java.net down
In-Reply-To: <CAA-vtUxiLF_N6kP0Tk9jywVO763qyV4WwsJmqFWACadMzUapLQ@mail.gmail.com>
References: <CAA-vtUxiLF_N6kP0Tk9jywVO763qyV4WwsJmqFWACadMzUapLQ@mail.gmail.com>
Message-ID: <a1e1aeba-d413-43a7-36c5-3cf894817df3@oracle.com>

Hi Thomas,

On 2016-12-19 09:24, Thomas St?fe wrote:
> Hi all,
>
> cr.openjdk.java.net is not reachable at least from Germany since yesterday,
> does anyone know when it will be available again? Or who we should contact?
>
> Sorry if this is the wrong list.

It is down for us as well and we have notified ops at openjdk.java.net

/Mikael

>
> Thanks, Thomas
>

From thomas.stuefe at gmail.com  Mon Dec 19 08:56:48 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 19 Dec 2016 09:56:48 +0100
Subject: cr.openjdk.java.net down
In-Reply-To: <a1e1aeba-d413-43a7-36c5-3cf894817df3@oracle.com>
References: <CAA-vtUxiLF_N6kP0Tk9jywVO763qyV4WwsJmqFWACadMzUapLQ@mail.gmail.com>
	<a1e1aeba-d413-43a7-36c5-3cf894817df3@oracle.com>
Message-ID: <CAA-vtUzV4POWCvL0GN77ASJgZaDxrWmsV0a9gfcynX+et=H8Dg@mail.gmail.com>

Thank you Mikael!

On Dec 19, 2016 9:35 AM, "Mikael Gerdin" <mikael.gerdin at oracle.com> wrote:

> Hi Thomas,
>
> On 2016-12-19 09:24, Thomas St?fe wrote:
>
>> Hi all,
>>
>> cr.openjdk.java.net is not reachable at least from Germany since
>> yesterday,
>> does anyone know when it will be available again? Or who we should
>> contact?
>>
>> Sorry if this is the wrong list.
>>
>
> It is down for us as well and we have notified ops at openjdk.java.net
>
> /Mikael
>
>
>> Thanks, Thomas
>>
>>

From staffan.larsen at oracle.com  Mon Dec 19 09:48:27 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Dec 2016 10:48:27 +0100
Subject: RFR: 8171366 macOS: Do not run failure handler commands that
	require Developer mode access
In-Reply-To: <139814C6-7F52-4645-9EEC-50B01C61AA9C@oracle.com>
References: <AF14250A-5E38-40CA-AAA1-C16BF1AF0698@oracle.com>
	<a447544a-e0ec-860f-e29d-5eee1dd695de@oracle.com>
	<83A7F286-F62C-4D47-AF6C-56EBB3734DE1@oracle.com>
	<139814C6-7F52-4645-9EEC-50B01C61AA9C@oracle.com>
Message-ID: <4B429535-24D6-414A-BA4C-E1D6991A5685@oracle.com>

Thanks!

> On 16 Dec 2016, at 19:45, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Looks good to me.
> 
> Thanks,
> ? Igor
> 
>> On Dec 16, 2016, at 5:10 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> 
>> Good point. New webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.01/ <http://cr.openjdk.java.net/~sla/8171366/webrev.01/>
>> 
>> Thanks!
>> 
>>> On 16 Dec 2016, at 15:05, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>> 
>>> I would recommend using the -q flag to grep instead of piping to /dev/null. Otherwise I think this looks ok.
>>> 
>>> /Erik
>>> 
>>> 
>>> On 2016-12-16 14:45, Staffan Larsen wrote:
>>>> The failure handler (test/failure_handler) runs a number of commands when it detects a timeout in one of the tests. On OS X some of these commands require "Developer mode" (like getting a core file). If "Developer mode" is not enabled, the tools will open a modal dialog. This is problematic when running automated test. The dialog will also prevent other tests from completing.
>>>> 
>>>> This patch changes the Failure handler to check if "Developer mode" is enabled before running commands that require it. It also includes the output of "DevToolsSecurity ?status? which is used to check for ?Developer mode?.
>>>> 
>>>> Please review the webrev below,
>>>> /Staffan
>>>> 
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8171366
>>>> webrev: http://cr.openjdk.java.net/~sla/8171366/webrev.00/
>>> 
>> 
> 


From edward.nevill at gmail.com  Mon Dec 19 10:09:22 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Mon, 19 Dec 2016 10:09:22 +0000
Subject: RFR: 8171410: aarch64: long multiplyExact shifts by 31 instead of 63
Message-ID: <1482142162.2883.4.camel@gmail.com>

Hi,

Please review the following webrev

http://cr.openjdk.java.net/~enevill/8171410/webrev

(changeset is included inline below because of issues with cr.openjdk.java.net)

Bug report here

https://bugs.openjdk.java.net/browse/JDK-8171410

The patterns for multplyExact long in aarch64.ad shift by 31 instead of 63

? 0x000003ff64b29aa8: mul???????x8, x19, x20
? 0x000003ff64b29aac: smulh?????x9, x19, x20
? 0x000003ff64b29ab0: cmp???????x9, x8, asr #31??<<<<<<< should be 63
? 0x000003ff64b29ab4: b.ne??????0x000003ff64b29b4c

The effect of this is to cause the overflow branch to be taken in cases where the multiply has not overflowed. For example 0x5a5a5a5a * 0xa5a5a5a5 does not overflow but the overflow branch will be taken above.

This was not detected in testing because when the overflow branch is taken C2 causes a call to the real (non intrinsic) multiplyExact to be taken. This then executes correctly.

The effect is a degenerate dis-improvement in performance. Using the following test case

class Mul {
? static long multest(long a, long b) {
	long res = a;
	for (int i = 0; i < 100000000; i++) {
		res += Math.multiplyExact(a, b);
		a ^= 1L; b ^= 1L; // Stop loop invariant hoisting
	}
	return res;
? }
? public static void main(String argv[]) {
????????long a = 0x5a5a5a5aL;
	long b = 0xa5a5a5a5L;
	System.out.println("res " + a + ", " + b + " = " + multest(a, b));
? }
}

With -XX:-UseMathExactIntrinsics this takes 1.95 S
With -XX:+UseMathExactIntrinsics this takes 13.42 S

With the following webrev

http://cr.openjdk.java.net/~enevill/8171410/webrev

-XX:-UseMathExactIntrinsics takes 1.98 S
-XX:+UseMathExactIntrinsics takes??0.95 S

--- CUT HERE ---
# HG changeset patch
# User enevill
# Date 1482100004 18000
#??????Sun Dec 18 17:26:44 2016 -0500
# Node ID c0e2c655e28064fd01b54a47915037d8f2423f81
# Parent??66e2100be052e42af8064e519658185112be6dc3
8171410: aarch64: long multiplyExact shifts by 31 instead of 63
Reviewed-by: aph

diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad
--- a/src/cpu/aarch64/vm/aarch64.ad
+++ b/src/cpu/aarch64/vm/aarch64.ad
@@ -14086,7 +14086,7 @@
?
???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t"
?????????????"smulh rscratch2, $op1, $op2\n\t"
-????????????"cmp???rscratch2, rscratch1, ASR #31\n\t"
+????????????"cmp???rscratch2, rscratch1, ASR #63\n\t"
?????????????"movw??rscratch1, #0x80000000\n\t"
?????????????"cselw rscratch1, rscratch1, zr, NE\n\t"
?????????????"cmpw??rscratch1, #1" %}
@@ -14094,7 +14094,7 @@
???ins_encode %{
?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63
?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127
-????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext
+????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext
?????__ movw(rscratch1, 0x80000000);????????????????????// Develop 0 (EQ),
?????__ cselw(rscratch1, rscratch1, zr, Assembler::NE); // or 0x80000000 (NE)
?????__ cmpw(rscratch1, 1);?????????????????????????????// 0x80000000 - 1 => VS
@@ -14112,7 +14112,7 @@
?
???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t"
?????????????"smulh rscratch2, $op1, $op2\n\t"
-????????????"cmp???rscratch2, rscratch1, ASR #31\n\t"
+????????????"cmp???rscratch2, rscratch1, ASR #63\n\t"
?????????????"b$cmp $labl" %}
???ins_cost(4 * INSN_COST); // Branch is rare so treat as INSN_COST
???ins_encode %{
@@ -14120,7 +14120,7 @@
?????Assembler::Condition cond = (Assembler::Condition)$cmp$$cmpcode;
?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63
?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127
-????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext
+????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext
?????__ br(cond == Assembler::VS ? Assembler::NE : Assembler::EQ, *L);
???%}
?
--- CUT HERE ---

The patterns for multplyExact long in aarch64.ad shift by 31 instead of 63

? 0x000003ff64b29aa8: mul???????x8, x19, x20
? 0x000003ff64b29aac: smulh?????x9, x19, x20
? 0x000003ff64b29ab0: cmp???????x9, x8, asr #31??<<<<<<< should be 63
? 0x000003ff64b29ab4: b.ne??????0x000003ff64b29b4c

The effect of this is to cause the overflow branch to be taken in cases where the multiply has not overflowed. For example 0x5a5a5a5a * 0xa5a5a5a5 does not overflow but the overflow branch will be taken above.

This was not detected in testing because when the overflow branch is taken C2 causes a call to the real (non intrinsic) multiplyExact to be taken. This then executes correctly.

The effect is a degenerate dis-improvement in performance. Usingthe following test case

class Mul {
? static long multest(long a, long b) {
	long res = a;
	for (int i = 0; i < 100000000; i++) {
		res += Math.multiplyExact(a, b);
		a ^= 1L; b ^= 1L; // Stop loop invariant hoisting
	}
	return res;
? }
? public static void main(String argv[]) {
????????long a = 0x5a5a5a5aL;
	long b = 0xa5a5a5a5L;
	System.out.println("res " + a + ", " + b + " = " + multest(a, b));
? }
}

With -XX:-UseMathExactIntrinsics this takes 1.95 S
With -XX:+UseMathExactIntrinsics this takes 13.42 S

With the following webrev

http://cr.openjdk.java.net/~enevill/8171410/webrev

-XX:-UseMathExactIntrinsics takes 1.98 S
-XX:+UseMathExactIntrinsics takes??0.95 S

--- CUT HERE ---
# HG changeset patch
# User enevill
# Date 1482100004 18000
#??????Sun Dec 18 17:26:44 2016 -0500
# Node ID c0e2c655e28064fd01b54a47915037d8f2423f81
# Parent??66e2100be052e42af8064e519658185112be6dc3
8171410: aarch64: long multiplyExact shifts by 31 instead of 63
Reviewed-by: aph

diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad
--- a/src/cpu/aarch64/vm/aarch64.ad
+++ b/src/cpu/aarch64/vm/aarch64.ad
@@ -14086,7 +14086,7 @@
?
???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t"
?????????????"smulh rscratch2, $op1, $op2\n\t"
-????????????"cmp???rscratch2, rscratch1, ASR #31\n\t"
+????????????"cmp???rscratch2, rscratch1, ASR #63\n\t"
?????????????"movw??rscratch1, #0x80000000\n\t"
?????????????"cselw rscratch1, rscratch1, zr, NE\n\t"
?????????????"cmpw??rscratch1, #1" %}
@@ -14094,7 +14094,7 @@
???ins_encode %{
?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63
?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127
-????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext
+????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext
?????__ movw(rscratch1, 0x80000000);????????????????????// Develop 0 (EQ),
?????__ cselw(rscratch1, rscratch1, zr, Assembler::NE); // or 0x80000000 (NE)
?????__ cmpw(rscratch1, 1);?????????????????????????????// 0x80000000 - 1 => VS
@@ -14112,7 +14112,7 @@
?
???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t"
?????????????"smulh rscratch2, $op1, $op2\n\t"
-????????????"cmp???rscratch2, rscratch1, ASR #31\n\t"
+????????????"cmp???rscratch2, rscratch1, ASR #63\n\t"
?????????????"b$cmp $labl" %}
???ins_cost(4 * INSN_COST); // Branch is rare so treat as INSN_COST
???ins_encode %{
@@ -14120,7 +14120,7 @@
?????Assembler::Condition cond = (Assembler::Condition)$cmp$$cmpcode;
?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63
?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127
-????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext
+????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext
?????__ br(cond == Assembler::VS ? Assembler::NE : Assembler::EQ, *L);
???%}
?
--- CUT HERE ---


From david.holmes at oracle.com  Mon Dec 19 10:29:43 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 Dec 2016 20:29:43 +1000
Subject: cr.openjdk.java.net down
In-Reply-To: <a1e1aeba-d413-43a7-36c5-3cf894817df3@oracle.com>
References: <CAA-vtUxiLF_N6kP0Tk9jywVO763qyV4WwsJmqFWACadMzUapLQ@mail.gmail.com>
	<a1e1aeba-d413-43a7-36c5-3cf894817df3@oracle.com>
Message-ID: <35ef2430-92d8-1bb3-c496-72478c390eba@oracle.com>

I emailed them two days ago. It affects cr.openjdk and the web interface 
to mail.openjdk. Of course no one around over the weekend who can do 
anything. :(

David

On 19/12/2016 6:35 PM, Mikael Gerdin wrote:
> Hi Thomas,
>
> On 2016-12-19 09:24, Thomas St?fe wrote:
>> Hi all,
>>
>> cr.openjdk.java.net is not reachable at least from Germany since
>> yesterday,
>> does anyone know when it will be available again? Or who we should
>> contact?
>>
>> Sorry if this is the wrong list.
>
> It is down for us as well and we have notified ops at openjdk.java.net
>
> /Mikael
>
>>
>> Thanks, Thomas
>>

From aph at redhat.com  Mon Dec 19 10:41:36 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 19 Dec 2016 10:41:36 +0000
Subject: Problem building Aarch64 hs today Internal error: Invalid feature
	tested: aot.
Message-ID: <18d7574e-d502-1835-06e0-4e8147f720d8@redhat.com>

lib/JvmFeatures.gmk:150: *** Internal error: Invalid feature tested:  aot.  Stop.

This is the code in question:

ifeq ($(call check-jvm-feature, aot), true)
  JVM_CFLAGS_FEATURES += -DINCLUDE_AOT
else
  JVM_EXCLUDE_FILES += \
      compiledIC_aot_x86_64.cpp compilerRuntime.cpp \
      aotCodeHeap.cpp aotCompiledMethod.cpp aotLoader.cpp compiledIC_aot.cpp
endif

But how is this actually supposed to work?

Andrew.

From david.holmes at oracle.com  Mon Dec 19 10:53:49 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 Dec 2016 20:53:49 +1000
Subject: Problem building Aarch64 hs today Internal error: Invalid feature
	tested: aot.
In-Reply-To: <18d7574e-d502-1835-06e0-4e8147f720d8@redhat.com>
References: <18d7574e-d502-1835-06e0-4e8147f720d8@redhat.com>
Message-ID: <bc278559-c2f4-2804-a68c-b56714d9ac51@oracle.com>

Hi Andrew,

On 19/12/2016 8:41 PM, Andrew Haley wrote:
> lib/JvmFeatures.gmk:150: *** Internal error: Invalid feature tested:  aot.  Stop.

Did you do a reconfigure before building?

> This is the code in question:
>
> ifeq ($(call check-jvm-feature, aot), true)
>   JVM_CFLAGS_FEATURES += -DINCLUDE_AOT
> else
>   JVM_EXCLUDE_FILES += \
>       compiledIC_aot_x86_64.cpp compilerRuntime.cpp \
>       aotCodeHeap.cpp aotCompiledMethod.cpp aotLoader.cpp compiledIC_aot.cpp
> endif
>
> But how is this actually supposed to work?

common/autoconf/hotspot.m4 lists the potential features that may exist:

# All valid JVM features, regardless of platform
VALID_JVM_FEATURES="compiler1 compiler2 zero shark minimal dtrace jvmti 
jvmci \
     graal fprof vm-structs jni-check services management all-gcs nmt 
cds static-build aot"

so that should exported into the generated build files for use by the 
check-jvm-feature function.

David
-----

> Andrew.
>

From aph at redhat.com  Mon Dec 19 10:56:18 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 19 Dec 2016 10:56:18 +0000
Subject: Graal import breaks AArch64 (and probably other non-Graal targets)
Message-ID: <72b9b167-fb8c-289b-6ccb-23411cd0680e@redhat.com>

Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 fprof jni-check jvmci jvmti management nmt services vm-structs'
make[3]: *** No rule to make target `/home/aph/hs/build/linux-aarch64-normal-server-release/buildtools/jdk.vm.compiler.match.processor.jar', needed by `/home/aph/hs/build/linux-aarch64-normal-server-release/support/gensrc/jdk.vm.compiler/_gensrc_proc_done'.
make[3]: *** No rule to make target `/home/aph/hs/build/linux-aarch64-normal-server-release/buildtools/jdk.vm.compiler.nodeinfo.processor.jar', needed by `/home/aph/hs/build/linux-aarch64-normal-server-release/support/gensrc/jdk.vm.compiler/_gensrc_proc_done'.
make[3]: *** No rule to make target `/home/aph/hs/build/linux-aarch64-normal-server-release/buildtools/jdk.vm.compiler.options.processor.jar', needed by `/home/aph/hs/build/linux-aarch64-normal-server-release/support/gensrc/jdk.vm.compiler/_gensrc_proc_done'.
make[3]: *** No rule to make target `/home/aph/hs/build/linux-aarch64-normal-server-release/buildtools/jdk.vm.compiler.replacements.verifier.jar', needed by `/home/aph/hs/build/linux-aarch64-normal-server-release/support/gensrc/jdk.vm.compiler/_gensrc_proc_done'.
make[3]: *** No rule to make target `/home/aph/hs/build/linux-aarch64-normal-server-release/buildtools/jdk.vm.compiler.serviceprovider.processor.jar', needed by `/home/aph/hs/build/linux-aarch64-normal-server-release/support/gensrc/jdk.vm.compiler/_gensrc_proc_done'.
make[3]: Target `default' not remade because of errors.
make[2]: *** [jdk.vm.compiler-gensrc-hotspot] Error 1

I understand that AArch64 isn't ready for Graal to be imported yet, but
the absence of Graal support should not break non-Graal targets.

Andrew.

From aph at redhat.com  Mon Dec 19 10:59:50 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 19 Dec 2016 10:59:50 +0000
Subject: Problem building Aarch64 hs today Internal error: Invalid feature
	tested: aot.
In-Reply-To: <bc278559-c2f4-2804-a68c-b56714d9ac51@oracle.com>
References: <18d7574e-d502-1835-06e0-4e8147f720d8@redhat.com>
	<bc278559-c2f4-2804-a68c-b56714d9ac51@oracle.com>
Message-ID: <0a49be61-5a40-968a-464d-7b6bb0be7c5f@redhat.com>

On 19/12/16 10:53, David Holmes wrote:
> On 19/12/2016 8:41 PM, Andrew Haley wrote:
>> lib/JvmFeatures.gmk:150: *** Internal error: Invalid feature tested:  aot.  Stop.
> Did you do a reconfigure before building?
> 

Ah, maybe not.  I'll delete the entire build dir and start again.

Thanks,

Andrew.


From aph at redhat.com  Mon Dec 19 11:02:27 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 19 Dec 2016 11:02:27 +0000
Subject: Graal import breaks AArch64 (and probably other non-Graal targets)
In-Reply-To: <72b9b167-fb8c-289b-6ccb-23411cd0680e@redhat.com>
References: <72b9b167-fb8c-289b-6ccb-23411cd0680e@redhat.com>
Message-ID: <184b4dd0-f83c-54f8-220a-0f731c787936@redhat.com>

Ah, forget that.  I needed to do a complete clean rebuild.  Sorry.

Andrew.

From adinn at redhat.com  Mon Dec 19 11:33:45 2016
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 19 Dec 2016 11:33:45 +0000
Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact
	shifts by 31 instead of 63
In-Reply-To: <1482142162.2883.4.camel@gmail.com>
References: <1482142162.2883.4.camel@gmail.com>
Message-ID: <d94a5c4f-3006-557b-f62d-e7f074bebc98@redhat.com>

Hi Ed,

On 19/12/16 10:09, Edward Nevill wrote:
> Please review the following webrev ...

The change looks good to me.

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 thomas.stuefe at gmail.com  Mon Dec 19 13:28:04 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 19 Dec 2016 14:28:04 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
Message-ID: <CAA-vtUxcjhcypSRBBxD4V0L+YHfYAfMdt_O3uyfFFpHdfD1r-A@mail.gmail.com>

On Sun, Dec 18, 2016 at 1:50 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi all,
>
> please take a look at this small fix. In short, on AIX when linking the
> gtest version of libjvm.so, the TOC overflows.
>
> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
> regular libjvm.so, which has no problems and can keep using a small TOC.
>
> Also, I compile all gtest objects with -qpic=large. Note that this only
> affects the gtest objects. The regular objects - which the gtest libjvm.so
> shares with the regular libjvm.so - I left at -qpic[=small]. This means we
> pay a bit of a performance overhead in the gtest libjvm.so but leave the
> regular libjvm.so at its optimal linker settings.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8171408
>
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-
> TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/
>
> (Hope the webrev link works, the webserver is still down).
>
> Kind Regards, Thomas
>
>
>
Because cr.openjdk.java.net is still down, here the zipped webrev as
attachment.

From thomas.stuefe at gmail.com  Mon Dec 19 13:33:29 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 19 Dec 2016 14:33:29 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
	<CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
	<CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
Message-ID: <CAA-vtUwKRFb9iMoUS1Kome=ZN8ByU4EY1JfP=T=QE=MgQiTG5A@mail.gmail.com>

On Sun, Dec 18, 2016 at 1:13 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> HI all,
>
> after investigating I see a number of issues preventing gtest from running
> on AIX, so I decided to get the fix for the wrong assert in the hotspot out
> of the way and open follow up issues for the other problems.
>
> So, this is just the fixed assert, fixed in the fashion David suggested.
> All other issues I will fix separately later.
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-
> fix-gtest-assert-compile-error/webrev.01
>
> (Hope the link is correct, the website seems down at the moment).
>
> Thank you for reviewing,
>
> Thomas
>

(openjdk.java.net is still down, so I attach here the webrev zip)

From zoltan.majo at oracle.com  Mon Dec 19 16:01:19 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 19 Dec 2016 17:01:19 +0100
Subject: [8u] Request for approval and review: 8157181, 8160551, and 8171155
Message-ID: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com>

Hi,


please approve (and review in case of 8157181) the following backports 
to 8u:

https://bugs.openjdk.java.net/browse/JDK-8157181
https://bugs.openjdk.java.net/browse/JDK-8160551
https://bugs.openjdk.java.net/browse/JDK-8171155

8160551 and 8171155 cleanly apply to 8u.

As suggested by John Rose in a comment for 8159215, only a part of the 
8157181 fix for 9 is backported to 8u. As a result, the backport of 
8157181 does not apply cleanly to 8u (thus the review request). Here is 
the webrev for that change:

http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/

I tested the three changes combined with JPRT, all tests pass.

Thank you!

Best regards,


Zoltan


From jesper.wilhelmsson at oracle.com  Mon Dec 19 17:34:50 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 19 Dec 2016 18:34:50 +0100
Subject: Fixing p4 and p5 bugs? Deadline is Wednesday.
Message-ID: <243e8788-5563-6db0-f54f-c9bbc8cc0cf0@oracle.com>

Hi,

The JDK 9 release is soon going in to Ramp Down Phase 1 (RDP1) [1]. While in 
this phase only bug fixes with priority p1-p3 are accepted.

The RDP1 date is January 5:th and that is the date when the last p4 and p5 bugs 
should reach jdk9/jdk9 - the master repository.

Changes that go through jdk9/hs will need about two weeks to reach master which 
means that they need to be in hs by December 21 - this Wednesday.

So, if you are looking at any p4 or p5 bugs, make sure they are fixed and pushed 
before Wednesday evening, or defer them to JDK 10.

This goes for any and all changes including all OpenJDK contributions.

Thanks,
/Jesper

[1] http://openjdk.java.net/projects/jdk9/

From david.holmes at oracle.com  Mon Dec 19 20:42:54 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Dec 2016 06:42:54 +1000
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
	<CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
	<CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
Message-ID: <ea582f01-2cb9-764f-bf3e-a00c9c6ffd79@oracle.com>



On 18/12/2016 10:13 PM, Thomas St?fe wrote:
> HI all,
>
> after investigating I see a number of issues preventing gtest from
> running on AIX, so I decided to get the fix for the wrong assert in the
> hotspot out of the way and open follow up issues for the other problems.
>
> So, this is just the fixed assert, fixed in the fashion David suggested.
> All other issues I will fix separately later.
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-fix-gtest-assert-compile-error/webrev.01

Looks good.

Thanks,
David

> (Hope the link is correct, the website seems down at the moment).
>
> Thank you for reviewing,
>
> Thomas
>
>
> On Sun, Dec 18, 2016 at 9:23 AM, Thomas St?fe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David,
>
>     thanks for your review, your suggestion makes sense. Will
>     incorporate it into the next webrev; but first I have to try and
>     meet Volkers linker demands :)
>
>     Thanks, Thomas
>
>     On Thu, Dec 15, 2016 at 11:33 AM, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         Hi Thomas,
>
>         On 15/12/2016 4:43 PM, Thomas St?fe wrote:
>
>             Hi all,
>
>             please review this small change. It fixes the gtest build on
>             AIX and
>             enables it by default.
>
>             Note that even though this is a fix for AIX, a cast needed
>             to be added to
>             shared test coding. This is because xlC struggles with
>             certain template
>             expansions and I had to help it by providing an explicit cast.
>
>
>         These kind of problems have been reported in the past. The way
>         we chose to address them was to convert to use ASSERT_TRUE(i ==
>         NULL) rather than apply casts to make the ASSERT_EQ(i, NULL)
>         compile.
>
>         Thanks,
>         David
>
>
>             Because linker options were changed as well, this
>             unfortunately this
>             spreads over two forest parts, so two webrevs were needed.
>
>             Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
>             <https://bugs.openjdk.java.net/browse/JDK-8171225>
>             Webrevs:
>             (hotspot)
>             http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
>             <http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/>
>             (top level)
>             http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/
>             <http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/>
>
>             Note that the toplevel change contains the newly generated
>             configure.sh. I
>             was not sure if that was needed, but it is included for
>             convenience.
>
>             Kind Regards, Thomas
>
>
>

From david.holmes at oracle.com  Mon Dec 19 20:43:43 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Dec 2016 06:43:43 +1000
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUxcjhcypSRBBxD4V0L+YHfYAfMdt_O3uyfFFpHdfD1r-A@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
	<CAA-vtUxcjhcypSRBBxD4V0L+YHfYAfMdt_O3uyfFFpHdfD1r-A@mail.gmail.com>
Message-ID: <7a803cd4-f506-ad2d-73e9-d06601f006c7@oracle.com>

Thomas,

Attachments gets stripped from most of the mailing lists.

But cr.openjdk is back now.

David

On 19/12/2016 11:28 PM, Thomas St?fe wrote:
> On Sun, Dec 18, 2016 at 1:50 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi all,
>>
>> please take a look at this small fix. In short, on AIX when linking the
>> gtest version of libjvm.so, the TOC overflows.
>>
>> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
>> regular libjvm.so, which has no problems and can keep using a small TOC.
>>
>> Also, I compile all gtest objects with -qpic=large. Note that this only
>> affects the gtest objects. The regular objects - which the gtest libjvm.so
>> shares with the regular libjvm.so - I left at -qpic[=small]. This means we
>> pay a bit of a performance overhead in the gtest libjvm.so but leave the
>> regular libjvm.so at its optimal linker settings.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8171408
>>
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-
>> TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/
>>
>> (Hope the webrev link works, the webserver is still down).
>>
>> Kind Regards, Thomas
>>
>>
>>
> Because cr.openjdk.java.net is still down, here the zipped webrev as
> attachment.
>

From david.holmes at oracle.com  Mon Dec 19 20:47:01 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Dec 2016 06:47:01 +1000
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
Message-ID: <b5448eba-ed05-c1ae-e93d-d9bf9bc995eb@oracle.com>

Hi Thomas,

On 18/12/2016 10:50 PM, Thomas St?fe wrote:
> Hi all,
>
> please take a look at this small fix. In short, on AIX when linking the
> gtest version of libjvm.so, the TOC overflows.
>
> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
> regular libjvm.so, which has no problems and can keep using a small TOC.
>
> Also, I compile all gtest objects with -qpic=large. Note that this only
> affects the gtest objects. The regular objects - which the gtest libjvm.so
> shares with the regular libjvm.so - I left at -qpic[=small]. This means we
> pay a bit of a performance overhead in the gtest libjvm.so but leave the
> regular libjvm.so at its optimal linker settings.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8171408
>
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/

This looks okay to me.

Thanks,
David
------

> (Hope the webrev link works, the webserver is still down).
>
> Kind Regards, Thomas
>

From vladimir.kozlov at oracle.com  Mon Dec 19 21:53:31 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 19 Dec 2016 13:53:31 -0800
Subject: [8u] Request for approval and review: 8157181, 8160551, and
	8171155
In-Reply-To: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com>
References: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com>
Message-ID: <77391954-5386-ce4b-39f3-10769d038945@oracle.com>

Looks good to me.

Thanks,
Vladimir

On 12/19/16 8:01 AM, Zolt?n Maj? wrote:
> Hi,
>
>
> please approve (and review in case of 8157181) the following backports
> to 8u:
>
> https://bugs.openjdk.java.net/browse/JDK-8157181
> https://bugs.openjdk.java.net/browse/JDK-8160551
> https://bugs.openjdk.java.net/browse/JDK-8171155
>
> 8160551 and 8171155 cleanly apply to 8u.
>
> As suggested by John Rose in a comment for 8159215, only a part of the
> 8157181 fix for 9 is backported to 8u. As a result, the backport of
> 8157181 does not apply cleanly to 8u (thus the review request). Here is
> the webrev for that change:
>
> http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/
>
> I tested the three changes combined with JPRT, all tests pass.
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>

From thomas.stuefe at gmail.com  Mon Dec 19 22:28:31 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 19 Dec 2016 23:28:31 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <b5448eba-ed05-c1ae-e93d-d9bf9bc995eb@oracle.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
	<b5448eba-ed05-c1ae-e93d-d9bf9bc995eb@oracle.com>
Message-ID: <CAA-vtUx2VuFW232TTaraPBVHCDzmrXVydZy_fmJqZUDE3DfXxQ@mail.gmail.com>

Thanks David!

On Dec 19, 2016 21:47, "David Holmes" <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> On 18/12/2016 10:50 PM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> please take a look at this small fix. In short, on AIX when linking the
>> gtest version of libjvm.so, the TOC overflows.
>>
>> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
>> regular libjvm.so, which has no problems and can keep using a small TOC.
>>
>> Also, I compile all gtest objects with -qpic=large. Note that this only
>> affects the gtest objects. The regular objects - which the gtest libjvm.so
>> shares with the regular libjvm.so - I left at -qpic[=small]. This means we
>> pay a bit of a performance overhead in the gtest libjvm.so but leave the
>> regular libjvm.so at its optimal linker settings.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8171408
>>
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-
>> overflow-when-linking-the-gtest-libjvm/webrev.00/
>>
>
> This looks okay to me.
>
> Thanks,
> David
> ------
>
> (Hope the webrev link works, the webserver is still down).
>>
>> Kind Regards, Thomas
>>
>>

From rob.mckenna at oracle.com  Mon Dec 19 22:51:56 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 19 Dec 2016 22:51:56 +0000
Subject: [8u] Request for approval and review: 8157181, 8160551, and
	8171155
In-Reply-To: <77391954-5386-ce4b-39f3-10769d038945@oracle.com>
References: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com>
	<77391954-5386-ce4b-39f3-10769d038945@oracle.com>
Message-ID: <20161219225156.GA4231@vimes>

Approved

    -Rob

On 19/12/16 01:53, Vladimir Kozlov wrote:
> Looks good to me.
> 
> Thanks,
> Vladimir
> 
> On 12/19/16 8:01 AM, Zolt?n Maj? wrote:
> >Hi,
> >
> >
> >please approve (and review in case of 8157181) the following backports
> >to 8u:
> >
> >https://bugs.openjdk.java.net/browse/JDK-8157181
> >https://bugs.openjdk.java.net/browse/JDK-8160551
> >https://bugs.openjdk.java.net/browse/JDK-8171155
> >
> >8160551 and 8171155 cleanly apply to 8u.
> >
> >As suggested by John Rose in a comment for 8159215, only a part of the
> >8157181 fix for 9 is backported to 8u. As a result, the backport of
> >8157181 does not apply cleanly to 8u (thus the review request). Here is
> >the webrev for that change:
> >
> >http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/
> >
> >I tested the three changes combined with JPRT, all tests pass.
> >
> >Thank you!
> >
> >Best regards,
> >
> >
> >Zoltan
> >

From thomas.stuefe at gmail.com  Tue Dec 20 04:31:10 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 05:31:10 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <ea582f01-2cb9-764f-bf3e-a00c9c6ffd79@oracle.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
	<CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
	<CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
	<ea582f01-2cb9-764f-bf3e-a00c9c6ffd79@oracle.com>
Message-ID: <CAA-vtUwDRbu5UY6aSDZMfWmJGAfwpCvxKFk7PSVZ7QR8qv+qTQ@mail.gmail.com>

Thanks David!

On Dec 19, 2016 21:43, "David Holmes" <david.holmes at oracle.com> wrote:

>
>
> On 18/12/2016 10:13 PM, Thomas St?fe wrote:
>
>> HI all,
>>
>> after investigating I see a number of issues preventing gtest from
>> running on AIX, so I decided to get the fix for the wrong assert in the
>> hotspot out of the way and open follow up issues for the other problems.
>>
>> So, this is just the fixed assert, fixed in the fashion David suggested.
>> All other issues I will fix separately later.
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-fix-
>> gtest-assert-compile-error/webrev.01
>>
>
> Looks good.
>
> Thanks,
> David
>
> (Hope the link is correct, the website seems down at the moment).
>>
>> Thank you for reviewing,
>>
>> Thomas
>>
>>
>> On Sun, Dec 18, 2016 at 9:23 AM, Thomas St?fe <thomas.stuefe at gmail.com
>> <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>     Hi David,
>>
>>     thanks for your review, your suggestion makes sense. Will
>>     incorporate it into the next webrev; but first I have to try and
>>     meet Volkers linker demands :)
>>
>>     Thanks, Thomas
>>
>>     On Thu, Dec 15, 2016 at 11:33 AM, David Holmes
>>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>>         Hi Thomas,
>>
>>         On 15/12/2016 4:43 PM, Thomas St?fe wrote:
>>
>>             Hi all,
>>
>>             please review this small change. It fixes the gtest build on
>>             AIX and
>>             enables it by default.
>>
>>             Note that even though this is a fix for AIX, a cast needed
>>             to be added to
>>             shared test coding. This is because xlC struggles with
>>             certain template
>>             expansions and I had to help it by providing an explicit cast.
>>
>>
>>         These kind of problems have been reported in the past. The way
>>         we chose to address them was to convert to use ASSERT_TRUE(i ==
>>         NULL) rather than apply casts to make the ASSERT_EQ(i, NULL)
>>         compile.
>>
>>         Thanks,
>>         David
>>
>>
>>             Because linker options were changed as well, this
>>             unfortunately this
>>             spreads over two forest parts, so two webrevs were needed.
>>
>>             Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
>>             <https://bugs.openjdk.java.net/browse/JDK-8171225>
>>             Webrevs:
>>             (hotspot)
>>             http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>> -gtests/webrev.00/webrev/
>>             <http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-buil
>> d-gtests/webrev.00/webrev/>
>>             (top level)
>>             http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build
>> -gtests/toplevel-webrev.00/webrev/
>>             <http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-buil
>> d-gtests/toplevel-webrev.00/webrev/>
>>
>>             Note that the toplevel change contains the newly generated
>>             configure.sh. I
>>             was not sure if that was needed, but it is included for
>>             convenience.
>>
>>             Kind Regards, Thomas
>>
>>
>>
>>

From volker.simonis at gmail.com  Tue Dec 20 08:11:08 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 20 Dec 2016 09:11:08 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CAA-vtUwKRFb9iMoUS1Kome=ZN8ByU4EY1JfP=T=QE=MgQiTG5A@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
	<CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
	<CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
	<CAA-vtUwKRFb9iMoUS1Kome=ZN8ByU4EY1JfP=T=QE=MgQiTG5A@mail.gmail.com>
Message-ID: <CA+3eh11Nzt5jWVboJaZvVJaxv9pBG09QGwAz3Cupg_mGy+KyLg@mail.gmail.com>

Looks good!

Volker


On Mon, Dec 19, 2016 at 2:33 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> On Sun, Dec 18, 2016 at 1:13 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>>
>> HI all,
>>
>> after investigating I see a number of issues preventing gtest from running
>> on AIX, so I decided to get the fix for the wrong assert in the hotspot out
>> of the way and open follow up issues for the other problems.
>>
>> So, this is just the fixed assert, fixed in the fashion David suggested.
>> All other issues I will fix separately later.
>>
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-fix-gtest-assert-compile-error/webrev.01
>>
>> (Hope the link is correct, the website seems down at the moment).
>>
>> Thank you for reviewing,
>>
>> Thomas
>
>
> (openjdk.java.net is still down, so I attach here the webrev zip)
>

From thomas.stuefe at gmail.com  Tue Dec 20 08:13:57 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 09:13:57 +0100
Subject: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12
In-Reply-To: <CA+3eh11Nzt5jWVboJaZvVJaxv9pBG09QGwAz3Cupg_mGy+KyLg@mail.gmail.com>
References: <CAA-vtUz5LhdADgscNc0N1jL_jej8YyAgxWk7QVt2A1TeUY0YPQ@mail.gmail.com>
	<160b6e06-e9f1-0c21-b899-2baf5876bb72@oracle.com>
	<CAA-vtUzWdy7tvFhJVCn4qbtwxB2pixvBeyEGpjx_pfyf91pLVg@mail.gmail.com>
	<CAA-vtUyi_Zr9+yLBJ4qX7_JDvEZWz=6eQGjKy19DHTpV3WwaDg@mail.gmail.com>
	<CAA-vtUwKRFb9iMoUS1Kome=ZN8ByU4EY1JfP=T=QE=MgQiTG5A@mail.gmail.com>
	<CA+3eh11Nzt5jWVboJaZvVJaxv9pBG09QGwAz3Cupg_mGy+KyLg@mail.gmail.com>
Message-ID: <CAA-vtUxyPFWRzjJANVQsuakPYZb8cDCtQ=OP2WFhRvuPYkjO7Q@mail.gmail.com>

Thanks Volker!

On Tue, Dec 20, 2016 at 9:11 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Looks good!
>
> Volker
>
>
> On Mon, Dec 19, 2016 at 2:33 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > On Sun, Dec 18, 2016 at 1:13 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> > wrote:
> >>
> >> HI all,
> >>
> >> after investigating I see a number of issues preventing gtest from
> running
> >> on AIX, so I decided to get the fix for the wrong assert in the hotspot
> out
> >> of the way and open follow up issues for the other problems.
> >>
> >> So, this is just the fixed assert, fixed in the fashion David suggested.
> >> All other issues I will fix separately later.
> >>
> >>
> >> http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-
> fix-gtest-assert-compile-error/webrev.01
> >>
> >> (Hope the link is correct, the website seems down at the moment).
> >>
> >> Thank you for reviewing,
> >>
> >> Thomas
> >
> >
> > (openjdk.java.net is still down, so I attach here the webrev zip)
> >
>

From erik.joelsson at oracle.com  Tue Dec 20 08:17:56 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 20 Dec 2016 09:17:56 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
Message-ID: <a4d1281d-a455-cdf6-e0fd-dea142bba69b@oracle.com>

Hello,

I understand why you want to filter out the -qpic flag from the general 
JVM_CFLAGS, but that kind of logic is brittle so we try to avoid it 
unless absolutely necessary. I prefer to just rely on the tools treating 
command line options as the last one takes precedence. I assume the AIX 
compiler behaves that way too and that a -qpic=large will override a 
-qpic earlier on the command line. We have consciously designed 
SetupNativeCompilation to add all the *FLAGS in the order of most 
specific flags last for this reason.

So, could you try removing the filtering and see if it still works?

/Erik


On 2016-12-18 13:50, Thomas St?fe wrote:
> Hi all,
>
> please take a look at this small fix. In short, on AIX when linking the
> gtest version of libjvm.so, the TOC overflows.
>
> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
> regular libjvm.so, which has no problems and can keep using a small TOC.
>
> Also, I compile all gtest objects with -qpic=large. Note that this only
> affects the gtest objects. The regular objects - which the gtest libjvm.so
> shares with the regular libjvm.so - I left at -qpic[=small]. This means we
> pay a bit of a performance overhead in the gtest libjvm.so but leave the
> regular libjvm.so at its optimal linker settings.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8171408
>
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/
>
> (Hope the webrev link works, the webserver is still down).
>
> Kind Regards, Thomas


From thomas.stuefe at gmail.com  Tue Dec 20 08:21:27 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 09:21:27 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <a4d1281d-a455-cdf6-e0fd-dea142bba69b@oracle.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
	<a4d1281d-a455-cdf6-e0fd-dea142bba69b@oracle.com>
Message-ID: <CAA-vtUzM8M2GDkX69jtHDm4a2KaM5VerBRDDDWgLQSp-eTUxaQ@mail.gmail.com>

Hi Erik,

On Tue, Dec 20, 2016 at 9:17 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello,
>
> I understand why you want to filter out the -qpic flag from the general
> JVM_CFLAGS, but that kind of logic is brittle so we try to avoid it unless
> absolutely necessary. I prefer to just rely on the tools treating command
> line options as the last one takes precedence. I assume the AIX compiler
> behaves that way too and that a -qpic=large will override a -qpic earlier
> on the command line. We have consciously designed SetupNativeCompilation to
> add all the *FLAGS in the order of most specific flags last for this reason.
>
>
You are right, and Volker just complained about the same thing :) I'll post
an updated ref where I just rely on qpic=large following qpic. I was not
happy with that filter-out expression either.

..Thomas


> So, could you try removing the filtering and see if it still works?
>
> /Erik
>
>
>
> On 2016-12-18 13:50, Thomas St?fe wrote:
>
>> Hi all,
>>
>> please take a look at this small fix. In short, on AIX when linking the
>> gtest version of libjvm.so, the TOC overflows.
>>
>> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
>> regular libjvm.so, which has no problems and can keep using a small TOC.
>>
>> Also, I compile all gtest objects with -qpic=large. Note that this only
>> affects the gtest objects. The regular objects - which the gtest libjvm.so
>> shares with the regular libjvm.so - I left at -qpic[=small]. This means we
>> pay a bit of a performance overhead in the gtest libjvm.so but leave the
>> regular libjvm.so at its optimal linker settings.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8171408
>>
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-
>> overflow-when-linking-the-gtest-libjvm/webrev.00/
>>
>> (Hope the webrev link works, the webserver is still down).
>>
>> Kind Regards, Thomas
>>
>
>

From thomas.stuefe at gmail.com  Tue Dec 20 08:30:00 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 09:30:00 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUzM8M2GDkX69jtHDm4a2KaM5VerBRDDDWgLQSp-eTUxaQ@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
	<a4d1281d-a455-cdf6-e0fd-dea142bba69b@oracle.com>
	<CAA-vtUzM8M2GDkX69jtHDm4a2KaM5VerBRDDDWgLQSp-eTUxaQ@mail.gmail.com>
Message-ID: <CAA-vtUzNwzPN1p9LvcSkifvd17Bv9SN_gPxOAwpT=yhR+9gHQQ@mail.gmail.com>

Hi guys,

updated webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.01/webrev/

Only change is that I removed the offending filter-out expression. This
means that gtest modules are compiled with both -qpic followed by
-qpic=large, but the latter should take precedence, so it is ok. Also keeps
the makefile simple.

Kind Regards, Thomas

On Tue, Dec 20, 2016 at 9:21 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Erik,
>
> On Tue, Dec 20, 2016 at 9:17 AM, Erik Joelsson <erik.joelsson at oracle.com>
> wrote:
>
>> Hello,
>>
>> I understand why you want to filter out the -qpic flag from the general
>> JVM_CFLAGS, but that kind of logic is brittle so we try to avoid it unless
>> absolutely necessary. I prefer to just rely on the tools treating command
>> line options as the last one takes precedence. I assume the AIX compiler
>> behaves that way too and that a -qpic=large will override a -qpic earlier
>> on the command line. We have consciously designed SetupNativeCompilation to
>> add all the *FLAGS in the order of most specific flags last for this reason.
>>
>>
> You are right, and Volker just complained about the same thing :) I'll
> post an updated ref where I just rely on qpic=large following qpic. I was
> not happy with that filter-out expression either.
>
> ..Thomas
>
>
>> So, could you try removing the filtering and see if it still works?
>>
>> /Erik
>>
>>
>>
>> On 2016-12-18 13:50, Thomas St?fe wrote:
>>
>>> Hi all,
>>>
>>> please take a look at this small fix. In short, on AIX when linking the
>>> gtest version of libjvm.so, the TOC overflows.
>>>
>>> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
>>> regular libjvm.so, which has no problems and can keep using a small TOC.
>>>
>>> Also, I compile all gtest objects with -qpic=large. Note that this only
>>> affects the gtest objects. The regular objects - which the gtest
>>> libjvm.so
>>> shares with the regular libjvm.so - I left at -qpic[=small]. This means
>>> we
>>> pay a bit of a performance overhead in the gtest libjvm.so but leave the
>>> regular libjvm.so at its optimal linker settings.
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8171408
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-o
>>> verflow-when-linking-the-gtest-libjvm/webrev.00/
>>>
>>> (Hope the webrev link works, the webserver is still down).
>>>
>>> Kind Regards, Thomas
>>>
>>
>>
>

From volker.simonis at gmail.com  Tue Dec 20 08:31:33 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 20 Dec 2016 09:31:33 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUzNwzPN1p9LvcSkifvd17Bv9SN_gPxOAwpT=yhR+9gHQQ@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
	<a4d1281d-a455-cdf6-e0fd-dea142bba69b@oracle.com>
	<CAA-vtUzM8M2GDkX69jtHDm4a2KaM5VerBRDDDWgLQSp-eTUxaQ@mail.gmail.com>
	<CAA-vtUzNwzPN1p9LvcSkifvd17Bv9SN_gPxOAwpT=yhR+9gHQQ@mail.gmail.com>
Message-ID: <CA+3eh13ECWYvq9rbSeoDx=p4TT-T370ZJgizx30-VWH-JBp4hQ@mail.gmail.com>

Looks good now!

Thanks,
Volker


On Tue, Dec 20, 2016 at 9:30 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi guys,
>
> updated webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.01/webrev/
>
> Only change is that I removed the offending filter-out expression. This
> means that gtest modules are compiled with both -qpic followed by
> -qpic=large, but the latter should take precedence, so it is ok. Also keeps
> the makefile simple.
>
> Kind Regards, Thomas
>
> On Tue, Dec 20, 2016 at 9:21 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>>
>> Hi Erik,
>>
>> On Tue, Dec 20, 2016 at 9:17 AM, Erik Joelsson <erik.joelsson at oracle.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> I understand why you want to filter out the -qpic flag from the general
>>> JVM_CFLAGS, but that kind of logic is brittle so we try to avoid it unless
>>> absolutely necessary. I prefer to just rely on the tools treating command
>>> line options as the last one takes precedence. I assume the AIX compiler
>>> behaves that way too and that a -qpic=large will override a -qpic earlier on
>>> the command line. We have consciously designed SetupNativeCompilation to add
>>> all the *FLAGS in the order of most specific flags last for this reason.
>>>
>>
>> You are right, and Volker just complained about the same thing :) I'll
>> post an updated ref where I just rely on qpic=large following qpic. I was
>> not happy with that filter-out expression either.
>>
>> ..Thomas
>>
>>>
>>> So, could you try removing the filtering and see if it still works?
>>>
>>> /Erik
>>>
>>>
>>>
>>> On 2016-12-18 13:50, Thomas St?fe wrote:
>>>>
>>>> Hi all,
>>>>
>>>> please take a look at this small fix. In short, on AIX when linking the
>>>> gtest version of libjvm.so, the TOC overflows.
>>>>
>>>> So the gtest libjvm.so must be linked with -bbigtoc, in contrast to the
>>>> regular libjvm.so, which has no problems and can keep using a small TOC.
>>>>
>>>> Also, I compile all gtest objects with -qpic=large. Note that this only
>>>> affects the gtest objects. The regular objects - which the gtest
>>>> libjvm.so
>>>> shares with the regular libjvm.so - I left at -qpic[=small]. This means
>>>> we
>>>> pay a bit of a performance overhead in the gtest libjvm.so but leave the
>>>> regular libjvm.so at its optimal linker settings.
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8171408
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/
>>>>
>>>> (Hope the webrev link works, the webserver is still down).
>>>>
>>>> Kind Regards, Thomas
>>>
>>>
>>
>

From erik.joelsson at oracle.com  Tue Dec 20 08:31:46 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 20 Dec 2016 09:31:46 +0100
Subject: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest
	libjvm.so
In-Reply-To: <CAA-vtUzNwzPN1p9LvcSkifvd17Bv9SN_gPxOAwpT=yhR+9gHQQ@mail.gmail.com>
References: <CAA-vtUxXYjnd+bkhj8-dCHOdajrqR4=Wxt+Grt3jQ7KpEJHf9g@mail.gmail.com>
	<a4d1281d-a455-cdf6-e0fd-dea142bba69b@oracle.com>
	<CAA-vtUzM8M2GDkX69jtHDm4a2KaM5VerBRDDDWgLQSp-eTUxaQ@mail.gmail.com>
	<CAA-vtUzNwzPN1p9LvcSkifvd17Bv9SN_gPxOAwpT=yhR+9gHQQ@mail.gmail.com>
Message-ID: <1d66211e-dbc4-926c-b032-0ebbb6a86974@oracle.com>

Looks good.

/Erik


On 2016-12-20 09:30, Thomas St?fe wrote:
> Hi guys,
>
> updated webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.01/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.01/webrev/>
>
> Only change is that I removed the offending filter-out expression. 
> This means that gtest modules are compiled with both -qpic followed by 
> -qpic=large, but the latter should take precedence, so it is ok. Also 
> keeps the makefile simple.
>
> Kind Regards, Thomas
>
> On Tue, Dec 20, 2016 at 9:21 AM, Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi Erik,
>
>     On Tue, Dec 20, 2016 at 9:17 AM, Erik Joelsson
>     <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>
>         Hello,
>
>         I understand why you want to filter out the -qpic flag from
>         the general JVM_CFLAGS, but that kind of logic is brittle so
>         we try to avoid it unless absolutely necessary. I prefer to
>         just rely on the tools treating command line options as the
>         last one takes precedence. I assume the AIX compiler behaves
>         that way too and that a -qpic=large will override a -qpic
>         earlier on the command line. We have consciously designed
>         SetupNativeCompilation to add all the *FLAGS in the order of
>         most specific flags last for this reason.
>
>
>     You are right, and Volker just complained about the same thing :)
>     I'll post an updated ref where I just rely on qpic=large following
>     qpic. I was not happy with that filter-out expression either.
>
>     ..Thomas
>
>         So, could you try removing the filtering and see if it still
>         works?
>
>         /Erik
>
>
>
>         On 2016-12-18 13:50, Thomas St?fe wrote:
>
>             Hi all,
>
>             please take a look at this small fix. In short, on AIX
>             when linking the
>             gtest version of libjvm.so, the TOC overflows.
>
>             So the gtest libjvm.so must be linked with -bbigtoc, in
>             contrast to the
>             regular libjvm.so, which has no problems and can keep
>             using a small TOC.
>
>             Also, I compile all gtest objects with -qpic=large. Note
>             that this only
>             affects the gtest objects. The regular objects - which the
>             gtest libjvm.so
>             shares with the regular libjvm.so - I left at
>             -qpic[=small]. This means we
>             pay a bit of a performance overhead in the gtest libjvm.so
>             but leave the
>             regular libjvm.so at its optimal linker settings.
>
>             Issue:
>             https://bugs.openjdk.java.net/browse/JDK-8171408
>             <https://bugs.openjdk.java.net/browse/JDK-8171408>
>
>             Webrev:
>             http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/
>             <http://cr.openjdk.java.net/%7Estuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.00/>
>
>             (Hope the webrev link works, the webserver is still down).
>
>             Kind Regards, Thomas
>
>
>
>


From zoltan.majo at oracle.com  Tue Dec 20 08:55:28 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Tue, 20 Dec 2016 09:55:28 +0100
Subject: [8u] Request for approval and review: 8157181, 8160551, and
	8171155
In-Reply-To: <20161219225156.GA4231@vimes>
References: <8de202d8-e726-cf32-d8cc-af1566d33e57@oracle.com>
	<77391954-5386-ce4b-39f3-10769d038945@oracle.com>
	<20161219225156.GA4231@vimes>
Message-ID: <9ef72691-121d-91a0-f0e9-b41f6e8b616b@oracle.com>

Thank you, Vladimir, for the review!
Thank you, Rob, for approving!

Best regards,


Zoltan

On 12/19/2016 11:51 PM, Rob McKenna wrote:
> Approved
>
>      -Rob
>
> On 19/12/16 01:53, Vladimir Kozlov wrote:
>> Looks good to me.
>>
>> Thanks,
>> Vladimir
>>
>> On 12/19/16 8:01 AM, Zolt?n Maj? wrote:
>>> Hi,
>>>
>>>
>>> please approve (and review in case of 8157181) the following backports
>>> to 8u:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8157181
>>> https://bugs.openjdk.java.net/browse/JDK-8160551
>>> https://bugs.openjdk.java.net/browse/JDK-8171155
>>>
>>> 8160551 and 8171155 cleanly apply to 8u.
>>>
>>> As suggested by John Rose in a comment for 8159215, only a part of the
>>> 8157181 fix for 9 is backported to 8u. As a result, the backport of
>>> 8157181 does not apply cleanly to 8u (thus the review request). Here is
>>> the webrev for that change:
>>>
>>> http://cr.openjdk.java.net/~zmajo/8157181_8u/webrev.00/
>>>
>>> I tested the three changes combined with JPRT, all tests pass.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>


From kirill.zhaldybin at oracle.com  Tue Dec 20 12:56:35 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 20 Dec 2016 15:56:35 +0300
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
Message-ID: <58592A83.6020709@oracle.com>

Dear all,

Could you please review this fix for 8170936?

The issue was windows specific - remove() function failed to delete a 
directory on that platform.
I added delete_directory function which uses winapi RemoveDirectory 
function and also does GTest style check on its result.
I also changed TEST to TEST_VM on a few tests from the same file since 
they used ResourceMark and crashed if they were run isolated.

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

Thank you.

Regards, Kirill

From thomas.stuefe at gmail.com  Tue Dec 20 13:13:16 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 14:13:16 +0100
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <58592A83.6020709@oracle.com>
References: <58592A83.6020709@oracle.com>
Message-ID: <CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>

Hi Kirill,

thanks a lot for fixing this! This was an annoyance on Windows.

Just small remarks:
- RemoveDirectory will only work on empty directories. Recursively deleting
non-empty directories seems to be more difficult. So could you please add a
comment that this function only deletes empty directories and is not
intended to work recursively? Or rename the function to
delete_empty_directory()?
- You do not have to output errno if RemoveDirectory failed, that number
will be unrelated to the error. GetLastError should be enough.

I also wonder why all those utilitiy functions are imeplemented in a header
file? I think it would be better for a C file (can change implementation
without triggering rebuild; also binary may be smaller, at least on
slowdebug).

Kind regards, Thomas


On Tue, Dec 20, 2016 at 1:56 PM, Kirill Zhaldybin <
kirill.zhaldybin at oracle.com> wrote:

> Dear all,
>
> Could you please review this fix for 8170936?
>
> The issue was windows specific - remove() function failed to delete a
> directory on that platform.
> I added delete_directory function which uses winapi RemoveDirectory
> function and also does GTest style check on its result.
> I also changed TEST to TEST_VM on a few tests from the same file since
> they used ResourceMark and crashed if they were run isolated.
>
> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/web
> rev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8170936
>
> Thank you.
>
> Regards, Kirill
>

From thomas.stuefe at gmail.com  Tue Dec 20 13:13:55 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 14:13:55 +0100
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
References: <58592A83.6020709@oracle.com>
	<CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
Message-ID: <CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>

(also, I am not a (R)eviewer, so I guess this does not count as real review)

On Tue, Dec 20, 2016 at 2:13 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Kirill,
>
> thanks a lot for fixing this! This was an annoyance on Windows.
>
> Just small remarks:
> - RemoveDirectory will only work on empty directories. Recursively
> deleting non-empty directories seems to be more difficult. So could you
> please add a comment that this function only deletes empty directories and
> is not intended to work recursively? Or rename the function to
> delete_empty_directory()?
> - You do not have to output errno if RemoveDirectory failed, that number
> will be unrelated to the error. GetLastError should be enough.
>
> I also wonder why all those utilitiy functions are imeplemented in a
> header file? I think it would be better for a C file (can change
> implementation without triggering rebuild; also binary may be smaller, at
> least on slowdebug).
>
> Kind regards, Thomas
>
>
> On Tue, Dec 20, 2016 at 1:56 PM, Kirill Zhaldybin <
> kirill.zhaldybin at oracle.com> wrote:
>
>> Dear all,
>>
>> Could you please review this fix for 8170936?
>>
>> The issue was windows specific - remove() function failed to delete a
>> directory on that platform.
>> I added delete_directory function which uses winapi RemoveDirectory
>> function and also does GTest style check on its result.
>> I also changed TEST to TEST_VM on a few tests from the same file since
>> they used ResourceMark and crashed if they were run isolated.
>>
>> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/web
>> rev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8170936
>>
>> Thank you.
>>
>> Regards, Kirill
>>
>
>

From kirill.zhaldybin at oracle.com  Tue Dec 20 18:04:05 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 20 Dec 2016 21:04:05 +0300
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>
References: <58592A83.6020709@oracle.com>
	<CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
	<CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>
Message-ID: <58597295.1060009@oracle.com>

Thomas,

Thank you for you comments. I really appreciate your review.
Here are a new WebRev: 
http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.01/

Changes:
1. renamed delete_directory to delete_empty_directory
2. left only GetLastError() in error output

Could you please also read comments inline?

Thank you.

Regards, Kirill

On 20.12.2016 16:13, Thomas St?fe wrote:
> (also, I am not a (R)eviewer, so I guess this does not count as real review)
>
> On Tue, Dec 20, 2016 at 2:13 PM, Thomas St?fe <thomas.stuefe at gmail.com
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi Kirill,
>
>     thanks a lot for fixing this! This was an annoyance on Windows.
>
>     Just small remarks:
>     - RemoveDirectory will only work on empty directories. Recursively
>     deleting non-empty directories seems to be more difficult. So could
>     you please add a comment that this function only deletes empty
>     directories and is not intended to work recursively? Or rename the
>     function to delete_empty_directory()?
fixed
>     - You do not have to output errno if RemoveDirectory failed, that
>     number will be unrelated to the error. GetLastError should be enough.
fixed
>
>     I also wonder why all those utilitiy functions are imeplemented in a
>     header file? I think it would be better for a C file (can change
>     implementation without triggering rebuild; also binary may be
>     smaller, at least on slowdebug).
well, I do not know why it was implemented that way but I could 
speculate that it was simpler (one file instead of two), the functions 
were not supposed to be changed often and side effects (size and build 
time increase) were not considered significant.
But it is only my speculations :)
If you think we should change this could you  please let me know? I will 
file an RFE.
>
>     Kind regards, Thomas
>
>
>     On Tue, Dec 20, 2016 at 1:56 PM, Kirill Zhaldybin
>     <kirill.zhaldybin at oracle.com <mailto:kirill.zhaldybin at oracle.com>>
>     wrote:
>
>         Dear all,
>
>         Could you please review this fix for 8170936?
>
>         The issue was windows specific - remove() function failed to
>         delete a directory on that platform.
>         I added delete_directory function which uses winapi
>         RemoveDirectory function and also does GTest style check on its
>         result.
>         I also changed TEST to TEST_VM on a few tests from the same file
>         since they used ResourceMark and crashed if they were run isolated.
>
>         WebRev:
>         http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.00/
>         <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.00/>
>         CR: https://bugs.openjdk.java.net/browse/JDK-8170936
>         <https://bugs.openjdk.java.net/browse/JDK-8170936>
>
>         Thank you.
>
>         Regards, Kirill
>
>
>


From kirill.zhaldybin at oracle.com  Tue Dec 20 18:18:16 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 20 Dec 2016 21:18:16 +0300
Subject: RFR(XXS): 8171517: test_logMessageTest.cpp has "ac_heapanied" instead
	of "accompanied" inside copyright notice
Message-ID: <585975E8.5040403@oracle.com>

Dear all,

Could you please review this small fix for 8171517?

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

Thank you.

Regards, Kirill

From joseph.provino at oracle.com  Tue Dec 20 18:21:08 2016
From: joseph.provino at oracle.com (Joseph Provino)
Date: Tue, 20 Dec 2016 13:21:08 -0500
Subject: RFR(XXS): 8171517: test_logMessageTest.cpp has "ac_heapanied"
	instead of "accompanied" inside copyright notice
In-Reply-To: <585975E8.5040403@oracle.com>
References: <585975E8.5040403@oracle.com>
Message-ID: <0cc37746-db21-3fa1-8bbc-4f35fa06666a@oracle.com>

Looks good!

joe


On 12/20/2016 1:18 PM, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please review this small fix for 8171517?
>
> WebRev: 
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171517/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8171517
>
> Thank you.
>
> Regards, Kirill


From serguei.spitsyn at oracle.com  Tue Dec 20 19:13:33 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 20 Dec 2016 11:13:33 -0800
Subject: RFR(XXS): 8171517: test_logMessageTest.cpp has "ac_heapanied"
	instead of "accompanied" inside copyright notice
In-Reply-To: <585975E8.5040403@oracle.com>
References: <585975E8.5040403@oracle.com>
Message-ID: <7da6f645-55aa-ccb9-3664-96a547021e74@oracle.com>

Hi Kirill,

Looks good.

Thanks,
Serguei


On 12/20/16 10:18, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please review this small fix for 8171517?
>
> WebRev: 
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171517/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8171517
>
> Thank you.
>
> Regards, Kirill


From igor.ignatyev at oracle.com  Tue Dec 20 19:33:34 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 20 Dec 2016 22:33:34 +0300
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <58597295.1060009@oracle.com>
References: <58592A83.6020709@oracle.com>
	<CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
	<CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>
	<58597295.1060009@oracle.com>
Message-ID: <D8E014EA-26F7-4B4A-9B02-3A55DBBC71B7@oracle.com>


> On Dec 20, 2016, at 9:04 PM, Kirill Zhaldybin <kirill.zhaldybin at oracle.com> wrote:
> 
> Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.01/

Hi Kirill,

webrev.01 looks good to me

Thanks,
? Igor

From thomas.stuefe at gmail.com  Tue Dec 20 20:20:07 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 20 Dec 2016 21:20:07 +0100
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <58597295.1060009@oracle.com>
References: <58592A83.6020709@oracle.com>
	<CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
	<CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>
	<58597295.1060009@oracle.com>
Message-ID: <CAA-vtUzpbnMdXYjGeN6+6i1pHSFBVhByiUegPm3Fzid9E9m11A@mail.gmail.com>

Hi Kirill,

This looks fine now to me. Thanks for fixing!

Further comments inline.

On Tue, Dec 20, 2016 at 7:04 PM, Kirill Zhaldybin <
kirill.zhaldybin at oracle.com> wrote:

> Thomas,
>
> Thank you for you comments. I really appreciate your review.
> Here are a new WebRev: http://cr.openjdk.java.net/~kz
> haldyb/webrevs/JDK-8170936/webrev.01/
>
> Changes:
> 1. renamed delete_directory to delete_empty_directory
> 2. left only GetLastError() in error output
>
> Could you please also read comments inline?
>
> Thank you.
>
> Regards, Kirill
>
> On 20.12.2016 16:13, Thomas St?fe wrote:
>
>> (also, I am not a (R)eviewer, so I guess this does not count as real
>> review)
>>
>> On Tue, Dec 20, 2016 at 2:13 PM, Thomas St?fe <thomas.stuefe at gmail.com
>> <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>     Hi Kirill,
>>
>>     thanks a lot for fixing this! This was an annoyance on Windows.
>>
>>     Just small remarks:
>>     - RemoveDirectory will only work on empty directories. Recursively
>>     deleting non-empty directories seems to be more difficult. So could
>>     you please add a comment that this function only deletes empty
>>     directories and is not intended to work recursively? Or rename the
>>     function to delete_empty_directory()?
>>
> fixed
>
>>     - You do not have to output errno if RemoveDirectory failed, that
>>     number will be unrelated to the error. GetLastError should be enough.
>>
> fixed
>
>>
>>     I also wonder why all those utilitiy functions are imeplemented in a
>>     header file? I think it would be better for a C file (can change
>>     implementation without triggering rebuild; also binary may be
>>     smaller, at least on slowdebug).
>>
> well, I do not know why it was implemented that way but I could speculate
> that it was simpler (one file instead of two), the functions were not
> supposed to be changed often and side effects (size and build time
> increase) were not considered significant.
> But it is only my speculations :)
> If you think we should change this could you  please let me know? I will
> file an RFE.
>

I do not have strong emotions, just small preferences :) I would leave it
up to Marcus, this is more of a style question.

Kind Regards, Thomas


>
>>     Kind regards, Thomas
>>
>>
>>     On Tue, Dec 20, 2016 at 1:56 PM, Kirill Zhaldybin
>>     <kirill.zhaldybin at oracle.com <mailto:kirill.zhaldybin at oracle.com>>
>>     wrote:
>>
>>         Dear all,
>>
>>         Could you please review this fix for 8170936?
>>
>>         The issue was windows specific - remove() function failed to
>>         delete a directory on that platform.
>>         I added delete_directory function which uses winapi
>>         RemoveDirectory function and also does GTest style check on its
>>         result.
>>         I also changed TEST to TEST_VM on a few tests from the same file
>>         since they used ResourceMark and crashed if they were run
>> isolated.
>>
>>         WebRev:
>>         http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/web
>> rev.00/
>>         <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/we
>> brev.00/>
>>         CR: https://bugs.openjdk.java.net/browse/JDK-8170936
>>         <https://bugs.openjdk.java.net/browse/JDK-8170936>
>>
>>         Thank you.
>>
>>         Regards, Kirill
>>
>>
>>
>>
>

From vladimir.kozlov at oracle.com  Wed Dec 21 05:10:46 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Dec 2016 21:10:46 -0800
Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks
In-Reply-To: <cb3813b6-7380-9a9c-21d9-069d7ab8e037@oracle.com>
References: <ce73e0fc-3716-3fc9-d476-de89b73e4017@oracle.com>
	<7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com>
	<5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com>
	<171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com>
	<215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com>
	<1182298D-0703-4F6C-A0B6-D23865233792@oracle.com>
	<cb3813b6-7380-9a9c-21d9-069d7ab8e037@oracle.com>
Message-ID: <5591a5fa-57b9-ca21-be0a-5923bb9fe013@oracle.com>

By suggestion from Aleksey we are pushing this into jdk9/dev directly to 
get it for promotion testing this week:

Aleksey Voytilov wrote:
 > Vladimir, if this fix can help with AOT stability, do you think we 
could get it in /dev before promotion starts? I'd like not to waste our 
lab running bigapps for weeks with known stability issues.

Note, this is AOT related changes. And Alexey is talked about additional 
bigapps testing which will use aoted java.base module.
Normal testing should not be affected since AOT is off by default 
(unless AOT libraries are present).

Thanks,
Vladimir

On 12/20/16 8:35 PM, dean.long at oracle.com wrote:
> Thanks Tom.
>
> dl
>
>
> On 12/20/16 8:30 PM, Tom Rodriguez wrote:
>>
>>> On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com
>>> <mailto:dean.long at oracle.com> wrote:
>>>
>>> On 12/20/16 3:34 PM, Vladimir Kozlov wrote:
>>>
>>>> On 12/20/16 1:44 PM, Tom Rodriguez wrote:
>>>>>
>>>>>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov
>>>>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Thank you, Dean, for finding the cause.
>>>>>>
>>>>>> Looks good to me.
>>>>>>
>>>>>> CCing to Graal since it affects it. I am curious why Labs did not
>>>>>> hit it before.
>>>>>
>>>>> Not sure either, though AOT?s been running for a while without
>>>>> seeing it either.
>>>>>
>>>>> I?m a unsure that this is the right logic though.  If you look at
>>>>> how C2 is setting this flag it?s driven by lower level code
>>>>> generation details.  Basically it?s looking at the underlying call
>>>>> object at the debug info site to determine if that call is
>>>>> returning an oop.  Will that produce the same answer as checking
>>>>> the return type of the call?  For any site which is a normal method
>>>>> invoke I think it will but what about other calls like a vm entry
>>>>> point?
>>>>
>>>
>>> Is there a VM entry point that returns an oop in a register?
>>
>> From the perspective of code generation the allocation paths do this.
>>  But to answer my own question, I think c2 may be setting it to true
>> under conditions where it will never be consulted.  Any VM entry point
>> that actually returns an oop uses a stub to handle it and passes the
>> value through vm_result so it?s handled across the safe point.  You
>> can't actually stop at the call site pc when you deoptimize.  I think
>> a correct value is only required for real Java invoke sites.
>>
>>>
>>>> I agree, C2 is checking is_ptr() which include metadata pointers.
>>>>
>>>
>>> It must be an oop, not metadata:
>>>
>>>        oop result = deoptee.saved_oop_result(&map);
>>>        assert(result == NULL || result->is_oop(), "must be oop?);
>>
>> The code is using isa_ptr() so any pointer return value will set it to
>> true which is clearly wrong.  I suspect any path which might set this
>> incorrectly simply will never consult the value.
>>
>> So I think your fix for JVMCI looks right.  And the existing C2 code
>> is benignly wrong.
>>
>> tom
>>
>>>
>>> dl
>>>
>>>> In such case we need help from you. I think pointer return
>>>> information can be recorded in DebugInfo or Call class.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>>>
>>>>> tom
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 12/19/16 1:22 PM, dean.long at oracle.com
>>>>>> <mailto:dean.long at oracle.com> wrote:
>>>>>>> AOT code, like C2 code, can reallocate objects during deoptimization,
>>>>>>> because of escape analysis.  To support this, we need to set the
>>>>>>> "return_oop" flag on the scope correctly.
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8169938
>>>>>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/
>>>>>>>
>>>>>>> dl
>>
>

From simon at cjnash.com  Wed Dec 21 07:43:18 2016
From: simon at cjnash.com (Simon Nash)
Date: Wed, 21 Dec 2016 07:43:18 +0000
Subject: JEP 297: Unified arm32/arm64 Port latest Merge
In-Reply-To: <1481797424.2342.8.camel@gmail.com>
References: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com>
	<1481797424.2342.8.camel@gmail.com>
Message-ID: <585A3296.6000008@cjnash.com>

On 15/12/2016 10:23, Edward Nevill wrote:
> On Tue, 2016-12-13 at 13:16 -0500, Bob Vandette wrote:
>> Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest.
>>
>> I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday. 
>>
>> http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/>
>> http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/>
>> http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ <http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/>
>>
> 
> Looks good. I have built the hs repo with these patches and run jtreg on x86, arm64 and arm32. Here is a summary of the results.
> 
> x86:
> 
> hotspot: passed: 1,372; failed: 30; error: 55
> langtools: 3,773; failed: 12; error: 9
> jdk: passed: 6,378; failed: 202; error: 10
> 
> arm64:
> 
> hotspot: passed: 1,315; failed: 31; error: 49
> langtools: 3,772; failed: 10; error: 10
> jdk: passed: 6,433; failed: 148; error: 8
> 
> arm32:
> 
> hotspot: 1,212; failed: 50; error: 48
> langtools: passed: 3,771; failed: 14; error: 9
> jdk: passed: 6,043; failed: 442; error: 18
> 
> There were no failures due to fatal errors (ie, SEGV, ABORT, assert/guarantee failure etc).
> 
> Currently running jcstress, results in approx 10 hours.
> 
> All the best,
> Ed.
> 
> 
What is the current status of this?  Have the necessary approvals been
given for this merge to happen?

Simon

From kirill.zhaldybin at oracle.com  Wed Dec 21 08:02:21 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 21 Dec 2016 11:02:21 +0300
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <D8E014EA-26F7-4B4A-9B02-3A55DBBC71B7@oracle.com>
References: <58592A83.6020709@oracle.com>
	<CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
	<CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>
	<58597295.1060009@oracle.com>
	<D8E014EA-26F7-4B4A-9B02-3A55DBBC71B7@oracle.com>
Message-ID: <585A370D.8040407@oracle.com>

Igor,

Thank you for review!

Regards, Kirill

On 20.12.2016 22:33, Igor Ignatyev wrote:
>
>> On Dec 20, 2016, at 9:04 PM, Kirill Zhaldybin <kirill.zhaldybin at oracle.com> wrote:
>>
>> Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.01/
>
> Hi Kirill,
>
> webrev.01 looks good to me
>
> Thanks,
> ? Igor
>


From kirill.zhaldybin at oracle.com  Wed Dec 21 08:03:12 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 21 Dec 2016 11:03:12 +0300
Subject: RFR(S): 8170936: Logging: LogFileOutput.invalid_file_test crashes
	when executed twice.
In-Reply-To: <CAA-vtUzpbnMdXYjGeN6+6i1pHSFBVhByiUegPm3Fzid9E9m11A@mail.gmail.com>
References: <58592A83.6020709@oracle.com>
	<CAA-vtUz_SixqajT_pP6TEvDcQvtxY2tD0MHm2X8tKS=7CEamUA@mail.gmail.com>
	<CAA-vtUw2yf=5tqT750j9C83kME8N1b8QSm-2m_ihEQKuD3=7Tw@mail.gmail.com>
	<58597295.1060009@oracle.com>
	<CAA-vtUzpbnMdXYjGeN6+6i1pHSFBVhByiUegPm3Fzid9E9m11A@mail.gmail.com>
Message-ID: <585A3740.2080008@oracle.com>

Thomas,

Thank you for review!

Regards, Kirill

On 20.12.2016 23:20, Thomas St?fe wrote:
> Hi Kirill,
>
> This looks fine now to me. Thanks for fixing!
>
> Further comments inline.
>
> On Tue, Dec 20, 2016 at 7:04 PM, Kirill Zhaldybin
> <kirill.zhaldybin at oracle.com <mailto:kirill.zhaldybin at oracle.com>> wrote:
>
>     Thomas,
>
>     Thank you for you comments. I really appreciate your review.
>     Here are a new WebRev:
>     http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.01/
>     <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.01/>
>
>     Changes:
>     1. renamed delete_directory to delete_empty_directory
>     2. left only GetLastError() in error output
>
>     Could you please also read comments inline?
>
>     Thank you.
>
>     Regards, Kirill
>
>     On 20.12.2016 16:13, Thomas St?fe wrote:
>
>         (also, I am not a (R)eviewer, so I guess this does not count as
>         real review)
>
>         On Tue, Dec 20, 2016 at 2:13 PM, Thomas St?fe
>         <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>
>         <mailto:thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>>> wrote:
>
>              Hi Kirill,
>
>              thanks a lot for fixing this! This was an annoyance on Windows.
>
>              Just small remarks:
>              - RemoveDirectory will only work on empty directories.
>         Recursively
>              deleting non-empty directories seems to be more difficult.
>         So could
>              you please add a comment that this function only deletes empty
>              directories and is not intended to work recursively? Or
>         rename the
>              function to delete_empty_directory()?
>
>     fixed
>
>              - You do not have to output errno if RemoveDirectory
>         failed, that
>              number will be unrelated to the error. GetLastError should
>         be enough.
>
>     fixed
>
>
>              I also wonder why all those utilitiy functions are
>         imeplemented in a
>              header file? I think it would be better for a C file (can
>         change
>              implementation without triggering rebuild; also binary may be
>              smaller, at least on slowdebug).
>
>     well, I do not know why it was implemented that way but I could
>     speculate that it was simpler (one file instead of two), the
>     functions were not supposed to be changed often and side effects
>     (size and build time increase) were not considered significant.
>     But it is only my speculations :)
>     If you think we should change this could you  please let me know? I
>     will file an RFE.
>
>
> I do not have strong emotions, just small preferences :) I would leave
> it up to Marcus, this is more of a style question.
>
> Kind Regards, Thomas
>
>
>              Kind regards, Thomas
>
>
>              On Tue, Dec 20, 2016 at 1:56 PM, Kirill Zhaldybin
>              <kirill.zhaldybin at oracle.com
>         <mailto:kirill.zhaldybin at oracle.com>
>         <mailto:kirill.zhaldybin at oracle.com
>         <mailto:kirill.zhaldybin at oracle.com>>>
>              wrote:
>
>                  Dear all,
>
>                  Could you please review this fix for 8170936?
>
>                  The issue was windows specific - remove() function
>         failed to
>                  delete a directory on that platform.
>                  I added delete_directory function which uses winapi
>                  RemoveDirectory function and also does GTest style
>         check on its
>                  result.
>                  I also changed TEST to TEST_VM on a few tests from the
>         same file
>                  since they used ResourceMark and crashed if they were
>         run isolated.
>
>                  WebRev:
>         http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.00/
>         <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.00/>
>
>         <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.00/
>         <http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8170936/webrev.00/>>
>                  CR: https://bugs.openjdk.java.net/browse/JDK-8170936
>         <https://bugs.openjdk.java.net/browse/JDK-8170936>
>                  <https://bugs.openjdk.java.net/browse/JDK-8170936
>         <https://bugs.openjdk.java.net/browse/JDK-8170936>>
>
>                  Thank you.
>
>                  Regards, Kirill
>
>
>
>
>


From kirill.zhaldybin at oracle.com  Wed Dec 21 08:03:58 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 21 Dec 2016 11:03:58 +0300
Subject: RFR(XXS): 8171517: test_logMessageTest.cpp has "ac_heapanied"
	instead of "accompanied" inside copyright notice
In-Reply-To: <7da6f645-55aa-ccb9-3664-96a547021e74@oracle.com>
References: <585975E8.5040403@oracle.com>
	<7da6f645-55aa-ccb9-3664-96a547021e74@oracle.com>
Message-ID: <585A376E.2000604@oracle.com>

Serguei,

Thank you for review!

Regards, Kirill

On 20.12.2016 22:13, serguei.spitsyn at oracle.com wrote:
> Hi Kirill,
>
> Looks good.
>
> Thanks,
> Serguei
>
>
> On 12/20/16 10:18, Kirill Zhaldybin wrote:
>> Dear all,
>>
>> Could you please review this small fix for 8171517?
>>
>> WebRev:
>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171517/webrev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8171517
>>
>> Thank you.
>>
>> Regards, Kirill
>


From kirill.zhaldybin at oracle.com  Wed Dec 21 08:04:40 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 21 Dec 2016 11:04:40 +0300
Subject: RFR(XXS): 8171517: test_logMessageTest.cpp has "ac_heapanied"
	instead of "accompanied" inside copyright notice
In-Reply-To: <0cc37746-db21-3fa1-8bbc-4f35fa06666a@oracle.com>
References: <585975E8.5040403@oracle.com>
	<0cc37746-db21-3fa1-8bbc-4f35fa06666a@oracle.com>
Message-ID: <585A3798.8090508@oracle.com>

Joseph,

Thank you for review!

Regards, Kirill

On 20.12.2016 21:21, Joseph Provino wrote:
> Looks good!
>
> joe
>
>
> On 12/20/2016 1:18 PM, Kirill Zhaldybin wrote:
>> Dear all,
>>
>> Could you please review this small fix for 8171517?
>>
>> WebRev:
>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171517/webrev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8171517
>>
>> Thank you.
>>
>> Regards, Kirill
>


From edward.nevill at gmail.com  Wed Dec 21 10:16:53 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Wed, 21 Dec 2016 10:16:53 +0000
Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact
	shifts by 31 instead of 63
In-Reply-To: <d94a5c4f-3006-557b-f62d-e7f074bebc98@redhat.com>
References: <1482142162.2883.4.camel@gmail.com>
	<d94a5c4f-3006-557b-f62d-e7f074bebc98@redhat.com>
Message-ID: <1482315413.2303.4.camel@gmail.com>

On Mon, 2016-12-19 at 11:33 +0000, Andrew Dinn wrote:
> Hi Ed,
> 
> On 19/12/16 10:09, Edward Nevill wrote:
> > 
> > Please review the following webrev ...
> The change looks good to me.
> 
> Andrew Dinn

Thanks Andrew, could I have an official Reviewer please.

All the best,
Ed.


From aph at redhat.com  Wed Dec 21 10:29:31 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 21 Dec 2016 10:29:31 +0000
Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact
	shifts by 31 instead of 63
In-Reply-To: <1482315413.2303.4.camel@gmail.com>
References: <1482142162.2883.4.camel@gmail.com>
	<d94a5c4f-3006-557b-f62d-e7f074bebc98@redhat.com>
	<1482315413.2303.4.camel@gmail.com>
Message-ID: <54cbf252-9996-1066-22a2-be43d955bd2d@redhat.com>

On 21/12/16 10:16, Edward Nevill wrote:
> Thanks Andrew, could I have an official Reviewer please.

OK.

Andrew.


From kirill.zhaldybin at oracle.com  Wed Dec 21 10:36:05 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 21 Dec 2016 13:36:05 +0300
Subject: RFR(S): 8171848: ObjectMonitor verify() and print() methods are empty
Message-ID: <585A5B15.80607@oracle.com>

Dear all,

Could you please review this fix for 8171848?
I deleted both methods from ObjectMonitor and the code which was not 
doing anything from ObjectSynchronizer::verify().
I did local and rbt testing to be sure that I found all calls to deleted 
methods.

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

Thank you.

Regards, Kirill

From david.holmes at oracle.com  Wed Dec 21 12:46:38 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 21 Dec 2016 22:46:38 +1000
Subject: RFR(S): 8171848: ObjectMonitor verify() and print() methods are
	empty
In-Reply-To: <585A5B15.80607@oracle.com>
References: <585A5B15.80607@oracle.com>
Message-ID: <83afe5b7-abb5-a960-b92b-655284a54531@oracle.com>

Hi Kirill,

This cleanup is considered an enhancement and as such is no longer 
acceptable in JDK 9 - sorry. The CR has been re-targetted to JDK 10.

The removal itself seems okay. I wonder whether 
ObjectSynchronizer::verify is itself ever called?

David

On 21/12/2016 8:36 PM, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please review this fix for 8171848?
> I deleted both methods from ObjectMonitor and the code which was not
> doing anything from ObjectSynchronizer::verify().
> I did local and rbt testing to be sure that I found all calls to deleted
> methods.
>
> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171848/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8171848
>
> Thank you.
>
> Regards, Kirill

From kirill.zhaldybin at oracle.com  Wed Dec 21 13:24:55 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 21 Dec 2016 16:24:55 +0300
Subject: RFR(S): 8171848: ObjectMonitor verify() and print() methods are
	empty
In-Reply-To: <83afe5b7-abb5-a960-b92b-655284a54531@oracle.com>
References: <585A5B15.80607@oracle.com>
	<83afe5b7-abb5-a960-b92b-655284a54531@oracle.com>
Message-ID: <0f2829ac-a404-b256-41fc-0bd6d1b56656@oracle.com>

David,

Thank you for review!

On 21.12.2016 15:46, David Holmes wrote:
> Hi Kirill,
>
> This cleanup is considered an enhancement and as such is no longer 
> acceptable in JDK 9 - sorry. The CR has been re-targetted to JDK 10.
>
> The removal itself seems okay. I wonder whether 
> ObjectSynchronizer::verify is itself ever called?
I did not find any calls to it but it was after I sent WebRev.
I will double-check and will send new one if we can just delete 
ObjectSynchronizer::verify.

Regards, Kirill
>
> David
>
> On 21/12/2016 8:36 PM, Kirill Zhaldybin wrote:
>> Dear all,
>>
>> Could you please review this fix for 8171848?
>> I deleted both methods from ObjectMonitor and the code which was not
>> doing anything from ObjectSynchronizer::verify().
>> I did local and rbt testing to be sure that I found all calls to deleted
>> methods.
>>
>> WebRev: 
>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171848/webrev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8171848
>>
>> Thank you.
>>
>> Regards, Kirill


From dmitry.fazunenko at oracle.com  Wed Dec 21 14:16:16 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Wed, 21 Dec 2016 17:16:16 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of
	tools which failed checks
Message-ID: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>

Hello,

I'm looking for reviews of a relatively simple test change:
     http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/
     https://bugs.openjdk.java.net/browse/JDK-8171441

The purpose of the change is to improve diagnostic.

Thanks,
Dima

PS: After the fix the failures will be reported as:

----------System.err:(13/956)----------
java.lang.AssertionError: VersionCheck failed: testJVersionStrings: 
[java]; testToolVersion: [jar];
     at VersionCheck.main(VersionCheck.java:295)
     at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
     at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
     at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.base/java.lang.reflect.Method.invoke(Method.java:538)
     at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
     at java.base/java.lang.Thread.run(Thread.java:844)

JavaTest Message: Test threw exception: java.lang.AssertionError: 
VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.AssertionError: 
VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];

PPS: The output of passed test now looks like:

=== testJVersionStrings ===
Testing servertool
Testing jstat
Testing jmod
Testing jjs
Testing jimage
Testing jlink
Testing jrunscript
Testing jdeprscan
Testing jconsole
Testing rmiregistry
Testing keytool
Testing schemagen
Testing javac
Testing jar
Testing jhsdb
Testing jcmd
Testing jstack
Testing wsgen
Testing jshell
Testing serialver
Testing jmap
Testing javap
Testing jps
Testing jstatd
Testing javadoc
Testing tnameserv
Testing jdb
Testing jinfo
Testing jdeps
Testing xjc
Testing rmid
Testing jarsigner
Testing idlj
Testing rmic
Testing appletviewer
Testing pack200
Testing javah
Testing policytool
Testing orbd
testJVersionStrings passed
=== testInternalStrings ===
testInternalStrings passed
=== testToolVersion ===
Testing java
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java 
-version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+149)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
#> echo $?
0
Testing javac
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac 
-version
javac 9-ea
#> echo $?
0
Testing jhsdb
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb 
-version
     clhsdb           command line debugger
     debugd           debug server
     hsdb             ui debugger
     jstack --help    to get more information
     jmap   --help    to get more information
     jinfo  --help    to get more information
     jsnap  --help    to get more information
#> echo $?
0
Testing jshell
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell 
-version
jshell 9-ea
#> echo $?
0
Testing javap
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap 
-version
9-ea
#> echo $?
0
Testing jdb
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb 
-version
This is jdb version 9.0 (Java SE version 9-ea)
#> echo $?
0
Testing idlj
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj 
-version
IDL-to-Java compiler (portable), version "3.2"
#> echo $?
0
Testing javah
#> 
/net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah 
-version

Warning: The javah tool is planned to be removed in the next major
JDK release. The tool has been superseded by the '-h' option added
to javac in JDK 8. Users are recommended to migrate to using the
javac '-h' option; see the javac man page for more information.

javah version "9-ea"
#> echo $?
0
testToolVersion passed
=== testInternalStrings ===
testDebugVersion passed
All Version string comparisons: PASS
----------System.err:(1/15)----------


From bob.vandette at oracle.com  Wed Dec 21 17:04:27 2016
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 21 Dec 2016 12:04:27 -0500
Subject: JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master
Message-ID: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com>

I am please to announce that the source changes for JEP 297: Unified arm32/arm64 Port
have now been integrated into the JDK 9 Master forest (http://hg.openjdk.java.net/jdk9/jdk9).

JEP URL:    http://openjdk.java.net/jeps/297

This means that we made feature complete cutoff and JDK 9 will now include an open sourced hybrid 
32 and 64-bit ARM port.

Thanks to everyone on the aarch32, aarch64, hotspot and build teams that helped with the JEP process, 
reviews and testing.  

Bob.





From edward.nevill at gmail.com  Wed Dec 21 17:15:54 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Wed, 21 Dec 2016 17:15:54 +0000
Subject: JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master
In-Reply-To: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com>
References: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com>
Message-ID: <1482340554.2303.8.camel@gmail.com>

On Wed, 2016-12-21 at 12:04 -0500, Bob Vandette wrote:
>?
> JEP URL:????http://openjdk.java.net/jeps/297
> 
> This means that we made feature complete cutoff and JDK 9 will now
> include an open sourced hybrid?
> 32 and 64-bit ARM port.

This is excellent news Bob. Thank you for all your hard work
integrating this.

Also, thanks to Oracle for agreeing to open source the unified
arm32/arm64 port. This is a major milestone for ARM.

All the best,
Ed.


From simon at cjnash.com  Wed Dec 21 17:56:32 2016
From: simon at cjnash.com (Simon Nash)
Date: Wed, 21 Dec 2016 17:56:32 +0000
Subject: JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master
In-Reply-To: <1482340554.2303.8.camel@gmail.com>
References: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com>
	<1482340554.2303.8.camel@gmail.com>
Message-ID: <585AC250.6090805@cjnash.com>

On 21/12/2016 17:15, Edward Nevill wrote:
> On Wed, 2016-12-21 at 12:04 -0500, Bob Vandette wrote:
>>  
>> JEP URL:    http://openjdk.java.net/jeps/297
>>
>> This means that we made feature complete cutoff and JDK 9 will now
>> include an open sourced hybrid 
>> 32 and 64-bit ARM port.
> 
> This is excellent news Bob. Thank you for all your hard work
> integrating this.
> 
> Also, thanks to Oracle for agreeing to open source the unified
> arm32/arm64 port. This is a major milestone for ARM.
> 
> All the best,
> Ed.
> 
> 
I would also like to add my thanks to all concerned.  This is a major
step towards establishing Java as a fully competitive industry platform
for ARM applications.

Best regards,
Simon

From stanislav.smirnov at oracle.com  Thu Dec 22 16:55:37 2016
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Thu, 22 Dec 2016 19:55:37 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
Message-ID: <D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>

Hi Dima,

changes look good, I will only suggest using lambda?s in couple of iterations
+            for (String s : tr.testOutput) {
+                System.out.println(s);
+            }
tr.testOutput.forEach(System.out::println)

         for (String x : tr.testOutput) {
             alist.add(x.trim());
         }
tr.testOutput.stream.map(String::trim).forEach(aList:add)


Best regards,
Stanislav Smirnov





> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
> 
> Hello,
> 
> I'm looking for reviews of a relatively simple test change:
>    http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/
>    https://bugs.openjdk.java.net/browse/JDK-8171441
> 
> The purpose of the change is to improve diagnostic.
> 
> Thanks,
> Dima
> 
> PS: After the fix the failures will be reported as:
> 
> ----------System.err:(13/956)----------
> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>    at VersionCheck.main(VersionCheck.java:295)
>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>    at java.base/java.lang.Thread.run(Thread.java:844)
> 
> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
> 
> PPS: The output of passed test now looks like:
> 
> === testJVersionStrings ===
> Testing servertool
> Testing jstat
> Testing jmod
> Testing jjs
> Testing jimage
> Testing jlink
> Testing jrunscript
> Testing jdeprscan
> Testing jconsole
> Testing rmiregistry
> Testing keytool
> Testing schemagen
> Testing javac
> Testing jar
> Testing jhsdb
> Testing jcmd
> Testing jstack
> Testing wsgen
> Testing jshell
> Testing serialver
> Testing jmap
> Testing javap
> Testing jps
> Testing jstatd
> Testing javadoc
> Testing tnameserv
> Testing jdb
> Testing jinfo
> Testing jdeps
> Testing xjc
> Testing rmid
> Testing jarsigner
> Testing idlj
> Testing rmic
> Testing appletviewer
> Testing pack200
> Testing javah
> Testing policytool
> Testing orbd
> testJVersionStrings passed
> === testInternalStrings ===
> testInternalStrings passed
> === testToolVersion ===
> Testing java
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+149)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
> #> echo $?
> 0
> Testing javac
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version
> javac 9-ea
> #> echo $?
> 0
> Testing jhsdb
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version
>    clhsdb           command line debugger
>    debugd           debug server
>    hsdb             ui debugger
>    jstack --help    to get more information
>    jmap   --help    to get more information
>    jinfo  --help    to get more information
>    jsnap  --help    to get more information
> #> echo $?
> 0
> Testing jshell
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version
> jshell 9-ea
> #> echo $?
> 0
> Testing javap
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version
> 9-ea
> #> echo $?
> 0
> Testing jdb
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version
> This is jdb version 9.0 (Java SE version 9-ea)
> #> echo $?
> 0
> Testing idlj
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version
> IDL-to-Java compiler (portable), version "3.2"
> #> echo $?
> 0
> Testing javah
> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version
> 
> Warning: The javah tool is planned to be removed in the next major
> JDK release. The tool has been superseded by the '-h' option added
> to javac in JDK 8. Users are recommended to migrate to using the
> javac '-h' option; see the javac man page for more information.
> 
> javah version "9-ea"
> #> echo $?
> 0
> testToolVersion passed
> === testInternalStrings ===
> testDebugVersion passed
> All Version string comparisons: PASS
> ----------System.err:(1/15)----------
> 


From dmitry.fazunenko at oracle.com  Fri Dec 23 08:55:28 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Fri, 23 Dec 2016 11:55:28 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
Message-ID: <b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>

Hi Stanislav,

Thanks for looking.
Updated webrev:
http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/

-- Dima


On 22.12.2016 19:55, Stanislav Smirnov wrote:
> Hi Dima,
>
> changes look good, I will only suggest using lambda?s in couple of 
> iterations
> +            for (String s : tr.testOutput) {
> +                System.out.println(s);
> +            }
> tr.testOutput.forEach(System.out::println)
>
>           for (String x : tr.testOutput) {
>               alist.add(x.trim());
>           }
> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>
>
> Best regards,
> Stanislav Smirnov
>
>
>
>
>
>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko 
>> <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>
>> Hello,
>>
>> I'm looking for reviews of a relatively simple test change:
>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>> https://bugs.openjdk.java.net/browse/JDK-8171441
>>
>> The purpose of the change is to improve diagnostic.
>>
>> Thanks,
>> Dima
>>
>> PS: After the fix the failures will be reported as:
>>
>> ----------System.err:(13/956)----------
>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: 
>> [java]; testToolVersion: [jar];
>>    at VersionCheck.main(VersionCheck.java:295)
>>    at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> Method)
>>    at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>    at 
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>    at 
>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>
>> JavaTest Message: Test threw exception: java.lang.AssertionError: 
>> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>> JavaTest Message: shutting down test
>>
>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: 
>> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>
>> PPS: The output of passed test now looks like:
>>
>> === testJVersionStrings ===
>> Testing servertool
>> Testing jstat
>> Testing jmod
>> Testing jjs
>> Testing jimage
>> Testing jlink
>> Testing jrunscript
>> Testing jdeprscan
>> Testing jconsole
>> Testing rmiregistry
>> Testing keytool
>> Testing schemagen
>> Testing javac
>> Testing jar
>> Testing jhsdb
>> Testing jcmd
>> Testing jstack
>> Testing wsgen
>> Testing jshell
>> Testing serialver
>> Testing jmap
>> Testing javap
>> Testing jps
>> Testing jstatd
>> Testing javadoc
>> Testing tnameserv
>> Testing jdb
>> Testing jinfo
>> Testing jdeps
>> Testing xjc
>> Testing rmid
>> Testing jarsigner
>> Testing idlj
>> Testing rmic
>> Testing appletviewer
>> Testing pack200
>> Testing javah
>> Testing policytool
>> Testing orbd
>> testJVersionStrings passed
>> === testInternalStrings ===
>> testInternalStrings passed
>> === testToolVersion ===
>> Testing java
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> 
>> -version
>> java version "9-ea"
>> Java(TM) SE Runtime Environment (build 9-ea+149)
>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>> #> echo $?
>> 0
>> Testing javac
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> 
>> -version
>> javac 9-ea
>> #> echo $?
>> 0
>> Testing jhsdb
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> 
>> -version
>>    clhsdb           command line debugger
>>    debugd           debug server
>>    hsdb             ui debugger
>>    jstack --help    to get more information
>>    jmap   --help    to get more information
>>    jinfo  --help    to get more information
>>    jsnap  --help    to get more information
>> #> echo $?
>> 0
>> Testing jshell
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> 
>> -version
>> jshell 9-ea
>> #> echo $?
>> 0
>> Testing javap
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> 
>> -version
>> 9-ea
>> #> echo $?
>> 0
>> Testing jdb
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> 
>> -version
>> This is jdb version 9.0 (Java SE version 9-ea)
>> #> echo $?
>> 0
>> Testing idlj
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> 
>> -version
>> IDL-to-Java compiler (portable), version "3.2"
>> #> echo $?
>> 0
>> Testing javah
>> #> 
>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah 
>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> 
>> -version
>>
>> Warning: The javah tool is planned to be removed in the next major
>> JDK release. The tool has been superseded by the '-h' option added
>> to javac in JDK 8. Users are recommended to migrate to using the
>> javac '-h' option; see the javac man page for more information.
>>
>> javah version "9-ea"
>> #> echo $?
>> 0
>> testToolVersion passed
>> === testInternalStrings ===
>> testDebugVersion passed
>> All Version string comparisons: PASS
>> ----------System.err:(1/15)----------
>>
>


From stanislav.smirnov at oracle.com  Fri Dec 23 10:40:16 2016
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Fri, 23 Dec 2016 13:40:16 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
Message-ID: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>

Hi,

sorry, missed this strange comment during the first review.
 152     /*
 153      * this tests if the tool can take a version string and returns
 154      * a 0 exit code, it is not possible to validate the contents
 155      * of the -version output as they are inconsistent.
 156      */
 157     static String testToolVersion() {
It confuses me, can you please rephrase it?

Best regards,
Stanislav Smirnov





> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com> wrote:
> 
> Hi Stanislav,
> 
> Thanks for looking.
> Updated webrev:
> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ <http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/>
> 
> -- Dima
> 
> 
> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>> Hi Dima,
>> 
>> changes look good, I will only suggest using lambda?s in couple of iterations
>> +            for (String s : tr.testOutput) {
>> +                System.out.println(s);
>> +            }
>> tr.testOutput.forEach(System.out::println)
>> 
>>          for (String x : tr.testOutput) {
>>              alist.add(x.trim());
>>          }
>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>> 
>> 
>> Best regards,
>> Stanislav Smirnov
>> 
>> 
>> 
>> 
>> 
>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>> 
>>> Hello,
>>> 
>>> I'm looking for reviews of a relatively simple test change:
>>>    http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>    https://bugs.openjdk.java.net/browse/JDK-8171441 <https://bugs.openjdk.java.net/browse/JDK-8171441>
>>> 
>>> The purpose of the change is to improve diagnostic.
>>> 
>>> Thanks,
>>> Dima
>>> 
>>> PS: After the fix the failures will be reported as:
>>> 
>>> ----------System.err:(13/956)----------
>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>    at VersionCheck.main(VersionCheck.java:295)
>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>> 
>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>> JavaTest Message: shutting down test
>>> 
>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>> 
>>> PPS: The output of passed test now looks like:
>>> 
>>> === testJVersionStrings ===
>>> Testing servertool
>>> Testing jstat
>>> Testing jmod
>>> Testing jjs
>>> Testing jimage
>>> Testing jlink
>>> Testing jrunscript
>>> Testing jdeprscan
>>> Testing jconsole
>>> Testing rmiregistry
>>> Testing keytool
>>> Testing schemagen
>>> Testing javac
>>> Testing jar
>>> Testing jhsdb
>>> Testing jcmd
>>> Testing jstack
>>> Testing wsgen
>>> Testing jshell
>>> Testing serialver
>>> Testing jmap
>>> Testing javap
>>> Testing jps
>>> Testing jstatd
>>> Testing javadoc
>>> Testing tnameserv
>>> Testing jdb
>>> Testing jinfo
>>> Testing jdeps
>>> Testing xjc
>>> Testing rmid
>>> Testing jarsigner
>>> Testing idlj
>>> Testing rmic
>>> Testing appletviewer
>>> Testing pack200
>>> Testing javah
>>> Testing policytool
>>> Testing orbd
>>> testJVersionStrings passed
>>> === testInternalStrings ===
>>> testInternalStrings passed
>>> === testToolVersion ===
>>> Testing java
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>> java version "9-ea"
>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>> #> echo $?
>>> 0
>>> Testing javac
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>> javac 9-ea
>>> #> echo $?
>>> 0
>>> Testing jhsdb
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>    clhsdb           command line debugger
>>>    debugd           debug server
>>>    hsdb             ui debugger
>>>    jstack --help    to get more information
>>>    jmap   --help    to get more information
>>>    jinfo  --help    to get more information
>>>    jsnap  --help    to get more information
>>> #> echo $?
>>> 0
>>> Testing jshell
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>> jshell 9-ea
>>> #> echo $?
>>> 0
>>> Testing javap
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>> 9-ea
>>> #> echo $?
>>> 0
>>> Testing jdb
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>> This is jdb version 9.0 (Java SE version 9-ea)
>>> #> echo $?
>>> 0
>>> Testing idlj
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>> IDL-to-Java compiler (portable), version "3.2"
>>> #> echo $?
>>> 0
>>> Testing javah
>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>> 
>>> Warning: The javah tool is planned to be removed in the next major
>>> JDK release. The tool has been superseded by the '-h' option added
>>> to javac in JDK 8. Users are recommended to migrate to using the
>>> javac '-h' option; see the javac man page for more information.
>>> 
>>> javah version "9-ea"
>>> #> echo $?
>>> 0
>>> testToolVersion passed
>>> === testInternalStrings ===
>>> testDebugVersion passed
>>> All Version string comparisons: PASS
>>> ----------System.err:(1/15)----------
>>> 
>> 
> 


From dmitry.fazunenko at oracle.com  Fri Dec 23 16:13:35 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Fri, 23 Dec 2016 19:13:35 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
Message-ID: <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>

Hi,

new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/

This comment now looks like:

  152     /*
  153      * Checks if the tools accept "-version" option (exit code is zero).
  154      * The output of the tools run with "-version" is not verified.
  155      */


Thanks
Dima

On 23.12.2016 13:40, Stanislav Smirnov wrote:
> Hi,
>
> sorry, missed this strange comment during the first review.
>   152     /*
>   153      * this tests if the tool can take a version string and returns
>   154      * a 0 exit code, it is not possible to validate the contents
>   155      * of the -version output as they are inconsistent.
>   156      */
>   157     static String testToolVersion() {
> It confuses me, can you please rephrase it?
>
> Best regards,
> Stanislav Smirnov
>
>
>
>
>
>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko 
>> <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>
>> Hi Stanislav,
>>
>> Thanks for looking.
>> Updated webrev:
>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/
>>
>> -- Dima
>>
>>
>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>> Hi Dima,
>>>
>>> changes look good, I will only suggest using lambda?s in couple of 
>>> iterations
>>> +            for (String s : tr.testOutput) {
>>> +                System.out.println(s);
>>> +            }
>>> tr.testOutput.forEach(System.out::println)
>>>
>>>           for (String x : tr.testOutput) {
>>>               alist.add(x.trim());
>>>           }
>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>
>>>
>>> Best regards,
>>> Stanislav Smirnov
>>>
>>>
>>>
>>>
>>>
>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko 
>>>> <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> 
>>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm looking for reviews of a relatively simple test change:
>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>> https://bugs.openjdk.java.net/browse/JDK-8171441
>>>>
>>>> The purpose of the change is to improve diagnostic.
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> PS: After the fix the failures will be reported as:
>>>>
>>>> ----------System.err:(13/956)----------
>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: 
>>>> [java]; testToolVersion: [jar];
>>>>    at VersionCheck.main(VersionCheck.java:295)
>>>>    at 
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>>>> Method)
>>>>    at 
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>    at 
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>    at 
>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>>>
>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: 
>>>> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: 
>>>> [jar];
>>>> JavaTest Message: shutting down test
>>>>
>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: 
>>>> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: 
>>>> [jar];
>>>>
>>>> PPS: The output of passed test now looks like:
>>>>
>>>> === testJVersionStrings ===
>>>> Testing servertool
>>>> Testing jstat
>>>> Testing jmod
>>>> Testing jjs
>>>> Testing jimage
>>>> Testing jlink
>>>> Testing jrunscript
>>>> Testing jdeprscan
>>>> Testing jconsole
>>>> Testing rmiregistry
>>>> Testing keytool
>>>> Testing schemagen
>>>> Testing javac
>>>> Testing jar
>>>> Testing jhsdb
>>>> Testing jcmd
>>>> Testing jstack
>>>> Testing wsgen
>>>> Testing jshell
>>>> Testing serialver
>>>> Testing jmap
>>>> Testing javap
>>>> Testing jps
>>>> Testing jstatd
>>>> Testing javadoc
>>>> Testing tnameserv
>>>> Testing jdb
>>>> Testing jinfo
>>>> Testing jdeps
>>>> Testing xjc
>>>> Testing rmid
>>>> Testing jarsigner
>>>> Testing idlj
>>>> Testing rmic
>>>> Testing appletviewer
>>>> Testing pack200
>>>> Testing javah
>>>> Testing policytool
>>>> Testing orbd
>>>> testJVersionStrings passed
>>>> === testInternalStrings ===
>>>> testInternalStrings passed
>>>> === testToolVersion ===
>>>> Testing java
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> 
>>>> -version
>>>> java version "9-ea"
>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>> #> echo $?
>>>> 0
>>>> Testing javac
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> 
>>>> -version
>>>> javac 9-ea
>>>> #> echo $?
>>>> 0
>>>> Testing jhsdb
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> 
>>>> -version
>>>>    clhsdb           command line debugger
>>>>    debugd           debug server
>>>>    hsdb             ui debugger
>>>>    jstack --help    to get more information
>>>>    jmap   --help    to get more information
>>>>    jinfo  --help    to get more information
>>>>    jsnap  --help    to get more information
>>>> #> echo $?
>>>> 0
>>>> Testing jshell
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> 
>>>> -version
>>>> jshell 9-ea
>>>> #> echo $?
>>>> 0
>>>> Testing javap
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> 
>>>> -version
>>>> 9-ea
>>>> #> echo $?
>>>> 0
>>>> Testing jdb
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> 
>>>> -version
>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>> #> echo $?
>>>> 0
>>>> Testing idlj
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> 
>>>> -version
>>>> IDL-to-Java compiler (portable), version "3.2"
>>>> #> echo $?
>>>> 0
>>>> Testing javah
>>>> #> 
>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah 
>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> 
>>>> -version
>>>>
>>>> Warning: The javah tool is planned to be removed in the next major
>>>> JDK release. The tool has been superseded by the '-h' option added
>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>> javac '-h' option; see the javac man page for more information.
>>>>
>>>> javah version "9-ea"
>>>> #> echo $?
>>>> 0
>>>> testToolVersion passed
>>>> === testInternalStrings ===
>>>> testDebugVersion passed
>>>> All Version string comparisons: PASS
>>>> ----------System.err:(1/15)----------
>>>>
>>>
>>
>


From vladimir.kozlov at oracle.com  Sat Dec 24 00:23:13 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 23 Dec 2016 16:23:13 -0800
Subject: Hotspot for BSD / opinion request
In-Reply-To: <CA+XhMqy0L=6DHzHmFFJQWgn5VYXpv4EV6OHOdKCJ3iTah8RHSQ@mail.gmail.com>
References: <CA+XhMqy0L=6DHzHmFFJQWgn5VYXpv4EV6OHOdKCJ3iTah8RHSQ@mail.gmail.com>
Message-ID: <1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com>

Hi,

Forwarding to mailing lists since I can't answer.
May be someone can answer your question on these lists.

Regards,
Vladimir

On 12/23/16 2:17 AM, David CARLIER wrote:
> Hi,
>
> this is my first mail to the maiing list, I have difficulties to push
> messages to any mailing lists, but as BSD user/dev I was
> looking at code's part like this one
>
> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>
> I was wondering if it would be better to explicitally set the attr
> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>
> What do you think ?
>
> Thanks in advance.
>
> Kindest regards.
>

From david.holmes at oracle.com  Sat Dec 24 02:16:29 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 24 Dec 2016 12:16:29 +1000
Subject: Hotspot for BSD / opinion request
In-Reply-To: <1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com>
References: <CA+XhMqy0L=6DHzHmFFJQWgn5VYXpv4EV6OHOdKCJ3iTah8RHSQ@mail.gmail.com>
	<1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com>
Message-ID: <ef2ebc7c-4958-bab1-ced8-9b5baed49824@oracle.com>

If there is a platform, we support, where the default settings are 
inappropriate then setting them explicitly would be the right thing to do.

David

On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
> Hi,
>
> Forwarding to mailing lists since I can't answer.
> May be someone can answer your question on these lists.
>
> Regards,
> Vladimir
>
> On 12/23/16 2:17 AM, David CARLIER wrote:
>> Hi,
>>
>> this is my first mail to the maiing list, I have difficulties to push
>> messages to any mailing lists, but as BSD user/dev I was
>> looking at code's part like this one
>>
>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>
>>
>> I was wondering if it would be better to explicitally set the attr
>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>
>> What do you think ?
>>
>> Thanks in advance.
>>
>> Kindest regards.
>>

From stanislav.smirnov at oracle.com  Mon Dec 26 14:40:58 2016
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Mon, 26 Dec 2016 17:40:58 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
Message-ID: <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>

Hi,

thanks, looks good

Best regards,
Stanislav Smirnov





> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
> 
> Hi,
> 
> new version:  http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ <http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/>
> 
> This comment now looks like:
>  152     /*
>  153      * Checks if the tools accept "-version" option (exit code is zero).
>  154      * The output of the tools run with "-version" is not verified.
>  155      */
> 
> Thanks
> Dima
> 
> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>> Hi,
>> 
>> sorry, missed this strange comment during the first review.
>>  152     /*
>>  153      * this tests if the tool can take a version string and returns
>>  154      * a 0 exit code, it is not possible to validate the contents
>>  155      * of the -version output as they are inconsistent.
>>  156      */
>>  157     static String testToolVersion() {
>> It confuses me, can you please rephrase it?
>> 
>> Best regards,
>> Stanislav Smirnov
>> 
>> 
>> 
>> 
>> 
>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>> 
>>> Hi Stanislav,
>>> 
>>> Thanks for looking.
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.01/>
>>> 
>>> -- Dima
>>> 
>>> 
>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>> Hi Dima,
>>>> 
>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>> +            for (String s : tr.testOutput) {
>>>> +                System.out.println(s);
>>>> +            }
>>>> tr.testOutput.forEach(System.out::println)
>>>> 
>>>>          for (String x : tr.testOutput) {
>>>>              alist.add(x.trim());
>>>>          }
>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>> 
>>>> 
>>>> Best regards,
>>>> Stanislav Smirnov
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>    http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>    https://bugs.openjdk.java.net/browse/JDK-8171441 <https://bugs.openjdk.java.net/browse/JDK-8171441>
>>>>> 
>>>>> The purpose of the change is to improve diagnostic.
>>>>> 
>>>>> Thanks,
>>>>> Dima
>>>>> 
>>>>> PS: After the fix the failures will be reported as:
>>>>> 
>>>>> ----------System.err:(13/956)----------
>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>    at VersionCheck.main(VersionCheck.java:295)
>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>>>> 
>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>> JavaTest Message: shutting down test
>>>>> 
>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>> 
>>>>> PPS: The output of passed test now looks like:
>>>>> 
>>>>> === testJVersionStrings ===
>>>>> Testing servertool
>>>>> Testing jstat
>>>>> Testing jmod
>>>>> Testing jjs
>>>>> Testing jimage
>>>>> Testing jlink
>>>>> Testing jrunscript
>>>>> Testing jdeprscan
>>>>> Testing jconsole
>>>>> Testing rmiregistry
>>>>> Testing keytool
>>>>> Testing schemagen
>>>>> Testing javac
>>>>> Testing jar
>>>>> Testing jhsdb
>>>>> Testing jcmd
>>>>> Testing jstack
>>>>> Testing wsgen
>>>>> Testing jshell
>>>>> Testing serialver
>>>>> Testing jmap
>>>>> Testing javap
>>>>> Testing jps
>>>>> Testing jstatd
>>>>> Testing javadoc
>>>>> Testing tnameserv
>>>>> Testing jdb
>>>>> Testing jinfo
>>>>> Testing jdeps
>>>>> Testing xjc
>>>>> Testing rmid
>>>>> Testing jarsigner
>>>>> Testing idlj
>>>>> Testing rmic
>>>>> Testing appletviewer
>>>>> Testing pack200
>>>>> Testing javah
>>>>> Testing policytool
>>>>> Testing orbd
>>>>> testJVersionStrings passed
>>>>> === testInternalStrings ===
>>>>> testInternalStrings passed
>>>>> === testToolVersion ===
>>>>> Testing java
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>> java version "9-ea"
>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>> #> echo $?
>>>>> 0
>>>>> Testing javac
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>> javac 9-ea
>>>>> #> echo $?
>>>>> 0
>>>>> Testing jhsdb
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>    clhsdb           command line debugger
>>>>>    debugd           debug server
>>>>>    hsdb             ui debugger
>>>>>    jstack --help    to get more information
>>>>>    jmap   --help    to get more information
>>>>>    jinfo  --help    to get more information
>>>>>    jsnap  --help    to get more information
>>>>> #> echo $?
>>>>> 0
>>>>> Testing jshell
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>> jshell 9-ea
>>>>> #> echo $?
>>>>> 0
>>>>> Testing javap
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>> 9-ea
>>>>> #> echo $?
>>>>> 0
>>>>> Testing jdb
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>> #> echo $?
>>>>> 0
>>>>> Testing idlj
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>> #> echo $?
>>>>> 0
>>>>> Testing javah
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>> 
>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>> javac '-h' option; see the javac man page for more information.
>>>>> 
>>>>> javah version "9-ea"
>>>>> #> echo $?
>>>>> 0
>>>>> testToolVersion passed
>>>>> === testInternalStrings ===
>>>>> testDebugVersion passed
>>>>> All Version string comparisons: PASS
>>>>> ----------System.err:(1/15)----------
>>>>> 
>>>> 
>>> 
>> 
> 


From dmitry.fazunenko at oracle.com  Mon Dec 26 15:36:07 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Mon, 26 Dec 2016 18:36:07 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
	<6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
	<41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com>
Message-ID: <42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com>

Hi Andrey,

On 26.12.2016 17:53, Andrey Nazarov wrote:
> Hi,
>
> 2 minor comments.
> bug id  has not been added ?@bug 8171441?
I believe the purpose of the @bug tag is to list the issues the test 
verifies or the test is regression test for.
And it's not need to mention all the problem with the test itself here.
> javadoc should start with /** not  152 /*
I intentionally kept "/*", because it's not a javadoc comment, but just 
a comment to a method.
If we convert this to javadoc, we need to provide javadoc to other 
similar methods.
Of course this would be good, but I'm afraid this activity is rather a 
separate RFE.

Thanks,
Dima

>
>
> ?Andrey
>> On 26 Dec 2016, at 17:40, Stanislav Smirnov <stanislav.smirnov at oracle.com> wrote:
>>
>> Hi,
>>
>> thanks, looks good
>>
>> Best regards,
>> Stanislav Smirnov
>>
>>
>>
>>
>>
>>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> new version:  http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ <http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/>
>>>
>>> This comment now looks like:
>>> 152     /*
>>> 153      * Checks if the tools accept "-version" option (exit code is zero).
>>> 154      * The output of the tools run with "-version" is not verified.
>>> 155      */
>>>
>>> Thanks
>>> Dima
>>>
>>> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>>>> Hi,
>>>>
>>>> sorry, missed this strange comment during the first review.
>>>> 152     /*
>>>> 153      * this tests if the tool can take a version string and returns
>>>> 154      * a 0 exit code, it is not possible to validate the contents
>>>> 155      * of the -version output as they are inconsistent.
>>>> 156      */
>>>> 157     static String testToolVersion() {
>>>> It confuses me, can you please rephrase it?
>>>>
>>>> Best regards,
>>>> Stanislav Smirnov
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>
>>>>> Hi Stanislav,
>>>>>
>>>>> Thanks for looking.
>>>>> Updated webrev:
>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.01/>
>>>>>
>>>>> -- Dima
>>>>>
>>>>>
>>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>>>> Hi Dima,
>>>>>>
>>>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>>>> +            for (String s : tr.testOutput) {
>>>>>> +                System.out.println(s);
>>>>>> +            }
>>>>>> tr.testOutput.forEach(System.out::println)
>>>>>>
>>>>>>          for (String x : tr.testOutput) {
>>>>>>              alist.add(x.trim());
>>>>>>          }
>>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Stanislav Smirnov
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>>>    http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>>>    https://bugs.openjdk.java.net/browse/JDK-8171441 <https://bugs.openjdk.java.net/browse/JDK-8171441>
>>>>>>>
>>>>>>> The purpose of the change is to improve diagnostic.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>> PS: After the fix the failures will be reported as:
>>>>>>>
>>>>>>> ----------System.err:(13/956)----------
>>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>    at VersionCheck.main(VersionCheck.java:295)
>>>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>>>    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>>>
>>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>> JavaTest Message: shutting down test
>>>>>>>
>>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>
>>>>>>> PPS: The output of passed test now looks like:
>>>>>>>
>>>>>>> === testJVersionStrings ===
>>>>>>> Testing servertool
>>>>>>> Testing jstat
>>>>>>> Testing jmod
>>>>>>> Testing jjs
>>>>>>> Testing jimage
>>>>>>> Testing jlink
>>>>>>> Testing jrunscript
>>>>>>> Testing jdeprscan
>>>>>>> Testing jconsole
>>>>>>> Testing rmiregistry
>>>>>>> Testing keytool
>>>>>>> Testing schemagen
>>>>>>> Testing javac
>>>>>>> Testing jar
>>>>>>> Testing jhsdb
>>>>>>> Testing jcmd
>>>>>>> Testing jstack
>>>>>>> Testing wsgen
>>>>>>> Testing jshell
>>>>>>> Testing serialver
>>>>>>> Testing jmap
>>>>>>> Testing javap
>>>>>>> Testing jps
>>>>>>> Testing jstatd
>>>>>>> Testing javadoc
>>>>>>> Testing tnameserv
>>>>>>> Testing jdb
>>>>>>> Testing jinfo
>>>>>>> Testing jdeps
>>>>>>> Testing xjc
>>>>>>> Testing rmid
>>>>>>> Testing jarsigner
>>>>>>> Testing idlj
>>>>>>> Testing rmic
>>>>>>> Testing appletviewer
>>>>>>> Testing pack200
>>>>>>> Testing javah
>>>>>>> Testing policytool
>>>>>>> Testing orbd
>>>>>>> testJVersionStrings passed
>>>>>>> === testInternalStrings ===
>>>>>>> testInternalStrings passed
>>>>>>> === testToolVersion ===
>>>>>>> Testing java
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>>>> java version "9-ea"
>>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing javac
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>>>> javac 9-ea
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing jhsdb
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>>>    clhsdb           command line debugger
>>>>>>>    debugd           debug server
>>>>>>>    hsdb             ui debugger
>>>>>>>    jstack --help    to get more information
>>>>>>>    jmap   --help    to get more information
>>>>>>>    jinfo  --help    to get more information
>>>>>>>    jsnap  --help    to get more information
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing jshell
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>>>> jshell 9-ea
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing javap
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>>>> 9-ea
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing jdb
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing idlj
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> Testing javah
>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>>>>
>>>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>>>> javac '-h' option; see the javac man page for more information.
>>>>>>>
>>>>>>> javah version "9-ea"
>>>>>>> #> echo $?
>>>>>>> 0
>>>>>>> testToolVersion passed
>>>>>>> === testInternalStrings ===
>>>>>>> testDebugVersion passed
>>>>>>> All Version string comparisons: PASS
>>>>>>> ----------System.err:(1/15)----------
>>>>>>>


From dmitry.fazunenko at oracle.com  Mon Dec 26 15:40:52 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Mon, 26 Dec 2016 18:40:52 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
	<6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
Message-ID: <efc2f480-cbc4-05cf-c2f3-2b9deb03557a@oracle.com>

Thank you, Stanislav.

-- Dima

On 26.12.2016 17:40, Stanislav Smirnov wrote:
> Hi,
>
> thanks, looks good
>
> Best regards,
> Stanislav Smirnov
>
>
>
>
>
>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko 
>> <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>
>> Hi,
>>
>> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/
>>
>> This comment now looks like:
>>   152     /*
>>   153      * Checks if the tools accept "-version" option (exit code is zero).
>>   154      * The output of the tools run with "-version" is not verified.
>>   155      */
>>
>> Thanks
>> Dima
>>
>> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>>> Hi,
>>>
>>> sorry, missed this strange comment during the first review.
>>>   152     /*
>>>   153      * this tests if the tool can take a version string and returns
>>>   154      * a 0 exit code, it is not possible to validate the contents
>>>   155      * of the -version output as they are inconsistent.
>>>   156      */
>>>   157     static String testToolVersion() {
>>> It confuses me, can you please rephrase it?
>>>
>>> Best regards,
>>> Stanislav Smirnov
>>>
>>>
>>>
>>>
>>>
>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko 
>>>> <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> 
>>>> wrote:
>>>>
>>>> Hi Stanislav,
>>>>
>>>> Thanks for looking.
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/
>>>>
>>>> -- Dima
>>>>
>>>>
>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>>> Hi Dima,
>>>>>
>>>>> changes look good, I will only suggest using lambda?s in couple of 
>>>>> iterations
>>>>> +            for (String s : tr.testOutput) {
>>>>> +                System.out.println(s);
>>>>> +            }
>>>>> tr.testOutput.forEach(System.out::println)
>>>>>
>>>>>           for (String x : tr.testOutput) {
>>>>>               alist.add(x.trim());
>>>>>           }
>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Stanislav Smirnov
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko 
>>>>>> <dmitry.fazunenko at oracle.com 
>>>>>> <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ 
>>>>>> <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441
>>>>>>
>>>>>> The purpose of the change is to improve diagnostic.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> PS: After the fix the failures will be reported as:
>>>>>>
>>>>>> ----------System.err:(13/956)----------
>>>>>> java.lang.AssertionError: VersionCheck failed: 
>>>>>> testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>    at VersionCheck.main(VersionCheck.java:295)
>>>>>>    at 
>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>>>>>> Method)
>>>>>>    at 
>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>    at 
>>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>>    at 
>>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>>
>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: 
>>>>>> VersionCheck failed: testJVersionStrings: [java]; 
>>>>>> testToolVersion: [jar];
>>>>>> JavaTest Message: shutting down test
>>>>>>
>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: 
>>>>>> VersionCheck failed: testJVersionStrings: [java]; 
>>>>>> testToolVersion: [jar];
>>>>>>
>>>>>> PPS: The output of passed test now looks like:
>>>>>>
>>>>>> === testJVersionStrings ===
>>>>>> Testing servertool
>>>>>> Testing jstat
>>>>>> Testing jmod
>>>>>> Testing jjs
>>>>>> Testing jimage
>>>>>> Testing jlink
>>>>>> Testing jrunscript
>>>>>> Testing jdeprscan
>>>>>> Testing jconsole
>>>>>> Testing rmiregistry
>>>>>> Testing keytool
>>>>>> Testing schemagen
>>>>>> Testing javac
>>>>>> Testing jar
>>>>>> Testing jhsdb
>>>>>> Testing jcmd
>>>>>> Testing jstack
>>>>>> Testing wsgen
>>>>>> Testing jshell
>>>>>> Testing serialver
>>>>>> Testing jmap
>>>>>> Testing javap
>>>>>> Testing jps
>>>>>> Testing jstatd
>>>>>> Testing javadoc
>>>>>> Testing tnameserv
>>>>>> Testing jdb
>>>>>> Testing jinfo
>>>>>> Testing jdeps
>>>>>> Testing xjc
>>>>>> Testing rmid
>>>>>> Testing jarsigner
>>>>>> Testing idlj
>>>>>> Testing rmic
>>>>>> Testing appletviewer
>>>>>> Testing pack200
>>>>>> Testing javah
>>>>>> Testing policytool
>>>>>> Testing orbd
>>>>>> testJVersionStrings passed
>>>>>> === testInternalStrings ===
>>>>>> testInternalStrings passed
>>>>>> === testToolVersion ===
>>>>>> Testing java
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> 
>>>>>> -version
>>>>>> java version "9-ea"
>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javac
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> 
>>>>>> -version
>>>>>> javac 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jhsdb
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> 
>>>>>> -version
>>>>>>    clhsdb           command line debugger
>>>>>>    debugd           debug server
>>>>>>    hsdb             ui debugger
>>>>>>    jstack --help    to get more information
>>>>>>    jmap   --help    to get more information
>>>>>>    jinfo  --help    to get more information
>>>>>>    jsnap  --help    to get more information
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jshell
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> 
>>>>>> -version
>>>>>> jshell 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javap
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> 
>>>>>> -version
>>>>>> 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jdb
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> 
>>>>>> -version
>>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing idlj
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> 
>>>>>> -version
>>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javah
>>>>>> #> 
>>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah 
>>>>>> <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> 
>>>>>> -version
>>>>>>
>>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>>> javac '-h' option; see the javac man page for more information.
>>>>>>
>>>>>> javah version "9-ea"
>>>>>> #> echo $?
>>>>>> 0
>>>>>> testToolVersion passed
>>>>>> === testInternalStrings ===
>>>>>> testDebugVersion passed
>>>>>> All Version string comparisons: PASS
>>>>>> ----------System.err:(1/15)----------
>>>>>>
>>>>>
>>>>
>>>
>>
>


From igor.ignatyev at oracle.com  Mon Dec 26 15:42:24 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 26 Dec 2016 18:42:24 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
Message-ID: <9BD01FBA-2EF2-462A-8197-46D57B996499@oracle.com>

Hi Dima,

the fix looks good to me,

Cheers,
? Igor

> On Dec 23, 2016, at 7:13 PM, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
> 
> Hi,
> 
> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/
> 
> This comment now looks like:
> 
> 152     /*
> 153      * Checks if the tools accept "-version" option (exit code is zero).
> 154      * The output of the tools run with "-version" is not verified.
> 155      */
> 
> 
> Thanks
> Dima
> 
> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>> Hi,
>> 
>> sorry, missed this strange comment during the first review.
>>  152     /*
>>  153      * this tests if the tool can take a version string and returns
>>  154      * a 0 exit code, it is not possible to validate the contents
>>  155      * of the -version output as they are inconsistent.
>>  156      */
>>  157     static String testToolVersion() {
>> It confuses me, can you please rephrase it?
>> 
>> Best regards,
>> Stanislav Smirnov
>> 
>> 
>> 
>> 
>> 
>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>> 
>>> Hi Stanislav,
>>> 
>>> Thanks for looking.
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/
>>> 
>>> -- Dima
>>> 
>>> 
>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>> Hi Dima,
>>>> 
>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>> +            for (String s : tr.testOutput) {
>>>> +                System.out.println(s);
>>>> +            }
>>>> tr.testOutput.forEach(System.out::println)
>>>> 
>>>>          for (String x : tr.testOutput) {
>>>>              alist.add(x.trim());
>>>>          }
>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>> 
>>>> 
>>>> Best regards,
>>>> Stanislav Smirnov
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I'm looking for reviews of a relatively simple test change:
>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441
>>>>> 
>>>>> The purpose of the change is to improve diagnostic.
>>>>> 
>>>>> Thanks,
>>>>> Dima
>>>>> 
>>>>> PS: After the fix the failures will be reported as:
>>>>> 
>>>>> ----------System.err:(13/956)----------
>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>   at VersionCheck.main(VersionCheck.java:295)
>>>>>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>   at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>   at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>   at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>   at java.base/java.lang.Thread.run(Thread.java:844)
>>>>> 
>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>> JavaTest Message: shutting down test
>>>>> 
>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>> 
>>>>> PPS: The output of passed test now looks like:
>>>>> 
>>>>> === testJVersionStrings ===
>>>>> Testing servertool
>>>>> Testing jstat
>>>>> Testing jmod
>>>>> Testing jjs
>>>>> Testing jimage
>>>>> Testing jlink
>>>>> Testing jrunscript
>>>>> Testing jdeprscan
>>>>> Testing jconsole
>>>>> Testing rmiregistry
>>>>> Testing keytool
>>>>> Testing schemagen
>>>>> Testing javac
>>>>> Testing jar
>>>>> Testing jhsdb
>>>>> Testing jcmd
>>>>> Testing jstack
>>>>> Testing wsgen
>>>>> Testing jshell
>>>>> Testing serialver
>>>>> Testing jmap
>>>>> Testing javap
>>>>> Testing jps
>>>>> Testing jstatd
>>>>> Testing javadoc
>>>>> Testing tnameserv
>>>>> Testing jdb
>>>>> Testing jinfo
>>>>> Testing jdeps
>>>>> Testing xjc
>>>>> Testing rmid
>>>>> Testing jarsigner
>>>>> Testing idlj
>>>>> Testing rmic
>>>>> Testing appletviewer
>>>>> Testing pack200
>>>>> Testing javah
>>>>> Testing policytool
>>>>> Testing orbd
>>>>> testJVersionStrings passed
>>>>> === testInternalStrings ===
>>>>> testInternalStrings passed
>>>>> === testToolVersion ===
>>>>> Testing java
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>> java version "9-ea"
>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>> #> echo $?
>>>>> 0
>>>>> Testing javac
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>> javac 9-ea
>>>>> #> echo $?
>>>>> 0
>>>>> Testing jhsdb
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>   clhsdb           command line debugger
>>>>>   debugd           debug server
>>>>>   hsdb             ui debugger
>>>>>   jstack --help    to get more information
>>>>>   jmap   --help    to get more information
>>>>>   jinfo  --help    to get more information
>>>>>   jsnap  --help    to get more information
>>>>> #> echo $?
>>>>> 0
>>>>> Testing jshell
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>> jshell 9-ea
>>>>> #> echo $?
>>>>> 0
>>>>> Testing javap
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>> 9-ea
>>>>> #> echo $?
>>>>> 0
>>>>> Testing jdb
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>> #> echo $?
>>>>> 0
>>>>> Testing idlj
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>> #> echo $?
>>>>> 0
>>>>> Testing javah
>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>> 
>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>> javac '-h' option; see the javac man page for more information.
>>>>> 
>>>>> javah version "9-ea"
>>>>> #> echo $?
>>>>> 0
>>>>> testToolVersion passed
>>>>> === testInternalStrings ===
>>>>> testDebugVersion passed
>>>>> All Version string comparisons: PASS
>>>>> ----------System.err:(1/15)----------
>>>>> 
>>>> 
>>> 
>> 
> 


From dmitry.fazunenko at oracle.com  Mon Dec 26 16:00:44 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Mon, 26 Dec 2016 19:00:44 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <651385B8-25FC-4036-8E0B-1C015367F863@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
	<6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
	<41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com>
	<42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com>
	<651385B8-25FC-4036-8E0B-1C015367F863@oracle.com>
Message-ID: <9d31fd1c-b60f-0afc-af32-4f4b5bae2ef2@oracle.com>



On 26.12.2016 18:45, Andrey Nazarov wrote:
>> On 26 Dec 2016, at 18:36, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>>
>> Hi Andrey,
>>
>> On 26.12.2016 17:53, Andrey Nazarov wrote:
>>> Hi,
>>>
>>> 2 minor comments.
>>> bug id  has not been added ?@bug 8171441?
>> I believe the purpose of the @bug tag is to list the issues the test verifies or the test is regression test for.
>> And it's not need to mention all the problem with the test itself here.
> My understanding is that @bug tag is used to track the reasons for the test modifications and creation. But I haven?t seen any documentation for it.

It's not needed to list CRs related to the test modification, they could 
be extracted from the history.
Much more useful is to list the regressions caught by the test.

-- Dima


>>> javadoc should start with /** not  152 /*
>> I intentionally kept "/*", because it's not a javadoc comment, but just a comment to a method.
>> If we convert this to javadoc, we need to provide javadoc to other similar methods.
>> Of course this would be good, but I'm afraid this activity is rather a separate RFE.
> Ok.
>> Thanks,
>> Dima
>>
>>>
>>> ?Andrey
>>>> On 26 Dec 2016, at 17:40, Stanislav Smirnov <stanislav.smirnov at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> thanks, looks good
>>>>
>>>> Best regards,
>>>> Stanislav Smirnov
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> new version:  http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ <http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/>
>>>>>
>>>>> This comment now looks like:
>>>>> 152     /*
>>>>> 153      * Checks if the tools accept "-version" option (exit code is zero).
>>>>> 154      * The output of the tools run with "-version" is not verified.
>>>>> 155      */
>>>>>
>>>>> Thanks
>>>>> Dima
>>>>>
>>>>> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> sorry, missed this strange comment during the first review.
>>>>>> 152     /*
>>>>>> 153      * this tests if the tool can take a version string and returns
>>>>>> 154      * a 0 exit code, it is not possible to validate the contents
>>>>>> 155      * of the -version output as they are inconsistent.
>>>>>> 156      */
>>>>>> 157     static String testToolVersion() {
>>>>>> It confuses me, can you please rephrase it?
>>>>>>
>>>>>> Best regards,
>>>>>> Stanislav Smirnov
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hi Stanislav,
>>>>>>>
>>>>>>> Thanks for looking.
>>>>>>> Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.01/>
>>>>>>>
>>>>>>> -- Dima
>>>>>>>
>>>>>>>
>>>>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>>>>>> Hi Dima,
>>>>>>>>
>>>>>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>>>>>> +            for (String s : tr.testOutput) {
>>>>>>>> +                System.out.println(s);
>>>>>>>> +            }
>>>>>>>> tr.testOutput.forEach(System.out::println)
>>>>>>>>
>>>>>>>>          for (String x : tr.testOutput) {
>>>>>>>>              alist.add(x.trim());
>>>>>>>>          }
>>>>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Stanislav Smirnov
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>>>>>    http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>>>>>    https://bugs.openjdk.java.net/browse/JDK-8171441 <https://bugs.openjdk.java.net/browse/JDK-8171441>
>>>>>>>>>
>>>>>>>>> The purpose of the change is to improve diagnostic.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dima
>>>>>>>>>
>>>>>>>>> PS: After the fix the failures will be reported as:
>>>>>>>>>
>>>>>>>>> ----------System.err:(13/956)----------
>>>>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>>>    at VersionCheck.main(VersionCheck.java:295)
>>>>>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>>    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>>>>>    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>>>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>>>>>
>>>>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>>> JavaTest Message: shutting down test
>>>>>>>>>
>>>>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>>>
>>>>>>>>> PPS: The output of passed test now looks like:
>>>>>>>>>
>>>>>>>>> === testJVersionStrings ===
>>>>>>>>> Testing servertool
>>>>>>>>> Testing jstat
>>>>>>>>> Testing jmod
>>>>>>>>> Testing jjs
>>>>>>>>> Testing jimage
>>>>>>>>> Testing jlink
>>>>>>>>> Testing jrunscript
>>>>>>>>> Testing jdeprscan
>>>>>>>>> Testing jconsole
>>>>>>>>> Testing rmiregistry
>>>>>>>>> Testing keytool
>>>>>>>>> Testing schemagen
>>>>>>>>> Testing javac
>>>>>>>>> Testing jar
>>>>>>>>> Testing jhsdb
>>>>>>>>> Testing jcmd
>>>>>>>>> Testing jstack
>>>>>>>>> Testing wsgen
>>>>>>>>> Testing jshell
>>>>>>>>> Testing serialver
>>>>>>>>> Testing jmap
>>>>>>>>> Testing javap
>>>>>>>>> Testing jps
>>>>>>>>> Testing jstatd
>>>>>>>>> Testing javadoc
>>>>>>>>> Testing tnameserv
>>>>>>>>> Testing jdb
>>>>>>>>> Testing jinfo
>>>>>>>>> Testing jdeps
>>>>>>>>> Testing xjc
>>>>>>>>> Testing rmid
>>>>>>>>> Testing jarsigner
>>>>>>>>> Testing idlj
>>>>>>>>> Testing rmic
>>>>>>>>> Testing appletviewer
>>>>>>>>> Testing pack200
>>>>>>>>> Testing javah
>>>>>>>>> Testing policytool
>>>>>>>>> Testing orbd
>>>>>>>>> testJVersionStrings passed
>>>>>>>>> === testInternalStrings ===
>>>>>>>>> testInternalStrings passed
>>>>>>>>> === testToolVersion ===
>>>>>>>>> Testing java
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>>>>>> java version "9-ea"
>>>>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing javac
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>>>>>> javac 9-ea
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing jhsdb
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>>>>>    clhsdb           command line debugger
>>>>>>>>>    debugd           debug server
>>>>>>>>>    hsdb             ui debugger
>>>>>>>>>    jstack --help    to get more information
>>>>>>>>>    jmap   --help    to get more information
>>>>>>>>>    jinfo  --help    to get more information
>>>>>>>>>    jsnap  --help    to get more information
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing jshell
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>>>>>> jshell 9-ea
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing javap
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>>>>>> 9-ea
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing jdb
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing idlj
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> Testing javah
>>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>>>>>>
>>>>>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>>>>>> javac '-h' option; see the javac man page for more information.
>>>>>>>>>
>>>>>>>>> javah version "9-ea"
>>>>>>>>> #> echo $?
>>>>>>>>> 0
>>>>>>>>> testToolVersion passed
>>>>>>>>> === testInternalStrings ===
>>>>>>>>> testDebugVersion passed
>>>>>>>>> All Version string comparisons: PASS
>>>>>>>>> ----------System.err:(1/15)----------
>>>>>>>>>


From dmitry.fazunenko at oracle.com  Mon Dec 26 17:25:54 2016
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko)
Date: Mon, 26 Dec 2016 20:25:54 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <9BD01FBA-2EF2-462A-8197-46D57B996499@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
	<9BD01FBA-2EF2-462A-8197-46D57B996499@oracle.com>
Message-ID: <35f4427f-e354-04e0-ef35-e102b4b9f8bf@oracle.com>

Hi Igor,

Thanks for the review!

-- dima

On 26.12.2016 18:42, Igor Ignatyev wrote:
> Hi Dima,
>
> the fix looks good to me,
>
> Cheers,
> ? Igor
>
>> On Dec 23, 2016, at 7:13 PM, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>>
>> Hi,
>>
>> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/
>>
>> This comment now looks like:
>>
>> 152     /*
>> 153      * Checks if the tools accept "-version" option (exit code is zero).
>> 154      * The output of the tools run with "-version" is not verified.
>> 155      */
>>
>>
>> Thanks
>> Dima
>>
>> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>>> Hi,
>>>
>>> sorry, missed this strange comment during the first review.
>>>   152     /*
>>>   153      * this tests if the tool can take a version string and returns
>>>   154      * a 0 exit code, it is not possible to validate the contents
>>>   155      * of the -version output as they are inconsistent.
>>>   156      */
>>>   157     static String testToolVersion() {
>>> It confuses me, can you please rephrase it?
>>>
>>> Best regards,
>>> Stanislav Smirnov
>>>
>>>
>>>
>>>
>>>
>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>
>>>> Hi Stanislav,
>>>>
>>>> Thanks for looking.
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/
>>>>
>>>> -- Dima
>>>>
>>>>
>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>>> Hi Dima,
>>>>>
>>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>>> +            for (String s : tr.testOutput) {
>>>>> +                System.out.println(s);
>>>>> +            }
>>>>> tr.testOutput.forEach(System.out::println)
>>>>>
>>>>>           for (String x : tr.testOutput) {
>>>>>               alist.add(x.trim());
>>>>>           }
>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Stanislav Smirnov
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441
>>>>>>
>>>>>> The purpose of the change is to improve diagnostic.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> PS: After the fix the failures will be reported as:
>>>>>>
>>>>>> ----------System.err:(13/956)----------
>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>    at VersionCheck.main(VersionCheck.java:295)
>>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>    at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>>    at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>>    at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>>
>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>> JavaTest Message: shutting down test
>>>>>>
>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>
>>>>>> PPS: The output of passed test now looks like:
>>>>>>
>>>>>> === testJVersionStrings ===
>>>>>> Testing servertool
>>>>>> Testing jstat
>>>>>> Testing jmod
>>>>>> Testing jjs
>>>>>> Testing jimage
>>>>>> Testing jlink
>>>>>> Testing jrunscript
>>>>>> Testing jdeprscan
>>>>>> Testing jconsole
>>>>>> Testing rmiregistry
>>>>>> Testing keytool
>>>>>> Testing schemagen
>>>>>> Testing javac
>>>>>> Testing jar
>>>>>> Testing jhsdb
>>>>>> Testing jcmd
>>>>>> Testing jstack
>>>>>> Testing wsgen
>>>>>> Testing jshell
>>>>>> Testing serialver
>>>>>> Testing jmap
>>>>>> Testing javap
>>>>>> Testing jps
>>>>>> Testing jstatd
>>>>>> Testing javadoc
>>>>>> Testing tnameserv
>>>>>> Testing jdb
>>>>>> Testing jinfo
>>>>>> Testing jdeps
>>>>>> Testing xjc
>>>>>> Testing rmid
>>>>>> Testing jarsigner
>>>>>> Testing idlj
>>>>>> Testing rmic
>>>>>> Testing appletviewer
>>>>>> Testing pack200
>>>>>> Testing javah
>>>>>> Testing policytool
>>>>>> Testing orbd
>>>>>> testJVersionStrings passed
>>>>>> === testInternalStrings ===
>>>>>> testInternalStrings passed
>>>>>> === testToolVersion ===
>>>>>> Testing java
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>>> java version "9-ea"
>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javac
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>>> javac 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jhsdb
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>>    clhsdb           command line debugger
>>>>>>    debugd           debug server
>>>>>>    hsdb             ui debugger
>>>>>>    jstack --help    to get more information
>>>>>>    jmap   --help    to get more information
>>>>>>    jinfo  --help    to get more information
>>>>>>    jsnap  --help    to get more information
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jshell
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>>> jshell 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javap
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>>> 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jdb
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing idlj
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javah
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>>>
>>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>>> javac '-h' option; see the javac man page for more information.
>>>>>>
>>>>>> javah version "9-ea"
>>>>>> #> echo $?
>>>>>> 0
>>>>>> testToolVersion passed
>>>>>> === testInternalStrings ===
>>>>>> testDebugVersion passed
>>>>>> All Version string comparisons: PASS
>>>>>> ----------System.err:(1/15)----------
>>>>>>


From igor.ignatyev at oracle.com  Tue Dec 27 13:01:52 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 27 Dec 2016 16:01:52 +0300
Subject: RFR(S): 8171090: Convert VMStruct_test to GTest
In-Reply-To: <f3d8548a-d25b-9256-4214-3c5fa36ff1f9@oracle.com>
References: <f3d8548a-d25b-9256-4214-3c5fa36ff1f9@oracle.com>
Message-ID: <7D2CBE3E-AEDA-4710-88F3-8A9E61D3A420@oracle.com>

Hi Kirill,

looks good to me. thanks for fixing that.

Cheers,
? Igor
> On Dec 12, 2016, at 4:27 PM, Kirill Zhaldybin <kirill.zhaldybin at oracle.com> wrote:
> 
> Dear all,
> 
> Could you please review this fix for 8171090?
> 
> I added accessors to get arrays' lengths since they were defined in cpp file and separated the test into to two scenarios.
> 
> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171090/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8171090
> 
> Thank you.
> 
> Regards, Kirill


From kirill.zhaldybin at oracle.com  Tue Dec 27 13:07:31 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 27 Dec 2016 16:07:31 +0300
Subject: RFR(S): 8171090: Convert VMStruct_test to GTest
In-Reply-To: <7D2CBE3E-AEDA-4710-88F3-8A9E61D3A420@oracle.com>
References: <f3d8548a-d25b-9256-4214-3c5fa36ff1f9@oracle.com>
	<7D2CBE3E-AEDA-4710-88F3-8A9E61D3A420@oracle.com>
Message-ID: <35710afd-d144-22a9-54be-61e0aa8fac9d@oracle.com>

Igor,

Thank you for review!

Regards, Kirill

On 27.12.2016 16:01, Igor Ignatyev wrote:
> Hi Kirill,
>
> looks good to me. thanks for fixing that.
>
> Cheers,
> ? Igor
>> On Dec 12, 2016, at 4:27 PM, Kirill Zhaldybin <kirill.zhaldybin at oracle.com> wrote:
>>
>> Dear all,
>>
>> Could you please review this fix for 8171090?
>>
>> I added accessors to get arrays' lengths since they were defined in cpp file and separated the test into to two scenarios.
>>
>> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171090/webrev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8171090
>>
>> Thank you.
>>
>> Regards, Kirill


From kirill.zhaldybin at oracle.com  Tue Dec 27 14:41:50 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 27 Dec 2016 17:41:50 +0300
Subject: RFR(XS): 8171097: Convert TestReservedSpace_test to Gtest
In-Reply-To: <281bd401-30a9-9142-bfc2-fb5cf11d52bd@oracle.com>
References: <281bd401-30a9-9142-bfc2-fb5cf11d52bd@oracle.com>
Message-ID: <400e69d2-f89c-9bbc-f23a-7594f4999526@oracle.com>

After getting offline comments I updated webrev: 
http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171097/webrev.01/

Changes:
1. Deleted "return;" which was not needed
2. Changed two ASSERTs to EXPECTs

Thank you.

Regards, KIrill

On 12.12.2016 19:31, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please review this fix for 8171097?
>
> WebRev: 
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171097/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8171097
>
> Thank you.
>
> Regards, Kirill


From igor.ignatyev at oracle.com  Tue Dec 27 14:49:49 2016
From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=)
Date: Tue, 27 Dec 2016 17:49:49 +0300
Subject: =?utf-8?B?UmU6IFJGUihYUyk6IDgxNzEwOTc6IENvbnZlcnQgVGVzdFJlc2VydmVkU3BhY2Vf?=
	=?utf-8?B?dGVzdCB0byBHdGVzdA==?=
Message-ID: <201612271449.uBREnnLb023538@userv0122.oracle.com>

Hi Kirill,

Looks good to me.

-- II

----- Reply message -----
From: "Kirill Zhaldybin" <kirill.zhaldybin at oracle.com>
To: "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.java.net>, "hotspot-dev developers" <hotspot-dev at openjdk.java.net>
Subject: RFR(XS): 8171097: Convert TestReservedSpace_test to Gtest
Date: Tue, Dec 27, 2016 17:41

After getting offline comments I updated webrev: 
http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171097/webrev.01/

Changes:
1. Deleted "return;" which was not needed
2. Changed two ASSERTs to EXPECTs

Thank you.

Regards, KIrill

On 12.12.2016 19:31, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please review this fix for 8171097?
>
> WebRev: 
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171097/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8171097
>
> Thank you.
>
> Regards, Kirill

From kirill.zhaldybin at oracle.com  Tue Dec 27 15:32:10 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 27 Dec 2016 18:32:10 +0300
Subject: RFR(XS): 8171097: Convert TestReservedSpace_test to Gtest
Message-ID: <c00cc2bd-0f75-8fd6-4f9e-cd38c2373759@oracle.com>

Igor,

Thank you for review!

Regards, Kirill

On 27.12.2016 17:49, igor.ignatyev at oracle.com wrote:
> Hi Kirill,
>
> Looks good to me.
>
> -- II
>
> ----- Reply message -----
> From: "Kirill Zhaldybin" <kirill.zhaldybin at oracle.com>
> To: "hotspot-runtime-dev at openjdk.java.net" 
> <hotspot-runtime-dev at openjdk.java.net>, "hotspot-dev developers" 
> <hotspot-dev at openjdk.java.net>
> Subject: RFR(XS): 8171097: Convert TestReservedSpace_test to Gtest
> Date: Tue, Dec 27, 2016 17:41
>
> After getting offline comments I updated webrev:
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171097/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ekzhaldyb/webrevs/JDK-8171097/webrev.01/>
>
> Changes:
> 1. Deleted "return;" which was not needed
> 2. Changed two ASSERTs to EXPECTs
>
> Thank you.
>
> Regards, KIrill
>
> On 12.12.2016 19:31, Kirill Zhaldybin wrote:
> > Dear all,
> >
> > Could you please review this fix for 8171097?
> >
> > WebRev:
> >http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171097/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ekzhaldyb/webrevs/JDK-8171097/webrev.00/>
> > CR:https://bugs.openjdk.java.net/browse/JDK-8171097
> >
> > Thank you.
> >
> > Regards, Kirill
>


From igor.ignatyev at oracle.com  Wed Dec 28 12:27:41 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 28 Dec 2016 15:27:41 +0300
Subject: RFR(XXS) : 8172094 : 8171433 changes in generated-configure should be
	restored
Message-ID: <FE4E319A-E8FC-4A88-983A-7EE18E442AAB@oracle.com>

Hi all,

could you please review this tiny fix which restores 8171433 changes in generated-configure file?

the changes were lost during latest hs<->dev merge. I?ve regenerated them by runing common/autoconf/autogen.sh.

JBS: https://bugs.openjdk.java.net/browse/JDK-8172094
webrev: http://cr.openjdk.java.net/~iignatyev/8172094/webrev.00/

Thanks,
? Igor 

From erik.joelsson at oracle.com  Wed Dec 28 13:03:41 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 28 Dec 2016 14:03:41 +0100
Subject: RFR(XXS) : 8172094 : 8171433 changes in generated-configure
	should be restored
In-Reply-To: <FE4E319A-E8FC-4A88-983A-7EE18E442AAB@oracle.com>
References: <FE4E319A-E8FC-4A88-983A-7EE18E442AAB@oracle.com>
Message-ID: <1f6cfbf8-f1d9-e9e9-8325-3e5315b00cec@oracle.com>

Looks good.

/Erik


On 2016-12-28 13:27, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this tiny fix which restores 8171433 changes in generated-configure file?
>
> the changes were lost during latest hs<->dev merge. I?ve regenerated them by runing common/autoconf/autogen.sh.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8172094
> webrev: http://cr.openjdk.java.net/~iignatyev/8172094/webrev.00/
>
> Thanks,
> ? Igor


From kirill.zhaldybin at oracle.com  Wed Dec 28 14:41:03 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 28 Dec 2016 17:41:03 +0300
Subject: RFR(XXS) : 8172094 : 8171433 changes in generated-configure
	should be restored
In-Reply-To: <FE4E319A-E8FC-4A88-983A-7EE18E442AAB@oracle.com>
References: <FE4E319A-E8FC-4A88-983A-7EE18E442AAB@oracle.com>
Message-ID: <2b7da373-b5ef-bdda-ab96-5d6b0a608550@oracle.com>

Igor,

Looks good to me.

Regards, Kirill

On 28.12.2016 15:27, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this tiny fix which restores 8171433 changes in generated-configure file?
>
> the changes were lost during latest hs<->dev merge. I?ve regenerated them by runing common/autoconf/autogen.sh.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8172094
> webrev: http://cr.openjdk.java.net/~iignatyev/8172094/webrev.00/
>
> Thanks,
> ? Igor


From kirill.zhaldybin at oracle.com  Wed Dec 28 16:26:22 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 28 Dec 2016 19:26:22 +0300
Subject: RFR(S): 8172098: A lot of gtests uses TEST instead of TEST_VM
Message-ID: <d1db1639-a0b5-ea3b-e289-054222d225c1@oracle.com>

Dear all,

Could you please review this fix for 8172098?
I changed TEST to TEST_VM to avoid tests crashes, mostly in Log tests 
and in WorkerDataArray tests.

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

Thank you.

Regards, Kirill

From igor.ignatyev at oracle.com  Wed Dec 28 16:41:32 2016
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 28 Dec 2016 19:41:32 +0300
Subject: RFR(S): 8172098: A lot of gtests uses TEST instead of TEST_VM
In-Reply-To: <d1db1639-a0b5-ea3b-e289-054222d225c1@oracle.com>
References: <d1db1639-a0b5-ea3b-e289-054222d225c1@oracle.com>
Message-ID: <038E0D33-1141-4361-A361-56A183E0CCB5@oracle.com>

Hi Kirill,

looks good to me.

Thanks,
? Igor

> On Dec 28, 2016, at 7:26 PM, Kirill Zhaldybin <kirill.zhaldybin at oracle.com> wrote:
> 
> Dear all,
> 
> Could you please review this fix for 8172098?
> I changed TEST to TEST_VM to avoid tests crashes, mostly in Log tests and in WorkerDataArray tests.
> 
> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8172098/webrev.00/
> CR: https://bugs.openjdk.java.net/browse/JDK-8172098
> 
> Thank you.
> 
> Regards, Kirill


From kirill.zhaldybin at oracle.com  Wed Dec 28 16:48:44 2016
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Wed, 28 Dec 2016 19:48:44 +0300
Subject: RFR(S): 8172098: A lot of gtests uses TEST instead of TEST_VM
In-Reply-To: <038E0D33-1141-4361-A361-56A183E0CCB5@oracle.com>
References: <d1db1639-a0b5-ea3b-e289-054222d225c1@oracle.com>
	<038E0D33-1141-4361-A361-56A183E0CCB5@oracle.com>
Message-ID: <ef1077cb-97f4-a944-336a-fb6700c59182@oracle.com>

Igor,

Thank you for review!

Regards, Kirill

On 28.12.2016 19:41, Igor Ignatyev wrote:
> Hi Kirill,
>
> looks good to me.
>
> Thanks,
> ? Igor
>
>> On Dec 28, 2016, at 7:26 PM, Kirill Zhaldybin <kirill.zhaldybin at oracle.com> wrote:
>>
>> Dear all,
>>
>> Could you please review this fix for 8172098?
>> I changed TEST to TEST_VM to avoid tests crashes, mostly in Log tests and in WorkerDataArray tests.
>>
>> WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8172098/webrev.00/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8172098
>>
>> Thank you.
>>
>> Regards, Kirill


From gromero at linux.vnet.ibm.com  Fri Dec 30 13:59:37 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Fri, 30 Dec 2016 11:59:37 -0200
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <58530522.3030102@linux.vnet.ibm.com>
References: <58530522.3030102@linux.vnet.ibm.com>
Message-ID: <58666849.1020700@linux.vnet.ibm.com>

Hi,

That change is already reviewed by Martin on the ppc-aix-port ML [1], but since
I understand that a formal review has to be submitted to the hs ML I resent it.

Is any thing missing on my side?

Thank you.


Regards,
Gustavo

[1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html

On 15-12-2016 19:03, Gustavo Romero wrote:
> Hi,
> 
> Could the following change be reviewed please?
> 
> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
> bug   : https://bugs.openjdk.java.net/browse/JDK-8171266
> 
> Thank you.
> 
> 
> Regards,
> Gustavo
> 


From andrey.x.nazarov at oracle.com  Mon Dec 26 14:53:26 2016
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Mon, 26 Dec 2016 17:53:26 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
	<6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
Message-ID: <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com>

Hi,

2 minor comments.
bug id  has not been added ?@bug 8171441?
javadoc should start with /** not  152 /*


?Andrey
> On 26 Dec 2016, at 17:40, Stanislav Smirnov <stanislav.smirnov at oracle.com> wrote:
> 
> Hi,
> 
> thanks, looks good
> 
> Best regards,
> Stanislav Smirnov
> 
> 
> 
> 
> 
>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>> 
>> Hi,
>> 
>> new version:  http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ <http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/>
>> 
>> This comment now looks like:
>> 152     /*
>> 153      * Checks if the tools accept "-version" option (exit code is zero).
>> 154      * The output of the tools run with "-version" is not verified.
>> 155      */
>> 
>> Thanks
>> Dima
>> 
>> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>>> Hi,
>>> 
>>> sorry, missed this strange comment during the first review.
>>> 152     /*
>>> 153      * this tests if the tool can take a version string and returns
>>> 154      * a 0 exit code, it is not possible to validate the contents
>>> 155      * of the -version output as they are inconsistent.
>>> 156      */
>>> 157     static String testToolVersion() {
>>> It confuses me, can you please rephrase it?
>>> 
>>> Best regards,
>>> Stanislav Smirnov
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>> 
>>>> Hi Stanislav,
>>>> 
>>>> Thanks for looking.
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.01/>
>>>> 
>>>> -- Dima
>>>> 
>>>> 
>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>>> Hi Dima,
>>>>> 
>>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>>> +            for (String s : tr.testOutput) {
>>>>> +                System.out.println(s);
>>>>> +            }
>>>>> tr.testOutput.forEach(System.out::println)
>>>>> 
>>>>>         for (String x : tr.testOutput) {
>>>>>             alist.add(x.trim());
>>>>>         }
>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Stanislav Smirnov
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>>   http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>>   https://bugs.openjdk.java.net/browse/JDK-8171441 <https://bugs.openjdk.java.net/browse/JDK-8171441>
>>>>>> 
>>>>>> The purpose of the change is to improve diagnostic.
>>>>>> 
>>>>>> Thanks,
>>>>>> Dima
>>>>>> 
>>>>>> PS: After the fix the failures will be reported as:
>>>>>> 
>>>>>> ----------System.err:(13/956)----------
>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>   at VersionCheck.main(VersionCheck.java:295)
>>>>>>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>   at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>   at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>>   at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>>   at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>> 
>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>> JavaTest Message: shutting down test
>>>>>> 
>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>> 
>>>>>> PPS: The output of passed test now looks like:
>>>>>> 
>>>>>> === testJVersionStrings ===
>>>>>> Testing servertool
>>>>>> Testing jstat
>>>>>> Testing jmod
>>>>>> Testing jjs
>>>>>> Testing jimage
>>>>>> Testing jlink
>>>>>> Testing jrunscript
>>>>>> Testing jdeprscan
>>>>>> Testing jconsole
>>>>>> Testing rmiregistry
>>>>>> Testing keytool
>>>>>> Testing schemagen
>>>>>> Testing javac
>>>>>> Testing jar
>>>>>> Testing jhsdb
>>>>>> Testing jcmd
>>>>>> Testing jstack
>>>>>> Testing wsgen
>>>>>> Testing jshell
>>>>>> Testing serialver
>>>>>> Testing jmap
>>>>>> Testing javap
>>>>>> Testing jps
>>>>>> Testing jstatd
>>>>>> Testing javadoc
>>>>>> Testing tnameserv
>>>>>> Testing jdb
>>>>>> Testing jinfo
>>>>>> Testing jdeps
>>>>>> Testing xjc
>>>>>> Testing rmid
>>>>>> Testing jarsigner
>>>>>> Testing idlj
>>>>>> Testing rmic
>>>>>> Testing appletviewer
>>>>>> Testing pack200
>>>>>> Testing javah
>>>>>> Testing policytool
>>>>>> Testing orbd
>>>>>> testJVersionStrings passed
>>>>>> === testInternalStrings ===
>>>>>> testInternalStrings passed
>>>>>> === testToolVersion ===
>>>>>> Testing java
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>>> java version "9-ea"
>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javac
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>>> javac 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jhsdb
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>>   clhsdb           command line debugger
>>>>>>   debugd           debug server
>>>>>>   hsdb             ui debugger
>>>>>>   jstack --help    to get more information
>>>>>>   jmap   --help    to get more information
>>>>>>   jinfo  --help    to get more information
>>>>>>   jsnap  --help    to get more information
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jshell
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>>> jshell 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javap
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>>> 9-ea
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing jdb
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing idlj
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>>> #> echo $?
>>>>>> 0
>>>>>> Testing javah
>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>>> 
>>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>>> javac '-h' option; see the javac man page for more information.
>>>>>> 
>>>>>> javah version "9-ea"
>>>>>> #> echo $?
>>>>>> 0
>>>>>> testToolVersion passed
>>>>>> === testInternalStrings ===
>>>>>> testDebugVersion passed
>>>>>> All Version string comparisons: PASS
>>>>>> ----------System.err:(1/15)----------
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From andrey.x.nazarov at oracle.com  Mon Dec 26 15:45:38 2016
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Mon, 26 Dec 2016 18:45:38 +0300
Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report
	names of tools which failed checks
In-Reply-To: <42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com>
References: <a0659fe4-0035-b0f6-60a9-1f0fd82c747e@oracle.com>
	<D9BBBA76-BB7F-425E-A151-BF91A5C5DF54@oracle.com>
	<b3ae2749-761b-4a64-bbc1-3c1264efbc42@oracle.com>
	<0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com>
	<03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com>
	<6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com>
	<41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com>
	<42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com>
Message-ID: <651385B8-25FC-4036-8E0B-1C015367F863@oracle.com>


> On 26 Dec 2016, at 18:36, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
> 
> Hi Andrey,
> 
> On 26.12.2016 17:53, Andrey Nazarov wrote:
>> Hi,
>> 
>> 2 minor comments.
>> bug id  has not been added ?@bug 8171441?
> I believe the purpose of the @bug tag is to list the issues the test verifies or the test is regression test for.
> And it's not need to mention all the problem with the test itself here.
My understanding is that @bug tag is used to track the reasons for the test modifications and creation. But I haven?t seen any documentation for it.
>> javadoc should start with /** not  152 /*
> I intentionally kept "/*", because it's not a javadoc comment, but just a comment to a method.
> If we convert this to javadoc, we need to provide javadoc to other similar methods.
> Of course this would be good, but I'm afraid this activity is rather a separate RFE.
Ok.
> 
> Thanks,
> Dima
> 
>> 
>> 
>> ?Andrey
>>> On 26 Dec 2016, at 17:40, Stanislav Smirnov <stanislav.smirnov at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> thanks, looks good
>>> 
>>> Best regards,
>>> Stanislav Smirnov
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> new version:  http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ <http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/>
>>>> 
>>>> This comment now looks like:
>>>> 152     /*
>>>> 153      * Checks if the tools accept "-version" option (exit code is zero).
>>>> 154      * The output of the tools run with "-version" is not verified.
>>>> 155      */
>>>> 
>>>> Thanks
>>>> Dima
>>>> 
>>>> On 23.12.2016 13:40, Stanislav Smirnov wrote:
>>>>> Hi,
>>>>> 
>>>>> sorry, missed this strange comment during the first review.
>>>>> 152     /*
>>>>> 153      * this tests if the tool can take a version string and returns
>>>>> 154      * a 0 exit code, it is not possible to validate the contents
>>>>> 155      * of the -version output as they are inconsistent.
>>>>> 156      */
>>>>> 157     static String testToolVersion() {
>>>>> It confuses me, can you please rephrase it?
>>>>> 
>>>>> Best regards,
>>>>> Stanislav Smirnov
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Stanislav,
>>>>>> 
>>>>>> Thanks for looking.
>>>>>> Updated webrev:
>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.01/>
>>>>>> 
>>>>>> -- Dima
>>>>>> 
>>>>>> 
>>>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote:
>>>>>>> Hi Dima,
>>>>>>> 
>>>>>>> changes look good, I will only suggest using lambda?s in couple of iterations
>>>>>>> +            for (String s : tr.testOutput) {
>>>>>>> +                System.out.println(s);
>>>>>>> +            }
>>>>>>> tr.testOutput.forEach(System.out::println)
>>>>>>> 
>>>>>>>         for (String x : tr.testOutput) {
>>>>>>>             alist.add(x.trim());
>>>>>>>         }
>>>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add)
>>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Stanislav Smirnov
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko <dmitry.fazunenko at oracle.com <mailto:dmitry.fazunenko at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> I'm looking for reviews of a relatively simple test change:
>>>>>>>>   http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ <http://cr.openjdk.java.net/%7Edfazunen/8171441/webrev.00/>
>>>>>>>>   https://bugs.openjdk.java.net/browse/JDK-8171441 <https://bugs.openjdk.java.net/browse/JDK-8171441>
>>>>>>>> 
>>>>>>>> The purpose of the change is to improve diagnostic.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Dima
>>>>>>>> 
>>>>>>>> PS: After the fix the failures will be reported as:
>>>>>>>> 
>>>>>>>> ----------System.err:(13/956)----------
>>>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>>   at VersionCheck.main(VersionCheck.java:295)
>>>>>>>>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>   at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>   at java.base/java.lang.reflect.Method.invoke(Method.java:538)
>>>>>>>>   at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
>>>>>>>>   at java.base/java.lang.Thread.run(Thread.java:844)
>>>>>>>> 
>>>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>> JavaTest Message: shutting down test
>>>>>>>> 
>>>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar];
>>>>>>>> 
>>>>>>>> PPS: The output of passed test now looks like:
>>>>>>>> 
>>>>>>>> === testJVersionStrings ===
>>>>>>>> Testing servertool
>>>>>>>> Testing jstat
>>>>>>>> Testing jmod
>>>>>>>> Testing jjs
>>>>>>>> Testing jimage
>>>>>>>> Testing jlink
>>>>>>>> Testing jrunscript
>>>>>>>> Testing jdeprscan
>>>>>>>> Testing jconsole
>>>>>>>> Testing rmiregistry
>>>>>>>> Testing keytool
>>>>>>>> Testing schemagen
>>>>>>>> Testing javac
>>>>>>>> Testing jar
>>>>>>>> Testing jhsdb
>>>>>>>> Testing jcmd
>>>>>>>> Testing jstack
>>>>>>>> Testing wsgen
>>>>>>>> Testing jshell
>>>>>>>> Testing serialver
>>>>>>>> Testing jmap
>>>>>>>> Testing javap
>>>>>>>> Testing jps
>>>>>>>> Testing jstatd
>>>>>>>> Testing javadoc
>>>>>>>> Testing tnameserv
>>>>>>>> Testing jdb
>>>>>>>> Testing jinfo
>>>>>>>> Testing jdeps
>>>>>>>> Testing xjc
>>>>>>>> Testing rmid
>>>>>>>> Testing jarsigner
>>>>>>>> Testing idlj
>>>>>>>> Testing rmic
>>>>>>>> Testing appletviewer
>>>>>>>> Testing pack200
>>>>>>>> Testing javah
>>>>>>>> Testing policytool
>>>>>>>> Testing orbd
>>>>>>>> testJVersionStrings passed
>>>>>>>> === testInternalStrings ===
>>>>>>>> testInternalStrings passed
>>>>>>>> === testToolVersion ===
>>>>>>>> Testing java
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java> -version
>>>>>>>> java version "9-ea"
>>>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149)
>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode)
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing javac
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac> -version
>>>>>>>> javac 9-ea
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing jhsdb
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb> -version
>>>>>>>>   clhsdb           command line debugger
>>>>>>>>   debugd           debug server
>>>>>>>>   hsdb             ui debugger
>>>>>>>>   jstack --help    to get more information
>>>>>>>>   jmap   --help    to get more information
>>>>>>>>   jinfo  --help    to get more information
>>>>>>>>   jsnap  --help    to get more information
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing jshell
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell> -version
>>>>>>>> jshell 9-ea
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing javap
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap> -version
>>>>>>>> 9-ea
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing jdb
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb> -version
>>>>>>>> This is jdb version 9.0 (Java SE version 9-ea)
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing idlj
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj> -version
>>>>>>>> IDL-to-Java compiler (portable), version "3.2"
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> Testing javah
>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah <http://jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah> -version
>>>>>>>> 
>>>>>>>> Warning: The javah tool is planned to be removed in the next major
>>>>>>>> JDK release. The tool has been superseded by the '-h' option added
>>>>>>>> to javac in JDK 8. Users are recommended to migrate to using the
>>>>>>>> javac '-h' option; see the javac man page for more information.
>>>>>>>> 
>>>>>>>> javah version "9-ea"
>>>>>>>> #> echo $?
>>>>>>>> 0
>>>>>>>> testToolVersion passed
>>>>>>>> === testInternalStrings ===
>>>>>>>> testDebugVersion passed
>>>>>>>> All Version string comparisons: PASS
>>>>>>>> ----------System.err:(1/15)----------
>>>>>>>> 
>