Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[Thomas Stüfe]

Thank you, Eric!

On Thu, Dec 17, 2015 at 8:58 AM, Erik Joelsson 
wrote:

> I only got a bug report for Linux and can't test AIX. A quick look at the
> makefiles for AIX, I think you are probably fine. At least the weird
> construct in the Linux makefiles is not there to mess things up.
>
> /Erik
>
>
> On 2015-12-17 07:49, Thomas Stüfe wrote:
>
> Hi Eric,
>
> short question, are other platforms beside Linux affected or is this
> Linux-specific (I saw you said Windows x64 showed no regression)?
>
> Reason I ask is, we just changed the default for AIX to "internal" because
> this is the only configuration we support and the build was broken after  
> JDK-8036003
> (see   
> https://bugs.openjdk.java.net/browse/JDK-8145560)
>
> Kind Regards, Thomas
>
>
> On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson 
> wrote:
>
>> Hello,
>>
>> Please review this quick fix for the build issue introduced in Hotspot by
>> JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when
>> building Hotspot fastdebug, you essentially get a slowdebug build. For an
>> explanation of why, see comment in bug. This behavior is of course also a
>> bug, but not something I will address in this quick fix.
>>
>> What happened in JDK-8036003 was that a new configure API for controlling
>> debug symbols was introduced. The two main settings of this new parameter,
>> --with-native-debug-symbols, that we use internally at Oracle are
>> "external" and "zipped". It was important to us that the behavior of these
>> did not change with JDK-8036003, but exactly that did happen, because both
>> of these settings now cause DEBUG_BINARIES=true to be set. This variable
>> has never been set by configure before and because of the above weird
>> behavior in the Hotspot makefiles, we are having problems.
>>
>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or
>> "zipped". It can remain true for "internal" since Oracle never builds it
>> that way, and I understand those that requested this new configure
>> parameter were setting DEBUG_BINARIES=true as a workaround before this
>> anyway, so they should be fine with the broken fastdebug behavior for a
>> while more. I will file a follow up bug to properly clean up this mess, but
>> it will take some more time.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>
>> /Erik
>>
>
>
>

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[David Holmes]

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:

One more thing, where should this fix be pushed? Do you need it urgently
in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via 
NativeCompilation.gmk was in any way a problem. I would have expected 
any problems there to be readily seen before this was reviewed and 
pushed. So I'm a bit confused about this.


I'm tempted to say rollback the whole thing rather than hack at it.

And apologies as I'm just about to go offline for a few hours at least.

David
-




We will followup with a more complete fix.

/Erik

Thanks,
David


/Erik

On 2015-12-16 22:34, Erik Joelsson wrote:

Hello,

Please review this quick fix for the build issue introduced in Hotspot
by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
when building Hotspot fastdebug, you essentially get a slowdebug
build. For an explanation of why, see comment in bug. This behavior is
of course also a bug, but not something I will address in this quick
fix.

What happened in JDK-8036003 was that a new configure API for
controlling debug symbols was introduced. The two main settings of
this new parameter, --with-native-debug-symbols, that we use
internally at Oracle are "external" and "zipped". It was important to
us that the behavior of these did not change with JDK-8036003, but
exactly that did happen, because both of these settings now cause
DEBUG_BINARIES=true to be set. This variable has never been set by
configure before and because of the above weird behavior in the
Hotspot makefiles, we are having problems.

My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
or "zipped". It can remain true for "internal" since Oracle never
builds it that way, and I understand those that requested this new
configure parameter were setting DEBUG_BINARIES=true as a workaround
before this anyway, so they should be fine with the broken fastdebug
behavior for a while more. I will file a follow up bug to properly
clean up this mess, but it will take some more time.

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

/Erik

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[Magnus Ihse Bursie]

On 2015-12-17 09:08, David Holmes wrote:

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:
One more thing, where should this fix be pushed? Do you need it 
urgently

in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via 
NativeCompilation.gmk was in any way a problem. I would have expected 
any problems there to be readily seen before this was reviewed and 
pushed. So I'm a bit confused about this.


The changes in NativeCompilation.gmk looked perfectly fine. They turned 
out to trigger a bug (or, at the very least, very unsuspected behavior) 
which was deeply hidden in the hotspot linux makefiles, where setting 
DEBUG_BINARIES did indeed enable the -g flag, but also, as a side 
effect, turned fastdebug builds into slowdebug builds. This was not 
something that we could possibly forsee.




I'm tempted to say rollback the whole thing rather than hack at it.


I don't think there is any compelling reason to rollback the whole 
change. The basic idea is sound. However, we do need to work on how to 
handle the debug symbols "under the hood". This deficit has been known 
for a long time to me and Erik but we have not spent any time on it. 
This change brought the problems up to daylight, and I think that's a 
good thing.


I've started working on JDK-8145596, which will provide a proper 
solution to how we handle debug symbols. It is based on JDK-8036003.


/Magnus




And apologies as I'm just about to go offline for a few hours at least.

David
-




We will followup with a more complete fix.

/Erik

Thanks,
David


/Erik

On 2015-12-16 22:34, Erik Joelsson wrote:

Hello,

Please review this quick fix for the build issue introduced in 
Hotspot
by JDK-8036003. The short story is that if you set 
DEBUG_BINARIES=true

when building Hotspot fastdebug, you essentially get a slowdebug
build. For an explanation of why, see comment in bug. This 
behavior is

of course also a bug, but not something I will address in this quick
fix.

What happened in JDK-8036003 was that a new configure API for
controlling debug symbols was introduced. The two main settings of
this new parameter, --with-native-debug-symbols, that we use
internally at Oracle are "external" and "zipped". It was important to
us that the behavior of these did not change with JDK-8036003, but
exactly that did happen, because both of these settings now cause
DEBUG_BINARIES=true to be set. This variable has never been set by
configure before and because of the above weird behavior in the
Hotspot makefiles, we are having problems.

My proposed quick fix is to not set DEBUG_BINARIES=true for 
"external"

or "zipped". It can remain true for "internal" since Oracle never
builds it that way, and I understand those that requested this new
configure parameter were setting DEBUG_BINARIES=true as a workaround
before this anyway, so they should be fine with the broken fastdebug
behavior for a while more. I will file a follow up bug to properly
clean up this mess, but it will take some more time.

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

/Erik

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[Erik Joelsson]

On 2015-12-17 09:08, David Holmes wrote:

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:
One more thing, where should this fix be pushed? Do you need it 
urgently

in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via 
NativeCompilation.gmk was in any way a problem. I would have expected 
any problems there to be readily seen before this was reviewed and 
pushed. So I'm a bit confused about this.


I didn't follow this particular review closely as Magnus was on it and 
so I had missed the NativeCompilation part. It's true that it is very 
unlikely to be part of the problem described in this bug, but I still 
feel that the safest action at this point is to restore the behavior of 
"external" and "zipped" to what they used to be. Magnus is working on a 
complete fix where debug symbols will be enabled for everything in 
NativeCompilation.

I'm tempted to say rollback the whole thing rather than hack at it.

Rolling back will be much more work for me than submitting this patch. 
There are two changes already that depend on this change. I also don't 
dislike the idea of the new configure parameter.

And apologies as I'm just about to go offline for a few hours at least.

I hope you won't object to me pushing this with just ihse as reviewer. I 
feel this is rather a priority to get fixed.


/Erik

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

I've revised the original webrev based on some feedback received.
   - reverted white space only changes
   - proper copyrights on the new files
   - some hotspot files contained previously removed code

  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.

On 12/11/15 10:15, Gary Adams wrote:
Here's the initial upload of changes that provides support for the ios 
and android ports
for the mobile/dev repos. While there have been some preliminary 
reviews of the code,
there is still more work required before we will look for more 
thorough reviews

and an integration to mobile/jdk9 repos.

  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/


Here's a simple configure script to generate a ios-x86_64 build for use
with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH

bash ../../configure \
--openjdk-target=x86_64-macos-ios \
--with-boot-jdk=$JAVA_HOME \
--disable-warnings-as-errors \
--disable-headful \
--enable-static-build=yes \
--with-jvm-variants=minimal1


Also, tested with i586-macos-ios target for 32 bit
with a locally built --with-freetype 2.6.2.

Re: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build

[Igor Ignatyev]

> On Dec 17, 2015, at 2:10 AM, Kim Barrett  wrote:
> 
> On Dec 16, 2015, at 5:54 PM, Igor Ignatyev  wrote:
>> 
>> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc.
>> here is the new webrev: 
>> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/
> 
> I wonder why the value for WARNINGS_ARE_ERRORS isn't obtained from the
> configure-provided variable CFLAGS_WARNINGS_ARE_ERRORS?
> E.g. something like
> 
>  WARNINGS_ARE_ERRORS ?= $(CFLAGS_WARNINGS_ARE_ERRORS)
> 
> There may be a good reason for that, and thinking about it is probably
> better done as a separate RFE.  Doing so might simplify things by
> allowing the assignment to be moved to some higher level common point.
> [The bsd conditionalization on $(COMPILER_WARNINGS_FATAL) might make
> that hard.  Where does that variable come from?  I haven't looked for
> anything similar elsewhere.]
> 
> --
>  
> make/solaris/makefiles/adlc.make 
>  77   WARNINGS_ARE_ERRORS ?= -w -xwe
> 
> I'm pretty sure "-w" is wrong here, and should be removed.
you are right, I made a typo, it was ‘+w’ before. the new webrev : 
http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/

>  And it's
> not clear why this assignment should be conditional on the compiler
> version.
it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, 
excerpt from Chris’s evaluation:

> Since some of the errors are in system headers we can only disable the "+w 
> -errwarn" on SS11 and below.

RFR: JDK-8145596 Enable debug symbols for all libraries

[Magnus Ihse Bursie]

For historical reasons, the FDS (Full Debug Symbols) project only 
enabled debug symbols for a few select libraries, since this was 
difficult to achieve in the old build. Also, the FDS project never 
enabled debug symbols for macosx on the JDK libraries.


With the new build system, debug symbols come for free for all 
libraries, and we actually have to do extra work to keep them out. :-&


We should just stop doing that. It hurts no-one to have proper debug 
information for all libraries, it might come in helpful, and just doing 
it everywhere would simplify build logic.


This is mainly a build change, but I'm cc:ing the component teams just 
in case.


This patch leverages JDK-8036003, but provides a cleaner implementation 
of this logic in the makefiles. Instead of the vague 
ENABLE_DEBUG_SYMBOLS, I have introduced three clearly defined variables:


COMPILE_WITH_DEBUG_SYMBOLS
COPY_DEBUG_SYMBOLS
ZIP_EXTERNAL_DEBUG_SYMBOLS

The various settings of --with-native-debug-symbols turns these 
variables on/off depending on what we want to achieve, and the makefiles 
check these variables to determine what compiler flags to use, whether 
to run objcopy (or similar) and whether to zip the extracted symbols, 
respectively.


A fourth variable (STRIP_DEBUG_SYMBOLS) is needed to fully complement 
this, but the way we handle stripping is complex in it's own right, and 
I've saved that for a separate patch.


Note that this patch intentionally does not affect the Hotspot build 
system. The variables for the hotspot build is kept unchanged. When the 
new build-infra based hotspot build system arrives, the functionality 
introduced in this patch will be automatically used. Until then, I 
prefer not to mess any more than necessary with the hotspot makefiles.


Bug: https://bugs.openjdk.java.net/browse/JDK-8145596
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8145596-fix-native-debug-symbols-properly/webrev.01


/Magnus

RFR: JDK-8145670: New Solaris devkits are missing gobjcopy

[Erik Joelsson]

Hello,

Please review this minor update to the Solaris devkit which adds 
gobjcopy. New devkits have been built using this and are being deployed.


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

/Erik

Re: RFR: JDK-8145670: New Solaris devkits are missing gobjcopy

[Magnus Ihse Bursie]

On 2015-12-17 14:59, Erik Joelsson wrote:

Hello,

Please review this minor update to the Solaris devkit which adds 
gobjcopy. New devkits have been built using this and are being deployed.


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

/Erik

Looks good to me.

/Magnus

Re: RFR: JDK-8145596 Enable debug symbols for all libraries

[Erik Joelsson]

Looks good to me.

Note that this patch will conflict with the quick fix I did in jdk9/hs, 
so you will need to either wait for my patch, push in a forest that has 
my patch, or make sure the integrator can handle it correctly.


/Erik

On 2015-12-17 14:43, Magnus Ihse Bursie wrote:
For historical reasons, the FDS (Full Debug Symbols) project only 
enabled debug symbols for a few select libraries, since this was 
difficult to achieve in the old build. Also, the FDS project never 
enabled debug symbols for macosx on the JDK libraries.


With the new build system, debug symbols come for free for all 
libraries, and we actually have to do extra work to keep them out. :-&


We should just stop doing that. It hurts no-one to have proper debug 
information for all libraries, it might come in helpful, and just 
doing it everywhere would simplify build logic.


This is mainly a build change, but I'm cc:ing the component teams just 
in case.


This patch leverages JDK-8036003, but provides a cleaner 
implementation of this logic in the makefiles. Instead of the vague 
ENABLE_DEBUG_SYMBOLS, I have introduced three clearly defined variables:


COMPILE_WITH_DEBUG_SYMBOLS
COPY_DEBUG_SYMBOLS
ZIP_EXTERNAL_DEBUG_SYMBOLS

The various settings of --with-native-debug-symbols turns these 
variables on/off depending on what we want to achieve, and the 
makefiles check these variables to determine what compiler flags to 
use, whether to run objcopy (or similar) and whether to zip the 
extracted symbols, respectively.


A fourth variable (STRIP_DEBUG_SYMBOLS) is needed to fully complement 
this, but the way we handle stripping is complex in it's own right, 
and I've saved that for a separate patch.


Note that this patch intentionally does not affect the Hotspot build 
system. The variables for the hotspot build is kept unchanged. When 
the new build-infra based hotspot build system arrives, the 
functionality introduced in this patch will be automatically used. 
Until then, I prefer not to mess any more than necessary with the 
hotspot makefiles.


Bug: https://bugs.openjdk.java.net/browse/JDK-8145596
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8145596-fix-native-debug-symbols-properly/webrev.01


/Magnus

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[Daniel D. Daugherty]

DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only
affects Linux (IIRC). Basically, many years ago someone got tired of
trying to figure out how to get completely debuggable HotSpot build
on Linux and this big hammer was dropped in. I could chase down who
and when, but I don't think that really matters...

When I did FDS a few years back, I was asked to not break the semantics
of DEBUG_BINARIES and so the big hammer was left in. Solaris is my
primary dev platform and DEBUG_BINARIES doesn't work there so I didn't
mind leaving in DEBUG_BINARIES for the Linux folks...

Fast forward to today... I don't think the entire patch needs to be
backed out. Not touching DEBUG_BINARIES via configure is a "good idea"
(TM) because it is such a big hammer. I do recommend trying to deprecate
the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite...

I'm very much looking forward to a cleaner HotSpot build...

Dan


On 12/17/15 2:24 AM, Erik Joelsson wrote:



On 2015-12-17 09:08, David Holmes wrote:

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:
One more thing, where should this fix be pushed? Do you need it 
urgently

in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via 
NativeCompilation.gmk was in any way a problem. I would have expected 
any problems there to be readily seen before this was reviewed and 
pushed. So I'm a bit confused about this.


I didn't follow this particular review closely as Magnus was on it and 
so I had missed the NativeCompilation part. It's true that it is very 
unlikely to be part of the problem described in this bug, but I still 
feel that the safest action at this point is to restore the behavior 
of "external" and "zipped" to what they used to be. Magnus is working 
on a complete fix where debug symbols will be enabled for everything 
in NativeCompilation.

I'm tempted to say rollback the whole thing rather than hack at it.

Rolling back will be much more work for me than submitting this patch. 
There are two changes already that depend on this change. I also don't 
dislike the idea of the new configure parameter.

And apologies as I'm just about to go offline for a few hours at least.

I hope you won't object to me pushing this with just ihse as reviewer. 
I feel this is rather a priority to get fixed.


/Erik

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Magnus Ihse Bursie]

