hg: jdk8/build/langtools: 8 new changesets

[david . katleman]

Changeset: a39c99192184
Author:katleman
Date:  2012-06-21 17:08 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/a39c99192184

Added tag jdk8-b44 for changeset 59cbead12ff4

! .hgtags

Changeset: 9cafabb5e576
Author:ksrini
Date:  2012-06-11 15:33 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/9cafabb5e576

7160072: (javac) JavacParserTests needs cleanup
Reviewed-by: jjg

! test/tools/javac/parser/JavacParserTest.java

Changeset: e534aa747b22
Author:lana
Date:  2012-06-17 21:37 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/e534aa747b22

Merge


Changeset: 34e254ffd0e7
Author:mcimadamore
Date:  2012-06-19 13:25 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/34e254ffd0e7

7177701: error: Filling jar message during 
javax/imageio/metadata/IIOMetadataFormatImpl compilation
Summary: Recent JDK hash changes affected order in which files are returned 
from JavacFileManager.list()
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java

Changeset: 5c0b3faeb0b0
Author:jjg
Date:  2012-06-20 13:23 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/5c0b3faeb0b0

7174143: encapsulate doc comment table
Reviewed-by: ksrini, mcimadamore

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/CRTable.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
- src/share/classes/com/sun/tools/javac/parser/EndPosTable.java
! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
+ src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java
+ src/share/classes/com/sun/tools/javac/tree/EndPosTable.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/tree/DocCommentToplevelTest.java
! test/tools/javac/tree/TreePosTest.java

Changeset: 067f51db3402
Author:jjg
Date:  2012-06-21 13:22 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/067f51db3402

7178297: provide mapping from doc comment position to source file position
Reviewed-by: mcimadamore, ksrini

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java

Changeset: 3468519d9b45
Author:jjg
Date:  2012-06-22 14:40 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/3468519d9b45

7178763: javadoc OutOfMemory error results in several jdk8 tl nightly failures
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java

Changeset: e111e4587cca
Author:lana
Date:  2012-06-25 21:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/langtools/rev/e111e4587cca

Merge

- src/share/classes/com/sun/tools/javac/parser/EndPosTable.java

hg: jdk8/build/jaxws: Added tag jdk8-b44 for changeset f6a417540ef1

[david . katleman]

Changeset: e80ac58b5ba9
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/jaxws/rev/e80ac58b5ba9

Added tag jdk8-b44 for changeset f6a417540ef1

! .hgtags

hg: jdk8/build/hotspot: 11 new changesets

[david . katleman]

Changeset: 0976e71907b9
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0976e71907b9

Added tag jdk8-b44 for changeset 831e5c76a20a

! .hgtags

Changeset: 1e76463170b3
Author:kamg
Date:  2012-03-29 18:55 -0400
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1e76463170b3

7110720: Issue with vm config file loadingIssue with vm config file loading
Summary: disabling default config files if -XX:-ReadDefaultConfigFiles
Reviewed-by: phh, jrose, dcubed, dholmes

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/compiler/compilerOracle.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/7110720/Test7110720.sh

Changeset: e778c29768e6
Author:never
Date:  2012-04-04 20:44 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e778c29768e6

7152811: Issues in client compiler
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciField.hpp

Changeset: 958bb4b7be49
Author:asaha
Date:  2012-04-10 10:42 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/958bb4b7be49

Merge

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

Changeset: aa07e41a9f80
Author:never
Date:  2012-04-12 12:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aa07e41a9f80

7160677: missing else in fix for 7152811
Reviewed-by: kvn, kevinw

! src/share/vm/ci/ciField.cpp

Changeset: 5142b5110214
Author:asaha
Date:  2012-05-08 07:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5142b5110214

Merge

! src/share/vm/opto/runtime.cpp

Changeset: d558e01a72c0
Author:kamg
Date:  2012-05-03 15:37 -0400
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d558e01a72c0

7160757: Problem with hotspot/runtime_classfile
Summary: Allow only current and super invokespecials of 
Reviewed-by: never, coleenp, dcubed

! src/share/vm/classfile/verifier.cpp
+ test/runtime/7160757/Test7160757.java

