Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

[Erik Joelsson]

Much better, and thank you for fixing the existing mkdir/echo lines too. 
Just one nit, for this continuation:


$(TOOL_CACERTSHASHER) -i $(GENDATA_CACERTSHASHER_IN) \
 -o $(GENDATA_CACERTSHASHER)

please use tab+4spaces for the second line. No need to resend webrev for 
that. See [1] for our build system code conventions.


[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

/Erik

On 2016-03-18 18:09, Anthony Scarpino wrote:

I believe I got everyone's comments. I've updated the webrev.

http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/

Thanks

Tony


On 02/29/2016 08:55 AM, Anthony Scarpino wrote:

Currently CertPath algorithm restrictions allow or deny all
certificates.  This change adds the ability to reject certificate chains
that contain a restricted algorithm and the chain terminates at a root
CA; therefore, allowing a self-signed or chain that does not terminate
at a root CA.

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

Thanks

Tony

Re: RFR: 8151841: Build needs additional flags to compile with GCC 6

[Erik Joelsson]

Looks good to me.

/Erik

On 2016-03-18 05:42, Andrew Hughes wrote:


- Original Message -

On 2016-03-16 05:25, Andrew Hughes wrote:

- Original Message -

Hello,

As representative for the build-infra group creating the new Hotspot
build, I appreciate that the changes are made in configure. That will at
least automatically force me to merge them correctly when they hit the
build-infra forest and will make the merge easier. The idea is to start
getting the new Hotspot build in soon after Jigsaw M3 is integrated. If
the GCC 6 changes get in soon enough in jdk9/dev I will be able to merge
and convert in time.


When is M3 due to happen? I couldn't see anything regarding the milestones
on http://openjdk.java.net/projects/jdk9/. Hopefully we can get this change
in this week.

See http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html


Ah ok, I think I did see this mail.


If you get in this week, it should be fine.

I like the refactoring of the FLAGS_COMPILER_CHECK_ARGUMENTS. Disabling
optimizations that have obviously worked fine for a long time doesn't
seem like a good idea though. I would prefer putting a conditional on
the GCC version in those cases, but still keep the proposed flag check
as well. There should be a toolchain version variable to compare
against.

I agree that will lower the potential impact of this change. I've
added:

+TOOLCHAIN_CHECK_COMPILER_VERSION(VERSION: 6, IF_AT_LEAST:
FLAGS_SETUP_GCC6_COMPILER_FLAGS)

and moved the -fno-lifetime-dse and -fno-delete-null-pointer-checks
into this new macro, FLAGS_SETUP_GCC6_COMPILER_FLAGS. I'll post the
revised version once I've done more testing with GCC 6. With GCC 5.3,
I can confirm the tests and additions are gone with this change.

Nice, I haven't kept up to date with the recent improvements Magnus made
to configure here. That macro made the change very simple.

Yes, I was glad to find this. It will mean that chunks of these
earlier changesets will also need to be backported for 8u though.


/Erik

Here's the revised webrev:

http://cr.openjdk.java.net/~andrew/8151841/webrev.02/

Changes:

1. GCC 6 check added as mentioned earlier. The two optimisation flags
are now handled in a GCC 6 macro, FLAGS_SETUP_GCC6_COMPILER_FLAGS.
2. Copyright updated in hotspot-spec.gmk.in
3. Line break added in hotspot-spec.gmk.in
4. Typos fixed in toolchain.m4
5. Version number regular expression updated in toolchain.m4. The
previous version expected the version number to always be followed
by a space i.e. "x.y.z " which is not true for some pre-release
versions (e.g. Gentoo's GCC 6 reports 6.0.0-alpha20160306) so instead
it now matches the first character that is not a number or a '.'.
It works as before with released versions.

This should fix all concerns raised so far. Tested on both
GCC 5.3.0 and 6.0.0 successfully.

Incidentally, it may be worth sanity-checking COMPILER_VERSION_NUMBER
as, when it was mis-parsed, configure still carried on, with it set
to the entire first line of the version output, thus causing the later
version tests to return incorrect results.

Thanks,

Re: RFR(XS): 8151987: jexec should be executable

[Volker Simonis]

On Wed, Mar 16, 2016 at 12:29 PM, Volker Simonis 
wrote:

>
>
> On Wed, Mar 16, 2016 at 12:14 PM, Alan Bateman 
> wrote:
>
>> On 16/03/2016 11:08, Volker Simonis wrote:
>>
>>> Hi,
>>>
>>> can I please have a review for the following small fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8151987/
>>> https://bugs.openjdk.java.net/browse/JDK-8151987
>>>
>>> 'jexec' is currently not executable in the created images (i.e.
>>> images/{jdk,jre}/lib/jexec.
>>>
>>> There is currently a special handling in ImageBuilder for
>>> 'jspawnhelper' which apparently had the same problem.
>>>
>>> Volker - this patches the temporary image builder that we have in JDK 9.
>> This will be go away, to be replaced by jlink, when we bring the module
>> system into JDK 9. This will hopefully be next week.
>>
>>
> OK, but then we will have to fix jlink. I've just verified that a 'jake'
> build from last week has the same problem:
>
> la ../output-jake-opt/images/jdk/lib/jexec
> -rw-r--r-- 1 d00 kmem 22034 Mar  7 15:02
> ../output-jake-opt/images/jdk/lib/jexec
>
>
>
So here comes a new (and even smaller) version of the patch which fixes
jlink in the same way:

http://cr.openjdk.java.net/~simonis/webrevs/2016/8151987.v1/

Please feel free to push it to jake or I can push it to jdk9-dev once jake
is there.

Regards,
Volker




>
>
-Alan.
>>
>
>

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

[Anthony Scarpino]

I believe I got everyone's comments. I've updated the webrev.

http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/

Thanks

Tony


On 02/29/2016 08:55 AM, Anthony Scarpino wrote:

Currently CertPath algorithm restrictions allow or deny all
certificates.  This change adds the ability to reject certificate chains
that contain a restricted algorithm and the chain terminates at a root
CA; therefore, allowing a self-signed or chain that does not terminate
at a root CA.

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

Thanks

Tony

Errors building on OSX 10.8.5

[Lance Andersen]

While I plan to upgrade this week to El Capitan from 10.8.5, it looks like the 
build now requires a more current version of OSX than it did a few weeks ago 
based on the error I am seeing  after updating my  jdk9  workspace today before 
the jake integration.

I assume I am out of luck until i get off the bench and upgrade OSX  now (which 
is more motivation :-) )?  

p.s.  Was there an email I might have missed on this change (I know I was 
probably lucky before)


-

ljanders-mac:modular-dev ljanders$ make all
Building target 'all' in configuration 'macosx-x86_64-normal-server-release'
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jdk/src/java.desktop/macosx/native/libosx/CFileManager.m:225:25:
 error: 'trashItemAtURL:resultingItemURL:error:' is unavailable
returnValue  = [[NSFileManager defaultManager] trashItemAtURL:url
^
/System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:162:1: 
note: declaration has been explicitly marked unavailable here
- (BOOL)trashItemAtURL:(NSURL *)url resultingItemURL:(NSURL **)outResultingURL 
error:(NSError **)error NS_AVAILABLE_MAC(10_8);
^
1 error generated.
make[3]: *** 
[/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/native/java.desktop/libosx/CFileManager.o]
 Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [java.desktop-libs] Error 2
make[2]: *** Waiting for unfinished jobs
Compiling 775 files for jdk.xml.bind
Starting server. Command: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java -d64 
-Xms512M -Xmx2048M 
-Xbootclasspath/p:/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar
 -cp 
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar
 com.sun.tools.sjavac.Main 
--startserver:portfile=/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/make-support/javacservers/server.port,poolsize=8,keepalive=120
Trying to connect. Attempt 1 of 3
Connected
Compiling 1226 files for java.xml.ws
Trying to connect. Attempt 1 of 3
Connected
[server] Note: Some input files use or override a deprecated API.
[server] Note: Recompile with -Xlint:deprecation for details.
[server] Note: Some input files use unchecked or unsafe operations.
[server] Note: Recompile with -Xlint:unchecked for details.
[server] Note: Some input files use or override a deprecated API.
[server] Note: Recompile with -Xlint:deprecation for details.
[server] Note: Some input files use unchecked or unsafe operations.
[server] Note: Recompile with -Xlint:unchecked for details.

ERROR: Build failed for target 'all' in configuration 
'macosx-x86_64-normal-server-release' (exit code 2) 
=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libosx_CFileManager.o:
/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/jdk/src/java.desktop/macosx/native/libosx/CFileManager.m:225:25:
 error: 'trashItemAtURL:resultingItemURL:error:' is unavailable
returnValue  = [[NSFileManager defaultManager] trashItemAtURL:url
^
/System/Library/Frameworks/Foundation.framework/Headers/NSFileManager.h:162:1: 
note: declaration has been explicitly marked unavailable here
- (BOOL)trashItemAtURL:(NSURL *)url resultingItemURL:(NSURL **)outResultingURL 
error:(NSError **)error NS_AVAILABLE_MAC(10_8);
^
1 error generated.
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.

make[1]: *** [main] Error 2
make: *** [all] Error 2
ljanders-mac:modular-dev ljanders$ 








Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8151841: Build needs additional flags to compile with GCC 6

[Andrew Hughes]

- Original Message -
> Looks good to me.
> 
> /Erik
> 

Thanks. Pushed:

http://hg.openjdk.java.net/jdk9/dev/rev/9d77f922d694
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Re: RFR(XS): 8151987: jexec should be executable

[Alan Bateman]

On 16/03/2016 12:19, Volker Simonis wrote:



So here comes a new (and even smaller) version of the patch which 
fixes jlink in the same way:


http://cr.openjdk.java.net/~simonis/webrevs/2016/8151987.v1/ 



Please feel free to push it to jake or I can push it to jdk9-dev once 
jake is there.

Sure, I can get this into jake today.

-Alan

Re: RFR: JDK-8151973: Add Jib and JPRT configuration for linux-arm64 open only

[David Holmes]

Erik,

On 16/03/2016 8:10 PM, Erik Joelsson wrote:

Hello,

Since we have a community supported Linux aarch64 port, I would like to
be able to build it using Jib and JPRT, specifically as part of the new
buildinfra testset.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151973
Webrev: http://cr.openjdk.java.net/~erikj/JDK-8151973/webrev.01/


The open aarch64 port uses a native build, not cross-compilation.

David


/Erik

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

[Anthony Scarpino]

Ok..  thanks.. I'll make those changes..

Tony

On 03/12/2016 07:37 AM, Erik Joelsson wrote:

Hello Anthony,

I realize you followed the patterns already in the file and we
apparently haven't updated that file to follow latest standards. I would
like you to change the following:

 $(ECHO) foo

should be

 $(call LogInfo, foo)

and

 $(MKDIR) -p foo

should be

 $(call MakeDir, foo)

I also don't know what the "|| exit 1" is good for. I think it should
just be removed.

Finally for indentation, in recipes we recommend:

some command with arguments \
<4 spaces>some more arguments

Otherwise it looks good.

/Erik

On 2016-03-11 22:43, Anthony Scarpino wrote:


I updated the webrev and added the build-dev list as there are two
makefile changes.

http://cr.openjdk.java.net/~ascarpino/8140422/webrev.01/

thanks

Tony

On 02/29/2016 08:55 AM, Anthony Scarpino wrote:

I need a code review of this change:

Currently CertPath algorithm restrictions allow or deny all
certificates.  This change adds the ability to reject certificate chains
that contain a restricted algorithm and the chain terminates at a root
CA; therefore, allowing a self-signed or chain that does not terminate
at a root CA.

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

Re: RFR: JDK-8151656: Minor tweaks to old Hotspot build to ease comparison with new

[Christian Thalinger]

> On Mar 15, 2016, at 10:51 PM, Erik Joelsson  wrote:
> 
> The __FILE__ macro is built into the compiler and evaluates to the file name 
> of the current source file. It's intended use is for debug messages. In the 
> rest of the JDK we eliminated its use completely by providing a macro called 
> THIS_FILE that evaluates to the basename.ext of the source file being 
> compiled. In Hotspot it's still used and it's used in header files, which 
> makes the THIS_FILE solution invalid.
> 
> For most of our compilers, the format of the path is based on how the file 
> was presented on the command line. This matters to us since the old Hotspot 
> build uses relative paths to the generated source and header files and the 
> new build uses absolute paths for all source files. Also, the directory 
> structure in the output directory differ. This means that for certain object 
> files, the constant strings resulting from the use of __FILE__ differ, both 
> in contents and length. The difference in length causes alignment differences 
> in the objects and the resulting libraries.

This is actually a very good point.  Alignment differences can cause 
performance differences.  Sometimes hard to track down and almost impossible to 
reproduce.

> 
> When creating the new build, we are trying very hard to make sure we are 
> still building the same thing. One way to verify this is to compare various 
> aspects of the built binaries. When possible, this is far easier than running 
> a very large amount of tests and it gives us a large amount of confidence in 
> our changes. The alignment differences caused by different lengths of 
> constant strings severely limits the amount of clean comparisons we can do.
> 
> The particular fix here changes how we generate the files from the ADLC tool. 
> The tool already generates #line directives which helps the compiler figure 
> out which actual source file and line parts of the generated files came from. 
> Basically overriding what __FILE__ and __LINE__ will evaluate to. Some of 
> these lines need a bit of post processing, and for that, the build already 
> uses awk to rewrite them. The current awk script looks for lines like this, 
> which the ADLC tool prints when it doesn't know the correct source file:
> 
> #line 99
> 
> and rewrites it to
> 
> #line   file>
> 
> I changed this to instead rewrite to:
> 
> #line  

You removed the +1.  Why was it used in the first place?

> 
> I also added an initial #line first in each file.
> 
> #line 1 
> 
> With these changes, we can do very clean comparisons on Linux, Solaris and 
> Macosx. This helps the new hotspot build immensely, but will also be good in 
> the future as we have a very convenient way of verifying build changes that 
> shouldn't affect the built output.

Now this all makes sense.  Thanks.  The change looks good to me.

> 
> /Erik
> 
> On 2016-03-15 22:02, Christian Thalinger wrote:
>>> On Mar 15, 2016, at 12:06 AM, Erik Joelsson  
>>> wrote:
>>> 
>>> Any chance I could get a second review on this? Preferably from the hotspot 
>>> team.
>> It’s not quite obvious to me what the __FILE__ change is.  Maybe an example 
>> would help.
>> 
>>> /Erik
>>> 
>>> On 2016-03-11 18:16, Erik Joelsson wrote:
 In preparation for the new Hotspot build, there are a few changes to the 
 old build that needs to happen first. These changes should be harmless, 
 but do impact the generated binaries some. These changes are:
 
 * Standardizing sort order for objects on link command line on Windows to 
 a locale independent order.
 * Working around compare differences caused by the __FILE__ macro in 
 certain generated files by overriding the value of __FILE__ in those files.
 
 By making these changes first and separate from introducing the new build 
 we reduce the potential impact of when we do introduce the new build.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8151656
 Webrev: http://cr.openjdk.java.net/~erikj/8151656/index.html
 
 /Erik
> 

Re: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

[Anthony Scarpino]

ok.. thanks

Tony

On 03/18/2016 10:27 AM, Erik Joelsson wrote:

Much better, and thank you for fixing the existing mkdir/echo lines too.
Just one nit, for this continuation:

 $(TOOL_CACERTSHASHER) -i $(GENDATA_CACERTSHASHER_IN) \
  -o $(GENDATA_CACERTSHASHER)

please use tab+4spaces for the second line. No need to resend webrev for
that. See [1] for our build system code conventions.

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

/Erik

On 2016-03-18 18:09, Anthony Scarpino wrote:

I believe I got everyone's comments. I've updated the webrev.

http://cr.openjdk.java.net/~ascarpino/8140422/webrev.02/

Thanks

Tony


On 02/29/2016 08:55 AM, Anthony Scarpino wrote:

Currently CertPath algorithm restrictions allow or deny all
certificates.  This change adds the ability to reject certificate chains
that contain a restricted algorithm and the chain terminates at a root
CA; therefore, allowing a self-signed or chain that does not terminate
at a root CA.

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

Thanks

Tony

Re: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc

[Phil Race]

+1

-phil.

On 02/15/2016 01:02 AM, Erik Joelsson wrote:

Looks good.
/Erik

On 2016-02-12 10:15, Seán Coffey wrote:

Approved for jdk8u-dev once you have a peer code review.

Regards,
Sean.

On 12/02/2016 08:19, Alexey Ivanov wrote:

I forgot to add jdk8u-dev list...

On 11.02.2016 17:19, Alexey Ivanov wrote:

Hello,

Could you please review the fix for JDK-8147807 and approve push to 
8u-dev?


JBS: https://bugs.openjdk.java.net/browse/JDK-8147807
Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/

The issue is not relevant to jdk 9.

The fix just removes kcms service leaving lcms as the only option 
which is the default in jdk8.



Thanks in advance,
Alexey

Re: RFR: 8151841: Build needs additional flags to compile with GCC 6

[Andrew Hughes]

- Original Message -
> On 2016-03-16 05:25, Andrew Hughes wrote:
> > - Original Message -
> >> Hello,
> >>
> >> As representative for the build-infra group creating the new Hotspot
> >> build, I appreciate that the changes are made in configure. That will at
> >> least automatically force me to merge them correctly when they hit the
> >> build-infra forest and will make the merge easier. The idea is to start
> >> getting the new Hotspot build in soon after Jigsaw M3 is integrated. If
> >> the GCC 6 changes get in soon enough in jdk9/dev I will be able to merge
> >> and convert in time.
> >>
> > When is M3 due to happen? I couldn't see anything regarding the milestones
> > on http://openjdk.java.net/projects/jdk9/. Hopefully we can get this change
> > in this week.
> See http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html
> 

Ah ok, I think I did see this mail.

> If you get in this week, it should be fine.
> >> I like the refactoring of the FLAGS_COMPILER_CHECK_ARGUMENTS. Disabling
> >> optimizations that have obviously worked fine for a long time doesn't
> >> seem like a good idea though. I would prefer putting a conditional on
> >> the GCC version in those cases, but still keep the proposed flag check
> >> as well. There should be a toolchain version variable to compare
> >> against.
> > I agree that will lower the potential impact of this change. I've
> > added:
> >
> > +TOOLCHAIN_CHECK_COMPILER_VERSION(VERSION: 6, IF_AT_LEAST:
> > FLAGS_SETUP_GCC6_COMPILER_FLAGS)
> >
> > and moved the -fno-lifetime-dse and -fno-delete-null-pointer-checks
> > into this new macro, FLAGS_SETUP_GCC6_COMPILER_FLAGS. I'll post the
> > revised version once I've done more testing with GCC 6. With GCC 5.3,
> > I can confirm the tests and additions are gone with this change.
> Nice, I haven't kept up to date with the recent improvements Magnus made
> to configure here. That macro made the change very simple.

Yes, I was glad to find this. It will mean that chunks of these
earlier changesets will also need to be backported for 8u though.

> 
> /Erik

Here's the revised webrev:

http://cr.openjdk.java.net/~andrew/8151841/webrev.02/

Changes:

1. GCC 6 check added as mentioned earlier. The two optimisation flags
are now handled in a GCC 6 macro, FLAGS_SETUP_GCC6_COMPILER_FLAGS.
2. Copyright updated in hotspot-spec.gmk.in
3. Line break added in hotspot-spec.gmk.in
4. Typos fixed in toolchain.m4
5. Version number regular expression updated in toolchain.m4. The
previous version expected the version number to always be followed
by a space i.e. "x.y.z " which is not true for some pre-release
versions (e.g. Gentoo's GCC 6 reports 6.0.0-alpha20160306) so instead
it now matches the first character that is not a number or a '.'.
It works as before with released versions.

This should fix all concerns raised so far. Tested on both
GCC 5.3.0 and 6.0.0 successfully.

Incidentally, it may be worth sanity-checking COMPILER_VERSION_NUMBER
as, when it was mis-parsed, configure still carried on, with it set
to the entire first line of the version output, thus causing the later
version tests to return incorrect results.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222