On 2015-12-17 14:19, Gary Adams wrote:

I've revised the original webrev based on some feedback received.
   - reverted white space only changes
   - proper copyrights on the new files
   - some hotspot files contained previously removed code

  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.


Hi Gary,

There seems to be multiple merge/diff errors in this patch. I'm seeing 
several location where this patch contains changes that is part of 
other, recently pushed change sets. This makes it hard to fully 
understand what changes you are contributing in this patch, to speak 
nothing of the merge problems that are likely to arise if this patch 
were pushed as it is.


I found several other issues as well. I'm sorry I have not been able to 
review this code before. It's a quite massive patch. If you want to 
commit the patch as-is in the mobile/dev forest and then fix my comments 
later before pushing further to mobile/jdk9, it's ok for me. I 
understand that it's tricky to manage a patch of this size. (But I think 
it's better to fix issues now, if you ask me...)


I'll start with something that you and Erik already has discussed: how 
to express tests for logic that is common to ios and macosx. There are 
places in the patch right now that I'm still not happy with.


First of all, I don't think you need to be shy of testing for macosx or 
ios. It's a bit more to write, but it's very clear to the reader, and 
code is read more often than written.


Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. It's 
a bit strange, since it changes the meaning of the OS_ENV (previously it 
was only used to differentiate between cygwin and msys in Windows), but 
I think it could be a reasonable modification. This means that you can 
test if OPENJDK_TARGET_OS_ENV == macosx to cover both the case of macosx 
and ios. Let's just assume that you need to know what you're doing when 
looking at OS_ENV. So this could be an alternative to a lot of "if 
target == macosx or target == ios", if you don't want to type that 
everywhere. For android it seems less of a point of setting OS_ENV. Or 
do you think you could unify android/linux code by this?


