Re: JDK-8025705

[David Holmes]

Hi Keith,

Okay ... so you don't set OPENJDK and thus from the make logic 
perspective you are implicitly ORACLE_JDK. So first question: why don't 
you set OPENJDK and then add blocks guarded by MY_JDK (or whatever) for 
your custom stuff?


Second, the way to get a disjunction is to use the text functions eg 
(untested but you should get the gist):


// OR
ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)

// not-OR
ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)

It's not as trivial as || etc but not too horrendously ugly :)

Does this help?

David

On 22/04/2014 11:10 PM, Keith McGuigan wrote:

Hi David,

Most of the problem resides in jdk/make, in the following files:
make/CompileDemos.gmk
make/CompileJavaClasses.gmk
make/CopyFiles.gmk
make/CopyIntoClasses.gmk
make/CreateSecurityJars.gmk
make/gensrc/GensrcIcons.gmk
make/Images.gmk
make/lib/Awt2dLibraries.gmk

Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk
has a bit too).  Basically in each situation where there's a "ifndef
OPENJDK", it encloses a block of code that access something in
src/closed or make/closed.

I did initially try to set a new variable in our build in an attempt to
replace these areas with something like:
ifndef OPENJDK && ifndef PRIVATEJDK

... but there's apparently no convenient way of doing that in makefiles
(conjunctions and disjunctions at the preprocessing level aren't
available -- and the workarounds are rather goofy).  Duplicating the
OPENJDK only code quickly became unreasonable too -- a few of the code
blocks are one-liners, but there's a bunch that are much more involved
clauses.



On Tue, Apr 22, 2014 at 8:23 AM, David Holmes mailto:david.hol...@oracle.com>> wrote:

Hi Keith,

Sorry I have very limited cycles right now, and just had a 4 day
Easter break with anther long weekend ahead :)

You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat
tangential to your issue.

The existence checks I suggested would be a check for whatever
file/directory is enough to indicate the "feature" is present.

Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
introducing a third variation doesn't really fit.

Can you give a concrete example of something that highlights this
problem for you and how your proposal addresses it? I may get a
better sense of things with specifics rather than trying to
generalize - because I don't see a general solution without a lot of
refactoring.

Thanks,
David


On 22/04/2014 2:42 PM, Keith McGuigan wrote:

Hi Mark, et al.,

The sad reality of the situation is that there is indeed
Oracle-specific
code in the OpenJDK makefiles, and this code interferes with our
customization of the JDK.  Adding temporary signposts to allow
us (and
others) to avoid this code will not make things worse.  It
doesn't have
to be a distribution name -- we call it whatever you like:
TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to
latch onto
to deactivate that code when it is not needed.  This would provide
immediate relief to customizing distributors and give Oracle
engineers
time to phase that code into closed makefiles (at which time the
signposts can be removed completely).

Taking all this code out wholesale instead would be great, and
this is
something I am totally willing to tackle and put the effort in
on if I
was in a position to do so.  Unfortunately, since this is not fully
open-source, I can't do the refactoring needed to move this code
into
the closed directories.  And I though I could easily strip the
code from
OpenJDK, this would totally muck with Oracle distribution so any
patch I
would submit would surely be immediately rejected.

Considering that the code is question has been in OpenJDK for
about 8
years now, I think it's safe to assume that it's not a high priority
item for Oracle engineers to get this fixed.  Which is totally
fine, IMO
-- it's very much a tenant of open source development that he
who has
the itch ought to be the one to scratch it, and different
entities are
expected to have different sets of priorities.  No doubt I'm
probably
the first one to complain about this :)

Unfortunately, I'm also in the unfortunate position of having an
itch
(and willing fingernails), but an inability to scratch it.

So, where do we go from here and how can I help in this effort?  I
really do want to help, as this is an immediate problem for me and I
can't afford to wait years for it to get fixed.  I still think that
signposts are a very reasonable compromise given that:
(1) It is something that can be done inde

Re: RFR 8030011: Update Hotspot version string output

[Alejandro E Murillo]

On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:

On 4/22/14 4:42 PM, Alejandro E Murillo wrote:


On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:

Hi Alejandro,

I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.




Next assert message is not consistent with previous messages which use
"vm", I think it should be "vm" here too:

  DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build
number"));

we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls


Can we simple say "wrong build number"?

sounds good!


So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number 
anymore.

it's gone!




Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.

I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html 



http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html 



No, I mean next code should encode micro version too:

 unsigned int Abstract_VM_Version::jvm_version() {
   return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
  ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
+ ((Abstract_VM_Version::vm_micro_version() & 0xFF) <<  8) |
  (Abstract_VM_Version::vm_build_number() & 0xFF);
 }


