From david.holmes at oracle.com  Thu Jun  1 00:49:02 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Jun 2017 10:49:02 +1000
Subject: OpenJDK build system might need to be adapted for Sun Solaris
 Sparc/SmartOS
In-Reply-To: <20170531122616.GF14877@physik.fu-berlin.de>
References: <CAGHtMWk94FY5fhOvrSH0HPDimQMJ19_aVazP=7+fyJpGmtSKug@mail.gmail.com>
 <3c079b6d-a8ad-275d-9068-043742b09bd6@oracle.com>
 <20170531095200.GA14877@physik.fu-berlin.de>
 <82892d7a-55a2-2882-6feb-41970dba431e@oracle.com>
 <20170531104400.GB14877@physik.fu-berlin.de>
 <CAGUMyaTNUcrVMgY8+MfkwY=fD22B24Y0bitHgOm5MNGEJ-=hjw@mail.gmail.com>
 <20170531115036.GE14877@physik.fu-berlin.de>
 <CAGUMyaQcqMfYC7kFQnW0Pee79o=6aaLPk-O+xYZW+iXXwArJPA@mail.gmail.com>
 <20170531122616.GF14877@physik.fu-berlin.de>
Message-ID: <a1707bcd-b29c-91a7-320d-63aba7e5c97f@oracle.com>

Hi Adrian,

The original thread has been hijacked by this discussion.

On 31/05/2017 10:26 PM, John Paul Adrian Glaubitz wrote:
> On Wed, May 31, 2017 at 02:12:16PM +0200, Mario Torre wrote:
>> I can't check the patches in detail now, but I see that the discussion
>> on those threads doesn't go much on the technical side but rather
>> focus on whether Oracle should support or not their own products :)
> 
> Well, I wish we could focus on the technical side.

The initial problem is not a technical one but a process one.

>> I think David's reply was highlighting the actual points instead:
>>
>> * The status of linux-sparc as a port in OpenJDK 9 (or 8u) is unclear
>> * There is no way you will get them JDK 9 at this stage, this work
>> needs to be done on 10
> 
> I just want the changes to get merged into what would be HEAD in git
> terms, just to get them off my plate.
> 
>> * Hotspot group leads should have a say on this
>>
>> I think it makes sense to seek the hotspot leads approval for that
>> work before anything else.
> 
> For one-liner patches?

It isn't the size or nature of these specific patches that is in 
question but the whole status of the linux/sparc port in OpenJDK. The 
leads may say "lets just take these now and defer the bigger question to 
later" - or they may say something else. That's their call.

David
-----

>>>> In the meantime perhaps I would suggest to get in touch with the
>>>> distro-pkg-dev people since they may help you, even if this is not
>>>> Linux specific.
>>>
>>> I am one of the maintainers of the Debian/sparc64 port and we have the
>>> possibility to add distro-specific patches. However, I don't want to
>>> carry these patches around forever but rather get them merged upstream
>>> and make them available to all downstreams, not just Debian.
>>>
>>
>> The way we have done that in the past is exactly this, slowly merge
>> upstream all the downstream specific changes, it's a process that
>> takes a lot of time, especially at the beginning when you need to
>> build trust and experience with the upstream developers.
> 
> That's sound very slow and painful. I don't think this way you will be
> able to attract contributors in the future. If such minor changes
> already involve so much discussion, most contributors will refrain
> from sending in patches which is sad because it means lots of good
> patches and ideas will never get merged.
> 
> Adrian
> 


From david.holmes at oracle.com  Thu Jun  1 01:22:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Jun 2017 11:22:31 +1000
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <592EC8F6.5080605@oracle.com>
References: <592EC8F6.5080605@oracle.com>
Message-ID: <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>

Hi Erik,

A small change with big questions :)

On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
> Hi,
> 
> It would be desirable to be able to use harmless C++ standard library 
> headers like <limits> in the code as long as it does not add any 
> link-time dependencies to the standard library.

What does a 'harmless' C++ standard library header look like?

> This is possible on all supported platforms except the ones using the 
> solaris studio compiler where we enforce -library=%none in both CFLAGS 
> and LDFLAGS.
> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
> 
> I have consulted with the studio folks, and they think this is 
> absolutely fine and thought that the choice of -library=stlport4 should 
> be fine for our CFLAGS and is indeed what is already used in the gtest 
> launcher.

So what exactly does this mean? IIUC this allows you to use headers for, 
and compile against "STLport?s Standard Library implementation version 
4.5.3 instead of the default libCstd". But how do you then not need to 
link against libstlport.so ??

https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html

"STLport is binary incompatible with the default libCstd. If you use the 
STLport implementation of the standard library, then you must compile 
and link all files, including third-party libraries, with the option 
-library=stlport4"

There are lots of other comments in that document regarding STLport that 
makes me think that using it may be introducing a fragile dependency 
into the OpenJDK code!

"STLport is an open source product and does not guarantee compatibility 
across different releases. In other words, compiling with a future 
version of STLport may break applications compiled with STLport 4.5.3. 
It also might not be possible to link binaries compiled using STLport 
4.5.3 with binaries compiled using a future version of STLport."

"Future releases of the compiler might not include STLport4. They might 
include only a later version of STLport. The compiler option 
-library=stlport4 might not be available in future releases, but could 
be replaced by an option referring to a later STLport version."

None of that sounds very good to me.

Cheers,
David


> Webrev for jdk10-hs top level repository:
> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
> 
> Webrev for jdk10-hs hotspot repository:
> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
> 
> Testing: JPRT.
> 
> Will need a sponsor.
> 
> Thanks,
> /Erik


From kim.barrett at oracle.com  Thu Jun  1 05:51:24 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 1 Jun 2017 01:51:24 -0400
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
Message-ID: <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>

> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Erik,
> 
> A small change with big questions :)
> 
> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>> Hi,
>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
> 
> What does a 'harmless' C++ standard library header look like?

Header-only (doesn't require linking), doesn't run afoul of our
[vm]assert macro, and provides functionality we presently lack (or
only handle poorly) and would not be easy to reproduce.

The instigator for this is Erik and I are working on a project that
needs information that is present in std::numeric_limits<> (provided
by the <limits> header).  Reproducing that functionality ourselves
would require platform-specific code (with all the complexity that can
imply).  We'd really rather not re-discover and maintain information
that is trivially accessible in every standard library.

>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
> 
> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
> 
> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
> 
> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?

It means we can only use header-only parts of the standard library.
This was confirmed / suggested by the Studio folks Erik consulted,
providing such limited access while continuing to constrain our
dependency on the library.  Figuring out what can be used will need to
be determined on a case-by-case basis.  Maybe we could just link with
a standard library on Solaris too.  So far as I can tell, Solaris is
the only platform where we don't do that.  But Erik is trying to be
conservative.

> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
> 
> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
> 
> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
> 
> None of that sounds very good to me.

I don't see how this is any different from any other part of the
process for using a different version of Solaris Studio.

stlport4 is one of the three standard libraries that are presently
included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
Studio folks which to use (for the purposes of our present project, we
don't have any particular preference, so long as it works), and
stlport4 seemed the right choice (libCstd was, I think, described as
"ancient").  Perhaps more importantly, we already use stlport4,
including linking against it, for gtest builds.  Mixing two different
standard libraries seems like a bad idea...

> 
> Cheers,
> David
> 
> 
>> Webrev for jdk10-hs top level repository:
>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>> Webrev for jdk10-hs hotspot repository:
>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>> Testing: JPRT.
>> Will need a sponsor.
>> Thanks,
>> /Erik




From david.holmes at oracle.com  Thu Jun  1 06:09:09 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Jun 2017 16:09:09 +1000
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
Message-ID: <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com>

Hi Kim,

On 1/06/2017 3:51 PM, Kim Barrett wrote:
>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Erik,
>>
>> A small change with big questions :)
>>
>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>> Hi,
>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>>
>> What does a 'harmless' C++ standard library header look like?
> 
> Header-only (doesn't require linking), doesn't run afoul of our
> [vm]assert macro, and provides functionality we presently lack (or
> only handle poorly) and would not be easy to reproduce.

And how does one establish those properties exist for a given header 
file? Just use it and if no link errors then all is good?

> The instigator for this is Erik and I are working on a project that
> needs information that is present in std::numeric_limits<> (provided
> by the <limits> header).  Reproducing that functionality ourselves
> would require platform-specific code (with all the complexity that can
> imply).  We'd really rather not re-discover and maintain information
> that is trivially accessible in every standard library.

Understood. I have no issue with using <limits> but am concerned by the 
state of stlport4. Can you use <limits> without changing -library=%none?

>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>>
>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>>
>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>
>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?
> 
> It means we can only use header-only parts of the standard library.
> This was confirmed / suggested by the Studio folks Erik consulted,
> providing such limited access while continuing to constrain our
> dependency on the library.  Figuring out what can be used will need to
> be determined on a case-by-case basis.  Maybe we could just link with
> a standard library on Solaris too.  So far as I can tell, Solaris is
> the only platform where we don't do that.  But Erik is trying to be
> conservative.

Okay, but the docs don't seem to acknowledge the ability to use, but not 
link to, stlport4.

>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>>
>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>>
>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>>
>> None of that sounds very good to me.
> 
> I don't see how this is any different from any other part of the
> process for using a different version of Solaris Studio.

Well we'd discover the problem when testing the compiler change, but my 
point was more to the fact that they don't seem very committed to this 
library - very much a "use at own risk" disclaimer.

> stlport4 is one of the three standard libraries that are presently
> included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
> Studio folks which to use (for the purposes of our present project, we
> don't have any particular preference, so long as it works), and
> stlport4 seemed the right choice (libCstd was, I think, described as
> "ancient").  Perhaps more importantly, we already use stlport4,
> including linking against it, for gtest builds.  Mixing two different
> standard libraries seems like a bad idea...

So we have the choice of "ancient", "unsupported" or gcc :)

My confidence in this has not increased :)

What we do in gtest doesn't necessarily make things okay to do in the 
product.

If this were part of a compiler upgrade process we'd be comparing 
binaries with old flag and new to ensure there are no unexpected 
consequences.

Cheers,
David

>>
>> Cheers,
>> David
>>
>>
>>> Webrev for jdk10-hs top level repository:
>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>> Webrev for jdk10-hs hotspot repository:
>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>> Testing: JPRT.
>>> Will need a sponsor.
>>> Thanks,
>>> /Erik
> 
> 


From volker.simonis at gmail.com  Thu Jun  1 07:05:32 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 1 Jun 2017 09:05:32 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
Message-ID: <CA+3eh13ZTHQfNCUCEFsqeQzc-Un5J_Gx5-afQta20N_HEwu8yw@mail.gmail.com>

On Thu, Jun 1, 2017 at 7:51 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Erik,
>>
>> A small change with big questions :)
>>
>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>> Hi,
>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>>
>> What does a 'harmless' C++ standard library header look like?
>
> Header-only (doesn't require linking), doesn't run afoul of our
> [vm]assert macro, and provides functionality we presently lack (or
> only handle poorly) and would not be easy to reproduce.
>
> The instigator for this is Erik and I are working on a project that
> needs information that is present in std::numeric_limits<> (provided
> by the <limits> header).  Reproducing that functionality ourselves
> would require platform-specific code (with all the complexity that can
> imply).  We'd really rather not re-discover and maintain information
> that is trivially accessible in every standard library.
>

Hi Kim, Erik,

can you please explain why you only need this information on Solaris?

I'm just a little concerned that if you start this for "Solaris only"
it will be sooner or later be needed on other platforms as well.

As David already asked, how do you ensure to only use functionality
from the C++ standard library header which doesn't require link
support?

Thanks,
Volker

>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>>
>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>>
>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>
>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?
>
> It means we can only use header-only parts of the standard library.
> This was confirmed / suggested by the Studio folks Erik consulted,
> providing such limited access while continuing to constrain our
> dependency on the library.  Figuring out what can be used will need to
> be determined on a case-by-case basis.  Maybe we could just link with
> a standard library on Solaris too.  So far as I can tell, Solaris is
> the only platform where we don't do that.  But Erik is trying to be
> conservative.
>
>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>>
>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>>
>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>>
>> None of that sounds very good to me.
>
> I don't see how this is any different from any other part of the
> process for using a different version of Solaris Studio.
>
> stlport4 is one of the three standard libraries that are presently
> included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
> Studio folks which to use (for the purposes of our present project, we
> don't have any particular preference, so long as it works), and
> stlport4 seemed the right choice (libCstd was, I think, described as
> "ancient").  Perhaps more importantly, we already use stlport4,
> including linking against it, for gtest builds.  Mixing two different
> standard libraries seems like a bad idea...
>
>>
>> Cheers,
>> David
>>
>>
>>> Webrev for jdk10-hs top level repository:
>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>> Webrev for jdk10-hs hotspot repository:
>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>> Testing: JPRT.
>>> Will need a sponsor.
>>> Thanks,
>>> /Erik
>
>


From kim.barrett at oracle.com  Thu Jun  1 07:18:09 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 1 Jun 2017 03:18:09 -0400
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <CA+3eh13ZTHQfNCUCEFsqeQzc-Un5J_Gx5-afQta20N_HEwu8yw@mail.gmail.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <CA+3eh13ZTHQfNCUCEFsqeQzc-Un5J_Gx5-afQta20N_HEwu8yw@mail.gmail.com>
Message-ID: <DE87EE5A-33DA-4995-9CD9-BBB23D03ACC1@oracle.com>

> On Jun 1, 2017, at 3:05 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Thu, Jun 1, 2017 at 7:51 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> The instigator for this is Erik and I are working on a project that
>> needs information that is present in std::numeric_limits<> (provided
>> by the <limits> header).  Reproducing that functionality ourselves
>> would require platform-specific code (with all the complexity that can
>> imply).  We'd really rather not re-discover and maintain information
>> that is trivially accessible in every standard library.
>> 
> 
> Hi Kim, Erik,
> 
> can you please explain why you only need this information on Solaris?
> 
> I'm just a little concerned that if you start this for "Solaris only"
> it will be sooner or later be needed on other platforms as well.

The change is only to Solaris because the present Solaris build configuration
is the only one which doesn?t already provide the access we want.



From erik.osterlund at oracle.com  Thu Jun  1 09:36:00 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 1 Jun 2017 11:36:00 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com>
Message-ID: <592FE000.50003@oracle.com>

Hi David,

On 2017-06-01 08:09, David Holmes wrote:
> Hi Kim,
>
> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> Hi Erik,
>>>
>>> A small change with big questions :)
>>>
>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>> Hi,
>>>> It would be desirable to be able to use harmless C++ standard 
>>>> library headers like <limits> in the code as long as it does not 
>>>> add any link-time dependencies to the standard library.
>>>
>>> What does a 'harmless' C++ standard library header look like?
>>
>> Header-only (doesn't require linking), doesn't run afoul of our
>> [vm]assert macro, and provides functionality we presently lack (or
>> only handle poorly) and would not be easy to reproduce.
>
> And how does one establish those properties exist for a given header 
> file? Just use it and if no link errors then all is good?

Objects from headers that are not ODR-used such as constant folded 
expressions are not imposing link-time dependencies to C++ libraries. 
The -xnolib that we already have in the LDFLAGS will catch any 
accidental ODR-uses of C++ objects, and the JVM will not build if that 
happens.

As for external headers being included and not playing nicely with 
macros, this has to be evaluated on a case by case basis. Note that this 
is a problem that occurs when using system headers (that we are already 
using), as it is for using C++ standard library headers. We even run 
into that in our own JVM when e.g. the min/max macros occasionally slaps 
us gently in the face from time to time.

>
>> The instigator for this is Erik and I are working on a project that
>> needs information that is present in std::numeric_limits<> (provided
>> by the <limits> header).  Reproducing that functionality ourselves
>> would require platform-specific code (with all the complexity that can
>> imply).  We'd really rather not re-discover and maintain information
>> that is trivially accessible in every standard library.
>
> Understood. I have no issue with using <limits> but am concerned by 
> the state of stlport4. Can you use <limits> without changing 
> -library=%none?

No, that is precisely why we are here.

>
>>>> This is possible on all supported platforms except the ones using 
>>>> the solaris studio compiler where we enforce -library=%none in both 
>>>> CFLAGS and LDFLAGS.
>>>> I propose to remove the restriction from CFLAGS but keep it on 
>>>> LDFLAGS.
>>>> I have consulted with the studio folks, and they think this is 
>>>> absolutely fine and thought that the choice of -library=stlport4 
>>>> should be fine for our CFLAGS and is indeed what is already used in 
>>>> the gtest launcher.
>>>
>>> So what exactly does this mean? IIUC this allows you to use headers 
>>> for, and compile against "STLport?s Standard Library implementation 
>>> version 4.5.3 instead of the default libCstd". But how do you then 
>>> not need to link against libstlport.so ??
>>>
>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>
>>> "STLport is binary incompatible with the default libCstd. If you use 
>>> the STLport implementation of the standard library, then you must 
>>> compile and link all files, including third-party libraries, with 
>>> the option -library=stlport4?
>>
>> It means we can only use header-only parts of the standard library.
>> This was confirmed / suggested by the Studio folks Erik consulted,
>> providing such limited access while continuing to constrain our
>> dependency on the library.  Figuring out what can be used will need to
>> be determined on a case-by-case basis.  Maybe we could just link with
>> a standard library on Solaris too.  So far as I can tell, Solaris is
>> the only platform where we don't do that.  But Erik is trying to be
>> conservative.
>
> Okay, but the docs don't seem to acknowledge the ability to use, but 
> not link to, stlport4.

Not ODR-used objects do not require linkage. 
(http://en.cppreference.com/w/cpp/language/definition)
I have confirmed directly with the studio folks to be certain that 
accidental linkage would fail by keeping our existing guards in the 
LDFLAGS rather than the CFLAGS.
This is also reasonably well documented already 
(https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).

>
>>> There are lots of other comments in that document regarding STLport 
>>> that makes me think that using it may be introducing a fragile 
>>> dependency into the OpenJDK code!
>>>
>>> "STLport is an open source product and does not guarantee 
>>> compatibility across different releases. In other words, compiling 
>>> with a future version of STLport may break applications compiled 
>>> with STLport 4.5.3. It also might not be possible to link binaries 
>>> compiled using STLport 4.5.3 with binaries compiled using a future 
>>> version of STLport."
>>>
>>> "Future releases of the compiler might not include STLport4. They 
>>> might include only a later version of STLport. The compiler option 
>>> -library=stlport4 might not be available in future releases, but 
>>> could be replaced by an option referring to a later STLport version."
>>>
>>> None of that sounds very good to me.
>>
>> I don't see how this is any different from any other part of the
>> process for using a different version of Solaris Studio.
>
> Well we'd discover the problem when testing the compiler change, but 
> my point was more to the fact that they don't seem very committed to 
> this library - very much a "use at own risk" disclaimer.

If we eventually need to use something more modern for features that 
have not been around for a decade, like C++11 features, then we can 
change standard library when that day comes.

>
>> stlport4 is one of the three standard libraries that are presently
>> included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
>> Studio folks which to use (for the purposes of our present project, we
>> don't have any particular preference, so long as it works), and
>> stlport4 seemed the right choice (libCstd was, I think, described as
>> "ancient").  Perhaps more importantly, we already use stlport4,
>> including linking against it, for gtest builds.  Mixing two different
>> standard libraries seems like a bad idea...
>
> So we have the choice of "ancient", "unsupported" or gcc :)
>
> My confidence in this has not increased :)

I trust that e.g. std::numeric_limits<T>::is_signed in the standard 
libraries has more mileage than whatever simplified rewrite of that we 
try to replicate in the JVM. So it is not obvious to me that we should 
have less confidence in the same functionality from a standard library 
shipped together with the compiler we are using and that has already 
been used and tested in a variety of C++ applications for over a decade 
compared to the alternative of reinventing it ourselves.

> What we do in gtest doesn't necessarily make things okay to do in the 
> product.
>
> If this were part of a compiler upgrade process we'd be comparing 
> binaries with old flag and new to ensure there are no unexpected 
> consequences.

I would not compare including <limits> to a compiler upgrade process as 
we are not changing the compiler and hence not the way code is 
generated, but rather compare it to including a new system header that 
has previously not been included to use a constant folded expression 
from that header that has been used and tested for a decade. At least 
that is how I think of it.

Thanks,
/Erik

>
> Cheers,
> David
>
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>> Webrev for jdk10-hs top level repository:
>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>> Webrev for jdk10-hs hotspot repository:
>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>> Testing: JPRT.
>>>> Will need a sponsor.
>>>> Thanks,
>>>> /Erik
>>
>>



From david.holmes at oracle.com  Thu Jun  1 12:33:45 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Jun 2017 22:33:45 +1000
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <592FE000.50003@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
Message-ID: <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>

Hi Erik,

Just to be clear it is not the use of <limits> that I am concerned 
about, it is the -library=stlport4. It is the use of that flag that I 
would want to check in terms of having no affect on any existing code 
generation.

I'm finding the actual build situation very confusing. It seems to me in 
looking at the hotspot build files and the top-level build files that 
-xnolib is used for C++ compilation & linking whereas -library=%none is 
used for C compilation & linking. But the change is being applied to 
$2JVM_CFLAGS which one would think is for C compilation but we don't 
have $2JVM_CXXFLAGS, so it seems to be used for both!

David

On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
> Hi David,
> 
> On 2017-06-01 08:09, David Holmes wrote:
>> Hi Kim,
>>
>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi Erik,
>>>>
>>>> A small change with big questions :)
>>>>
>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>> Hi,
>>>>> It would be desirable to be able to use harmless C++ standard 
>>>>> library headers like <limits> in the code as long as it does not 
>>>>> add any link-time dependencies to the standard library.
>>>>
>>>> What does a 'harmless' C++ standard library header look like?
>>>
>>> Header-only (doesn't require linking), doesn't run afoul of our
>>> [vm]assert macro, and provides functionality we presently lack (or
>>> only handle poorly) and would not be easy to reproduce.
>>
>> And how does one establish those properties exist for a given header 
>> file? Just use it and if no link errors then all is good?
> 
> Objects from headers that are not ODR-used such as constant folded 
> expressions are not imposing link-time dependencies to C++ libraries. 
> The -xnolib that we already have in the LDFLAGS will catch any 
> accidental ODR-uses of C++ objects, and the JVM will not build if that 
> happens.
> 
> As for external headers being included and not playing nicely with 
> macros, this has to be evaluated on a case by case basis. Note that this 
> is a problem that occurs when using system headers (that we are already 
> using), as it is for using C++ standard library headers. We even run 
> into that in our own JVM when e.g. the min/max macros occasionally slaps 
> us gently in the face from time to time.
> 
>>
>>> The instigator for this is Erik and I are working on a project that
>>> needs information that is present in std::numeric_limits<> (provided
>>> by the <limits> header).  Reproducing that functionality ourselves
>>> would require platform-specific code (with all the complexity that can
>>> imply).  We'd really rather not re-discover and maintain information
>>> that is trivially accessible in every standard library.
>>
>> Understood. I have no issue with using <limits> but am concerned by 
>> the state of stlport4. Can you use <limits> without changing 
>> -library=%none?
> 
> No, that is precisely why we are here.
> 
>>
>>>>> This is possible on all supported platforms except the ones using 
>>>>> the solaris studio compiler where we enforce -library=%none in both 
>>>>> CFLAGS and LDFLAGS.
>>>>> I propose to remove the restriction from CFLAGS but keep it on 
>>>>> LDFLAGS.
>>>>> I have consulted with the studio folks, and they think this is 
>>>>> absolutely fine and thought that the choice of -library=stlport4 
>>>>> should be fine for our CFLAGS and is indeed what is already used in 
>>>>> the gtest launcher.
>>>>
>>>> So what exactly does this mean? IIUC this allows you to use headers 
>>>> for, and compile against "STLport?s Standard Library implementation 
>>>> version 4.5.3 instead of the default libCstd". But how do you then 
>>>> not need to link against libstlport.so ??
>>>>
>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>
>>>> "STLport is binary incompatible with the default libCstd. If you use 
>>>> the STLport implementation of the standard library, then you must 
>>>> compile and link all files, including third-party libraries, with 
>>>> the option -library=stlport4?
>>>
>>> It means we can only use header-only parts of the standard library.
>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>> providing such limited access while continuing to constrain our
>>> dependency on the library.  Figuring out what can be used will need to
>>> be determined on a case-by-case basis.  Maybe we could just link with
>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>> the only platform where we don't do that.  But Erik is trying to be
>>> conservative.
>>
>> Okay, but the docs don't seem to acknowledge the ability to use, but 
>> not link to, stlport4.
> 
> Not ODR-used objects do not require linkage. 
> (http://en.cppreference.com/w/cpp/language/definition)
> I have confirmed directly with the studio folks to be certain that 
> accidental linkage would fail by keeping our existing guards in the 
> LDFLAGS rather than the CFLAGS.
> This is also reasonably well documented already 
> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
> 
>>
>>>> There are lots of other comments in that document regarding STLport 
>>>> that makes me think that using it may be introducing a fragile 
>>>> dependency into the OpenJDK code!
>>>>
>>>> "STLport is an open source product and does not guarantee 
>>>> compatibility across different releases. In other words, compiling 
>>>> with a future version of STLport may break applications compiled 
>>>> with STLport 4.5.3. It also might not be possible to link binaries 
>>>> compiled using STLport 4.5.3 with binaries compiled using a future 
>>>> version of STLport."
>>>>
>>>> "Future releases of the compiler might not include STLport4. They 
>>>> might include only a later version of STLport. The compiler option 
>>>> -library=stlport4 might not be available in future releases, but 
>>>> could be replaced by an option referring to a later STLport version."
>>>>
>>>> None of that sounds very good to me.
>>>
>>> I don't see how this is any different from any other part of the
>>> process for using a different version of Solaris Studio.
>>
>> Well we'd discover the problem when testing the compiler change, but 
>> my point was more to the fact that they don't seem very committed to 
>> this library - very much a "use at own risk" disclaimer.
> 
> If we eventually need to use something more modern for features that 
> have not been around for a decade, like C++11 features, then we can 
> change standard library when that day comes.
> 
>>
>>> stlport4 is one of the three standard libraries that are presently
>>> included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
>>> Studio folks which to use (for the purposes of our present project, we
>>> don't have any particular preference, so long as it works), and
>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>> including linking against it, for gtest builds.  Mixing two different
>>> standard libraries seems like a bad idea...
>>
>> So we have the choice of "ancient", "unsupported" or gcc :)
>>
>> My confidence in this has not increased :)
> 
> I trust that e.g. std::numeric_limits<T>::is_signed in the standard 
> libraries has more mileage than whatever simplified rewrite of that we 
> try to replicate in the JVM. So it is not obvious to me that we should 
> have less confidence in the same functionality from a standard library 
> shipped together with the compiler we are using and that has already 
> been used and tested in a variety of C++ applications for over a decade 
> compared to the alternative of reinventing it ourselves.
> 
>> What we do in gtest doesn't necessarily make things okay to do in the 
>> product.
>>
>> If this were part of a compiler upgrade process we'd be comparing 
>> binaries with old flag and new to ensure there are no unexpected 
>> consequences.
> 
> I would not compare including <limits> to a compiler upgrade process as 
> we are not changing the compiler and hence not the way code is 
> generated, but rather compare it to including a new system header that 
> has previously not been included to use a constant folded expression 
> from that header that has been used and tested for a decade. At least 
> that is how I think of it.
> 
> Thanks,
> /Erik
> 
>>
>> Cheers,
>> David
>>
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>
>>>>> Webrev for jdk10-hs top level repository:
>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>> Webrev for jdk10-hs hotspot repository:
>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>> Testing: JPRT.
>>>>> Will need a sponsor.
>>>>> Thanks,
>>>>> /Erik
>>>
>>>
> 


From magnus.ihse.bursie at oracle.com  Thu Jun  1 12:46:19 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 1 Jun 2017 14:46:19 +0200
Subject: RFR: JDK-8180322 Move JNI spec to specs directory
Message-ID: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>

The JNI spec will move to a new place in the "specs" directory in the 
docs image, and links to it needs to be updated.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180322
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180322-move-jni-spec/webrev.01

This is a noreg-docs fix and will be pushed to jdk9.

/Magnus


From Roger.Riggs at Oracle.com  Thu Jun  1 13:29:24 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 1 Jun 2017 09:29:24 -0400
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
 <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>
Message-ID: <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>

Ping on the build change please


On 5/31/2017 10:43 AM, Alan Bateman wrote:
> On 31/05/2017 15:34, Roger Riggs wrote:
>
>> Please review javadoc markup change to update to html5 acceptable to 
>> doclint.
>> The table formatting is updated to html5 markup.
>>
>> The Docs build is updated to require doclint html5.
>>
>> Webrev:
>>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
>>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
> Some of the lines are way too long now and will means lots of 
> horizontal scrolling when looking at diffs in the future. Can these be 
> cleaned up before these changes are pushed?
>
> -Alan



From erik.joelsson at oracle.com  Thu Jun  1 13:46:20 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 1 Jun 2017 15:46:20 +0200
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
 <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>
 <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>
Message-ID: <03965d9c-697a-6a7c-5cfa-7ae010e17553@oracle.com>

Build change looks good, sorry for the delay.

/Erik

On 2017-06-01 15:29, Roger Riggs wrote:
> Ping on the build change please
>
>
> On 5/31/2017 10:43 AM, Alan Bateman wrote:
>> On 31/05/2017 15:34, Roger Riggs wrote:
>>
>>> Please review javadoc markup change to update to html5 acceptable to 
>>> doclint.
>>> The table formatting is updated to html5 markup.
>>>
>>> The Docs build is updated to require doclint html5.
>>>
>>> Webrev:
>>>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
>>>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
>> Some of the lines are way too long now and will means lots of 
>> horizontal scrolling when looking at diffs in the future. Can these 
>> be cleaned up before these changes are pushed?
>>
>> -Alan
>



From magnus.ihse.bursie at oracle.com  Thu Jun  1 13:46:46 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 1 Jun 2017 15:46:46 +0200
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
 <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>
 <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>
Message-ID: <083ba29d-d386-3d33-a729-303378140834@oracle.com>



On 2017-06-01 15:29, Roger Riggs wrote:
> Ping on the build change please

Just remove the entire "--doclint-format html4" instead, 
--doclint-format html5 is default and just overridden for java.base. 
(Basically revert CompileJavaModules.gmk to what it was just a while ago 
:-)).

/Magnus

>
>
> On 5/31/2017 10:43 AM, Alan Bateman wrote:
>> On 31/05/2017 15:34, Roger Riggs wrote:
>>
>>> Please review javadoc markup change to update to html5 acceptable to 
>>> doclint.
>>> The table formatting is updated to html5 markup.
>>>
>>> The Docs build is updated to require doclint html5.
>>>
>>> Webrev:
>>>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
>>>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
>> Some of the lines are way too long now and will means lots of 
>> horizontal scrolling when looking at diffs in the future. Can these 
>> be cleaned up before these changes are pushed?
>>
>> -Alan
>



From Roger.Riggs at Oracle.com  Thu Jun  1 14:23:06 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 1 Jun 2017 10:23:06 -0400
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <083ba29d-d386-3d33-a729-303378140834@oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
 <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>
 <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>
 <083ba29d-d386-3d33-a729-303378140834@oracle.com>
Message-ID: <6e907018-c1f0-cc0d-434c-3bc0fec29953@Oracle.com>

Thanks,

Webrev updated in place.
   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/

Roger

On 6/1/2017 9:46 AM, Magnus Ihse Bursie wrote:
>
>
> On 2017-06-01 15:29, Roger Riggs wrote:
>> Ping on the build change please
>
> Just remove the entire "--doclint-format html4" instead, 
> --doclint-format html5 is default and just overridden for java.base. 
> (Basically revert CompileJavaModules.gmk to what it was just a while 
> ago :-)).
>
> /Magnus
>
>>
>>
>> On 5/31/2017 10:43 AM, Alan Bateman wrote:
>>> On 31/05/2017 15:34, Roger Riggs wrote:
>>>
>>>> Please review javadoc markup change to update to html5 acceptable 
>>>> to doclint.
>>>> The table formatting is updated to html5 markup.
>>>>
>>>> The Docs build is updated to require doclint html5.
>>>>
>>>> Webrev:
>>>>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
>>>>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
>>> Some of the lines are way too long now and will means lots of 
>>> horizontal scrolling when looking at diffs in the future. Can these 
>>> be cleaned up before these changes are pushed?
>>>
>>> -Alan
>>
>



From kim.barrett at oracle.com  Thu Jun  1 14:42:49 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 1 Jun 2017 10:42:49 -0400
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
Message-ID: <0162ADA7-003A-46C6-90A6-381E8667D969@oracle.com>

> On Jun 1, 2017, at 8:33 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Erik,
> 
> Just to be clear it is not the use of <limits> that I am concerned about, it is the -library=stlport4. It is the use of that flag that I would want to check in terms of having no affect on any existing code generation.
> 
> I'm finding the actual build situation very confusing. It seems to me in looking at the hotspot build files and the top-level build files that -xnolib is used for C++ compilation & linking whereas -library=%none is used for C compilation & linking. But the change is being applied to $2JVM_CFLAGS which one would think is for C compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used for both!
> 
> David

Yes, it does look like there is some confusion there.

The documentation says that if using -xnolib, then -library is ignored!

Using -xnolib suppresses all the normal support libraries, and one must explicitly add back what?s needed.
And it looks like we do add -lCrun.



From erik.osterlund at oracle.com  Thu Jun  1 14:50:51 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 1 Jun 2017 16:50:51 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
Message-ID: <593029CB.7000100@oracle.com>

Hi David,

On 2017-06-01 14:33, David Holmes wrote:
> Hi Erik,
>
> Just to be clear it is not the use of <limits> that I am concerned 
> about, it is the -library=stlport4. It is the use of that flag that I 
> would want to check in terms of having no affect on any existing code 
> generation.

Thank you for the clarification. The use of -library=stlport4 should not 
have anything to do with code generation. It only says where to look for 
the standard library headers such as <limits> that are used in the 
compilation units.

Specifically, the man pages for CC say:

<man>
        -library=lib[,lib...]

            Incorporates  specified  CC-provided libraries into 
compilation and
            linking.

            When the -library option is used to specify a CC-provided  
library,
            the  proper  -I paths are set during compilation and the 
proper -L,
            -Y, -P, and -R paths and -l options are set during linking.
</man>

As we are setting this during compilation and not during linking, this 
corresponds to setting the right -I paths to find our C++ standard 
library headers.

My studio friends mentioned I could double-check that we did indeed not 
add a dependency to any C++ standard library by running elfdump on the 
generated libjvm.so file and check if the NEEDED entries in the dynamic 
section look right. I did and here are the results:

       [0]  NEEDED          0x2918ee   libsocket.so.1
       [1]  NEEDED          0x2918fd   libsched.so.1
       [2]  NEEDED          0x29190b   libdl.so.1
       [3]  NEEDED          0x291916   libm.so.1
       [4]  NEEDED          0x291920   libCrun.so.1
       [5]  NEEDED          0x29192d   libthread.so.1
       [6]  NEEDED          0x29193c   libdoor.so.1
       [7]  NEEDED          0x291949   libc.so.1
       [8]  NEEDED          0x291953   libdemangle.so.1
       [9]  NEEDED          0x291964   libnsl.so.1
      [10]  NEEDED          0x291970   libkstat.so.1
      [11]  NEEDED          0x29197e   librt.so.1

This list does not include any C++ standard libraries, as expected 
(libCrun is always in there even with -library=%none, and as expected no 
libstlport4.so or libCstd.so files are in there). The NEEDED entries in 
the dynamic section look identical with and without my patch.

> I'm finding the actual build situation very confusing. It seems to me 
> in looking at the hotspot build files and the top-level build files 
> that -xnolib is used for C++ compilation & linking whereas 
> -library=%none is used for C compilation & linking. But the change is 
> being applied to $2JVM_CFLAGS which one would think is for C 
> compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used 
> for both!

I have also been confused by this when I tried adding CXX flags through 
configure that seemed to not be used. But that's a different can of 
worms I suppose.

Thanks,
/Erik

> David
>
> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>> Hi David,
>>
>> On 2017-06-01 08:09, David Holmes wrote:
>>> Hi Kim,
>>>
>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>> On May 31, 2017, at 9:22 PM, David Holmes 
>>>>> <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Erik,
>>>>>
>>>>> A small change with big questions :)
>>>>>
>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>> Hi,
>>>>>> It would be desirable to be able to use harmless C++ standard 
>>>>>> library headers like <limits> in the code as long as it does not 
>>>>>> add any link-time dependencies to the standard library.
>>>>>
>>>>> What does a 'harmless' C++ standard library header look like?
>>>>
>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>> only handle poorly) and would not be easy to reproduce.
>>>
>>> And how does one establish those properties exist for a given header 
>>> file? Just use it and if no link errors then all is good?
>>
>> Objects from headers that are not ODR-used such as constant folded 
>> expressions are not imposing link-time dependencies to C++ libraries. 
>> The -xnolib that we already have in the LDFLAGS will catch any 
>> accidental ODR-uses of C++ objects, and the JVM will not build if 
>> that happens.
>>
>> As for external headers being included and not playing nicely with 
>> macros, this has to be evaluated on a case by case basis. Note that 
>> this is a problem that occurs when using system headers (that we are 
>> already using), as it is for using C++ standard library headers. We 
>> even run into that in our own JVM when e.g. the min/max macros 
>> occasionally slaps us gently in the face from time to time.
>>
>>>
>>>> The instigator for this is Erik and I are working on a project that
>>>> needs information that is present in std::numeric_limits<> (provided
>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>> would require platform-specific code (with all the complexity that can
>>>> imply).  We'd really rather not re-discover and maintain information
>>>> that is trivially accessible in every standard library.
>>>
>>> Understood. I have no issue with using <limits> but am concerned by 
>>> the state of stlport4. Can you use <limits> without changing 
>>> -library=%none?
>>
>> No, that is precisely why we are here.
>>
>>>
>>>>>> This is possible on all supported platforms except the ones using 
>>>>>> the solaris studio compiler where we enforce -library=%none in 
>>>>>> both CFLAGS and LDFLAGS.
>>>>>> I propose to remove the restriction from CFLAGS but keep it on 
>>>>>> LDFLAGS.
>>>>>> I have consulted with the studio folks, and they think this is 
>>>>>> absolutely fine and thought that the choice of -library=stlport4 
>>>>>> should be fine for our CFLAGS and is indeed what is already used 
>>>>>> in the gtest launcher.
>>>>>
>>>>> So what exactly does this mean? IIUC this allows you to use 
>>>>> headers for, and compile against "STLport?s Standard Library 
>>>>> implementation version 4.5.3 instead of the default libCstd". But 
>>>>> how do you then not need to link against libstlport.so ??
>>>>>
>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>
>>>>> "STLport is binary incompatible with the default libCstd. If you 
>>>>> use the STLport implementation of the standard library, then you 
>>>>> must compile and link all files, including third-party libraries, 
>>>>> with the option -library=stlport4?
>>>>
>>>> It means we can only use header-only parts of the standard library.
>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>> providing such limited access while continuing to constrain our
>>>> dependency on the library.  Figuring out what can be used will need to
>>>> be determined on a case-by-case basis.  Maybe we could just link with
>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>> the only platform where we don't do that.  But Erik is trying to be
>>>> conservative.
>>>
>>> Okay, but the docs don't seem to acknowledge the ability to use, but 
>>> not link to, stlport4.
>>
>> Not ODR-used objects do not require linkage. 
>> (http://en.cppreference.com/w/cpp/language/definition)
>> I have confirmed directly with the studio folks to be certain that 
>> accidental linkage would fail by keeping our existing guards in the 
>> LDFLAGS rather than the CFLAGS.
>> This is also reasonably well documented already 
>> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>
>>>
>>>>> There are lots of other comments in that document regarding 
>>>>> STLport that makes me think that using it may be introducing a 
>>>>> fragile dependency into the OpenJDK code!
>>>>>
>>>>> "STLport is an open source product and does not guarantee 
>>>>> compatibility across different releases. In other words, compiling 
>>>>> with a future version of STLport may break applications compiled 
>>>>> with STLport 4.5.3. It also might not be possible to link binaries 
>>>>> compiled using STLport 4.5.3 with binaries compiled using a future 
>>>>> version of STLport."
>>>>>
>>>>> "Future releases of the compiler might not include STLport4. They 
>>>>> might include only a later version of STLport. The compiler option 
>>>>> -library=stlport4 might not be available in future releases, but 
>>>>> could be replaced by an option referring to a later STLport version."
>>>>>
>>>>> None of that sounds very good to me.
>>>>
>>>> I don't see how this is any different from any other part of the
>>>> process for using a different version of Solaris Studio.
>>>
>>> Well we'd discover the problem when testing the compiler change, but 
>>> my point was more to the fact that they don't seem very committed to 
>>> this library - very much a "use at own risk" disclaimer.
>>
>> If we eventually need to use something more modern for features that 
>> have not been around for a decade, like C++11 features, then we can 
>> change standard library when that day comes.
>>
>>>
>>>> stlport4 is one of the three standard libraries that are presently
>>>> included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
>>>> Studio folks which to use (for the purposes of our present project, we
>>>> don't have any particular preference, so long as it works), and
>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>> including linking against it, for gtest builds.  Mixing two different
>>>> standard libraries seems like a bad idea...
>>>
>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>
>>> My confidence in this has not increased :)
>>
>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard 
>> libraries has more mileage than whatever simplified rewrite of that 
>> we try to replicate in the JVM. So it is not obvious to me that we 
>> should have less confidence in the same functionality from a standard 
>> library shipped together with the compiler we are using and that has 
>> already been used and tested in a variety of C++ applications for 
>> over a decade compared to the alternative of reinventing it ourselves.
>>
>>> What we do in gtest doesn't necessarily make things okay to do in 
>>> the product.
>>>
>>> If this were part of a compiler upgrade process we'd be comparing 
>>> binaries with old flag and new to ensure there are no unexpected 
>>> consequences.
>>
>> I would not compare including <limits> to a compiler upgrade process 
>> as we are not changing the compiler and hence not the way code is 
>> generated, but rather compare it to including a new system header 
>> that has previously not been included to use a constant folded 
>> expression from that header that has been used and tested for a 
>> decade. At least that is how I think of it.
>>
>> Thanks,
>> /Erik
>>
>>>
>>> Cheers,
>>> David
>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>
>>>>>> Webrev for jdk10-hs top level repository:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>> Testing: JPRT.
>>>>>> Will need a sponsor.
>>>>>> Thanks,
>>>>>> /Erik
>>>>
>>>>
>>



From magnus.ihse.bursie at oracle.com  Thu Jun  1 16:06:58 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 1 Jun 2017 18:06:58 +0200
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <6e907018-c1f0-cc0d-434c-3bc0fec29953@Oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 <e8e26648-4c90-cfe0-5c04-f2db6c842105@Oracle.com>
 <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>
 <fcef5712-dbb1-cde9-00d4-cb95ae99fdbe@Oracle.com>
 <083ba29d-d386-3d33-a729-303378140834@oracle.com>
 <6e907018-c1f0-cc0d-434c-3bc0fec29953@Oracle.com>
Message-ID: <3C814C92-61C5-4343-84B3-7700EEB0B67A@oracle.com>

Looks good!

/Magnus

> 1 juni 2017 kl. 16:23 skrev Roger Riggs <Roger.Riggs at Oracle.com>:
> 
> Thanks,
> 
> Webrev updated in place.
>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
> 
> Roger
> 
>> On 6/1/2017 9:46 AM, Magnus Ihse Bursie wrote:
>> 
>> 
>>> On 2017-06-01 15:29, Roger Riggs wrote: 
>>> Ping on the build change please
>> 
>> Just remove the entire "--doclint-format html4" instead, --doclint-format html5 is default and just overridden for java.base. (Basically revert CompileJavaModules.gmk to what it was just a while ago :-)). 
>> 
>> /Magnus 
>> 
>>> 
>>> 
>>>> On 5/31/2017 10:43 AM, Alan Bateman wrote: 
>>>> On 31/05/2017 15:34, Roger Riggs wrote: 
>>>> 
>>>>> Please review javadoc markup change to update to html5 acceptable to doclint. 
>>>>> The table formatting is updated to html5 markup. 
>>>>> 
>>>>> The Docs build is updated to require doclint html5. 
>>>>> 
>>>>> Webrev: 
>>>>>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/ 
>>>>>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
>>>> Some of the lines are way too long now and will means lots of horizontal scrolling when looking at diffs in the future. Can these be cleaned up before these changes are pushed? 
>>>> 
>>>> -Alan
> 


From david.holmes at oracle.com  Fri Jun  2 01:30:11 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Jun 2017 11:30:11 +1000
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <593029CB.7000100@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
Message-ID: <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>

Hi Erik,

On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
> Hi David,
> 
> On 2017-06-01 14:33, David Holmes wrote:
>> Hi Erik,
>>
>> Just to be clear it is not the use of <limits> that I am concerned 
>> about, it is the -library=stlport4. It is the use of that flag that I 
>> would want to check in terms of having no affect on any existing code 
>> generation.
> 
> Thank you for the clarification. The use of -library=stlport4 should not 
> have anything to do with code generation. It only says where to look for 
> the standard library headers such as <limits> that are used in the 
> compilation units.

The potential problem is that the stlport4 include path eg:

./SS12u4/lib/compilers/include/CC/stlport4/

doesn't only contain the C++ headers (new, limits, string etc) but also 
a whole bunch of regular 'standard' .h headers that are _different_ to 
those found outside the stlport4 directory ie the ones we would 
currently include. I don't know if the differences are significant, nor 
whether those others may be found ahead of the stlport4 version. But 
that is my concern about the effects on the code.

Thanks,
David
-----


> Specifically, the man pages for CC say:
> 
> <man>
>         -library=lib[,lib...]
> 
>             Incorporates  specified  CC-provided libraries into 
> compilation and
>             linking.
> 
>             When the -library option is used to specify a CC-provided 
> library,
>             the  proper  -I paths are set during compilation and the 
> proper -L,
>             -Y, -P, and -R paths and -l options are set during linking.
> </man>
> 
> As we are setting this during compilation and not during linking, this 
> corresponds to setting the right -I paths to find our C++ standard 
> library headers.
> 
> My studio friends mentioned I could double-check that we did indeed not 
> add a dependency to any C++ standard library by running elfdump on the 
> generated libjvm.so file and check if the NEEDED entries in the dynamic 
> section look right. I did and here are the results:
> 
>        [0]  NEEDED          0x2918ee   libsocket.so.1
>        [1]  NEEDED          0x2918fd   libsched.so.1
>        [2]  NEEDED          0x29190b   libdl.so.1
>        [3]  NEEDED          0x291916   libm.so.1
>        [4]  NEEDED          0x291920   libCrun.so.1
>        [5]  NEEDED          0x29192d   libthread.so.1
>        [6]  NEEDED          0x29193c   libdoor.so.1
>        [7]  NEEDED          0x291949   libc.so.1
>        [8]  NEEDED          0x291953   libdemangle.so.1
>        [9]  NEEDED          0x291964   libnsl.so.1
>       [10]  NEEDED          0x291970   libkstat.so.1
>       [11]  NEEDED          0x29197e   librt.so.1
> 
> This list does not include any C++ standard libraries, as expected 
> (libCrun is always in there even with -library=%none, and as expected no 
> libstlport4.so or libCstd.so files are in there). The NEEDED entries in 
> the dynamic section look identical with and without my patch.
> 
>> I'm finding the actual build situation very confusing. It seems to me 
>> in looking at the hotspot build files and the top-level build files 
>> that -xnolib is used for C++ compilation & linking whereas 
>> -library=%none is used for C compilation & linking. But the change is 
>> being applied to $2JVM_CFLAGS which one would think is for C 
>> compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used 
>> for both!
> 
> I have also been confused by this when I tried adding CXX flags through 
> configure that seemed to not be used. But that's a different can of 
> worms I suppose.
> 
> Thanks,
> /Erik
> 
>> David
>>
>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>> Hi David,
>>>
>>> On 2017-06-01 08:09, David Holmes wrote:
>>>> Hi Kim,
>>>>
>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>> On May 31, 2017, at 9:22 PM, David Holmes 
>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>
>>>>>> Hi Erik,
>>>>>>
>>>>>> A small change with big questions :)
>>>>>>
>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>> Hi,
>>>>>>> It would be desirable to be able to use harmless C++ standard 
>>>>>>> library headers like <limits> in the code as long as it does not 
>>>>>>> add any link-time dependencies to the standard library.
>>>>>>
>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>
>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>> only handle poorly) and would not be easy to reproduce.
>>>>
>>>> And how does one establish those properties exist for a given header 
>>>> file? Just use it and if no link errors then all is good?
>>>
>>> Objects from headers that are not ODR-used such as constant folded 
>>> expressions are not imposing link-time dependencies to C++ libraries. 
>>> The -xnolib that we already have in the LDFLAGS will catch any 
>>> accidental ODR-uses of C++ objects, and the JVM will not build if 
>>> that happens.
>>>
>>> As for external headers being included and not playing nicely with 
>>> macros, this has to be evaluated on a case by case basis. Note that 
>>> this is a problem that occurs when using system headers (that we are 
>>> already using), as it is for using C++ standard library headers. We 
>>> even run into that in our own JVM when e.g. the min/max macros 
>>> occasionally slaps us gently in the face from time to time.
>>>
>>>>
>>>>> The instigator for this is Erik and I are working on a project that
>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>> would require platform-specific code (with all the complexity that can
>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>> that is trivially accessible in every standard library.
>>>>
>>>> Understood. I have no issue with using <limits> but am concerned by 
>>>> the state of stlport4. Can you use <limits> without changing 
>>>> -library=%none?
>>>
>>> No, that is precisely why we are here.
>>>
>>>>
>>>>>>> This is possible on all supported platforms except the ones using 
>>>>>>> the solaris studio compiler where we enforce -library=%none in 
>>>>>>> both CFLAGS and LDFLAGS.
>>>>>>> I propose to remove the restriction from CFLAGS but keep it on 
>>>>>>> LDFLAGS.
>>>>>>> I have consulted with the studio folks, and they think this is 
>>>>>>> absolutely fine and thought that the choice of -library=stlport4 
>>>>>>> should be fine for our CFLAGS and is indeed what is already used 
>>>>>>> in the gtest launcher.
>>>>>>
>>>>>> So what exactly does this mean? IIUC this allows you to use 
>>>>>> headers for, and compile against "STLport?s Standard Library 
>>>>>> implementation version 4.5.3 instead of the default libCstd". But 
>>>>>> how do you then not need to link against libstlport.so ??
>>>>>>
>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>
>>>>>> "STLport is binary incompatible with the default libCstd. If you 
>>>>>> use the STLport implementation of the standard library, then you 
>>>>>> must compile and link all files, including third-party libraries, 
>>>>>> with the option -library=stlport4?
>>>>>
>>>>> It means we can only use header-only parts of the standard library.
>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>> providing such limited access while continuing to constrain our
>>>>> dependency on the library.  Figuring out what can be used will need to
>>>>> be determined on a case-by-case basis.  Maybe we could just link with
>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>> conservative.
>>>>
>>>> Okay, but the docs don't seem to acknowledge the ability to use, but 
>>>> not link to, stlport4.
>>>
>>> Not ODR-used objects do not require linkage. 
>>> (http://en.cppreference.com/w/cpp/language/definition)
>>> I have confirmed directly with the studio folks to be certain that 
>>> accidental linkage would fail by keeping our existing guards in the 
>>> LDFLAGS rather than the CFLAGS.
>>> This is also reasonably well documented already 
>>> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>
>>>>
>>>>>> There are lots of other comments in that document regarding 
>>>>>> STLport that makes me think that using it may be introducing a 
>>>>>> fragile dependency into the OpenJDK code!
>>>>>>
>>>>>> "STLport is an open source product and does not guarantee 
>>>>>> compatibility across different releases. In other words, compiling 
>>>>>> with a future version of STLport may break applications compiled 
>>>>>> with STLport 4.5.3. It also might not be possible to link binaries 
>>>>>> compiled using STLport 4.5.3 with binaries compiled using a future 
>>>>>> version of STLport."
>>>>>>
>>>>>> "Future releases of the compiler might not include STLport4. They 
>>>>>> might include only a later version of STLport. The compiler option 
>>>>>> -library=stlport4 might not be available in future releases, but 
>>>>>> could be replaced by an option referring to a later STLport version."
>>>>>>
>>>>>> None of that sounds very good to me.
>>>>>
>>>>> I don't see how this is any different from any other part of the
>>>>> process for using a different version of Solaris Studio.
>>>>
>>>> Well we'd discover the problem when testing the compiler change, but 
>>>> my point was more to the fact that they don't seem very committed to 
>>>> this library - very much a "use at own risk" disclaimer.
>>>
>>> If we eventually need to use something more modern for features that 
>>> have not been around for a decade, like C++11 features, then we can 
>>> change standard library when that day comes.
>>>
>>>>
>>>>> stlport4 is one of the three standard libraries that are presently
>>>>> included with Solaris Studio (libCstd, stlport4, gcc).  Erik asked the
>>>>> Studio folks which to use (for the purposes of our present project, we
>>>>> don't have any particular preference, so long as it works), and
>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>> including linking against it, for gtest builds.  Mixing two different
>>>>> standard libraries seems like a bad idea...
>>>>
>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>
>>>> My confidence in this has not increased :)
>>>
>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard 
>>> libraries has more mileage than whatever simplified rewrite of that 
>>> we try to replicate in the JVM. So it is not obvious to me that we 
>>> should have less confidence in the same functionality from a standard 
>>> library shipped together with the compiler we are using and that has 
>>> already been used and tested in a variety of C++ applications for 
>>> over a decade compared to the alternative of reinventing it ourselves.
>>>
>>>> What we do in gtest doesn't necessarily make things okay to do in 
>>>> the product.
>>>>
>>>> If this were part of a compiler upgrade process we'd be comparing 
>>>> binaries with old flag and new to ensure there are no unexpected 
>>>> consequences.
>>>
>>> I would not compare including <limits> to a compiler upgrade process 
>>> as we are not changing the compiler and hence not the way code is 
>>> generated, but rather compare it to including a new system header 
>>> that has previously not been included to use a constant folded 
>>> expression from that header that has been used and tested for a 
>>> decade. At least that is how I think of it.
>>>
>>> Thanks,
>>> /Erik
>>>
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>> Testing: JPRT.
>>>>>>> Will need a sponsor.
>>>>>>> Thanks,
>>>>>>> /Erik
>>>>>
>>>>>
>>>
> 


From david.holmes at oracle.com  Fri Jun  2 01:44:43 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Jun 2017 11:44:43 +1000
Subject: RFR: JDK-8180322 Move JNI spec to specs directory
In-Reply-To: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>
References: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>
Message-ID: <97f865ed-dd01-4851-87d4-0047621da5ea@oracle.com>

Hi Magnus,

Serviceability owns the jvmti.xml file, so cc'd.

The changes to externalink seem okay (I assume the GetEnv -> getenv 
change is not significant?).

The patch file seems to contain a bazillion whitespace changes so you 
might want to check what is going on there.

Thanks,
David

On 1/06/2017 10:46 PM, Magnus Ihse Bursie wrote:
> The JNI spec will move to a new place in the "specs" directory in the 
> docs image, and links to it needs to be updated.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180322
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180322-move-jni-spec/webrev.01
> 
> This is a noreg-docs fix and will be pushed to jdk9.
> 
> /Magnus


From mandy.chung at oracle.com  Fri Jun  2 01:50:34 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 1 Jun 2017 18:50:34 -0700
Subject: RFR: JDK-8180322 Move JNI spec to specs directory
In-Reply-To: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>
References: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>
Message-ID: <D887C3BB-9F2A-4484-B027-D7110C9D2457@oracle.com>


> On Jun 1, 2017, at 5:46 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> The JNI spec will move to a new place in the "specs" directory in the docs image, and links to it needs to be updated.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180322
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180322-move-jni-spec/webrev.01
> 
> This is a noreg-docs fix and will be pushed to jdk9.

Looks okay to me.

Mandy

From magnus.ihse.bursie at oracle.com  Fri Jun  2 09:50:18 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 2 Jun 2017 11:50:18 +0200
Subject: RFR: JDK-8180322 Move JNI spec to specs directory
In-Reply-To: <97f865ed-dd01-4851-87d4-0047621da5ea@oracle.com>
References: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>
 <97f865ed-dd01-4851-87d4-0047621da5ea@oracle.com>
Message-ID: <779DF8A7-C5AA-4237-836A-4737E578BDFA@oracle.com>


> 2 juni 2017 kl. 03:44 skrev David Holmes <david.holmes at oracle.com>:
> 
> Hi Magnus,
> 
> Serviceability owns the jvmti.xml file, so cc'd.
> 
> The changes to externalink seem okay (I assume the GetEnv -> getenv change is not significant?).

It matches the changes in the source document. 

> 
> The patch file seems to contain a bazillion whitespace changes so you might want to check what is going on there.

Those were trailing whitespaces. Unfortunately, jcheck only enforces the "no trailing whitespaces" rule for certain file types (or technically extensions), and .xml is not one of them (and neither is .gmk :-(). I have instructed my editor to remove trailing whitespaces always, and sometimes this means a patch gets lots of whitespace cleanup. 

/Magnus

> 
> Thanks,
> David
> 
>> On 1/06/2017 10:46 PM, Magnus Ihse Bursie wrote:
>> The JNI spec will move to a new place in the "specs" directory in the docs image, and links to it needs to be updated.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180322
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180322-move-jni-spec/webrev.01
>> This is a noreg-docs fix and will be pushed to jdk9.
>> /Magnus



From magnus.ihse.bursie at oracle.com  Fri Jun  2 13:03:00 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 2 Jun 2017 15:03:00 +0200
Subject: RFR: JDK-8180300 Move JDWP specs to specs directory
Message-ID: <8c99cf2c-f00b-98ef-9389-c45dfb982411@oracle.com>

The JDWP spec will move to a new place in the "specs" directory in the 
docs image, and links to it needs to be updated.

Bug: https://bugs.openjdk.java.net/browse/JDK-8180300
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8180300-move-jdwp-spec/webrev.01

This is a noreg-docs fix and will be pushed to jdk9.

/Magnus


From serguei.spitsyn at oracle.com  Fri Jun  2 20:42:44 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 2 Jun 2017 13:42:44 -0700
Subject: RFR: JDK-8180300 Move JDWP specs to specs directory
In-Reply-To: <8c99cf2c-f00b-98ef-9389-c45dfb982411@oracle.com>
References: <8c99cf2c-f00b-98ef-9389-c45dfb982411@oracle.com>
Message-ID: <74890c96-8aae-14d2-e01f-9451ed0fc592@oracle.com>

Magnus,

I've included the serviceability mailing list.
Thank you for catching these links!

But these two files are not the only fixes for this sub-task, right?
Should this webrev include your new markdown files as well?

Thanks,
Serguei



On 6/2/17 06:03, Magnus Ihse Bursie wrote:
> The JDWP spec will move to a new place in the "specs" directory in the 
> docs image, and links to it needs to be updated.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180300
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8180300-move-jdwp-spec/webrev.01
>
> This is a noreg-docs fix and will be pushed to jdk9.
>
> /Magnus



From serguei.spitsyn at oracle.com  Fri Jun  2 21:26:17 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 2 Jun 2017 14:26:17 -0700
Subject: RFR: JDK-8180322 Move JNI spec to specs directory
In-Reply-To: <D887C3BB-9F2A-4484-B027-D7110C9D2457@oracle.com>
References: <f42d4796-1ca5-cd3e-8c68-7df4c7ea30c5@oracle.com>
 <D887C3BB-9F2A-4484-B027-D7110C9D2457@oracle.com>
Message-ID: <7831d6bb-7e25-0886-f34d-052d2e2258b3@oracle.com>

On 6/1/17 18:50, Mandy Chung wrote:
>> On Jun 1, 2017, at 5:46 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> The JNI spec will move to a new place in the "specs" directory in the docs image, and links to it needs to be updated.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180322
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8180322-move-jni-spec/webrev.01
>>
>> This is a noreg-docs fix and will be pushed to jdk9.
> Looks okay to me.

+1

Thanks,
Serguei

>
> Mandy



From erik.osterlund at oracle.com  Mon Jun  5 10:38:53 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 5 Jun 2017 12:38:53 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
Message-ID: <593534BD.1090805@oracle.com>

Hi David,

On 2017-06-02 03:30, David Holmes wrote:
> Hi Erik,
>
> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>> Hi David,
>>
>> On 2017-06-01 14:33, David Holmes wrote:
>>> Hi Erik,
>>>
>>> Just to be clear it is not the use of <limits> that I am concerned 
>>> about, it is the -library=stlport4. It is the use of that flag that 
>>> I would want to check in terms of having no affect on any existing 
>>> code generation.
>>
>> Thank you for the clarification. The use of -library=stlport4 should 
>> not have anything to do with code generation. It only says where to 
>> look for the standard library headers such as <limits> that are used 
>> in the compilation units.
>
> The potential problem is that the stlport4 include path eg:
>
> ./SS12u4/lib/compilers/include/CC/stlport4/
>
> doesn't only contain the C++ headers (new, limits, string etc) but 
> also a whole bunch of regular 'standard' .h headers that are 
> _different_ to those found outside the stlport4 directory ie the ones 
> we would currently include. I don't know if the differences are 
> significant, nor whether those others may be found ahead of the 
> stlport4 version. But that is my concern about the effects on the code.

While I do not think exchanging these headers will have any behavioral 
impact, I agree that we can not prove so as they are indeed different 
header files. That is a good point.

However, I think that makes the stlport4 case stronger rather than 
weaker. We already use stlport4 for our gtest testing (because it is 
required and does not build without it). And if those headers would 
indeed have slightly different behaviour as you imply, it further 
motivates using the same standard library when compiling the product as 
the testing code. If they were to behave slightly differently, it might 
be that our gtest tests does not catch hidden bugs that only manifest 
when building with a different set of headers used for the product 
build. I therefore find it exceedingly dangerous to stay on two standard 
libraries (depending on if test code or product code is compiled) 
compared to consistently using the same standard library across all 
compilations. So for me, the larger the risk is of them behaving 
differently is, the bigger the motivation is to use stlport4 consistently.

Thanks,
/Erik

> Thanks,
> David
> -----
>
>
>> Specifically, the man pages for CC say:
>>
>> <man>
>>         -library=lib[,lib...]
>>
>>             Incorporates  specified  CC-provided libraries into 
>> compilation and
>>             linking.
>>
>>             When the -library option is used to specify a CC-provided 
>> library,
>>             the  proper  -I paths are set during compilation and the 
>> proper -L,
>>             -Y, -P, and -R paths and -l options are set during linking.
>> </man>
>>
>> As we are setting this during compilation and not during linking, 
>> this corresponds to setting the right -I paths to find our C++ 
>> standard library headers.
>>
>> My studio friends mentioned I could double-check that we did indeed 
>> not add a dependency to any C++ standard library by running elfdump 
>> on the generated libjvm.so file and check if the NEEDED entries in 
>> the dynamic section look right. I did and here are the results:
>>
>>        [0]  NEEDED          0x2918ee   libsocket.so.1
>>        [1]  NEEDED          0x2918fd   libsched.so.1
>>        [2]  NEEDED          0x29190b   libdl.so.1
>>        [3]  NEEDED          0x291916   libm.so.1
>>        [4]  NEEDED          0x291920   libCrun.so.1
>>        [5]  NEEDED          0x29192d   libthread.so.1
>>        [6]  NEEDED          0x29193c   libdoor.so.1
>>        [7]  NEEDED          0x291949   libc.so.1
>>        [8]  NEEDED          0x291953   libdemangle.so.1
>>        [9]  NEEDED          0x291964   libnsl.so.1
>>       [10]  NEEDED          0x291970   libkstat.so.1
>>       [11]  NEEDED          0x29197e   librt.so.1
>>
>> This list does not include any C++ standard libraries, as expected 
>> (libCrun is always in there even with -library=%none, and as expected 
>> no libstlport4.so or libCstd.so files are in there). The NEEDED 
>> entries in the dynamic section look identical with and without my patch.
>>
>>> I'm finding the actual build situation very confusing. It seems to 
>>> me in looking at the hotspot build files and the top-level build 
>>> files that -xnolib is used for C++ compilation & linking whereas 
>>> -library=%none is used for C compilation & linking. But the change 
>>> is being applied to $2JVM_CFLAGS which one would think is for C 
>>> compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used 
>>> for both!
>>
>> I have also been confused by this when I tried adding CXX flags 
>> through configure that seemed to not be used. But that's a different 
>> can of worms I suppose.
>>
>> Thanks,
>> /Erik
>>
>>> David
>>>
>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>> Hi David,
>>>>
>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>> Hi Kim,
>>>>>
>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes 
>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> A small change with big questions :)
>>>>>>>
>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>> Hi,
>>>>>>>> It would be desirable to be able to use harmless C++ standard 
>>>>>>>> library headers like <limits> in the code as long as it does 
>>>>>>>> not add any link-time dependencies to the standard library.
>>>>>>>
>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>
>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>
>>>>> And how does one establish those properties exist for a given 
>>>>> header file? Just use it and if no link errors then all is good?
>>>>
>>>> Objects from headers that are not ODR-used such as constant folded 
>>>> expressions are not imposing link-time dependencies to C++ 
>>>> libraries. The -xnolib that we already have in the LDFLAGS will 
>>>> catch any accidental ODR-uses of C++ objects, and the JVM will not 
>>>> build if that happens.
>>>>
>>>> As for external headers being included and not playing nicely with 
>>>> macros, this has to be evaluated on a case by case basis. Note that 
>>>> this is a problem that occurs when using system headers (that we 
>>>> are already using), as it is for using C++ standard library 
>>>> headers. We even run into that in our own JVM when e.g. the min/max 
>>>> macros occasionally slaps us gently in the face from time to time.
>>>>
>>>>>
>>>>>> The instigator for this is Erik and I are working on a project that
>>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>> would require platform-specific code (with all the complexity 
>>>>>> that can
>>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>>> that is trivially accessible in every standard library.
>>>>>
>>>>> Understood. I have no issue with using <limits> but am concerned 
>>>>> by the state of stlport4. Can you use <limits> without changing 
>>>>> -library=%none?
>>>>
>>>> No, that is precisely why we are here.
>>>>
>>>>>
>>>>>>>> This is possible on all supported platforms except the ones 
>>>>>>>> using the solaris studio compiler where we enforce 
>>>>>>>> -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>> I propose to remove the restriction from CFLAGS but keep it on 
>>>>>>>> LDFLAGS.
>>>>>>>> I have consulted with the studio folks, and they think this is 
>>>>>>>> absolutely fine and thought that the choice of 
>>>>>>>> -library=stlport4 should be fine for our CFLAGS and is indeed 
>>>>>>>> what is already used in the gtest launcher.
>>>>>>>
>>>>>>> So what exactly does this mean? IIUC this allows you to use 
>>>>>>> headers for, and compile against "STLport?s Standard Library 
>>>>>>> implementation version 4.5.3 instead of the default libCstd". 
>>>>>>> But how do you then not need to link against libstlport.so ??
>>>>>>>
>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>
>>>>>>> "STLport is binary incompatible with the default libCstd. If you 
>>>>>>> use the STLport implementation of the standard library, then you 
>>>>>>> must compile and link all files, including third-party 
>>>>>>> libraries, with the option -library=stlport4?
>>>>>>
>>>>>> It means we can only use header-only parts of the standard library.
>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>> providing such limited access while continuing to constrain our
>>>>>> dependency on the library.  Figuring out what can be used will 
>>>>>> need to
>>>>>> be determined on a case-by-case basis.  Maybe we could just link 
>>>>>> with
>>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>>> conservative.
>>>>>
>>>>> Okay, but the docs don't seem to acknowledge the ability to use, 
>>>>> but not link to, stlport4.
>>>>
>>>> Not ODR-used objects do not require linkage. 
>>>> (http://en.cppreference.com/w/cpp/language/definition)
>>>> I have confirmed directly with the studio folks to be certain that 
>>>> accidental linkage would fail by keeping our existing guards in the 
>>>> LDFLAGS rather than the CFLAGS.
>>>> This is also reasonably well documented already 
>>>> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>
>>>>>
>>>>>>> There are lots of other comments in that document regarding 
>>>>>>> STLport that makes me think that using it may be introducing a 
>>>>>>> fragile dependency into the OpenJDK code!
>>>>>>>
>>>>>>> "STLport is an open source product and does not guarantee 
>>>>>>> compatibility across different releases. In other words, 
>>>>>>> compiling with a future version of STLport may break 
>>>>>>> applications compiled with STLport 4.5.3. It also might not be 
>>>>>>> possible to link binaries compiled using STLport 4.5.3 with 
>>>>>>> binaries compiled using a future version of STLport."
>>>>>>>
>>>>>>> "Future releases of the compiler might not include STLport4. 
>>>>>>> They might include only a later version of STLport. The compiler 
>>>>>>> option -library=stlport4 might not be available in future 
>>>>>>> releases, but could be replaced by an option referring to a 
>>>>>>> later STLport version."
>>>>>>>
>>>>>>> None of that sounds very good to me.
>>>>>>
>>>>>> I don't see how this is any different from any other part of the
>>>>>> process for using a different version of Solaris Studio.
>>>>>
>>>>> Well we'd discover the problem when testing the compiler change, 
>>>>> but my point was more to the fact that they don't seem very 
>>>>> committed to this library - very much a "use at own risk" disclaimer.
>>>>
>>>> If we eventually need to use something more modern for features 
>>>> that have not been around for a decade, like C++11 features, then 
>>>> we can change standard library when that day comes.
>>>>
>>>>>
>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked 
>>>>>> the
>>>>>> Studio folks which to use (for the purposes of our present 
>>>>>> project, we
>>>>>> don't have any particular preference, so long as it works), and
>>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>> including linking against it, for gtest builds.  Mixing two 
>>>>>> different
>>>>>> standard libraries seems like a bad idea...
>>>>>
>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>
>>>>> My confidence in this has not increased :)
>>>>
>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard 
>>>> libraries has more mileage than whatever simplified rewrite of that 
>>>> we try to replicate in the JVM. So it is not obvious to me that we 
>>>> should have less confidence in the same functionality from a 
>>>> standard library shipped together with the compiler we are using 
>>>> and that has already been used and tested in a variety of C++ 
>>>> applications for over a decade compared to the alternative of 
>>>> reinventing it ourselves.
>>>>
>>>>> What we do in gtest doesn't necessarily make things okay to do in 
>>>>> the product.
>>>>>
>>>>> If this were part of a compiler upgrade process we'd be comparing 
>>>>> binaries with old flag and new to ensure there are no unexpected 
>>>>> consequences.
>>>>
>>>> I would not compare including <limits> to a compiler upgrade 
>>>> process as we are not changing the compiler and hence not the way 
>>>> code is generated, but rather compare it to including a new system 
>>>> header that has previously not been included to use a constant 
>>>> folded expression from that header that has been used and tested 
>>>> for a decade. At least that is how I think of it.
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>> Testing: JPRT.
>>>>>>>> Will need a sponsor.
>>>>>>>> Thanks,
>>>>>>>> /Erik
>>>>>>
>>>>>>
>>>>
>>



From david.holmes at oracle.com  Mon Jun  5 12:45:52 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 5 Jun 2017 22:45:52 +1000
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <593534BD.1090805@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
Message-ID: <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>

Hi Erik,

On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
> Hi David,
> 
> On 2017-06-02 03:30, David Holmes wrote:
>> Hi Erik,
>>
>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>> Hi David,
>>>
>>> On 2017-06-01 14:33, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>> Just to be clear it is not the use of <limits> that I am concerned 
>>>> about, it is the -library=stlport4. It is the use of that flag that 
>>>> I would want to check in terms of having no affect on any existing 
>>>> code generation.
>>>
>>> Thank you for the clarification. The use of -library=stlport4 should 
>>> not have anything to do with code generation. It only says where to 
>>> look for the standard library headers such as <limits> that are used 
>>> in the compilation units.
>>
>> The potential problem is that the stlport4 include path eg:
>>
>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>
>> doesn't only contain the C++ headers (new, limits, string etc) but 
>> also a whole bunch of regular 'standard' .h headers that are 
>> _different_ to those found outside the stlport4 directory ie the ones 
>> we would currently include. I don't know if the differences are 
>> significant, nor whether those others may be found ahead of the 
>> stlport4 version. But that is my concern about the effects on the code.
> 
> While I do not think exchanging these headers will have any behavioral 
> impact, I agree that we can not prove so as they are indeed different 
> header files. That is a good point.
> 
> However, I think that makes the stlport4 case stronger rather than 
> weaker. We already use stlport4 for our gtest testing (because it is 
> required and does not build without it). And if those headers would 
> indeed have slightly different behaviour as you imply, it further 
> motivates using the same standard library when compiling the product as 
> the testing code. If they were to behave slightly differently, it might 
> be that our gtest tests does not catch hidden bugs that only manifest 
> when building with a different set of headers used for the product 
> build. I therefore find it exceedingly dangerous to stay on two standard 
> libraries (depending on if test code or product code is compiled) 
> compared to consistently using the same standard library across all 
> compilations. So for me, the larger the risk is of them behaving 
> differently is, the bigger the motivation is to use stlport4 consistently.

Regardless of what gtest does if you want to switch the standard 
libraries used by the product then IMHO that should go through a vetting 
process no weaker than that for changing the toolchain, as you 
effectively are doing that.

Cheers,
David


> Thanks,
> /Erik
> 
>> Thanks,
>> David
>> -----
>>
>>
>>> Specifically, the man pages for CC say:
>>>
>>> <man>
>>>         -library=lib[,lib...]
>>>
>>>             Incorporates  specified  CC-provided libraries into 
>>> compilation and
>>>             linking.
>>>
>>>             When the -library option is used to specify a CC-provided 
>>> library,
>>>             the  proper  -I paths are set during compilation and the 
>>> proper -L,
>>>             -Y, -P, and -R paths and -l options are set during linking.
>>> </man>
>>>
>>> As we are setting this during compilation and not during linking, 
>>> this corresponds to setting the right -I paths to find our C++ 
>>> standard library headers.
>>>
>>> My studio friends mentioned I could double-check that we did indeed 
>>> not add a dependency to any C++ standard library by running elfdump 
>>> on the generated libjvm.so file and check if the NEEDED entries in 
>>> the dynamic section look right. I did and here are the results:
>>>
>>>        [0]  NEEDED          0x2918ee   libsocket.so.1
>>>        [1]  NEEDED          0x2918fd   libsched.so.1
>>>        [2]  NEEDED          0x29190b   libdl.so.1
>>>        [3]  NEEDED          0x291916   libm.so.1
>>>        [4]  NEEDED          0x291920   libCrun.so.1
>>>        [5]  NEEDED          0x29192d   libthread.so.1
>>>        [6]  NEEDED          0x29193c   libdoor.so.1
>>>        [7]  NEEDED          0x291949   libc.so.1
>>>        [8]  NEEDED          0x291953   libdemangle.so.1
>>>        [9]  NEEDED          0x291964   libnsl.so.1
>>>       [10]  NEEDED          0x291970   libkstat.so.1
>>>       [11]  NEEDED          0x29197e   librt.so.1
>>>
>>> This list does not include any C++ standard libraries, as expected 
>>> (libCrun is always in there even with -library=%none, and as expected 
>>> no libstlport4.so or libCstd.so files are in there). The NEEDED 
>>> entries in the dynamic section look identical with and without my patch.
>>>
>>>> I'm finding the actual build situation very confusing. It seems to 
>>>> me in looking at the hotspot build files and the top-level build 
>>>> files that -xnolib is used for C++ compilation & linking whereas 
>>>> -library=%none is used for C compilation & linking. But the change 
>>>> is being applied to $2JVM_CFLAGS which one would think is for C 
>>>> compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used 
>>>> for both!
>>>
>>> I have also been confused by this when I tried adding CXX flags 
>>> through configure that seemed to not be used. But that's a different 
>>> can of worms I suppose.
>>>
>>> Thanks,
>>> /Erik
>>>
>>>> David
>>>>
>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>> Hi David,
>>>>>
>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>> Hi Kim,
>>>>>>
>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes 
>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Erik,
>>>>>>>>
>>>>>>>> A small change with big questions :)
>>>>>>>>
>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>> Hi,
>>>>>>>>> It would be desirable to be able to use harmless C++ standard 
>>>>>>>>> library headers like <limits> in the code as long as it does 
>>>>>>>>> not add any link-time dependencies to the standard library.
>>>>>>>>
>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>
>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>
>>>>>> And how does one establish those properties exist for a given 
>>>>>> header file? Just use it and if no link errors then all is good?
>>>>>
>>>>> Objects from headers that are not ODR-used such as constant folded 
>>>>> expressions are not imposing link-time dependencies to C++ 
>>>>> libraries. The -xnolib that we already have in the LDFLAGS will 
>>>>> catch any accidental ODR-uses of C++ objects, and the JVM will not 
>>>>> build if that happens.
>>>>>
>>>>> As for external headers being included and not playing nicely with 
>>>>> macros, this has to be evaluated on a case by case basis. Note that 
>>>>> this is a problem that occurs when using system headers (that we 
>>>>> are already using), as it is for using C++ standard library 
>>>>> headers. We even run into that in our own JVM when e.g. the min/max 
>>>>> macros occasionally slaps us gently in the face from time to time.
>>>>>
>>>>>>
>>>>>>> The instigator for this is Erik and I are working on a project that
>>>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>>> would require platform-specific code (with all the complexity 
>>>>>>> that can
>>>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>>>> that is trivially accessible in every standard library.
>>>>>>
>>>>>> Understood. I have no issue with using <limits> but am concerned 
>>>>>> by the state of stlport4. Can you use <limits> without changing 
>>>>>> -library=%none?
>>>>>
>>>>> No, that is precisely why we are here.
>>>>>
>>>>>>
>>>>>>>>> This is possible on all supported platforms except the ones 
>>>>>>>>> using the solaris studio compiler where we enforce 
>>>>>>>>> -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it on 
>>>>>>>>> LDFLAGS.
>>>>>>>>> I have consulted with the studio folks, and they think this is 
>>>>>>>>> absolutely fine and thought that the choice of 
>>>>>>>>> -library=stlport4 should be fine for our CFLAGS and is indeed 
>>>>>>>>> what is already used in the gtest launcher.
>>>>>>>>
>>>>>>>> So what exactly does this mean? IIUC this allows you to use 
>>>>>>>> headers for, and compile against "STLport?s Standard Library 
>>>>>>>> implementation version 4.5.3 instead of the default libCstd". 
>>>>>>>> But how do you then not need to link against libstlport.so ??
>>>>>>>>
>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>
>>>>>>>> "STLport is binary incompatible with the default libCstd. If you 
>>>>>>>> use the STLport implementation of the standard library, then you 
>>>>>>>> must compile and link all files, including third-party 
>>>>>>>> libraries, with the option -library=stlport4?
>>>>>>>
>>>>>>> It means we can only use header-only parts of the standard library.
>>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>>> providing such limited access while continuing to constrain our
>>>>>>> dependency on the library.  Figuring out what can be used will 
>>>>>>> need to
>>>>>>> be determined on a case-by-case basis.  Maybe we could just link 
>>>>>>> with
>>>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>>>> conservative.
>>>>>>
>>>>>> Okay, but the docs don't seem to acknowledge the ability to use, 
>>>>>> but not link to, stlport4.
>>>>>
>>>>> Not ODR-used objects do not require linkage. 
>>>>> (http://en.cppreference.com/w/cpp/language/definition)
>>>>> I have confirmed directly with the studio folks to be certain that 
>>>>> accidental linkage would fail by keeping our existing guards in the 
>>>>> LDFLAGS rather than the CFLAGS.
>>>>> This is also reasonably well documented already 
>>>>> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>
>>>>>>
>>>>>>>> There are lots of other comments in that document regarding 
>>>>>>>> STLport that makes me think that using it may be introducing a 
>>>>>>>> fragile dependency into the OpenJDK code!
>>>>>>>>
>>>>>>>> "STLport is an open source product and does not guarantee 
>>>>>>>> compatibility across different releases. In other words, 
>>>>>>>> compiling with a future version of STLport may break 
>>>>>>>> applications compiled with STLport 4.5.3. It also might not be 
>>>>>>>> possible to link binaries compiled using STLport 4.5.3 with 
>>>>>>>> binaries compiled using a future version of STLport."
>>>>>>>>
>>>>>>>> "Future releases of the compiler might not include STLport4. 
>>>>>>>> They might include only a later version of STLport. The compiler 
>>>>>>>> option -library=stlport4 might not be available in future 
>>>>>>>> releases, but could be replaced by an option referring to a 
>>>>>>>> later STLport version."
>>>>>>>>
>>>>>>>> None of that sounds very good to me.
>>>>>>>
>>>>>>> I don't see how this is any different from any other part of the
>>>>>>> process for using a different version of Solaris Studio.
>>>>>>
>>>>>> Well we'd discover the problem when testing the compiler change, 
>>>>>> but my point was more to the fact that they don't seem very 
>>>>>> committed to this library - very much a "use at own risk" disclaimer.
>>>>>
>>>>> If we eventually need to use something more modern for features 
>>>>> that have not been around for a decade, like C++11 features, then 
>>>>> we can change standard library when that day comes.
>>>>>
>>>>>>
>>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked 
>>>>>>> the
>>>>>>> Studio folks which to use (for the purposes of our present 
>>>>>>> project, we
>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>> including linking against it, for gtest builds.  Mixing two 
>>>>>>> different
>>>>>>> standard libraries seems like a bad idea...
>>>>>>
>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>
>>>>>> My confidence in this has not increased :)
>>>>>
>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard 
>>>>> libraries has more mileage than whatever simplified rewrite of that 
>>>>> we try to replicate in the JVM. So it is not obvious to me that we 
>>>>> should have less confidence in the same functionality from a 
>>>>> standard library shipped together with the compiler we are using 
>>>>> and that has already been used and tested in a variety of C++ 
>>>>> applications for over a decade compared to the alternative of 
>>>>> reinventing it ourselves.
>>>>>
>>>>>> What we do in gtest doesn't necessarily make things okay to do in 
>>>>>> the product.
>>>>>>
>>>>>> If this were part of a compiler upgrade process we'd be comparing 
>>>>>> binaries with old flag and new to ensure there are no unexpected 
>>>>>> consequences.
>>>>>
>>>>> I would not compare including <limits> to a compiler upgrade 
>>>>> process as we are not changing the compiler and hence not the way 
>>>>> code is generated, but rather compare it to including a new system 
>>>>> header that has previously not been included to use a constant 
>>>>> folded expression from that header that has been used and tested 
>>>>> for a decade. At least that is how I think of it.
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>> Testing: JPRT.
>>>>>>>>> Will need a sponsor.
>>>>>>>>> Thanks,
>>>>>>>>> /Erik
>>>>>>>
>>>>>>>
>>>>>
>>>
> 


From erik.osterlund at oracle.com  Mon Jun  5 16:19:30 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 5 Jun 2017 18:19:30 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
 <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
Message-ID: <59358492.7030803@oracle.com>

Hi David,

On 2017-06-05 14:45, David Holmes wrote:
> Hi Erik,
>
> On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
>> Hi David,
>>
>> On 2017-06-02 03:30, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>>> Hi David,
>>>>
>>>> On 2017-06-01 14:33, David Holmes wrote:
>>>>> Hi Erik,
>>>>>
>>>>> Just to be clear it is not the use of <limits> that I am concerned 
>>>>> about, it is the -library=stlport4. It is the use of that flag 
>>>>> that I would want to check in terms of having no affect on any 
>>>>> existing code generation.
>>>>
>>>> Thank you for the clarification. The use of -library=stlport4 
>>>> should not have anything to do with code generation. It only says 
>>>> where to look for the standard library headers such as <limits> 
>>>> that are used in the compilation units.
>>>
>>> The potential problem is that the stlport4 include path eg:
>>>
>>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>>
>>> doesn't only contain the C++ headers (new, limits, string etc) but 
>>> also a whole bunch of regular 'standard' .h headers that are 
>>> _different_ to those found outside the stlport4 directory ie the 
>>> ones we would currently include. I don't know if the differences are 
>>> significant, nor whether those others may be found ahead of the 
>>> stlport4 version. But that is my concern about the effects on the code.
>>
>> While I do not think exchanging these headers will have any 
>> behavioral impact, I agree that we can not prove so as they are 
>> indeed different header files. That is a good point.
>>
>> However, I think that makes the stlport4 case stronger rather than 
>> weaker. We already use stlport4 for our gtest testing (because it is 
>> required and does not build without it). And if those headers would 
>> indeed have slightly different behaviour as you imply, it further 
>> motivates using the same standard library when compiling the product 
>> as the testing code. If they were to behave slightly differently, it 
>> might be that our gtest tests does not catch hidden bugs that only 
>> manifest when building with a different set of headers used for the 
>> product build. I therefore find it exceedingly dangerous to stay on 
>> two standard libraries (depending on if test code or product code is 
>> compiled) compared to consistently using the same standard library 
>> across all compilations. So for me, the larger the risk is of them 
>> behaving differently is, the bigger the motivation is to use stlport4 
>> consistently.
>
> Regardless of what gtest does if you want to switch the standard 
> libraries used by the product then IMHO that should go through a 
> vetting process no weaker than that for changing the toolchain, as you 
> effectively are doing that.

I talked to Erik Joelsson about how to compare two builds. He introduced 
me to our compare.sh script that is used to compare two builds.
I built a baseline without these changes and a new build with these 
changes applied, both on a Solaris SPARC T7 machine. Then I compared 
them with ./compare.sh -2dirs 
{$BUILD1}/hotspot/variant-server/libjvm/objs 
{$BUILD2}/hotspot/variant-server/libjvm/objs -libs --strip

This compares the object files produced when compiling hotspot in build 
1 and build 2 after stripping symbols.

First it reported:
Libraries...
    Size    : Symbols :  Deps   : Disass   :
            :* diff  *:         :          : ./dtrace.o
            :* diff  *:         :*   38918*: ./jni.o
            :* diff  *:         :*   23226*: ./unsafe.o

It seems like all symbols were not stripped here on these mentioned 
files and constituted all differences in the disassembly. So I made a 
simple sed filter to filter out symbol names in the disassembly with the 
regexp <.*>.

The result was:
Libraries...
    Size    : Symbols :  Deps   : Disass   :
            :* diff  *:         :          : ./dtrace.o
            :* diff  *:         :          : ./jni.o
            :* diff  *:         :          : ./unsafe.o

This shows that not a single instruction was emitted differently between 
the two builds.

I also did the filtering manually on jni.o and unsafe.o in emacs to make 
sure I did not mess up.

Are we happy with this, or do you still have doubts that this might 
result in different code or behavior?

Thanks,
/Erik

> Cheers,
> David
>
>
>> Thanks,
>> /Erik
>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>
>>>> Specifically, the man pages for CC say:
>>>>
>>>> <man>
>>>>         -library=lib[,lib...]
>>>>
>>>>             Incorporates  specified  CC-provided libraries into 
>>>> compilation and
>>>>             linking.
>>>>
>>>>             When the -library option is used to specify a 
>>>> CC-provided library,
>>>>             the  proper  -I paths are set during compilation and 
>>>> the proper -L,
>>>>             -Y, -P, and -R paths and -l options are set during 
>>>> linking.
>>>> </man>
>>>>
>>>> As we are setting this during compilation and not during linking, 
>>>> this corresponds to setting the right -I paths to find our C++ 
>>>> standard library headers.
>>>>
>>>> My studio friends mentioned I could double-check that we did indeed 
>>>> not add a dependency to any C++ standard library by running elfdump 
>>>> on the generated libjvm.so file and check if the NEEDED entries in 
>>>> the dynamic section look right. I did and here are the results:
>>>>
>>>>        [0]  NEEDED          0x2918ee   libsocket.so.1
>>>>        [1]  NEEDED          0x2918fd   libsched.so.1
>>>>        [2]  NEEDED          0x29190b   libdl.so.1
>>>>        [3]  NEEDED          0x291916   libm.so.1
>>>>        [4]  NEEDED          0x291920   libCrun.so.1
>>>>        [5]  NEEDED          0x29192d   libthread.so.1
>>>>        [6]  NEEDED          0x29193c   libdoor.so.1
>>>>        [7]  NEEDED          0x291949   libc.so.1
>>>>        [8]  NEEDED          0x291953   libdemangle.so.1
>>>>        [9]  NEEDED          0x291964   libnsl.so.1
>>>>       [10]  NEEDED          0x291970   libkstat.so.1
>>>>       [11]  NEEDED          0x29197e   librt.so.1
>>>>
>>>> This list does not include any C++ standard libraries, as expected 
>>>> (libCrun is always in there even with -library=%none, and as 
>>>> expected no libstlport4.so or libCstd.so files are in there). The 
>>>> NEEDED entries in the dynamic section look identical with and 
>>>> without my patch.
>>>>
>>>>> I'm finding the actual build situation very confusing. It seems to 
>>>>> me in looking at the hotspot build files and the top-level build 
>>>>> files that -xnolib is used for C++ compilation & linking whereas 
>>>>> -library=%none is used for C compilation & linking. But the change 
>>>>> is being applied to $2JVM_CFLAGS which one would think is for C 
>>>>> compilation but we don't have $2JVM_CXXFLAGS, so it seems to be 
>>>>> used for both!
>>>>
>>>> I have also been confused by this when I tried adding CXX flags 
>>>> through configure that seemed to not be used. But that's a 
>>>> different can of worms I suppose.
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>>> David
>>>>>
>>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>>> Hi Kim,
>>>>>>>
>>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes 
>>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Erik,
>>>>>>>>>
>>>>>>>>> A small change with big questions :)
>>>>>>>>>
>>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> It would be desirable to be able to use harmless C++ standard 
>>>>>>>>>> library headers like <limits> in the code as long as it does 
>>>>>>>>>> not add any link-time dependencies to the standard library.
>>>>>>>>>
>>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>>
>>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>>
>>>>>>> And how does one establish those properties exist for a given 
>>>>>>> header file? Just use it and if no link errors then all is good?
>>>>>>
>>>>>> Objects from headers that are not ODR-used such as constant 
>>>>>> folded expressions are not imposing link-time dependencies to C++ 
>>>>>> libraries. The -xnolib that we already have in the LDFLAGS will 
>>>>>> catch any accidental ODR-uses of C++ objects, and the JVM will 
>>>>>> not build if that happens.
>>>>>>
>>>>>> As for external headers being included and not playing nicely 
>>>>>> with macros, this has to be evaluated on a case by case basis. 
>>>>>> Note that this is a problem that occurs when using system headers 
>>>>>> (that we are already using), as it is for using C++ standard 
>>>>>> library headers. We even run into that in our own JVM when e.g. 
>>>>>> the min/max macros occasionally slaps us gently in the face from 
>>>>>> time to time.
>>>>>>
>>>>>>>
>>>>>>>> The instigator for this is Erik and I are working on a project 
>>>>>>>> that
>>>>>>>> needs information that is present in std::numeric_limits<> 
>>>>>>>> (provided
>>>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>>>> would require platform-specific code (with all the complexity 
>>>>>>>> that can
>>>>>>>> imply).  We'd really rather not re-discover and maintain 
>>>>>>>> information
>>>>>>>> that is trivially accessible in every standard library.
>>>>>>>
>>>>>>> Understood. I have no issue with using <limits> but am concerned 
>>>>>>> by the state of stlport4. Can you use <limits> without changing 
>>>>>>> -library=%none?
>>>>>>
>>>>>> No, that is precisely why we are here.
>>>>>>
>>>>>>>
>>>>>>>>>> This is possible on all supported platforms except the ones 
>>>>>>>>>> using the solaris studio compiler where we enforce 
>>>>>>>>>> -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it 
>>>>>>>>>> on LDFLAGS.
>>>>>>>>>> I have consulted with the studio folks, and they think this 
>>>>>>>>>> is absolutely fine and thought that the choice of 
>>>>>>>>>> -library=stlport4 should be fine for our CFLAGS and is indeed 
>>>>>>>>>> what is already used in the gtest launcher.
>>>>>>>>>
>>>>>>>>> So what exactly does this mean? IIUC this allows you to use 
>>>>>>>>> headers for, and compile against "STLport?s Standard Library 
>>>>>>>>> implementation version 4.5.3 instead of the default libCstd". 
>>>>>>>>> But how do you then not need to link against libstlport.so ??
>>>>>>>>>
>>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>>
>>>>>>>>> "STLport is binary incompatible with the default libCstd. If 
>>>>>>>>> you use the STLport implementation of the standard library, 
>>>>>>>>> then you must compile and link all files, including 
>>>>>>>>> third-party libraries, with the option -library=stlport4?
>>>>>>>>
>>>>>>>> It means we can only use header-only parts of the standard 
>>>>>>>> library.
>>>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>>>> providing such limited access while continuing to constrain our
>>>>>>>> dependency on the library.  Figuring out what can be used will 
>>>>>>>> need to
>>>>>>>> be determined on a case-by-case basis.  Maybe we could just 
>>>>>>>> link with
>>>>>>>> a standard library on Solaris too.  So far as I can tell, 
>>>>>>>> Solaris is
>>>>>>>> the only platform where we don't do that.  But Erik is trying 
>>>>>>>> to be
>>>>>>>> conservative.
>>>>>>>
>>>>>>> Okay, but the docs don't seem to acknowledge the ability to use, 
>>>>>>> but not link to, stlport4.
>>>>>>
>>>>>> Not ODR-used objects do not require linkage. 
>>>>>> (http://en.cppreference.com/w/cpp/language/definition)
>>>>>> I have confirmed directly with the studio folks to be certain 
>>>>>> that accidental linkage would fail by keeping our existing guards 
>>>>>> in the LDFLAGS rather than the CFLAGS.
>>>>>> This is also reasonably well documented already 
>>>>>> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>>
>>>>>>>
>>>>>>>>> There are lots of other comments in that document regarding 
>>>>>>>>> STLport that makes me think that using it may be introducing a 
>>>>>>>>> fragile dependency into the OpenJDK code!
>>>>>>>>>
>>>>>>>>> "STLport is an open source product and does not guarantee 
>>>>>>>>> compatibility across different releases. In other words, 
>>>>>>>>> compiling with a future version of STLport may break 
>>>>>>>>> applications compiled with STLport 4.5.3. It also might not be 
>>>>>>>>> possible to link binaries compiled using STLport 4.5.3 with 
>>>>>>>>> binaries compiled using a future version of STLport."
>>>>>>>>>
>>>>>>>>> "Future releases of the compiler might not include STLport4. 
>>>>>>>>> They might include only a later version of STLport. The 
>>>>>>>>> compiler option -library=stlport4 might not be available in 
>>>>>>>>> future releases, but could be replaced by an option referring 
>>>>>>>>> to a later STLport version."
>>>>>>>>>
>>>>>>>>> None of that sounds very good to me.
>>>>>>>>
>>>>>>>> I don't see how this is any different from any other part of the
>>>>>>>> process for using a different version of Solaris Studio.
>>>>>>>
>>>>>>> Well we'd discover the problem when testing the compiler change, 
>>>>>>> but my point was more to the fact that they don't seem very 
>>>>>>> committed to this library - very much a "use at own risk" 
>>>>>>> disclaimer.
>>>>>>
>>>>>> If we eventually need to use something more modern for features 
>>>>>> that have not been around for a decade, like C++11 features, then 
>>>>>> we can change standard library when that day comes.
>>>>>>
>>>>>>>
>>>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik 
>>>>>>>> asked the
>>>>>>>> Studio folks which to use (for the purposes of our present 
>>>>>>>> project, we
>>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>>> stlport4 seemed the right choice (libCstd was, I think, 
>>>>>>>> described as
>>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>>> including linking against it, for gtest builds. Mixing two 
>>>>>>>> different
>>>>>>>> standard libraries seems like a bad idea...
>>>>>>>
>>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>>
>>>>>>> My confidence in this has not increased :)
>>>>>>
>>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the 
>>>>>> standard libraries has more mileage than whatever simplified 
>>>>>> rewrite of that we try to replicate in the JVM. So it is not 
>>>>>> obvious to me that we should have less confidence in the same 
>>>>>> functionality from a standard library shipped together with the 
>>>>>> compiler we are using and that has already been used and tested 
>>>>>> in a variety of C++ applications for over a decade compared to 
>>>>>> the alternative of reinventing it ourselves.
>>>>>>
>>>>>>> What we do in gtest doesn't necessarily make things okay to do 
>>>>>>> in the product.
>>>>>>>
>>>>>>> If this were part of a compiler upgrade process we'd be 
>>>>>>> comparing binaries with old flag and new to ensure there are no 
>>>>>>> unexpected consequences.
>>>>>>
>>>>>> I would not compare including <limits> to a compiler upgrade 
>>>>>> process as we are not changing the compiler and hence not the way 
>>>>>> code is generated, but rather compare it to including a new 
>>>>>> system header that has previously not been included to use a 
>>>>>> constant folded expression from that header that has been used 
>>>>>> and tested for a decade. At least that is how I think of it.
>>>>>>
>>>>>> Thanks,
>>>>>> /Erik
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>>> Testing: JPRT.
>>>>>>>>>> Will need a sponsor.
>>>>>>>>>> Thanks,
>>>>>>>>>> /Erik
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>



From daniel.daugherty at oracle.com  Mon Jun  5 16:31:40 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 5 Jun 2017 10:31:40 -0600
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <59358492.7030803@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
 <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
 <59358492.7030803@oracle.com>
Message-ID: <997648e7-2880-a626-f866-8892abee2a5d@oracle.com>

On 6/5/17 10:19 AM, Erik ?sterlund wrote:
> Hi David,
>
> On 2017-06-05 14:45, David Holmes wrote:
>> Hi Erik,
>>
>> On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
>>> Hi David,
>>>
>>> On 2017-06-02 03:30, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>>>> Hi David,
>>>>>
>>>>> On 2017-06-01 14:33, David Holmes wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>> Just to be clear it is not the use of <limits> that I am 
>>>>>> concerned about, it is the -library=stlport4. It is the use of 
>>>>>> that flag that I would want to check in terms of having no affect 
>>>>>> on any existing code generation.
>>>>>
>>>>> Thank you for the clarification. The use of -library=stlport4 
>>>>> should not have anything to do with code generation. It only says 
>>>>> where to look for the standard library headers such as <limits> 
>>>>> that are used in the compilation units.
>>>>
>>>> The potential problem is that the stlport4 include path eg:
>>>>
>>>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>>>
>>>> doesn't only contain the C++ headers (new, limits, string etc) but 
>>>> also a whole bunch of regular 'standard' .h headers that are 
>>>> _different_ to those found outside the stlport4 directory ie the 
>>>> ones we would currently include. I don't know if the differences 
>>>> are significant, nor whether those others may be found ahead of the 
>>>> stlport4 version. But that is my concern about the effects on the 
>>>> code.
>>>
>>> While I do not think exchanging these headers will have any 
>>> behavioral impact, I agree that we can not prove so as they are 
>>> indeed different header files. That is a good point.
>>>
>>> However, I think that makes the stlport4 case stronger rather than 
>>> weaker. We already use stlport4 for our gtest testing (because it is 
>>> required and does not build without it). And if those headers would 
>>> indeed have slightly different behaviour as you imply, it further 
>>> motivates using the same standard library when compiling the product 
>>> as the testing code. If they were to behave slightly differently, it 
>>> might be that our gtest tests does not catch hidden bugs that only 
>>> manifest when building with a different set of headers used for the 
>>> product build. I therefore find it exceedingly dangerous to stay on 
>>> two standard libraries (depending on if test code or product code is 
>>> compiled) compared to consistently using the same standard library 
>>> across all compilations. So for me, the larger the risk is of them 
>>> behaving differently is, the bigger the motivation is to use 
>>> stlport4 consistently.
>>
>> Regardless of what gtest does if you want to switch the standard 
>> libraries used by the product then IMHO that should go through a 
>> vetting process no weaker than that for changing the toolchain, as 
>> you effectively are doing that.
>
> I talked to Erik Joelsson about how to compare two builds. He 
> introduced me to our compare.sh script that is used to compare two 
> builds.
> I built a baseline without these changes and a new build with these 
> changes applied, both on a Solaris SPARC T7 machine. Then I compared 
> them with ./compare.sh -2dirs 
> {$BUILD1}/hotspot/variant-server/libjvm/objs 
> {$BUILD2}/hotspot/variant-server/libjvm/objs -libs --strip
>
> This compares the object files produced when compiling hotspot in 
> build 1 and build 2 after stripping symbols.
>
> First it reported:
> Libraries...
>    Size    : Symbols :  Deps   : Disass   :
>            :* diff  *:         :          : ./dtrace.o
>            :* diff  *:         :*   38918*: ./jni.o
>            :* diff  *:         :*   23226*: ./unsafe.o
>
> It seems like all symbols were not stripped here on these mentioned 
> files and constituted all differences in the disassembly. So I made a 
> simple sed filter to filter out symbol names in the disassembly with 
> the regexp <.*>.
>
> The result was:
> Libraries...
>    Size    : Symbols :  Deps   : Disass   :
>            :* diff  *:         :          : ./dtrace.o
>            :* diff  *:         :          : ./jni.o
>            :* diff  *:         :          : ./unsafe.o
>
> This shows that not a single instruction was emitted differently 
> between the two builds.
>
> I also did the filtering manually on jni.o and unsafe.o in emacs to 
> make sure I did not mess up.
>
> Are we happy with this, or do you still have doubts that this might 
> result in different code or behavior?

Just to be clear: The current experiment changes both the header and
the standard library right? If so, then the compare.sh run works for
validating that using the new header file will not result in a change
in behavior. However, that comparison doesn't do anything for testing
a switch in the standard libraries right?

Dan


>
> Thanks,
> /Erik
>
>> Cheers,
>> David
>>
>>
>>> Thanks,
>>> /Erik
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>
>>>>> Specifically, the man pages for CC say:
>>>>>
>>>>> <man>
>>>>>         -library=lib[,lib...]
>>>>>
>>>>>             Incorporates  specified  CC-provided libraries into 
>>>>> compilation and
>>>>>             linking.
>>>>>
>>>>>             When the -library option is used to specify a 
>>>>> CC-provided library,
>>>>>             the  proper  -I paths are set during compilation and 
>>>>> the proper -L,
>>>>>             -Y, -P, and -R paths and -l options are set during 
>>>>> linking.
>>>>> </man>
>>>>>
>>>>> As we are setting this during compilation and not during linking, 
>>>>> this corresponds to setting the right -I paths to find our C++ 
>>>>> standard library headers.
>>>>>
>>>>> My studio friends mentioned I could double-check that we did 
>>>>> indeed not add a dependency to any C++ standard library by running 
>>>>> elfdump on the generated libjvm.so file and check if the NEEDED 
>>>>> entries in the dynamic section look right. I did and here are the 
>>>>> results:
>>>>>
>>>>>        [0]  NEEDED          0x2918ee   libsocket.so.1
>>>>>        [1]  NEEDED          0x2918fd   libsched.so.1
>>>>>        [2]  NEEDED          0x29190b   libdl.so.1
>>>>>        [3]  NEEDED          0x291916   libm.so.1
>>>>>        [4]  NEEDED          0x291920   libCrun.so.1
>>>>>        [5]  NEEDED          0x29192d   libthread.so.1
>>>>>        [6]  NEEDED          0x29193c   libdoor.so.1
>>>>>        [7]  NEEDED          0x291949   libc.so.1
>>>>>        [8]  NEEDED          0x291953   libdemangle.so.1
>>>>>        [9]  NEEDED          0x291964   libnsl.so.1
>>>>>       [10]  NEEDED          0x291970   libkstat.so.1
>>>>>       [11]  NEEDED          0x29197e   librt.so.1
>>>>>
>>>>> This list does not include any C++ standard libraries, as expected 
>>>>> (libCrun is always in there even with -library=%none, and as 
>>>>> expected no libstlport4.so or libCstd.so files are in there). The 
>>>>> NEEDED entries in the dynamic section look identical with and 
>>>>> without my patch.
>>>>>
>>>>>> I'm finding the actual build situation very confusing. It seems 
>>>>>> to me in looking at the hotspot build files and the top-level 
>>>>>> build files that -xnolib is used for C++ compilation & linking 
>>>>>> whereas -library=%none is used for C compilation & linking. But 
>>>>>> the change is being applied to $2JVM_CFLAGS which one would think 
>>>>>> is for C compilation but we don't have $2JVM_CXXFLAGS, so it 
>>>>>> seems to be used for both!
>>>>>
>>>>> I have also been confused by this when I tried adding CXX flags 
>>>>> through configure that seemed to not be used. But that's a 
>>>>> different can of worms I suppose.
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>>> David
>>>>>>
>>>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>>>> Hi Kim,
>>>>>>>>
>>>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes 
>>>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Erik,
>>>>>>>>>>
>>>>>>>>>> A small change with big questions :)
>>>>>>>>>>
>>>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> It would be desirable to be able to use harmless C++ 
>>>>>>>>>>> standard library headers like <limits> in the code as long 
>>>>>>>>>>> as it does not add any link-time dependencies to the 
>>>>>>>>>>> standard library.
>>>>>>>>>>
>>>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>>>
>>>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>>>> [vm]assert macro, and provides functionality we presently lack 
>>>>>>>>> (or
>>>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>>>
>>>>>>>> And how does one establish those properties exist for a given 
>>>>>>>> header file? Just use it and if no link errors then all is good?
>>>>>>>
>>>>>>> Objects from headers that are not ODR-used such as constant 
>>>>>>> folded expressions are not imposing link-time dependencies to 
>>>>>>> C++ libraries. The -xnolib that we already have in the LDFLAGS 
>>>>>>> will catch any accidental ODR-uses of C++ objects, and the JVM 
>>>>>>> will not build if that happens.
>>>>>>>
>>>>>>> As for external headers being included and not playing nicely 
>>>>>>> with macros, this has to be evaluated on a case by case basis. 
>>>>>>> Note that this is a problem that occurs when using system 
>>>>>>> headers (that we are already using), as it is for using C++ 
>>>>>>> standard library headers. We even run into that in our own JVM 
>>>>>>> when e.g. the min/max macros occasionally slaps us gently in the 
>>>>>>> face from time to time.
>>>>>>>
>>>>>>>>
>>>>>>>>> The instigator for this is Erik and I are working on a project 
>>>>>>>>> that
>>>>>>>>> needs information that is present in std::numeric_limits<> 
>>>>>>>>> (provided
>>>>>>>>> by the <limits> header).  Reproducing that functionality 
>>>>>>>>> ourselves
>>>>>>>>> would require platform-specific code (with all the complexity 
>>>>>>>>> that can
>>>>>>>>> imply).  We'd really rather not re-discover and maintain 
>>>>>>>>> information
>>>>>>>>> that is trivially accessible in every standard library.
>>>>>>>>
>>>>>>>> Understood. I have no issue with using <limits> but am 
>>>>>>>> concerned by the state of stlport4. Can you use <limits> 
>>>>>>>> without changing -library=%none?
>>>>>>>
>>>>>>> No, that is precisely why we are here.
>>>>>>>
>>>>>>>>
>>>>>>>>>>> This is possible on all supported platforms except the ones 
>>>>>>>>>>> using the solaris studio compiler where we enforce 
>>>>>>>>>>> -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it 
>>>>>>>>>>> on LDFLAGS.
>>>>>>>>>>> I have consulted with the studio folks, and they think this 
>>>>>>>>>>> is absolutely fine and thought that the choice of 
>>>>>>>>>>> -library=stlport4 should be fine for our CFLAGS and is 
>>>>>>>>>>> indeed what is already used in the gtest launcher.
>>>>>>>>>>
>>>>>>>>>> So what exactly does this mean? IIUC this allows you to use 
>>>>>>>>>> headers for, and compile against "STLport?s Standard Library 
>>>>>>>>>> implementation version 4.5.3 instead of the default libCstd". 
>>>>>>>>>> But how do you then not need to link against libstlport.so ??
>>>>>>>>>>
>>>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>>>
>>>>>>>>>> "STLport is binary incompatible with the default libCstd. If 
>>>>>>>>>> you use the STLport implementation of the standard library, 
>>>>>>>>>> then you must compile and link all files, including 
>>>>>>>>>> third-party libraries, with the option -library=stlport4?
>>>>>>>>>
>>>>>>>>> It means we can only use header-only parts of the standard 
>>>>>>>>> library.
>>>>>>>>> This was confirmed / suggested by the Studio folks Erik 
>>>>>>>>> consulted,
>>>>>>>>> providing such limited access while continuing to constrain our
>>>>>>>>> dependency on the library.  Figuring out what can be used will 
>>>>>>>>> need to
>>>>>>>>> be determined on a case-by-case basis.  Maybe we could just 
>>>>>>>>> link with
>>>>>>>>> a standard library on Solaris too.  So far as I can tell, 
>>>>>>>>> Solaris is
>>>>>>>>> the only platform where we don't do that.  But Erik is trying 
>>>>>>>>> to be
>>>>>>>>> conservative.
>>>>>>>>
>>>>>>>> Okay, but the docs don't seem to acknowledge the ability to 
>>>>>>>> use, but not link to, stlport4.
>>>>>>>
>>>>>>> Not ODR-used objects do not require linkage. 
>>>>>>> (http://en.cppreference.com/w/cpp/language/definition)
>>>>>>> I have confirmed directly with the studio folks to be certain 
>>>>>>> that accidental linkage would fail by keeping our existing 
>>>>>>> guards in the LDFLAGS rather than the CFLAGS.
>>>>>>> This is also reasonably well documented already 
>>>>>>> (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>>>
>>>>>>>>
>>>>>>>>>> There are lots of other comments in that document regarding 
>>>>>>>>>> STLport that makes me think that using it may be introducing 
>>>>>>>>>> a fragile dependency into the OpenJDK code!
>>>>>>>>>>
>>>>>>>>>> "STLport is an open source product and does not guarantee 
>>>>>>>>>> compatibility across different releases. In other words, 
>>>>>>>>>> compiling with a future version of STLport may break 
>>>>>>>>>> applications compiled with STLport 4.5.3. It also might not 
>>>>>>>>>> be possible to link binaries compiled using STLport 4.5.3 
>>>>>>>>>> with binaries compiled using a future version of STLport."
>>>>>>>>>>
>>>>>>>>>> "Future releases of the compiler might not include STLport4. 
>>>>>>>>>> They might include only a later version of STLport. The 
>>>>>>>>>> compiler option -library=stlport4 might not be available in 
>>>>>>>>>> future releases, but could be replaced by an option referring 
>>>>>>>>>> to a later STLport version."
>>>>>>>>>>
>>>>>>>>>> None of that sounds very good to me.
>>>>>>>>>
>>>>>>>>> I don't see how this is any different from any other part of the
>>>>>>>>> process for using a different version of Solaris Studio.
>>>>>>>>
>>>>>>>> Well we'd discover the problem when testing the compiler 
>>>>>>>> change, but my point was more to the fact that they don't seem 
>>>>>>>> very committed to this library - very much a "use at own risk" 
>>>>>>>> disclaimer.
>>>>>>>
>>>>>>> If we eventually need to use something more modern for features 
>>>>>>> that have not been around for a decade, like C++11 features, 
>>>>>>> then we can change standard library when that day comes.
>>>>>>>
>>>>>>>>
>>>>>>>>> stlport4 is one of the three standard libraries that are 
>>>>>>>>> presently
>>>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik 
>>>>>>>>> asked the
>>>>>>>>> Studio folks which to use (for the purposes of our present 
>>>>>>>>> project, we
>>>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>>>> stlport4 seemed the right choice (libCstd was, I think, 
>>>>>>>>> described as
>>>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>>>> including linking against it, for gtest builds. Mixing two 
>>>>>>>>> different
>>>>>>>>> standard libraries seems like a bad idea...
>>>>>>>>
>>>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>>>
>>>>>>>> My confidence in this has not increased :)
>>>>>>>
>>>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the 
>>>>>>> standard libraries has more mileage than whatever simplified 
>>>>>>> rewrite of that we try to replicate in the JVM. So it is not 
>>>>>>> obvious to me that we should have less confidence in the same 
>>>>>>> functionality from a standard library shipped together with the 
>>>>>>> compiler we are using and that has already been used and tested 
>>>>>>> in a variety of C++ applications for over a decade compared to 
>>>>>>> the alternative of reinventing it ourselves.
>>>>>>>
>>>>>>>> What we do in gtest doesn't necessarily make things okay to do 
>>>>>>>> in the product.
>>>>>>>>
>>>>>>>> If this were part of a compiler upgrade process we'd be 
>>>>>>>> comparing binaries with old flag and new to ensure there are no 
>>>>>>>> unexpected consequences.
>>>>>>>
>>>>>>> I would not compare including <limits> to a compiler upgrade 
>>>>>>> process as we are not changing the compiler and hence not the 
>>>>>>> way code is generated, but rather compare it to including a new 
>>>>>>> system header that has previously not been included to use a 
>>>>>>> constant folded expression from that header that has been used 
>>>>>>> and tested for a decade. At least that is how I think of it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> /Erik
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>>>> Testing: JPRT.
>>>>>>>>>>> Will need a sponsor.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>



From erik.osterlund at oracle.com  Mon Jun  5 16:59:38 2017
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Mon, 5 Jun 2017 18:59:38 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <997648e7-2880-a626-f866-8892abee2a5d@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
 <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
 <59358492.7030803@oracle.com>
 <997648e7-2880-a626-f866-8892abee2a5d@oracle.com>
Message-ID: <D279AD45-2763-429B-BD32-7D3BA0ACA002@oracle.com>

Hi Dan,

>> On 5 Jun 2017, at 18:31, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>> 
>> On 6/5/17 10:19 AM, Erik ?sterlund wrote:
>> Hi David,
>> 
>>> On 2017-06-05 14:45, David Holmes wrote:
>>> Hi Erik,
>>> 
>>>> On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
>>>> Hi David,
>>>> 
>>>>> On 2017-06-02 03:30, David Holmes wrote:
>>>>> Hi Erik,
>>>>> 
>>>>>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>>>>> Hi David,
>>>>>> 
>>>>>>> On 2017-06-01 14:33, David Holmes wrote:
>>>>>>> Hi Erik,
>>>>>>> 
>>>>>>> Just to be clear it is not the use of <limits> that I am concerned about, it is the -library=stlport4. It is the use of that flag that I would want to check in terms of having no affect on any existing code generation.
>>>>>> 
>>>>>> Thank you for the clarification. The use of -library=stlport4 should not have anything to do with code generation. It only says where to look for the standard library headers such as <limits> that are used in the compilation units.
>>>>> 
>>>>> The potential problem is that the stlport4 include path eg:
>>>>> 
>>>>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>>>> 
>>>>> doesn't only contain the C++ headers (new, limits, string etc) but also a whole bunch of regular 'standard' .h headers that are _different_ to those found outside the stlport4 directory ie the ones we would currently include. I don't know if the differences are significant, nor whether those others may be found ahead of the stlport4 version. But that is my concern about the effects on the code.
>>>> 
>>>> While I do not think exchanging these headers will have any behavioral impact, I agree that we can not prove so as they are indeed different header files. That is a good point.
>>>> 
>>>> However, I think that makes the stlport4 case stronger rather than weaker. We already use stlport4 for our gtest testing (because it is required and does not build without it). And if those headers would indeed have slightly different behaviour as you imply, it further motivates using the same standard library when compiling the product as the testing code. If they were to behave slightly differently, it might be that our gtest tests does not catch hidden bugs that only manifest when building with a different set of headers used for the product build. I therefore find it exceedingly dangerous to stay on two standard libraries (depending on if test code or product code is compiled) compared to consistently using the same standard library across all compilations. So for me, the larger the risk is of them behaving differently is, the bigger the motivation is to use stlport4 consistently.
>>> 
>>> Regardless of what gtest does if you want to switch the standard libraries used by the product then IMHO that should go through a vetting process no weaker than that for changing the toolchain, as you effectively are doing that.
>> 
>> I talked to Erik Joelsson about how to compare two builds. He introduced me to our compare.sh script that is used to compare two builds.
>> I built a baseline without these changes and a new build with these changes applied, both on a Solaris SPARC T7 machine. Then I compared them with ./compare.sh -2dirs {$BUILD1}/hotspot/variant-server/libjvm/objs {$BUILD2}/hotspot/variant-server/libjvm/objs -libs --strip
>> 
>> This compares the object files produced when compiling hotspot in build 1 and build 2 after stripping symbols.
>> 
>> First it reported:
>> Libraries...
>>   Size    : Symbols :  Deps   : Disass   :
>>           :* diff  *:         :          : ./dtrace.o
>>           :* diff  *:         :*   38918*: ./jni.o
>>           :* diff  *:         :*   23226*: ./unsafe.o
>> 
>> It seems like all symbols were not stripped here on these mentioned files and constituted all differences in the disassembly. So I made a simple sed filter to filter out symbol names in the disassembly with the regexp <.*>.
>> 
>> The result was:
>> Libraries...
>>   Size    : Symbols :  Deps   : Disass   :
>>           :* diff  *:         :          : ./dtrace.o
>>           :* diff  *:         :          : ./jni.o
>>           :* diff  *:         :          : ./unsafe.o
>> 
>> This shows that not a single instruction was emitted differently between the two builds.
>> 
>> I also did the filtering manually on jni.o and unsafe.o in emacs to make sure I did not mess up.
>> 
>> Are we happy with this, or do you still have doubts that this might result in different code or behavior?
> 
> Just to be clear: The current experiment changes both the header and
> the standard library right? If so, then the compare.sh run works for
> validating that using the new header file will not result in a change
> in behavior. However, that comparison doesn't do anything for testing
> a switch in the standard libraries right?

The -xnolib guards are still there in the LDFLAGS. That is, the linker will not allow anything to link against either standard library. I have manually confirmed this by doing the sanity check of comparing the NEEDED entries in the dynamic section of the libjvm.so elf file using elfdump. It has no references to neither libstlport4 nor libCstd with or without my changes.

Summary: the changes do not add any linktime dependencies to either standard library, and we are still guarded in the sense that if such dependencies were to accidentally be introduced, it would not build. The only difference then would be slightly different code generation of object files. And their disassemblies have been confirmed not to differ by even a single instruction generated differently.

Thanks,
/Erik

> Dan
> 
> 
>> 
>> Thanks,
>> /Erik
>> 
>>> Cheers,
>>> David
>>> 
>>> 
>>>> Thanks,
>>>> /Erik
>>>> 
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>> 
>>>>> 
>>>>>> Specifically, the man pages for CC say:
>>>>>> 
>>>>>> <man>
>>>>>>        -library=lib[,lib...]
>>>>>> 
>>>>>>            Incorporates  specified  CC-provided libraries into compilation and
>>>>>>            linking.
>>>>>> 
>>>>>>            When the -library option is used to specify a CC-provided library,
>>>>>>            the  proper  -I paths are set during compilation and the proper -L,
>>>>>>            -Y, -P, and -R paths and -l options are set during linking.
>>>>>> </man>
>>>>>> 
>>>>>> As we are setting this during compilation and not during linking, this corresponds to setting the right -I paths to find our C++ standard library headers.
>>>>>> 
>>>>>> My studio friends mentioned I could double-check that we did indeed not add a dependency to any C++ standard library by running elfdump on the generated libjvm.so file and check if the NEEDED entries in the dynamic section look right. I did and here are the results:
>>>>>> 
>>>>>>       [0]  NEEDED          0x2918ee   libsocket.so.1
>>>>>>       [1]  NEEDED          0x2918fd   libsched.so.1
>>>>>>       [2]  NEEDED          0x29190b   libdl.so.1
>>>>>>       [3]  NEEDED          0x291916   libm.so.1
>>>>>>       [4]  NEEDED          0x291920   libCrun.so.1
>>>>>>       [5]  NEEDED          0x29192d   libthread.so.1
>>>>>>       [6]  NEEDED          0x29193c   libdoor.so.1
>>>>>>       [7]  NEEDED          0x291949   libc.so.1
>>>>>>       [8]  NEEDED          0x291953   libdemangle.so.1
>>>>>>       [9]  NEEDED          0x291964   libnsl.so.1
>>>>>>      [10]  NEEDED          0x291970   libkstat.so.1
>>>>>>      [11]  NEEDED          0x29197e   librt.so.1
>>>>>> 
>>>>>> This list does not include any C++ standard libraries, as expected (libCrun is always in there even with -library=%none, and as expected no libstlport4.so or libCstd.so files are in there). The NEEDED entries in the dynamic section look identical with and without my patch.
>>>>>> 
>>>>>>> I'm finding the actual build situation very confusing. It seems to me in looking at the hotspot build files and the top-level build files that -xnolib is used for C++ compilation & linking whereas -library=%none is used for C compilation & linking. But the change is being applied to $2JVM_CFLAGS which one would think is for C compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used for both!
>>>>>> 
>>>>>> I have also been confused by this when I tried adding CXX flags through configure that seemed to not be used. But that's a different can of worms I suppose.
>>>>>> 
>>>>>> Thanks,
>>>>>> /Erik
>>>>>> 
>>>>>>> David
>>>>>>> 
>>>>>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>>>>> Hi David,
>>>>>>>> 
>>>>>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>>>>> Hi Kim,
>>>>>>>>> 
>>>>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Erik,
>>>>>>>>>>> 
>>>>>>>>>>> A small change with big questions :)
>>>>>>>>>>> 
>>>>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>>>>>>>>>>> 
>>>>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>>>> 
>>>>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>>>> 
>>>>>>>>> And how does one establish those properties exist for a given header file? Just use it and if no link errors then all is good?
>>>>>>>> 
>>>>>>>> Objects from headers that are not ODR-used such as constant folded expressions are not imposing link-time dependencies to C++ libraries. The -xnolib that we already have in the LDFLAGS will catch any accidental ODR-uses of C++ objects, and the JVM will not build if that happens.
>>>>>>>> 
>>>>>>>> As for external headers being included and not playing nicely with macros, this has to be evaluated on a case by case basis. Note that this is a problem that occurs when using system headers (that we are already using), as it is for using C++ standard library headers. We even run into that in our own JVM when e.g. the min/max macros occasionally slaps us gently in the face from time to time.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> The instigator for this is Erik and I are working on a project that
>>>>>>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>>>>>> would require platform-specific code (with all the complexity that can
>>>>>>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>>>>>>> that is trivially accessible in every standard library.
>>>>>>>>> 
>>>>>>>>> Understood. I have no issue with using <limits> but am concerned by the state of stlport4. Can you use <limits> without changing -library=%none?
>>>>>>>> 
>>>>>>>> No, that is precisely why we are here.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>>>>>>>>>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>>>>>>>>>>> 
>>>>>>>>>>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>>>>>>>>>>> 
>>>>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>>>> 
>>>>>>>>>>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?
>>>>>>>>>> 
>>>>>>>>>> It means we can only use header-only parts of the standard library.
>>>>>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>>>>>> providing such limited access while continuing to constrain our
>>>>>>>>>> dependency on the library.  Figuring out what can be used will need to
>>>>>>>>>> be determined on a case-by-case basis.  Maybe we could just link with
>>>>>>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>>>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>>>>>>> conservative.
>>>>>>>>> 
>>>>>>>>> Okay, but the docs don't seem to acknowledge the ability to use, but not link to, stlport4.
>>>>>>>> 
>>>>>>>> Not ODR-used objects do not require linkage. (http://en.cppreference.com/w/cpp/language/definition)
>>>>>>>> I have confirmed directly with the studio folks to be certain that accidental linkage would fail by keeping our existing guards in the LDFLAGS rather than the CFLAGS.
>>>>>>>> This is also reasonably well documented already (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>>>>>>>>>>> 
>>>>>>>>>>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>>>>>>>>>>> 
>>>>>>>>>>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>>>>>>>>>>> 
>>>>>>>>>>> None of that sounds very good to me.
>>>>>>>>>> 
>>>>>>>>>> I don't see how this is any different from any other part of the
>>>>>>>>>> process for using a different version of Solaris Studio.
>>>>>>>>> 
>>>>>>>>> Well we'd discover the problem when testing the compiler change, but my point was more to the fact that they don't seem very committed to this library - very much a "use at own risk" disclaimer.
>>>>>>>> 
>>>>>>>> If we eventually need to use something more modern for features that have not been around for a decade, like C++11 features, then we can change standard library when that day comes.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked the
>>>>>>>>>> Studio folks which to use (for the purposes of our present project, we
>>>>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>>>>> including linking against it, for gtest builds. Mixing two different
>>>>>>>>>> standard libraries seems like a bad idea...
>>>>>>>>> 
>>>>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>>>> 
>>>>>>>>> My confidence in this has not increased :)
>>>>>>>> 
>>>>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard libraries has more mileage than whatever simplified rewrite of that we try to replicate in the JVM. So it is not obvious to me that we should have less confidence in the same functionality from a standard library shipped together with the compiler we are using and that has already been used and tested in a variety of C++ applications for over a decade compared to the alternative of reinventing it ourselves.
>>>>>>>> 
>>>>>>>>> What we do in gtest doesn't necessarily make things okay to do in the product.
>>>>>>>>> 
>>>>>>>>> If this were part of a compiler upgrade process we'd be comparing binaries with old flag and new to ensure there are no unexpected consequences.
>>>>>>>> 
>>>>>>>> I would not compare including <limits> to a compiler upgrade process as we are not changing the compiler and hence not the way code is generated, but rather compare it to including a new system header that has previously not been included to use a constant folded expression from that header that has been used and tested for a decade. At least that is how I think of it.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> /Erik
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> David
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>>>>> Testing: JPRT.
>>>>>>>>>>>> Will need a sponsor.
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> /Erik
> 



From daniel.daugherty at oracle.com  Mon Jun  5 17:22:32 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 5 Jun 2017 11:22:32 -0600
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <D279AD45-2763-429B-BD32-7D3BA0ACA002@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
 <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
 <59358492.7030803@oracle.com>
 <997648e7-2880-a626-f866-8892abee2a5d@oracle.com>
 <D279AD45-2763-429B-BD32-7D3BA0ACA002@oracle.com>
Message-ID: <cddf2c3e-b20a-1d55-6322-2188fc57b238@oracle.com>

On 6/5/17 10:59 AM, Erik Osterlund wrote:
> Hi Dan,
>
>>> On 5 Jun 2017, at 18:31, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>
>>> On 6/5/17 10:19 AM, Erik ?sterlund wrote:
>>> Hi David,
>>>
>>>> On 2017-06-05 14:45, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>>> On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
>>>>> Hi David,
>>>>>
>>>>>> On 2017-06-02 03:30, David Holmes wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> On 2017-06-01 14:33, David Holmes wrote:
>>>>>>>> Hi Erik,
>>>>>>>>
>>>>>>>> Just to be clear it is not the use of <limits> that I am concerned about, it is the -library=stlport4. It is the use of that flag that I would want to check in terms of having no affect on any existing code generation.
>>>>>>> Thank you for the clarification. The use of -library=stlport4 should not have anything to do with code generation. It only says where to look for the standard library headers such as <limits> that are used in the compilation units.
>>>>>> The potential problem is that the stlport4 include path eg:
>>>>>>
>>>>>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>>>>>
>>>>>> doesn't only contain the C++ headers (new, limits, string etc) but also a whole bunch of regular 'standard' .h headers that are _different_ to those found outside the stlport4 directory ie the ones we would currently include. I don't know if the differences are significant, nor whether those others may be found ahead of the stlport4 version. But that is my concern about the effects on the code.
>>>>> While I do not think exchanging these headers will have any behavioral impact, I agree that we can not prove so as they are indeed different header files. That is a good point.
>>>>>
>>>>> However, I think that makes the stlport4 case stronger rather than weaker. We already use stlport4 for our gtest testing (because it is required and does not build without it). And if those headers would indeed have slightly different behaviour as you imply, it further motivates using the same standard library when compiling the product as the testing code. If they were to behave slightly differently, it might be that our gtest tests does not catch hidden bugs that only manifest when building with a different set of headers used for the product build. I therefore find it exceedingly dangerous to stay on two standard libraries (depending on if test code or product code is compiled) compared to consistently using the same standard library across all compilations. So for me, the larger the risk is of them behaving differently is, the bigger the motivation is to use stlport4 consistently.
>>>> Regardless of what gtest does if you want to switch the standard libraries used by the product then IMHO that should go through a vetting process no weaker than that for changing the toolchain, as you effectively are doing that.
>>> I talked to Erik Joelsson about how to compare two builds. He introduced me to our compare.sh script that is used to compare two builds.
>>> I built a baseline without these changes and a new build with these changes applied, both on a Solaris SPARC T7 machine. Then I compared them with ./compare.sh -2dirs {$BUILD1}/hotspot/variant-server/libjvm/objs {$BUILD2}/hotspot/variant-server/libjvm/objs -libs --strip
>>>
>>> This compares the object files produced when compiling hotspot in build 1 and build 2 after stripping symbols.
>>>
>>> First it reported:
>>> Libraries...
>>>    Size    : Symbols :  Deps   : Disass   :
>>>            :* diff  *:         :          : ./dtrace.o
>>>            :* diff  *:         :*   38918*: ./jni.o
>>>            :* diff  *:         :*   23226*: ./unsafe.o
>>>
>>> It seems like all symbols were not stripped here on these mentioned files and constituted all differences in the disassembly. So I made a simple sed filter to filter out symbol names in the disassembly with the regexp <.*>.
>>>
>>> The result was:
>>> Libraries...
>>>    Size    : Symbols :  Deps   : Disass   :
>>>            :* diff  *:         :          : ./dtrace.o
>>>            :* diff  *:         :          : ./jni.o
>>>            :* diff  *:         :          : ./unsafe.o
>>>
>>> This shows that not a single instruction was emitted differently between the two builds.
>>>
>>> I also did the filtering manually on jni.o and unsafe.o in emacs to make sure I did not mess up.
>>>
>>> Are we happy with this, or do you still have doubts that this might result in different code or behavior?
>> Just to be clear: The current experiment changes both the header and
>> the standard library right? If so, then the compare.sh run works for
>> validating that using the new header file will not result in a change
>> in behavior. However, that comparison doesn't do anything for testing
>> a switch in the standard libraries right?
> The -xnolib guards are still there in the LDFLAGS. That is, the linker will not allow anything to link against either standard library. I have manually confirmed this by doing the sanity check of comparing the NEEDED entries in the dynamic section of the libjvm.so elf file using elfdump. It has no references to neither libstlport4 nor libCstd with or without my changes.
>
> Summary: the changes do not add any linktime dependencies to either standard library, and we are still guarded in the sense that if such dependencies were to accidentally be introduced, it would not build. The only difference then would be slightly different code generation of object files. And their disassemblies have been confirmed not to differ by even a single instruction generated differently.

So your current changes use the stlport4 include path for both product
build and 'gtest' build. You've verified the following:

- The product binaries do not change even one instruction with the
   new include path.
- The options to keep us from linking to anything in stlport4 are
   still in place.
- You've manually verified that there are no linkage dependencies
   in the resulting binaries.

If I have all that right, then I think you've covered your bases.

Dan



>
> Thanks,
> /Erik
>
>> Dan
>>
>>
>>> Thanks,
>>> /Erik
>>>
>>>> Cheers,
>>>> David
>>>>
>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> Specifically, the man pages for CC say:
>>>>>>>
>>>>>>> <man>
>>>>>>>         -library=lib[,lib...]
>>>>>>>
>>>>>>>             Incorporates  specified  CC-provided libraries into compilation and
>>>>>>>             linking.
>>>>>>>
>>>>>>>             When the -library option is used to specify a CC-provided library,
>>>>>>>             the  proper  -I paths are set during compilation and the proper -L,
>>>>>>>             -Y, -P, and -R paths and -l options are set during linking.
>>>>>>> </man>
>>>>>>>
>>>>>>> As we are setting this during compilation and not during linking, this corresponds to setting the right -I paths to find our C++ standard library headers.
>>>>>>>
>>>>>>> My studio friends mentioned I could double-check that we did indeed not add a dependency to any C++ standard library by running elfdump on the generated libjvm.so file and check if the NEEDED entries in the dynamic section look right. I did and here are the results:
>>>>>>>
>>>>>>>        [0]  NEEDED          0x2918ee   libsocket.so.1
>>>>>>>        [1]  NEEDED          0x2918fd   libsched.so.1
>>>>>>>        [2]  NEEDED          0x29190b   libdl.so.1
>>>>>>>        [3]  NEEDED          0x291916   libm.so.1
>>>>>>>        [4]  NEEDED          0x291920   libCrun.so.1
>>>>>>>        [5]  NEEDED          0x29192d   libthread.so.1
>>>>>>>        [6]  NEEDED          0x29193c   libdoor.so.1
>>>>>>>        [7]  NEEDED          0x291949   libc.so.1
>>>>>>>        [8]  NEEDED          0x291953   libdemangle.so.1
>>>>>>>        [9]  NEEDED          0x291964   libnsl.so.1
>>>>>>>       [10]  NEEDED          0x291970   libkstat.so.1
>>>>>>>       [11]  NEEDED          0x29197e   librt.so.1
>>>>>>>
>>>>>>> This list does not include any C++ standard libraries, as expected (libCrun is always in there even with -library=%none, and as expected no libstlport4.so or libCstd.so files are in there). The NEEDED entries in the dynamic section look identical with and without my patch.
>>>>>>>
>>>>>>>> I'm finding the actual build situation very confusing. It seems to me in looking at the hotspot build files and the top-level build files that -xnolib is used for C++ compilation & linking whereas -library=%none is used for C compilation & linking. But the change is being applied to $2JVM_CFLAGS which one would think is for C compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used for both!
>>>>>>> I have also been confused by this when I tried adding CXX flags through configure that seemed to not be used. But that's a different can of worms I suppose.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> /Erik
>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>>>>>> Hi Kim,
>>>>>>>>>>
>>>>>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Erik,
>>>>>>>>>>>>
>>>>>>>>>>>> A small change with big questions :)
>>>>>>>>>>>>
>>>>>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>>>>>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>>>>> And how does one establish those properties exist for a given header file? Just use it and if no link errors then all is good?
>>>>>>>>> Objects from headers that are not ODR-used such as constant folded expressions are not imposing link-time dependencies to C++ libraries. The -xnolib that we already have in the LDFLAGS will catch any accidental ODR-uses of C++ objects, and the JVM will not build if that happens.
>>>>>>>>>
>>>>>>>>> As for external headers being included and not playing nicely with macros, this has to be evaluated on a case by case basis. Note that this is a problem that occurs when using system headers (that we are already using), as it is for using C++ standard library headers. We even run into that in our own JVM when e.g. the min/max macros occasionally slaps us gently in the face from time to time.
>>>>>>>>>
>>>>>>>>>>> The instigator for this is Erik and I are working on a project that
>>>>>>>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>>>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>>>>>>> would require platform-specific code (with all the complexity that can
>>>>>>>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>>>>>>>> that is trivially accessible in every standard library.
>>>>>>>>>> Understood. I have no issue with using <limits> but am concerned by the state of stlport4. Can you use <limits> without changing -library=%none?
>>>>>>>>> No, that is precisely why we are here.
>>>>>>>>>
>>>>>>>>>>>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>>>>>>>>>>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>>>>>>>>>>>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>>>>>>>>>>>>
>>>>>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>>>>>
>>>>>>>>>>>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?
>>>>>>>>>>> It means we can only use header-only parts of the standard library.
>>>>>>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>>>>>>> providing such limited access while continuing to constrain our
>>>>>>>>>>> dependency on the library.  Figuring out what can be used will need to
>>>>>>>>>>> be determined on a case-by-case basis.  Maybe we could just link with
>>>>>>>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>>>>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>>>>>>>> conservative.
>>>>>>>>>> Okay, but the docs don't seem to acknowledge the ability to use, but not link to, stlport4.
>>>>>>>>> Not ODR-used objects do not require linkage. (http://en.cppreference.com/w/cpp/language/definition)
>>>>>>>>> I have confirmed directly with the studio folks to be certain that accidental linkage would fail by keeping our existing guards in the LDFLAGS rather than the CFLAGS.
>>>>>>>>> This is also reasonably well documented already (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>>>>>
>>>>>>>>>>>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>>>>>>>>>>>>
>>>>>>>>>>>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>>>>>>>>>>>>
>>>>>>>>>>>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>>>>>>>>>>>>
>>>>>>>>>>>> None of that sounds very good to me.
>>>>>>>>>>> I don't see how this is any different from any other part of the
>>>>>>>>>>> process for using a different version of Solaris Studio.
>>>>>>>>>> Well we'd discover the problem when testing the compiler change, but my point was more to the fact that they don't seem very committed to this library - very much a "use at own risk" disclaimer.
>>>>>>>>> If we eventually need to use something more modern for features that have not been around for a decade, like C++11 features, then we can change standard library when that day comes.
>>>>>>>>>
>>>>>>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked the
>>>>>>>>>>> Studio folks which to use (for the purposes of our present project, we
>>>>>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>>>>>> including linking against it, for gtest builds. Mixing two different
>>>>>>>>>>> standard libraries seems like a bad idea...
>>>>>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>>>>>
>>>>>>>>>> My confidence in this has not increased :)
>>>>>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard libraries has more mileage than whatever simplified rewrite of that we try to replicate in the JVM. So it is not obvious to me that we should have less confidence in the same functionality from a standard library shipped together with the compiler we are using and that has already been used and tested in a variety of C++ applications for over a decade compared to the alternative of reinventing it ourselves.
>>>>>>>>>
>>>>>>>>>> What we do in gtest doesn't necessarily make things okay to do in the product.
>>>>>>>>>>
>>>>>>>>>> If this were part of a compiler upgrade process we'd be comparing binaries with old flag and new to ensure there are no unexpected consequences.
>>>>>>>>> I would not compare including <limits> to a compiler upgrade process as we are not changing the compiler and hence not the way code is generated, but rather compare it to including a new system header that has previously not been included to use a constant folded expression from that header that has been used and tested for a decade. At least that is how I think of it.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>>>>>> Testing: JPRT.
>>>>>>>>>>>>> Will need a sponsor.
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> /Erik



From erik.osterlund at oracle.com  Mon Jun  5 17:25:17 2017
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Mon, 5 Jun 2017 19:25:17 +0200
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <cddf2c3e-b20a-1d55-6322-2188fc57b238@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
 <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
 <59358492.7030803@oracle.com>
 <997648e7-2880-a626-f866-8892abee2a5d@oracle.com>
 <D279AD45-2763-429B-BD32-7D3BA0ACA002@oracle.com>
 <cddf2c3e-b20a-1d55-6322-2188fc57b238@oracle.com>
Message-ID: <883AE90B-C118-44E1-A8AF-8B3F7FB61E63@oracle.com>

Hi Dan,

You got that right. :)
Thanks for the review!

/Erik

> On 5 Jun 2017, at 19:22, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
>> On 6/5/17 10:59 AM, Erik Osterlund wrote:
>> Hi Dan,
>> 
>>>> On 5 Jun 2017, at 18:31, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>> 
>>>> On 6/5/17 10:19 AM, Erik ?sterlund wrote:
>>>> Hi David,
>>>> 
>>>>> On 2017-06-05 14:45, David Holmes wrote:
>>>>> Hi Erik,
>>>>> 
>>>>>> On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
>>>>>> Hi David,
>>>>>> 
>>>>>>> On 2017-06-02 03:30, David Holmes wrote:
>>>>>>> Hi Erik,
>>>>>>> 
>>>>>>>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>>>>>>> Hi David,
>>>>>>>> 
>>>>>>>>> On 2017-06-01 14:33, David Holmes wrote:
>>>>>>>>> Hi Erik,
>>>>>>>>> 
>>>>>>>>> Just to be clear it is not the use of <limits> that I am concerned about, it is the -library=stlport4. It is the use of that flag that I would want to check in terms of having no affect on any existing code generation.
>>>>>>>> Thank you for the clarification. The use of -library=stlport4 should not have anything to do with code generation. It only says where to look for the standard library headers such as <limits> that are used in the compilation units.
>>>>>>> The potential problem is that the stlport4 include path eg:
>>>>>>> 
>>>>>>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>>>>>> 
>>>>>>> doesn't only contain the C++ headers (new, limits, string etc) but also a whole bunch of regular 'standard' .h headers that are _different_ to those found outside the stlport4 directory ie the ones we would currently include. I don't know if the differences are significant, nor whether those others may be found ahead of the stlport4 version. But that is my concern about the effects on the code.
>>>>>> While I do not think exchanging these headers will have any behavioral impact, I agree that we can not prove so as they are indeed different header files. That is a good point.
>>>>>> 
>>>>>> However, I think that makes the stlport4 case stronger rather than weaker. We already use stlport4 for our gtest testing (because it is required and does not build without it). And if those headers would indeed have slightly different behaviour as you imply, it further motivates using the same standard library when compiling the product as the testing code. If they were to behave slightly differently, it might be that our gtest tests does not catch hidden bugs that only manifest when building with a different set of headers used for the product build. I therefore find it exceedingly dangerous to stay on two standard libraries (depending on if test code or product code is compiled) compared to consistently using the same standard library across all compilations. So for me, the larger the risk is of them behaving differently is, the bigger the motivation is to use stlport4 consistently.
>>>>> Regardless of what gtest does if you want to switch the standard libraries used by the product then IMHO that should go through a vetting process no weaker than that for changing the toolchain, as you effectively are doing that.
>>>> I talked to Erik Joelsson about how to compare two builds. He introduced me to our compare.sh script that is used to compare two builds.
>>>> I built a baseline without these changes and a new build with these changes applied, both on a Solaris SPARC T7 machine. Then I compared them with ./compare.sh -2dirs {$BUILD1}/hotspot/variant-server/libjvm/objs {$BUILD2}/hotspot/variant-server/libjvm/objs -libs --strip
>>>> 
>>>> This compares the object files produced when compiling hotspot in build 1 and build 2 after stripping symbols.
>>>> 
>>>> First it reported:
>>>> Libraries...
>>>>   Size    : Symbols :  Deps   : Disass   :
>>>>           :* diff  *:         :          : ./dtrace.o
>>>>           :* diff  *:         :*   38918*: ./jni.o
>>>>           :* diff  *:         :*   23226*: ./unsafe.o
>>>> 
>>>> It seems like all symbols were not stripped here on these mentioned files and constituted all differences in the disassembly. So I made a simple sed filter to filter out symbol names in the disassembly with the regexp <.*>.
>>>> 
>>>> The result was:
>>>> Libraries...
>>>>   Size    : Symbols :  Deps   : Disass   :
>>>>           :* diff  *:         :          : ./dtrace.o
>>>>           :* diff  *:         :          : ./jni.o
>>>>           :* diff  *:         :          : ./unsafe.o
>>>> 
>>>> This shows that not a single instruction was emitted differently between the two builds.
>>>> 
>>>> I also did the filtering manually on jni.o and unsafe.o in emacs to make sure I did not mess up.
>>>> 
>>>> Are we happy with this, or do you still have doubts that this might result in different code or behavior?
>>> Just to be clear: The current experiment changes both the header and
>>> the standard library right? If so, then the compare.sh run works for
>>> validating that using the new header file will not result in a change
>>> in behavior. However, that comparison doesn't do anything for testing
>>> a switch in the standard libraries right?
>> The -xnolib guards are still there in the LDFLAGS. That is, the linker will not allow anything to link against either standard library. I have manually confirmed this by doing the sanity check of comparing the NEEDED entries in the dynamic section of the libjvm.so elf file using elfdump. It has no references to neither libstlport4 nor libCstd with or without my changes.
>> 
>> Summary: the changes do not add any linktime dependencies to either standard library, and we are still guarded in the sense that if such dependencies were to accidentally be introduced, it would not build. The only difference then would be slightly different code generation of object files. And their disassemblies have been confirmed not to differ by even a single instruction generated differently.
> 
> So your current changes use the stlport4 include path for both product
> build and 'gtest' build. You've verified the following:
> 
> - The product binaries do not change even one instruction with the
>  new include path.
> - The options to keep us from linking to anything in stlport4 are
>  still in place.
> - You've manually verified that there are no linkage dependencies
>  in the resulting binaries.
> 
> If I have all that right, then I think you've covered your bases.
> 
> Dan
> 
> 
> 
>> 
>> Thanks,
>> /Erik
>> 
>>> Dan
>>> 
>>> 
>>>> Thanks,
>>>> /Erik
>>>> 
>>>>> Cheers,
>>>>> David
>>>>> 
>>>>> 
>>>>>> Thanks,
>>>>>> /Erik
>>>>>> 
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> -----
>>>>>>> 
>>>>>>> 
>>>>>>>> Specifically, the man pages for CC say:
>>>>>>>> 
>>>>>>>> <man>
>>>>>>>>        -library=lib[,lib...]
>>>>>>>> 
>>>>>>>>            Incorporates  specified  CC-provided libraries into compilation and
>>>>>>>>            linking.
>>>>>>>> 
>>>>>>>>            When the -library option is used to specify a CC-provided library,
>>>>>>>>            the  proper  -I paths are set during compilation and the proper -L,
>>>>>>>>            -Y, -P, and -R paths and -l options are set during linking.
>>>>>>>> </man>
>>>>>>>> 
>>>>>>>> As we are setting this during compilation and not during linking, this corresponds to setting the right -I paths to find our C++ standard library headers.
>>>>>>>> 
>>>>>>>> My studio friends mentioned I could double-check that we did indeed not add a dependency to any C++ standard library by running elfdump on the generated libjvm.so file and check if the NEEDED entries in the dynamic section look right. I did and here are the results:
>>>>>>>> 
>>>>>>>>       [0]  NEEDED          0x2918ee   libsocket.so.1
>>>>>>>>       [1]  NEEDED          0x2918fd   libsched.so.1
>>>>>>>>       [2]  NEEDED          0x29190b   libdl.so.1
>>>>>>>>       [3]  NEEDED          0x291916   libm.so.1
>>>>>>>>       [4]  NEEDED          0x291920   libCrun.so.1
>>>>>>>>       [5]  NEEDED          0x29192d   libthread.so.1
>>>>>>>>       [6]  NEEDED          0x29193c   libdoor.so.1
>>>>>>>>       [7]  NEEDED          0x291949   libc.so.1
>>>>>>>>       [8]  NEEDED          0x291953   libdemangle.so.1
>>>>>>>>       [9]  NEEDED          0x291964   libnsl.so.1
>>>>>>>>      [10]  NEEDED          0x291970   libkstat.so.1
>>>>>>>>      [11]  NEEDED          0x29197e   librt.so.1
>>>>>>>> 
>>>>>>>> This list does not include any C++ standard libraries, as expected (libCrun is always in there even with -library=%none, and as expected no libstlport4.so or libCstd.so files are in there). The NEEDED entries in the dynamic section look identical with and without my patch.
>>>>>>>> 
>>>>>>>>> I'm finding the actual build situation very confusing. It seems to me in looking at the hotspot build files and the top-level build files that -xnolib is used for C++ compilation & linking whereas -library=%none is used for C compilation & linking. But the change is being applied to $2JVM_CFLAGS which one would think is for C compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used for both!
>>>>>>>> I have also been confused by this when I tried adding CXX flags through configure that seemed to not be used. But that's a different can of worms I suppose.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> /Erik
>>>>>>>> 
>>>>>>>>> David
>>>>>>>>> 
>>>>>>>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>> 
>>>>>>>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>>>>>>> Hi Kim,
>>>>>>>>>>> 
>>>>>>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Erik,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> A small change with big questions :)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>>>>>>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>>>>>> And how does one establish those properties exist for a given header file? Just use it and if no link errors then all is good?
>>>>>>>>>> Objects from headers that are not ODR-used such as constant folded expressions are not imposing link-time dependencies to C++ libraries. The -xnolib that we already have in the LDFLAGS will catch any accidental ODR-uses of C++ objects, and the JVM will not build if that happens.
>>>>>>>>>> 
>>>>>>>>>> As for external headers being included and not playing nicely with macros, this has to be evaluated on a case by case basis. Note that this is a problem that occurs when using system headers (that we are already using), as it is for using C++ standard library headers. We even run into that in our own JVM when e.g. the min/max macros occasionally slaps us gently in the face from time to time.
>>>>>>>>>> 
>>>>>>>>>>>> The instigator for this is Erik and I are working on a project that
>>>>>>>>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>>>>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>>>>>>>> would require platform-specific code (with all the complexity that can
>>>>>>>>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>>>>>>>>> that is trivially accessible in every standard library.
>>>>>>>>>>> Understood. I have no issue with using <limits> but am concerned by the state of stlport4. Can you use <limits> without changing -library=%none?
>>>>>>>>>> No, that is precisely why we are here.
>>>>>>>>>> 
>>>>>>>>>>>>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>>>>>>>>>>>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>>>>>>>>>>>>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?
>>>>>>>>>>>> It means we can only use header-only parts of the standard library.
>>>>>>>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>>>>>>>> providing such limited access while continuing to constrain our
>>>>>>>>>>>> dependency on the library.  Figuring out what can be used will need to
>>>>>>>>>>>> be determined on a case-by-case basis.  Maybe we could just link with
>>>>>>>>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>>>>>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>>>>>>>>> conservative.
>>>>>>>>>>> Okay, but the docs don't seem to acknowledge the ability to use, but not link to, stlport4.
>>>>>>>>>> Not ODR-used objects do not require linkage. (http://en.cppreference.com/w/cpp/language/definition)
>>>>>>>>>> I have confirmed directly with the studio folks to be certain that accidental linkage would fail by keeping our existing guards in the LDFLAGS rather than the CFLAGS.
>>>>>>>>>> This is also reasonably well documented already (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>>>>>> 
>>>>>>>>>>>>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>>>>>>>>>>>>> 
>>>>>>>>>>>>> None of that sounds very good to me.
>>>>>>>>>>>> I don't see how this is any different from any other part of the
>>>>>>>>>>>> process for using a different version of Solaris Studio.
>>>>>>>>>>> Well we'd discover the problem when testing the compiler change, but my point was more to the fact that they don't seem very committed to this library - very much a "use at own risk" disclaimer.
>>>>>>>>>> If we eventually need to use something more modern for features that have not been around for a decade, like C++11 features, then we can change standard library when that day comes.
>>>>>>>>>> 
>>>>>>>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked the
>>>>>>>>>>>> Studio folks which to use (for the purposes of our present project, we
>>>>>>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>>>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>>>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>>>>>>> including linking against it, for gtest builds. Mixing two different
>>>>>>>>>>>> standard libraries seems like a bad idea...
>>>>>>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>>>>>> 
>>>>>>>>>>> My confidence in this has not increased :)
>>>>>>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard libraries has more mileage than whatever simplified rewrite of that we try to replicate in the JVM. So it is not obvious to me that we should have less confidence in the same functionality from a standard library shipped together with the compiler we are using and that has already been used and tested in a variety of C++ applications for over a decade compared to the alternative of reinventing it ourselves.
>>>>>>>>>> 
>>>>>>>>>>> What we do in gtest doesn't necessarily make things okay to do in the product.
>>>>>>>>>>> 
>>>>>>>>>>> If this were part of a compiler upgrade process we'd be comparing binaries with old flag and new to ensure there are no unexpected consequences.
>>>>>>>>>> I would not compare including <limits> to a compiler upgrade process as we are not changing the compiler and hence not the way code is generated, but rather compare it to including a new system header that has previously not been included to use a constant folded expression from that header that has been used and tested for a decade. At least that is how I think of it.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> /Erik
>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> David
>>>>>>>>>>> 
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>>>>>>> Testing: JPRT.
>>>>>>>>>>>>>> Will need a sponsor.
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> /Erik
> 



From david.holmes at oracle.com  Mon Jun  5 21:39:18 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 6 Jun 2017 07:39:18 +1000
Subject: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
In-Reply-To: <883AE90B-C118-44E1-A8AF-8B3F7FB61E63@oracle.com>
References: <592EC8F6.5080605@oracle.com>
 <0cfb3eb8-a19b-60f8-fdb1-249dc4798e7c@oracle.com>
 <D2B81771-9CD5-412A-9E46-ED9CDF242272@oracle.com>
 <e2bc3cf0-74de-1cf6-0a80-51b2d7ecd2ee@oracle.com> <592FE000.50003@oracle.com>
 <d7cde5bc-7fbf-e00d-43f0-1bce795dfc2a@oracle.com>
 <593029CB.7000100@oracle.com>
 <f86f1556-2593-0793-df37-1b259e4f326d@oracle.com>
 <593534BD.1090805@oracle.com>
 <e7b7e5d7-378a-a7d3-6ef9-5db23633b88c@oracle.com>
 <59358492.7030803@oracle.com>
 <997648e7-2880-a626-f866-8892abee2a5d@oracle.com>
 <D279AD45-2763-429B-BD32-7D3BA0ACA002@oracle.com>
 <cddf2c3e-b20a-1d55-6322-2188fc57b238@oracle.com>
 <883AE90B-C118-44E1-A8AF-8B3F7FB61E63@oracle.com>
Message-ID: <bcca9f6a-a6b7-caca-0841-4fe0a6872389@oracle.com>

Hi Erik,

Thanks - yes this is the level of checking that was needed.

Cheers,
David

On 6/06/2017 3:25 AM, Erik Osterlund wrote:
> Hi Dan,
> 
> You got that right. :)
> Thanks for the review!
> 
> /Erik
> 
>> On 5 Jun 2017, at 19:22, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>>> On 6/5/17 10:59 AM, Erik Osterlund wrote:
>>> Hi Dan,
>>>
>>>>> On 5 Jun 2017, at 18:31, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>>>
>>>>> On 6/5/17 10:19 AM, Erik ?sterlund wrote:
>>>>> Hi David,
>>>>>
>>>>>> On 2017-06-05 14:45, David Holmes wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>>> On 5/06/2017 8:38 PM, Erik ?sterlund wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> On 2017-06-02 03:30, David Holmes wrote:
>>>>>>>> Hi Erik,
>>>>>>>>
>>>>>>>>> On 2/06/2017 12:50 AM, Erik ?sterlund wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>>> On 2017-06-01 14:33, David Holmes wrote:
>>>>>>>>>> Hi Erik,
>>>>>>>>>>
>>>>>>>>>> Just to be clear it is not the use of <limits> that I am concerned about, it is the -library=stlport4. It is the use of that flag that I would want to check in terms of having no affect on any existing code generation.
>>>>>>>>> Thank you for the clarification. The use of -library=stlport4 should not have anything to do with code generation. It only says where to look for the standard library headers such as <limits> that are used in the compilation units.
>>>>>>>> The potential problem is that the stlport4 include path eg:
>>>>>>>>
>>>>>>>> ./SS12u4/lib/compilers/include/CC/stlport4/
>>>>>>>>
>>>>>>>> doesn't only contain the C++ headers (new, limits, string etc) but also a whole bunch of regular 'standard' .h headers that are _different_ to those found outside the stlport4 directory ie the ones we would currently include. I don't know if the differences are significant, nor whether those others may be found ahead of the stlport4 version. But that is my concern about the effects on the code.
>>>>>>> While I do not think exchanging these headers will have any behavioral impact, I agree that we can not prove so as they are indeed different header files. That is a good point.
>>>>>>>
>>>>>>> However, I think that makes the stlport4 case stronger rather than weaker. We already use stlport4 for our gtest testing (because it is required and does not build without it). And if those headers would indeed have slightly different behaviour as you imply, it further motivates using the same standard library when compiling the product as the testing code. If they were to behave slightly differently, it might be that our gtest tests does not catch hidden bugs that only manifest when building with a different set of headers used for the product build. I therefore find it exceedingly dangerous to stay on two standard libraries (depending on if test code or product code is compiled) compared to consistently using the same standard library across all compilations. So for me, the larger the risk is of them behaving differently is, the bigger the motivation is to use stlport4 consistently.
>>>>>> Regardless of what gtest does if you want to switch the standard libraries used by the product then IMHO that should go through a vetting process no weaker than that for changing the toolchain, as you effectively are doing that.
>>>>> I talked to Erik Joelsson about how to compare two builds. He introduced me to our compare.sh script that is used to compare two builds.
>>>>> I built a baseline without these changes and a new build with these changes applied, both on a Solaris SPARC T7 machine. Then I compared them with ./compare.sh -2dirs {$BUILD1}/hotspot/variant-server/libjvm/objs {$BUILD2}/hotspot/variant-server/libjvm/objs -libs --strip
>>>>>
>>>>> This compares the object files produced when compiling hotspot in build 1 and build 2 after stripping symbols.
>>>>>
>>>>> First it reported:
>>>>> Libraries...
>>>>>    Size    : Symbols :  Deps   : Disass   :
>>>>>            :* diff  *:         :          : ./dtrace.o
>>>>>            :* diff  *:         :*   38918*: ./jni.o
>>>>>            :* diff  *:         :*   23226*: ./unsafe.o
>>>>>
>>>>> It seems like all symbols were not stripped here on these mentioned files and constituted all differences in the disassembly. So I made a simple sed filter to filter out symbol names in the disassembly with the regexp <.*>.
>>>>>
>>>>> The result was:
>>>>> Libraries...
>>>>>    Size    : Symbols :  Deps   : Disass   :
>>>>>            :* diff  *:         :          : ./dtrace.o
>>>>>            :* diff  *:         :          : ./jni.o
>>>>>            :* diff  *:         :          : ./unsafe.o
>>>>>
>>>>> This shows that not a single instruction was emitted differently between the two builds.
>>>>>
>>>>> I also did the filtering manually on jni.o and unsafe.o in emacs to make sure I did not mess up.
>>>>>
>>>>> Are we happy with this, or do you still have doubts that this might result in different code or behavior?
>>>> Just to be clear: The current experiment changes both the header and
>>>> the standard library right? If so, then the compare.sh run works for
>>>> validating that using the new header file will not result in a change
>>>> in behavior. However, that comparison doesn't do anything for testing
>>>> a switch in the standard libraries right?
>>> The -xnolib guards are still there in the LDFLAGS. That is, the linker will not allow anything to link against either standard library. I have manually confirmed this by doing the sanity check of comparing the NEEDED entries in the dynamic section of the libjvm.so elf file using elfdump. It has no references to neither libstlport4 nor libCstd with or without my changes.
>>>
>>> Summary: the changes do not add any linktime dependencies to either standard library, and we are still guarded in the sense that if such dependencies were to accidentally be introduced, it would not build. The only difference then would be slightly different code generation of object files. And their disassemblies have been confirmed not to differ by even a single instruction generated differently.
>>
>> So your current changes use the stlport4 include path for both product
>> build and 'gtest' build. You've verified the following:
>>
>> - The product binaries do not change even one instruction with the
>>   new include path.
>> - The options to keep us from linking to anything in stlport4 are
>>   still in place.
>> - You've manually verified that there are no linkage dependencies
>>   in the resulting binaries.
>>
>> If I have all that right, then I think you've covered your bases.
>>
>> Dan
>>
>>
>>
>>>
>>> Thanks,
>>> /Erik
>>>
>>>> Dan
>>>>
>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> /Erik
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>
>>>>>>>>> Specifically, the man pages for CC say:
>>>>>>>>>
>>>>>>>>> <man>
>>>>>>>>>         -library=lib[,lib...]
>>>>>>>>>
>>>>>>>>>             Incorporates  specified  CC-provided libraries into compilation and
>>>>>>>>>             linking.
>>>>>>>>>
>>>>>>>>>             When the -library option is used to specify a CC-provided library,
>>>>>>>>>             the  proper  -I paths are set during compilation and the proper -L,
>>>>>>>>>             -Y, -P, and -R paths and -l options are set during linking.
>>>>>>>>> </man>
>>>>>>>>>
>>>>>>>>> As we are setting this during compilation and not during linking, this corresponds to setting the right -I paths to find our C++ standard library headers.
>>>>>>>>>
>>>>>>>>> My studio friends mentioned I could double-check that we did indeed not add a dependency to any C++ standard library by running elfdump on the generated libjvm.so file and check if the NEEDED entries in the dynamic section look right. I did and here are the results:
>>>>>>>>>
>>>>>>>>>        [0]  NEEDED          0x2918ee   libsocket.so.1
>>>>>>>>>        [1]  NEEDED          0x2918fd   libsched.so.1
>>>>>>>>>        [2]  NEEDED          0x29190b   libdl.so.1
>>>>>>>>>        [3]  NEEDED          0x291916   libm.so.1
>>>>>>>>>        [4]  NEEDED          0x291920   libCrun.so.1
>>>>>>>>>        [5]  NEEDED          0x29192d   libthread.so.1
>>>>>>>>>        [6]  NEEDED          0x29193c   libdoor.so.1
>>>>>>>>>        [7]  NEEDED          0x291949   libc.so.1
>>>>>>>>>        [8]  NEEDED          0x291953   libdemangle.so.1
>>>>>>>>>        [9]  NEEDED          0x291964   libnsl.so.1
>>>>>>>>>       [10]  NEEDED          0x291970   libkstat.so.1
>>>>>>>>>       [11]  NEEDED          0x29197e   librt.so.1
>>>>>>>>>
>>>>>>>>> This list does not include any C++ standard libraries, as expected (libCrun is always in there even with -library=%none, and as expected no libstlport4.so or libCstd.so files are in there). The NEEDED entries in the dynamic section look identical with and without my patch.
>>>>>>>>>
>>>>>>>>>> I'm finding the actual build situation very confusing. It seems to me in looking at the hotspot build files and the top-level build files that -xnolib is used for C++ compilation & linking whereas -library=%none is used for C compilation & linking. But the change is being applied to $2JVM_CFLAGS which one would think is for C compilation but we don't have $2JVM_CXXFLAGS, so it seems to be used for both!
>>>>>>>>> I have also been confused by this when I tried adding CXX flags through configure that seemed to not be used. But that's a different can of worms I suppose.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> On 1/06/2017 7:36 PM, Erik ?sterlund wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>>> On 2017-06-01 08:09, David Holmes wrote:
>>>>>>>>>>>> Hi Kim,
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/06/2017 3:51 PM, Kim Barrett wrote:
>>>>>>>>>>>>>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Erik,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A small change with big questions :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 31/05/2017 11:45 PM, Erik ?sterlund wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>>>>>>>>>>>>>> What does a 'harmless' C++ standard library header look like?
>>>>>>>>>>>>> Header-only (doesn't require linking), doesn't run afoul of our
>>>>>>>>>>>>> [vm]assert macro, and provides functionality we presently lack (or
>>>>>>>>>>>>> only handle poorly) and would not be easy to reproduce.
>>>>>>>>>>>> And how does one establish those properties exist for a given header file? Just use it and if no link errors then all is good?
>>>>>>>>>>> Objects from headers that are not ODR-used such as constant folded expressions are not imposing link-time dependencies to C++ libraries. The -xnolib that we already have in the LDFLAGS will catch any accidental ODR-uses of C++ objects, and the JVM will not build if that happens.
>>>>>>>>>>>
>>>>>>>>>>> As for external headers being included and not playing nicely with macros, this has to be evaluated on a case by case basis. Note that this is a problem that occurs when using system headers (that we are already using), as it is for using C++ standard library headers. We even run into that in our own JVM when e.g. the min/max macros occasionally slaps us gently in the face from time to time.
>>>>>>>>>>>
>>>>>>>>>>>>> The instigator for this is Erik and I are working on a project that
>>>>>>>>>>>>> needs information that is present in std::numeric_limits<> (provided
>>>>>>>>>>>>> by the <limits> header).  Reproducing that functionality ourselves
>>>>>>>>>>>>> would require platform-specific code (with all the complexity that can
>>>>>>>>>>>>> imply).  We'd really rather not re-discover and maintain information
>>>>>>>>>>>>> that is trivially accessible in every standard library.
>>>>>>>>>>>> Understood. I have no issue with using <limits> but am concerned by the state of stlport4. Can you use <limits> without changing -library=%none?
>>>>>>>>>>> No, that is precisely why we are here.
>>>>>>>>>>>
>>>>>>>>>>>>>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>>>>>>>>>>>>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>>>>>>>>>>>>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>>>>>>>>>>>>>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport?s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4?
>>>>>>>>>>>>> It means we can only use header-only parts of the standard library.
>>>>>>>>>>>>> This was confirmed / suggested by the Studio folks Erik consulted,
>>>>>>>>>>>>> providing such limited access while continuing to constrain our
>>>>>>>>>>>>> dependency on the library.  Figuring out what can be used will need to
>>>>>>>>>>>>> be determined on a case-by-case basis.  Maybe we could just link with
>>>>>>>>>>>>> a standard library on Solaris too.  So far as I can tell, Solaris is
>>>>>>>>>>>>> the only platform where we don't do that.  But Erik is trying to be
>>>>>>>>>>>>> conservative.
>>>>>>>>>>>> Okay, but the docs don't seem to acknowledge the ability to use, but not link to, stlport4.
>>>>>>>>>>> Not ODR-used objects do not require linkage. (http://en.cppreference.com/w/cpp/language/definition)
>>>>>>>>>>> I have confirmed directly with the studio folks to be certain that accidental linkage would fail by keeping our existing guards in the LDFLAGS rather than the CFLAGS.
>>>>>>>>>>> This is also reasonably well documented already (https://docs.oracle.com/cd/E19205-01/819-5267/bkbeq/index.html).
>>>>>>>>>>>
>>>>>>>>>>>>>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> None of that sounds very good to me.
>>>>>>>>>>>>> I don't see how this is any different from any other part of the
>>>>>>>>>>>>> process for using a different version of Solaris Studio.
>>>>>>>>>>>> Well we'd discover the problem when testing the compiler change, but my point was more to the fact that they don't seem very committed to this library - very much a "use at own risk" disclaimer.
>>>>>>>>>>> If we eventually need to use something more modern for features that have not been around for a decade, like C++11 features, then we can change standard library when that day comes.
>>>>>>>>>>>
>>>>>>>>>>>>> stlport4 is one of the three standard libraries that are presently
>>>>>>>>>>>>> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked the
>>>>>>>>>>>>> Studio folks which to use (for the purposes of our present project, we
>>>>>>>>>>>>> don't have any particular preference, so long as it works), and
>>>>>>>>>>>>> stlport4 seemed the right choice (libCstd was, I think, described as
>>>>>>>>>>>>> "ancient").  Perhaps more importantly, we already use stlport4,
>>>>>>>>>>>>> including linking against it, for gtest builds. Mixing two different
>>>>>>>>>>>>> standard libraries seems like a bad idea...
>>>>>>>>>>>> So we have the choice of "ancient", "unsupported" or gcc :)
>>>>>>>>>>>>
>>>>>>>>>>>> My confidence in this has not increased :)
>>>>>>>>>>> I trust that e.g. std::numeric_limits<T>::is_signed in the standard libraries has more mileage than whatever simplified rewrite of that we try to replicate in the JVM. So it is not obvious to me that we should have less confidence in the same functionality from a standard library shipped together with the compiler we are using and that has already been used and tested in a variety of C++ applications for over a decade compared to the alternative of reinventing it ourselves.
>>>>>>>>>>>
>>>>>>>>>>>> What we do in gtest doesn't necessarily make things okay to do in the product.
>>>>>>>>>>>>
>>>>>>>>>>>> If this were part of a compiler upgrade process we'd be comparing binaries with old flag and new to ensure there are no unexpected consequences.
>>>>>>>>>>> I would not compare including <limits> to a compiler upgrade process as we are not changing the compiler and hence not the way code is generated, but rather compare it to including a new system header that has previously not been included to use a constant folded expression from that header that has been used and tested for a decade. At least that is how I think of it.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> /Erik
>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Webrev for jdk10-hs top level repository:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
>>>>>>>>>>>>>>> Webrev for jdk10-hs hotspot repository:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
>>>>>>>>>>>>>>> Testing: JPRT.
>>>>>>>>>>>>>>> Will need a sponsor.
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> /Erik
>>
> 


From matcdac at gmail.com  Mon Jun  5 21:47:24 2017
From: matcdac at gmail.com (Prakhar Makhija)
Date: Tue, 6 Jun 2017 03:17:24 +0530
Subject: JDK / JRE jar
Message-ID: <CAPu805qWSD6pCsr_6viwstf6NPt4A-4z-jWkFekf3A3dV7MOFg@mail.gmail.com>

Hi,

Could you please tell me how to make jar out of src.zip, which is placed in
Java installation directory?

Would that be enough to override the JVM of the older Java version?


Scenario:

I have say JDK 6 installed on my machine and it's path is set.

I have to run and deploy of Java 8 code without installing Java 8.

There is provision for jar to be added.

How to do it?

Is it possible?


From jonathan.gibbons at oracle.com  Mon Jun  5 21:57:12 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Jun 2017 14:57:12 -0700
Subject: JDK / JRE jar
In-Reply-To: <CAPu805qWSD6pCsr_6viwstf6NPt4A-4z-jWkFekf3A3dV7MOFg@mail.gmail.com>
References: <CAPu805qWSD6pCsr_6viwstf6NPt4A-4z-jWkFekf3A3dV7MOFg@mail.gmail.com>
Message-ID: <5935D3B8.90800@oracle.com>

You need to install JDK 8 to run Java 8 code.

-- Jon

On 06/05/2017 02:47 PM, Prakhar Makhija wrote:
> Hi,
>
> Could you please tell me how to make jar out of src.zip, which is placed in
> Java installation directory?
>
> Would that be enough to override the JVM of the older Java version?
>
>
> Scenario:
>
> I have say JDK 6 installed on my machine and it's path is set.
>
> I have to run and deploy of Java 8 code without installing Java 8.
>
> There is provision for jar to be added.
>
> How to do it?
>
> Is it possible?



From DakshinS at advisory.com  Tue Jun  6 04:55:52 2017
From: DakshinS at advisory.com (Dakshinamoorthi, Soundararajan)
Date: Tue, 6 Jun 2017 04:55:52 +0000
Subject: JDK / JRE jar
In-Reply-To: <5935D3B8.90800@oracle.com>
References: <CAPu805qWSD6pCsr_6viwstf6NPt4A-4z-jWkFekf3A3dV7MOFg@mail.gmail.com>
 <5935D3B8.90800@oracle.com>
Message-ID: <E16E36D4-2EFB-459F-9A16-532CF2457332@advisory.com>

It?s ok to install java 8 side-by-side java 6. If you are hesitant to install copy the JDK 1.8 directory from some other machine and put it in your machine (of same architecture) and setup your application path etc., to use them.

BR,
Soundararajan

> On 06-Jun-2017, at 03:27, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> You need to install JDK 8 to run Java 8 code.
> 
> -- Jon
> 
> On 06/05/2017 02:47 PM, Prakhar Makhija wrote:
>> Hi,
>> 
>> Could you please tell me how to make jar out of src.zip, which is placed in
>> Java installation directory?
>> 
>> Would that be enough to override the JVM of the older Java version?
>> 
>> 
>> Scenario:
>> 
>> I have say JDK 6 installed on my machine and it's path is set.
>> 
>> I have to run and deploy of Java 8 code without installing Java 8.
>> 
>> There is provision for jar to be added.
>> 
>> How to do it?
>> 
>> Is it possible?
> 


From rob.mckenna at oracle.com  Tue Jun  6 17:01:43 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 6 Jun 2017 18:01:43 +0100
Subject: [jdk10 & jdk8u] Request for Review: 8173654
Message-ID: <20170606170143.GL4512@vimes>

Hi folks,

We've found it useful to be able to override LIBJAVA_SRC_DIRS /
LIBJAVA_MAPFILE in libjava. This change in 10 allows the former and
backports the latter to 8:

http://cr.openjdk.java.net/~robm/8173654/

Thanks,

    -Rob



From erik.joelsson at oracle.com  Wed Jun  7 07:16:03 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 7 Jun 2017 09:16:03 +0200
Subject: [jdk10 & jdk8u] Request for Review: 8173654
In-Reply-To: <20170606170143.GL4512@vimes>
References: <20170606170143.GL4512@vimes>
Message-ID: <b632107c-aed6-1436-990c-1c6985e94f3e@oracle.com>

The 8u change looks good. In JKD 10 (as well as 9) we have created a 
macro to handle this so please use something like this:

# Hook to include the corresponding custom file, if present.
$(eval $(call IncludeCustomExtension, jdk, lib/CoreLibraries.gmk))

/Erik


On 2017-06-06 19:01, Rob McKenna wrote:
> Hi folks,
>
> We've found it useful to be able to override LIBJAVA_SRC_DIRS /
> LIBJAVA_MAPFILE in libjava. This change in 10 allows the former and
> backports the latter to 8:
>
> http://cr.openjdk.java.net/~robm/8173654/
>
> Thanks,
>
>      -Rob
>



From sgehwolf at redhat.com  Wed Jun  7 09:29:39 2017
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 07 Jun 2017 11:29:39 +0200
Subject: Cannot link against memset_with_concurrent_readers_sparc.cpp
In-Reply-To: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
References: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
Message-ID: <1496827779.3701.5.camel@redhat.com>

Hi,

On Wed, 2017-06-07 at 02:10 +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I'm still working on fixing OpenJDK-9 on Linux/sparc64 and I'm currently
> running into something which should be a trivial Makefile issue which
> is a linker problem (see for the paste below, full log in [1]).
> 
> Now, the problem obviously happens on SPARC only because it has its own
> custom implementation of the memset_with_concurrent_readers() function
> in ./src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp, the
> other platforms use ./src/share/vm/gc/shared/memset_with_concurrent_readers.hpp.
> 
> From the full build log, it's obvious that memset_with_concurrent_readers_sparc.cpp
> is being compiled earlier, but it's apparently missing on the linker command
> line later.
> 
> I have been trying to understand the hand-written Makefiles but I can't
> seem to find the place which I need to patch.
> 
> Does anyone who is more familiar with the build system have an idea
> where to look?

This is likely a question for build-dev (CC). They might have some
pointers.

Thanks,
Severin

> Thanks,
> Adrian
> 
> > [1] http://people.debian.org/~glaubitz/openjdk-9_9~b170-2_sparc64.build.gz
> 
> === Output from failing command(s) repeated here ===
> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n"
> * For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
> (/bin/grep -v -e "^Note: including file:" <
> /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log || true) | /usr/bin/head -n 12
> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/gtest/objs/test_memset_with_concurrent_readers.o: In function
> `gc_memset_with_concurrent_readers_test_Test::TestBody()':
> ./src/hotspot/make/./src/hotspot/test/native/gc/shared/test_memset_with_concurrent_readers.cpp:66: undefined reference to `memset_with_concurrent_readers(void*,
> int, unsigned long)'
> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetSharedArray::fill_range(unsigned long, unsigned long,
> unsigned char)':
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
> more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
> collect2: error: ld returned 1 exit status
> if test `/usr/bin/wc -l < /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` -gt 12; then
> /bin/echo "???... (rest of output omitted)" ; fi
> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n"
> * For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:
> (/bin/grep -v -e "^Note: including file:" <??/<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log ||
> true) | /usr/bin/head -n 12
> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetSharedArray::fill_range(unsigned long, unsigned long,
> unsigned char)':
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
> more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
> collect2: error: ld returned 1 exit status
> if test `/usr/bin/wc -l < /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then /bin/echo "
> ? ... (rest of output omitted)" ; fi
> /usr/bin/printf "\n* All command lines available in /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs.\n"
> 
> * All command lines available in /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs.
> /usr/bin/printf "=== End of repeated output ===\n"
> === End of repeated output ===
> if /bin/grep -q "recipe for target .* failed" /<<PKGBUILDDIR>>/build-zero/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here
> ===\n" ; /bin/grep "recipe for target .* failed" /<<PKGBUILDDIR>>/build-zero/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf
> "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ;
> /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi
> 
> === Make failed targets repeated here ===
> lib/CompileJvm.gmk:212: recipe for target '/<<PKGBUILDDIR>>/build-zero/support/modules_libs/java.base/server/libjvm.so' failed
> lib/CompileGtest.gmk:64: recipe for target '/<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/gtest/libjvm.so' failed
> make/Main.gmk:263: recipe for target 'hotspot-zero-libs' failed
> === End of repeated output ===
> 



From glaubitz at physik.fu-berlin.de  Wed Jun  7 09:34:21 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 7 Jun 2017 11:34:21 +0200
Subject: Cannot link against memset_with_concurrent_readers_sparc.cpp
In-Reply-To: <1496827779.3701.5.camel@redhat.com>
References: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
 <1496827779.3701.5.camel@redhat.com>
Message-ID: <20170607093421.GC6481@physik.fu-berlin.de>

On Wed, Jun 07, 2017 at 11:29:39AM +0200, Severin Gehwolf wrote:
> > Does anyone who is more familiar with the build system have an idea
> > where to look?
> 
> This is likely a question for build-dev (CC). They might have some
> pointers.

Ok, thanks, I'll ask over there.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Wed Jun  7 10:05:26 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 7 Jun 2017 12:05:26 +0200
Subject: Cannot link against memset_with_concurrent_readers_sparc.cpp
In-Reply-To: <1496827779.3701.5.camel@redhat.com>
References: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
 <1496827779.3701.5.camel@redhat.com>
Message-ID: <7cafff82-8413-ea5b-ebde-7479f9337570@oracle.com>

Hello John,

If the cpp file is compiled for libjvm.so, the object file should 
automatically end up on the link command line. I found your build log in 
the original email. The link command line is:

/usr/bin/sparc64-linux-gnu-g++-6 -Wl,-z,defs -Wl,-z,noexecstack -Wl,-O1 
-Wl,-z,relro -shared -Xlinker -z -Xli
nker relro -Xlinker -Bsymbolic-functions 
-Wl,-version-script=/<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/l
ibjvm/mapfile -Wl,-soname=libjvm.so -o 
/<<PKGBUILDDIR>>/build-zero/support/modules_libs/java.base/server/libjvm
.so 
@/<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt 
-lm -ldl -l
pthread -lffi_pic

Can you check the contents of this file to verify that the object file 
in question is actually missing:

/<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt 


/Erik

On 2017-06-07 11:29, Severin Gehwolf wrote:
> Hi,
>
> On Wed, 2017-06-07 at 02:10 +0200, John Paul Adrian Glaubitz wrote:
>> Hi!
>>
>> I'm still working on fixing OpenJDK-9 on Linux/sparc64 and I'm currently
>> running into something which should be a trivial Makefile issue which
>> is a linker problem (see for the paste below, full log in [1]).
>>
>> Now, the problem obviously happens on SPARC only because it has its own
>> custom implementation of the memset_with_concurrent_readers() function
>> in ./src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp, the
>> other platforms use ./src/share/vm/gc/shared/memset_with_concurrent_readers.hpp.
>>
>>  From the full build log, it's obvious that memset_with_concurrent_readers_sparc.cpp
>> is being compiled earlier, but it's apparently missing on the linker command
>> line later.
>>
>> I have been trying to understand the hand-written Makefiles but I can't
>> seem to find the place which I need to patch.
>>
>> Does anyone who is more familiar with the build system have an idea
>> where to look?
> This is likely a question for build-dev (CC). They might have some
> pointers.
>
> Thanks,
> Severin
>
>> Thanks,
>> Adrian
>>
>>> [1] http://people.debian.org/~glaubitz/openjdk-9_9~b170-2_sparc64.build.gz
>> === Output from failing command(s) repeated here ===
>> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n"
>> * For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
>> (/bin/grep -v -e "^Note: including file:" <
>> /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log || true) | /usr/bin/head -n 12
>> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/gtest/objs/test_memset_with_concurrent_readers.o: In function
>> `gc_memset_with_concurrent_readers_test_Test::TestBody()':
>> ./src/hotspot/make/./src/hotspot/test/native/gc/shared/test_memset_with_concurrent_readers.cpp:66: undefined reference to `memset_with_concurrent_readers(void*,
>> int, unsigned long)'
>> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetSharedArray::fill_range(unsigned long, unsigned long,
>> unsigned char)':
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
>> more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
>> collect2: error: ld returned 1 exit status
>> if test `/usr/bin/wc -l < /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` -gt 12; then
>> /bin/echo "   ... (rest of output omitted)" ; fi
>> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n"
>> * For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:
>> (/bin/grep -v -e "^Note: including file:" <  /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log ||
>> true) | /usr/bin/head -n 12
>> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetSharedArray::fill_range(unsigned long, unsigned long,
>> unsigned char)':
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> ./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
>> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:./src/hotspot/make/./src/hotspot/src/share/vm/gc/shared/blockOffsetTable.hpp:159:
>> more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
>> collect2: error: ld returned 1 exit status
>> if test `/usr/bin/wc -l < /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then /bin/echo "
>>    ... (rest of output omitted)" ; fi
>> /usr/bin/printf "\n* All command lines available in /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs.\n"
>>
>> * All command lines available in /<<PKGBUILDDIR>>/build-zero/make-support/failure-logs.
>> /usr/bin/printf "=== End of repeated output ===\n"
>> === End of repeated output ===
>> if /bin/grep -q "recipe for target .* failed" /<<PKGBUILDDIR>>/build-zero/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here
>> ===\n" ; /bin/grep "recipe for target .* failed" /<<PKGBUILDDIR>>/build-zero/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf
>> "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ;
>> /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi
>>
>> === Make failed targets repeated here ===
>> lib/CompileJvm.gmk:212: recipe for target '/<<PKGBUILDDIR>>/build-zero/support/modules_libs/java.base/server/libjvm.so' failed
>> lib/CompileGtest.gmk:64: recipe for target '/<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/gtest/libjvm.so' failed
>> make/Main.gmk:263: recipe for target 'hotspot-zero-libs' failed
>> === End of repeated output ===
>>



From glaubitz at physik.fu-berlin.de  Wed Jun  7 11:05:06 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 7 Jun 2017 13:05:06 +0200
Subject: Cannot link against memset_with_concurrent_readers_sparc.cpp
In-Reply-To: <7cafff82-8413-ea5b-ebde-7479f9337570@oracle.com>
References: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
 <1496827779.3701.5.camel@redhat.com>
 <7cafff82-8413-ea5b-ebde-7479f9337570@oracle.com>
Message-ID: <20170607110506.GF6481@physik.fu-berlin.de>

On Wed, Jun 07, 2017 at 12:05:26PM +0200, Erik Joelsson wrote:
> Can you check the contents of this file to verify that the object file in
> question is actually missing:
> 
> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt

Yes, it's missing, see [1].

Adrian

> [1] https://people.debian.org/~glaubitz/_BUILD_LIBJVM_objectfilenames.txt

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From mikael.gerdin at oracle.com  Wed Jun  7 11:42:47 2017
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 7 Jun 2017 13:42:47 +0200
Subject: Cannot link against memset_with_concurrent_readers_sparc.cpp
In-Reply-To: <20170607110506.GF6481@physik.fu-berlin.de>
References: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
 <1496827779.3701.5.camel@redhat.com>
 <7cafff82-8413-ea5b-ebde-7479f9337570@oracle.com>
 <20170607110506.GF6481@physik.fu-berlin.de>
Message-ID: <9e6409be-5823-bef4-96ec-2c4603c41ecc@oracle.com>

Hi,

On 2017-06-07 13:05, John Paul Adrian Glaubitz wrote:
> On Wed, Jun 07, 2017 at 12:05:26PM +0200, Erik Joelsson wrote:
>> Can you check the contents of this file to verify that the object file in
>> question is actually missing:
>>
>> /<<PKGBUILDDIR>>/build-zero/hotspot/variant-zero/libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt
> 
> Yes, it's missing, see [1].
> 

I think the problem is that your build configuration is ZERO but the 
file memset_with_concurrent_readers_sparc.cpp is in the cpu/sparc 
directory and will only be visible if building a native (non-zero) SPARC 
config.

Perhaps there is a mismatch between -DSPARC and the source directory 
selection?

/MIkael

> Adrian
> 
>> [1] https://people.debian.org/~glaubitz/_BUILD_LIBJVM_objectfilenames.txt
> 


From glaubitz at physik.fu-berlin.de  Wed Jun  7 11:49:47 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 7 Jun 2017 13:49:47 +0200
Subject: Cannot link against memset_with_concurrent_readers_sparc.cpp
In-Reply-To: <9e6409be-5823-bef4-96ec-2c4603c41ecc@oracle.com>
References: <1b9a20ca-9481-dfc4-125a-6d779c380f3e@physik.fu-berlin.de>
 <1496827779.3701.5.camel@redhat.com>
 <7cafff82-8413-ea5b-ebde-7479f9337570@oracle.com>
 <20170607110506.GF6481@physik.fu-berlin.de>
 <9e6409be-5823-bef4-96ec-2c4603c41ecc@oracle.com>
Message-ID: <20170607114947.GH6481@physik.fu-berlin.de>

On Wed, Jun 07, 2017 at 01:42:47PM +0200, Mikael Gerdin wrote:
> I think the problem is that your build configuration is ZERO but the file
> memset_with_concurrent_readers_sparc.cpp is in the cpu/sparc directory and
> will only be visible if building a native (non-zero) SPARC config.

That's a *very* good hint. I just saw there is actually a related
patch in the Debian package which came from the openjdk-8 package
and is currently disabled for the openjdk-9 package! Attaching
the old patch, it pretty much looks like what I need to be looking
into.

Thanks for the pointer!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zero-sparc.diff
Type: text/x-diff
Size: 13366 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170607/023d093b/zero-sparc.diff>

From rob.mckenna at oracle.com  Wed Jun  7 12:30:51 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 7 Jun 2017 13:30:51 +0100
Subject: [jdk10 & jdk8u] Request for Review: 8173654
In-Reply-To: <b632107c-aed6-1436-990c-1c6985e94f3e@oracle.com>
References: <20170606170143.GL4512@vimes>
 <b632107c-aed6-1436-990c-1c6985e94f3e@oracle.com>
Message-ID: <20170607123051.GA3376@vimes>

Ack, its there already. Didn't notice it. Thanks Erik,

    -Rob

On 07/06/17 09:16, Erik Joelsson wrote:
> The 8u change looks good. In JKD 10 (as well as 9) we have created a macro
> to handle this so please use something like this:
> 
> # Hook to include the corresponding custom file, if present.
> $(eval $(call IncludeCustomExtension, jdk, lib/CoreLibraries.gmk))
> 
> /Erik
> 
> 
> On 2017-06-06 19:01, Rob McKenna wrote:
> >Hi folks,
> >
> >We've found it useful to be able to override LIBJAVA_SRC_DIRS /
> >LIBJAVA_MAPFILE in libjava. This change in 10 allows the former and
> >backports the latter to 8:
> >
> >http://cr.openjdk.java.net/~robm/8173654/
> >
> >Thanks,
> >
> >     -Rob
> >
> 


From erik.joelsson at oracle.com  Wed Jun  7 13:57:03 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 7 Jun 2017 15:57:03 +0200
Subject: [jdk10 & jdk8u] Request for Review: 8173654
In-Reply-To: <20170607123051.GA3376@vimes>
References: <20170606170143.GL4512@vimes>
 <b632107c-aed6-1436-990c-1c6985e94f3e@oracle.com>
 <20170607123051.GA3376@vimes>
Message-ID: <6e401abd-42d8-3e4a-b7e6-de9bb09206f7@oracle.com>

Right, it is, I missed it too.

/Erik


On 2017-06-07 14:30, Rob McKenna wrote:
> Ack, its there already. Didn't notice it. Thanks Erik,
>
>      -Rob
>
> On 07/06/17 09:16, Erik Joelsson wrote:
>> The 8u change looks good. In JKD 10 (as well as 9) we have created a macro
>> to handle this so please use something like this:
>>
>> # Hook to include the corresponding custom file, if present.
>> $(eval $(call IncludeCustomExtension, jdk, lib/CoreLibraries.gmk))
>>
>> /Erik
>>
>>
>> On 2017-06-06 19:01, Rob McKenna wrote:
>>> Hi folks,
>>>
>>> We've found it useful to be able to override LIBJAVA_SRC_DIRS /
>>> LIBJAVA_MAPFILE in libjava. This change in 10 allows the former and
>>> backports the latter to 8:
>>>
>>> http://cr.openjdk.java.net/~robm/8173654/
>>>
>>> Thanks,
>>>
>>>      -Rob
>>>



From erik.joelsson at oracle.com  Wed Jun  7 14:14:06 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 7 Jun 2017 16:14:06 +0200
Subject: RFR: JDK-8178064: OpenJDK RI binary should include the license file
 for freetype
Message-ID: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>

Hello,

Please review this late change for JDK 9. It adds a new configure 
parameter --with-freetype-license, which can optionally be set to point 
to a license file for freetype. If freetype bundling is enabled, this 
license file will be included in the java.desktop.jmod file and 
subsequently in the images/{jdk,jre}/legal/java.desktop directory.

Note that freetype comes with a dual license. For normal GPL OpenJDK 
builds, no additional license is needed as freetype is also GPL. This 
feature is only needed when someone is licensing OpenJDK with a 
different license (which the Oracle reference implementation builds do).

This change is considered noreg-doc and will go into jdk9.

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

Webrev: http://cr.openjdk.java.net/~erikj/8178064/webrev.01

/Erik



From tim.bell at oracle.com  Wed Jun  7 15:00:06 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 07 Jun 2017 08:00:06 -0700
Subject: RFR: JDK-8178064: OpenJDK RI binary should include the license
 file for freetype
In-Reply-To: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>
References: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>
Message-ID: <593814F6.5040002@oracle.com>

Erik:

> Please review this late change for JDK 9. It adds a new configure
> parameter --with-freetype-license, which can optionally be set to point
> to a license file for freetype. If freetype bundling is enabled, this
> license file will be included in the java.desktop.jmod file and
> subsequently in the images/{jdk,jre}/legal/java.desktop directory.
>
> Note that freetype comes with a dual license. For normal GPL OpenJDK
> builds, no additional license is needed as freetype is also GPL. This
> feature is only needed when someone is licensing OpenJDK with a
> different license (which the Oracle reference implementation builds do).
>
> This change is considered noreg-doc and will go into jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178064
>
> Webrev: http://cr.openjdk.java.net/~erikj/8178064/webrev.01

Looks good to me.

/Tim




From kumar.x.srinivasan at oracle.com  Wed Jun  7 21:58:22 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 07 Jun 2017 14:58:22 -0700
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
Message-ID: <593876FE.7030605@oracle.com>

Hello,

Please review the changes to fix  JDK-8180334,  essentially -DJAVA_ARGS 
exceeds
a Visual Studio C++ compiler limit, and this fix provides a way to specify
very long  string literals, by the build system.

This also includes some minor and subtle simplifications and cleanups wrt.
the JAVA_ARGS and its handling.

Thanks

Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
JBS: https://bugs.openjdk.java.net/browse/JDK-8180334


From kim.barrett at oracle.com  Wed Jun  7 23:51:32 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 7 Jun 2017 19:51:32 -0400
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
Message-ID: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>

Please review this change to the build of hotspot to globally define
the __STDC_xxx_MACROS macros via the command line, rather than
via #defines scattered through several header files.

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

Webrev:
http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/

Testing:
JPRT



From mandy.chung at oracle.com  Thu Jun  8 01:12:36 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 7 Jun 2017 18:12:36 -0700
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <593876FE.7030605@oracle.com>
References: <593876FE.7030605@oracle.com>
Message-ID: <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>


> On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> Hello,
> 
> Please review the changes to fix  JDK-8180334,  essentially -DJAVA_ARGS exceeds
> a Visual Studio C++ compiler limit, and this fix provides a way to specify
> very long  string literals, by the build system.
> 
> This also includes some minor and subtle simplifications and cleanups wrt.
> the JAVA_ARGS and its handling.
> 
> Thanks
> 
> Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180334

This is a reasonable short-term solution.  As we discussed, we should
look into extending jlink to create the native launcher using @argfile
in a future release.

make/launcher/LauncherCommon.gmk

+# EXTRA_JAVA_ARGS Processed into a -DEXTRA_JAVA_ARGS and is prependedi

typo: s/prependedi/prepended

src/java.base/share/native/launcher/main.c
  It may help to detect if main_jargc == 0 but extra_jargc > 0 and exit with an error in case any bug in creating such a launcher.

Mandy

From erik.joelsson at oracle.com  Thu Jun  8 06:23:36 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Jun 2017 08:23:36 +0200
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
References: <593876FE.7030605@oracle.com>
 <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
Message-ID: <c58ba41e-7b1c-c210-8e6e-787661412977@oracle.com>

Hello,

Build changes look good with Mandy's correction. I would also like a 
comment sentence explaining the reason for EXTRA_JAVA_ARGS in 
LauncherCommon.gmk. Otherwise we risk cleaning this away in the future.

/Erik


On 2017-06-08 03:12, Mandy Chung wrote:
>> On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review the changes to fix  JDK-8180334,  essentially -DJAVA_ARGS exceeds
>> a Visual Studio C++ compiler limit, and this fix provides a way to specify
>> very long  string literals, by the build system.
>>
>> This also includes some minor and subtle simplifications and cleanups wrt.
>> the JAVA_ARGS and its handling.
>>
>> Thanks
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180334
> This is a reasonable short-term solution.  As we discussed, we should
> look into extending jlink to create the native launcher using @argfile
> in a future release.
>
> make/launcher/LauncherCommon.gmk
>
> +# EXTRA_JAVA_ARGS Processed into a -DEXTRA_JAVA_ARGS and is prependedi
>
> typo: s/prependedi/prepended
>
> src/java.base/share/native/launcher/main.c
>    It may help to detect if main_jargc == 0 but extra_jargc > 0 and exit with an error in case any bug in creating such a launcher.
>
> Mandy



From erik.joelsson at oracle.com  Thu Jun  8 06:28:06 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Jun 2017 08:28:06 +0200
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
In-Reply-To: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
References: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
Message-ID: <db7bae38-13b9-38a8-bdb4-e9882991cc1f@oracle.com>

Build changes look good to me.

/Erik


On 2017-06-08 01:51, Kim Barrett wrote:
> Please review this change to the build of hotspot to globally define
> the __STDC_xxx_MACROS macros via the command line, rather than
> via #defines scattered through several header files.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8086005
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
> http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/
>
> Testing:
> JPRT
>



From magnus.ihse.bursie at oracle.com  Thu Jun  8 08:50:21 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 8 Jun 2017 10:50:21 +0200
Subject: RFR: JDK-8181776 Move specs again
Message-ID: <ae99f247-e84b-c6e4-2fa6-222141598e04@oracle.com>

We need to move back spacs to closed due to legal considerations. Here 
is the open part.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181776
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8181776-move-back-specs/webrev.01

/Magnus



From magnus.ihse.bursie at oracle.com  Thu Jun  8 08:56:24 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 8 Jun 2017 10:56:24 +0200
Subject: RFR: JDK-8178064: OpenJDK RI binary should include the license
 file for freetype
In-Reply-To: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>
References: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>
Message-ID: <d193d5d6-42b7-acee-5c41-53026b00dbbd@oracle.com>

Erik,

My only concern is that when doing the bundling, we assume that 
FREETYPE_LICENSE is set, but no verification of this is done in 
configure. That is, either should the SetupCopyFiles block be 
conditional on the license file existing, or the code in 
LIB_SETUP_FREETYPE should verify that we have a license if bundling is 
enabled. I think enforcing a license file when bundling is the reight 
way, so this means adding a check in configure.

Apart from that it looks good.

I'm also ok if you push this code as it is in jdk9 and file a follow-up 
bug for jdk 10 of adding the verification to configure.

/Magnus


On 2017-06-07 16:14, Erik Joelsson wrote:
> Hello,
>
> Please review this late change for JDK 9. It adds a new configure 
> parameter --with-freetype-license, which can optionally be set to 
> point to a license file for freetype. If freetype bundling is enabled, 
> this license file will be included in the java.desktop.jmod file and 
> subsequently in the images/{jdk,jre}/legal/java.desktop directory.
>
> Note that freetype comes with a dual license. For normal GPL OpenJDK 
> builds, no additional license is needed as freetype is also GPL. This 
> feature is only needed when someone is licensing OpenJDK with a 
> different license (which the Oracle reference implementation builds do).
>
> This change is considered noreg-doc and will go into jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178064
>
> Webrev: http://cr.openjdk.java.net/~erikj/8178064/webrev.01
>
> /Erik
>



From erik.joelsson at oracle.com  Thu Jun  8 09:22:34 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Jun 2017 11:22:34 +0200
Subject: RFR: JDK-8181776 Move specs again
In-Reply-To: <ae99f247-e84b-c6e4-2fa6-222141598e04@oracle.com>
References: <ae99f247-e84b-c6e4-2fa6-222141598e04@oracle.com>
Message-ID: <7ac7306d-7707-3ee8-2e2a-4cbcb1d33a70@oracle.com>

Looks good.

/Erik


On 2017-06-08 10:50, Magnus Ihse Bursie wrote:
> We need to move back spacs to closed due to legal considerations. Here 
> is the open part.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181776
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8181776-move-back-specs/webrev.01
>
> /Magnus
>



From erik.joelsson at oracle.com  Thu Jun  8 09:28:04 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Jun 2017 11:28:04 +0200
Subject: RFR: JDK-8178064: OpenJDK RI binary should include the license
 file for freetype
In-Reply-To: <d193d5d6-42b7-acee-5c41-53026b00dbbd@oracle.com>
References: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>
 <d193d5d6-42b7-acee-5c41-53026b00dbbd@oracle.com>
Message-ID: <8982711a-7c07-c49e-e8ed-99d8216a0b48@oracle.com>

Hello,

On 2017-06-08 10:56, Magnus Ihse Bursie wrote:
> Erik,
>
> My only concern is that when doing the bundling, we assume that 
> FREETYPE_LICENSE is set, but no verification of this is done in 
> configure. That is, either should the SetupCopyFiles block be 
> conditional on the license file existing, or the code in 
> LIB_SETUP_FREETYPE should verify that we have a license if bundling is 
> enabled. I think enforcing a license file when bundling is the reight 
> way, so this means adding a check in configure.
>
I disagree. SetupCopyFiles is designed to work fine if the FILES input 
is empty. It will just generate 0 rules in that case, so this is 
intended from my part. I do make sure that it's empty in configure so we 
don't accidentally get rubbish in it however. We do not want to enforce 
FREETYPE_LICENSE to be set as we are not going to bundle a license for 
GPL (default) builds, but only when using a different license for the 
rest of OpenJDK.

/Erik

> Apart from that it looks good.
>
> I'm also ok if you push this code as it is in jdk9 and file a 
> follow-up bug for jdk 10 of adding the verification to configure.
>
> /Magnus
>
>
> On 2017-06-07 16:14, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this late change for JDK 9. It adds a new configure 
>> parameter --with-freetype-license, which can optionally be set to 
>> point to a license file for freetype. If freetype bundling is 
>> enabled, this license file will be included in the java.desktop.jmod 
>> file and subsequently in the images/{jdk,jre}/legal/java.desktop 
>> directory.
>>
>> Note that freetype comes with a dual license. For normal GPL OpenJDK 
>> builds, no additional license is needed as freetype is also GPL. This 
>> feature is only needed when someone is licensing OpenJDK with a 
>> different license (which the Oracle reference implementation builds do).
>>
>> This change is considered noreg-doc and will go into jdk9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178064
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8178064/webrev.01
>>
>> /Erik
>>
>



From kim.barrett at oracle.com  Thu Jun  8 10:36:37 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Jun 2017 06:36:37 -0400
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
In-Reply-To: <db7bae38-13b9-38a8-bdb4-e9882991cc1f@oracle.com>
References: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
 <db7bae38-13b9-38a8-bdb4-e9882991cc1f@oracle.com>
Message-ID: <8D1B5CE1-782E-4942-B069-E31067F3E8A3@oracle.com>

> On Jun 8, 2017, at 2:28 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Build changes look good to me.

Thanks.

> /Erik
> 
> 
> On 2017-06-08 01:51, Kim Barrett wrote:
>> Please review this change to the build of hotspot to globally define
>> the __STDC_xxx_MACROS macros via the command line, rather than
>> via #defines scattered through several header files.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8086005
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
>> http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/
>> 
>> Testing:
>> JPRT




From magnus.ihse.bursie at oracle.com  Thu Jun  8 12:07:09 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 8 Jun 2017 14:07:09 +0200
Subject: RFR: JDK-8178064: OpenJDK RI binary should include the license
 file for freetype
In-Reply-To: <8982711a-7c07-c49e-e8ed-99d8216a0b48@oracle.com>
References: <7283959e-18b9-d77b-0ecb-7cb78d12f3ac@oracle.com>
 <d193d5d6-42b7-acee-5c41-53026b00dbbd@oracle.com>
 <8982711a-7c07-c49e-e8ed-99d8216a0b48@oracle.com>
Message-ID: <75d8dac3-fe01-b2ac-4696-09e300cd5ad2@oracle.com>

On 2017-06-08 11:28, Erik Joelsson wrote:
> Hello,
>
> On 2017-06-08 10:56, Magnus Ihse Bursie wrote:
>> Erik,
>>
>> My only concern is that when doing the bundling, we assume that 
>> FREETYPE_LICENSE is set, but no verification of this is done in 
>> configure. That is, either should the SetupCopyFiles block be 
>> conditional on the license file existing, or the code in 
>> LIB_SETUP_FREETYPE should verify that we have a license if bundling 
>> is enabled. I think enforcing a license file when bundling is the 
>> reight way, so this means adding a check in configure.
>>
> I disagree. SetupCopyFiles is designed to work fine if the FILES input 
> is empty. It will just generate 0 rules in that case, so this is 
> intended from my part. 

I didn't know that. Well, in that case, your code works.

However, I'm not sure I like that behavior of SetupCopyFiles. Sounds 
like it's too easy to get something lost without a warning, e.g. if you 
mistype a variable name somewhere. But let's discuss that at another 
time. :-)

> I do make sure that it's empty in configure so we don't accidentally 
> get rubbish in it however. We do not want to enforce FREETYPE_LICENSE 
> to be set as we are not going to bundle a license for GPL (default) 
> builds, but only when using a different license for the rest of OpenJDK.

Ok, sounds good then.

/Magnus

>
> /Erik
>
>> Apart from that it looks good.
>>
>> I'm also ok if you push this code as it is in jdk9 and file a 
>> follow-up bug for jdk 10 of adding the verification to configure.
>>
>> /Magnus
>>
>>
>> On 2017-06-07 16:14, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this late change for JDK 9. It adds a new configure 
>>> parameter --with-freetype-license, which can optionally be set to 
>>> point to a license file for freetype. If freetype bundling is 
>>> enabled, this license file will be included in the java.desktop.jmod 
>>> file and subsequently in the images/{jdk,jre}/legal/java.desktop 
>>> directory.
>>>
>>> Note that freetype comes with a dual license. For normal GPL OpenJDK 
>>> builds, no additional license is needed as freetype is also GPL. 
>>> This feature is only needed when someone is licensing OpenJDK with a 
>>> different license (which the Oracle reference implementation builds 
>>> do).
>>>
>>> This change is considered noreg-doc and will go into jdk9.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178064
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8178064/webrev.01
>>>
>>> /Erik
>>>
>>
>



From erik.joelsson at oracle.com  Thu Jun  8 12:50:14 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Jun 2017 14:50:14 +0200
Subject: RFR: JDK-8181788: Unable to build JDK10 on SPARC-M8 machines
Message-ID: <a99d112d-a1ac-d1f9-696c-2879a2dcd7ac@oracle.com>

The default boot jdk for jdk10 is still 8GA. This jdk is known not to 
run on newer sparc hardware, which was addressed for generation 7 in 
JDK-8176271 and JDK-8162354. Now we need to run on the gen 8 chips and 
are facing the same issue.

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

Patch:

diff -r 6b750cdb823a common/conf/jib-profiles.js
--- a/common/conf/jib-profiles.js
+++ b/common/conf/jib-profiles.js
@@ -387,7 +387,7 @@
      // on such hardware.
      if (input.build_cpu == "sparcv9") {
         var cpu_brand = $EXEC("bash -c \"kstat -m cpu_info | grep brand 
| head -n1 | awk '{ print \$2 }'\"");
-       if (cpu_brand.trim().match('SPARC-.7')) {
+       if (cpu_brand.trim().match('SPARC-.[78]')) {
             boot_jdk_revision = "8u20";
             boot_jdk_subdirpart = "1.8.0_20";
         }


/Erik



From tim.bell at oracle.com  Thu Jun  8 13:34:10 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 08 Jun 2017 06:34:10 -0700
Subject: RFR: JDK-8181788: Unable to build JDK10 on SPARC-M8 machines
In-Reply-To: <a99d112d-a1ac-d1f9-696c-2879a2dcd7ac@oracle.com>
References: <a99d112d-a1ac-d1f9-696c-2879a2dcd7ac@oracle.com>
Message-ID: <59395252.4070407@oracle.com>

Erik:

> The default boot jdk for jdk10 is still 8GA. This jdk is known not to
> run on newer sparc hardware, which was addressed for generation 7 in
> JDK-8176271 and JDK-8162354. Now we need to run on the gen 8 chips and
> are facing the same issue.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181788
>
> Patch:
>
> diff -r 6b750cdb823a common/conf/jib-profiles.js
> --- a/common/conf/jib-profiles.js
> +++ b/common/conf/jib-profiles.js
> @@ -387,7 +387,7 @@
>       // on such hardware.
>       if (input.build_cpu == "sparcv9") {
>          var cpu_brand = $EXEC("bash -c \"kstat -m cpu_info | grep brand
> | head -n1 | awk '{ print \$2 }'\"");
> -       if (cpu_brand.trim().match('SPARC-.7')) {
> +       if (cpu_brand.trim().match('SPARC-.[78]')) {
>              boot_jdk_revision = "8u20";
>              boot_jdk_subdirpart = "1.8.0_20";
>          }
>

Looks good.

/Tim




From magnus.ihse.bursie at oracle.com  Thu Jun  8 14:30:06 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 8 Jun 2017 16:30:06 +0200
Subject: RFR: JDK-8181788: Unable to build JDK10 on SPARC-M8 machines
In-Reply-To: <a99d112d-a1ac-d1f9-696c-2879a2dcd7ac@oracle.com>
References: <a99d112d-a1ac-d1f9-696c-2879a2dcd7ac@oracle.com>
Message-ID: <ba718b2b-12f0-9daa-70ba-54070b944042@oracle.com>


On 2017-06-08 14:50, Erik Joelsson wrote:
> The default boot jdk for jdk10 is still 8GA. This jdk is known not to 
> run on newer sparc hardware, which was addressed for generation 7 in 
> JDK-8176271 and JDK-8162354. Now we need to run on the gen 8 chips and 
> are facing the same issue.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181788
>
> Patch:
>
> diff -r 6b750cdb823a common/conf/jib-profiles.js
> --- a/common/conf/jib-profiles.js
> +++ b/common/conf/jib-profiles.js
> @@ -387,7 +387,7 @@
>      // on such hardware.
>      if (input.build_cpu == "sparcv9") {
>         var cpu_brand = $EXEC("bash -c \"kstat -m cpu_info | grep 
> brand | head -n1 | awk '{ print \$2 }'\"");
> -       if (cpu_brand.trim().match('SPARC-.7')) {
> +       if (cpu_brand.trim().match('SPARC-.[78]')) {
>             boot_jdk_revision = "8u20";
>             boot_jdk_subdirpart = "1.8.0_20";
>         }

Looks good to me.

/Magnus

>
>
> /Erik
>



From kumar.x.srinivasan at oracle.com  Thu Jun  8 15:15:52 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 08 Jun 2017 08:15:52 -0700
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
References: <593876FE.7030605@oracle.com>
 <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
Message-ID: <59396A28.1000409@oracle.com>


1. Added a comment in the LauncherCommon.gmk, fixed typo
2. Added checks for spurious EXTRA_JAVA_ARGS, both as
     compile time and runtime check, the latter for a good measure.

Thanks
Kumar

PS: Mandy,  could you please file a RFE for the jlink requirements and 
assign it to me.

>> On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review the changes to fix  JDK-8180334,  essentially -DJAVA_ARGS exceeds
>> a Visual Studio C++ compiler limit, and this fix provides a way to specify
>> very long  string literals, by the build system.
>>
>> This also includes some minor and subtle simplifications and cleanups wrt.
>> the JAVA_ARGS and its handling.
>>
>> Thanks
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180334
> This is a reasonable short-term solution.  As we discussed, we should
> look into extending jlink to create the native launcher using @argfile
> in a future release.
>
> make/launcher/LauncherCommon.gmk
>
> +# EXTRA_JAVA_ARGS Processed into a -DEXTRA_JAVA_ARGS and is prependedi
>
> typo: s/prependedi/prepended
>
> src/java.base/share/native/launcher/main.c
>    It may help to detect if main_jargc == 0 but extra_jargc > 0 and exit with an error in case any bug in creating such a launcher.
>
> Mandy



From kumar.x.srinivasan at oracle.com  Thu Jun  8 15:17:42 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 08 Jun 2017 08:17:42 -0700
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <59396A28.1000409@oracle.com>
References: <593876FE.7030605@oracle.com>
 <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
 <59396A28.1000409@oracle.com>
Message-ID: <59396A96.7000506@oracle.com>


Oops here are the webrevs:
Delta webrev: 
http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/webrev.delta/
Full webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/

Kumar

>
> 1. Added a comment in the LauncherCommon.gmk, fixed typo
> 2. Added checks for spurious EXTRA_JAVA_ARGS, both as
>     compile time and runtime check, the latter for a good measure.
>
> Thanks
> Kumar
>
> PS: Mandy,  could you please file a RFE for the jlink requirements and 
> assign it to me.
>
>>> On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan 
>>> <kumar.x.srinivasan at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> Please review the changes to fix  JDK-8180334,  essentially 
>>> -DJAVA_ARGS exceeds
>>> a Visual Studio C++ compiler limit, and this fix provides a way to 
>>> specify
>>> very long  string literals, by the build system.
>>>
>>> This also includes some minor and subtle simplifications and 
>>> cleanups wrt.
>>> the JAVA_ARGS and its handling.
>>>
>>> Thanks
>>>
>>> Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180334
>> This is a reasonable short-term solution.  As we discussed, we should
>> look into extending jlink to create the native launcher using @argfile
>> in a future release.
>>
>> make/launcher/LauncherCommon.gmk
>>
>> +# EXTRA_JAVA_ARGS Processed into a -DEXTRA_JAVA_ARGS and is prependedi
>>
>> typo: s/prependedi/prepended
>>
>> src/java.base/share/native/launcher/main.c
>>    It may help to detect if main_jargc == 0 but extra_jargc > 0 and 
>> exit with an error in case any bug in creating such a launcher.
>>
>> Mandy
>



From erik.joelsson at oracle.com  Thu Jun  8 15:19:42 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 8 Jun 2017 17:19:42 +0200
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <59396A96.7000506@oracle.com>
References: <593876FE.7030605@oracle.com>
 <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
 <59396A28.1000409@oracle.com> <59396A96.7000506@oracle.com>
Message-ID: <1610a31a-477a-ea0b-cd6e-05491259ac39@oracle.com>

Looks good to me.

/Erik


On 2017-06-08 17:17, Kumar Srinivasan wrote:
>
> Oops here are the webrevs:
> Delta webrev: 
> http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/webrev.delta/
> Full webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/
>
> Kumar
>
>>
>> 1. Added a comment in the LauncherCommon.gmk, fixed typo
>> 2. Added checks for spurious EXTRA_JAVA_ARGS, both as
>>     compile time and runtime check, the latter for a good measure.
>>
>> Thanks
>> Kumar
>>
>> PS: Mandy,  could you please file a RFE for the jlink requirements 
>> and assign it to me.
>>
>>>> On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan 
>>>> <kumar.x.srinivasan at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Please review the changes to fix  JDK-8180334,  essentially 
>>>> -DJAVA_ARGS exceeds
>>>> a Visual Studio C++ compiler limit, and this fix provides a way to 
>>>> specify
>>>> very long  string literals, by the build system.
>>>>
>>>> This also includes some minor and subtle simplifications and 
>>>> cleanups wrt.
>>>> the JAVA_ARGS and its handling.
>>>>
>>>> Thanks
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180334
>>> This is a reasonable short-term solution.  As we discussed, we should
>>> look into extending jlink to create the native launcher using @argfile
>>> in a future release.
>>>
>>> make/launcher/LauncherCommon.gmk
>>>
>>> +# EXTRA_JAVA_ARGS Processed into a -DEXTRA_JAVA_ARGS and is prependedi
>>>
>>> typo: s/prependedi/prepended
>>>
>>> src/java.base/share/native/launcher/main.c
>>>    It may help to detect if main_jargc == 0 but extra_jargc > 0 and 
>>> exit with an error in case any bug in creating such a launcher.
>>>
>>> Mandy
>>
>



From gerard.ziemski at oracle.com  Thu Jun  8 21:21:01 2017
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Thu, 8 Jun 2017 16:21:01 -0500
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
In-Reply-To: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
References: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
Message-ID: <38B1C99D-0DE4-481E-A971-311CB16B59F3@oracle.com>

hi Kim,

My understanding is that to enable c++11, for example, we need to do 2 things (at least on Mac OS X):

#1 For the compilation phase we need to add ?-std=c++11 -stdlib=libc++?, where ?-std=c++11? selects the language model, and ?-stdlib=libc++? selects the corresponding headers.

#2 For the linking phase we need to add "-stdlib=libc++? to select the corresponding c++ standard lib.

Ie, we need to set both cflags and ldflags, but you are only allowing to add to JVM_CFLAGS. Without the ability to also modify JVM_LDFLAGS, this fix, as is, is not complete on Mac OS X.

Unless I?m mistaken, please correct me if I?m wrong, can we include modifying JVM_LDFLAGS in this fix as well?


cheers


> On Jun 7, 2017, at 6:51 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this change to the build of hotspot to globally define
> the __STDC_xxx_MACROS macros via the command line, rather than
> via #defines scattered through several header files.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8086005
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
> http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/
> 
> Testing:
> JPRT
> 



From magnus.ihse.bursie at oracle.com  Fri Jun  9 09:42:14 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 9 Jun 2017 11:42:14 +0200
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <59396A96.7000506@oracle.com>
References: <593876FE.7030605@oracle.com>
 <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
 <59396A28.1000409@oracle.com> <59396A96.7000506@oracle.com>
Message-ID: <b5392112-3af0-aff8-e14a-930f2290ab05@oracle.com>

Looks good to me.

/Magnus

On 2017-06-08 17:17, Kumar Srinivasan wrote:
>
> Oops here are the webrevs:
> Delta webrev: 
> http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/webrev.delta/
> Full webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/
>
> Kumar
>
>>
>> 1. Added a comment in the LauncherCommon.gmk, fixed typo
>> 2. Added checks for spurious EXTRA_JAVA_ARGS, both as
>>     compile time and runtime check, the latter for a good measure.
>>
>> Thanks
>> Kumar
>>
>> PS: Mandy,  could you please file a RFE for the jlink requirements 
>> and assign it to me.
>>
>>>> On Jun 7, 2017, at 2:58 PM, Kumar Srinivasan 
>>>> <kumar.x.srinivasan at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Please review the changes to fix  JDK-8180334,  essentially 
>>>> -DJAVA_ARGS exceeds
>>>> a Visual Studio C++ compiler limit, and this fix provides a way to 
>>>> specify
>>>> very long  string literals, by the build system.
>>>>
>>>> This also includes some minor and subtle simplifications and 
>>>> cleanups wrt.
>>>> the JAVA_ARGS and its handling.
>>>>
>>>> Thanks
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.00
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180334
>>> This is a reasonable short-term solution.  As we discussed, we should
>>> look into extending jlink to create the native launcher using @argfile
>>> in a future release.
>>>
>>> make/launcher/LauncherCommon.gmk
>>>
>>> +# EXTRA_JAVA_ARGS Processed into a -DEXTRA_JAVA_ARGS and is prependedi
>>>
>>> typo: s/prependedi/prepended
>>>
>>> src/java.base/share/native/launcher/main.c
>>>    It may help to detect if main_jargc == 0 but extra_jargc > 0 and 
>>> exit with an error in case any bug in creating such a launcher.
>>>
>>> Mandy
>>
>



From glaubitz at physik.fu-berlin.de  Fri Jun  9 10:20:42 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 9 Jun 2017 12:20:42 +0200
Subject: [PATCH] linux-sparc build fixes
Message-ID: <20170609102041.GA2477@physik.fu-berlin.de>

Hi!

I am currently working on fixing OpenJDK-9 on all non-mainstream
targets available in Debian. For Debian/sparc64, the attached four
patches were necessary to make the build succeed [1].

I know the patches cannot be merged right now, but I'm posting them
anyway in case someone else is interested in using them.

All patches are:

    Signed-off-by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>

I also signed the OCA.

I'm now looking into fixing the builds on alpha (DEC Alpha), armel
(ARMv4T), m68k (680x0), powerpc (PPC32) and sh4 (SuperH/J-Core).

Cheers,
Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1496931563&raw=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hotspot-add-missing-log-header.diff
Type: text/x-diff
Size: 352 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170609/4c348e34/hotspot-add-missing-log-header.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hotspot-fix-checkbytebuffer.diff
Type: text/x-diff
Size: 792 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170609/4c348e34/hotspot-fix-checkbytebuffer.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename-sparc-linux-atomic-header.diff
Type: text/x-diff
Size: 16060 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170609/4c348e34/rename-sparc-linux-atomic-header.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-zero-build-on-sparc.diff
Type: text/x-diff
Size: 11316 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20170609/4c348e34/fix-zero-build-on-sparc.diff>

From gerard.ziemski at oracle.com  Fri Jun  9 15:43:46 2017
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Fri, 9 Jun 2017 10:43:46 -0500
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
In-Reply-To: <38B1C99D-0DE4-481E-A971-311CB16B59F3@oracle.com>
References: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
 <38B1C99D-0DE4-481E-A971-311CB16B59F3@oracle.com>
Message-ID: <2E5939FD-B3E6-4650-9DBE-742E870F5169@oracle.com>

hi Kim,

I?m withdrawing my objection.

Making this mechanism cover ldflags is beyond the scope of this fix and deserves its own feature request.


cheers

> On Jun 8, 2017, at 4:21 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> 
> hi Kim,
> 
> My understanding is that to enable c++11, for example, we need to do 2 things (at least on Mac OS X):
> 
> #1 For the compilation phase we need to add ?-std=c++11 -stdlib=libc++?, where ?-std=c++11? selects the language model, and ?-stdlib=libc++? selects the corresponding headers.
> 
> #2 For the linking phase we need to add "-stdlib=libc++? to select the corresponding c++ standard lib.
> 
> Ie, we need to set both cflags and ldflags, but you are only allowing to add to JVM_CFLAGS. Without the ability to also modify JVM_LDFLAGS, this fix, as is, is not complete on Mac OS X.
> 
> Unless I?m mistaken, please correct me if I?m wrong, can we include modifying JVM_LDFLAGS in this fix as well?
> 
> 
> cheers
> 
> 
>> On Jun 7, 2017, at 6:51 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> Please review this change to the build of hotspot to globally define
>> the __STDC_xxx_MACROS macros via the command line, rather than
>> via #defines scattered through several header files.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8086005
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
>> http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/
>> 
>> Testing:
>> JPRT
>> 
> 



From mandy.chung at oracle.com  Fri Jun  9 16:45:48 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 9 Jun 2017 09:45:48 -0700
Subject: RFR: JDK10: JDK-8180334: Unable to build jaotc launcher on windows
In-Reply-To: <59396A96.7000506@oracle.com>
References: <593876FE.7030605@oracle.com>
 <93FA0684-A65B-4A44-AC03-B57834BF321A@oracle.com>
 <59396A28.1000409@oracle.com> <59396A96.7000506@oracle.com>
Message-ID: <26710BF6-F88F-4F4C-AEEF-C6F495359C50@oracle.com>


> On Jun 8, 2017, at 8:17 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> 
> Oops here are the webrevs:
> Delta webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/webrev.delta/
> Full webrev: http://cr.openjdk.java.net/~ksrini/8180334/webrev.01/
> 

Looks good.
Mandy



From magnus.ihse.bursie at oracle.com  Mon Jun 12 07:28:56 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 12 Jun 2017 09:28:56 +0200
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
Message-ID: <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>

Hi,

This patch, while approved by reviewers, was put on hold due to legal 
reasons.

Here's a new patch, with updated legalese.

http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.02

/Magnus


On 2017-05-03 16:02, Magnus Ihse Bursie wrote:
> The new $module/specs specifications needs to point to a proper 
> copyright file.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>
> /Magnus
>



From erik.joelsson at oracle.com  Mon Jun 12 07:42:15 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Jun 2017 09:42:15 +0200
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
 <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
Message-ID: <45231318-fd98-1c98-a7d1-4205a1dbe185@oracle.com>

Still looks good to me.

/Erik


On 2017-06-12 09:28, Magnus Ihse Bursie wrote:
> Hi,
>
> This patch, while approved by reviewers, was put on hold due to legal 
> reasons.
>
> Here's a new patch, with updated legalese.
>
> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.02 
>
>
> /Magnus
>
>
> On 2017-05-03 16:02, Magnus Ihse Bursie wrote:
>> The new $module/specs specifications needs to point to a proper 
>> copyright file.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>>
>> /Magnus
>>
>



From mandy.chung at oracle.com  Mon Jun 12 16:19:54 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 12 Jun 2017 09:19:54 -0700
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
 <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
Message-ID: <EEE3A6C6-B10D-413B-8E2D-B2F8FAD0DD97@oracle.com>

jdk/make/src/classes/build/tools/docs/docs-bundle-page.html has a reference to cpyr.html that needs to be fixed.

It?d be good to wrap the long lines in copyright.html.

Mandy

> On Jun 12, 2017, at 12:28 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> Hi,
> 
> This patch, while approved by reviewers, was put on hold due to legal reasons.
> 
> Here's a new patch, with updated legalese.
> 
> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.02
> 
> /Magnus
> 
> 
> On 2017-05-03 16:02, Magnus Ihse Bursie wrote:
>> The new $module/specs specifications needs to point to a proper copyright file.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>> 
>> /Magnus
>> 
> 



From mandy.chung at oracle.com  Tue Jun 13 05:21:59 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 12 Jun 2017 22:21:59 -0700
Subject: Request Review JDK-8182029: Make the top-level docs index.html to a
 HTML-level redirect to the API overview page
Message-ID: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182029/webrev.00/

JBS issue:
  https://bugs.openjdk.java.net/browse/JDK-8182029

This patch replaces the top-level docs index.html to a HTML-level redirect to the API overview page.  We can come back to this page later in a future release to convey grouping information.

Mandy

From erik.joelsson at oracle.com  Tue Jun 13 07:17:42 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 13 Jun 2017 09:17:42 +0200
Subject: Request Review JDK-8182029: Make the top-level docs index.html to
 a HTML-level redirect to the API overview page
In-Reply-To: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>
References: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>
Message-ID: <35b60d55-924c-4d7a-e1ee-1907cd216277@oracle.com>

Looks ok to me.

/Erik


On 2017-06-13 07:21, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182029/webrev.00/
>
> JBS issue:
>    https://bugs.openjdk.java.net/browse/JDK-8182029
>
> This patch replaces the top-level docs index.html to a HTML-level redirect to the API overview page.  We can come back to this page later in a future release to convey grouping information.
>
> Mandy



From Alan.Bateman at oracle.com  Tue Jun 13 07:26:08 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jun 2017 08:26:08 +0100
Subject: Request Review JDK-8182029: Make the top-level docs index.html to
 a HTML-level redirect to the API overview page
In-Reply-To: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>
References: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>
Message-ID: <138981a0-e538-a775-80f8-a5f7cc12fe0b@oracle.com>

On 13/06/2017 06:21, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182029/webrev.00/
>
> JBS issue:
>    https://bugs.openjdk.java.net/browse/JDK-8182029
>
> This patch replaces the top-level docs index.html to a HTML-level redirect to the API overview page.  We can come back to this page later in a future release to convey grouping information.
>
This looks okay to me and I think okay for Docs.gmk to have the content 
of the top-level index.html (I initially thought it might make more 
sense to have it in the repo but it's probably not worth it).

-Alan


From magnus.ihse.bursie at oracle.com  Tue Jun 13 10:57:50 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 13 Jun 2017 12:57:50 +0200
Subject: Request Review JDK-8182029: Make the top-level docs index.html to
 a HTML-level redirect to the API overview page
In-Reply-To: <138981a0-e538-a775-80f8-a5f7cc12fe0b@oracle.com>
References: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>
 <138981a0-e538-a775-80f8-a5f7cc12fe0b@oracle.com>
Message-ID: <9e210b0b-3e37-9494-bc63-95d027d32f07@oracle.com>



On 2017-06-13 09:26, Alan Bateman wrote:
> On 13/06/2017 06:21, Mandy Chung wrote:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182029/webrev.00/
>>
>> JBS issue:
>>    https://bugs.openjdk.java.net/browse/JDK-8182029
>>
>> This patch replaces the top-level docs index.html to a HTML-level 
>> redirect to the API overview page.  We can come back to this page 
>> later in a future release to convey grouping information.
>>
> This looks okay to me and I think okay for Docs.gmk to have the 
> content of the top-level index.html (I initially thought it might make 
> more sense to have it in the repo but it's probably not worth it).

I agree. It's trivial enough (although barely) to be created by Docs.gmk 
like this.

For a long-term solution I'd like to see a more correct change (for 
instance, index.html will not be regenerated if JDK_INDEX_CONTENT 
changes), but for jdk9 this is okay.

/Magnus

>
> -Alan



From erik.osterlund at oracle.com  Tue Jun 13 12:49:45 2017
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 13 Jun 2017 14:49:45 +0200
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
In-Reply-To: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
References: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
Message-ID: <593FDF69.4030701@oracle.com>

Hi,

This looks good to me. Relying on header include order is never a good idea.

Thanks,
/Erik

On 2017-06-08 01:51, Kim Barrett wrote:
> Please review this change to the build of hotspot to globally define
> the __STDC_xxx_MACROS macros via the command line, rather than
> via #defines scattered through several header files.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8086005
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
> http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/
>
> Testing:
> JPRT
>



From kim.barrett at oracle.com  Tue Jun 13 13:16:10 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 13 Jun 2017 09:16:10 -0400
Subject: RFR: 8086005: Define __STDC_xxx_MACROS config macros globally via
 build system
In-Reply-To: <593FDF69.4030701@oracle.com>
References: <FD57E385-8AE7-4260-818F-34DD4F29B18C@oracle.com>
 <593FDF69.4030701@oracle.com>
Message-ID: <2D79DE80-C5B3-48E4-830F-669A090490C0@oracle.com>

> On Jun 13, 2017, at 8:49 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
> 
> Hi,
> 
> This looks good to me. Relying on header include order is never a good idea.

Thanks.

> 
> Thanks,
> /Erik
> 
> On 2017-06-08 01:51, Kim Barrett wrote:
>> Please review this change to the build of hotspot to globally define
>> the __STDC_xxx_MACROS macros via the command line, rather than
>> via #defines scattered through several header files.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8086005
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8086005/hs.00/
>> http://cr.openjdk.java.net/~kbarrett/8086005/hotspot.00/
>> 
>> Testing:
>> JPRT




From claes.redestad at oracle.com  Tue Jun 13 14:03:31 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 13 Jun 2017 16:03:31 +0200
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
Message-ID: <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>

<adding build-dev; see 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html 
for missing context>

Updated webrevs:
http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
http://cr.openjdk.java.net/~redestad/8181147/top.04/

In this version there are various cleanups based on Martin's
comments, improved test coverage and some small changes to
ensure the updated test builds and runs on all our supported
platforms.

If someone with access to any of the platforms not supported
by Oracle could take this for a spin and ensure linking the newly
added test against libjava works as expected (or suggest how
to make it work if it doesn't) then that'd be much appreciated.

Thanks!

/Claes

On 06/13/2017 02:01 AM, Martin Buchholz wrote:
> I'm hoping Xueming will review as well.
> +    char asciiCheck;
> +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
> +        asciiCheck |= *p;
> +    }
> +    len = (p - str);
> Probably conversion from ptrdiff_t to int needs a cast.
>
> Someday we might need to worry about input string longer than 2^31, 
> but that's a pre-existing problem.
>
> The signed-ness of char being implementation-defined makes me nervous.
> Maybe do all the bit operations using explicit unsigned char, then the 
> final test becomes simply
>
> asciiCheck <= 0x80
>
>
> On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     Hi Martin,
>
>     thanks for reviewing!
>
>     On 2017-06-12 22:14, Martin Buchholz wrote:
>
>         +/* Optimized for char set UTF-8 */
>
>         "charset" is a (poor misnomer!) jargon term, not two words.
>
>
>     I got that from the existing use of "char set" in this file, but
>     will fix it in all places.
>
>
>         ---
>
>         +    for (b = str[len]; b != '\0'; len++, b = str[len]) {
>         +        if (isAscii && b & 0x80) {
>         +            isAscii = JNI_FALSE;
>         +        }
>         +    }
>
>         I would write this more like
>
>         const signed char *p;
>         int isAscii;
>
>         for (isAscii = 0, p = (const signed char *) str; *p != '\0';
>         p++) isAscii &= (*p >= 0);
>
>
>     Did you mean for isAscii to be initialized to 1 (true) and then be
>     cleared to 0 (false) when *p >= 0 is false?
>
>
>         Then length is (p - str)
>
>
>     How about something like this to hoist the second comparison from
>     the loop:
>
>         int len;
>         char asciiCheck;
>         for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>             asciiCheck |= *p;
>         }
>         len = (p - str);
>
>         if (asciiCheck & 0x80) {
>             // ascii fast-path
>             return newSizedString8859_1(env, str, len);
>         }
>
>         ...
>
>         ---
>
>         +    jbyteArray hab = NULL;
>
>         I'm having a hard time decoding the name "hab"
>
>
>     Not sure, but my guess is "heap allocated byteArray".
>
>
>         ---
>
>         The code below is not UTF-8 specific. Can it be refactored?
>
>         +    hab = (*env)->NewByteArray(env, len);
>         +    if (hab != 0) {
>         +        jclass strClazz = JNU_ClassString(env);
>         +        CHECK_NULL_RETURN(strClazz, 0);
>         +        (*env)->SetByteArrayRegion(env, hab, 0, len, (jbyte
>         *)str);
>         +        result = (*env)->NewObject(env, strClazz,
>         +                                       String_init_ID, hab,
>         jnuEncoding);
>         +        (*env)->DeleteLocalRef(env, hab);
>         +        return result;
>         +    }
>
>
>     Yes, probably. The excessive copy-paste here is due to a crash
>     issue I ran into when
>     Charset.isSupported was called without proper initialization. It
>     has since been
>     resolved, but seems I forgot to revisit this part.
>
>     I also realized I haven't added a test for this method. I'll look
>     into doing the
>     refactoring and adding some sanity testing tomorrow.
>
>
>         ---
>
>         We probably want to use unicode escapes in out java sources to
>         keep all source files strictly ASCII.
>
>
>     You mean in the test? Sure.
>
>     Refreshed the jdk webrev:
>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>     <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/> - more to
>     come.
>
>     Thanks!
>
>     /Claes
>
>



From mandy.chung at oracle.com  Tue Jun 13 15:52:46 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 13 Jun 2017 08:52:46 -0700
Subject: Request Review JDK-8182029: Make the top-level docs index.html to
 a HTML-level redirect to the API overview page
In-Reply-To: <9e210b0b-3e37-9494-bc63-95d027d32f07@oracle.com>
References: <BFB5682B-F221-473C-9AD4-7D98F2731B8F@oracle.com>
 <138981a0-e538-a775-80f8-a5f7cc12fe0b@oracle.com>
 <9e210b0b-3e37-9494-bc63-95d027d32f07@oracle.com>
Message-ID: <1D436F1C-F798-4620-BA0A-E392E3B7E7C4@oracle.com>


> On Jun 13, 2017, at 3:57 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> 
> 
> On 2017-06-13 09:26, Alan Bateman wrote:
>> On 13/06/2017 06:21, Mandy Chung wrote:
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182029/webrev.00/
>>> 
>>> JBS issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-8182029
>>> 
>>> This patch replaces the top-level docs index.html to a HTML-level redirect to the API overview page.  We can come back to this page later in a future release to convey grouping information.
>>> 
>> This looks okay to me and I think okay for Docs.gmk to have the content of the top-level index.html (I initially thought it might make more sense to have it in the repo but it's probably not worth it).

> I agree. It's trivial enough (although barely) to be created by Docs.gmk like this.
> 

I considered checking in this file.  As this is trivial and only few lines, Docs.gmk has several text snipplets and this follows the same convention.

> For a long-term solution I'd like to see a more correct change (for instance, index.html will not be regenerated if JDK_INDEX_CONTENT changes), but for jdk9 this is okay.

I will file a bug for this.  Checking in a file would be one way to solve this.

Mandy

From nishit.jain at oracle.com  Tue Jun 13 16:57:59 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 13 Jun 2017 22:27:59 +0530
Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib
Message-ID: <8610a85e-f12a-2a27-2be7-b25da7ac899e@oracle.com>

Hi,

Please review the fix for JDK-8176583

Bug: https://bugs.openjdk.java.net/browse/JDK-8176583
Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.02/

Fix: Relocated currency.data from java.base module 
(/java.base/java/util/currency.data) to /lib directory

Review mail thread of JDK-8176583 at i18n-dev: 
http://mail.openjdk.java.net/pipermail/i18n-dev/2017-June/002307.html

Regards,
Nishit Jain


From martinrb at google.com  Tue Jun 13 19:09:12 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 13 Jun 2017 12:09:12 -0700
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
Message-ID: <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>

Looks good to me, although still hoping for more review from others.

+    if (bytes != 0) {

Style: use NULL.

+static jstring newStringJava(JNIEnv *env, const char *str) {


I expected two versions, one that took a length and one that did not, as
you did with newString8859_1.

---

TIL that jbyte is signed char, not plain char, and so is more consistent
with java "byte", hence less error prone, at least in theory.

---

Can we test different native environments by using -Dsun.jnu.encoding=... ?



On Tue, Jun 13, 2017 at 7:03 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> <adding build-dev; see http://mail.openjdk.java.net/p
> ipermail/core-libs-dev/2017-June/048233.html for missing context>
>
> Updated webrevs:
> http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
> http://cr.openjdk.java.net/~redestad/8181147/top.04/
>
> In this version there are various cleanups based on Martin's
> comments, improved test coverage and some small changes to
> ensure the updated test builds and runs on all our supported
> platforms.
>
> If someone with access to any of the platforms not supported
> by Oracle could take this for a spin and ensure linking the newly
> added test against libjava works as expected (or suggest how
> to make it work if it doesn't) then that'd be much appreciated.
>
> Thanks!
>
> /Claes
>
> On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>
>> I'm hoping Xueming will review as well.
>> +    char asciiCheck;
>> +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>> +        asciiCheck |= *p;
>> +    }
>> +    len = (p - str);
>> Probably conversion from ptrdiff_t to int needs a cast.
>>
>> Someday we might need to worry about input string longer than 2^31, but
>> that's a pre-existing problem.
>>
>> The signed-ness of char being implementation-defined makes me nervous.
>> Maybe do all the bit operations using explicit unsigned char, then the
>> final test becomes simply
>>
>> asciiCheck <= 0x80
>>
>>
>> On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad <
>> claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>
>>     Hi Martin,
>>
>>     thanks for reviewing!
>>
>>     On 2017-06-12 22:14, Martin Buchholz wrote:
>>
>>         +/* Optimized for char set UTF-8 */
>>
>>         "charset" is a (poor misnomer!) jargon term, not two words.
>>
>>
>>     I got that from the existing use of "char set" in this file, but
>>     will fix it in all places.
>>
>>
>>         ---
>>
>>         +    for (b = str[len]; b != '\0'; len++, b = str[len]) {
>>         +        if (isAscii && b & 0x80) {
>>         +            isAscii = JNI_FALSE;
>>         +        }
>>         +    }
>>
>>         I would write this more like
>>
>>         const signed char *p;
>>         int isAscii;
>>
>>         for (isAscii = 0, p = (const signed char *) str; *p != '\0';
>>         p++) isAscii &= (*p >= 0);
>>
>>
>>     Did you mean for isAscii to be initialized to 1 (true) and then be
>>     cleared to 0 (false) when *p >= 0 is false?
>>
>>
>>         Then length is (p - str)
>>
>>
>>     How about something like this to hoist the second comparison from
>>     the loop:
>>
>>         int len;
>>         char asciiCheck;
>>         for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>             asciiCheck |= *p;
>>         }
>>         len = (p - str);
>>
>>         if (asciiCheck & 0x80) {
>>             // ascii fast-path
>>             return newSizedString8859_1(env, str, len);
>>         }
>>
>>         ...
>>
>>         ---
>>
>>         +    jbyteArray hab = NULL;
>>
>>         I'm having a hard time decoding the name "hab"
>>
>>
>>     Not sure, but my guess is "heap allocated byteArray".
>>
>>
>>         ---
>>
>>         The code below is not UTF-8 specific. Can it be refactored?
>>
>>         +    hab = (*env)->NewByteArray(env, len);
>>         +    if (hab != 0) {
>>         +        jclass strClazz = JNU_ClassString(env);
>>         +        CHECK_NULL_RETURN(strClazz, 0);
>>         +        (*env)->SetByteArrayRegion(env, hab, 0, len, (jbyte
>>         *)str);
>>         +        result = (*env)->NewObject(env, strClazz,
>>         +                                       String_init_ID, hab,
>>         jnuEncoding);
>>         +        (*env)->DeleteLocalRef(env, hab);
>>         +        return result;
>>         +    }
>>
>>
>>     Yes, probably. The excessive copy-paste here is due to a crash
>>     issue I ran into when
>>     Charset.isSupported was called without proper initialization. It
>>     has since been
>>     resolved, but seems I forgot to revisit this part.
>>
>>     I also realized I haven't added a test for this method. I'll look
>>     into doing the
>>     refactoring and adding some sanity testing tomorrow.
>>
>>
>>         ---
>>
>>         We probably want to use unicode escapes in out java sources to
>>         keep all source files strictly ASCII.
>>
>>
>>     You mean in the test? Sure.
>>
>>     Refreshed the jdk webrev:
>>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>>     <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/> - more to
>>     come.
>>
>>     Thanks!
>>
>>     /Claes
>>
>>
>>
>


From claes.redestad at oracle.com  Tue Jun 13 20:27:02 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 13 Jun 2017 22:27:02 +0200
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
Message-ID: <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>



On 2017-06-13 21:09, Martin Buchholz wrote:
> Looks good to me, although still hoping for more review from others.

I expect Sherman to weigh in. :-)

>
> +    if (bytes != 0) {
> Style: use NULL.

Done.

>
> +static jstring newStringJava(JNIEnv *env, const char *str) {
>
> I expected two versions, one that took a length and one that did not, 
> as you did with newString8859_1.

Ah, yes. Refactored and updated in-place.

> ---
> TIL that jbyte is signed char, not plain char, and so is more 
> consistent with java "byte", hence less error prone, at least in theory.
>
> ---
> Can we test different native environments by using 
> -Dsun.jnu.encoding=... ?

I did try, but jtreg currently doesn't appear to support specifying 
flags for main/native @run:s (and helpfully suggests using main/othervm 
instead...) - maybe someone knows a way around this?

/Claes

>
>
>
> On Tue, Jun 13, 2017 at 7:03 AM, Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     <adding build-dev; see
>     http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html
>     <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html>
>     for missing context>
>
>     Updated webrevs:
>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>     <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>     http://cr.openjdk.java.net/~redestad/8181147/top.04/
>     <http://cr.openjdk.java.net/%7Eredestad/8181147/top.04/>
>
>     In this version there are various cleanups based on Martin's
>     comments, improved test coverage and some small changes to
>     ensure the updated test builds and runs on all our supported
>     platforms.
>
>     If someone with access to any of the platforms not supported
>     by Oracle could take this for a spin and ensure linking the newly
>     added test against libjava works as expected (or suggest how
>     to make it work if it doesn't) then that'd be much appreciated.
>
>     Thanks!
>
>     /Claes
>
>     On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>
>         I'm hoping Xueming will review as well.
>         +    char asciiCheck;
>         +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>         +        asciiCheck |= *p;
>         +    }
>         +    len = (p - str);
>         Probably conversion from ptrdiff_t to int needs a cast.
>
>         Someday we might need to worry about input string longer than
>         2^31, but that's a pre-existing problem.
>
>         The signed-ness of char being implementation-defined makes me
>         nervous.
>         Maybe do all the bit operations using explicit unsigned char,
>         then the final test becomes simply
>
>         asciiCheck <= 0x80
>
>
>         On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad
>         <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>
>         <mailto:claes.redestad at oracle.com
>         <mailto:claes.redestad at oracle.com>>> wrote:
>
>             Hi Martin,
>
>             thanks for reviewing!
>
>             On 2017-06-12 22:14, Martin Buchholz wrote:
>
>                 +/* Optimized for char set UTF-8 */
>
>                 "charset" is a (poor misnomer!) jargon term, not two
>         words.
>
>
>             I got that from the existing use of "char set" in this
>         file, but
>             will fix it in all places.
>
>
>                 ---
>
>                 +    for (b = str[len]; b != '\0'; len++, b = str[len]) {
>                 +        if (isAscii && b & 0x80) {
>                 +            isAscii = JNI_FALSE;
>                 +        }
>                 +    }
>
>                 I would write this more like
>
>                 const signed char *p;
>                 int isAscii;
>
>                 for (isAscii = 0, p = (const signed char *) str; *p !=
>         '\0';
>                 p++) isAscii &= (*p >= 0);
>
>
>             Did you mean for isAscii to be initialized to 1 (true) and
>         then be
>             cleared to 0 (false) when *p >= 0 is false?
>
>
>                 Then length is (p - str)
>
>
>             How about something like this to hoist the second
>         comparison from
>             the loop:
>
>                 int len;
>                 char asciiCheck;
>                 for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>                     asciiCheck |= *p;
>                 }
>                 len = (p - str);
>
>                 if (asciiCheck & 0x80) {
>                     // ascii fast-path
>                     return newSizedString8859_1(env, str, len);
>                 }
>
>                 ...
>
>                 ---
>
>                 +    jbyteArray hab = NULL;
>
>                 I'm having a hard time decoding the name "hab"
>
>
>             Not sure, but my guess is "heap allocated byteArray".
>
>
>                 ---
>
>                 The code below is not UTF-8 specific. Can it be
>         refactored?
>
>                 +    hab = (*env)->NewByteArray(env, len);
>                 +    if (hab != 0) {
>                 +        jclass strClazz = JNU_ClassString(env);
>                 +        CHECK_NULL_RETURN(strClazz, 0);
>                 +        (*env)->SetByteArrayRegion(env, hab, 0, len,
>         (jbyte
>                 *)str);
>                 +        result = (*env)->NewObject(env, strClazz,
>                 +  String_init_ID, hab,
>                 jnuEncoding);
>                 +        (*env)->DeleteLocalRef(env, hab);
>                 +        return result;
>                 +    }
>
>
>             Yes, probably. The excessive copy-paste here is due to a crash
>             issue I ran into when
>             Charset.isSupported was called without proper
>         initialization. It
>             has since been
>             resolved, but seems I forgot to revisit this part.
>
>             I also realized I haven't added a test for this method.
>         I'll look
>             into doing the
>             refactoring and adding some sanity testing tomorrow.
>
>
>                 ---
>
>                 We probably want to use unicode escapes in out java
>         sources to
>                 keep all source files strictly ASCII.
>
>
>             You mean in the test? Sure.
>
>             Refreshed the jdk webrev:
>         http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>         <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>             <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/
>         <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>> -
>         more to
>             come.
>
>             Thanks!
>
>             /Claes
>
>
>
>



From erik.joelsson at oracle.com  Wed Jun 14 06:52:54 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Jun 2017 08:52:54 +0200
Subject: Review Request JDK-8182032: Make java.compiler upgradeable
In-Reply-To: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com>
References: <268EE83D-7C9C-4BF4-B062-10EB9F06C770@oracle.com>
Message-ID: <5093902b-7f33-d543-cf39-629da85bff57@oracle.com>

Hello Mandy,

Looks good to me.

/Erik


On 2017-06-13 07:35, Mandy Chung wrote:
> Webrev at:
>     http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182032/webrev.00/
>
> java.compiler is a standalone technology that allows to be running on older JDK, in particular for IDE to support new language features.
>
> This patch takes out the make logic to find the modules that directly and indirectly require any upgradeable modules and include them as upgradeable.  Instead it lists all upgradeable modules.  The list of upgradeable modules is small whereas the exclude list is not (which is also error-prone to find them).  I have added a new test to verify what modules are hashed in java.base.
>
> Mandy



From erik.joelsson at oracle.com  Wed Jun 14 07:08:10 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Jun 2017 09:08:10 +0200
Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib
In-Reply-To: <8610a85e-f12a-2a27-2be7-b25da7ac899e@oracle.com>
References: <8610a85e-f12a-2a27-2be7-b25da7ac899e@oracle.com>
Message-ID: <ce774b71-0c89-034b-a302-6086ec3ff1b1@oracle.com>

Build change looks good.

/Erik


On 2017-06-13 18:57, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8176583
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176583
> Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.02/
>
> Fix: Relocated currency.data from java.base module 
> (/java.base/java/util/currency.data) to /lib directory
>
> Review mail thread of JDK-8176583 at i18n-dev: 
> http://mail.openjdk.java.net/pipermail/i18n-dev/2017-June/002307.html
>
> Regards,
> Nishit Jain



From erik.joelsson at oracle.com  Wed Jun 14 07:11:45 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Jun 2017 09:11:45 +0200
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
Message-ID: <d71793f1-5f5b-0653-e552-988323c33f29@oracle.com>

Build changes look good to me.

/Erik


On 2017-06-13 22:27, Claes Redestad wrote:
>
>
> On 2017-06-13 21:09, Martin Buchholz wrote:
>> Looks good to me, although still hoping for more review from others.
>
> I expect Sherman to weigh in. :-)
>
>>
>> +    if (bytes != 0) {
>> Style: use NULL.
>
> Done.
>
>>
>> +static jstring newStringJava(JNIEnv *env, const char *str) {
>>
>> I expected two versions, one that took a length and one that did not, 
>> as you did with newString8859_1.
>
> Ah, yes. Refactored and updated in-place.
>
>> ---
>> TIL that jbyte is signed char, not plain char, and so is more 
>> consistent with java "byte", hence less error prone, at least in theory.
>>
>> ---
>> Can we test different native environments by using 
>> -Dsun.jnu.encoding=... ?
>
> I did try, but jtreg currently doesn't appear to support specifying 
> flags for main/native @run:s (and helpfully suggests using 
> main/othervm instead...) - maybe someone knows a way around this?
>
> /Claes
>
>>
>>
>>
>> On Tue, Jun 13, 2017 at 7:03 AM, Claes Redestad 
>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>
>>     <adding build-dev; see
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html>
>>     for missing context>
>>
>>     Updated webrevs:
>>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>>     http://cr.openjdk.java.net/~redestad/8181147/top.04/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/top.04/>
>>
>>     In this version there are various cleanups based on Martin's
>>     comments, improved test coverage and some small changes to
>>     ensure the updated test builds and runs on all our supported
>>     platforms.
>>
>>     If someone with access to any of the platforms not supported
>>     by Oracle could take this for a spin and ensure linking the newly
>>     added test against libjava works as expected (or suggest how
>>     to make it work if it doesn't) then that'd be much appreciated.
>>
>>     Thanks!
>>
>>     /Claes
>>
>>     On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>>
>>         I'm hoping Xueming will review as well.
>>         +    char asciiCheck;
>>         +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>         +        asciiCheck |= *p;
>>         +    }
>>         +    len = (p - str);
>>         Probably conversion from ptrdiff_t to int needs a cast.
>>
>>         Someday we might need to worry about input string longer than
>>         2^31, but that's a pre-existing problem.
>>
>>         The signed-ness of char being implementation-defined makes me
>>         nervous.
>>         Maybe do all the bit operations using explicit unsigned char,
>>         then the final test becomes simply
>>
>>         asciiCheck <= 0x80
>>
>>
>>         On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad
>>         <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>
>>         <mailto:claes.redestad at oracle.com
>>         <mailto:claes.redestad at oracle.com>>> wrote:
>>
>>             Hi Martin,
>>
>>             thanks for reviewing!
>>
>>             On 2017-06-12 22:14, Martin Buchholz wrote:
>>
>>                 +/* Optimized for char set UTF-8 */
>>
>>                 "charset" is a (poor misnomer!) jargon term, not two
>>         words.
>>
>>
>>             I got that from the existing use of "char set" in this
>>         file, but
>>             will fix it in all places.
>>
>>
>>                 ---
>>
>>                 +    for (b = str[len]; b != '\0'; len++, b = 
>> str[len]) {
>>                 +        if (isAscii && b & 0x80) {
>>                 +            isAscii = JNI_FALSE;
>>                 +        }
>>                 +    }
>>
>>                 I would write this more like
>>
>>                 const signed char *p;
>>                 int isAscii;
>>
>>                 for (isAscii = 0, p = (const signed char *) str; *p !=
>>         '\0';
>>                 p++) isAscii &= (*p >= 0);
>>
>>
>>             Did you mean for isAscii to be initialized to 1 (true) and
>>         then be
>>             cleared to 0 (false) when *p >= 0 is false?
>>
>>
>>                 Then length is (p - str)
>>
>>
>>             How about something like this to hoist the second
>>         comparison from
>>             the loop:
>>
>>                 int len;
>>                 char asciiCheck;
>>                 for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>                     asciiCheck |= *p;
>>                 }
>>                 len = (p - str);
>>
>>                 if (asciiCheck & 0x80) {
>>                     // ascii fast-path
>>                     return newSizedString8859_1(env, str, len);
>>                 }
>>
>>                 ...
>>
>>                 ---
>>
>>                 +    jbyteArray hab = NULL;
>>
>>                 I'm having a hard time decoding the name "hab"
>>
>>
>>             Not sure, but my guess is "heap allocated byteArray".
>>
>>
>>                 ---
>>
>>                 The code below is not UTF-8 specific. Can it be
>>         refactored?
>>
>>                 +    hab = (*env)->NewByteArray(env, len);
>>                 +    if (hab != 0) {
>>                 +        jclass strClazz = JNU_ClassString(env);
>>                 +        CHECK_NULL_RETURN(strClazz, 0);
>>                 +        (*env)->SetByteArrayRegion(env, hab, 0, len,
>>         (jbyte
>>                 *)str);
>>                 +        result = (*env)->NewObject(env, strClazz,
>>                 +  String_init_ID, hab,
>>                 jnuEncoding);
>>                 +        (*env)->DeleteLocalRef(env, hab);
>>                 +        return result;
>>                 +    }
>>
>>
>>             Yes, probably. The excessive copy-paste here is due to a 
>> crash
>>             issue I ran into when
>>             Charset.isSupported was called without proper
>>         initialization. It
>>             has since been
>>             resolved, but seems I forgot to revisit this part.
>>
>>             I also realized I haven't added a test for this method.
>>         I'll look
>>             into doing the
>>             refactoring and adding some sanity testing tomorrow.
>>
>>
>>                 ---
>>
>>                 We probably want to use unicode escapes in out java
>>         sources to
>>                 keep all source files strictly ASCII.
>>
>>
>>             You mean in the test? Sure.
>>
>>             Refreshed the jdk webrev:
>>         http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>> -
>>         more to
>>             come.
>>
>>             Thanks!
>>
>>             /Claes
>>
>>
>>
>>
>



From erik.helin at oracle.com  Wed Jun 14 11:50:06 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 14 Jun 2017 13:50:06 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170609102041.GA2477@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
Message-ID: <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>

Hey Adrian,

thanks for contributing and signing the OCA!

I think the first three patches (hotspot-add-missing-log-header.diff, 
hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) 
all look good, thanks for fixing broken code. Consider them Reviewed by 
me. Every patch needs a corresponding issue in the bug tracker, so I 
went ahead and created:
- https://bugs.openjdk.java.net/browse/JDK-8182163
- https://bugs.openjdk.java.net/browse/JDK-8182164
- https://bugs.openjdk.java.net/browse/JDK-8182165

For the last of those three patches, 
rename-space-linux-atomic-header.diff, did you do `hg mv` when renaming 
the file (in order to preserve version control history)?

For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For 
example, the following is a bit surprising to me (mostly because I'm not 
familiar with zero):

--- a/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
+++ b/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
@@ -37,7 +37,7 @@
  // understanding that there may be concurrent readers of that memory.
  void memset_with_concurrent_readers(void* to, int value, size_t size);

-#ifdef SPARC
+#if defined(SPARC) && !defined(ZERO)

When this code was written, the intent was clearly to have a specialized 
version of this function for SPARC. When writing such code, do we always 
have to take into account the zero case with !defined(ZERO)? That 
doesn't seem like the right (or a scalable) approach to me.

Severin and/or Roman, do you guys know more about Zero and how this 
should work? If I want to write a function that I want to specialize for 
e.g. x86-64 or arm, do I always have to take Zero into account? Or 
should some other define be used, like #ifdef TARGET_ARCH_sparc?

Thanks,
Erik

On 06/09/2017 12:20 PM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> I am currently working on fixing OpenJDK-9 on all non-mainstream
> targets available in Debian. For Debian/sparc64, the attached four
> patches were necessary to make the build succeed [1].
>
> I know the patches cannot be merged right now, but I'm posting them
> anyway in case someone else is interested in using them.
>
> All patches are:
>
>     Signed-off-by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
>
> I also signed the OCA.
>
> I'm now looking into fixing the builds on alpha (DEC Alpha), armel
> (ARMv4T), m68k (680x0), powerpc (PPC32) and sh4 (SuperH/J-Core).
>
> Cheers,
> Adrian
>
>> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1496931563&raw=0
>


From glaubitz at physik.fu-berlin.de  Wed Jun 14 12:04:08 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 14 Jun 2017 14:04:08 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
Message-ID: <20170614120408.GB16230@physik.fu-berlin.de>

Hi Erik!

On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
> thanks for contributing and signing the OCA!

Thanks for reviewing my patches ;-).

> I think the first three patches (hotspot-add-missing-log-header.diff,
> hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) all
> look good, thanks for fixing broken code. Consider them Reviewed by me.
> Every patch needs a corresponding issue in the bug tracker, so I went ahead
> and created:
> - https://bugs.openjdk.java.net/browse/JDK-8182163
> - https://bugs.openjdk.java.net/browse/JDK-8182164
> - https://bugs.openjdk.java.net/browse/JDK-8182165

Great, thank you!

> For the last of those three patches, rename-space-linux-atomic-header.diff,
> did you do `hg mv` when renaming the file (in order to preserve version
> control history)?

I'm not 100% whether I did that. I'm not very familar with mercurial
as I'm more used to git. If the patch format looks wrong to you, I can
resend a revised version of this patch.

> For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For
> example, the following is a bit surprising to me (mostly because I'm not
> familiar with zero):

The fourth patch may not be a 100% clean as it's more a result of
fixing compile errors until the build finished. I can definitely send
a revised, cleaner version of this patch after more extensive testing.

> When this code was written, the intent was clearly to have a specialized
> version of this function for SPARC. When writing such code, do we always
> have to take into account the zero case with !defined(ZERO)? That doesn't
> seem like the right (or a scalable) approach to me.

I agree. It's rather suboptimal.

> Severin and/or Roman, do you guys know more about Zero and how this should
> work? If I want to write a function that I want to specialize for e.g.
> x86-64 or arm, do I always have to take Zero into account? Or should some
> other define be used, like #ifdef TARGET_ARCH_sparc?

Thanks a lot for the review!

Can't wait for my first patches getting merged into OpenJDK ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From sgehwolf at redhat.com  Wed Jun 14 12:21:24 2017
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 14 Jun 2017 14:21:24 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
Message-ID: <1497442884.3741.1.camel@redhat.com>

Hi Eric,

On Wed, 2017-06-14 at 13:50 +0200, Erik Helin wrote:
> For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For?
> example, the following is a bit surprising to me (mostly because I'm not?
> familiar with zero):
> 
> --- a/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
> +++ b/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
> @@ -37,7 +37,7 @@
> ? // understanding that there may be concurrent readers of that memory.
> ? void memset_with_concurrent_readers(void* to, int value, size_t size);
> 
> -#ifdef SPARC
> +#if defined(SPARC) && !defined(ZERO)
> 
> When this code was written, the intent was clearly to have a specialized?
> version of this function for SPARC. When writing such code, do we always?
> have to take into account the zero case with !defined(ZERO)?

As of now, yes I think so. The thing is that Zero is supposed to be
architecture agnostic for the most part. That is, you can build Zero on
x86_64, SPARC, aarch64, etc.

> That?
> doesn't seem like the right (or a scalable) approach to me.

Agreed. That's how it is at the moment, though.

> Severin and/or Roman, do you guys know more about Zero and how this?
> should work? If I want to write a function that I want to specialize for?
> e.g. x86-64 or arm, do I always have to take Zero into account? Or?
> should some other define be used, like #ifdef TARGET_ARCH_sparc?

So the ZERO define can happen regardless of arch. I don't really know
any define which does what you want except #if defined(<ARCH>) &&
!defined(ZERO) perhaps.

Thanks,
Severin

> Thanks,
> Erik
> 
> On 06/09/2017 12:20 PM, John Paul Adrian Glaubitz wrote:
> > Hi!
> > 
> > I am currently working on fixing OpenJDK-9 on all non-mainstream
> > targets available in Debian. For Debian/sparc64, the attached four
> > patches were necessary to make the build succeed [1].
> > 
> > I know the patches cannot be merged right now, but I'm posting them
> > anyway in case someone else is interested in using them.
> > 
> > All patches are:
> > 
> > ????Signed-off-by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
> > 
> > I also signed the OCA.
> > 
> > I'm now looking into fixing the builds on alpha (DEC Alpha), armel
> > (ARMv4T), m68k (680x0), powerpc (PPC32) and sh4 (SuperH/J-Core).
> > 
> > Cheers,
> > Adrian
> > 
> > > [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1496931563&raw=0



From erik.helin at oracle.com  Wed Jun 14 12:30:24 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 14 Jun 2017 14:30:24 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170614120408.GB16230@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
Message-ID: <2979e5ff-5bc7-fd83-8b15-b62dfa9cf593@oracle.com>

On 06/14/2017 02:04 PM, John Paul Adrian Glaubitz wrote:
> Hi Erik!
>
> On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
>> thanks for contributing and signing the OCA!
>
> Thanks for reviewing my patches ;-).
>
>> I think the first three patches (hotspot-add-missing-log-header.diff,
>> hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) all
>> look good, thanks for fixing broken code. Consider them Reviewed by me.
>> Every patch needs a corresponding issue in the bug tracker, so I went ahead
>> and created:
>> - https://bugs.openjdk.java.net/browse/JDK-8182163
>> - https://bugs.openjdk.java.net/browse/JDK-8182164
>> - https://bugs.openjdk.java.net/browse/JDK-8182165
>
> Great, thank you!
>
>> For the last of those three patches, rename-space-linux-atomic-header.diff,
>> did you do `hg mv` when renaming the file (in order to preserve version
>> control history)?
>
> I'm not 100% whether I did that. I'm not very familar with mercurial
> as I'm more used to git. If the patch format looks wrong to you, I can
> resend a revised version of this patch.

No worries, someone will have to commit your patches anyway (most likely 
me). I can have a look then and ensure that `hg mv` is used for renaming 
the file.

>> For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For
>> example, the following is a bit surprising to me (mostly because I'm not
>> familiar with zero):
>
> The fourth patch may not be a 100% clean as it's more a result of
> fixing compile errors until the build finished. I can definitely send
> a revised, cleaner version of this patch after more extensive testing.

Yeah, I guessed that was the case :) Without the fourth patch 
(fix-zero-build-on-sparc.diff), does the "regular" linux/sparc build 
compile and run? Is that something you can test?

Also, have you run the tier 1 testing for hotspot (the tests that need 
to pass for every commit)? You can run those tests by running (from the 
top-level "root" repo):

$ make test TEST=hotspot_tier1

or, if you want to try the new run-test functionality

$ make run-test-hotspot_tier1

>> When this code was written, the intent was clearly to have a specialized
>> version of this function for SPARC. When writing such code, do we always
>> have to take into account the zero case with !defined(ZERO)? That doesn't
>> seem like the right (or a scalable) approach to me.
>
> I agree. It's rather suboptimal.

Yes, which is why I want to get a better understanding before I give a 
"thumbs up" for this last patch. I hope (suspect) that there is a better 
way to do this.

>> Severin and/or Roman, do you guys know more about Zero and how this should
>> work? If I want to write a function that I want to specialize for e.g.
>> x86-64 or arm, do I always have to take Zero into account? Or should some
>> other define be used, like #ifdef TARGET_ARCH_sparc?
>
> Thanks a lot for the review!

You are welcome :)

> Can't wait for my first patches getting merged into OpenJDK ;-).

Well, you do need one more reviewer for your patches. Hotspot requires 
at least two reviewers for every patch (and one of the reviewers has to 
have the Reviewer role).

Thanks,
Erik

> Adrian
>


From glaubitz at physik.fu-berlin.de  Wed Jun 14 12:46:07 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 14 Jun 2017 14:46:07 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <2979e5ff-5bc7-fd83-8b15-b62dfa9cf593@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <2979e5ff-5bc7-fd83-8b15-b62dfa9cf593@oracle.com>
Message-ID: <20170614124607.GD16230@physik.fu-berlin.de>

On Wed, Jun 14, 2017 at 02:30:24PM +0200, Erik Helin wrote:
> >I'm not 100% whether I did that. I'm not very familar with mercurial
> >as I'm more used to git. If the patch format looks wrong to you, I can
> >resend a revised version of this patch.
> 
> No worries, someone will have to commit your patches anyway (most likely
> me). I can have a look then and ensure that `hg mv` is used for renaming the
> file.

Great, thank you!

> >>For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For
> >>example, the following is a bit surprising to me (mostly because I'm not
> >>familiar with zero):
> >
> >The fourth patch may not be a 100% clean as it's more a result of
> >fixing compile errors until the build finished. I can definitely send
> >a revised, cleaner version of this patch after more extensive testing.
> 
> Yeah, I guessed that was the case :) Without the fourth patch
> (fix-zero-build-on-sparc.diff), does the "regular" linux/sparc build compile
> and run? Is that something you can test?

I will have a look tonight. I'm currently at work.

> Also, have you run the tier 1 testing for hotspot (the tests that need to
> pass for every commit)? You can run those tests by running (from the
> top-level "root" repo):
> 
> $ make test TEST=hotspot_tier1
> 
> or, if you want to try the new run-test functionality
> 
> $ make run-test-hotspot_tier1

Ok, I will give that a try.

> >>When this code was written, the intent was clearly to have a specialized
> >>version of this function for SPARC. When writing such code, do we always
> >>have to take into account the zero case with !defined(ZERO)? That doesn't
> >>seem like the right (or a scalable) approach to me.
> >
> >I agree. It's rather suboptimal.
> 
> Yes, which is why I want to get a better understanding before I give a
> "thumbs up" for this last patch. I hope (suspect) that there is a better way
> to do this.

Ok.

> >Can't wait for my first patches getting merged into OpenJDK ;-).
> 
> Well, you do need one more reviewer for your patches. Hotspot requires at
> least two reviewers for every patch (and one of the reviewers has to have
> the Reviewer role).

Hey, it's a first step ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From dalibor.topic at oracle.com  Wed Jun 14 13:08:57 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 14 Jun 2017 15:08:57 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170614120408.GB16230@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
Message-ID: <fd75b77f-b29d-b4f6-76df-102059584a90@oracle.com>

On 14.06.2017 14:04, John Paul Adrian Glaubitz wrote:
> Can't wait for my first patches getting merged into OpenJDK ;-).

Hi Adrian,

thanks, congrats & welcome!

Since your OCA submission has not been processed yet, you are not listed 
on http://www.oracle.com/technetwork/community/oca-486395.html . Patches 
can be merged once your OCA submission had been processed and your name 
appears on that list.

I'll take a look at the queue today and get back to you and Erik once 
it's processed or if there is a need for further information.

Once you have two or more sponsored changes in a Project's repository, 
you can become an Author, and can start using the OpenJDK code review, 
bug tracking and other infrastructure directly. Please see
http://openjdk.java.net/projects/#project-author for details.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From glaubitz at physik.fu-berlin.de  Wed Jun 14 13:12:48 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 14 Jun 2017 15:12:48 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <fd75b77f-b29d-b4f6-76df-102059584a90@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <fd75b77f-b29d-b4f6-76df-102059584a90@oracle.com>
Message-ID: <20170614131248.GF16230@physik.fu-berlin.de>

Hi Dalibor!

On Wed, Jun 14, 2017 at 03:08:57PM +0200, dalibor topic wrote:
> thanks, congrats & welcome!

Thank you!

> Since your OCA submission has not been processed yet, you are not listed on
> http://www.oracle.com/technetwork/community/oca-486395.html . Patches can be
> merged once your OCA submission had been processed and your name appears on
> that list.

Yes, I have just checked that list today and noticed my name wasn't on
the list yet.

> I'll take a look at the queue today and get back to you and Erik once it's
> processed or if there is a need for further information.

Perfect. Thank you very much!

> Once you have two or more sponsored changes in a Project's repository, you
> can become an Author, and can start using the OpenJDK code review, bug
> tracking and other infrastructure directly. Please see
> http://openjdk.java.net/projects/#project-author for details.

Sounds very exciting ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.helin at oracle.com  Wed Jun 14 14:38:34 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 14 Jun 2017 16:38:34 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <1497442884.3741.1.camel@redhat.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <1497442884.3741.1.camel@redhat.com>
Message-ID: <70fb60d3-7d19-ed9b-840e-bbb7315ae864@oracle.com>

On 06/14/2017 02:21 PM, Severin Gehwolf wrote:
> Hi Eric,
> 
> On Wed, 2017-06-14 at 13:50 +0200, Erik Helin wrote:
>> For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For 
>> example, the following is a bit surprising to me (mostly because I'm not 
>> familiar with zero):
>>
>> --- a/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
>> +++ b/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
>> @@ -37,7 +37,7 @@
>>   // understanding that there may be concurrent readers of that memory.
>>   void memset_with_concurrent_readers(void* to, int value, size_t size);
>>
>> -#ifdef SPARC
>> +#if defined(SPARC) && !defined(ZERO)
>>
>> When this code was written, the intent was clearly to have a specialized 
>> version of this function for SPARC. When writing such code, do we always 
>> have to take into account the zero case with !defined(ZERO)?
> 
> As of now, yes I think so. The thing is that Zero is supposed to be
> architecture agnostic for the most part. That is, you can build Zero on
> x86_64, SPARC, aarch64, etc.

Ok. But if Zero is architecture agnostic, why do we have the directory
hotspot/src/cpu/zero? Sorry, I don't know much about Zero...

>> That 
>> doesn't seem like the right (or a scalable) approach to me.
> 
> Agreed. That's how it is at the moment, though.
> 
>> Severin and/or Roman, do you guys know more about Zero and how this 
>> should work? If I want to write a function that I want to specialize for 
>> e.g. x86-64 or arm, do I always have to take Zero into account? Or 
>> should some other define be used, like #ifdef TARGET_ARCH_sparc?
> 
> So the ZERO define can happen regardless of arch. I don't really know
> any define which does what you want except #if defined(<ARCH>) &&
> !defined(ZERO) perhaps.

Hmm, ok, but for the above code snippet, if we are running with Zero on
Sparc, can't we use the Sparc optimized version of
memset_with_concurrent_readers? Or can't we use Sparc assembly in the
runtime when running with Zero?

Thanks,
Erik

> Thanks,
> Severin
> 
>> Thanks,
>> Erik
>>
>> On 06/09/2017 12:20 PM, John Paul Adrian Glaubitz wrote:
>>> Hi!
>>>
>>> I am currently working on fixing OpenJDK-9 on all non-mainstream
>>> targets available in Debian. For Debian/sparc64, the attached four
>>> patches were necessary to make the build succeed [1].
>>>
>>> I know the patches cannot be merged right now, but I'm posting them
>>> anyway in case someone else is interested in using them.
>>>
>>> All patches are:
>>>
>>>     Signed-off-by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
>>>
>>> I also signed the OCA.
>>>
>>> I'm now looking into fixing the builds on alpha (DEC Alpha), armel
>>> (ARMv4T), m68k (680x0), powerpc (PPC32) and sh4 (SuperH/J-Core).
>>>
>>> Cheers,
>>> Adrian
>>>
>>>> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1496931563&raw=0
> 


From sgehwolf at redhat.com  Wed Jun 14 16:05:42 2017
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 14 Jun 2017 18:05:42 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <70fb60d3-7d19-ed9b-840e-bbb7315ae864@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <1497442884.3741.1.camel@redhat.com>
 <70fb60d3-7d19-ed9b-840e-bbb7315ae864@oracle.com>
Message-ID: <1497456342.3741.15.camel@redhat.com>

Hi Eric,

On Wed, 2017-06-14 at 16:38 +0200, Erik Helin wrote:
> On 06/14/2017 02:21 PM, Severin Gehwolf wrote:
> > Hi Eric,
> > 
> > On Wed, 2017-06-14 at 13:50 +0200, Erik Helin wrote:
> > > For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For?
> > > example, the following is a bit surprising to me (mostly because I'm not?
> > > familiar with zero):
> > > 
> > > --- a/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
> > > +++ b/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
> > > @@ -37,7 +37,7 @@
> > > ? // understanding that there may be concurrent readers of that memory.
> > > ? void memset_with_concurrent_readers(void* to, int value, size_t size);
> > > 
> > > -#ifdef SPARC
> > > +#if defined(SPARC) && !defined(ZERO)
> > > 
> > > When this code was written, the intent was clearly to have a specialized?
> > > version of this function for SPARC. When writing such code, do we always?
> > > have to take into account the zero case with !defined(ZERO)?
> > 
> > As of now, yes I think so. The thing is that Zero is supposed to be
> > architecture agnostic for the most part. That is, you can build Zero on
> > x86_64, SPARC, aarch64, etc.
> 
> Ok. But if Zero is architecture agnostic, why do we have the directory
> hotspot/src/cpu/zero? Sorry, I don't know much about Zero...

I don't know a lot about Zero either ;-)

Zero uses the C++ interpreter and is supposed to be a "Zero assembler
port". In contrast to the old C++ interpreter, Zero uses no platform
specific code to set up frames. It's glue code specific to Zero. Zero
isn't a cpu arch, though. It predates me as to why the code ended up in
src/cpu/zero.

> > > That?
> > > doesn't seem like the right (or a scalable) approach to me.
> > 
> > Agreed. That's how it is at the moment, though.
> > 
> > > Severin and/or Roman, do you guys know more about Zero and how this?
> > > should work? If I want to write a function that I want to specialize for?
> > > e.g. x86-64 or arm, do I always have to take Zero into account? Or?
> > > should some other define be used, like #ifdef TARGET_ARCH_sparc?
> > 
> > So the ZERO define can happen regardless of arch. I don't really know
> > any define which does what you want except #if defined(<ARCH>) &&
> > !defined(ZERO) perhaps.
> 
> Hmm, ok, but for the above code snippet, if we are running with Zero on
> Sparc, can't we use the Sparc optimized version of
> memset_with_concurrent_readers? Or can't we use Sparc assembly in the
> runtime when running with Zero?

Zero == Zero assembler. So the latter. Yet, I'm unsure as to what that
assembler is doing exactly. What's more, I've never built Zero on
SPARC, so I don't know whether or not the patch in question fixes a
compile or runtime issue. It might be technically possible to use
assembler, but it hinders it's goal of Zero being a porters tool[1].

HTH,
Severin

[1] http://icedtea.classpath.org/wiki/ZeroSharkFaq#Why_was_Zero_written.3F

> Thanks,
> Erik
> 
> > Thanks,
> > Severin
> > 
> > > Thanks,
> > > Erik
> > > 
> > > On 06/09/2017 12:20 PM, John Paul Adrian Glaubitz wrote:
> > > > Hi!
> > > > 
> > > > I am currently working on fixing OpenJDK-9 on all non-mainstream
> > > > targets available in Debian. For Debian/sparc64, the attached four
> > > > patches were necessary to make the build succeed [1].
> > > > 
> > > > I know the patches cannot be merged right now, but I'm posting them
> > > > anyway in case someone else is interested in using them.
> > > > 
> > > > All patches are:
> > > > 
> > > > ????Signed-off-by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
> > > > 
> > > > I also signed the OCA.
> > > > 
> > > > I'm now looking into fixing the builds on alpha (DEC Alpha), armel
> > > > (ARMv4T), m68k (680x0), powerpc (PPC32) and sh4 (SuperH/J-Core).
> > > > 
> > > > Cheers,
> > > > Adrian
> > > > 
> > > > > [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1496931563&raw=0



From roger.riggs at oracle.com  Thu Jun 15 01:37:21 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 14 Jun 2017 21:37:21 -0400
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <EEE3A6C6-B10D-413B-8E2D-B2F8FAD0DD97@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
 <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
 <EEE3A6C6-B10D-413B-8E2D-B2F8FAD0DD97@oracle.com>
Message-ID: <1aca2541-93d4-2279-4937-174033804db0@oracle.com>

Hi,

This change looks ok,  I have some other links to the copyright.html to 
fix in serialization
and can fix the tools/docs/docs-bundle-page at the same time.

Roger


On 6/12/17 12:19 PM, Mandy Chung wrote:
> jdk/make/src/classes/build/tools/docs/docs-bundle-page.html has a reference to cpyr.html that needs to be fixed.
>
> It?d be good to wrap the long lines in copyright.html.
>
> Mandy
>
>> On Jun 12, 2017, at 12:28 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> Hi,
>>
>> This patch, while approved by reviewers, was put on hold due to legal reasons.
>>
>> Here's a new patch, with updated legalese.
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.02
>>
>> /Magnus
>>
>>
>> On 2017-05-03 16:02, Magnus Ihse Bursie wrote:
>>> The new $module/specs specifications needs to point to a proper copyright file.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>>>
>>> /Magnus
>>>



From xueming.shen at oracle.com  Thu Jun 15 03:27:34 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 14 Jun 2017 20:27:34 -0700
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
Message-ID: <5941FEA6.3010507@oracle.com>

Hi Claes,

The change looks fine. Yes, encoding the 2-byete latin1 at native looks 
reasonable.

One nick picking is that it might be better to initialize the constant 
"LATIN1" from the String class
when intializing String_coder_ID? recently I got a "naked constants" 
complain #JDK-8156530, so
I guess it might be better to do so at you change, though I don't expect 
it's going to change in the
foreseeable future, even we finally add a "utf8" variants there.

478 static const jbyte LATIN1 = 0;
479 static const jbyte UTF16  = 1;

thanks,
Sherman

On 6/13/17, 1:27 PM, Claes Redestad wrote:
>
>
> On 2017-06-13 21:09, Martin Buchholz wrote:
>> Looks good to me, although still hoping for more review from others.
>
> I expect Sherman to weigh in. :-)
>
>>
>> +    if (bytes != 0) {
>> Style: use NULL.
>
> Done.
>
>>
>> +static jstring newStringJava(JNIEnv *env, const char *str) {
>>
>> I expected two versions, one that took a length and one that did not, 
>> as you did with newString8859_1.
>
> Ah, yes. Refactored and updated in-place.
>
>> ---
>> TIL that jbyte is signed char, not plain char, and so is more 
>> consistent with java "byte", hence less error prone, at least in theory.
>>
>> ---
>> Can we test different native environments by using 
>> -Dsun.jnu.encoding=... ?
>
> I did try, but jtreg currently doesn't appear to support specifying 
> flags for main/native @run:s (and helpfully suggests using 
> main/othervm instead...) - maybe someone knows a way around this?
>
> /Claes
>
>>
>>
>>
>> On Tue, Jun 13, 2017 at 7:03 AM, Claes Redestad 
>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>
>> <adding build-dev; see
>>     
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html>
>>     for missing context>
>>
>>     Updated webrevs:
>>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>>     http://cr.openjdk.java.net/~redestad/8181147/top.04/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/top.04/>
>>
>>     In this version there are various cleanups based on Martin's
>>     comments, improved test coverage and some small changes to
>>     ensure the updated test builds and runs on all our supported
>>     platforms.
>>
>>     If someone with access to any of the platforms not supported
>>     by Oracle could take this for a spin and ensure linking the newly
>>     added test against libjava works as expected (or suggest how
>>     to make it work if it doesn't) then that'd be much appreciated.
>>
>>     Thanks!
>>
>>     /Claes
>>
>>     On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>>
>>         I'm hoping Xueming will review as well.
>>         +    char asciiCheck;
>>         +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>         +        asciiCheck |= *p;
>>         +    }
>>         +    len = (p - str);
>>         Probably conversion from ptrdiff_t to int needs a cast.
>>
>>         Someday we might need to worry about input string longer than
>>         2^31, but that's a pre-existing problem.
>>
>>         The signed-ness of char being implementation-defined makes me
>>         nervous.
>>         Maybe do all the bit operations using explicit unsigned char,
>>         then the final test becomes simply
>>
>>         asciiCheck <= 0x80
>>
>>
>>         On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad
>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>
>> <mailto:claes.redestad at oracle.com
>> <mailto:claes.redestad at oracle.com>>> wrote:
>>
>>             Hi Martin,
>>
>>             thanks for reviewing!
>>
>>             On 2017-06-12 22:14, Martin Buchholz wrote:
>>
>>                 +/* Optimized for char set UTF-8 */
>>
>>                 "charset" is a (poor misnomer!) jargon term, not two
>>         words.
>>
>>
>>             I got that from the existing use of "char set" in this
>>         file, but
>>             will fix it in all places.
>>
>>
>>                 ---
>>
>>                 +    for (b = str[len]; b != '\0'; len++, b = 
>> str[len]) {
>>                 +        if (isAscii && b & 0x80) {
>>                 +            isAscii = JNI_FALSE;
>>                 +        }
>>                 +    }
>>
>>                 I would write this more like
>>
>>                 const signed char *p;
>>                 int isAscii;
>>
>>                 for (isAscii = 0, p = (const signed char *) str; *p !=
>>         '\0';
>>                 p++) isAscii &= (*p >= 0);
>>
>>
>>             Did you mean for isAscii to be initialized to 1 (true) and
>>         then be
>>             cleared to 0 (false) when *p >= 0 is false?
>>
>>
>>                 Then length is (p - str)
>>
>>
>>             How about something like this to hoist the second
>>         comparison from
>>             the loop:
>>
>>                 int len;
>>                 char asciiCheck;
>>                 for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>                     asciiCheck |= *p;
>>                 }
>>                 len = (p - str);
>>
>>                 if (asciiCheck & 0x80) {
>>                     // ascii fast-path
>>                     return newSizedString8859_1(env, str, len);
>>                 }
>>
>>                 ...
>>
>>                 ---
>>
>>                 +    jbyteArray hab = NULL;
>>
>>                 I'm having a hard time decoding the name "hab"
>>
>>
>>             Not sure, but my guess is "heap allocated byteArray".
>>
>>
>>                 ---
>>
>>                 The code below is not UTF-8 specific. Can it be
>>         refactored?
>>
>>                 +    hab = (*env)->NewByteArray(env, len);
>>                 +    if (hab != 0) {
>>                 +        jclass strClazz = JNU_ClassString(env);
>>                 +        CHECK_NULL_RETURN(strClazz, 0);
>>                 +        (*env)->SetByteArrayRegion(env, hab, 0, len,
>>         (jbyte
>>                 *)str);
>>                 +        result = (*env)->NewObject(env, strClazz,
>>                 +  String_init_ID, hab,
>>                 jnuEncoding);
>>                 +        (*env)->DeleteLocalRef(env, hab);
>>                 +        return result;
>>                 +    }
>>
>>
>>             Yes, probably. The excessive copy-paste here is due to a 
>> crash
>>             issue I ran into when
>>             Charset.isSupported was called without proper
>>         initialization. It
>>             has since been
>>             resolved, but seems I forgot to revisit this part.
>>
>>             I also realized I haven't added a test for this method.
>>         I'll look
>>             into doing the
>>             refactoring and adding some sanity testing tomorrow.
>>
>>
>>                 ---
>>
>>                 We probably want to use unicode escapes in out java
>>         sources to
>>                 keep all source files strictly ASCII.
>>
>>
>>             You mean in the test? Sure.
>>
>>             Refreshed the jdk webrev:
>>         http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/
>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>> -
>>         more to
>>             come.
>>
>>             Thanks!
>>
>>             /Claes
>>
>>
>>
>>
>



From claes.redestad at oracle.com  Thu Jun 15 13:29:42 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 15 Jun 2017 15:29:42 +0200
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <5941FEA6.3010507@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
 <5941FEA6.3010507@oracle.com>
Message-ID: <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>

Hi Sherman,

On 06/15/2017 05:27 AM, Xueming Shen wrote:
> Hi Claes,
>
> The change looks fine. Yes, encoding the 2-byete latin1 at native 
> looks reasonable.

Thanks for reviewing!

>
> One nick picking is that it might be better to initialize the constant 
> "LATIN1" from the String class
> when intializing String_coder_ID? recently I got a "naked constants" 
> complain #JDK-8156530, so
> I guess it might be better to do so at you change, though I don't 
> expect it's going to change in the
> foreseeable future, even we finally add a "utf8" variants there.
>
> 478 static const jbyte LATIN1 = 0;
> 479 static const jbyte UTF16  = 1;

Not sure how the "naked constants" issue applies, but maybe we can save 
us some
future surprises by adding a precondition check in the new test to 
ensure the
constants defined in jni_util matches the constants defined in 
java.lang.String:

http://cr.openjdk.java.net/~redestad/8181147/jdk.06/

Does this suffice?

Thanks!

/Claes

>
> thanks,
> Sherman
>
> On 6/13/17, 1:27 PM, Claes Redestad wrote:
>>
>>
>> On 2017-06-13 21:09, Martin Buchholz wrote:
>>> Looks good to me, although still hoping for more review from others.
>>
>> I expect Sherman to weigh in. :-)
>>
>>>
>>> +    if (bytes != 0) {
>>> Style: use NULL.
>>
>> Done.
>>
>>>
>>> +static jstring newStringJava(JNIEnv *env, const char *str) {
>>>
>>> I expected two versions, one that took a length and one that did 
>>> not, as you did with newString8859_1.
>>
>> Ah, yes. Refactored and updated in-place.
>>
>>> ---
>>> TIL that jbyte is signed char, not plain char, and so is more 
>>> consistent with java "byte", hence less error prone, at least in 
>>> theory.
>>>
>>> ---
>>> Can we test different native environments by using 
>>> -Dsun.jnu.encoding=... ?
>>
>> I did try, but jtreg currently doesn't appear to support specifying 
>> flags for main/native @run:s (and helpfully suggests using 
>> main/othervm instead...) - maybe someone knows a way around this?
>>
>> /Claes
>>
>>>
>>>
>>>
>>> On Tue, Jun 13, 2017 at 7:03 AM, Claes Redestad 
>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>>
>>> <adding build-dev; see
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html
>>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html> 
>>>
>>>     for missing context>
>>>
>>>     Updated webrevs:
>>>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>>>     http://cr.openjdk.java.net/~redestad/8181147/top.04/
>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/top.04/>
>>>
>>>     In this version there are various cleanups based on Martin's
>>>     comments, improved test coverage and some small changes to
>>>     ensure the updated test builds and runs on all our supported
>>>     platforms.
>>>
>>>     If someone with access to any of the platforms not supported
>>>     by Oracle could take this for a spin and ensure linking the newly
>>>     added test against libjava works as expected (or suggest how
>>>     to make it work if it doesn't) then that'd be much appreciated.
>>>
>>>     Thanks!
>>>
>>>     /Claes
>>>
>>>     On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>>>
>>>         I'm hoping Xueming will review as well.
>>>         +    char asciiCheck;
>>>         +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>>         +        asciiCheck |= *p;
>>>         +    }
>>>         +    len = (p - str);
>>>         Probably conversion from ptrdiff_t to int needs a cast.
>>>
>>>         Someday we might need to worry about input string longer than
>>>         2^31, but that's a pre-existing problem.
>>>
>>>         The signed-ness of char being implementation-defined makes me
>>>         nervous.
>>>         Maybe do all the bit operations using explicit unsigned char,
>>>         then the final test becomes simply
>>>
>>>         asciiCheck <= 0x80
>>>
>>>
>>>         On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad
>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>
>>> <mailto:claes.redestad at oracle.com
>>> <mailto:claes.redestad at oracle.com>>> wrote:
>>>
>>>             Hi Martin,
>>>
>>>             thanks for reviewing!
>>>
>>>             On 2017-06-12 22:14, Martin Buchholz wrote:
>>>
>>>                 +/* Optimized for char set UTF-8 */
>>>
>>>                 "charset" is a (poor misnomer!) jargon term, not two
>>>         words.
>>>
>>>
>>>             I got that from the existing use of "char set" in this
>>>         file, but
>>>             will fix it in all places.
>>>
>>>
>>>                 ---
>>>
>>>                 +    for (b = str[len]; b != '\0'; len++, b = 
>>> str[len]) {
>>>                 +        if (isAscii && b & 0x80) {
>>>                 +            isAscii = JNI_FALSE;
>>>                 +        }
>>>                 +    }
>>>
>>>                 I would write this more like
>>>
>>>                 const signed char *p;
>>>                 int isAscii;
>>>
>>>                 for (isAscii = 0, p = (const signed char *) str; *p !=
>>>         '\0';
>>>                 p++) isAscii &= (*p >= 0);
>>>
>>>
>>>             Did you mean for isAscii to be initialized to 1 (true) and
>>>         then be
>>>             cleared to 0 (false) when *p >= 0 is false?
>>>
>>>
>>>                 Then length is (p - str)
>>>
>>>
>>>             How about something like this to hoist the second
>>>         comparison from
>>>             the loop:
>>>
>>>                 int len;
>>>                 char asciiCheck;
>>>                 for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>>                     asciiCheck |= *p;
>>>                 }
>>>                 len = (p - str);
>>>
>>>                 if (asciiCheck & 0x80) {
>>>                     // ascii fast-path
>>>                     return newSizedString8859_1(env, str, len);
>>>                 }
>>>
>>>                 ...
>>>
>>>                 ---
>>>
>>>                 +    jbyteArray hab = NULL;
>>>
>>>                 I'm having a hard time decoding the name "hab"
>>>
>>>
>>>             Not sure, but my guess is "heap allocated byteArray".
>>>
>>>
>>>                 ---
>>>
>>>                 The code below is not UTF-8 specific. Can it be
>>>         refactored?
>>>
>>>                 +    hab = (*env)->NewByteArray(env, len);
>>>                 +    if (hab != 0) {
>>>                 +        jclass strClazz = JNU_ClassString(env);
>>>                 +        CHECK_NULL_RETURN(strClazz, 0);
>>>                 +        (*env)->SetByteArrayRegion(env, hab, 0, len,
>>>         (jbyte
>>>                 *)str);
>>>                 +        result = (*env)->NewObject(env, strClazz,
>>>                 +  String_init_ID, hab,
>>>                 jnuEncoding);
>>>                 +        (*env)->DeleteLocalRef(env, hab);
>>>                 +        return result;
>>>                 +    }
>>>
>>>
>>>             Yes, probably. The excessive copy-paste here is due to a 
>>> crash
>>>             issue I ran into when
>>>             Charset.isSupported was called without proper
>>>         initialization. It
>>>             has since been
>>>             resolved, but seems I forgot to revisit this part.
>>>
>>>             I also realized I haven't added a test for this method.
>>>         I'll look
>>>             into doing the
>>>             refactoring and adding some sanity testing tomorrow.
>>>
>>>
>>>                 ---
>>>
>>>                 We probably want to use unicode escapes in out java
>>>         sources to
>>>                 keep all source files strictly ASCII.
>>>
>>>
>>>             You mean in the test? Sure.
>>>
>>>             Refreshed the jdk webrev:
>>>         http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/
>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>> -
>>>         more to
>>>             come.
>>>
>>>             Thanks!
>>>
>>>             /Claes
>>>
>>>
>>>
>>>
>>
>



From xueming.shen at oracle.com  Thu Jun 15 15:09:29 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 15 Jun 2017 08:09:29 -0700
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
 <5941FEA6.3010507@oracle.com>
 <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
Message-ID: <5942A329.7000107@oracle.com>

On 6/15/17, 6:29 AM, Claes Redestad wrote:
> Hi Sherman,
>
>>
>> One nick picking is that it might be better to initialize the 
>> constant "LATIN1" from the String class
>> when intializing String_coder_ID? recently I got a "naked constants" 
>> complain #JDK-8156530, so
>> I guess it might be better to do so at you change, though I don't 
>> expect it's going to change in the
>> foreseeable future, even we finally add a "utf8" variants there.
>>
>> 478 static const jbyte LATIN1 = 0;
>> 479 static const jbyte UTF16  = 1;
>
> Not sure how the "naked constants" issue applies, but maybe we can 
> save us some
> future surprises by adding a precondition check in the new test to 
> ensure the
> constants defined in jni_util matches the constants defined in 
> java.lang.String:
+1

I was thinking of initializing the LATIN1 with the value vai 
GetStaticByteField as you are
doing now in the test.

But the new test is good enough for me, a warning/reminder in the future 
in case we have to
change the constant values in String class.

-Sherman

>
> http://cr.openjdk.java.net/~redestad/8181147/jdk.06/
>
> Does this suffice?
>
> Thanks!
>
> /Claes
>
>>
>> thanks,
>> Sherman
>>
>> On 6/13/17, 1:27 PM, Claes Redestad wrote:
>>>
>>>
>>> On 2017-06-13 21:09, Martin Buchholz wrote:
>>>> Looks good to me, although still hoping for more review from others.
>>>
>>> I expect Sherman to weigh in. :-)
>>>
>>>>
>>>> +    if (bytes != 0) {
>>>> Style: use NULL.
>>>
>>> Done.
>>>
>>>>
>>>> +static jstring newStringJava(JNIEnv *env, const char *str) {
>>>>
>>>> I expected two versions, one that took a length and one that did 
>>>> not, as you did with newString8859_1.
>>>
>>> Ah, yes. Refactored and updated in-place.
>>>
>>>> ---
>>>> TIL that jbyte is signed char, not plain char, and so is more 
>>>> consistent with java "byte", hence less error prone, at least in 
>>>> theory.
>>>>
>>>> ---
>>>> Can we test different native environments by using 
>>>> -Dsun.jnu.encoding=... ?
>>>
>>> I did try, but jtreg currently doesn't appear to support specifying 
>>> flags for main/native @run:s (and helpfully suggests using 
>>> main/othervm instead...) - maybe someone knows a way around this?
>>>
>>> /Claes
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jun 13, 2017 at 7:03 AM, Claes Redestad 
>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>>>>
>>>> <adding build-dev; see
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html 
>>>>
>>>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048233.html> 
>>>>
>>>>     for missing context>
>>>>
>>>>     Updated webrevs:
>>>>     http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>>>>     http://cr.openjdk.java.net/~redestad/8181147/top.04/
>>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/top.04/>
>>>>
>>>>     In this version there are various cleanups based on Martin's
>>>>     comments, improved test coverage and some small changes to
>>>>     ensure the updated test builds and runs on all our supported
>>>>     platforms.
>>>>
>>>>     If someone with access to any of the platforms not supported
>>>>     by Oracle could take this for a spin and ensure linking the newly
>>>>     added test against libjava works as expected (or suggest how
>>>>     to make it work if it doesn't) then that'd be much appreciated.
>>>>
>>>>     Thanks!
>>>>
>>>>     /Claes
>>>>
>>>>     On 06/13/2017 02:01 AM, Martin Buchholz wrote:
>>>>
>>>>         I'm hoping Xueming will review as well.
>>>>         +    char asciiCheck;
>>>>         +    for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>>>         +        asciiCheck |= *p;
>>>>         +    }
>>>>         +    len = (p - str);
>>>>         Probably conversion from ptrdiff_t to int needs a cast.
>>>>
>>>>         Someday we might need to worry about input string longer than
>>>>         2^31, but that's a pre-existing problem.
>>>>
>>>>         The signed-ness of char being implementation-defined makes me
>>>>         nervous.
>>>>         Maybe do all the bit operations using explicit unsigned char,
>>>>         then the final test becomes simply
>>>>
>>>>         asciiCheck <= 0x80
>>>>
>>>>
>>>>         On Mon, Jun 12, 2017 at 4:36 PM, Claes Redestad
>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>
>>>> <mailto:claes.redestad at oracle.com
>>>> <mailto:claes.redestad at oracle.com>>> wrote:
>>>>
>>>>             Hi Martin,
>>>>
>>>>             thanks for reviewing!
>>>>
>>>>             On 2017-06-12 22:14, Martin Buchholz wrote:
>>>>
>>>>                 +/* Optimized for char set UTF-8 */
>>>>
>>>>                 "charset" is a (poor misnomer!) jargon term, not two
>>>>         words.
>>>>
>>>>
>>>>             I got that from the existing use of "char set" in this
>>>>         file, but
>>>>             will fix it in all places.
>>>>
>>>>
>>>>                 ---
>>>>
>>>>                 +    for (b = str[len]; b != '\0'; len++, b = 
>>>> str[len]) {
>>>>                 +        if (isAscii && b & 0x80) {
>>>>                 +            isAscii = JNI_FALSE;
>>>>                 +        }
>>>>                 +    }
>>>>
>>>>                 I would write this more like
>>>>
>>>>                 const signed char *p;
>>>>                 int isAscii;
>>>>
>>>>                 for (isAscii = 0, p = (const signed char *) str; *p !=
>>>>         '\0';
>>>>                 p++) isAscii &= (*p >= 0);
>>>>
>>>>
>>>>             Did you mean for isAscii to be initialized to 1 (true) and
>>>>         then be
>>>>             cleared to 0 (false) when *p >= 0 is false?
>>>>
>>>>
>>>>                 Then length is (p - str)
>>>>
>>>>
>>>>             How about something like this to hoist the second
>>>>         comparison from
>>>>             the loop:
>>>>
>>>>                 int len;
>>>>                 char asciiCheck;
>>>>                 for (asciiCheck = 0, p = str; *p != '\0'; p++) {
>>>>                     asciiCheck |= *p;
>>>>                 }
>>>>                 len = (p - str);
>>>>
>>>>                 if (asciiCheck & 0x80) {
>>>>                     // ascii fast-path
>>>>                     return newSizedString8859_1(env, str, len);
>>>>                 }
>>>>
>>>>                 ...
>>>>
>>>>                 ---
>>>>
>>>>                 +    jbyteArray hab = NULL;
>>>>
>>>>                 I'm having a hard time decoding the name "hab"
>>>>
>>>>
>>>>             Not sure, but my guess is "heap allocated byteArray".
>>>>
>>>>
>>>>                 ---
>>>>
>>>>                 The code below is not UTF-8 specific. Can it be
>>>>         refactored?
>>>>
>>>>                 +    hab = (*env)->NewByteArray(env, len);
>>>>                 +    if (hab != 0) {
>>>>                 +        jclass strClazz = JNU_ClassString(env);
>>>>                 +        CHECK_NULL_RETURN(strClazz, 0);
>>>>                 +        (*env)->SetByteArrayRegion(env, hab, 0, len,
>>>>         (jbyte
>>>>                 *)str);
>>>>                 +        result = (*env)->NewObject(env, strClazz,
>>>>                 +  String_init_ID, hab,
>>>>                 jnuEncoding);
>>>>                 +        (*env)->DeleteLocalRef(env, hab);
>>>>                 +        return result;
>>>>                 +    }
>>>>
>>>>
>>>>             Yes, probably. The excessive copy-paste here is due to 
>>>> a crash
>>>>             issue I ran into when
>>>>             Charset.isSupported was called without proper
>>>>         initialization. It
>>>>             has since been
>>>>             resolved, but seems I forgot to revisit this part.
>>>>
>>>>             I also realized I haven't added a test for this method.
>>>>         I'll look
>>>>             into doing the
>>>>             refactoring and adding some sanity testing tomorrow.
>>>>
>>>>
>>>>                 ---
>>>>
>>>>                 We probably want to use unicode escapes in out java
>>>>         sources to
>>>>                 keep all source files strictly ASCII.
>>>>
>>>>
>>>>             You mean in the test? Sure.
>>>>
>>>>             Refreshed the jdk webrev:
>>>>         http://cr.openjdk.java.net/~redestad/8181147/jdk.05/
>>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>
>>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/
>>>> <http://cr.openjdk.java.net/%7Eredestad/8181147/jdk.05/>> -
>>>>         more to
>>>>             come.
>>>>
>>>>             Thanks!
>>>>
>>>>             /Claes
>>>>
>>>>
>>>>
>>>>
>>>
>>
>



From chris.hegarty at oracle.com  Thu Jun 15 16:26:12 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Jun 2017 17:26:12 +0100
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
 <5941FEA6.3010507@oracle.com>
 <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
Message-ID: <3C2A2F2C-3BF6-4EB8-8A55-62C5C892F2FB@oracle.com>


> On 15 Jun 2017, at 14:29, Claes Redestad <claes.redestad at oracle.com> wrote:
> ...
> http://cr.openjdk.java.net/~redestad/8181147/jdk.06/

Claes,

This is the first test in the core area that will now use a test
specific native library, which will need to be built ( by the build
system, which it does ), and pointed to when executing jtreg
from the command line, e.g.

jtreg ... -nativepath:build/macosx-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib

I think this may be ok, but some folk will need to get used to
adding this option to their jtreg runs. Either that, or move the 
test to a separate group / target.

-Chris.



From Alan.Bateman at oracle.com  Thu Jun 15 16:50:07 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 15 Jun 2017 17:50:07 +0100
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <3C2A2F2C-3BF6-4EB8-8A55-62C5C892F2FB@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
 <5941FEA6.3010507@oracle.com>
 <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
 <3C2A2F2C-3BF6-4EB8-8A55-62C5C892F2FB@oracle.com>
Message-ID: <6f3f2a23-9e7a-06d4-21d6-c8afe985bf8b@oracle.com>



On 15/06/2017 17:26, Chris Hegarty wrote:
> :
> Claes,
>
> This is the first test in the core area that will now use a test
> specific native library, which will need to be built ( by the build
> system, which it does ), and pointed to when executing jtreg
> from the command line, e.g.
>
> jtreg ... -nativepath:build/macosx-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib
>
> I think this may be ok, but some folk will need to get used to
> adding this option to their jtreg runs. Either that, or move the
> test to a separate group / target.
>
One thing to mention is `jtreg -k:!native ..` if you need to skip the 
native tests.

-Alan


From claes.redestad at oracle.com  Thu Jun 15 22:35:54 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 16 Jun 2017 00:35:54 +0200
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <6f3f2a23-9e7a-06d4-21d6-c8afe985bf8b@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
 <5941FEA6.3010507@oracle.com>
 <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
 <3C2A2F2C-3BF6-4EB8-8A55-62C5C892F2FB@oracle.com>
 <6f3f2a23-9e7a-06d4-21d6-c8afe985bf8b@oracle.com>
Message-ID: <7ab7e31a-95c0-f47d-88e0-ae671b5b43af@oracle.com>



On 2017-06-15 18:50, Alan Bateman wrote:
>
>
> On 15/06/2017 17:26, Chris Hegarty wrote:
>> :
>> Claes,
>>
>> This is the first test in the core area that will now use a test
>> specific native library, which will need to be built ( by the build
>> system, which it does ), and pointed to when executing jtreg
>> from the command line, e.g.
>>
>> jtreg ... 
>> -nativepath:build/macosx-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib
>>
>> I think this may be ok, but some folk will need to get used to
>> adding this option to their jtreg runs. Either that, or move the
>> test to a separate group / target.
>>
> One thing to mention is `jtreg -k:!native ..` if you need to skip the 
> native tests.

Neat!

If you don't mind I'd like to move ahead with the test
configuration as-is, and then if there's a pressing need
to split the jdk_lang test group into a native and non-native
part that can be done as a follow-up. As there seems
there's a simple workaround in case a test system needs
time to adapt this doesn't seem too unreasonable, no?

I've been using the new run-test target to test this locally:

make run-test TEST=jdk/test/java/lang/String/nativeEncoding

Very convenient, and it of course emits the full command
line for reruns if something goes wrong.

---

On a different note I finally found out how to allow specifying
different runs with native tests:

@run main/othervm/native ...

By running this with -Xcheck:jni I found a couple of benign
issues (passed wrong arguments to
ReleasePrimitiveArrayCritical in both jni_util.c and the test,
and triggered a capacity warning at one place in pre-existing
code).  I fixed these and added -Xcheck:jni to the default
test configuration.

Now it turns out setting -Dsun.jnu.encoding actually breaks
things in subtle ways (seems the native code reads the implicit
property, which is determined by LANG/LC_ALL before it gets
set by the provided flag). I've verified the test passes locally
for some different LANG+LC_ALL values, but can't figure out
how to express that in the test.  I think we can lean on having
test systems with different default locales set, and leave it to
the future to - if possible - improve coverage.

Finally, Chris Hegarty pointed out that we could use the
@Native annotation to expose constants to JNI code (as
generated #defines), which saves us the trouble of
maintaining this assumption as a test. Since there doesn't
seem to be any drawbacks to this then I went ahead with
this approach.

New webrev:
http://cr.openjdk.java.net/~redestad/8181147/jdk.07

Thanks!

/Claes


From magnus.ihse.bursie at oracle.com  Fri Jun 16 09:30:57 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jun 2017 11:30:57 +0200
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <45231318-fd98-1c98-a7d1-4205a1dbe185@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
 <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
 <45231318-fd98-1c98-a7d1-4205a1dbe185@oracle.com>
Message-ID: <183ae49b-8523-4d53-0f26-0ec0720a68b0@oracle.com>

Apparently these files should reside in the closed repo instead...

Now there's yet another version of this patch, this time with trivial 
changes to open only:

http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.04

Let's hope third time's a charm.

/Magnus


On 2017-06-12 09:42, Erik Joelsson wrote:
> Still looks good to me.
>
> /Erik
>
>
> On 2017-06-12 09:28, Magnus Ihse Bursie wrote:
>> Hi,
>>
>> This patch, while approved by reviewers, was put on hold due to legal 
>> reasons.
>>
>> Here's a new patch, with updated legalese.
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.02 
>>
>>
>> /Magnus
>>
>>
>> On 2017-05-03 16:02, Magnus Ihse Bursie wrote:
>>> The new $module/specs specifications needs to point to a proper 
>>> copyright file.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>>>
>>> /Magnus
>>>
>>
>



From erik.joelsson at oracle.com  Fri Jun 16 09:36:55 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 16 Jun 2017 11:36:55 +0200
Subject: RFR: JDK-8179556 Add specs copyright file
In-Reply-To: <183ae49b-8523-4d53-0f26-0ec0720a68b0@oracle.com>
References: <6bbc2b04-1d3b-59a3-dd48-073d5541c5cc@oracle.com>
 <21734d07-c1c8-7bb8-5bdc-b8070473144f@oracle.com>
 <45231318-fd98-1c98-a7d1-4205a1dbe185@oracle.com>
 <183ae49b-8523-4d53-0f26-0ec0720a68b0@oracle.com>
Message-ID: <01419e69-c0fc-1330-0701-10d836eae250@oracle.com>

Looks good to me.

/Erik


On 2017-06-16 11:30, Magnus Ihse Bursie wrote:
> Apparently these files should reside in the closed repo instead...
>
> Now there's yet another version of this patch, this time with trivial 
> changes to open only:
>
> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.04 
>
>
> Let's hope third time's a charm.
>
> /Magnus
>
>
> On 2017-06-12 09:42, Erik Joelsson wrote:
>> Still looks good to me.
>>
>> /Erik
>>
>>
>> On 2017-06-12 09:28, Magnus Ihse Bursie wrote:
>>> Hi,
>>>
>>> This patch, while approved by reviewers, was put on hold due to 
>>> legal reasons.
>>>
>>> Here's a new patch, with updated legalese.
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.02 
>>>
>>>
>>> /Magnus
>>>
>>>
>>> On 2017-05-03 16:02, Magnus Ihse Bursie wrote:
>>>> The new $module/specs specifications needs to point to a proper 
>>>> copyright file.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179556
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8179556-add-legal-copyright-html/webrev.01
>>>>
>>>> /Magnus
>>>>
>>>
>>
>



From xueming.shen at oracle.com  Fri Jun 16 13:42:32 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 16 Jun 2017 06:42:32 -0700
Subject: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast
 path for UTF-8
In-Reply-To: <7ab7e31a-95c0-f47d-88e0-ae671b5b43af@oracle.com>
References: <65fc7c2f-c2d7-2b01-8a06-846bb2712e36@oracle.com>
 <CA+kOe08kme+L3QvejVJtuiGWt+FoiKao8=B7L1O40PF20mPb=A@mail.gmail.com>
 <964f377a-e0e4-8d12-7895-15bd7e09cba3@oracle.com>
 <CA+kOe09X23FowT8iYxkFWboEb5H1qq4MaKgZE_4GCXA_GxGT_w@mail.gmail.com>
 <adf34b87-e3ab-6a56-d4b9-70b223aeadcf@oracle.com>
 <CA+kOe0_mGOUg-FhSShZ6+dG8WmWDeqg8GgKMvvP83Rd6WLbo_g@mail.gmail.com>
 <54d59fa0-d1b6-3845-35bb-577d765f8ce7@oracle.com>
 <5941FEA6.3010507@oracle.com>
 <90030a6b-1fb0-9d91-d80e-63688d92431e@oracle.com>
 <3C2A2F2C-3BF6-4EB8-8A55-62C5C892F2FB@oracle.com>
 <6f3f2a23-9e7a-06d4-21d6-c8afe985bf8b@oracle.com>
 <7ab7e31a-95c0-f47d-88e0-ae671b5b43af@oracle.com>
Message-ID: <6BAD79E4-EE2C-4E35-A71C-7CE70A670A97@oracle.com>

+1

On Jun 15, 2017, at 3:35 PM, Claes Redestad <claes.redestad at oracle.com> wrote:



> On 2017-06-15 18:50, Alan Bateman wrote:
> 
> 
>> On 15/06/2017 17:26, Chris Hegarty wrote:
>> :
>> Claes,
>> 
>> This is the first test in the core area that will now use a test
>> specific native library, which will need to be built ( by the build
>> system, which it does ), and pointed to when executing jtreg
>> from the command line, e.g.
>> 
>> jtreg ... -nativepath:build/macosx-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib
>> 
>> I think this may be ok, but some folk will need to get used to
>> adding this option to their jtreg runs. Either that, or move the
>> test to a separate group / target.
>> 
> One thing to mention is `jtreg -k:!native ..` if you need to skip the native tests.

Neat!

If you don't mind I'd like to move ahead with the test
configuration as-is, and then if there's a pressing need
to split the jdk_lang test group into a native and non-native
part that can be done as a follow-up. As there seems
there's a simple workaround in case a test system needs
time to adapt this doesn't seem too unreasonable, no?

I've been using the new run-test target to test this locally:

make run-test TEST=jdk/test/java/lang/String/nativeEncoding

Very convenient, and it of course emits the full command
line for reruns if something goes wrong.

---

On a different note I finally found out how to allow specifying
different runs with native tests:

@run main/othervm/native ...

By running this with -Xcheck:jni I found a couple of benign
issues (passed wrong arguments to
ReleasePrimitiveArrayCritical in both jni_util.c and the test,
and triggered a capacity warning at one place in pre-existing
code).  I fixed these and added -Xcheck:jni to the default
test configuration.

Now it turns out setting -Dsun.jnu.encoding actually breaks
things in subtle ways (seems the native code reads the implicit
property, which is determined by LANG/LC_ALL before it gets
set by the provided flag). I've verified the test passes locally
for some different LANG+LC_ALL values, but can't figure out
how to express that in the test.  I think we can lean on having
test systems with different default locales set, and leave it to
the future to - if possible - improve coverage.

Finally, Chris Hegarty pointed out that we could use the
@Native annotation to expose constants to JNI code (as
generated #defines), which saves us the trouble of
maintaining this assumption as a test. Since there doesn't
seem to be any drawbacks to this then I went ahead with
this approach.

New webrev:
http://cr.openjdk.java.net/~redestad/8181147/jdk.07

Thanks!

/Claes



From magnus.ihse.bursie at oracle.com  Fri Jun 16 16:03:56 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jun 2017 18:03:56 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <70fb60d3-7d19-ed9b-840e-bbb7315ae864@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <1497442884.3741.1.camel@redhat.com>
 <70fb60d3-7d19-ed9b-840e-bbb7315ae864@oracle.com>
Message-ID: <f6e0063e-04d6-c236-af0d-02dbbf2ecd72@oracle.com>


On 2017-06-14 16:38, Erik Helin wrote:
> On 06/14/2017 02:21 PM, Severin Gehwolf wrote:
>> Hi Eric,
>>
>> On Wed, 2017-06-14 at 13:50 +0200, Erik Helin wrote:
>>> For the fourth patch, fix-zero-build-on-sparc.diff, I'm not so sure. For
>>> example, the following is a bit surprising to me (mostly because I'm not
>>> familiar with zero):
>>>
>>> --- a/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
>>> +++ b/hotspot/src/share/vm/gc/shared/memset_with_concurrent_readers.hpp
>>> @@ -37,7 +37,7 @@
>>>    // understanding that there may be concurrent readers of that memory.
>>>    void memset_with_concurrent_readers(void* to, int value, size_t size);
>>>
>>> -#ifdef SPARC
>>> +#if defined(SPARC) && !defined(ZERO)
>>>
>>> When this code was written, the intent was clearly to have a specialized
>>> version of this function for SPARC. When writing such code, do we always
>>> have to take into account the zero case with !defined(ZERO)?
>> As of now, yes I think so. The thing is that Zero is supposed to be
>> architecture agnostic for the most part. That is, you can build Zero on
>> x86_64, SPARC, aarch64, etc.
> Ok. But if Zero is architecture agnostic, why do we have the directory
> hotspot/src/cpu/zero? Sorry, I don't know much about Zero...

Zero is a strange beast. :-&

It behaves partially as a separate architecture, and partially as a "jvm 
variant" (like server, client), and partially as a "turn this special 
flag on".

Long term, there's probably a bunch of clarity to gain from cleaning 
this up.

/Magnus

>
>>> That
>>> doesn't seem like the right (or a scalable) approach to me.
>> Agreed. That's how it is at the moment, though.
>>
>>> Severin and/or Roman, do you guys know more about Zero and how this
>>> should work? If I want to write a function that I want to specialize for
>>> e.g. x86-64 or arm, do I always have to take Zero into account? Or
>>> should some other define be used, like #ifdef TARGET_ARCH_sparc?
>> So the ZERO define can happen regardless of arch. I don't really know
>> any define which does what you want except #if defined(<ARCH>) &&
>> !defined(ZERO) perhaps.
> Hmm, ok, but for the above code snippet, if we are running with Zero on
> Sparc, can't we use the Sparc optimized version of
> memset_with_concurrent_readers? Or can't we use Sparc assembly in the
> runtime when running with Zero?
>
> Thanks,
> Erik
>
>> Thanks,
>> Severin
>>
>>> Thanks,
>>> Erik
>>>
>>> On 06/09/2017 12:20 PM, John Paul Adrian Glaubitz wrote:
>>>> Hi!
>>>>
>>>> I am currently working on fixing OpenJDK-9 on all non-mainstream
>>>> targets available in Debian. For Debian/sparc64, the attached four
>>>> patches were necessary to make the build succeed [1].
>>>>
>>>> I know the patches cannot be merged right now, but I'm posting them
>>>> anyway in case someone else is interested in using them.
>>>>
>>>> All patches are:
>>>>
>>>>      Signed-off-by: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
>>>>
>>>> I also signed the OCA.
>>>>
>>>> I'm now looking into fixing the builds on alpha (DEC Alpha), armel
>>>> (ARMv4T), m68k (680x0), powerpc (PPC32) and sh4 (SuperH/J-Core).
>>>>
>>>> Cheers,
>>>> Adrian
>>>>
>>>>> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=sparc64&ver=9%7Eb170-2&stamp=1496931563&raw=0



From magnus.ihse.bursie at oracle.com  Fri Jun 16 20:05:51 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jun 2017 22:05:51 +0200
Subject: RFR: JDK-8179537 Update testing.md for more clarity regarding JTreg
 configuration
Message-ID: <c11a4843-d3d8-5f0a-1591-e84fba911cd8@oracle.com>

Thanks to user feedback, this patch adds a section to testing.md about 
the need to configure the JTreg framework for run-test to be able to 
work, and describes some ways to achieve this.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179537
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.01

Generated html file: 
http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.01/raw_files/new/common/doc/testing.html

/Magnus



From magnus.ihse.bursie at oracle.com  Fri Jun 16 21:44:44 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jun 2017 23:44:44 +0200
Subject: RFR: JDK-8179537 Update testing.md for more clarity regarding
 JTReg configuration
In-Reply-To: <c11a4843-d3d8-5f0a-1591-e84fba911cd8@oracle.com>
References: <c11a4843-d3d8-5f0a-1591-e84fba911cd8@oracle.com>
Message-ID: <44de0313-1574-c344-8732-2fbc519bcca9@oracle.com>

Jon pointed out in private conversation that the test suite should be 
written "JTReg", not "JTreg". I've updated both the new text and all old 
instances.

New webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.02

/Magnus

On 2017-06-16 22:05, Magnus Ihse Bursie wrote:
> Thanks to user feedback, this patch adds a section to testing.md about 
> the need to configure the JTreg framework for run-test to be able to 
> work, and describes some ways to achieve this.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179537
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.01
>
> Generated html file: 
> http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.01/raw_files/new/common/doc/testing.html
>
> /Magnus
>



From pepper at gradle.com  Sat Jun 17 07:53:52 2017
From: pepper at gradle.com (Pepper Lebeck-Jobe)
Date: Sat, 17 Jun 2017 07:53:52 +0000
Subject: Build Failure on Master
Message-ID: <CAAJ2G_aTwq8+X=0qzDqjvBpN3tkk_pjSET4fU1xF=wyKuufQbA@mail.gmail.com>

I decided to try and figure out where the empty source path regression was
coming from, and possibly fix it. See:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012938.html

But, when I checked out the sources from mercurial and tried to build them,
I ended up getting some errors. Anyone know whether I should be suspecting
my development environment or the actual code?

Here's what I did based on these instructions.
http://hg.openjdk.java.net/jdk9/jdk9/file/023f93e511ba/common/doc/building.md

$>  hg clone http://hg.openjdk.java.net/jdk9/jdk9 openJDK
$> cd openJDK
$> bash ./get_source.sh
$> bash ./configure --with-boot-jdk=$JAVA_HOME
Output here:
https://drive.google.com/file/d/0Byp8Kl9b7wdibzk2TEFzN3ExVXc/view
$> make clean
$> make all LOG=debug
Output here:
https://drive.google.com/file/d/0Byp8Kl9b7wdiSEpVeHNjSDBIZTA/view

Any help is appreciated. I *think* I have installed the prerequisites
according to the instructions although my version of XCode (8.3.3) is
considerably newer. It wasn't clear of XCode 6.3 was a minimum requirement
or an exact requirement.

Thanks,
Pepper


From pepper at gradle.com  Sat Jun 17 09:17:42 2017
From: pepper at gradle.com (Pepper Lebeck-Jobe)
Date: Sat, 17 Jun 2017 09:17:42 +0000
Subject: Build Failure on Master
In-Reply-To: <80b3b844-b58d-448b-edda-4ce9bdedee36@oracle.com>
References: <CAAJ2G_aTwq8+X=0qzDqjvBpN3tkk_pjSET4fU1xF=wyKuufQbA@mail.gmail.com>
 <80b3b844-b58d-448b-edda-4ce9bdedee36@oracle.com>
Message-ID: <CAAJ2G_bFKUrLSRaJuDke6Gx-2R0muod9nFokSF_cupLKsOWMTg@mail.gmail.com>

Thanks Gary. That got me unblocked. One more question about the repository
layout. If I want to be on the bleeding edge of development for the JPMS
(a.k.a Jigsaw) which of these should I be building from?

http://hg.openjdk.java.net/jigsaw/jake/
http://hg.openjdk.java.net/jdk9/jdk9/
http://hg.openjdk.java.net/jdk9/dev

Thanks,
Pepper

On Sat, Jun 17, 2017 at 5:04 PM gary.adams at oracle.com <gary.adams at oracle.com>
wrote:

> Try adding
>
>     --disable-warnings-as-errors
>
> to your configure command line.
>
> A newer toolchain is sometimes stricter about the source code.
> See "error:" in your build log mentions warnings being treated as errors.
>
> On 6/17/17 3:53 AM, Pepper Lebeck-Jobe wrote:
> > I decided to try and figure out where the empty source path regression
> was
> > coming from, and possibly fix it. See:
> > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012938.html
> >
> > But, when I checked out the sources from mercurial and tried to build
> them,
> > I ended up getting some errors. Anyone know whether I should be
> suspecting
> > my development environment or the actual code?
> >
> > Here's what I did based on these instructions.
> >
> http://hg.openjdk.java.net/jdk9/jdk9/file/023f93e511ba/common/doc/building.md
> >
> > $>  hg clone http://hg.openjdk.java.net/jdk9/jdk9 openJDK
> > $> cd openJDK
> > $> bash ./get_source.sh
> > $> bash ./configure --with-boot-jdk=$JAVA_HOME
> > Output here:
> > https://drive.google.com/file/d/0Byp8Kl9b7wdibzk2TEFzN3ExVXc/view
> > $> make clean
> > $> make all LOG=debug
> > Output here:
> > https://drive.google.com/file/d/0Byp8Kl9b7wdiSEpVeHNjSDBIZTA/view
> >
> > Any help is appreciated. I *think* I have installed the prerequisites
> > according to the instructions although my version of XCode (8.3.3) is
> > considerably newer. It wasn't clear of XCode 6.3 was a minimum
> requirement
> > or an exact requirement.
> >
> > Thanks,
> > Pepper
>
>
>


From claes.redestad at oracle.com  Sat Jun 17 11:39:52 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 17 Jun 2017 13:39:52 +0200
Subject: Build Failure on Master
In-Reply-To: <CAAJ2G_bFKUrLSRaJuDke6Gx-2R0muod9nFokSF_cupLKsOWMTg@mail.gmail.com>
References: <CAAJ2G_aTwq8+X=0qzDqjvBpN3tkk_pjSET4fU1xF=wyKuufQbA@mail.gmail.com>
 <80b3b844-b58d-448b-edda-4ce9bdedee36@oracle.com>
 <CAAJ2G_bFKUrLSRaJuDke6Gx-2R0muod9nFokSF_cupLKsOWMTg@mail.gmail.com>
Message-ID: <594f2df3-8c1b-c749-df69-31ea5a1ef0e9@oracle.com>

http://hg.openjdk.java.net/jigsaw/jake/ - but it was recently synced to jdk9/dev
(as in a few hours ago) and should be effectively the same. With some luck there'll
not be much if any difference between them going forward.

/Claes

On 2017-06-17 11:17, Pepper Lebeck-Jobe wrote:
> Thanks Gary. That got me unblocked. One more question about the repository
> layout. If I want to be on the bleeding edge of development for the JPMS
> (a.k.a Jigsaw) which of these should I be building from?
>
> http://hg.openjdk.java.net/jigsaw/jake/
> http://hg.openjdk.java.net/jdk9/jdk9/
> http://hg.openjdk.java.net/jdk9/dev
>
> Thanks,
> Pepper
>
> On Sat, Jun 17, 2017 at 5:04 PM gary.adams at oracle.com <gary.adams at oracle.com>
> wrote:
>
>> Try adding
>>
>>      --disable-warnings-as-errors
>>
>> to your configure command line.
>>
>> A newer toolchain is sometimes stricter about the source code.
>> See "error:" in your build log mentions warnings being treated as errors.
>>
>> On 6/17/17 3:53 AM, Pepper Lebeck-Jobe wrote:
>>> I decided to try and figure out where the empty source path regression
>> was
>>> coming from, and possibly fix it. See:
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012938.html
>>>
>>> But, when I checked out the sources from mercurial and tried to build
>> them,
>>> I ended up getting some errors. Anyone know whether I should be
>> suspecting
>>> my development environment or the actual code?
>>>
>>> Here's what I did based on these instructions.
>>>
>> http://hg.openjdk.java.net/jdk9/jdk9/file/023f93e511ba/common/doc/building.md
>>> $>  hg clone http://hg.openjdk.java.net/jdk9/jdk9 openJDK
>>> $> cd openJDK
>>> $> bash ./get_source.sh
>>> $> bash ./configure --with-boot-jdk=$JAVA_HOME
>>> Output here:
>>> https://drive.google.com/file/d/0Byp8Kl9b7wdibzk2TEFzN3ExVXc/view
>>> $> make clean
>>> $> make all LOG=debug
>>> Output here:
>>> https://drive.google.com/file/d/0Byp8Kl9b7wdiSEpVeHNjSDBIZTA/view
>>>
>>> Any help is appreciated. I *think* I have installed the prerequisites
>>> according to the instructions although my version of XCode (8.3.3) is
>>> considerably newer. It wasn't clear of XCode 6.3 was a minimum
>> requirement
>>> or an exact requirement.
>>>
>>> Thanks,
>>> Pepper
>>
>>



From Alan.Bateman at oracle.com  Sat Jun 17 14:51:31 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 17 Jun 2017 15:51:31 +0100
Subject: Build Failure on Master
In-Reply-To: <594f2df3-8c1b-c749-df69-31ea5a1ef0e9@oracle.com>
References: <CAAJ2G_aTwq8+X=0qzDqjvBpN3tkk_pjSET4fU1xF=wyKuufQbA@mail.gmail.com>
 <80b3b844-b58d-448b-edda-4ce9bdedee36@oracle.com>
 <CAAJ2G_bFKUrLSRaJuDke6Gx-2R0muod9nFokSF_cupLKsOWMTg@mail.gmail.com>
 <594f2df3-8c1b-c749-df69-31ea5a1ef0e9@oracle.com>
Message-ID: <0258afaf-5c61-ebfa-5b98-1dbf6cc6d353@oracle.com>

On 17/06/2017 12:39, Claes Redestad wrote:
> http://hg.openjdk.java.net/jigsaw/jake/ - but it was recently synced 
> to jdk9/dev
> (as in a few hours ago) and should be effectively the same. With some 
> luck there'll
> not be much if any difference between them going forward.
The changes that were accumulating in jigsaw/jake have been pushed to 
jdk9/dev so that jdk9/dev has almost everything for next week's build 
(expected to be the initial release candidate build [1]). I expect we'll 
mark jigsaw/jake read-only soon.

-Alan

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html


From rohitvvv at gmail.com  Sat Jun 17 19:19:18 2017
From: rohitvvv at gmail.com (Rohit Vaidya)
Date: Sun, 18 Jun 2017 00:49:18 +0530
Subject: Build failing on Mac OS X 10.12.5
Message-ID: <CAPFUtmS_piNV995w56PHaoW=+PAu7aK+8JtB9RpV5GurEipsYg@mail.gmail.com>

Hello Experts,

I was running a fresh JDK 9 build on Mac OS Sierra 10.12.5.
"$sh configure" fails with freetype dependency. On installing freetype with
brew it still continues to fail.

configure: error: Could not find freetype! You might be able to fix this by
running 'brew install freetype'.

/Users/rohitvaidya/Downloads/projects/9dev/common/autoconf/generated-configure.sh:
line 82: 5: Bad file descriptor
configure exiting with result code 1

Has anyone faced this before?
-- 
Regards,
Rohit Vaidya


From glaubitz at physik.fu-berlin.de  Sat Jun 17 23:40:06 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sun, 18 Jun 2017 01:40:06 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170614120408.GB16230@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
Message-ID: <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>

Hi Erik!

On 06/14/2017 02:04 PM, John Paul Adrian Glaubitz wrote:
> On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
>> thanks for contributing and signing the OCA!
> 
> Thanks for reviewing my patches ;-).

My OCA has been completed now and I'm now showing up on the list
of signees:

> http://www.oracle.com/technetwork/community/oca-486395.html

So, at least from the bureaucracy side, I should be all set now.

>> I think the first three patches (hotspot-add-missing-log-header.diff,
>> hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) all
>> look good, thanks for fixing broken code. Consider them Reviewed by me.
>> Every patch needs a corresponding issue in the bug tracker, so I went ahead
>> and created:
>> - https://bugs.openjdk.java.net/browse/JDK-8182163
>> - https://bugs.openjdk.java.net/browse/JDK-8182164
>> - https://bugs.openjdk.java.net/browse/JDK-8182165

So, for these three patches. What else needs to be done to get them
in a state so they can be merged? I understand they need to be reviewed
by a second reviewer as they concern Hotspot code.

In another message, you also mentioned:

> Also, have you run the tier 1 testing for hotspot (the tests that need to
> pass for every commit)? You can run those tests by running (from the
> top-level "root" repo):
>
> $ make test TEST=hotspot_tier1
>
> or, if you want to try the new run-test functionality
>
> $ make run-test-hotspot_tier1

Should those be run on the Linux sparc64 machine or just on Linux x86_64?

I'm asking because running the testsuite on Linux sparc64 will only be
possible with all four patches applied as they are build fixes. Running
the testsuite on Linux x86_64 will be possible, of course.

After fixing the build on Linux sparc, I will have more patches ready
to fix the Zero builds on even more targets ;-).

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From mark.reinhold at oracle.com  Sun Jun 18 10:47:19 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Sun, 18 Jun 2017 03:47:19 -0700 (PDT)
Subject: RFR 8167227: Simplify the JDK 9 API-specification overview page (docs
 only)
Message-ID: <20170618104719.C194774F73@eggemoggin.niobe.net>

http://cr.openjdk.java.net/~mr/rev/8182408/
https://bugs.openjdk.java.net/browse/JDK-8182408

This is a follow-on to Magnus's changes for 8175824.

Oracle's legal department has recently advised that the liberal use of
trademark symbols on the API-specification overview page is not required.
We should, rather, just include a registered-trademark symbol (&reg;)
after the first prominent instance of "Java". The warnings about the
provisional nature of the API can also be simplified.

The webrev page contains links to example Javadoc output for different
variants: GA vs. ad-hoc, and SE + JDK + FX vs. SE + JDK vs. just SE.

Current output, for reference:
http://download.java.net/java/jdk9/docs/api/overview-summary.html

Thanks,
- Mark


From mandy.chung at oracle.com  Mon Jun 19 04:05:21 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sun, 18 Jun 2017 21:05:21 -0700
Subject: RFR 8167227: Simplify the JDK 9 API-specification overview page
 (docs only)
In-Reply-To: <20170618104719.C194774F73@eggemoggin.niobe.net>
References: <20170618104719.C194774F73@eggemoggin.niobe.net>
Message-ID: <18B164C3-A963-4BD4-8671-2F94D25FFE6D@oracle.com>

Looks good to me.

Mandy

> On Jun 18, 2017, at 3:47 AM, mark.reinhold at oracle.com wrote:
> 
> http://cr.openjdk.java.net/~mr/rev/8182408/
> https://bugs.openjdk.java.net/browse/JDK-8182408
> 
> This is a follow-on to Magnus's changes for 8175824.
> 
> Oracle's legal department has recently advised that the liberal use of
> trademark symbols on the API-specification overview page is not required.
> We should, rather, just include a registered-trademark symbol (&reg;)
> after the first prominent instance of "Java". The warnings about the
> provisional nature of the API can also be simplified.
> 
> The webrev page contains links to example Javadoc output for different
> variants: GA vs. ad-hoc, and SE + JDK + FX vs. SE + JDK vs. just SE.
> 
> Current output, for reference:
> http://download.java.net/java/jdk9/docs/api/overview-summary.html
> 
> Thanks,
> - Mark



From erik.helin at oracle.com  Mon Jun 19 06:59:38 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 19 Jun 2017 08:59:38 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
Message-ID: <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>

On 06/18/2017 01:40 AM, John Paul Adrian Glaubitz wrote:
> Hi Erik!
> 
> On 06/14/2017 02:04 PM, John Paul Adrian Glaubitz wrote:
>> On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
>>> thanks for contributing and signing the OCA!
>>
>> Thanks for reviewing my patches ;-).
> 
> My OCA has been completed now and I'm now showing up on the list
> of signees:
> 
>> http://www.oracle.com/technetwork/community/oca-486395.html
> 
> So, at least from the bureaucracy side, I should be all set now.

Great, thanks!

>>> I think the first three patches (hotspot-add-missing-log-header.diff,
>>> hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) all
>>> look good, thanks for fixing broken code. Consider them Reviewed by me.
>>> Every patch needs a corresponding issue in the bug tracker, so I went ahead
>>> and created:
>>> - https://bugs.openjdk.java.net/browse/JDK-8182163
>>> - https://bugs.openjdk.java.net/browse/JDK-8182164
>>> - https://bugs.openjdk.java.net/browse/JDK-8182165
> 
> So, for these three patches. What else needs to be done to get them
> in a state so they can be merged? I understand they need to be reviewed
> by a second reviewer as they concern Hotspot code.

Yep, you need a second reviewer for these patches.

> In another message, you also mentioned:
> 
>> Also, have you run the tier 1 testing for hotspot (the tests that need to
>> pass for every commit)? You can run those tests by running (from the
>> top-level "root" repo):
>>
>> $ make test TEST=hotspot_tier1
>>
>> or, if you want to try the new run-test functionality
>>
>> $ make run-test-hotspot_tier1
> 
> Should those be run on the Linux sparc64 machine or just on Linux x86_64?

The tests should be run in order to verify your changes. Since your
changes make Linux/sparc64 work again, they should be run on Linux/sparc64.

> I'm asking because running the testsuite on Linux sparc64 will only be
> possible with all four patches applied as they are build fixes. Running
> the testsuite on Linux x86_64 will be possible, of course.

Ok, this is the part I don't really understand yet. Why run with Zero on
Linux/sparc64? Shouldn't it be possible to run HotSpot "natively" (with
the template interpreter, C1, C2) on Linux/sparc64?

Thanks,
Erik

> After fixing the build on Linux sparc, I will have more patches ready
> to fix the Zero builds on even more targets ;-).
> 
> Cheers,
> Adrian
> 


From glaubitz at physik.fu-berlin.de  Mon Jun 19 07:06:13 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 19 Jun 2017 09:06:13 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
 <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>
Message-ID: <20170619070613.GE28760@physik.fu-berlin.de>

On Mon, Jun 19, 2017 at 08:59:38AM +0200, Erik Helin wrote:
> > I'm asking because running the testsuite on Linux sparc64 will only be
> > possible with all four patches applied as they are build fixes. Running
> > the testsuite on Linux x86_64 will be possible, of course.
> 
> Ok, this is the part I don't really understand yet. Why run with Zero on
> Linux/sparc64? Shouldn't it be possible to run HotSpot "natively" (with
> the template interpreter, C1, C2) on Linux/sparc64?

The first three patches are needed to get native Hotspot to build on
Linux sparc. Without the patches, the builds bails out with compiler
errors.

So, should I just run the testsuite with all three patches applied?

The fourth patch just fixes Zero on Linux sparc. If I understand
correctly, Debian's openjdk packages always build the Zero VM even on
targets with a native Hotspot. And without the last patch, the Zero
build fails on Linux sparc.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Mon Jun 19 08:24:09 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Jun 2017 10:24:09 +0200
Subject: RFR: JDK-8179537 Update testing.md for more clarity regarding
 JTReg configuration
In-Reply-To: <44de0313-1574-c344-8732-2fbc519bcca9@oracle.com>
References: <c11a4843-d3d8-5f0a-1591-e84fba911cd8@oracle.com>
 <44de0313-1574-c344-8732-2fbc519bcca9@oracle.com>
Message-ID: <a661568f-da40-1595-8e81-3d51d055cf13@oracle.com>

Looks good.

/Erik


On 2017-06-16 23:44, Magnus Ihse Bursie wrote:
> Jon pointed out in private conversation that the test suite should be 
> written "JTReg", not "JTreg". I've updated both the new text and all 
> old instances.
>
> New webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.02
>
> /Magnus
>
> On 2017-06-16 22:05, Magnus Ihse Bursie wrote:
>> Thanks to user feedback, this patch adds a section to testing.md 
>> about the need to configure the JTreg framework for run-test to be 
>> able to work, and describes some ways to achieve this.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179537
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.01
>>
>> Generated html file: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179537-update-testing-readme-about-jtreg-configuration/webrev.01/raw_files/new/common/doc/testing.html
>>
>> /Magnus
>>
>



From erik.joelsson at oracle.com  Mon Jun 19 08:41:09 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Jun 2017 10:41:09 +0200
Subject: RFR 8167227: Simplify the JDK 9 API-specification overview page
 (docs only)
In-Reply-To: <20170618104719.C194774F73@eggemoggin.niobe.net>
References: <20170618104719.C194774F73@eggemoggin.niobe.net>
Message-ID: <ffdeac86-c7d9-13ad-78bf-4bb457af57f0@oracle.com>

Looks good to me.

The change to the log message is a bit weird. Was this meant as a 
temporary way for finding the output file?

/Erik


On 2017-06-18 12:47, mark.reinhold at oracle.com wrote:
> http://cr.openjdk.java.net/~mr/rev/8182408/
> https://bugs.openjdk.java.net/browse/JDK-8182408
>
> This is a follow-on to Magnus's changes for 8175824.
>
> Oracle's legal department has recently advised that the liberal use of
> trademark symbols on the API-specification overview page is not required.
> We should, rather, just include a registered-trademark symbol (&reg;)
> after the first prominent instance of "Java". The warnings about the
> provisional nature of the API can also be simplified.
>
> The webrev page contains links to example Javadoc output for different
> variants: GA vs. ad-hoc, and SE + JDK + FX vs. SE + JDK vs. just SE.
>
> Current output, for reference:
> http://download.java.net/java/jdk9/docs/api/overview-summary.html
>
> Thanks,
> - Mark



From mark.reinhold at oracle.com  Mon Jun 19 09:02:38 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 19 Jun 2017 11:02:38 +0200
Subject: RFR 8167227: Simplify the JDK 9 API-specification overview page
 (docs only)
In-Reply-To: <ffdeac86-c7d9-13ad-78bf-4bb457af57f0@oracle.com>
References: <20170618104719.C194774F73@eggemoggin.niobe.net>
 <ffdeac86-c7d9-13ad-78bf-4bb457af57f0@oracle.com>
Message-ID: <20170619110238.290072611@eggemoggin.niobe.net>

2017/6/19 10:41:09 +0200, erik.joelsson at oracle.com:
> Looks good to me.
> 
> The change to the log message is a bit weird. Was this meant as a 
> temporary way for finding the output file?

Good catch -- yes, that was temporary.  I'll remove it.

Thanks,
- Mark


From erik.helin at oracle.com  Mon Jun 19 12:48:39 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 19 Jun 2017 14:48:39 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170619070613.GE28760@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
 <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>
 <20170619070613.GE28760@physik.fu-berlin.de>
Message-ID: <c65e8d8e-b400-a42b-8d13-eed77525cde9@oracle.com>



On 06/19/2017 09:06 AM, John Paul Adrian Glaubitz wrote:
> On Mon, Jun 19, 2017 at 08:59:38AM +0200, Erik Helin wrote:
>>> I'm asking because running the testsuite on Linux sparc64 will only be
>>> possible with all four patches applied as they are build fixes. Running
>>> the testsuite on Linux x86_64 will be possible, of course.
>>
>> Ok, this is the part I don't really understand yet. Why run with Zero on
>> Linux/sparc64? Shouldn't it be possible to run HotSpot "natively" (with
>> the template interpreter, C1, C2) on Linux/sparc64?
>
> The first three patches are needed to get native Hotspot to build on
> Linux sparc. Without the patches, the builds bails out with compiler
> errors.
>
> So, should I just run the testsuite with all three patches applied?

Yes, please run the testsuite with the three patches applied. This 
should work (famous last words ;)) for the "native" Linux/sparc64 
version of hotspot (if not, I would to curious to learn why). To test 
Linux/sparc64+zero you obviously need the fourth patch applied as well.

> The fourth patch just fixes Zero on Linux sparc. If I understand
> correctly, Debian's openjdk packages always build the Zero VM even on
> targets with a native Hotspot. And without the last patch, the Zero
> build fails on Linux sparc.

Ah, now I think I get it :) This is for the openjdk-9-jre-zero package, 
right? Does the openjdk-9-jre package provide the "native" (using 
template interpreter, C1, C2) version of hotspot if possible?

Thanks,
Erik

> Adrian
>


From mandy.chung at oracle.com  Mon Jun 19 17:17:53 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 19 Jun 2017 10:17:53 -0700
Subject: Request Review JDK-8182492: docs bundle needs legal notices for 3rd
 party libraries distributed for javadoc search 
Message-ID: <46272D2A-12F6-4BDD-BAC3-C60891F9BA0C@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182492/webrev.00/

JDK docs build enables javadoc search that distributes jquery and jszip.
The docs bundle needs to include legal notices for these 3rd party
libraries.

In addition, pako.md is missing and fixed in this patch.

Mandy


From jonathan.gibbons at oracle.com  Mon Jun 19 19:04:54 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 19 Jun 2017 12:04:54 -0700
Subject: Request Review JDK-8182492: docs bundle needs legal notices for
 3rd party libraries distributed for javadoc search
In-Reply-To: <46272D2A-12F6-4BDD-BAC3-C60891F9BA0C@oracle.com>
References: <46272D2A-12F6-4BDD-BAC3-C60891F9BA0C@oracle.com>
Message-ID: <59482056.9030307@oracle.com>

Looks good to me.

-- Jon

On 06/19/2017 10:17 AM, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182492/webrev.00/
>
> JDK docs build enables javadoc search that distributes jquery and jszip.
> The docs bundle needs to include legal notices for these 3rd party
> libraries.
>
> In addition, pako.md is missing and fixed in this patch.
>
> Mandy



From john.r.rose at oracle.com  Mon Jun 19 20:22:54 2017
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 19 Jun 2017 13:22:54 -0700
Subject: RFR 8167227: Simplify the JDK 9 API-specification overview page
 (docs only)
In-Reply-To: <20170618104719.C194774F73@eggemoggin.niobe.net>
References: <20170618104719.C194774F73@eggemoggin.niobe.net>
Message-ID: <981FE5D8-DE42-4728-8F75-C104611A4092@oracle.com>

On Jun 18, 2017, at 3:47 AM, mark.reinhold at oracle.com wrote:
> 
> Current output, for reference:
> http://download.java.net/java/jdk9/docs/api/overview-summary.html <http://download.java.net/java/jdk9/docs/api/overview-summary.html>

Yes, the language changes are good.  (From a non-legal English major POV.)

I also reviewed the makefile mechanics; those look good AFAICT.

? John

From erik.joelsson at oracle.com  Tue Jun 20 09:27:11 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 20 Jun 2017 11:27:11 +0200
Subject: Request Review JDK-8182492: docs bundle needs legal notices for
 3rd party libraries distributed for javadoc search
In-Reply-To: <46272D2A-12F6-4BDD-BAC3-C60891F9BA0C@oracle.com>
References: <46272D2A-12F6-4BDD-BAC3-C60891F9BA0C@oracle.com>
Message-ID: <b957f29d-d0bf-26a6-4dfb-ed5661d0ba75@oracle.com>

Looks good to me.

/Erik


On 2017-06-19 19:17, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182492/webrev.00/
>
> JDK docs build enables javadoc search that distributes jquery and jszip.
> The docs bundle needs to include legal notices for these 3rd party
> libraries.
>
> In addition, pako.md is missing and fixed in this patch.
>
> Mandy



From jonathan.gibbons at oracle.com  Tue Jun 20 18:32:52 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 20 Jun 2017 11:32:52 -0700
Subject: RFR: 8182611: @extLink taglet ignores text after first newline.
Message-ID: <59496A54.2030305@oracle.com>

Please review a simple fix to the regex used to analyze the content of 
an {@extLink } tag.

The fix is to use DOTALL mode for the regex, and for good measure, to 
ensure the match is up to the end of the line.

JBS: https://bugs.openjdk.java.net/browse/JDK-8182611

The one-line fix is in the comments for the JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8182611?focusedCommentId=14094548&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14094548

-- Jon


From kumar.x.srinivasan at oracle.com  Tue Jun 20 21:21:56 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 20 Jun 2017 14:21:56 -0700
Subject: RFR: 8182611: @extLink taglet ignores text after first newline.
In-Reply-To: <59496A54.2030305@oracle.com>
References: <59496A54.2030305@oracle.com>
Message-ID: <594991F4.1070203@oracle.com>


Hi Jon,

Looks good to me.

Thanks
Kumar

> Please review a simple fix to the regex used to analyze the content of 
> an {@extLink } tag.
>
> The fix is to use DOTALL mode for the regex, and for good measure, to 
> ensure the match is up to the end of the line.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8182611
>
> The one-line fix is in the comments for the JBS issue:
> https://bugs.openjdk.java.net/browse/JDK-8182611?focusedCommentId=14094548&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14094548 
>
>
> -- Jon



From magnus.ihse.bursie at oracle.com  Wed Jun 21 00:46:50 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 21 Jun 2017 02:46:50 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
Message-ID: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>

Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this 
document. !!!!!!!!!!!!!" :-)

The build documentation has been in need of an overhaul for a very long 
time. The document is not very well structured, and contains not only 
outdated but also irrelevant information, all the while valuable 
information is missing.

For some time now, I've worked as a background project to rewrite the 
build documentation to address these shortcomings. Now it's finally done.

Here is the new documentation in html format: 
http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html

And here it is in markdown: 
http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md

I've tried to make the document as readable as possible in raw markdown, 
hoping it can be of assistance for command-line users.

Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01

/Magnus


From thomas.stuefe at gmail.com  Wed Jun 21 07:02:46 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 21 Jun 2017 09:02:46 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
Message-ID: <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>

Hi Magnus,

excellent work! Some minor remarks:

You also mentioned Cygwin hg in the "Special considerations" section.
However, because updating Cygwin is a bit of a pain (you need to close all
consoles to do this) it may make sense to move the "Install Cygwin and all
required packages" up to the beginning of the document and include
"mercurial" in the list of cygwin packages to install.

In addition to that (if contributing to the OpenJDK is in the scope for
this document?) it may make sense to install at least ksh (for webrevs) and
sftp (for uploading webrevs) for Cygwin.

As for AIX, so far we have not yet broken compatibility with AIX 5.3. While
this is something which we may give up in the future, currently jdk9/10
still build and run on AIX 5.3 and 6.1. I think we can flesh out this
section a lot. We will discuss this in our team.

Kind Regards, Thomas



On Wed, Jun 21, 2017 at 2:46 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document.
> !!!!!!!!!!!!!" :-)
>
> The build documentation has been in need of an overhaul for a very long
> time. The document is not very well structured, and contains not only
> outdated but also irrelevant information, all the while valuable
> information is missing.
>
> For some time now, I've worked as a background project to rewrite the
> build documentation to address these shortcomings. Now it's finally done.
>
> Here is the new documentation in html format:
> http://cr.openjdk.java.net/~ihse/demo-new-build-readme/commo
> n/doc/building.html
>
> And here it is in markdown: http://cr.openjdk.java.net/~ih
> se/JDK-8179892-update-build-readme/webrev.01/raw_files/new/c
> ommon/doc/building.md
>
> I've tried to make the document as readable as possible in raw markdown,
> hoping it can be of assistance for command-line users.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-re
> adme/webrev.01
>
> /Magnus
>


From erik.joelsson at oracle.com  Wed Jun 21 08:07:14 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 21 Jun 2017 10:07:14 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
Message-ID: <a28dbdff-7b1d-aa8e-6a95-ddf78387000b@oracle.com>

Wow, this is massive, and very good!

IMO, we should just push this as is and handle any updates/corrections 
as followups. Otherwise we risk not getting this in at all.

Looks good enough to me.

/Erik


On 2017-06-21 02:46, Magnus Ihse Bursie wrote:
> Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this 
> document. !!!!!!!!!!!!!" :-)
>
> The build documentation has been in need of an overhaul for a very 
> long time. The document is not very well structured, and contains not 
> only outdated but also irrelevant information, all the while valuable 
> information is missing.
>
> For some time now, I've worked as a background project to rewrite the 
> build documentation to address these shortcomings. Now it's finally done.
>
> Here is the new documentation in html format: 
> http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html
>
> And here it is in markdown: 
> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md
>
> I've tried to make the document as readable as possible in raw 
> markdown, hoping it can be of assistance for command-line users.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Wed Jun 21 10:54:07 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 21 Jun 2017 12:54:07 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <a28dbdff-7b1d-aa8e-6a95-ddf78387000b@oracle.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
 <a28dbdff-7b1d-aa8e-6a95-ddf78387000b@oracle.com>
Message-ID: <41cbb6f1-e6b7-e0e1-4b49-223c191b9e7d@oracle.com>

On 2017-06-21 10:07, Erik Joelsson wrote:
> Wow, this is massive, and very good!

Thanks you. It's been in the making for a long time, and I almost didn't 
get to complete it in time for JDK 9.

> IMO, we should just push this as is and handle any updates/corrections 
> as followups. Otherwise we risk not getting this in at all.

Agree. I'm sure there are lots of things left to improve. Please open a 
new bug for JDK 10 with your comments, or we can discuss in person when 
I'm back from my vacation.

/Magnus

>
> Looks good enough to me.
>
> /Erik
>
>
> On 2017-06-21 02:46, Magnus Ihse Bursie wrote:
>> Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this 
>> document. !!!!!!!!!!!!!" :-)
>>
>> The build documentation has been in need of an overhaul for a very 
>> long time. The document is not very well structured, and contains not 
>> only outdated but also irrelevant information, all the while valuable 
>> information is missing.
>>
>> For some time now, I've worked as a background project to rewrite the 
>> build documentation to address these shortcomings. Now it's finally 
>> done.
>>
>> Here is the new documentation in html format: 
>> http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html
>>
>> And here it is in markdown: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md
>>
>> I've tried to make the document as readable as possible in raw 
>> markdown, hoping it can be of assistance for command-line users.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01
>>
>> /Magnus
>



From magnus.ihse.bursie at oracle.com  Wed Jun 21 10:59:39 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 21 Jun 2017 12:59:39 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
 <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>
Message-ID: <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>

On 2017-06-21 09:02, Thomas St?fe wrote:
> Hi Magnus,
>
> excellent work!

Thank you! :-)

> Some minor remarks:
>
> You also mentioned Cygwin hg in the "Special considerations" section. 
> However, because updating Cygwin is a bit of a pain (you need to close 
> all consoles to do this) it may make sense to move the "Install Cygwin 
> and all required packages" up to the beginning of the document and 
> include "mercurial" in the list of cygwin packages to install.
>
> In addition to that (if contributing to the OpenJDK is in the scope 
> for this document?) it may make sense to install at least ksh (for 
> webrevs) and sftp (for uploading webrevs) for Cygwin.

For JDK 10, we can discuss where to draw the line of the responsibility 
of this document. I don't think it can cover all OpenJDK developer 
stories, like webrev, etc. But we should probably make sure that such a 
document exists somewhere, in the repo or on the OpenJDK web site or wiki.

I've tried putting information about what to install and how grouped to 
the specific requirements. This has both drawbacks and benefits. One 
thing you don't get is a "one stop" description of "install all these 
packages". That could perhaps be added to the TL;DR section -- if you 
just want something quick that is likely to work, and you don't care 
why, or if you install slightly too much.

> As for AIX, so far we have not yet broken compatibility with AIX 5.3. 
> While this is something which we may give up in the future, currently 
> jdk9/10 still build and run on AIX 5.3 and 6.1.

Ok, I updated the document to include this information.

> I think we can flesh out this section a lot. We will discuss this in 
> our team.

That sounds great! I realize the AIX part was a bit thin, but at least 
it is mentioned, as compared to the old document. :)

I'm leaving for vacation now, but I'll be happy to discuss with you and 
your team how to improve the documentation for AIX/PPC in JDK 10.

/Magnus

>
> Kind Regards, Thomas
>
>
> On Wed, Jun 21, 2017 at 2:46 AM, Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>> 
> wrote:
>
>     Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this
>     document. !!!!!!!!!!!!!" :-)
>
>     The build documentation has been in need of an overhaul for a very
>     long time. The document is not very well structured, and contains
>     not only outdated but also irrelevant information, all the while
>     valuable information is missing.
>
>     For some time now, I've worked as a background project to rewrite
>     the build documentation to address these shortcomings. Now it's
>     finally done.
>
>     Here is the new documentation in html format:
>     http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html
>     <http://cr.openjdk.java.net/%7Eihse/demo-new-build-readme/common/doc/building.html>
>
>     And here it is in markdown:
>     http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md
>     <http://cr.openjdk.java.net/%7Eihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md>
>
>     I've tried to make the document as readable as possible in raw
>     markdown, hoping it can be of assistance for command-line users.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
>     <https://bugs.openjdk.java.net/browse/JDK-8179892>
>     WebRev:
>     http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01
>     <http://cr.openjdk.java.net/%7Eihse/JDK-8179892-update-build-readme/webrev.01>
>
>     /Magnus
>
>



From dalibor.topic at oracle.com  Wed Jun 21 11:03:11 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 21 Jun 2017 13:03:11 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
Message-ID: <12d804e3-b7c3-7d5f-1ae3-6e49d95121d3@oracle.com>

On 21.06.2017 02:46, Magnus Ihse Bursie wrote:
> Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this 
> document. !!!!!!!!!!!!!" :-)

It is also very good. Thank you. ;)

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From thomas.stuefe at gmail.com  Wed Jun 21 13:39:20 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 21 Jun 2017 15:39:20 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
 <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>
 <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>
Message-ID: <CAA-vtUxUVpz=-AUtFsci1ZxjyfXfwrUoB8GLpfJLpAEvC25Ddw@mail.gmail.com>

I agree with Eric that it looks fine enough as it is now, and that any
subsequent additions (e.g. AIX related infos) can be added later as
separate changes.

Happy Vacation!

..Thomas

On Wed, Jun 21, 2017 at 12:59 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2017-06-21 09:02, Thomas St?fe wrote:
>
> Hi Magnus,
>
> excellent work!
>
>
> Thank you! :-)
>
> Some minor remarks:
>
> You also mentioned Cygwin hg in the "Special considerations" section.
> However, because updating Cygwin is a bit of a pain (you need to close all
> consoles to do this) it may make sense to move the "Install Cygwin and all
> required packages" up to the beginning of the document and include
> "mercurial" in the list of cygwin packages to install.
>
> In addition to that (if contributing to the OpenJDK is in the scope for
> this document?) it may make sense to install at least ksh (for webrevs) and
> sftp (for uploading webrevs) for Cygwin.
>
>
> For JDK 10, we can discuss where to draw the line of the responsibility of
> this document. I don't think it can cover all OpenJDK developer stories,
> like webrev, etc. But we should probably make sure that such a document
> exists somewhere, in the repo or on the OpenJDK web site or wiki.
>
> I've tried putting information about what to install and how grouped to
> the specific requirements. This has both drawbacks and benefits. One thing
> you don't get is a "one stop" description of "install all these packages".
> That could perhaps be added to the TL;DR section -- if you just want
> something quick that is likely to work, and you don't care why, or if you
> install slightly too much.
>
> As for AIX, so far we have not yet broken compatibility with AIX 5.3.
> While this is something which we may give up in the future, currently
> jdk9/10 still build and run on AIX 5.3 and 6.1.
>
>
> Ok, I updated the document to include this information.
>
> I think we can flesh out this section a lot. We will discuss this in our
> team.
>
>
> That sounds great! I realize the AIX part was a bit thin, but at least it
> is mentioned, as compared to the old document. :)
>
> I'm leaving for vacation now, but I'll be happy to discuss with you and
> your team how to improve the documentation for AIX/PPC in JDK 10.
>
> /Magnus
>
>
> Kind Regards, Thomas
>
>
>
> On Wed, Jun 21, 2017 at 2:46 AM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>> Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this
>> document. !!!!!!!!!!!!!" :-)
>>
>> The build documentation has been in need of an overhaul for a very long
>> time. The document is not very well structured, and contains not only
>> outdated but also irrelevant information, all the while valuable
>> information is missing.
>>
>> For some time now, I've worked as a background project to rewrite the
>> build documentation to address these shortcomings. Now it's finally done.
>>
>> Here is the new documentation in html format:
>> http://cr.openjdk.java.net/~ihse/demo-new-build-readme/commo
>> n/doc/building.html
>>
>> And here it is in markdown: http://cr.openjdk.java.net/~ih
>> se/JDK-8179892-update-build-readme/webrev.01/raw_files/new/c
>> ommon/doc/building.md
>>
>> I've tried to make the document as readable as possible in raw markdown,
>> hoping it can be of assistance for command-line users.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-re
>> adme/webrev.01
>>
>> /Magnus
>>
>
>
>


From martinrb at google.com  Wed Jun 21 13:44:04 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 21 Jun 2017 06:44:04 -0700
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <CAA-vtUxUVpz=-AUtFsci1ZxjyfXfwrUoB8GLpfJLpAEvC25Ddw@mail.gmail.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
 <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>
 <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>
 <CAA-vtUxUVpz=-AUtFsci1ZxjyfXfwrUoB8GLpfJLpAEvC25Ddw@mail.gmail.com>
Message-ID: <CA+kOe0-OgO8Nqgn-92NP_Cni3i4QozwaORa3a7ug7aHk=vSB0w@mail.gmail.com>

Thanks!

On debian-based systems, it's useful to get dependencies using

sudo apt-get -y build-dep openjdk-8-jdk

even when building jdk9 or jdk10


From volker.simonis at gmail.com  Thu Jun 22 09:31:23 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 22 Jun 2017 11:31:23 +0200
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
 <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>
 <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>
Message-ID: <CA+3eh13NaK697Yv2N9LOOyphvS++nFn96-K4z163NB_vm7KQ0A@mail.gmail.com>

On Wed, Jun 21, 2017 at 12:59 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2017-06-21 09:02, Thomas St?fe wrote:
>>
>> Hi Magnus,
>>
>> excellent work!
>
>
> Thank you! :-)
>
>> Some minor remarks:
>>
>> You also mentioned Cygwin hg in the "Special considerations" section.
>> However, because updating Cygwin is a bit of a pain (you need to close all
>> consoles to do this) it may make sense to move the "Install Cygwin and all
>> required packages" up to the beginning of the document and include
>> "mercurial" in the list of cygwin packages to install.
>>
>> In addition to that (if contributing to the OpenJDK is in the scope for
>> this document?) it may make sense to install at least ksh (for webrevs) and
>> sftp (for uploading webrevs) for Cygwin.
>
>
> For JDK 10, we can discuss where to draw the line of the responsibility of
> this document. I don't think it can cover all OpenJDK developer stories,
> like webrev, etc. But we should probably make sure that such a document
> exists somewhere, in the repo or on the OpenJDK web site or wiki.
>
> I've tried putting information about what to install and how grouped to the
> specific requirements. This has both drawbacks and benefits. One thing you
> don't get is a "one stop" description of "install all these packages". That
> could perhaps be added to the TL;DR section -- if you just want something
> quick that is likely to work, and you don't care why, or if you install
> slightly too much.
>
>> As for AIX, so far we have not yet broken compatibility with AIX 5.3.
>> While this is something which we may give up in the future, currently
>> jdk9/10 still build and run on AIX 5.3 and 6.1.
>
>
> Ok, I updated the document to include this information.
>
>> I think we can flesh out this section a lot. We will discuss this in our
>> team.
>
>
> That sounds great! I realize the AIX part was a bit thin, but at least it is
> mentioned, as compared to the old document. :)
>
> I'm leaving for vacation now, but I'll be happy to discuss with you and your
> team how to improve the documentation for AIX/PPC in JDK 10.
>

Great stuff Magnus!

Happy midsummer and happy holidays :)

> /Magnus
>
>>
>> Kind Regards, Thomas
>>
>>
>> On Wed, Jun 21, 2017 at 2:46 AM, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>> wrote:
>>
>>     Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this
>>     document. !!!!!!!!!!!!!" :-)
>>
>>     The build documentation has been in need of an overhaul for a very
>>     long time. The document is not very well structured, and contains
>>     not only outdated but also irrelevant information, all the while
>>     valuable information is missing.
>>
>>     For some time now, I've worked as a background project to rewrite
>>     the build documentation to address these shortcomings. Now it's
>>     finally done.
>>
>>     Here is the new documentation in html format:
>>
>> http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html
>>
>> <http://cr.openjdk.java.net/%7Eihse/demo-new-build-readme/common/doc/building.html>
>>
>>     And here it is in markdown:
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md
>>
>> <http://cr.openjdk.java.net/%7Eihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md>
>>
>>     I've tried to make the document as readable as possible in raw
>>     markdown, hoping it can be of assistance for command-line users.
>>
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
>>     <https://bugs.openjdk.java.net/browse/JDK-8179892>
>>     WebRev:
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01
>>
>> <http://cr.openjdk.java.net/%7Eihse/JDK-8179892-update-build-readme/webrev.01>
>>
>>     /Magnus
>>
>>
>


From glaubitz at physik.fu-berlin.de  Thu Jun 22 10:27:03 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 22 Jun 2017 12:27:03 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <c65e8d8e-b400-a42b-8d13-eed77525cde9@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
 <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>
 <20170619070613.GE28760@physik.fu-berlin.de>
 <c65e8d8e-b400-a42b-8d13-eed77525cde9@oracle.com>
Message-ID: <20170622102703.GC18516@physik.fu-berlin.de>

On Mon, Jun 19, 2017 at 02:48:39PM +0200, Erik Helin wrote:
> >So, should I just run the testsuite with all three patches applied?
> 
> Yes, please run the testsuite with the three patches applied. This should
> work (famous last words ;)) for the "native" Linux/sparc64 version of
> hotspot (if not, I would to curious to learn why). To test
> Linux/sparc64+zero you obviously need the fourth patch applied as well.

Ok, I will give it a try. I will do a hotspot-native build first, run
the testsuite and post the results. Let's tackle zero later. I've got
anoter bunch of zero-related fixes that we're carrying in the Debian
package and that should be upstreamed to be available for other
downstreams as well.

> >The fourth patch just fixes Zero on Linux sparc. If I understand
> >correctly, Debian's openjdk packages always build the Zero VM even on
> >targets with a native Hotspot. And without the last patch, the Zero
> >build fails on Linux sparc.
> 
> Ah, now I think I get it :) This is for the openjdk-9-jre-zero package,
> right? Does the openjdk-9-jre package provide the "native" (using template
> interpreter, C1, C2) version of hotspot if possible?

>From the description of the -zero package you mentioned:

> The package provides an alternative runtime using the Zero VM and
> the Shark Just In Time Compiler (JIT). Built on architectures in
> addition to the Hotspot VM as a debugging aid for those architectures
> which don't have a Hotspot VM.

> The VM is started with the option `-zero'. See the README.Debian for
> details.

For the -jre-headless package, we have:

> Minimal Java runtime - needed for executing non GUI Java programs,
> using Hotspot JIT.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From glaubitz at physik.fu-berlin.de  Tue Jun 27 13:40:55 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 27 Jun 2017 15:40:55 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170622102703.GC18516@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
 <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>
 <20170619070613.GE28760@physik.fu-berlin.de>
 <c65e8d8e-b400-a42b-8d13-eed77525cde9@oracle.com>
 <20170622102703.GC18516@physik.fu-berlin.de>
Message-ID: <20170627134055.GA30354@physik.fu-berlin.de>

On Thu, Jun 22, 2017 at 12:27:03PM +0200, John Paul Adrian Glaubitz wrote:
> On Mon, Jun 19, 2017 at 02:48:39PM +0200, Erik Helin wrote:
> > >So, should I just run the testsuite with all three patches applied?
> > 
> > Yes, please run the testsuite with the three patches applied. This should
> > work (famous last words ;)) for the "native" Linux/sparc64 version of
> > hotspot (if not, I would to curious to learn why). To test
> > Linux/sparc64+zero you obviously need the fourth patch applied as well.
> 
> Ok, I will give it a try. I will do a hotspot-native build first, run
> the testsuite and post the results. Let's tackle zero later. I've got
> anoter bunch of zero-related fixes that we're carrying in the Debian
> package and that should be upstreamed to be available for other
> downstreams as well.

Here's a build with the patches applied and the testsuite enabled:

> https://people.debian.org/~glaubitz/openjdk-9_9~b170-2_sparc64.build

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Thu Jun 29 10:20:33 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 29 Jun 2017 12:20:33 +0200
Subject: RFR: JDK-8183166: lib\jawt.lib is missing from JDK 9 distribution for
 Windows
Message-ID: <a4cb6f0f-f411-527d-82c3-8418a44ba4af@oracle.com>

The Windows link library jawt.lib is currently missing from 
java.desktop.jmod and linked images. This is caused a mistake in the 
makefile for building jawt. The copy logic for this file was never 
updated when the modular images were introduced, so the file ends up in 
the wrong place and is not picked up by jmod.

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

Webrev: http://cr.openjdk.java.net/~erikj/8183166/webrev.01/

Note that this bug is still waiting on approval for inclusion in JDK 9.

/Erik



From magnus.ihse.bursie at oracle.com  Thu Jun 29 12:25:37 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 29 Jun 2017 14:25:37 +0200
Subject: RFR: JDK-8183166: lib\jawt.lib is missing from JDK 9 distribution
 for Windows
In-Reply-To: <a4cb6f0f-f411-527d-82c3-8418a44ba4af@oracle.com>
References: <a4cb6f0f-f411-527d-82c3-8418a44ba4af@oracle.com>
Message-ID: <5E14D5BA-DEEF-4251-AAC1-0E4BD3F38461@oracle.com>

Looks good to me. 

/Magnus

> 29 juni 2017 kl. 12:20 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> The Windows link library jawt.lib is currently missing from java.desktop.jmod and linked images. This is caused a mistake in the makefile for building jawt. The copy logic for this file was never updated when the modular images were introduced, so the file ends up in the wrong place and is not picked up by jmod.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8183166
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8183166/webrev.01/
> 
> Note that this bug is still waiting on approval for inclusion in JDK 9.
> 
> /Erik
> 



From dalibor.topic at oracle.com  Thu Jun 29 14:42:39 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 29 Jun 2017 16:42:39 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170627134055.GA30354@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170614120408.GB16230@physik.fu-berlin.de>
 <5d613e41-a982-ec67-3a48-5befbf3a2808@physik.fu-berlin.de>
 <31eeeb60-1b0d-a0cb-238c-ca2361430786@oracle.com>
 <20170619070613.GE28760@physik.fu-berlin.de>
 <c65e8d8e-b400-a42b-8d13-eed77525cde9@oracle.com>
 <20170622102703.GC18516@physik.fu-berlin.de>
 <20170627134055.GA30354@physik.fu-berlin.de>
Message-ID: <84b21e57-fbf7-750f-49c3-a26ec3f7da1b@oracle.com>

On 27.06.2017 15:40, John Paul Adrian Glaubitz wrote:

> Here's a build with the patches applied and the testsuite enabled:
> 
>> https://people.debian.org/~glaubitz/openjdk-9_9~b170-2_sparc64.build

For comparison it can be useful to keep an eye on 
http://download.java.net/openjdk/testresults/9/testresults.html . New 
test results for EA builds are announced on quality-discuss mailing list.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From rohitvvv at gmail.com  Thu Jun 29 16:09:12 2017
From: rohitvvv at gmail.com (Rohit Vaidya)
Date: Thu, 29 Jun 2017 21:39:12 +0530
Subject: Build failing on Mac OS X 10.12.5
In-Reply-To: <CAPFUtmS_piNV995w56PHaoW=+PAu7aK+8JtB9RpV5GurEipsYg@mail.gmail.com>
References: <CAPFUtmS_piNV995w56PHaoW=+PAu7aK+8JtB9RpV5GurEipsYg@mail.gmail.com>
Message-ID: <CAPFUtmQ=opRg=p7ubsbz7H_jV0DODH4u0GL10qiZ0q2ekCfTGA@mail.gmail.com>

A gentle reminder experts. I found something similar issue posted here
https://community.oracle.com/thread/4038913


On Sun, Jun 18, 2017 at 12:49 AM, Rohit Vaidya <rohitvvv at gmail.com> wrote:

> Hello Experts,
>
> I was running a fresh JDK 9 build on Mac OS Sierra 10.12.5.
> "$sh configure" fails with freetype dependency. On installing freetype
> with brew it still continues to fail.
>
> configure: error: Could not find freetype! You might be able to fix this
> by running 'brew install freetype'.
>
> /Users/rohitvaidya/Downloads/projects/9dev/common/autoconf/generated-configure.sh:
> line 82: 5: Bad file descriptor
> configure exiting with result code 1
>
> Has anyone faced this before?
> --
> Regards,
> Rohit Vaidya
>



-- 
Regards,
Rohit Vaidya


From erik.joelsson at oracle.com  Fri Jun 30 07:40:57 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 30 Jun 2017 09:40:57 +0200
Subject: Build failing on Mac OS X 10.12.5
In-Reply-To: <CAPFUtmQ=opRg=p7ubsbz7H_jV0DODH4u0GL10qiZ0q2ekCfTGA@mail.gmail.com>
References: <CAPFUtmS_piNV995w56PHaoW=+PAu7aK+8JtB9RpV5GurEipsYg@mail.gmail.com>
 <CAPFUtmQ=opRg=p7ubsbz7H_jV0DODH4u0GL10qiZ0q2ekCfTGA@mail.gmail.com>
Message-ID: <34e325fe-52bc-25a1-eaf2-e503b49028ab@oracle.com>

I think configure is looking for freetype in the wrong place on newer 
Macosx. You will need to point it out explicitly using a combination of 
--with-freetype* arguments.

The "Bad file descriptor" error is benign IIRC, but happens a lot on mac.

/Erik

On 2017-06-29 18:09, Rohit Vaidya wrote:
> A gentle reminder experts. I found something similar issue posted here
> https://community.oracle.com/thread/4038913
>
>
> On Sun, Jun 18, 2017 at 12:49 AM, Rohit Vaidya <rohitvvv at gmail.com> wrote:
>
>> Hello Experts,
>>
>> I was running a fresh JDK 9 build on Mac OS Sierra 10.12.5.
>> "$sh configure" fails with freetype dependency. On installing freetype
>> with brew it still continues to fail.
>>
>> configure: error: Could not find freetype! You might be able to fix this
>> by running 'brew install freetype'.
>>
>> /Users/rohitvaidya/Downloads/projects/9dev/common/autoconf/generated-configure.sh:
>> line 82: 5: Bad file descriptor
>> configure exiting with result code 1
>>
>> Has anyone faced this before?
>> --
>> Regards,
>> Rohit Vaidya
>>
>
>



From stuart.monteith at linaro.org  Fri Jun 30 14:32:57 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 30 Jun 2017 15:32:57 +0100
Subject: RFR: JDK-8179892 Update build documentation for JDK 9
In-Reply-To: <CA+3eh13NaK697Yv2N9LOOyphvS++nFn96-K4z163NB_vm7KQ0A@mail.gmail.com>
References: <ad72d4c1-e6f9-37d7-513b-a59e1ea52070@oracle.com>
 <CAA-vtUzKKSq=2_iuzKKnb7MUgqUxFh1kqOkaLvXtSuUTvy83Vg@mail.gmail.com>
 <6019db3a-e9e7-9d00-3d8d-ddf11befc2a9@oracle.com>
 <CA+3eh13NaK697Yv2N9LOOyphvS++nFn96-K4z163NB_vm7KQ0A@mail.gmail.com>
Message-ID: <CAEGA6kZXc5UK1nEYdiqqYpyw2ocJ_L2+ZSMAg6xZYp1FVhD=mw@mail.gmail.com>

Hi,
   It's good to see updated documentation - a project always feels a
bit stale if its documentation is out of date. However, I'd appreciate
it if Derek White's issue could be addressed:

"JDK-8182733: aarch64 build documentation misleading"
https://bugs.openjdk.java.net/browse/JDK-8182733

OpenJDK builds perfectly fine on AArch64 machines natively.

I don't think you need to make a specific recommendation for AArch64,
although my smallest machine has 8 cores and 16 GB, while, I'd guess
that the SPARC minimum requirements ought to be sufficient, I'd go
with that.

Thanks,
    Stuart


On 22 June 2017 at 10:31, Volker Simonis <volker.simonis at gmail.com> wrote:
> On Wed, Jun 21, 2017 at 12:59 PM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2017-06-21 09:02, Thomas St?fe wrote:
>>>
>>> Hi Magnus,
>>>
>>> excellent work!
>>
>>
>> Thank you! :-)
>>
>>> Some minor remarks:
>>>
>>> You also mentioned Cygwin hg in the "Special considerations" section.
>>> However, because updating Cygwin is a bit of a pain (you need to close all
>>> consoles to do this) it may make sense to move the "Install Cygwin and all
>>> required packages" up to the beginning of the document and include
>>> "mercurial" in the list of cygwin packages to install.
>>>
>>> In addition to that (if contributing to the OpenJDK is in the scope for
>>> this document?) it may make sense to install at least ksh (for webrevs) and
>>> sftp (for uploading webrevs) for Cygwin.
>>
>>
>> For JDK 10, we can discuss where to draw the line of the responsibility of
>> this document. I don't think it can cover all OpenJDK developer stories,
>> like webrev, etc. But we should probably make sure that such a document
>> exists somewhere, in the repo or on the OpenJDK web site or wiki.
>>
>> I've tried putting information about what to install and how grouped to the
>> specific requirements. This has both drawbacks and benefits. One thing you
>> don't get is a "one stop" description of "install all these packages". That
>> could perhaps be added to the TL;DR section -- if you just want something
>> quick that is likely to work, and you don't care why, or if you install
>> slightly too much.
>>
>>> As for AIX, so far we have not yet broken compatibility with AIX 5.3.
>>> While this is something which we may give up in the future, currently
>>> jdk9/10 still build and run on AIX 5.3 and 6.1.
>>
>>
>> Ok, I updated the document to include this information.
>>
>>> I think we can flesh out this section a lot. We will discuss this in our
>>> team.
>>
>>
>> That sounds great! I realize the AIX part was a bit thin, but at least it is
>> mentioned, as compared to the old document. :)
>>
>> I'm leaving for vacation now, but I'll be happy to discuss with you and your
>> team how to improve the documentation for AIX/PPC in JDK 10.
>>
>
> Great stuff Magnus!
>
> Happy midsummer and happy holidays :)
>
>> /Magnus
>>
>>>
>>> Kind Regards, Thomas
>>>
>>>
>>> On Wed, Jun 21, 2017 at 2:46 AM, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>>> wrote:
>>>
>>>     Also known as: "!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this
>>>     document. !!!!!!!!!!!!!" :-)
>>>
>>>     The build documentation has been in need of an overhaul for a very
>>>     long time. The document is not very well structured, and contains
>>>     not only outdated but also irrelevant information, all the while
>>>     valuable information is missing.
>>>
>>>     For some time now, I've worked as a background project to rewrite
>>>     the build documentation to address these shortcomings. Now it's
>>>     finally done.
>>>
>>>     Here is the new documentation in html format:
>>>
>>> http://cr.openjdk.java.net/~ihse/demo-new-build-readme/common/doc/building.html
>>>
>>> <http://cr.openjdk.java.net/%7Eihse/demo-new-build-readme/common/doc/building.html>
>>>
>>>     And here it is in markdown:
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md
>>>
>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8179892-update-build-readme/webrev.01/raw_files/new/common/doc/building.md>
>>>
>>>     I've tried to make the document as readable as possible in raw
>>>     markdown, hoping it can be of assistance for command-line users.
>>>
>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8179892
>>>     <https://bugs.openjdk.java.net/browse/JDK-8179892>
>>>     WebRev:
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8179892-update-build-readme/webrev.01
>>>
>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8179892-update-build-readme/webrev.01>
>>>
>>>     /Magnus
>>>
>>>
>>


From michel.trudeau at oracle.com  Fri Jun 30 15:07:59 2017
From: michel.trudeau at oracle.com (Michel Trudeau)
Date: Fri, 30 Jun 2017 08:07:59 -0700
Subject: Build failing on Mac OS X 10.12.5
In-Reply-To: <34e325fe-52bc-25a1-eaf2-e503b49028ab@oracle.com>
References: <CAPFUtmS_piNV995w56PHaoW=+PAu7aK+8JtB9RpV5GurEipsYg@mail.gmail.com>
 <CAPFUtmQ=opRg=p7ubsbz7H_jV0DODH4u0GL10qiZ0q2ekCfTGA@mail.gmail.com>
 <34e325fe-52bc-25a1-eaf2-e503b49028ab@oracle.com>
Message-ID: <5956694F.4070609@oracle.com>

I am on 10.12.5 and this is what I use as a configure command to build 
jdk 10 successfully.

bash configure --with-freetype-include=/usr/X11/include/freetype2 
--with-freetype-lib=/usr/X11/lib 
--with-boot-jdk=/Users/micheltrudeau/java/jdk9/b167 
--disable-warnings-as-errors

-- 
Thanks,
Michel



> Erik Joelsson <mailto:erik.joelsson at oracle.com>
> June 30, 2017 at 12:40 AM
> I think configure is looking for freetype in the wrong place on newer 
> Macosx. You will need to point it out explicitly using a combination 
> of --with-freetype* arguments.
>
> The "Bad file descriptor" error is benign IIRC, but happens a lot on mac.
>
> /Erik
>
>
>
> Rohit Vaidya <mailto:rohitvvv at gmail.com>
> June 29, 2017 at 9:09 AM
> A gentle reminder experts. I found something similar issue posted here
> https://community.oracle.com/thread/4038913
>
>
>
>
>
> Rohit Vaidya <mailto:rohitvvv at gmail.com>
> June 17, 2017 at 12:19 PM
> Hello Experts,
>
> I was running a fresh JDK 9 build on Mac OS Sierra 10.12.5.
> "$sh configure" fails with freetype dependency. On installing freetype 
> with
> brew it still continues to fail.
>
> configure: error: Could not find freetype! You might be able to fix 
> this by
> running 'brew install freetype'.
>
> /Users/rohitvaidya/Downloads/projects/9dev/common/autoconf/generated-configure.sh:
> line 82: 5: Bad file descriptor
> configure exiting with result code 1
>
> Has anyone faced this before?



From mark.reinhold at oracle.com  Fri Jun 30 21:36:08 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 30 Jun 2017 14:36:08 -0700 (PDT)
Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes
Message-ID: <20170630213608.0A5718091A@eggemoggin.niobe.net>

8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules
8183161: Remove extraneous font-family style attributes from module declarations
8183251: Meta "keywords" tag malformed in overview-summary.html and related pages

http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)

None of these is truly P1 but they're all fairly embarrassing and the
fixes are low-risk, so since we know we're going to do another build next
week anyway I'd like to include this patch.

The fix for 8183251 doesn't solve the problem of `<div>` occurring inside
`<h1>`, but this only ever happens in the frame-summary pages and appears
to do no harm when rendered.

This patch includes a few minor editorial fixes, e.g., changing `@link`
tags to `@linkplain` where appropriate in module declarations.

Thanks,
- Mark


From jonathan.gibbons at oracle.com  Fri Jun 30 23:08:09 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 30 Jun 2017 16:08:09 -0700
Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes
In-Reply-To: <20170630213608.0A5718091A@eggemoggin.niobe.net>
References: <20170630213608.0A5718091A@eggemoggin.niobe.net>
Message-ID: <5956D9D9.1010104@oracle.com>

Mark,

The font-family settings in the <dl> nodes were deliberate, and a 
workaround for not having time to create a proper taglet for tool guides.

If you remove the style attribute, you'll see in your sample output that 
the "Tool Guides" header is in Serif font, but the immediately following 
"Since: "  header is in the standard Sans Serif font.

See, for example, this page:
http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html

And for those that can see images in line:

Screnshot of mismatched header fonts

The screenshot has also been attached to the appropriate bug: JDK-8183161

I would recommend that JDK-8183161 should be "Not An Issue" and the 
changes reverted in the proposed patch.

-- Jon

On 06/30/2017 02:36 PM, mark.reinhold at oracle.com wrote:
> 8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules
> 8183161: Remove extraneous font-family style attributes from module declarations
> 8183251: Meta "keywords" tag malformed in overview-summary.html and related pages
>
> http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
> http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)
>
> None of these is truly P1 but they're all fairly embarrassing and the
> fixes are low-risk, so since we know we're going to do another build next
> week anyway I'd like to include this patch.
>
> The fix for 8183251 doesn't solve the problem of `<div>` occurring inside
> `<h1>`, but this only ever happens in the frame-summary pages and appears
> to do no harm when rendered.
>
> This patch includes a few minor editorial fixes, e.g., changing `@link`
> tags to `@linkplain` where appropriate in module declarations.
>
> Thanks,
> - Mark