Changeset: 6d2c830e025d
Author:asaha
Date:  2012-05-08 11:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6d2c830e025d

Merge


Changeset: 84e198dc2474
Author:asaha
Date:  2012-05-21 14:56 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/84e198dc2474

Merge

- src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: f9d57285de70
Author:asaha
Date:  2012-06-07 12:30 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f9d57285de70

Merge

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

Changeset: 9d5f20961bc5
Author:lana
Date:  2012-06-26 10:27 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9d5f20961bc5

Merge

! src/share/vm/classfile/verifier.cpp

hg: jdk8/build/corba: 9 new changesets

[david . katleman]

Changeset: ad3ba4b392cc
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/ad3ba4b392cc

Added tag jdk8-b44 for changeset 439d9bf8e4ff

! .hgtags

Changeset: 5222b7d658d4
Author:coffeys
Date:  2012-03-26 14:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/5222b7d658d4

7143851: Improve IIOP stub and tie generation in RMIC
7149048: Changes to corba rmic stubGenerator class are not used during jdk 
build process
Reviewed-by: mschoene, robm

! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java

Changeset: e324dfb90c9e
Author:mbankal
Date:  2012-03-28 02:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/e324dfb90c9e

7079902: Refine CORBA data models
Reviewed-by: coffeys

! 
src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java
! 
src/share/classes/com/sun/corba/se/impl/interceptors/ServerRequestInfoImpl.java
! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java
! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java
! src/share/classes/com/sun/corba/se/impl/oa/toa/TOAFactory.java
! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java
! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java
! 
src/share/classes/com/sun/corba/se/impl/protocol/LocalClientRequestDispatcherBase.java
! src/share/classes/com/sun/corba/se/impl/util/RepositoryId.java
! src/share/classes/com/sun/corba/se/spi/logging/CORBALogDomains.java
! src/share/classes/sun/rmi/rmic/iiop/IDLNames.java

Changeset: 2846cb957582
Author:mbankal
Date:  2012-03-28 02:53 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/2846cb957582

Merge


Changeset: a00c5c0b1f30
Author:asaha
Date:  2012-04-10 10:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/a00c5c0b1f30

Merge

- make/tools/src/build/tools/stripproperties/StripProperties.java

Changeset: 3697feea6f54
Author:asaha
Date:  2012-05-08 07:27 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/3697feea6f54

Merge


Changeset: 787fb5a0602f
Author:asaha
Date:  2012-05-21 14:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/787fb5a0602f

Merge


Changeset: 25bb958d07de
Author:asaha
Date:  2012-06-07 12:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/25bb958d07de

Merge


Changeset: 747dad9e9d37
Author:lana
Date:  2012-06-26 10:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/corba/rev/747dad9e9d37

Merge

hg: jdk8/build: 4 new changesets

[david . katleman]

Changeset: 1e989139ce0d
Author:katleman
Date:  2012-06-21 17:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/rev/1e989139ce0d

Added tag jdk8-b44 for changeset e4f81a817447

! .hgtags

Changeset: 1af3996aa431
Author:sla
Date:  2012-06-11 20:52 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/rev/1af3996aa431

7175802: Missing jdk_jfr in top-level make file
Reviewed-by: alanb

! test/Makefile

Changeset: 67e1fb3b2b33
Author:lana
Date:  2012-06-17 21:27 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/rev/67e1fb3b2b33

Merge


Changeset: 633f2378c904
Author:lana
Date:  2012-06-25 21:37 -0700
URL:   http://hg.openjdk.java.net/jdk8/build/rev/633f2378c904

Merge

Re: Round two - RFR (7152336): Enable OpenJDK builds on Windows with MinGW/MSYS

[John Coomes]

Tim Bell (tim.b...@oracle.com) wrote:
> I went over the open changes again and removed some debug code left in
> by mistake, updated copyright dates and fixed a few typos.  Here is an
> updated webrev:
> 
>  http://cr.openjdk.java.net/~tbell/7152336/webrev.01/
> 
> These changes are building in both 32 and 64 bit mode on my Windows 7 
> system.
> 
> jtreg test runs of the '-automatic -noshell' tests under test/java/lang 
> test/java/math test/java/util ran as expected (2 failures, both known 
> bugs).