Third, I'm not really fond of the TOOLCHAIN_NAME variable. The concept 
is fine, but the variable name is not (I know you didn't invent this).  
We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME sounds like just a 
variant of that. Perhaps resusing the fluffy and unspecified ENV and 
call it TOOLCHAIN_ENV instead? I thought of TOOLCHAIN_VENDOR, but then 
again I'd assume that it'd be "apple", and I think we gain clarity by 
calling Xcode "xcode" and not "apple".


So, to the specifics:
basics.m4: It's not really true that this is build os rather than target 
os. In fact, the whole block is a mix of target and build dependent 
stuff. For instance, xattr depends on build platform but dsymutil 
depends on target os. I suggest you change to target == macosx || ios.


boot-jdk.m4: At the end looks like merge error.

flags.m4: Why delete CPPFLAGS for SYSROOTS?

I think that if you set only LEGACY_EXTRA_CFLAGS and not EXTRA_CFLAGS, 
you will only pass this to Hotspot and not the jdk libraries. But 
honestly, the flag handling is mysterious even to me so I can't say for 
sure. But you might want to double-check this.


BUILD_CC check looks like merge error.

lib-bundled.m4:
Out choice to use system zlib has nothing to do with xcode. It's a 
target os decision.


lib-freetype.m4: OTOH, I'd say that this is indeed a build-os decision :-)

lib-std.m4: This test is only valid for gcc. We are currently not using 
gcc, only clang, for macosx builds. Are you really using gcc for ios 
builds? Otherwise, just leave it as it is.


spec.gmk.in:
Looks like mostly (only?) merge problems here. Or have you added something?

toolchain.m4: See discussion above on TOOLCHAIN_NAME. It looks like 
there are lot of merge errors here.


CompileJavaModules.gmk: Merge errrors galore. I can't really tell what 
are your changes in here.


Images.gmk: Care to elaborate? I don't understand anything.

Main.gmk, JavaCompilation.gmk, Modules.gmk: Merge errors. What is your 
changes in these files? I can't review this.


MakeBase.gmk: just wanted to let you know that I approve of the change 
to build os. :-) I'd appreciate if you could fix the whitespace mistake 
as well (space after the comma is missing).