you are right. I recall having added that earlier :(
it's back int the webrev




Use corresponding test in jdk for testing of these changes:

jdk/test/sun/misc/Version/Version.java

yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions


Good.



jvm.h: Next comment is not accurate:

+/* VM version string: JDK version string */

If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:

+/* VM version string follows the JDK release version naming
convention
+ * ..-bxx[-][-]

Based on your examples [-][-] is still used
so it should be reflected in the comment.

Let me make that explicit.


Don't remove next comments from vm_version.cpp but fix it ("follow the
JDK release"):

-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// .-b[-][-]

ok


You did not show default VM version example when VM is built locally
by engineer.

It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm  into a promoted build, so it
looks like this:

java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed 
mode)


okay





Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'

Haven't tested that, thanks for pointing that out.


thank you



Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:

-# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION

see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.

let me check that again


I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:

-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)

I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache,  that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:

# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.



I was concern that it will not be passed into nested make so that, for 
example, buildtree.make will not get it.

I see. I don't think it's needed

I think I incorporated all the changes David, John and you suggested and 
started some sanity testing;

Here's is the latest webrev:

http://cr.openjdk.java.net/~amurillo/9/8030011/

Please review (don't forget to refresh each file on your browser) and 
let me know if I missed anything.

thanks guys!

--
Alejandro

Re: RFR 8030011: Update Hotspot version string output

[Vladimir Kozlov]

On 4/22/14 4:42 PM, Alejandro E Murillo wrote:


On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:

Hi Alejandro,

I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.




Next assert message is not consistent with previous messages which use
"vm", I think it should be "vm" here too:

  DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build
number"));

we do not have hotspot build number anymore, so I think we should not
mention hotspot build numberls


Can we simple say "wrong build number"?

So you don't want update build number in make/*_version files? ;)
Yes, I see in your example of JPRT build VM does not have build number 
anymore.




Abstract_VM_Version::jvm_version() should include micro version. See
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in
jdk/src/share/javavm/export/jvm.h.

I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html

http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html


No, I mean next code should encode micro version too:

 unsigned int Abstract_VM_Version::jvm_version() {
   return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
  ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
+ ((Abstract_VM_Version::vm_micro_version() & 0xFF) <<  8) |
  (Abstract_VM_Version::vm_build_number() & 0xFF);
 }





Use corresponding test in jdk for testing of these changes:

jdk/test/sun/misc/Version/Version.java

yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions


Good.



jvm.h: Next comment is not accurate:

+/* VM version string: JDK version string */

If we build VM separately (for example, in JPRT) VM version will not
be JDK version in which VM is installed. It will take numbers either
from passed make parameters or from make/hotspot_version. I think it
should say:

+/* VM version string follows the JDK release version naming
convention
+ * ..-bxx[-][-]

Based on your examples [-][-] is still used
so it should be reflected in the comment.

Let me make that explicit.


Don't remove next comments from vm_version.cpp but fix it ("follow the
JDK release"):

-// HOTSPOT_RELEASE_VERSION must follow the release version naming
convention
-// .-b[-][-]

ok


You did not show default VM version example when VM is built locally
by engineer.

It will be similar to the hotspot only jprt build. There will be a
mismatch,
I tested by dropping the resulting libjvm  into a promoted build, so it
looks like this:

java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode)


okay





Please test that correct version string is constructed when you build
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'

Haven't tested that, thanks for pointing that out.


thank you



Next comment change in buildtree.make is not correct because
HOTSPOT_RELEASE_VERSION make parameter does not include
HOTSPOT_BUILD_VERSION:

-# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus
HOTSPOT_BUILD_VERSION

see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.

let me check that again


I think next change in make/defs.make is not safe (removing make
parameter) due to complexity of our builds:

-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)

I checked the code, and HOTSPOT_RELEASE_VERSION is only used in
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since
the JDK version string
sometimes might have time stamps, it may affect ccache,  that's why at
some point they
separated the options for vm_version.cpp from the options for other
components. See this
comment on vm,make:

# This is VERY important! The version define must only be supplied to
vm_version.o
# If not, ccache will not re-use the cache at all, since the version
string might contain
# a time and date.



I was concern that it will not be passed into nested make so that, for 
example, buildtree.make will not get it.







I know that windows build is mess. Please verify it carefully. For
example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but
build.make uses them:

JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER)


That was a typo. Note that I changed the left handside, so they were
incorrectly reassigning those.
The places were JDK_MINOR_VER is used, the value is read from
jdk_version (formerly hotspot_version)


Okay.

Thanks,
Vladimir



Thanks a lot for the feedback!
Alejandro



Regards,
Vladimir

On 4/21/14 10:13 AM, Alejandro E Murillo wrote:


On 4/18/2014 6:50 PM, John Coomes wrote:

Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:

Please review this change to make the hots

Re: RFR 8030011: Update Hotspot version string output

[Alejandro E Murillo]

On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:

Hi Alejandro,

I don't think we need to rename make/hotspot_version file. It is still 
used to set JVM's version string and not JDK's version.




Next should be 2014 (I think David pointed it too but there is no new 
webrev): HOTSPOT_VM_COPYRIGHT=Copyright 2013

correct. I haven't changed that yet


If you pass major, micro etc numbers to avoid parsing you need to 
verify that constructed from them string is equal to passed 
HOTSPOT_RELEASE_VERSION.

yes, there's a test for that, which is run when I submit a full jprt job.


Next assert message is not consistent with previous messages which use 
"vm", I think it should be "vm" here too:


  DEBUG_ONLY(assert_digits(vm_build_num, offset, "wrong JDK build 
number"));
we do not have hotspot build number anymore, so I think we should not 
mention hotspot build numberls




Abstract_VM_Version::jvm_version() should include micro version. See 
JVM_GetVersionInfo() in jvm.cpp and jvm_version_info in 
jdk/src/share/javavm/export/jvm.h.

I added that here, is that what you are referring?
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vmStructs.cpp.udiff.html
http://cr.openjdk.java.net/~amurillo/9/8030011/src/share/vm/runtime/vm_version.hpp.udiff.html


Use corresponding test in jdk for testing of these changes:

jdk/test/sun/misc/Version/Version.java

yeah, I run that test as part of jprt full builds,
That test handles both JDK and Hotspot express versions


jvm.h: Next comment is not accurate:

+/* VM version string: JDK version string */

If we build VM separately (for example, in JPRT) VM version will not 
be JDK version in which VM is installed. It will take numbers either 
from passed make parameters or from make/hotspot_version. I think it 
should say:


+/* VM version string follows the JDK release version naming 
convention

+ * ..-bxx[-][-]

Based on your examples [-][-] is still used 
so it should be reflected in the comment.

Let me make that explicit.


Don't remove next comments from vm_version.cpp but fix it ("follow the 
JDK release"):


-// HOTSPOT_RELEASE_VERSION must follow the release version naming 
convention

-// .-b[-][-]

ok


You did not show default VM version example when VM is built locally 
by engineer.

It will be similar to the hotspot only jprt build. There will be a mismatch,
I tested by dropping the resulting libjvm  into a promoted build, so it 
looks like this:


java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-debug, mixed mode)



Please test that correct version string is constructed when you build 
VM using make/build.sh, for example 'sh make/build.sh debug LP64=1'

Haven't tested that, thanks for pointing that out.


Next comment change in buildtree.make is not correct because 
HOTSPOT_RELEASE_VERSION make parameter does not include 
HOTSPOT_BUILD_VERSION:


-# HOTSPOT_RELEASE_VERSION - .-b (11.0-b07)
+# HOTSPOT_RELEASE_VERSION - JRE_RELEASE_VERSION plus 
HOTSPOT_BUILD_VERSION


see JPRT logs where HOTSPOT_BUILD_VERSION is set separately.

let me check that again


I think next change in make/defs.make is not safe (removing make 
parameter) due to complexity of our builds:


-MAKE_ARGS += HOTSPOT_RELEASE_VERSION=$(HOTSPOT_RELEASE_VERSION)
I checked the code, and HOTSPOT_RELEASE_VERSION is only used in 
vm_version.cpp,
so I think is fine to remove it. Note that if we keep it there, since 
the JDK version string
sometimes might have time stamps, it may affect ccache,  that's why at 
some point they
separated the options for vm_version.cpp from the options for other 
components. See this

comment on vm,make:

# This is VERY important! The version define must only be supplied to 
vm_version.o
# If not, ccache will not re-use the cache at all, since the version string 
might contain
# a time and date.





I know that windows build is mess. Please verify it carefully. For 
example, you changed names JDK_*_VER to JDK_*_VERSION in def.make but 
build.make uses them:


JDK_VER=$(JDK_MINOR_VER),$(JDK_MICRO_VER),$(JDK_UPDATE_VER),$(JDK_BUILD_NUMBER) 

That was a typo. Note that I changed the left handside, so they were 
incorrectly reassigning those.
The places were JDK_MINOR_VER is used, the value is read from 
jdk_version (formerly hotspot_version)


Thanks a lot for the feedback!
Alejandro



Regards,
Vladimir

On 4/21/14 10:13 AM, Alejandro E Murillo wrote:


On 4/18/2014 6:50 PM, John Coomes wrote:

Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output 
produced by

"java -version"
match the corresponding JDK output:

webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011

Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we h

Re: RFR: JDK-8041487: Fix proper dependencies for correct incremental build of javadocs

[Jonathan Gibbons]

The comments at the end of the webrev could be improved as well at some 
point.
You can barely see the code for all the dust and spiders.  I think it 
talks about

"large 32 bits machines" but surely that can't be right... :-)

1200 #release version of core packages 
1201
1202 # The rel-coredocs and rel-docs targets were added by Eric Armstrong. 
rel-coredocs
1203 # assumes the kind of large, 32-bit machine used in the javapubs group's 
docs-release
1204 # process. It specifies memory settings accordingly to maximize 
performance.
1205 #
1206 # The performance settings, like the sanity check, are most important for 
the core
1207 # docs--the platform APIs. Running javadoc on those APIs takes a 
significant amount
1208 # of time and memory. Setting the initial heap size as large as possible 
is important
1209 # to prevent thrashing as the heap grows. Setting the maximum as large as 
necessary
1210 # is also important to keep the job from failing.
1211 #
1212 #-J-Xmx512 sets a maximum of 512, which became necessary in 6.0
1213 #-J-Xms256 sets starting size to 256 (default is 8)
1214 #
1215 # rel-coredocs also includes a sanity check to help ensure that 
BUILD_NUMBER and
1216 # MILESTONE are specified properly when docs are built outside of the 
normal release
1217 # engineering process, with the intention of releasing them on the web or 
in a downloaded





On 04/22/2014 08:04 AM, Erik Joelsson wrote:

(adding javadoc-dev)

On 2014-04-22 15:29, Erik Joelsson wrote:

(reposting with correct subject)

On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed 
some attention. This patch makes it behave correctly for incremental 
builds and reduces the log output on the default log level to much 
more manageable levels.


I realize that we should probably rewrite this even more to reduce 
all the code duplication, but choose to leave that for later.


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

/Erik

Re: RFR: JDK-8041487: Fix proper dependencies for correct incremental build of javadocs

[Mike Duigou]

Nice to see this improved.

Mike

On Apr 22 2014, at 06:29 , Erik Joelsson  wrote:

> (reposting with correct subject)
> 
> On 2014-04-22 15:28, Erik Joelsson wrote:
>> I recently had to work with make/Javadoc.gmk and felt that it needed some 
>> attention. This patch makes it behave correctly for incremental builds and 
>> reduces the log output on the default log level to much more manageable 
>> levels.
>> 
>> I realize that we should probably rewrite this even more to reduce all the 
>> code duplication, but choose to leave that for later.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041487
>> Webrev: http://cr.openjdk.java.net/~erikj/8041487/webrev.root.01/
>> 
>> /Erik
> 

Re: jdk7u full build fails on Win - unable to load zip.dll

[Pete Brunet]

Hi Erik,
On 4/22/14 2:58 AM, Erik Joelsson wrote:
> The build is trying to run rmic using the newly built jdk. It seems
> there is a problem with the zip.dll that you just built. Are you able
> to run
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/bin/java
> at all?
No - because zip.dll is not there.  But it is in
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/tmp/sun/java/java.util.zip/zip/obj_g0.
 
Earlier in the build it's copied from there to .../bin/java.  That copy
seems to have been successful, e.g. the following "Checking for /SAFESEH
usage" appears to have not failed, but I couldn't find any rm commands
that would have gotten rid of it. 

The cp line is interesting:
/usr/bin/cp
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/tmp/sun/java.util.zip/zip/obj_gO/zip.dll
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/zip.dll

Note this:
windows-i586/../windows-i586-fastdebug
That might be OK but it looks unusual.

I see I had one error in my invocation.  I had fastdebug_build images. 
I don't know if that extra parameter caused any problems.

A JPRT build works OK, but that was not a fastdebug build, so I tried
again locally leaving off fastdebug_build (and images) and that got past
the problem.  But then I hit this one:

C:/Progra~1/Java/jdk1.6.0_45/bin/java -XX:-PrintVMOptions
-XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx512m
-Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m
"-Xbootclasspath/p:C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/javadoc.jar;C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/javac.jar;C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/doclets.jar"
-jar
 
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/langtools/dist/bootstrap/lib/javadoc.jar
-bootclasspath
"C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/classes"  -d
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/docs/api \
 
@C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/tmp/docs/doctmp/coredocs.options
@C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/tmp/docs/doctmp/coredocs.packages
..\..\src\share\classes\java\awt\color\ICC_Profile.java:1069: warning -
Tag @see: missing '#': "activateDeferredProfile()"
..\..\src\share\classes\java\util\Calendar.java:1717: warning - Tag
@see: can't find setInternallySetState(int) in java.util.Calendar
..\..\src\share\classes\java\util\Currency.java:685: warning - @throws
tag has no arguments.
..\..\src\share\classes\javax\swing\plaf\nimbus\NimbusStyle.java:854:
warning - @return tag has no arguments.
..\..\src\share\classes\javax\swing\plaf\nimbus\NimbusStyle.java:926:
warning - @return tag has no arguments.
C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586\impsrc\javax\xml\bind\JAXBContext.java:262:
warning - Tag @see: reference not found: S 7.4.1 "Named Packages" in
Java Language Specification
javadoc: error - java.lang.OutOfMemoryError: Please increase memory.
For example, on the JDK Classic or HotSpot VMs, add the option -J-Xmx
such as -J-Xmx32m.
1 error
6 warnings
make[3]: ***
[C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/docs/api/index.html]
Error 1
make[3]: Leaving directory
`/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/docs'
make[2]: *** [docs] Error 1
make[2]: Leaving directory
`/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make'
make[1]: *** [jdk-build] Error 2
make[1]: Leaving directory `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7'
make: *** [build_product_image] Error 2

I noticed my 4G was maxed out so I rebooted and that issues was resolved.

BTW, I prefer a local build because I have a bunch of them to do and I
need to test all of them locally.

Pete
>
> /Erik
>
> On 2014-04-18 23:56, Pete Brunet wrote:
>> p.s. The ALT_BOOTDIR specifies 6u45.
>>
>> On 4/18/14 4:53 PM, Pete Brunet wrote:
>>> A full 7u build currently fails like this:
>>>
>>> make[6]: Entering directory
>>> `/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx'
>>> /usr/bin/mkdir -p
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi
>>>
>>> rm -f
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class
>>>
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/java
>>>
>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>> -client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
>>>
>>> sun.rmi.rmic.Main -classpath
>>> "C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes"
>>>
>>> \
>>>  -d
>>> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/w

Re: RFR: 8041267 : (s) Add filtering capability to CacheFind

[Mike Duigou]

On Apr 22 2014, at 01:21 , Erik Joelsson  wrote:

> Hello Mike,
> 
> This will probably work fine. Perhaps a note on the formatting of the new 
> argument is needed? From what I can tell it needs to always start with "-a".

The specialization could theoretically start with an -o but you are right that 
for openJDK builds it will probably always be "-a". I added a note and fixed 
one additional spelling error (FIND_CACHE_DIR vs FIND_CACHE_DIRS)

Mike

> I can't help but think that there might be a need for named caches at some 
> point if this is introduced, but I will add that if I find a need for it.
> 
> /Erik
> 
> On 2014-04-19 20:54, Mike Duigou wrote:
>> Hello all;
>> 
>> In some cases the results of find operations need to be more specific. 
>> Adding a filter capability to the find/caching stage would reduce the 
>> overhead of some requests. This changeset adds an optional second parameter 
>> allowing a find expression to provide additional filtering of find results.
>> 
>> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041267
>> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041267/0/webrev/
>> 
>> Once the functionality is available it will be used in CreateJars.gmk, 
>> GensrcProperties.gmk, and Images.gmk to narrow find results.
>> 
>> Mike
> 

Re: RFR: JDK-8041487: Fix proper dependencies for correct incremental build of javadocs

[Erik Joelsson]

(adding javadoc-dev)

On 2014-04-22 15:29, Erik Joelsson wrote:

(reposting with correct subject)

On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed 
some attention. This patch makes it behave correctly for incremental 
builds and reduces the log output on the default log level to much 
more manageable levels.


I realize that we should probably rewrite this even more to reduce 
all the code duplication, but choose to leave that for later.


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

/Erik

Re: RFR: JDK-8041487: Fix proper dependencies for correct incremental build of javadocs

[Tim Bell]

Hi Erik:


(reposting with correct subject)

On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed 
some attention. This patch makes it behave correctly for incremental 
builds and reduces the log output on the default log level to much 
more manageable levels.


I realize that we should probably rewrite this even more to reduce 
all the code duplication, but choose to leave that for later.


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


Looks good to me.

Tim

RFR: JDK-8041487: Fix proper dependencies for correct incremental build of javadocs

[Erik Joelsson]

(reposting with correct subject)

On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed 
some attention. This patch makes it behave correctly for incremental 
builds and reduces the log output on the default log level to much 
more manageable levels.


I realize that we should probably rewrite this even more to reduce all 
the code duplication, but choose to leave that for later.


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

/Erik

RFR: JDK-8041487

[Erik Joelsson]

I recently had to work with make/Javadoc.gmk and felt that it needed 
some attention. This patch makes it behave correctly for incremental 
builds and reduces the log output on the default log level to much more 
manageable levels.


I realize that we should probably rewrite this even more to reduce all 
the code duplication, but choose to leave that for later.


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

/Erik

Re: JDK-8025705

[Keith McGuigan]

Hi David,

Most of the problem resides in jdk/make, in the following files:
make/CompileDemos.gmk
make/CompileJavaClasses.gmk
make/CopyFiles.gmk
make/CopyIntoClasses.gmk
make/CreateSecurityJars.gmk
make/gensrc/GensrcIcons.gmk
make/Images.gmk
make/lib/Awt2dLibraries.gmk

Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk has a
bit too).  Basically in each situation where there's a "ifndef OPENJDK", it
encloses a block of code that access something in src/closed or make/closed.

I did initially try to set a new variable in our build in an attempt to
replace these areas with something like:
ifndef OPENJDK && ifndef PRIVATEJDK

... but there's apparently no convenient way of doing that in makefiles
(conjunctions and disjunctions at the preprocessing level aren't available
-- and the workarounds are rather goofy).  Duplicating the OPENJDK only
code quickly became unreasonable too -- a few of the code blocks are
one-liners, but there's a bunch that are much more involved clauses.



On Tue, Apr 22, 2014 at 8:23 AM, David Holmes wrote:

> Hi Keith,
>
> Sorry I have very limited cycles right now, and just had a 4 day Easter
> break with anther long weekend ahead :)
>
> You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat tangential
> to your issue.
>
> The existence checks I suggested would be a check for whatever
> file/directory is enough to indicate the "feature" is present.
>
> Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
> introducing a third variation doesn't really fit.
>
> Can you give a concrete example of something that highlights this problem
> for you and how your proposal addresses it? I may get a better sense of
> things with specifics rather than trying to generalize - because I don't
> see a general solution without a lot of refactoring.
>
> Thanks,
> David
>
>
> On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>> Hi Mark, et al.,
>>
>> The sad reality of the situation is that there is indeed Oracle-specific
>> code in the OpenJDK makefiles, and this code interferes with our
>> customization of the JDK.  Adding temporary signposts to allow us (and
>> others) to avoid this code will not make things worse.  It doesn't have
>> to be a distribution name -- we call it whatever you like:
>> TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto
>> to deactivate that code when it is not needed.  This would provide
>> immediate relief to customizing distributors and give Oracle engineers
>> time to phase that code into closed makefiles (at which time the
>> signposts can be removed completely).
>>
>> Taking all this code out wholesale instead would be great, and this is
>> something I am totally willing to tackle and put the effort in on if I
>> was in a position to do so.  Unfortunately, since this is not fully
>> open-source, I can't do the refactoring needed to move this code into
>> the closed directories.  And I though I could easily strip the code from
>> OpenJDK, this would totally muck with Oracle distribution so any patch I
>> would submit would surely be immediately rejected.
>>
>> Considering that the code is question has been in OpenJDK for about 8
>> years now, I think it's safe to assume that it's not a high priority
>> item for Oracle engineers to get this fixed.  Which is totally fine, IMO
>> -- it's very much a tenant of open source development that he who has
>> the itch ought to be the one to scratch it, and different entities are
>> expected to have different sets of priorities.  No doubt I'm probably
>> the first one to complain about this :)
>>
>> Unfortunately, I'm also in the unfortunate position of having an itch
>> (and willing fingernails), but an inability to scratch it.
>>
>> So, where do we go from here and how can I help in this effort?  I
>> really do want to help, as this is an immediate problem for me and I
>> can't afford to wait years for it to get fixed.  I still think that
>> signposts are a very reasonable compromise given that:
>> (1) It is something that can be done independently and doesn't require
>> Oracle engineering resources (other than reviews and shepherding)
>> (2) It does not interfere with efforts to move closed code out of
>> OpenJDK makefiles
>> (3) it can be done quickly
>> (4) It does not avoid the Makefile-checking for existence of required
>> files/directories (which reduces build-brittleness)
>>
>> Mark/Dave, if I can't convince you that we should take this path, can
>> you please suggest an alternative design?  I'm not picky -- if we can
>> come up with something else that works then let's do it and I'll start
>> on it right away.
>>
>> --
>> - Keith (itchy)
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 8:23 PM, > > wrote:
>>
>> 2014/4/16 14:52 -0700, david.hol...@oracle.com
>> :
>>
>>  > src/closed is Oracle's "custom source" location (hotspot calls it
>>  > alt_src). If we never saw src/closed in the makefil

Re: JDK-8025705

[David Holmes]

Hi Keith,

Sorry I have very limited cycles right now, and just had a 4 day Easter 
break with anther long weekend ahead :)


You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat 
tangential to your issue.


The existence checks I suggested would be a check for whatever 
file/directory is enough to indicate the "feature" is present.


Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so 
introducing a third variation doesn't really fit.


Can you give a concrete example of something that highlights this 
problem for you and how your proposal addresses it? I may get a better 
sense of things with specifics rather than trying to generalize - 
because I don't see a general solution without a lot of refactoring.


Thanks,
David

On 22/04/2014 2:42 PM, Keith McGuigan wrote:

Hi Mark, et al.,

The sad reality of the situation is that there is indeed Oracle-specific
code in the OpenJDK makefiles, and this code interferes with our
customization of the JDK.  Adding temporary signposts to allow us (and
others) to avoid this code will not make things worse.  It doesn't have
to be a distribution name -- we call it whatever you like:
TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto
to deactivate that code when it is not needed.  This would provide
immediate relief to customizing distributors and give Oracle engineers
time to phase that code into closed makefiles (at which time the
signposts can be removed completely).

Taking all this code out wholesale instead would be great, and this is
something I am totally willing to tackle and put the effort in on if I
was in a position to do so.  Unfortunately, since this is not fully
open-source, I can't do the refactoring needed to move this code into
the closed directories.  And I though I could easily strip the code from
OpenJDK, this would totally muck with Oracle distribution so any patch I
would submit would surely be immediately rejected.

Considering that the code is question has been in OpenJDK for about 8
years now, I think it's safe to assume that it's not a high priority
item for Oracle engineers to get this fixed.  Which is totally fine, IMO
-- it's very much a tenant of open source development that he who has
the itch ought to be the one to scratch it, and different entities are
expected to have different sets of priorities.  No doubt I'm probably
the first one to complain about this :)

Unfortunately, I'm also in the unfortunate position of having an itch
(and willing fingernails), but an inability to scratch it.

So, where do we go from here and how can I help in this effort?  I
really do want to help, as this is an immediate problem for me and I
can't afford to wait years for it to get fixed.  I still think that
signposts are a very reasonable compromise given that:
(1) It is something that can be done independently and doesn't require
Oracle engineering resources (other than reviews and shepherding)
(2) It does not interfere with efforts to move closed code out of
OpenJDK makefiles
(3) it can be done quickly
(4) It does not avoid the Makefile-checking for existence of required
files/directories (which reduces build-brittleness)

Mark/Dave, if I can't convince you that we should take this path, can
you please suggest an alternative design?  I'm not picky -- if we can
come up with something else that works then let's do it and I'll start
on it right away.

--
- Keith (itchy)




On Mon, Apr 21, 2014 at 8:23 PM, mailto:mark.reinh...@oracle.com>> wrote:

2014/4/16 14:52 -0700, david.hol...@oracle.com
:
 > src/closed is Oracle's "custom source" location (hotspot calls it
 > alt_src). If we never saw src/closed in the makefiles, only
 > CUSTOM_SRC_DIR, and guarded with an existence test for a specific
 > directory/file, then that should address your problem. That would
be a
 > first step in moving things to the custom makefiles where they
belong.
 >
 > I'm opposed to the ORACLEJDK variable because I want to maintain the
 > pressure to get this fixed properly. If we hack around it then it
will
 > never get cleaned up.

I think it's wrong, in principle, for OpenJDK source code to contain
identifiers naming specific vendors of JDK implementations.  We're not
quite there at the moment, but let's please not add any more.

- Mark

Re: building 7u on macosx

[David Holmes]

On 22/04/2014 1:25 PM, Pete Brunet wrote:


On 4/21/14 9:30 PM, David Holmes wrote:

On 19/04/2014 5:25 AM, Pete Brunet wrote:

Success.  I found this post from Arun Gupta:
https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on

which specifies this

make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true
ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v1.6`
HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`

rather than this

CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+` HOTSPOT_BUILD_JOBS=`sysctl
-n hw.ncpu`

at https://wiki.openjdk.java.net/display/MacOSXPort/Main

The differences are:
- At the front, remove:  CPATH="/usr/X11/include" LANG=C
- Add this:  SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true


You missed the v1.6 vs v1.7+ on the ALT_BOOTDIR setting. I suspect
that is the real difference.

Thanks David, That makes sense.  What does -v do?  I didn't find a spec
describing it.  -Pete


I would assume it selects the version of the JDK to run. It's an Apple 
JDK, or perhaps an OS X software installation, option.


David



David
-


I didn't yet investigate if there is a subset of the changes that would
be successful.

Pete

On 4/18/14 1:43 PM, Pete Brunet wrote:

I see Mac downloads for 7u55 so I should be able to build 7u.  But the
instructions at
https://wiki.openjdk.java.net/display/MacOSXPort/Main
are for 8 so maybe the instructions are different for 7?  The
instuctions in the 7 section of
http://openjdk.java.net/groups/build/
have no mention of mac os x.

Pete

On 4/18/14 11:59 AM, Pete Brunet wrote:

Maybe 7 is not supported?  The reason I am trying to build it is to
back
port two bugs from 9, but maybe that's not needed.

On 4/18/14 11:39 AM, Pete Brunet wrote:

Hi, It's been a long time since I built 7 on macosx.  Refering to

https://wiki.openjdk.java.net/display/MacOSXPort/Main

I see these instructions

CPATH="/usr/X11/include" LANG=C make ALLOW_DOWNLOADS=true
ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
HOTSPOT_BUILD_JOBS=`sysctl
-n hw.ncpu`

but that fails.  See the log below.

Are the instructions still OK?

Pete

ptb-mbp-2:jdk7 petebrunet$ CPATH="/usr/X11/include" LANG=C make
ALLOW_DOWNLOADS=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7+`
HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu`
( cd  ./jdk/make && \
make sanity HOTSPOT_IMPORT_CHECK=false
JDK_TOPDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk
JDK_MAKE_SHARED_DIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/jdk/make/common/shared

EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00
JDK_BUILD_NUMBER=b00
FULL_VERSION=1.7.0-internal-petebrunet_2014_04_18_11_07-b00
PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6
PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
ALT_OUTPUTDIR=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64

ALT_LANGTOOLS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/langtools/dist

ALT_CORBA_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/corba/dist

ALT_JAXP_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxp/dist

ALT_JAXWS_DIST=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/jaxws/dist

ALT_HOTSPOT_IMPORT_PATH=/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import

BUILD_HOTSPOT=true ; )

Build Machine Information:
 build machine = ptb-mbp-2.local

Build Directory Structure:
 CWD = /Users/petebrunet/JDK7u/JDK-8041112/jdk7
 TOPDIR = .
 LANGTOOLS_TOPDIR = ./langtools
 JAXP_TOPDIR = ./jaxp
 JAXWS_TOPDIR = ./jaxws
 CORBA_TOPDIR = ./corba
 HOTSPOT_TOPDIR = ./hotspot
 JDK_TOPDIR = ./jdk

Build Directives:
 BUILD_LANGTOOLS = true
 BUILD_JAXP = true
 BUILD_JAXWS = true
 BUILD_CORBA = true
 BUILD_HOTSPOT = true
 BUILD_JDK= true
 DEBUG_CLASSFILES =
 DEBUG_BINARIES =

Hotspot Settings:
HOTSPOT_BUILD_JOBS  = 8
HOTSPOT_OUTPUTDIR   =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/outputdir


HOTSPOT_EXPORT_PATH =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64/hotspot/import





Bootstrap Settings:
BOOTDIR =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
  ALT_BOOTDIR =
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
BOOT_VER = 1.8.0 [requires at least 1.6]
OUTPUTDIR =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
  ALT_OUTPUTDIR =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64
ABS_OUTPUTDIR =
/Users/petebrunet/JDK7u/JDK-8041112/jdk7/build/macosx-x86_64

Build Tool Settings:
SLASH_JAVA = /java
  ALT_SLASH_JAVA =
VARIANT = OPT
JDK_DEVTOOLS_DIR = /java/devtools
  ALT_JDK_DEVTOOLS_DIR =
ANT_HOME =
UNIXCOMMAND_PATH = /bin/
   

Result: Nomination of Tim Bell as the new Build Group Lead

[Erik Joelsson]

Voting for Build Group Lead Tim Bell [1] is now closed.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Simple Majority, this is
sufficient to approve the new Group Lead.  The OpenJDK Lead will
ask the Governing Board to ratify this nomination.

Erik Joelsson (on behalf of Magnus Ihse Bursie)

[1] http://mail.openjdk.java.net/pipermail/build-dev/2014-April/012269.html

Re: RFR: 8041151: More concurrent hgforest.

[Chris Hegarty]

> On 22 Apr 2014, at 09:10, Erik Joelsson  wrote:
> 
> Seems to work for me too. Nice speedup! Looks good to me.

+1.  Thanks for doing these improvements Mike.

-Chris.

> 
> /Erik
> 
>> On 2014-04-19 01:21, Mike Duigou wrote:
>> Hello all;
>> 
>> This is an improvement to hgforest to increase it's concurrency behaviour. 
>> Currently hgforest.sh limits the rate at which it starts new sub-processes 
>> because it wants to limit the number of concurrent tasks. The naive approach 
>> it takes can cause unnecessary delays. For sequences of operations that are 
>> entirely local the overhead of waiting is significant. The revised 
>> implementation uses fifos for completion notification on capable platforms 
>> or compares started task count to completed task count in a shorter sleep 
>> loop.
>> 
>> The intention is to use the enhanced concurrency to allow for a fancier 
>> get_source.sh that can handle rebasing for mq patches. This involves running 
>> a half dozen commands through hgforest. With my current in-development 
>> get_source.sh script changes these hgforest changes provide a 10X speedup. 
>> (4s vs 40s)
>> 
>> The changeset also incorporates a build-dev suggested improvement to extra 
>> base repo url handling and other minor fixes (status code from subprocesses).
>> 
>> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
>> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
>> 
>> I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) 
>> and Cygwin x64
>> 
>> Cheers,
>> 
>> Mike
> 

Re: RFR: 8041151: More concurrent hgforest.

[Staffan Larsen]

I ran the patch on OS X and it worked there too. Thanks!

You mention “status code from subprocesses” which got me thinking of a problem 
I frequently run into when I have some uncommitted changes in one of the repos:

...
.:   searching for changes
.:   adding changesets
.:   adding manifests
.:   adding file changes
.:   added 1 changesets with 2 changes to 2 files (+1 heads)
.:   not updating: not a linear update
.:   (merge or update --check to force update)
...

This output is frequently lost to me in all the other output, would it be 
possible to catch these errors and somehow highlight the failure at the end of 
the run? I guess I could go spelunking in the code to find out, but I’m too 
lazy and prefer to bother someone else. :)

Thanks,
/Staffan

On 19 apr 2014, at 01:21, Mike Duigou  wrote:

> Hello all;
> 
> This is an improvement to hgforest to increase it's concurrency behaviour. 
> Currently hgforest.sh limits the rate at which it starts new sub-processes 
> because it wants to limit the number of concurrent tasks. The naive approach 
> it takes can cause unnecessary delays. For sequences of operations that are 
> entirely local the overhead of waiting is significant. The revised 
> implementation uses fifos for completion notification on capable platforms or 
> compares started task count to completed task count in a shorter sleep loop.
> 
> The intention is to use the enhanced concurrency to allow for a fancier 
> get_source.sh that can handle rebasing for mq patches. This involves running 
> a half dozen commands through hgforest. With my current in-development 
> get_source.sh script changes these hgforest changes provide a 10X speedup. 
> (4s vs 40s)
> 
> The changeset also incorporates a build-dev suggested improvement to extra 
> base repo url handling and other minor fixes (status code from subprocesses).
> 
> JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
> WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/
> 
> I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) 
> and Cygwin x64
> 
> Cheers,
> 
> Mike
> 

Re: RFR: 8041267 : (s) Add filtering capability to CacheFind

[Erik Joelsson]

Hello Mike,

This will probably work fine. Perhaps a note on the formatting of the 
new argument is needed? From what I can tell it needs to always start 
with "-a".


I can't help but think that there might be a need for named caches at 
some point if this is introduced, but I will add that if I find a need 
for it.


/Erik

On 2014-04-19 20:54, Mike Duigou wrote:

Hello all;

In some cases the results of find operations need to be more specific. Adding a 
filter capability to the find/caching stage would reduce the overhead of some 
requests. This changeset adds an optional second parameter allowing a find 
expression to provide additional filtering of find results.

JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041267
WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041267/0/webrev/

Once the functionality is available it will be used in CreateJars.gmk, 
GensrcProperties.gmk, and Images.gmk to narrow find results.

Mike

Re: RFR: 8007327: (xxs) Emit MEMORY_SIZE into spec.gmk

[Erik Joelsson]

Looks good.
/Erik

On 2014-04-19 02:23, Mike Duigou wrote:

Hello all;

This is a very simple patch which causes the already calculated MEMORY_SIZE 
variable to be emitted into the spec.gmk where it can be used by make scripts. 
Generally this will be to provide a different calculation of the number of 
concurrent jobs.

JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8007327
WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8007327/0/webrev/

Mike

Re: RFR: 8041151: More concurrent hgforest.

[Erik Joelsson]

Seems to work for me too. Nice speedup! Looks good to me.

/Erik

On 2014-04-19 01:21, Mike Duigou wrote:

Hello all;

This is an improvement to hgforest to increase it's concurrency behaviour. 
Currently hgforest.sh limits the rate at which it starts new sub-processes 
because it wants to limit the number of concurrent tasks. The naive approach it 
takes can cause unnecessary delays. For sequences of operations that are 
entirely local the overhead of waiting is significant. The revised 
implementation uses fifos for completion notification on capable platforms or 
compares started task count to completed task count in a shorter sleep loop.

The intention is to use the enhanced concurrency to allow for a fancier 
get_source.sh that can handle rebasing for mq patches. This involves running a 
half dozen commands through hgforest. With my current in-development 
get_source.sh script changes these hgforest changes provide a 10X speedup. (4s 
vs 40s)

The changeset also incorporates a build-dev suggested improvement to extra base 
repo url handling and other minor fixes (status code from subprocesses).

JBSBUG: https://bugs.openjdk.java.net/browse/JDK-8041151
WEBREV: http://cr.openjdk.java.net/~mduigou/JDK-8041151/0/webrev/

I've so far tested it on successfully on Linux (Ubuntu 13.10) Solaris (10u9) 
and Cygwin x64

Cheers,

Mike

Re: jdk7u full build fails on Win - unable to load zip.dll

[Erik Joelsson]

The build is trying to run rmic using the newly built jdk. It seems 
there is a problem with the zip.dll that you just built. Are you able to 
run 
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/bin/java at 
all?


/Erik

On 2014-04-18 23:56, Pete Brunet wrote:

p.s. The ALT_BOOTDIR specifies 6u45.

On 4/18/14 4:53 PM, Pete Brunet wrote:

A full 7u build currently fails like this:

make[6]: Entering directory
`/cygdrive/c/Users/Pete/JDK7u/jdk7-clone/jdk7/jdk/make/com/sun/jmx'
/usr/bin/mkdir -p
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi
rm -f
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/bin/java
-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
-client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
sun.rmi.rmic.Main -classpath
"C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes"
\
 -d
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586/../windows-i586-fastdebug/classes
\
 -v1.2   \
 -keepgenerated  \
 javax.management.remote.rmi.RMIConnectionImpl
Error occurred during initialization of VM
Unable to load ZIP library:
C:\Users\Pete\JDK7u\jdk7-clone\jdk7\build\windows-i586-fastdebug\bin\zip.dll

I have BUILD_DEPLOY and BUILD_INSTALL set to off.  I mention that
because this was advice much earlier when hitting the same problem.

Any ideas?

Pete

Re: Problems about building JDK9 on windows

[Erik Joelsson]

That didn't help much unfortunately. I'm suspecting something strange in 
your environment. Could you try applying this patch and post then post 
the contents of full-vs-env.txt?



diff -r 9d88779ac71e common/autoconf/toolchain_windows.m4
--- a/common/autoconf/toolchain_windows.m4  Mon Apr 21 20:17:00 2014 
-0400
+++ b/common/autoconf/toolchain_windows.m4  Tue Apr 22 09:52:11 2014 
+0200

@@ -164,6 +164,7 @@
 # C:/CygWin/bin/bash -c 'echo VS_PATH=\"$PATH\" > localdevenv.sh
 # The trailing space for everyone except PATH is no typo, but is 
needed due

 # to trailing \ in the Windows paths. These will be stripped later.
+$ECHO "set > full-vs-env.txt" >> $EXTRACT_VC_ENV_BAT_FILE
 $ECHO "$WINPATH_BASH -c 'echo VS_PATH="'\"$PATH\" > set-vs-env.sh' 
>> $EXTRACT_VC_ENV_BAT_FILE
 $ECHO "$WINPATH_BASH -c 'echo VS_INCLUDE="'\"$INCLUDE \" >> 
set-vs-env.sh' >> $EXTRACT_VC_ENV_BAT_FILE
 $ECHO "$WINPATH_BASH -c 'echo VS_LIB="'\"$LIB \" >> set-vs-env.sh' 
>> $EXTRACT_VC_ENV_BAT_FILEOn 2014-04-18 01:17,



/Erik

Amanda Jiang wrote:

Hi Volker,

As Erik mentioned, localdevenv.sh is not existed.

The toolchain detection part from config.log are pasted below:

Command: /cygdrive/c/Users/amjiang/workspace/tools/jdk1.8.0/bin/java 
-Xmx512M -version

configure:26179: result:  -XX:+UseSerialGC -Xms32M -Xmx512M
configure:26624: Using default toolchain microsoft (Microsoft Visual 
Studio)

configure:26657: checking for link
configure:26675: found /cygdrive/c/Program Files (x86)/Microsoft 
Visual Studio 10.0/VC/bin/link
configure:26687: result: /cygdrive/c/Program Files (x86)/Microsoft 
Visual Studio 10.0/VC/bin/link
configure:26696: checking if the first found link.exe is actually the 
Cygwin link tool

configure:26703: result: no
configure:26778: Found Visual Studio installation at 
/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/ using 
VS100COMNTOOLS variable
configure:27348: Rewriting VS_ENV_CMD to 
"/cygdrive/c/progra~2/micros~2.0/vc/bin/vcvars32.bat"

configure:27354: Trying to extract Visual Studio environment variables
configure:27423: Setting extracted environment variables
configure:27435: checking for Visual Studio variables
configure:27444: result: ok
configure:27650: checking for cl
configure:27668: found /cygdrive/c/Program Files (x86)/Microsoft 
Visual Studio 10.0/VC/BIN/cl
configure:27680: result: /cygdrive/c/Program Files (x86)/Microsoft 
Visual Studio 10.0/VC/BIN/cl
configure:27991: Rewriting CC to 
"/cygdrive/c/progra~2/micros~2.0/vc/bin/cl"

configure:28000: checking resolved symbolic links for CC
configure:28050: result: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl
configure:28053: checking if CC is disguised ccache
configure:28491: result: no, keeping CC
configure:28612: Using microsoft C compiler version 16.00.30319.01 
[Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86]

configure:28729: checking for C compiler version
configure:28738: /cygdrive/c/progra~2/micros~2.0/vc/bin/cl --version >&5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 
for 80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

Thanks,
Amanda

On 4/17/14 1:37 AM, Erik Joelsson wrote:

Hello Volker,

On 2014-04-17 10:26, Volker Simonis wrote:

Hi,

what is "set-vs-env.sh"? I can not find that in my output directory.

I think the variables INCLUDE and LIB from which VS_INCLUDE and VS_LIB
are derived are in /localdevenv.sh
That depends what source you are building. Magnus recently changed 
the part of configure that extracts these variables from Visual Studio.
Amanda, could you please also post the contents of 
/localdevenv.sh

Since you have set-vs-env.sh, localdevenv.sh will not be found.

Also please post the part of config.log where the toolchain detection
starts (i.e. something like "configure:26374: Using default toolchain
microsoft (Microsoft Visual Studio)") up tot he part you already
posted.

Yes, this would be the next place to look.

/Erik

Regards,
Volker

On Thu, Apr 17, 2014 at 1:02 AM, Magnus Ihse Bursie
 wrote:
On 16 apr 2014, at 21:00, Amanda Jiang  
wrote:

VS_INCLUDE=" "
VS_LIB=" "
These should not be empty. It is the cause of your failures. The 
question is why they are empty, though...


/Magnus