I only looked at the hotspot changes, which are fine.
One minor request.  In hotspot/make/windows/makefiles/defs.make:

 215 else
 216   ifeq ($(USING_MINGW), true)
 217 ABS_OUTPUTDIR   := $(shell $(CD) $(OUTPUTDIR);$(PWD))
 218 ABS_BOOTDIR := $(shell $(CD) $(BOOTDIR);$(PWD))
 219 ABS_GAMMADIR:= $(shell $(CD) $(GAMMADIR);$(PWD))
 220 ABS_OS_MAKEFILE := $(shell $(CD) 
$(HS_MAKE_DIR)/$(OSNAME);$(PWD))/build.make
 221   else

You can append line 216 to 215, e.g.,

 215 else ifeq ($(USING_MINGW), true)

which eliminates some indentation and an endif, and I find easier to
read.

-John

> Thanks in advance for your review and feedback - I'd like to get these 
> changes in soon.
> 
> Tim Bell
> 
> 
> On 06/13/12 22:31, Tim Bell wrote:
> > Hello everyone-
> >
> > Kelly asked me to pick up on bug #/7152336 "//Enable builds on Windows 
> > with MinGW/MSYS"/, and this email thread:
> >
> > http://mail.openjdk.java.net/pipermail/build-dev/2012-April/thread.html#6083
> >  
> >
> >
> > As David pointed out, we will need at least one other bug # for the 
> > hotspot changes.  That said, this is enough to get me started.
> >
> > Hi Volker:
> >
> > I have applied the patches originally from your posting.  Many thanks 
> > for that:
> > http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/
> >
> > With a few modifications (keep cpio for non MinGW/Msys builds, keep 
> > MKS as an option), the proposed changes are visible here for review:
> >
> >   http://cr.openjdk.java.net/~tbell/7152336/webrev.00/
> >
> > For reference, my test build log is visible here:
> >
> > http://cr.openjdk.java.net/~tbell/7152336/webrev.00/full_control_build_no_docs.log
> >  
> >
> >
> > Additional test builds on JPRT (our internal build apparatus) verified 
> > that I didn't regress the existing build.
> >
> > Abbreviated jtreg [1] testing on this build was successful:
> >
> > $ /d/tools/jdk8/7152336/windows-i586/bin/java -jar 
> > /d/tools/jtreg-internal/jtreg/lib/jtreg.jar -automatic -noshell 
> > test/java/lang test/java/math test/java/util
> > Directory "JTreport" not found: creating
> > Directory "JTwork" not found: creating
> > Directory "JTwork\scratch" not found: creating
> > Test results: passed: 698; failed: 1; error: 5
> > Report written to D:\tools\jdk8\7152336\jdk\JTreport\html\report.html
> > Results written to D:\tools\jdk8\7152336\jdk\JTwork
> > Error: Some tests failed or other problems occurred.
> >
> > The failing test (java/lang/Math/WorstCaseTests.java) is due to a 
> > known regression: 7174532 
> >  
> > "jdk/test/java/lang/Math/WorstCaseTests.java failing on x86"
> >
> > The 5 error tests are all ignored until bug xxx (for some value of 
> > x) is resolved.
> >
> > Thanks in advance for your review and feedback -
> >
> > Tim Bell
> >
> > [1]  http://openjdk.java.net/projects/code-tools/
> >
> 

Re: why can I not download the /jdk repository