SetupJavaCompilers.gmk: merge errors? For the GENERATE_JAVA5_BYTECODE, 
please use space after comma. (I know we didn't do that everywhere 
originally, but new code should adhere to the styleguide.)


jdk/make/CompileDemos.gmk: Merge erros. The new android ifdef should 
have proper whitespace (space after comma, the if block indented two 
spaces).


jdk/make/Import.gmk: Looks like the block after the two ifneq 
($(OPENJDK_TARGET_OS), ios) has not been indented. (Or is it a problem 
with the webrev?) Also, the android ifdef is weirdly indented, l

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Bob Vandette]

1. In make/bsd/makefiles/vm.make

You commented out the libffi logic that we’ll need to Zero iOS ARM.  I guess we 
could uncomment this
with the push to add this support.

2. hotspot/src/share/vm/runtime/java.cpp

You shouldn’t need this change.  dll_lookup does the right thing
for static builds now.

661 #ifndef STATIC_BUILD

 662   void *lib_handle = os::native_java_library();

 663   func = CAST_TO_FN_PTR(jdk_version_info_fn_t,

 664  os::dll_lookup(lib_handle, "JDK_GetVersionInfo0"));

 665 #else
 666   extern jdk_version_info_fn_t  JDK_GetVersionInfo0;
 667   func = CAST_TO_FN_PTR(jdk_version_info_fn_t,
 668  &JDK_GetVersionInfo0);
 669 #endif


3. jdk/src/java.base/unix/native/libnio/ch/Net.c

Can you check to see that all of these changes are really necessary?

Bob.



> On Dec 17, 2015, at 8:19 AM, Gary Adams  wrote:
> 
> I've revised the original webrev based on some feedback received.
>   - reverted white space only changes
>   - proper copyrights on the new files
>   - some hotspot files contained previously removed code
> 
>  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/
> 
> Planning to push this first batch tomorrow.
> 
> On 12/11/15 10:15, Gary Adams wrote:
>> Here's the initial upload of changes that provides support for the ios and 
>> android ports
>> for the mobile/dev repos. While there have been some preliminary reviews of 
>> the code,
>> there is still more work required before we will look for more thorough 
>> reviews
>> and an integration to mobile/jdk9 repos.
>> 
>>  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
>>  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/
>> 
>> 
>> Here's a simple configure script to generate a ios-x86_64 build for use
>> with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)
>> 
>> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
>> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
>> 
>> bash ../../configure \
>>--openjdk-target=x86_64-macos-ios \
>>--with-boot-jdk=$JAVA_HOME \
>>--disable-warnings-as-errors \
>>--disable-headful \
>>--enable-static-build=yes \
>>--with-jvm-variants=minimal1
>> 
>> 
>> Also, tested with i586-macos-ios target for 32 bit
>> with a locally built --with-freetype 2.6.2.
> 

Re: Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition

[Kumar Srinivasan]

I am good with this change!.

I would like the rest of the component teams to weigh in on the others.

Thanks
Kumar

On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:

On 2015-12-16 16:33, Kumar Srinivasan wrote:

Hello,

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html 



You are undefining Windows math.h OVERFLOW, what is it defined
as ? With you redefining this, will it cause problems for users of
this API, likely to affect JNI apps.

Probably need to redefine the pack200 OVERFLOW constant to
something else, probably PACK200_OVERFLOW to prevent namespace
collisions.


I agree, this is a better solution. I've updated the webrev with this 
solution (although I used the name PSIZE_OVERFLOW to align with 
PSIZE_MAX).


http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02 



/Magnus




Kumar

On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:

On 2015-11-05 18:03, Timo Kinnunen wrote:
Hi,
  I have signed the OCA and emailed a scan according the 
instructions. I separated the freetype changes into a separate 
batch as suggested. I have shared the patch files on OneDrive, they 
are my Public folder. Here’s the link to the folder: 
https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107

  The OneDrive folder should contain these 4 files:
  freetype_JDK9.patch
vs2015_JDK9.patch
vs2015_JDK9_hotspot.patch
vs2015_JDK9_jdk.patch
  The first two target the root repository, the other two are for 
hotspot and jdk repositories, respectively.
  I rebased the patches on JDK9 tip today. I   ran “make 
images” and fixed a couple of new errors that have appeared since 
the previous version. A couple of the changes I had made were also 
not needed any more.

  Please have a look!

Hi Timo,

I'm sorry for the long delay.

I have created JDK-8145548 for the freetype fix. I'm sponsoring this 
fix. I'll send out a proper review on cr.openjdk.java.net shortly.


The vs2015 changes are more complicated since they touch multiple 
places in the code. Also, your patch had started bitrotting slightly 
during my long response time. I'm trying to fix it up, and will post 
a review when I have sorted everything out. I will verify that the 
change does not break any of our supported platforms, but I'd like 
you to verify that the patch still works on VS2015. When I publish 
the webrev, there will be a download link to the patch file.


Also, this patch touches both hotspot code and multiple jdk modules, 
so it will need to be reviewed by other groups as well, besides the 
build team.


/Magnus


Sent from Mail for Windows 10

From: Magnus Ihse Bursie
Sent: Friday, October 23, 2015 17:13
To: timo.kinnu...@gmail.com;build-dev
Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 
Communityedition

On 2015-09-25 17:55, timo.kinnu...@gmail.com wrote:

Hi,

I’ve been going over the Windows build of the whole JDK for a 
while with VS 2015 and now I have patches that allow the build to 
complete.


I’ve made changes in the root repository as well as in hotspot and 
jdk repositories. The changes fall broadly in three categories: 
enabling the v140 toolchain and improving freetype compilation, 
adding casts to where pointers are truncated and miscellaneous 
small-scale code changes.


The patch to the root repository streamlines handling of freetype 
by implementing a default source directory at $HOME/freetype under 
Cygwin. It is checked during configure and used for compiling if 
“--with-freetype-src” is not specified. A help message giving the 
unpacking command with the correct directory is also included. 
This patch is about 90 lines without counting 
generated-configure.sh changes.


The patches to jdk and hotspot contain native code changes only 
and no changes to make-files. These are about 580 and 290 lines, 
respectively. All patches are generated with “hg diff -g”.


Would you be willing to incorporate these? How should I proceed 
with this?

  Hi Timo,
  First of all, I apologize that you have not recieved any response 
for