[Kelly O'Hair]

I found this old documentation when I worked on the JavaFX project, maybe this 
helps:

TortoiseHG (Windows)

Get the TortoiseHG Download bundle and install it. It install into the 
directory:
"C:/Program Files/TortoiseHG/".
After installing it:

Edit the file "C:/Program Files/TortoiseHG/Mercurial.ini" and make sure the ssh 
command used is from CYGWIN and not Plink. Unless of course you want to use 
Plink, it's up to you.
Prepend "C:/Program Files/TortoiseHG/" to your PATH, make sure it is before 
/usr/bin, so that running hg version tells you it is TortoiseHG.
Mercurial Tips

On Windows, the default CYGWIN hg will not work on some of the repositories, so 
you can downgrade the CYGWIN hg version to 1.0.2 or switch to use the 
TortoiseHG build of Mercurial, which is a 1.3.1 or newer version. The problem 
centers around the Windows limits to full pathnames. Mercurial .hg/ files can 
end up with much longer filenames than the file they represent in the working 
set, or the files you edit. The most recent releases of Mercurial have 
optimized these path lengths, but versions like 1.1 had made the problem worse, 
resulting in some of our repositories not cloning. Version 1.0.2 was ok, but 
1.3.1 or newer is best. Unfortunately, at this time, 1.3.1 is not available 
with CYGWIN.
On Windows, the CYGWIN hg is a Python script and doesn't play well with the 
native Windows system. Some ant scripts try and run hg and ant will fail when 
running a Python script. Using TortoiseHG solves this problem because it 
provides a hg.exe.
-kto

On Jun 27, 2012, at 10:32 AM, Volker Simonis wrote:

> Hi,
> 
> this may be related to Cygwin. The error "C770817@C036357
> /cygdrive/e/OpenJDK/jdk8" indicates that you are using a
> "Cygwin-Mercurial". I would recommend to install and use a native
> Windows Mercurial (e.g.
> http://tortoisehg.bitbucket.org/download/index.html) and try with that
> one.
> 
> I never had problems cloning with tortoisehg, also I didn't succeed to
> push with it (I think because of some ssh/private-key issues). So I
> use the Cygwin hg for pushing, but that's not very stable for me
> either...
> 
> Regards,
> Volker
> 
> On Wed, Jun 27, 2012 at 6:59 PM, Stadelmann Josef
>  wrote:
>> Just o inform you before I give up.
>> 
>> At the README of jdk7 or jdk8 one can read
>> 
>> ---
>> 
>> This one root repository can be obtained with something like:
>> 
>> hg clone http://hg.openjdk.java.net/jdk8/jdk8 openjdk8
>> 
>> 
>> 
>>   To make sure you have all the nested repositories, you can run the
>> 
>>   get_source.sh script located in the same respository as this file:
>> 
>> cd openjdk8 && sh ./get_source.sh
>> 
>> ---
>> 
>> Since weeks, running the get_source.sh, download takes place for all
>> 
>> sub-repositories except and always fails for the jdk*/jdk repository.
>> 
>> "hg clone http://hg.openjdk.java.net/jdk7/jdk7/ C:/OpenJDK/jdk7/jdk"
>> 
>> Watching the network, there is an immediate transfer of the .hg subdirectory
>> 
>> but then after about 20 minutes I get an abort error
>> 
>> C770817@C036357 /cygdrive/e/OpenJDK/jdk8
>> 
>> $ hg clone http://hg.openjdk.java.net/jdk8/jdk8/jdk jdk
>> 
>> requesting all changes
>> 
>> abort: error:
>> 
>> WHY?
>> 
>> Once in the past 4 weeks, I was able to download it on a Saturday at home.
>> 
>> Josef

Re: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx

[David Kocher]

I remember having seen this before [1].

[1] http://java.net/jira/browse/MACOSX_PORT-521

On 22.06.2012, at 09:08, Henri Gomez wrote:

>> Staffan and Henri,
>> 
>> I think you guys are talking about different levels of support
>> for MacOS X Universal builds. Staffan's change is in HotSpot
>> which has supported MacOS X Universal builds for a while now.
>> 
>> Henri is talking about the forest of repos which does not
>> currently support MacOS X Universal builds.
> 
> If HotSpot support MacOS X Universal build, may be I could find here
> some support to fix a problem I get with my OpenJDK 7 universal build
> when using 32bits supper (-d32) and server mode (no problem in client
> mode).
> 
> ...
> 
> INFO: AJP13 Listener started: port=8009
> juin 22, 2012 9:02:16 AM winstone.Logger logInternal
> INFO: Winstone Servlet Engine v0.9.10 running: controlPort=disabled
> juin 22, 2012 9:02:17 AM jenkins.InitReactorRunner$1 onAttained
> INFO: Started initialization
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x00f5cb88, pid=495, tid=19971
> #
> # JRE version: 7.0
> # Java VM: OpenJDK Server VM (23.2-b05 mixed mode bsd-x86 )
> # Problematic frame:
> # J  sun.util.calendar.ZoneInfo.getOffsets(J[II)I
> #
> # Failed to write core dump. Core dumps have been disabled. To enable
> core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/henri/Downloads/jenkins/hs_err_pid495.log
> 
> 
> It is easily reproducible :
> 
> - Install OpenJDK 7 (from jdk7u-dev built in universal mode) from my
> googlecode site :
> 
> http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u5-b30-20120621.dmg)
> 
> Then :
> 
> export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home
> 
> mkdir jenkins
> cd jenkins
> curl -L http://mirrors.jenkins-ci.org/war/latest/jenkins.war -o jenkins.war
> mkdir data
> export JENKINS_HOME=`pwd`/data
> java -d32 -jar jenkins.war
> 
> 
> And there is no problem using -d32 -client or -d64.
> 
> Any help from Hotspot guys will be very useful since this problem
> prevent me to ask for universal patch to be reintroduce in OpenJDK 7
> and 8.
> 
> Thanks
> 

Re: why can I not download the /jdk repository

[Volker Simonis]

Hi,

this may be related to Cygwin. The error "C770817@C036357
/cygdrive/e/OpenJDK/jdk8" indicates that you are using a
"Cygwin-Mercurial". I would recommend to install and use a native
Windows Mercurial (e.g.
http://tortoisehg.bitbucket.org/download/index.html) and try with that
one.

I never had problems cloning with tortoisehg, also I didn't succeed to
push with it (I think because of some ssh/private-key issues). So I
use the Cygwin hg for pushing, but that's not very stable for me
either...

Regards,
Volker

On Wed, Jun 27, 2012 at 6:59 PM, Stadelmann Josef
 wrote:
> Just o inform you before I give up.
>
> At the README of jdk7 or jdk8 one can read
>
> ---
>
> This one root repository can be obtained with something like:
>
>     hg clone http://hg.openjdk.java.net/jdk8/jdk8 openjdk8
>
>
>
>   To make sure you have all the nested repositories, you can run the
>
>   get_source.sh script located in the same respository as this file:
>
>     cd openjdk8 && sh ./get_source.sh
>
> ---
>
> Since weeks, running the get_source.sh, download takes place for all
>
> sub-repositories except and always fails for the jdk*/jdk repository.
>
> "hg clone http://hg.openjdk.java.net/jdk7/jdk7/ C:/OpenJDK/jdk7/jdk"
>
> Watching the network, there is an immediate transfer of the .hg subdirectory
>
> but then after about 20 minutes I get an abort error
>
> C770817@C036357 /cygdrive/e/OpenJDK/jdk8
>
> $ hg clone http://hg.openjdk.java.net/jdk8/jdk8/jdk jdk
>
> requesting all changes
>
> abort: error:
>
> WHY?
>
> Once in the past 4 weeks, I was able to download it on a Saturday at home.
>
> Josef

why can I not download the /jdk repository

[Stadelmann Josef]

Just o inform you before I give up.

At the README of jdk7 or jdk8 one can read

---
This one root repository can be obtained with something like:

hg clone http://hg.openjdk.java.net/jdk8/jdk8 openjdk8
  
  To make sure you have all the nested repositories, you can run the
  get_source.sh script located in the same respository as this file:

cd openjdk8 && sh ./get_source.sh
---

Since weeks, running the get_source.sh, download takes place for all
sub-repositories except and always fails for the jdk*/jdk repository.

"hg clone http://hg.openjdk.java.net/jdk7/jdk7/ C:/OpenJDK/jdk7/jdk"

Watching the network, there is an immediate transfer of the .hg
subdirectory
but then after about 20 minutes I get an abort error

C770817@C036357 /cygdrive/e/OpenJDK/jdk8
$ hg clone http://hg.openjdk.java.net/jdk8/jdk8/jdk jdk
requesting all changes
abort: error:

WHY?

Once in the past 4 weeks, I was able to download it on a Saturday at
home.

Josef

Round two - RFR (7152336): Enable OpenJDK builds on Windows with MinGW/MSYS

[Tim Bell]

I went over the open changes again and removed some debug code left in
by mistake, updated copyright dates and fixed a few typos.  Here is an
updated webrev:

http://cr.openjdk.java.net/~tbell/7152336/webrev.01/

These changes are building in both 32 and 64 bit mode on my Windows 7 
system.


jtreg test runs of the '-automatic -noshell' tests under test/java/lang 
test/java/math test/java/util ran as expected (2 failures, both known 
bugs).


Thanks in advance for your review and feedback - I'd like to get these 
changes in soon.


Tim Bell


On 06/13/12 22:31, Tim Bell wrote:

Hello everyone-

Kelly asked me to pick up on bug #/7152336 "//Enable builds on Windows 
with MinGW/MSYS"/, and this email thread:


http://mail.openjdk.java.net/pipermail/build-dev/2012-April/thread.html#6083 



As David pointed out, we will need at least one other bug # for the 
hotspot changes.  That said, this is enough to get me started.


Hi Volker:

I have applied the patches originally from your posting.  Many thanks 
for that:

http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/

With a few modifications (keep cpio for non MinGW/Msys builds, keep 
MKS as an option), the proposed changes are visible here for review:


  http://cr.openjdk.java.net/~tbell/7152336/webrev.00/

For reference, my test build log is visible here:

http://cr.openjdk.java.net/~tbell/7152336/webrev.00/full_control_build_no_docs.log 



Additional test builds on JPRT (our internal build apparatus) verified 
that I didn't regress the existing build.


Abbreviated jtreg [1] testing on this build was successful:

$ /d/tools/jdk8/7152336/windows-i586/bin/java -jar 
/d/tools/jtreg-internal/jtreg/lib/jtreg.jar -automatic -noshell 
test/java/lang test/java/math test/java/util

Directory "JTreport" not found: creating
Directory "JTwork" not found: creating
Directory "JTwork\scratch" not found: creating
Test results: passed: 698; failed: 1; error: 5
Report written to D:\tools\jdk8\7152336\jdk\JTreport\html\report.html
Results written to D:\tools\jdk8\7152336\jdk\JTwork
Error: Some tests failed or other problems occurred.

The failing test (java/lang/Math/WorstCaseTests.java) is due to a 
known regression: 7174532 
 
"jdk/test/java/lang/Math/WorstCaseTests.java failing on x86"


The 5 error tests are all ignored until bug xxx (for some value of 
x) is resolved.


Thanks in advance for your review and feedback -

Tim Bell

[1]  http://openjdk.java.net/projects/code-tools/

Re: Surprising failure after "make sanity" passed

[Erik Joelsson]

In the build-infra world, the compiler has to be found by configure in 
some way (usually by putting it in the path) at configure time. After 
that the build will use the absolute path found by configure. Configure 
will definitely fail if it can't find a valid compiler.


/Erik

On 2012-06-26 11:08, Kelly O'Hair wrote:

Solaris builds will always be tough.

You need particular versions of the C/C++ compilers (cc/CC or Sun Studio, or 
now Oracle Solaris Studio) in your PATH.

I'm not sure exactly how this will be dealt with in the new build 
infrastructure yet.  But I'll be looking at it today hopefully.

-kto

On Jun 22, 2012, at 5:15 PM, Jonathan Gibbons wrote:


I was doing a top level build, which complained about a few things until I 
fixed them up.   But then the check seemed to be OK and the build proceeded OK, 
until it ran into this issue, and then another issue -- something that was 
brought in from /usr/sfw because of the default setting to enable debug 
symbols. Once I figured out how to disable them, I finally got a build to 
proceed.

I presume the new build system will be better at determining up front 
everything that will be needed during the build.

-- Jon

On 06/22/2012 05:02 PM, David Holmes wrote:

Hi Jon,

On 23/06/2012 5:16 AM, Jonathan Gibbons wrote:

A build of tl passed "make sanity" but I still got this error:


CC -DSOLARIS -DSPARC_WORKS -DIA32
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/share/vm/prims
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/share/vm
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/share/vm/precompiled
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/cpu/x86/vm
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/os_cpu/solaris_x86/vm
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/os/solaris/vm
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/os/posix/vm
-I/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/share/vm/adlc
-I../generated -DASSERT -DTARGET_OS_FAMILY_solaris -DTARGET_ARCH_x86
-DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_solaris_x86
-DTARGET_OS_ARCH_MODEL_solaris_x86_32 -DTARGET_COMPILER_sparcWorks
-DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -D_REENTRANT
-library=Cstd -g -xwe -g -c -o ../generated/adfiles/adlparse.o
/tmp/jjg/7178763-doctree-oome/tl/hotspot/src/share/vm/adlc/adlparse.cpp
make381[6]: CC: Command not found

Was this a JDK sanity check or hotspot? hotspot doesn't really do any sanity 
checking of its own. What did the sanity check report?

David
-


make381[6]: *** [../generated/adfiles/adlparse.o] Error 127
make381[6]: Leaving directory
`/tmp/jjg/7178763-doctree-oome/tl/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product'

make381[5]: *** [ad_stuff] Error 2
make381[5]: Leaving directory
`/tmp/jjg/7178763-doctree-oome/tl/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product'

make381[4]: *** [product] Error 2
make381[4]: Leaving directory
`/tmp/jjg/7178763-doctree-oome/tl/build/solaris-i586/hotspot/outputdir'
make381[3]: *** [generic_build2] Error 2
make381[3]: Leaving directory
`/tmp/jjg/7178763-doctree-oome/tl/hotspot/make'
make381[2]: *** [product] Error 2
make381[2]: Leaving directory
`/tmp/jjg/7178763-doctree-oome/tl/hotspot/make'
make381[1]: *** [hotspot-build] Error 2
make381[1]: Leaving directory `/tmp/jjg/7178763-doctree-oome/tl'
make381: *** [build_product_image] Error 2

Re: Building OpenJDK 6 on Solaris sparc

[Weiqi Gao]

Thank you John.

--
Weiqi Gao

On 6/26/2012 4:17 PM, John Coomes wrote:

Weiqi Gao (weiqi...@gmail.com) wrote:

Hi,

I'm trying to build OpenJDK 6 and OpenJDK 7 on a variety of machines.
I have encountered the following error while building OpenJDK 7
(http://hg.openjdk.java.net/jdk7/jdk7) on Solaris sparc (SunOS cicada2
5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Blade-1000).  I'm using
the suncc5.10 compiler and the lasted jdk1.6.0_32 from Oracle as the
bootstrap JDK.

I'm not sure what's the cause of this problem.  Can anyone shed some
light on it?

rm -f copy.o
CC -DSOLARIS -DSPARC_WORKS -DSPARC -DPRODUCT -xF
...
cg: assertion failed in file ../src/sparc/block_edges.cc at line 581
cg: block_edges.accumulate_successors: bad state
cg: 1 errors

Hi,

That's a bug in the compiler backend.  Make sure you have applied the
patches listed in the README-builds.html file:

http://hg.openjdk.java.net/jdk7/jdk7/raw-file/dada8003df87/README-builds.html#studio

-John

Re: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx

[David Holmes]

On 27/06/2012 6:13 PM, Staffan Larsen wrote:

Can I have a Review for this change, please?


Ok. :)

David


The very simple fix is here:
http://cr.openjdk.java.net/~sla/7178667/webrev.02/

Thanks,
/Staffan

On 25 jun 2012, at 10:36, Staffan Larsen wrote:




So, it sounds like when you rebuilt, everything was built into
jre/lib/i386 and jre/lib/amd64, but never combined (or, in this
case, just copied) into jre/lib, and therefore not found.


Yes. Or rather, only the client jvm was combined, but the client jvm
isn't copied into the j2sdk-image on mac, so nothing was copied.


Which begs the question: if we only build 64-bit on OSX then how/why
is client being built in the first place?


I should have said: "only the client jvm was _attempted_ to be
combined". In fact, the client does not exist, but the universalize
makefiles are written to handle client if it did exist.

So what happened was:
- the product jvm was built
- it was copied to the import jdk (into jre/lib/amd64/server/) by the
generic_export target
- the universalize makefile tried to take the client jvm and
universalize it into jre/lib/client/ (notice that there is no amd64
directory level on mac)
- the universalize makefile removes all {amd64,i386} directories

What should have happened:
- the product jvm was built
- it was copied to the import jdk (into jre/lib/amd64/server/) by the
generic_export target
- the universalize makefile makes a universal binary of any existing
jvms (client or server)
- the universalize makefile copies these jvms into jre/lib/{server,client}
- the universalize makefile removes all {amd64,i386} directories

But because the targets weren't .PHONY, the third step above failed.

I hope that explains the problem in more detail. Who wants to be put
down as reviewer?

Thanks,
/Staffan

Re: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx

[Dmitry Samersoff]

Looks good for me.

-Dmitry

On 2012-06-27 12:13, Staffan Larsen wrote:
> Can I have a Review for this change, please?
> 
> The very simple fix is
> here: http://cr.openjdk.java.net/~sla/7178667/webrev.02/
> 
> Thanks,
> /Staffan
> 
> On 25 jun 2012, at 10:36, Staffan Larsen wrote:
> 
>>
> So, it sounds like when you rebuilt, everything was built into
> jre/lib/i386 and jre/lib/amd64, but never combined (or, in this
> case, just copied) into jre/lib, and therefore not found.

 Yes. Or rather, only the client jvm was combined, but the client jvm
 isn't copied into the j2sdk-image on mac, so nothing was copied.
>>>
>>> Which begs the question: if we only build 64-bit on OSX then how/why
>>> is client being built in the first place?
>>
>> I should have said: "only the client jvm was _attempted_ to be
>> combined". In fact, the client does not exist, but the universalize
>> makefiles are written to handle client if it did exist.
>>
>> So what happened was:
>> - the product jvm was built
>> - it was copied to the import jdk (into jre/lib/amd64/server/) by the
>> generic_export target
>> - the universalize makefile tried to take the client jvm and
>> universalize it into jre/lib/client/ (notice that there is no amd64
>> directory level on mac)
>> - the universalize makefile removes all {amd64,i386} directories
>>
>> What should have happened:
>> - the product jvm was built
>> - it was copied to the import jdk (into jre/lib/amd64/server/) by the
>> generic_export target
>> - the universalize makefile makes a universal binary of any existing
>> jvms (client or server)
>> - the universalize makefile copies these jvms into jre/lib/{server,client}
>> - the universalize makefile removes all {amd64,i386} directories
>>
>> But because the targets weren't .PHONY, the third step above failed.
>>
>> I hope that explains the problem in more detail. Who wants to be put
>> down as reviewer?
>>
>> Thanks,
>> /Staffan
>>
> 


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

Re: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx

[Staffan Larsen]

Can I have a Review for this change, please?

The very simple fix is here: http://cr.openjdk.java.net/~sla/7178667/webrev.02/

Thanks,
/Staffan

On 25 jun 2012, at 10:36, Staffan Larsen wrote:

> 
 So, it sounds like when you rebuilt, everything was built into 
 jre/lib/i386 and jre/lib/amd64, but never combined (or, in this case, just 
 copied) into jre/lib, and therefore not found.
>>> 
>>> Yes. Or rather, only the client jvm was combined, but the client jvm isn't 
>>> copied into the j2sdk-image on mac, so nothing was copied.
>> 
>> Which begs the question: if we only build 64-bit on OSX then how/why is 
>> client being built in the first place?
> 
> I should have said: "only the client jvm was _attempted_ to be combined". In 
> fact, the client does not exist, but the universalize makefiles are written 
> to handle client if it did exist. 
> 
> So what happened was: 
> - the product jvm was built
> - it was copied to the import jdk (into jre/lib/amd64/server/) by the 
> generic_export target
> - the universalize makefile tried to take the client jvm and universalize it 
> into jre/lib/client/ (notice that there is no amd64 directory level on mac)
> - the universalize makefile removes all {amd64,i386} directories
> 
> What should have happened:
> - the product jvm was built
> - it was copied to the import jdk (into jre/lib/amd64/server/) by the 
> generic_export target
> - the universalize makefile makes a universal binary of any existing jvms 
> (client or server)
> - the universalize makefile copies these jvms into jre/lib/{server,client}
> - the universalize makefile removes all {amd64,i386} directories
> 
> But because the targets weren't .PHONY, the third step above failed.
> 
> I hope that explains the problem in more detail. Who wants to be put down as 
> reviewer?
> 
> Thanks,
> /Staffan
>