far too long. :-(
  Thank you for your interest in helping to improve OpenJDK!
  In general, a patch to allow compilation on   VS 2015 
Community edition

sounds like a good edition to OpenJDK. I am willing to sponsor this
patch and help you work with getting it accepted.
  My first question to you is: have you signed the OCA? Also, unless
you've done so already, reading http://openjdk.java.net/contribute/ 
is a

good start for starting to contribute to OpenJDK.
  However, supporting a new compiler, without at the same time 
breaking an

older one, can sometimes be tricky business. This means that you might
need to iterate your patch a number of times, until it's suitable for
inclusion. I don't want to scare you away, just be realistic up front
that it might require some more work from your part (and our!). Also,
(FYI, we have recently upgraded

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

On 12/17/15 11:09, Magnus Ihse Bursie wrote:

On 2015-12-17 14:19, Gary Adams wrote:

I've revised the original webrev based on some feedback received.
   - reverted white space only changes
   - proper copyrights on the new files
   - some hotspot files contained previously removed code

  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.


Hi Gary,

There seems to be multiple merge/diff errors in this patch. I'm seeing 
several location where this patch contains changes that is part of 
other, recently pushed change sets. This makes it hard to fully 
understand what changes you are contributing in this patch, to speak 
nothing of the merge problems that are likely to arise if this patch 
were pushed as it is.
My bad. In getting the workspace to build I had diff'ed the files 
against the latest jdk9-dev sources
and pulled in changes that were ahead of the recently cloned mobile/dev 
repos.
The next merge will bring in those updates. mobile/dev is cloned from 
jdk9-b94 and latest jdk9/dev

is at jdk9-9+b96.



I found several other issues as well. I'm sorry I have not been able 
to review this code before. It's a quite massive patch. If you want to 
commit the patch as-is in the mobile/dev forest and then fix my 
comments later before pushing further to mobile/jdk9, it's ok for me. 
I understand that it's tricky to manage a patch of this size. (But I 
think it's better to fix issues now, if you ask me...)
I'd like to do any simple cleanups before the initial push. We know 
there will be more pushes coming, so I'm not opposed to partial solutions

being put back at this time.


I'll start with something that you and Erik already has discussed: how 
to express tests for logic that is common to ios and macosx. There are 
places in the patch right now that I'm still not happy with.


First of all, I don't think you need to be shy of testing for macosx 
or ios. It's a bit more to write, but it's very clear to the reader, 
and code is read more often than written.
I am uncomfortable with all the places platform specific changes need to 
be made.
There isn't an easy way to express platform A is like platform B with 
the following

differences.



Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. 
It's a bit strange, since it changes the meaning of the OS_ENV 
(previously it was only used to differentiate between cygwin and msys 
in Windows), but I think it could be a reasonable modification. This 
means that you can test if OPENJDK_TARGET_OS_ENV == macosx to cover 
both the case of macosx and ios. Let's just assume that you need to 
know what you're doing when looking at OS_ENV. So this could be an 
alternative to a lot of "if target == macosx or target == ios", if you 
don't want to type that everywhere. For android it seems less of a 
point of setting OS_ENV. Or do you think you could unify android/linux 
code by this?
I thought previously we were told not to use OPENJDK_TARGET_OS_ENV and I 
asked at that time for "documentation".


Third, I'm not really fond of the TOOLCHAIN_NAME variable. The concept 
is fine, but the variable name is not (I know you didn't invent 
this).  We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME sounds 
like just a variant of that. Perhaps resusing the fluffy and 
unspecified ENV and call it TOOLCHAIN_ENV instead? I thought of 
TOOLCHAIN_VENDOR, but then again I'd assume that it'd be "apple", and 
I think we gain clarity by calling Xcode "xcode" and not "apple".


I'd be glad to use a different name or value for the flag, just let me know.

This is a change we could defer til the mobile/dev to mobile/jdk9 
integration.
At this time I'm mostly interested to know that we've used it in the 
right places.
e.g. prior to discovery of boot-jdk and xcode we used BUILD_OS macosx, 
after
that we use toolchain xcode check, for native flags and libraries we 
still check TARGET_OS

for macosx or ios when not xcode specific.


So, to the specifics:
basics.m4: It's not really true that this is build os rather than 
target os. In fact, the whole block is a mix of target and build 
dependent stuff. For instance, xattr depends on build platform but 
dsymutil depends on target os. I suggest you change to target == 
macosx || ios.

Will do.


boot-jdk.m4: At the end looks like merge error.

Will fix.
We had the big java fix in ejdk8u and it recently cam back in jdk9
recent builds.



flags.m4: Why delete CPPFLAGS for SYSROOTS?

SYSROOT does not belong on CPPFLAGS.
We needed the fix for the ios builds.



I think that if you set only LEGACY_EXTRA_CFLAGS and not EXTRA_CFLAGS, 
you will only pass this to Hotspot and not the jdk libraries. But 
honestly, the flag handling is mysterious even to me so I can't say 
for sure. But you might want to double-check this.
Not sure about this comment. We have working ios and android builds from 
the flags
that are currently being set. Several fingers over several years have 
touched these

Re: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build

[Kim Barrett]

On Dec 17, 2015, at 8:22 AM, Igor Ignatyev  wrote:
> 
> 
>> On Dec 17, 2015, at 2:10 AM, Kim Barrett  wrote:
>> make/solaris/makefiles/adlc.make 
>> 77   WARNINGS_ARE_ERRORS ?= -w -xwe
>> 
>> I'm pretty sure "-w" is wrong here, and should be removed.
> you are right, I made a typo, it was ‘+w’ before. the new webrev : 
> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/
> 
>> And it's
>> not clear why this assignment should be conditional on the compiler
>> version.
> it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, 
> excerpt from Chris’s evaluation:
> 
>> Since some of the errors are in system headers we can only disable the "+w 
>> -errwarn" on SS11 and below.

"+w" has nothing to do with warnings being errors; it just turns on
more warnings.  So it shouldn't be in WARNINGS_ARE_ERRORS.

CFLAGS_WARN is (according to various comments) supposed to hold
options to enable/disable warnings, so "+w" there was reasonable,
while -errwarn should not have been there by that definition.

The conditionalization disables additional warnings and "warnings are
errors" for older compilers that I think we're no longer using for
jdk9.  Are we allowed to retire support for such?

The conditionalization may only be needed for "+w", though without
testing on a no longer officially supported version of the compiler
that would be hard to prove.

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[David Holmes]

On 17/12/2015 6:18 PM, Magnus Ihse Bursie wrote:

On 2015-12-17 09:08, David Holmes wrote:

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:

One more thing, where should this fix be pushed? Do you need it
urgently
in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via
NativeCompilation.gmk was in any way a problem. I would have expected
any problems there to be readily seen before this was reviewed and
pushed. So I'm a bit confused about this.


The changes in NativeCompilation.gmk looked perfectly fine. They turned
out to trigger a bug (or, at the very least, very unsuspected behavior)
which was deeply hidden in the hotspot linux makefiles, where setting
DEBUG_BINARIES did indeed enable the -g flag, but also, as a side
effect, turned fastdebug builds into slowdebug builds. This was not
something that we could possibly forsee.


That was my understanding too - that this was simply a side-effect on 
hotspot, hence my suggestion to rename the variable. But Erik then said 
this was also not working correctly for the JDK side - which means the 
problem is far worse.


David
-




I'm tempted to say rollback the whole thing rather than hack at it.


I don't think there is any compelling reason to rollback the whole
change. The basic idea is sound. However, we do need to work on how to
handle the debug symbols "under the hood". This deficit has been known
for a long time to me and Erik but we have not spent any time on it.
This change brought the problems up to daylight, and I think that's a
good thing.

I've started working on JDK-8145596, which will provide a proper
solution to how we handle debug symbols. It is based on JDK-8036003.

/Magnus




And apologies as I'm just about to go offline for a few hours at least.

David
-




We will followup with a more complete fix.

/Erik

Thanks,
David


/Erik

On 2015-12-16 22:34, Erik Joelsson wrote:

Hello,

Please review this quick fix for the build issue introduced in
Hotspot
by JDK-8036003. The short story is that if you set
DEBUG_BINARIES=true
when building Hotspot fastdebug, you essentially get a slowdebug
build. For an explanation of why, see comment in bug. This
behavior is
of course also a bug, but not something I will address in this quick
fix.

What happened in JDK-8036003 was that a new configure API for
controlling debug symbols was introduced. The two main settings of
this new parameter, --with-native-debug-symbols, that we use
internally at Oracle are "external" and "zipped". It was important to
us that the behavior of these did not change with JDK-8036003, but
exactly that did happen, because both of these settings now cause
DEBUG_BINARIES=true to be set. This variable has never been set by
configure before and because of the above weird behavior in the
Hotspot makefiles, we are having problems.

My proposed quick fix is to not set DEBUG_BINARIES=true for
"external"
or "zipped". It can remain true for "internal" since Oracle never
builds it that way, and I understand those that requested this new
configure parameter were setting DEBUG_BINARIES=true as a workaround
before this anyway, so they should be fine with the broken fastdebug
behavior for a while more. I will file a follow up bug to properly
clean up this mess, but it will take some more time.

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

/Erik

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[David Holmes]

On 17/12/2015 7:24 PM, Erik Joelsson wrote:

On 2015-12-17 09:08, David Holmes wrote:

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:

One more thing, where should this fix be pushed? Do you need it
urgently
in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via
NativeCompilation.gmk was in any way a problem. I would have expected
any problems there to be readily seen before this was reviewed and
pushed. So I'm a bit confused about this.


I didn't follow this particular review closely as Magnus was on it and
so I had missed the NativeCompilation part. It's true that it is very
unlikely to be part of the problem described in this bug, but I still
feel that the safest action at this point is to restore the behavior of
"external" and "zipped" to what they used to be.


My concern is recognizing that these adjustments do in fact restore the 
old behaviour. From the hotspot side it seemed cleaner to avoid the 
breakage by using a different variable name.



Magnus is working on a
complete fix where debug symbols will be enabled for everything in
NativeCompilation.

I'm tempted to say rollback the whole thing rather than hack at it.


Rolling back will be much more work for me than submitting this patch.
There are two changes already that depend on this change. I also don't
dislike the idea of the new configure parameter.


Rolling back the new configure parameters and then reinstating them 
again would also not win us any friends as it would be very disruptive. 
As others have noted the way we introduce and remove configure 
parameters needs to be looked at. I was mainly concerned that the 
out-of-the-box default behaviour was unchanged.



And apologies as I'm just about to go offline for a few hours at least.


I hope you won't object to me pushing this with just ihse as reviewer. I
feel this is rather a priority to get fixed.


Sure. I had verified that DEBUG_BINARIES is only ever tested against 
"true" so setting it to false should be as effective as not setting it 
at all.


I'll follow up separately to see where this was pushed and whether we 
need to pull it into anywhere else urgently.


Thanks,
David


/Erik

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

[David Holmes]

On 18/12/2015 1:58 AM, Daniel D. Daugherty wrote:

DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only
affects Linux (IIRC). Basically, many years ago someone got tired of
trying to figure out how to get completely debuggable HotSpot build
on Linux and this big hammer was dropped in. I could chase down who
and when, but I don't think that really matters...


Unfortunately it also got "cloned" into BSD and AIX ports.

Thanks for the additional info.

David
-


When I did FDS a few years back, I was asked to not break the semantics
of DEBUG_BINARIES and so the big hammer was left in. Solaris is my
primary dev platform and DEBUG_BINARIES doesn't work there so I didn't
mind leaving in DEBUG_BINARIES for the Linux folks...

Fast forward to today... I don't think the entire patch needs to be
backed out. Not touching DEBUG_BINARIES via configure is a "good idea"
(TM) because it is such a big hammer. I do recommend trying to deprecate
the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite...

I'm very much looking forward to a cleaner HotSpot build...

Dan


On 12/17/15 2:24 AM, Erik Joelsson wrote:



On 2015-12-17 09:08, David Holmes wrote:

On 17/12/2015 5:54 PM, Erik Joelsson wrote:



On 2015-12-17 01:40, David Holmes wrote:

On 17/12/2015 7:35 AM, Erik Joelsson wrote:

One more thing, where should this fix be pushed? Do you need it
urgently
in hs-rt?


It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.


Will do.

With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?


Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.


I had not inferred from any of this that what was being done via
NativeCompilation.gmk was in any way a problem. I would have expected
any problems there to be readily seen before this was reviewed and
pushed. So I'm a bit confused about this.


I didn't follow this particular review closely as Magnus was on it and
so I had missed the NativeCompilation part. It's true that it is very
unlikely to be part of the problem described in this bug, but I still
feel that the safest action at this point is to restore the behavior
of "external" and "zipped" to what they used to be. Magnus is working
on a complete fix where debug symbols will be enabled for everything
in NativeCompilation.

I'm tempted to say rollback the whole thing rather than hack at it.


Rolling back will be much more work for me than submitting this patch.
There are two changes already that depend on this change. I also don't
dislike the idea of the new configure parameter.

And apologies as I'm just about to go offline for a few hours at least.


I hope you won't object to me pushing this with just ihse as reviewer.
I feel this is rather a priority to get fixed.

/Erik

Re: Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition

[David Holmes]

On 18/12/2015 3:28 AM, Kumar Srinivasan wrote:

I am good with this change!.

I would like the rest of the component teams to weigh in on the others.


This needs to be sent to all the affected component teams, or even 
better split into three pieces: build, hotspot and JDK libs, and then sent.


Hotspot changes looked okay to me - though the need for casts in various 
places was unpleasant - we may want neater ways to deal with that.


Thanks,
David


Thanks
Kumar

On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:

On 2015-12-16 16:33, Kumar Srinivasan wrote:

Hello,

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html


You are undefining Windows math.h OVERFLOW, what is it defined
as ? With you redefining this, will it cause problems for users of
this API, likely to affect JNI apps.

Probably need to redefine the pack200 OVERFLOW constant to
something else, probably PACK200_OVERFLOW to prevent namespace
collisions.


I agree, this is a better solution. I've updated the webrev with this
solution (although I used the name PSIZE_OVERFLOW to align with
PSIZE_MAX).

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02


/Magnus




Kumar

On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:

On 2015-11-05 18:03, Timo Kinnunen wrote:
Hi,
  I have signed the OCA and emailed a scan according the
instructions. I separated the freetype changes into a separate
batch as suggested. I have shared the patch files on OneDrive, they
are my Public folder. Here’s the link to the folder:
https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
  The OneDrive folder should contain these 4 files:
  freetype_JDK9.patch
vs2015_JDK9.patch
vs2015_JDK9_hotspot.patch
vs2015_JDK9_jdk.patch
  The first two target the root repository, the other two are for
hotspot and jdk repositories, respectively.
  I rebased the patches on JDK9 tip today. I   ran “make
images” and fixed a couple of new errors that have appeared since
the previous version. A couple of the changes I had made were also
not needed any more.
  Please have a look!

Hi Timo,

I'm sorry for the long delay.

I have created JDK-8145548 for the freetype fix. I'm sponsoring this
fix. I'll send out a proper review on cr.openjdk.java.net shortly.

The vs2015 changes are more complicated since they touch multiple
places in the code. Also, your patch had started bitrotting slightly
during my long response time. I'm trying to fix it up, and will post
a review when I have sorted everything out. I will verify that the
change does not break any of our supported platforms, but I'd like
you to verify that the patch still works on VS2015. When I publish
the webrev, there will be a download link to the patch file.

Also, this patch touches both hotspot code and multiple jdk modules,
so it will need to be reviewed by other groups as well, besides the
build team.

/Magnus


Sent from Mail for Windows 10

From: Magnus Ihse Bursie
Sent: Friday, October 23, 2015 17:13
To: timo.kinnu...@gmail.com;build-dev
Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015
Communityedition
On 2015-09-25 17:55, timo.kinnu...@gmail.com wrote:

Hi,

I’ve been going over the Windows build of the whole JDK for a
while with VS 2015 and now I have patches that allow the build to
complete.

I’ve made changes in the root repository as well as in hotspot and
jdk repositories. The changes fall broadly in three categories:
enabling the v140 toolchain and improving freetype compilation,
adding casts to where pointers are truncated and miscellaneous
small-scale code changes.

The patch to the root repository streamlines handling of freetype
by implementing a default source directory at $HOME/freetype under
Cygwin. It is checked during configure and used for compiling if
“--with-freetype-src” is not specified. A help message giving the
unpacking command with the correct directory is also included.
This patch is about 90 lines without counting
generated-configure.sh changes.

The patches to jdk and hotspot contain native code changes only
and no changes to make-files. These are about 580 and 290 lines,
respectively. All patches are generated with “hg diff -g”.

Would you be willing to incorporate these? How should I proceed
with this?

  Hi Timo,
  First of all, I apologize that you have not recieved any response
for
far too long. :-(
  Thank you for your interest in helping to improve OpenJDK!
  In general, a patch to allow compilation on   VS 2015
Community edition
sounds like a good edition to OpenJDK. I am willing to sponsor this
patch and help you work with getting it accepted.
  My first question to you is: have you signed the OCA? Also, unless
you've done so already, reading http://openjdk.java.net/contribute/
is a
good start for starting to contribute to OpenJDK.
  However, supporting a new compiler, without at the same time
breaking an
older one, can s

Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

[David Holmes]

On 17/12/2015 7:41 AM, Martin Buchholz wrote:

We can fix both JDK-6515172 and JDK-8144312 by doing the autconf
detection of how to count the number of allowed processors, then
actually measuring what's available during the build, and also fixing
the hotspot implemementation of Runtime.availableProcessors.


We don't need any autoconf involvement for 6515172 (which I referred to 
a couple of days ago). Let's not muddy the waters. Autosizing the build 
parallelism is tricky enough.


David