From vonseg at gmail.com  Wed Jan  4 06:16:12 2012
From: vonseg at gmail.com (John Von Seggern)
Date: Wed, 4 Jan 2012 01:16:12 -0500
Subject: Does OpenJDK statically link the C++ runtime?
Message-ID: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>

Way back in a bug report for Java 1.4, I found this note:

"We statically link the C++ runtime in JDK and enabled linker script
to hide symbols from libstdc++ and other internal symbols."
--http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590

Does OpenJDK continue to take this approach?

I'm asking because I would like to use the Java Native Interface to
call functions in a C++ library (that statically links the C++
runtime).  When I distribute my application, do I need to worry about
C++ ABI compatibility issues?

In case it's useful to anyone, I also asked this question on StackOverflow:
http://stackoverflow.com/questions/8722320/is-the-java-native-interface-jni-affected-by-c-abi-compatibility-issues

(I figured I'd also try asking here, too.  I apologize if this is the
wrong place.)

Thanks,
-John


From luchsh at linux.vnet.ibm.com  Wed Jan  4 08:17:25 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Wed, 04 Jan 2012 16:17:25 +0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <4EF0821C.6070207@linux.vnet.ibm.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>
Message-ID: <4F040B15.8010604@linux.vnet.ibm.com>

Anybody interested in this change? does it sound reasonable?
Thanks and regards!

On 12/20/2011 08:39 PM, Jonathan Lu wrote:
> Hi build-dev,
>
> On some Unix environments, such as AIX, the link option to set library 
> search patch is the same as Solaris. But in current script the  option 
> to link tool freetype_versioncheck is the same as Linux, this makes 
> the tool cannot be compiled on AIX.
> So in order to improve portability, here I propose a patch to adjust 
> the default link option to Solaris' definition.
>
> http://cr.openjdk.java.net/~luchsh/ft_ld_option_sequence/
>
> For other platforms, such as Mac OS X and BSD, I found there's some 
> definitions there in macosx port project[1], so maybe we can just wait 
> for the incoming merge, right?
>
> [1] 
> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/file/2a76fda3fe23/make/tools/freetypecheck/Makefile
>
> Cheers,
> - Jonathan Lu
>



From volker.simonis at gmail.com  Wed Jan  4 10:09:30 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 4 Jan 2012 11:09:30 +0100
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
Message-ID: <CA+3eh13Ex8oCLEhPCarchqAvt8V83taY9cHYTDRYMYgweJn83w@mail.gmail.com>

Regarding your first question: yes, at least the HotSpot (i.e.
libjvm.so) still statically links libstdc++.

You can verify this by looking at make/linux/makefiles/vm.make:

ifeq ($(SHARK_BUILD), true)
  STATIC_CXX = false
else
  ifeq ($(ZERO_LIBARCH), ppc64)
    STATIC_CXX = false
  else
    STATIC_CXX = true
  endif
endif

...

  # JVM is statically linked with libgcc[_s] and libstdc++; this is needed to
  # get around library dependency and compatibility issues. Must use gcc not
  # g++ to link.
  ifeq ($(STATIC_CXX), true)
    LFLAGS_VM              += $(STATIC_LIBGCC)
    LIBS_VM                += $(STATIC_STDCXX)
  else
    LIBS_VM                += -lstdc++
  endif

So for any build except SHARK build and ZERO builds on ppc64,
libstdc++ is statically linked.

STATIC_STDCXX is defined in make/linux/makefiles/gcc.make as:

# statically link libstdc++.so, work with gcc but ignored by g++
STATIC_STDCXX = -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic

Regards,
Volker


On Wed, Jan 4, 2012 at 7:16 AM, John Von Seggern <vonseg at gmail.com> wrote:
> Way back in a bug report for Java 1.4, I found this note:
>
> "We statically link the C++ runtime in JDK and enabled linker script
> to hide symbols from libstdc++ and other internal symbols."
> --http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590
>
> Does OpenJDK continue to take this approach?
>
> I'm asking because I would like to use the Java Native Interface to
> call functions in a C++ library (that statically links the C++
> runtime). ?When I distribute my application, do I need to worry about
> C++ ABI compatibility issues?
>
> In case it's useful to anyone, I also asked this question on StackOverflow:
> http://stackoverflow.com/questions/8722320/is-the-java-native-interface-jni-affected-by-c-abi-compatibility-issues
>
> (I figured I'd also try asking here, too. ?I apologize if this is the
> wrong place.)
>
> Thanks,
> -John


From aph at redhat.com  Wed Jan  4 10:41:11 2012
From: aph at redhat.com (Andrew Haley)
Date: Wed, 04 Jan 2012 10:41:11 +0000
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
Message-ID: <4F042CC7.80903@redhat.com>

On 01/04/2012 06:16 AM, John Von Seggern wrote:
> Way back in a bug report for Java 1.4, I found this note:
> 
> "We statically link the C++ runtime in JDK and enabled linker script
> to hide symbols from libstdc++ and other internal symbols."
> --http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590
> 
> Does OpenJDK continue to take this approach?

Yes it does, but if you're using Linux be aware that most Linux
distros patch this out, AFAIK.

Andrew.


From ahughes at redhat.com  Wed Jan  4 12:42:41 2012
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Wed, 4 Jan 2012 12:42:41 +0000
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <4F042CC7.80903@redhat.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<4F042CC7.80903@redhat.com>
Message-ID: <20120104124241.GF2596@rivendell.middle-earth.co.uk>

On 10:41 Wed 04 Jan     , Andrew Haley wrote:
> On 01/04/2012 06:16 AM, John Von Seggern wrote:
> > Way back in a bug report for Java 1.4, I found this note:
> > 
> > "We statically link the C++ runtime in JDK and enabled linker script
> > to hide symbols from libstdc++ and other internal symbols."
> > --http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590
> > 
> > Does OpenJDK continue to take this approach?
> 
> Yes it does, but if you're using Linux be aware that most Linux
> distros patch this out, AFAIK.
> 

I'm not sure it even needs patching (though we do in IcedTea6).  Setting
STATIC_CXX=false should be enough (it defaults to true).

> Andrew.

-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120104/c2a9d035/signature.asc>

From kelly.ohair at oracle.com  Wed Jan  4 22:15:00 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 Jan 2012 14:15:00 -0800
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
Message-ID: <F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>


On Jan 3, 2012, at 10:16 PM, John Von Seggern wrote:

> Does OpenJDK continue to take this approach?
> 

Depends on who does the build. The default might be to statically link, pretty sure anyway.

> I'm asking because I would like to use the Java Native Interface to
> call functions in a C++ library (that statically links the C++
> runtime).  When I distribute my application, do I need to worry about
> C++ ABI compatibility issues?

When you distribute a C++ application you always need to worry about compatibility issues.

If you statically link in a C++ library, you need to make sure you are not also providing those
interfaces as your own public exported interfaces, if you use the proper version scripts (mapfiles) this
kind of thing can work fine. But it means that you have baked in the implementation of code that
you don't maintain, and any bugs in that code requires you to rebuild your product and re-ship.
There is a maintenance cost to static linking.

So in general, doing static linking is a bad idea and should not be done lightly, if ever.

On Solaris, in OpenJDK makefiles, there is no static linking, or shouldn't be any.

On Windows, we do static linking of some DLLs, but not the primary one MSVCR100.DLL,
except in rare cases, which I try to burn from my memory every time I see them,
and we have lots of debates on that issue. With Windows you have to ship the
MSVC*.DLLs with your product, so there are space considerations, big DLLs here.

On Linux, we shouldn't use static linking, but we had to a long time ago, and we just haven't undone
it completely. Obviously the distros don't want static linking, but when Oracle builds a Linux
distribution, the binaries need to run on a variety of Linux systems, so we need to be careful, and
we don't want to build a separate Oracle JDK for every Linux distro.
It is quite possible that we don't need to static link anything anymore, but that would need to be verified.
When the initial JDK4 work was done on Linux, static links of the C++ runtime was the only way
for us to create binaries that had any chance of running on a variety of distributions of Linux.

Of course, then there is the other sharing issue, the one where you copy the source into your
repository and build your own private version of a library that also ships with the underlying system.
That's another story.

-kto



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120104/541269ce/attachment.htm>

From kelly.ohair at oracle.com  Wed Jan  4 22:35:06 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 Jan 2012 14:35:06 -0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <4F040B15.8010604@linux.vnet.ibm.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>
	<4F040B15.8010604@linux.vnet.ibm.com>
Message-ID: <BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>

The change sounds reasonable, but it's a change to something I have always hated, so it's somewhat distasteful to me
because of that. Having the makefiles build and run an application as part of a sanity check just seems so... 
what is the word....  silly?  :^(

I had hoped that we could just have the sanity check inspect the freetype headers and libraries to
insure the right version, not have to build an application just so we could run it to get the version number.
On the other hand, building this little app is a way to verify that the freetype library links ok.

So to the question of whether this change is ok, basically yes,  but why was this line added:

  53     CC_PROGRAM_OUTPUT_FLAG= -o 

???

-kto


On Jan 4, 2012, at 12:17 AM, Jonathan Lu wrote:

> Anybody interested in this change? does it sound reasonable?
> Thanks and regards!
> 
> On 12/20/2011 08:39 PM, Jonathan Lu wrote:
>> Hi build-dev,
>> 
>> On some Unix environments, such as AIX, the link option to set library search patch is the same as Solaris. But in current script the  option to link tool freetype_versioncheck is the same as Linux, this makes the tool cannot be compiled on AIX.
>> So in order to improve portability, here I propose a patch to adjust the default link option to Solaris' definition.
>> 
>> http://cr.openjdk.java.net/~luchsh/ft_ld_option_sequence/
>> 
>> For other platforms, such as Mac OS X and BSD, I found there's some definitions there in macosx port project[1], so maybe we can just wait for the incoming merge, right?
>> 
>> [1] http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/file/2a76fda3fe23/make/tools/freetypecheck/Makefile
>> 
>> Cheers,
>> - Jonathan Lu
>> 
> 



From david.katleman at sun.com  Wed Jan  4 22:55:45 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 22:55:45 +0000
Subject: hg: jdk8/build: Added tag jdk8-b19 for changeset 237bc29afbfc
Message-ID: <20120104225545.5293A47883@hg.openjdk.java.net>

Changeset: 5a5eaf6374bc
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/rev/5a5eaf6374bc

Added tag jdk8-b19 for changeset 237bc29afbfc

! .hgtags



From david.katleman at sun.com  Wed Jan  4 22:55:52 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 22:55:52 +0000
Subject: hg: jdk8/build/corba: Added tag jdk8-b19 for changeset e1366c5d84ef
Message-ID: <20120104225552.D1E8F47884@hg.openjdk.java.net>

Changeset: 51d8b6cb18c0
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/corba/rev/51d8b6cb18c0

Added tag jdk8-b19 for changeset e1366c5d84ef

! .hgtags



From david.katleman at sun.com  Wed Jan  4 22:56:14 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 22:56:14 +0000
Subject: hg: jdk8/build/hotspot: Added tag jdk8-b19 for changeset 9232e0ecbc2c
Message-ID: <20120104225616.D069E47885@hg.openjdk.java.net>

Changeset: fe2c87649981
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fe2c87649981

Added tag jdk8-b19 for changeset 9232e0ecbc2c

! .hgtags



From david.katleman at sun.com  Wed Jan  4 22:57:15 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 22:57:15 +0000
Subject: hg: jdk8/build/jaxp: Added tag jdk8-b19 for changeset dffeb62b1a7f
Message-ID: <20120104225715.A740947886@hg.openjdk.java.net>

Changeset: f052abb8f374
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxp/rev/f052abb8f374

Added tag jdk8-b19 for changeset dffeb62b1a7f

! .hgtags



From david.katleman at sun.com  Wed Jan  4 22:57:22 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 22:57:22 +0000
Subject: hg: jdk8/build/jaxws: Added tag jdk8-b19 for changeset b73b733214aa
Message-ID: <20120104225722.C6B8F47887@hg.openjdk.java.net>

Changeset: 2b2818e3386f
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxws/rev/2b2818e3386f

Added tag jdk8-b19 for changeset b73b733214aa

! .hgtags



From david.katleman at sun.com  Wed Jan  4 22:58:09 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 22:58:09 +0000
Subject: hg: jdk8/build/jdk: 9 new changesets
Message-ID: <20120104225935.91AB547888@hg.openjdk.java.net>

Changeset: 80350ee39fa8
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/80350ee39fa8

Added tag jdk8-b19 for changeset 3778f8577305

! .hgtags

Changeset: 172d70c50c65
Author:    cgruszka
Date:      2011-09-15 13:59 -0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/172d70c50c65

7066713: Separate demos from the bundles on Solaris and Linux
Summary: add new license files to demos and samples, new directory for bundling
Reviewed-by: katleman, ohair, billyh

! make/common/Release.gmk
! make/common/shared/Defs-control.gmk

Changeset: eaf967fd25c5
Author:    cgruszka
Date:      2011-10-18 14:21 -0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/eaf967fd25c5

7099017: jdk7u2-dev does not build
Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK
Reviewed-by: ohair, billyh

! make/common/Release.gmk

Changeset: 39b7f01203c9
Author:    cgruszka
Date:      2011-11-17 16:57 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/39b7f01203c9

Merge


Changeset: b64e7263b4fd
Author:    cgruszka
Date:      2011-11-18 01:03 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/b64e7263b4fd

Merge


Changeset: e98869ff9f1e
Author:    cgruszka
Date:      2011-12-05 12:41 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/e98869ff9f1e

Merge

- test/java/io/FileDescriptor/FileChannelFDTest.java
- test/java/io/etc/FileDescriptorSharing.java

Changeset: ffa36a6a46f5
Author:    cgruszka
Date:      2011-12-16 15:01 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/ffa36a6a46f5

Merge

- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
- src/share/native/java/util/zip/zlib-1.2.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.2.3/README
- src/share/native/java/util/zip/zlib-1.2.3/compress.c
- src/share/native/java/util/zip/zlib-1.2.3/crc32.h
- src/share/native/java/util/zip/zlib-1.2.3/deflate.c
- src/share/native/java/util/zip/zlib-1.2.3/deflate.h
- src/share/native/java/util/zip/zlib-1.2.3/gzio.c
- src/share/native/java/util/zip/zlib-1.2.3/infback.c
- src/share/native/java/util/zip/zlib-1.2.3/inffast.c
- src/share/native/java/util/zip/zlib-1.2.3/inffast.h
- src/share/native/java/util/zip/zlib-1.2.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.2.3/inflate.c
- src/share/native/java/util/zip/zlib-1.2.3/inflate.h
- src/share/native/java/util/zip/zlib-1.2.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.2.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java
- src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff
- src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff
- src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff
- src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff
- src/share/native/java/util/zip/zlib-1.2.3/trees.c
- src/share/native/java/util/zip/zlib-1.2.3/trees.h
- src/share/native/java/util/zip/zlib-1.2.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.2.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.2.3/zconf.h
- src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.2.3/zlib.h
- src/share/native/java/util/zip/zlib-1.2.3/zutil.c
- src/share/native/java/util/zip/zlib-1.2.3/zutil.h
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
- src/solaris/native/sun/awt/awt_Cursor.h
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh

Changeset: 5fe1525e6e2c
Author:    cgruszka
Date:      2011-12-23 10:43 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/5fe1525e6e2c

Merge


Changeset: 39e938cd1b82
Author:    cgruszka
Date:      2012-01-03 14:34 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/39e938cd1b82

Merge




From david.katleman at sun.com  Wed Jan  4 23:00:43 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 04 Jan 2012 23:00:43 +0000
Subject: hg: jdk8/build/langtools: Added tag jdk8-b19 for changeset
	77b2c066084c
Message-ID: <20120104230045.9605B47889@hg.openjdk.java.net>

Changeset: ffd294128a48
Author:    katleman
Date:      2011-12-29 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/ffd294128a48

Added tag jdk8-b19 for changeset 77b2c066084c

! .hgtags



From kelly.ohair at oracle.com  Wed Jan  4 23:50:35 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 Jan 2012 15:50:35 -0800
Subject: Need reviewer: fixes to prtconf for solaris zones and less execs
Message-ID: <6AAC4DBC-E93D-4C52-AF88-9199DDCC41D6@oracle.com>


Need reviewer: fixes to prtconf for solaris zones and less execs

Basically this patch, will be made to openjdk6, 7u4, and jdk8:

diff --git a/make/common/shared/Platform.gmk b/make/common/shared/Platform.gmk
--- a/make/common/shared/Platform.gmk
+++ b/make/common/shared/Platform.gmk
@@ -147,8 +147,8 @@
   endif
   # Suffix for file bundles used in previous release
   BUNDLE_FILE_SUFFIX=.tar
-  # How much RAM does this machine have:
-  MB_OF_MEMORY=$(shell /usr/sbin/prtconf | fgrep 'Memory size:' | expand | cut -d' ' -f3)
+  # How much RAM does this machine have (zones send an error to stderr):
+  MB_OF_MEMORY:=$(shell /usr/sbin/prtconf 2>/dev/null | fgrep 'Memory size:' | expand | cut -d' ' -f3)
 endif

Solaris zones caise prtconf to spit out an error to stderr which we can safely ignore, and this make variable
should be evaluated just once, so the = was changed to a :=.
This only applied to Solaris.

7127104: Build issue with prtconf and zones, also using := to avoid extra execs
http://cr.openjdk.java.net/~ohair/openjdk6/prtconf-zones-execs/webrev/
http://cr.openjdk.java.net/~ohair/openjdk7/prtconf-zones-execs/webrev/
http://cr.openjdk.java.net/~ohair/openjdk8/prtconf-zones-execs/webrev/

-kto




From david.katleman at oracle.com  Thu Jan  5 00:12:13 2012
From: david.katleman at oracle.com (David Katleman)
Date: Wed, 04 Jan 2012 16:12:13 -0800
Subject: Need reviewer: fixes to prtconf for solaris zones and less execs
In-Reply-To: <6AAC4DBC-E93D-4C52-AF88-9199DDCC41D6@oracle.com>
References: <6AAC4DBC-E93D-4C52-AF88-9199DDCC41D6@oracle.com>
Message-ID: <4F04EADD.40906@oracle.com>

Change looks correct, follows what we discussed.

Thanks

         Dave

On 1/4/2012 3:50 PM, Kelly O'Hair wrote:
> Need reviewer: fixes to prtconf for solaris zones and less execs
>
> Basically this patch, will be made to openjdk6, 7u4, and jdk8:
>
> diff --git a/make/common/shared/Platform.gmk b/make/common/shared/Platform.gmk
> --- a/make/common/shared/Platform.gmk
> +++ b/make/common/shared/Platform.gmk
> @@ -147,8 +147,8 @@
>     endif
>     # Suffix for file bundles used in previous release
>     BUNDLE_FILE_SUFFIX=.tar
> -  # How much RAM does this machine have:
> -  MB_OF_MEMORY=$(shell /usr/sbin/prtconf | fgrep 'Memory size:' | expand | cut -d' ' -f3)
> +  # How much RAM does this machine have (zones send an error to stderr):
> +  MB_OF_MEMORY:=$(shell /usr/sbin/prtconf 2>/dev/null | fgrep 'Memory size:' | expand | cut -d' ' -f3)
>   endif
>
> Solaris zones caise prtconf to spit out an error to stderr which we can safely ignore, and this make variable
> should be evaluated just once, so the = was changed to a :=.
> This only applied to Solaris.
>
> 7127104: Build issue with prtconf and zones, also using := to avoid extra execs
> http://cr.openjdk.java.net/~ohair/openjdk6/prtconf-zones-execs/webrev/
> http://cr.openjdk.java.net/~ohair/openjdk7/prtconf-zones-execs/webrev/
> http://cr.openjdk.java.net/~ohair/openjdk8/prtconf-zones-execs/webrev/
>
> -kto
>
>


From vonseg at gmail.com  Thu Jan  5 01:36:49 2012
From: vonseg at gmail.com (John Von Seggern)
Date: Wed, 4 Jan 2012 20:36:49 -0500
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <20120104124241.GF2596@rivendell.middle-earth.co.uk>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<4F042CC7.80903@redhat.com>
	<20120104124241.GF2596@rivendell.middle-earth.co.uk>
Message-ID: <CANsuF7Zt4AE7zRzvmC5SxGhwRN_6rS_2XgyMWy8nZZhAjSOE=w@mail.gmail.com>

Volker, Andrew, and Andrew,

Thanks for the information.  (In case it's useful to anyone in the
future, I've updated my original stackoverflow question with
everyone's answers.)

Thanks again,
-John

On Wed, Jan 4, 2012 at 7:42 AM, Dr Andrew John Hughes
<ahughes at redhat.com> wrote:
> On 10:41 Wed 04 Jan ? ? , Andrew Haley wrote:
>> On 01/04/2012 06:16 AM, John Von Seggern wrote:
>> > Way back in a bug report for Java 1.4, I found this note:
>> >
>> > "We statically link the C++ runtime in JDK and enabled linker script
>> > to hide symbols from libstdc++ and other internal symbols."
>> > --http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590
>> >
>> > Does OpenJDK continue to take this approach?
>>
>> Yes it does, but if you're using Linux be aware that most Linux
>> distros patch this out, AFAIK.
>>
>
> I'm not sure it even needs patching (though we do in IcedTea6). ?Setting
> STATIC_CXX=false should be enough (it defaults to true).
>
>> Andrew.
>
> --
> Andrew :)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: 248BDC07 (https://keys.indymedia.org/)
> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F ?8F91 3B96 A578 248B DC07


From vonseg at gmail.com  Thu Jan  5 01:43:10 2012
From: vonseg at gmail.com (John Von Seggern)
Date: Wed, 4 Jan 2012 20:43:10 -0500
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>
Message-ID: <CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>

Kelly,
Thanks for taking the time to answer my question.  This information is
very helpful.

> So in general, doing static linking is a bad idea and should not be done lightly, if ever.

As I've been looking into these issues, I've encountered developers
who advise against dynamically loading any C++ code.  For example, a
coworker referred me to this article:

http://www.trilithium.com/johan/2005/06/static-libstdc/

If you don't want to do all that reading, the key quotes are:

1. "C++ ABI changes have been introduced with every major release of GCC"
2. "code compiled against different ABIs is simply not binary compatible."
3. "a fairly workable compromise is to link all C++ code into an
executable while using dynamically loaded C libraries only."
4. "for this to work reliably you must not use dynamically loaded C++ code"

As I understand it, Sun took a similar approach for JDK4.

The blog article and JDK4 are both getting pretty old now, and it
sounds like maybe the situation has changed since then.

> It is quite possible that we don't need to static link anything anymore, but that would need to be verified.

What has changed since JDK4?

> When you distribute a C++ application you always need to worry about compatibility issues.

Do you know of a general approach that addresses these issues?

Feel free to ignore me if answering these questions would take up too
much of your time.  I'm mainly just asking now because I'd like to
know more.  (For my application, I can use the file system rather than
JNI.  JNI would have been more efficient, but this part won't be the
bottle-neck anyway.)

Thanks again,
-John

On Wed, Jan 4, 2012 at 5:15 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>
> On Jan 3, 2012, at 10:16 PM, John Von Seggern wrote:
>
> Does OpenJDK continue to take this approach?
>
>
> Depends on who does the build. The default might be to statically link,
> pretty sure anyway.
>
> I'm asking because I would like to use the Java Native Interface to
> call functions in a C++ library (that statically links the C++
> runtime). ?When I distribute my application, do I need to worry about
> C++ ABI compatibility issues?
>
>
> When you distribute a C++ application you always need to worry
> about?compatibility issues.
>
> If you statically link in a C++ library, you need to make sure you are not
> also providing those
> interfaces as your own public exported interfaces, if you use the proper
> version scripts (mapfiles) this
> kind of thing can work fine. But it means that you have baked in the
> implementation of code that
> you don't maintain, and any bugs in that code requires you to rebuild your
> product and re-ship.
> There is a maintenance cost to static linking.
>
> So in general, doing static linking is a bad idea and should not be done
> lightly, if ever.
>
> On Solaris, in OpenJDK makefiles, there is no static linking, or shouldn't
> be any.
>
> On Windows, we do static linking of some DLLs, but not the primary one
> MSVCR100.DLL,
> except in rare cases, which I try to burn from my memory every time I see
> them,
> and we have lots of debates on that issue. With Windows you have to ship the
> MSVC*.DLLs with your product, so there are space considerations, big DLLs
> here.
>
> On Linux, we shouldn't use static linking, but we had to a long time ago,
> and we just haven't undone
> it completely. Obviously the distros don't want static linking, but when
> Oracle builds a Linux
> distribution, the binaries need to run on a variety of Linux systems, so we
> need to be careful, and
> we don't want to build a separate Oracle JDK for every Linux distro.
> It is quite possible that we don't need to static link anything anymore, but
> that would need to be verified.
> When the initial JDK4 work was done on Linux, static links of the C++
> runtime was the only way
> for us to create binaries that had any chance of running on a variety of
> distributions of Linux.
>
> Of course, then there is the other sharing issue, the one where you copy the
> source into your
> repository and build your own private version of a library that also ships
> with the underlying system.
> That's another story.
>
> -kto
>
>
>


From kelly.ohair at oracle.com  Thu Jan  5 01:43:10 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Thu, 05 Jan 2012 01:43:10 +0000
Subject: hg: jdk8/build/jdk: 7127104: Build issue with prtconf and zones,
	also using := to avoid extra execs
Message-ID: <20120105014322.6B5754788F@hg.openjdk.java.net>

Changeset: ddb97d4fa83d
Author:    ohair
Date:      2012-01-04 17:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/ddb97d4fa83d

7127104: Build issue with prtconf and zones, also using := to avoid extra execs
Reviewed-by: katleman

! make/common/shared/Platform.gmk



From ahughes at redhat.com  Thu Jan  5 02:03:21 2012
From: ahughes at redhat.com (Dr Andrew John Hughes)
Date: Thu, 5 Jan 2012 02:03:21 +0000
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>
	<CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>
Message-ID: <20120105020321.GG18480@rivendell.middle-earth.co.uk>

On 20:43 Wed 04 Jan     , John Von Seggern wrote:
> Kelly,
> Thanks for taking the time to answer my question.  This information is
> very helpful.
> 
> > So in general, doing static linking is a bad idea and should not be done lightly, if ever.
> 

The most obvious issue for me is security.  If a security flaw appears in libstdc++
(or whatever library is linked statically), you have to rebuild to fix it.  So the JDK
has to have a security update due to one of its dependencies.

> As I've been looking into these issues, I've encountered developers
> who advise against dynamically loading any C++ code.  For example, a
> coworker referred me to this article:
> 
> http://www.trilithium.com/johan/2005/06/static-libstdc/
> 
> If you don't want to do all that reading, the key quotes are:
> 
> 1. "C++ ABI changes have been introduced with every major release of GCC"
> 2. "code compiled against different ABIs is simply not binary compatible."
> 3. "a fairly workable compromise is to link all C++ code into an
> executable while using dynamically loaded C libraries only."
> 4. "for this to work reliably you must not use dynamically loaded C++ code"
> 
> As I understand it, Sun took a similar approach for JDK4.
> 

A lot of this depends on development model.

In a FOSS model, the source is available so anyone can perform a rebuild.  Hence,
if they upgrade their compiler, they can simply rebuild its dependencies.  GNU/Linux
is provided in distributions which means that each part of the stack is under the control
of the same entity.  So they know if a gcc upgrade is performed and to do a mass
rebuild of all packages (usually for a new release).  This also shakes out build problems
with that new compiler.  A lot of the work IcedTea (http://icedtea.classpath.org/) has
done with OpenJDK relates to making it work well in this kind of environment.

In a proprietary model, which OpenJDK's build system is designed around, the user is
provided with a blob and has to cross their fingers that it runs.  If it doesn't, all
they can do is go back to the provider and complain.  Hence, it is in the provider's
interest to make that blob compatible with as many systems as possible.  This is done
by statically linking libraries and is also the reason you'll find copies of system
libraries (libpng, libjpeg, zlib, lcms) in the OpenJDK tree as well as libraries like
Gtk+ (for the look and feel) being opened dynamically.  The aim of all that is to
minimise dependencies and make the binary self-contained, but it means that if any
part of the stack has a security issue, a rebuild is necessary.  Such a blob is always
going to be safer in terms of compatibility as all the parts are in the same box.
This is the model followed by applications on Windows and Mac OS platforms, and
leads to issues such as "DLL hell" with dynamically linked bundled libraries, as several
applications all bring their own copies of the same library but different versions.

-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120105/2c1c5cbe/signature.asc>

From kelly.ohair at oracle.com  Thu Jan  5 02:18:38 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 Jan 2012 18:18:38 -0800
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>
	<CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>
Message-ID: <4B721536-89C0-4271-9DC5-C7D784942828@oracle.com>


On Jan 4, 2012, at 5:43 PM, John Von Seggern wrote:

> Kelly,
> Thanks for taking the time to answer my question.  This information is
> very helpful.
> 
>> So in general, doing static linking is a bad idea and should not be done lightly, if ever.
> 
> As I've been looking into these issues, I've encountered developers
> who advise against dynamically loading any C++ code.  For example, a
> coworker referred me to this article:
> 
> http://www.trilithium.com/johan/2005/06/static-libstdc/
> 
> If you don't want to do all that reading, the key quotes are:
> 
> 1. "C++ ABI changes have been introduced with every major release of GCC"
> 2. "code compiled against different ABIs is simply not binary compatible."
> 3. "a fairly workable compromise is to link all C++ code into an
> executable while using dynamically loaded C libraries only."
> 4. "for this to work reliably you must not use dynamically loaded C++ code"
> 
> As I understand it, Sun took a similar approach for JDK4.

Yes, and in 2004/2005, this all may have been true.

But there have always been a bit of a battle between the static and dynamic camps on this topic.
The pro-static people will say you are more predictable and maybe even argue about performance being better.
The pro-dynamic people will say that there a very few bugs in the C++ runtime and all you are doing is
making your product bigger and baking in potential C++ runtime bugs that can't be fixed with a system update.

I'm sure the arguments will go on for a long time.

> 
> The blog article and JDK4 are both getting pretty old now, and it
> sounds like maybe the situation has changed since then.

I think it has. Or rather, I hope it has.

> 
>> It is quite possible that we don't need to static link anything anymore, but that would need to be verified.
> 
> What has changed since JDK4?

The g++ and C++ runtimes have gotten more stable, and as I understand it, the versions of the
C++ runtimes are more readily available on many systems.
Adding a new package to a Linux system is pretty simple now even if you needed to.

> 
>> When you distribute a C++ application you always need to worry about compatibility issues.
> 
> Do you know of a general approach that addresses these issues?

Nope. Sorry.

> 
> Feel free to ignore me if answering these questions would take up too
> much of your time.  I'm mainly just asking now because I'd like to
> know more.  (For my application, I can use the file system rather than
> JNI.  JNI would have been more efficient, but this part won't be the
> bottle-neck anyway.)

If you can avoid JNI I would.
If you can keep your JNI native code trivial, and use C, I'd do that.
If your JNI native code is complicated enough to need C++, I'd wonder why not Java?

Native code development is one thing, but JNI development is another.
With JNI, you get all the hassles of native code development, and also have to make sure that what
you build will work well with all the native code in the JDK, which may have used a different
C/C++ compiler, and/or may depend on using a specific version of the C/C++ runtime.
C is easier than C++ because the runtime issues are not as complicated.
And each JDK release uses a different C/C++ compiler and potentially a different C++ runtime.
Usually, only one C++ runtime is allowed in a process at a time, or at least sanity requires that. ;^)

-kto

> 
> Thanks again,
> -John
> 
> On Wed, Jan 4, 2012 at 5:15 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:
>> 
>> On Jan 3, 2012, at 10:16 PM, John Von Seggern wrote:
>> 
>> Does OpenJDK continue to take this approach?
>> 
>> 
>> Depends on who does the build. The default might be to statically link,
>> pretty sure anyway.
>> 
>> I'm asking because I would like to use the Java Native Interface to
>> call functions in a C++ library (that statically links the C++
>> runtime).  When I distribute my application, do I need to worry about
>> C++ ABI compatibility issues?
>> 
>> 
>> When you distribute a C++ application you always need to worry
>> about compatibility issues.
>> 
>> If you statically link in a C++ library, you need to make sure you are not
>> also providing those
>> interfaces as your own public exported interfaces, if you use the proper
>> version scripts (mapfiles) this
>> kind of thing can work fine. But it means that you have baked in the
>> implementation of code that
>> you don't maintain, and any bugs in that code requires you to rebuild your
>> product and re-ship.
>> There is a maintenance cost to static linking.
>> 
>> So in general, doing static linking is a bad idea and should not be done
>> lightly, if ever.
>> 
>> On Solaris, in OpenJDK makefiles, there is no static linking, or shouldn't
>> be any.
>> 
>> On Windows, we do static linking of some DLLs, but not the primary one
>> MSVCR100.DLL,
>> except in rare cases, which I try to burn from my memory every time I see
>> them,
>> and we have lots of debates on that issue. With Windows you have to ship the
>> MSVC*.DLLs with your product, so there are space considerations, big DLLs
>> here.
>> 
>> On Linux, we shouldn't use static linking, but we had to a long time ago,
>> and we just haven't undone
>> it completely. Obviously the distros don't want static linking, but when
>> Oracle builds a Linux
>> distribution, the binaries need to run on a variety of Linux systems, so we
>> need to be careful, and
>> we don't want to build a separate Oracle JDK for every Linux distro.
>> It is quite possible that we don't need to static link anything anymore, but
>> that would need to be verified.
>> When the initial JDK4 work was done on Linux, static links of the C++
>> runtime was the only way
>> for us to create binaries that had any chance of running on a variety of
>> distributions of Linux.
>> 
>> Of course, then there is the other sharing issue, the one where you copy the
>> source into your
>> repository and build your own private version of a library that also ships
>> with the underlying system.
>> That's another story.
>> 
>> -kto
>> 
>> 
>> 



From kelly.ohair at oracle.com  Thu Jan  5 02:20:48 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 Jan 2012 18:20:48 -0800
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <20120105020321.GG18480@rivendell.middle-earth.co.uk>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>
	<CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>
	<20120105020321.GG18480@rivendell.middle-earth.co.uk>
Message-ID: <1495B3D5-1F64-407F-916A-A2DAE85C990B@oracle.com>


On Jan 4, 2012, at 6:03 PM, Dr Andrew John Hughes wrote:

> The most obvious issue for me is security.  If a security flaw appears in libstdc++
> (or whatever library is linked statically), you have to rebuild to fix it.  So the JDK
> has to have a security update due to one of its dependencies.

Yup. Good one.

-kto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120104/fa0a015d/attachment.htm>

From luchsh at linux.vnet.ibm.com  Thu Jan  5 02:50:56 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 05 Jan 2012 10:50:56 +0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>	<4F040B15.8010604@linux.vnet.ibm.com>
	<BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>
Message-ID: <4F051010.5050006@linux.vnet.ibm.com>

Hi Kelly,

Thanks for reviewing,

On 01/05/2012 06:35 AM, Kelly O'Hair wrote:
> The change sounds reasonable, but it's a change to something I have always hated, so it's somewhat distasteful to me
> because of that. Having the makefiles build and run an application as part of a sanity check just seems so...
> what is the word....  silly?  :^(
>
> I had hoped that we could just have the sanity check inspect the freetype headers and libraries to
> insure the right version, not have to build an application just so we could run it to get the version number.
> On the other hand, building this little app is a way to verify that the freetype library links ok
Agree, have you got any good ideas about inspecting the headers and 
libraries? especially for the integrity of a binary library, 'nm libaaa' ?
> So to the question of whether this change is ok, basically yes,  but why was this line added:
>
>    53     CC_PROGRAM_OUTPUT_FLAG= -o
>
> ???
This line is added because there may not be a definition of 
CC_PROGRAM_OUTPUT_FLAG in jdk/make/common/Defs-<platform>.gmk for all 
Unix's, so this line will make the little application pass the 
compilation even without a Defs-<platform>.gmk.

And if this change is OK, do you plan to push it?
> -kto



From kelly.ohair at oracle.com  Thu Jan  5 20:46:23 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 5 Jan 2012 12:46:23 -0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <4F051010.5050006@linux.vnet.ibm.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>	<4F040B15.8010604@linux.vnet.ibm.com>
	<BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>
	<4F051010.5050006@linux.vnet.ibm.com>
Message-ID: <11980FE8-8FF0-477D-B6F6-83933BAB60F1@oracle.com>


I got a little carried away... but here is what I came up with:

http://cr.openjdk.java.net/~ohair/openjdk8/freetype-rpath/webrev/

Just got rid of CC_PROGRAM_OUTPUT_FLAG and also fixed a few indentation annoyances.

The CC_OBJECT_OUTPUT_FLAG is used quite a bit in other places, but
the CC_PROGRAM_OUTPUT_FLAG variable was not used consistently.
Windows has multiple ways to specify the names. So I just got rid of it, everyone is explicit now.

-kto

On Jan 4, 2012, at 6:50 PM, Jonathan Lu wrote:

> Hi Kelly,
> 
> Thanks for reviewing,
> 
> On 01/05/2012 06:35 AM, Kelly O'Hair wrote:
>> The change sounds reasonable, but it's a change to something I have always hated, so it's somewhat distasteful to me
>> because of that. Having the makefiles build and run an application as part of a sanity check just seems so...
>> what is the word....  silly?  :^(
>> 
>> I had hoped that we could just have the sanity check inspect the freetype headers and libraries to
>> insure the right version, not have to build an application just so we could run it to get the version number.
>> On the other hand, building this little app is a way to verify that the freetype library links ok
> Agree, have you got any good ideas about inspecting the headers and libraries? especially for the integrity of a binary library, 'nm libaaa' ?
>> So to the question of whether this change is ok, basically yes,  but why was this line added:
>> 
>>   53     CC_PROGRAM_OUTPUT_FLAG= -o
>> 
>> ???
> This line is added because there may not be a definition of CC_PROGRAM_OUTPUT_FLAG in jdk/make/common/Defs-<platform>.gmk for all Unix's, so this line will make the little application pass the compilation even without a Defs-<platform>.gmk.
> 
> And if this change is OK, do you plan to push it?
>> -kto
> 



From david.katleman at oracle.com  Thu Jan  5 21:02:32 2012
From: david.katleman at oracle.com (David Katleman)
Date: Thu, 05 Jan 2012 13:02:32 -0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <11980FE8-8FF0-477D-B6F6-83933BAB60F1@oracle.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>	<4F040B15.8010604@linux.vnet.ibm.com>	<BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>	<4F051010.5050006@linux.vnet.ibm.com>
	<11980FE8-8FF0-477D-B6F6-83933BAB60F1@oracle.com>
Message-ID: <4F060FE8.6010409@oracle.com>



On 1/5/2012 12:46 PM, Kelly O'Hair wrote:
> I got a little carried away... but here is what I came up with:
>
> http://cr.openjdk.java.net/~ohair/openjdk8/freetype-rpath/webrev/
>
> Just got rid of CC_PROGRAM_OUTPUT_FLAG and also fixed a few indentation annoyances.
>
> The CC_OBJECT_OUTPUT_FLAG is used quite a bit in other places, but
> the CC_PROGRAM_OUTPUT_FLAG variable was not used consistently.
> Windows has multiple ways to specify the names. So I just got rid of it, everyone is explicit now.

Change looks fine, and eliminates a seldom used variable 
(CC_PROGRAM_OUTPUT_FLAG)

         Dave

> On Jan 4, 2012, at 6:50 PM, Jonathan Lu wrote:
>
>> Hi Kelly,
>>
>> Thanks for reviewing,
>>
>> On 01/05/2012 06:35 AM, Kelly O'Hair wrote:
>>> The change sounds reasonable, but it's a change to something I have always hated, so it's somewhat distasteful to me
>>> because of that. Having the makefiles build and run an application as part of a sanity check just seems so...
>>> what is the word....  silly?  :^(
>>>
>>> I had hoped that we could just have the sanity check inspect the freetype headers and libraries to
>>> insure the right version, not have to build an application just so we could run it to get the version number.
>>> On the other hand, building this little app is a way to verify that the freetype library links ok
>> Agree, have you got any good ideas about inspecting the headers and libraries? especially for the integrity of a binary library, 'nm libaaa' ?
>>> So to the question of whether this change is ok, basically yes,  but why was this line added:
>>>
>>>    53     CC_PROGRAM_OUTPUT_FLAG= -o
>>>
>>> ???
>> This line is added because there may not be a definition of CC_PROGRAM_OUTPUT_FLAG in jdk/make/common/Defs-<platform>.gmk for all Unix's, so this line will make the little application pass the compilation even without a Defs-<platform>.gmk.
>>
>> And if this change is OK, do you plan to push it?
>>> -kto


From kelly.ohair at oracle.com  Fri Jan  6 18:30:45 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 6 Jan 2012 10:30:45 -0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <4F060FE8.6010409@oracle.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>	<4F040B15.8010604@linux.vnet.ibm.com>	<BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>	<4F051010.5050006@linux.vnet.ibm.com>
	<11980FE8-8FF0-477D-B6F6-83933BAB60F1@oracle.com>
	<4F060FE8.6010409@oracle.com>
Message-ID: <5EC770F3-75F5-4D98-B7EF-C73E821D7287@oracle.com>

Jonathan,

This is bit more than what you suggested but should fix your initial issue.

Let me know if you are ok with this change and I will try and integrate it asap.

-kto

On Jan 5, 2012, at 1:02 PM, David Katleman wrote:

> 
> 
> On 1/5/2012 12:46 PM, Kelly O'Hair wrote:
>> I got a little carried away... but here is what I came up with:
>> 
>> http://cr.openjdk.java.net/~ohair/openjdk8/freetype-rpath/webrev/
>> 
>> Just got rid of CC_PROGRAM_OUTPUT_FLAG and also fixed a few indentation annoyances.
>> 
>> The CC_OBJECT_OUTPUT_FLAG is used quite a bit in other places, but
>> the CC_PROGRAM_OUTPUT_FLAG variable was not used consistently.
>> Windows has multiple ways to specify the names. So I just got rid of it, everyone is explicit now.
> 
> Change looks fine, and eliminates a seldom used variable (CC_PROGRAM_OUTPUT_FLAG)
> 
>        Dave
> 
>> On Jan 4, 2012, at 6:50 PM, Jonathan Lu wrote:
>> 
>>> Hi Kelly,
>>> 
>>> Thanks for reviewing,
>>> 
>>> On 01/05/2012 06:35 AM, Kelly O'Hair wrote:
>>>> The change sounds reasonable, but it's a change to something I have always hated, so it's somewhat distasteful to me
>>>> because of that. Having the makefiles build and run an application as part of a sanity check just seems so...
>>>> what is the word....  silly?  :^(
>>>> 
>>>> I had hoped that we could just have the sanity check inspect the freetype headers and libraries to
>>>> insure the right version, not have to build an application just so we could run it to get the version number.
>>>> On the other hand, building this little app is a way to verify that the freetype library links ok
>>> Agree, have you got any good ideas about inspecting the headers and libraries? especially for the integrity of a binary library, 'nm libaaa' ?
>>>> So to the question of whether this change is ok, basically yes,  but why was this line added:
>>>> 
>>>>   53     CC_PROGRAM_OUTPUT_FLAG= -o
>>>> 
>>>> ???
>>> This line is added because there may not be a definition of CC_PROGRAM_OUTPUT_FLAG in jdk/make/common/Defs-<platform>.gmk for all Unix's, so this line will make the little application pass the compilation even without a Defs-<platform>.gmk.
>>> 
>>> And if this change is OK, do you plan to push it?
>>>> -kto



From luchsh at linux.vnet.ibm.com  Mon Jan  9 03:08:11 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 09 Jan 2012 11:08:11 +0800
Subject: freetype_versioncheck failed to compile
In-Reply-To: <5EC770F3-75F5-4D98-B7EF-C73E821D7287@oracle.com>
References: <4EF0821C.6070207@linux.vnet.ibm.com>	<4F040B15.8010604@linux.vnet.ibm.com>	<BB7D9DB7-39A4-4BA7-828B-87F1EE3B3FA4@oracle.com>	<4F051010.5050006@linux.vnet.ibm.com>	<11980FE8-8FF0-477D-B6F6-83933BAB60F1@oracle.com>	<4F060FE8.6010409@oracle.com>
	<5EC770F3-75F5-4D98-B7EF-C73E821D7287@oracle.com>
Message-ID: <4F0A5A1B.7080705@linux.vnet.ibm.com>

Hi Kelly,

I'm OK with the current change, thank you!

Cheers!
- Jonathan

On 01/07/2012 02:30 AM, Kelly O'Hair wrote:
> Jonathan,
>
> This is bit more than what you suggested but should fix your initial issue.
>
> Let me know if you are ok with this change and I will try and integrate it asap.
>
> -kto
>
> On Jan 5, 2012, at 1:02 PM, David Katleman wrote:
>
>>
>> On 1/5/2012 12:46 PM, Kelly O'Hair wrote:
>>> I got a little carried away... but here is what I came up with:
>>>
>>> http://cr.openjdk.java.net/~ohair/openjdk8/freetype-rpath/webrev/
>>>
>>> Just got rid of CC_PROGRAM_OUTPUT_FLAG and also fixed a few indentation annoyances.
>>>
>>> The CC_OBJECT_OUTPUT_FLAG is used quite a bit in other places, but
>>> the CC_PROGRAM_OUTPUT_FLAG variable was not used consistently.
>>> Windows has multiple ways to specify the names. So I just got rid of it, everyone is explicit now.
>> Change looks fine, and eliminates a seldom used variable (CC_PROGRAM_OUTPUT_FLAG)
>>
>>         Dave
>>
>>> On Jan 4, 2012, at 6:50 PM, Jonathan Lu wrote:
>>>
>>>> Hi Kelly,
>>>>
>>>> Thanks for reviewing,
>>>>
>>>> On 01/05/2012 06:35 AM, Kelly O'Hair wrote:
>>>>> The change sounds reasonable, but it's a change to something I have always hated, so it's somewhat distasteful to me
>>>>> because of that. Having the makefiles build and run an application as part of a sanity check just seems so...
>>>>> what is the word....  silly?  :^(
>>>>>
>>>>> I had hoped that we could just have the sanity check inspect the freetype headers and libraries to
>>>>> insure the right version, not have to build an application just so we could run it to get the version number.
>>>>> On the other hand, building this little app is a way to verify that the freetype library links ok
>>>> Agree, have you got any good ideas about inspecting the headers and libraries? especially for the integrity of a binary library, 'nm libaaa' ?
>>>>> So to the question of whether this change is ok, basically yes,  but why was this line added:
>>>>>
>>>>>    53     CC_PROGRAM_OUTPUT_FLAG= -o
>>>>>
>>>>> ???
>>>> This line is added because there may not be a definition of CC_PROGRAM_OUTPUT_FLAG in jdk/make/common/Defs-<platform>.gmk for all Unix's, so this line will make the little application pass the compilation even without a Defs-<platform>.gmk.
>>>>
>>>> And if this change is OK, do you plan to push it?
>>>>> -kto



From kelly.ohair at oracle.com  Mon Jan  9 20:06:39 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Mon, 09 Jan 2012 20:06:39 +0000
Subject: hg: jdk8/build/jaxws: 7096063: /META-INF/mimetypes.default missing in
	jre\lib\resources.jar
Message-ID: <20120109200639.A8865478F3@hg.openjdk.java.net>

Changeset: e67d51254533
Author:    ohair
Date:      2012-01-09 09:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxws/rev/e67d51254533

7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar
Reviewed-by: dholmes

! build-defs.xml



From kelly.ohair at oracle.com  Mon Jan  9 22:31:53 2012
From: kelly.ohair at oracle.com (kelly.ohair at oracle.com)
Date: Mon, 09 Jan 2012 22:31:53 +0000
Subject: hg: jdk8/build/jdk: 7128320: Fix freetype sanity check to make it
	more generic
Message-ID: <20120109223221.56244478F5@hg.openjdk.java.net>

Changeset: 7c8c16f2c05e
Author:    ohair
Date:      2012-01-09 09:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/7c8c16f2c05e

7128320: Fix freetype sanity check to make it more generic
Reviewed-by: luchsh, katleman
Contributed-by: Jonathan Lu <luchsh at linux.vnet.ibm.com>

! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/common/Defs-windows.gmk
! make/common/Demo.gmk
! make/tools/freetypecheck/Makefile



From david.katleman at sun.com  Thu Jan 12 00:18:03 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:18:03 +0000
Subject: hg: jdk8/build: Added tag jdk8-b20 for changeset 5a5eaf6374bc
Message-ID: <20120112001803.63D7747928@hg.openjdk.java.net>

Changeset: cc771d92284f
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/rev/cc771d92284f

Added tag jdk8-b20 for changeset 5a5eaf6374bc

! .hgtags



From david.katleman at sun.com  Thu Jan 12 00:18:11 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:18:11 +0000
Subject: hg: jdk8/build/corba: Added tag jdk8-b20 for changeset 51d8b6cb18c0
Message-ID: <20120112001812.45BC447929@hg.openjdk.java.net>

Changeset: f157fc2a71a3
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/corba/rev/f157fc2a71a3

Added tag jdk8-b20 for changeset 51d8b6cb18c0

! .hgtags



From david.katleman at sun.com  Thu Jan 12 00:18:44 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:18:44 +0000
Subject: hg: jdk8/build/hotspot: Added tag jdk8-b20 for changeset fe2c87649981
Message-ID: <20120112001846.40AB24792A@hg.openjdk.java.net>

Changeset: 9952d1c439d6
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9952d1c439d6

Added tag jdk8-b20 for changeset fe2c87649981

! .hgtags



From david.katleman at sun.com  Thu Jan 12 00:19:43 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:19:43 +0000
Subject: hg: jdk8/build/jaxp: Added tag jdk8-b20 for changeset f052abb8f374
Message-ID: <20120112001943.0F6334792B@hg.openjdk.java.net>

Changeset: d41eeadf5c13
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxp/rev/d41eeadf5c13

Added tag jdk8-b20 for changeset f052abb8f374

! .hgtags



From david.katleman at sun.com  Thu Jan 12 00:19:50 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:19:50 +0000
Subject: hg: jdk8/build/jaxws: 2 new changesets
Message-ID: <20120112001950.2A8FB4792C@hg.openjdk.java.net>

Changeset: dc2ee8b87884
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxws/rev/dc2ee8b87884

Added tag jdk8-b20 for changeset 2b2818e3386f

! .hgtags

Changeset: c266cab0e3ff
Author:    katleman
Date:      2012-01-11 16:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxws/rev/c266cab0e3ff

Merge




From david.katleman at sun.com  Thu Jan 12 00:20:19 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:20:19 +0000
Subject: hg: jdk8/build/jdk: 16 new changesets
Message-ID: <20120112002302.625614792D@hg.openjdk.java.net>

Changeset: fc050750f8a0
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/fc050750f8a0

Added tag jdk8-b20 for changeset 39e938cd1b82

! .hgtags

Changeset: 1c4fffa22930
Author:    okutsu
Date:      2011-12-21 17:09 +0900
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/1c4fffa22930

7122054: (tz) Windows-only: tzmappings needs update for KB2633952
Reviewed-by: peytoia

! src/windows/lib/tzmappings

Changeset: b1814b3ea6d3
Author:    michaelm
Date:      2011-12-21 10:06 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/b1814b3ea6d3

7078386: NetworkInterface.getNetworkInterfaces() may return corrupted results on linux
Reviewed-by: michaelm, alanb, chegar
Contributed-by: brandon.passanisi at oracle.com

! src/solaris/native/java/net/NetworkInterface.c

Changeset: a9dfdc523c2c
Author:    valeriep
Date:      2011-12-21 14:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/a9dfdc523c2c

6839886: Array overrun in pkcs11
Summary: Fix the wrong value when dealing w/ month and day.
Reviewed-by: mullan

! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c

Changeset: 11698dedbe79
Author:    weijun
Date:      2011-12-22 15:35 +0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/11698dedbe79

7122169: TcpTimeout fail for various reasons
Reviewed-by: alanb

! test/sun/security/krb5/auto/TcpTimeout.java

Changeset: 559e07ed1f56
Author:    alanb
Date:      2011-12-22 10:52 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/559e07ed1f56

7076310: (file) AclEntry.Builder setFlags throws IllegalArgumentException if set argument is empty
Reviewed-by: alanb
Contributed-by: stephen.flores at oracle.com

! src/share/classes/java/nio/file/attribute/AclEntry.java
+ test/java/nio/file/attribute/AclEntry/EmptySet.java

Changeset: 3c1ab134db71
Author:    dcubed
Date:      2011-12-22 18:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/3c1ab134db71

7121600: Instrumentation.redefineClasses() leaks class bytes
Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253.
Reviewed-by: acorn, poonam

! src/share/instrument/JPLISAgent.c
+ test/java/lang/instrument/BigClass.java
+ test/java/lang/instrument/MakeJAR4.sh
+ test/java/lang/instrument/RedefineBigClass.sh
+ test/java/lang/instrument/RedefineBigClassAgent.java
+ test/java/lang/instrument/RedefineBigClassApp.java
+ test/java/lang/instrument/RetransformBigClass.sh
+ test/java/lang/instrument/RetransformBigClassAgent.java
+ test/java/lang/instrument/RetransformBigClassApp.java

Changeset: 437255d15e76
Author:    lana
Date:      2011-12-28 10:51 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/437255d15e76

Merge

- src/share/classes/sun/awt/FocusingTextField.java
- src/share/classes/sun/awt/HorizBagLayout.java
- src/share/classes/sun/awt/OrientableFlowLayout.java
- src/share/classes/sun/awt/VariableGridLayout.java
- src/share/classes/sun/awt/VerticalBagLayout.java

Changeset: 3a7ea63302f8
Author:    smarks
Date:      2011-12-29 16:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/3a7ea63302f8

7122061: add -Xlint:all -Werror to warning-free build steps
Reviewed-by: chegar, alanb, dholmes, ohair

! make/com/sun/demo/jvmti/hprof/Makefile
! make/com/sun/java/browser/net/Makefile
! make/com/sun/tools/Makefile
! make/com/sun/tools/attach/Makefile
! make/com/sun/tracing/Makefile
! make/com/sun/tracing/dtrace/Makefile
! make/java/instrument/Makefile
! make/java/rmi/Makefile
! make/java/text/base/Makefile
! make/java/text/bidi/Makefile
! make/java/util/Makefile
! make/javax/accessibility/Makefile
! make/javax/others/Makefile
! make/javax/security/Makefile
! make/jpda/tty/Makefile
! make/sun/launcher/Makefile
! make/sun/serialver/Makefile
! make/sun/text/Makefile
! make/sun/util/Makefile

Changeset: 5aeefe0e5d8c
Author:    chegar
Date:      2012-01-01 09:24 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/5aeefe0e5d8c

7125055: ContentHandler.getContent API changed in error
Reviewed-by: alanb

! src/share/classes/java/net/ContentHandler.java
! src/share/classes/sun/net/www/content/image/gif.java
! src/share/classes/sun/net/www/content/image/jpeg.java
! src/share/classes/sun/net/www/content/image/png.java
! src/share/classes/sun/net/www/content/image/x_xbitmap.java
! src/share/classes/sun/net/www/content/image/x_xpixmap.java

Changeset: 8952a5f494f9
Author:    ksrini
Date:      2012-01-03 08:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/8952a5f494f9

7123582: (launcher) display the -version and -XshowSettings
Reviewed-by: alanb

! src/share/bin/java.c
! test/tools/launcher/Settings.java

Changeset: 5e34726cb4bb
Author:    ksrini
Date:      2012-01-03 08:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e34726cb4bb

7124443: (launcher) test DefaultsLocaleTest fails with Windows shells.
Reviewed-by: darcy

! test/tools/launcher/DefaultLocaleTest.java
- test/tools/launcher/DefaultLocaleTest.sh
+ test/tools/launcher/DefaultLocaleTestRun.java
! test/tools/launcher/TestHelper.java

Changeset: 0194fe5ca404
Author:    fparain
Date:      2012-01-04 03:49 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/0194fe5ca404

7104647: Adding a diagnostic command framework
Reviewed-by: mchung, dholmes

! make/common/Release.gmk
! make/java/management/mapfile-vers
! make/launchers/Makefile
! make/sun/tools/Makefile
+ src/linux/doc/man/jcmd.1
+ src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java
+ src/share/classes/com/sun/management/DiagnosticCommandInfo.java
! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java
! src/share/classes/sun/management/HotSpotDiagnostic.java
! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java
+ src/share/classes/sun/tools/jcmd/Arguments.java
+ src/share/classes/sun/tools/jcmd/JCmd.java
! src/share/javavm/export/jmm.h
! src/share/native/sun/management/HotSpotDiagnostic.c
+ src/solaris/doc/sun/man/man1/jcmd.1
+ test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java
+ test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java
+ test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java
! test/sun/tools/common/CommonSetup.sh
+ test/sun/tools/jcmd/dcmd-script.txt
+ test/sun/tools/jcmd/help_help.out
+ test/sun/tools/jcmd/jcmd-Defaults.sh
+ test/sun/tools/jcmd/jcmd-f.sh
+ test/sun/tools/jcmd/jcmd-help-help.sh
+ test/sun/tools/jcmd/jcmd-help.sh
+ test/sun/tools/jcmd/jcmd-pid.sh
+ test/sun/tools/jcmd/jcmd_Output1.awk
+ test/sun/tools/jcmd/jcmd_pid_Output1.awk
+ test/sun/tools/jcmd/jcmd_pid_Output2.awk
+ test/sun/tools/jcmd/usage.out

Changeset: 38a318502e19
Author:    lana
Date:      2012-01-04 10:57 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/38a318502e19

Merge

! make/common/Release.gmk
- test/tools/launcher/DefaultLocaleTest.sh

Changeset: 93ab1df09d11
Author:    lana
Date:      2012-01-09 19:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/93ab1df09d11

Merge

- test/tools/launcher/DefaultLocaleTest.sh

Changeset: 664fa4fb0ee4
Author:    katleman
Date:      2012-01-11 16:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/664fa4fb0ee4

Merge




From david.katleman at sun.com  Thu Jan 12 00:24:40 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Thu, 12 Jan 2012 00:24:40 +0000
Subject: hg: jdk8/build/langtools: 7 new changesets
Message-ID: <20120112002457.740314792E@hg.openjdk.java.net>

Changeset: 020819eb56d2
Author:    katleman
Date:      2012-01-05 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/020819eb56d2

Added tag jdk8-b20 for changeset ffd294128a48

! .hgtags

Changeset: 116f68a5e677
Author:    jjg
Date:      2011-12-23 22:30 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/116f68a5e677

7124605: typos in javac comments
Reviewed-by: ksrini

! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java
! test/tools/javac/generics/inference/7086601/T7086601b.java
! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java
! test/tools/javac/lambda/LambdaParserTest.java

Changeset: 67512b631961
Author:    lana
Date:      2011-12-28 10:52 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/67512b631961

Merge


Changeset: 7a836147b266
Author:    jjg
Date:      2012-01-03 11:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/7a836147b266

4881269: improve diagnostic for ill-formed tokens
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/IllegalDot.java
+ test/tools/javac/parser/T4881269.java
+ test/tools/javac/parser/T4881269.out

Changeset: a07eef109532
Author:    jjh
Date:      2012-01-03 17:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/a07eef109532

7046929: tools/javac/api/T6397104.java fails
Reviewed-by: jjg

! test/tools/javac/api/T6397104.java

Changeset: 4e8aa6eca726
Author:    lana
Date:      2012-01-04 10:58 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/4e8aa6eca726

Merge


Changeset: bcb21abf1c41
Author:    lana
Date:      2012-01-09 19:13 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/bcb21abf1c41

Merge




From michael.j.silverstri at gmail.com  Fri Jan 13 17:33:27 2012
From: michael.j.silverstri at gmail.com (m silverstri)
Date: Fri, 13 Jan 2012 09:33:27 -0800
Subject: Build openjdk in Ubuntu 11.10
Message-ID: <CABMudhTXxd8chBWMNOfrciiix8_OSyr73sT=uEfke6cD7Nj6Xg@mail.gmail.com>

Hi,

I am getting the following error when building openjdk 7.0 on ubuntu 11.10
But I already have the package libasound2-dev installed.

Please tell me what am I missing?
Thank you.


PLATFORM_API_LinuxOS_ALSA_CommonUtils.c:(.text+0x32): undefined
reference to `snd_lib_error_set_handler'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_GetFormats':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x1fd): undefined reference to
`snd_pcm_format_mask_malloc'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x20a): undefined reference to
`snd_pcm_close'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x225): undefined reference to
`snd_pcm_hw_params_malloc'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x236): undefined reference to
`snd_pcm_hw_params_get_format_mask'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x246): undefined reference to
`snd_pcm_format_mask_free'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x259): undefined reference to
`snd_pcm_hw_params_any'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x26a): undefined reference to
`snd_pcm_hw_params_get_format_mask'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x277): undefined reference to
`snd_pcm_hw_params_get_channels_min'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x288): undefined reference to
`snd_pcm_hw_params_get_channels_max'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x2cf): undefined reference to
`snd_pcm_format_mask_test'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x45d): undefined reference to
`snd_pcm_hw_params_free'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `setStartThresholdNoCommit':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x48c): undefined reference to
`snd_pcm_sw_params_set_start_threshold'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `setStartThreshold':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x4bf): undefined reference to
`snd_pcm_sw_params'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `setHWParams':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x518): undefined reference to
`snd_pcm_hw_params_any'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x531): undefined reference to
`snd_pcm_hw_params_set_access'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x544): undefined reference to
`snd_pcm_hw_params_set_format'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x557): undefined reference to
`snd_pcm_hw_params_set_channels'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x58a): undefined reference to
`snd_pcm_hw_params_set_rate_near'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x5dc): undefined reference to
`snd_pcm_hw_params_set_buffer_size_near'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x60b): undefined reference to
`snd_pcm_hw_params_set_period_time_near'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x61b): undefined reference to
`snd_pcm_hw_params'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x647): undefined reference to
`snd_pcm_hw_params_set_periods_near'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `setSWParams':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x67e): undefined reference to
`snd_pcm_sw_params_current'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x6b4): undefined reference to
`snd_pcm_sw_params_set_avail_min'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x6c4): undefined reference to
`snd_pcm_sw_params'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Start':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x6f3): undefined reference to
`snd_pcm_nonblock'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x708): undefined reference to
`snd_pcm_state'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x71f): undefined reference to
`snd_pcm_start'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x72c): undefined reference to
`snd_pcm_nonblock'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x734): undefined reference to
`snd_pcm_state'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x774): undefined reference to
`snd_pcm_prepare'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x786): undefined reference to
`snd_pcm_pause'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x794): undefined reference to
`snd_pcm_resume'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Stop':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x7b0): undefined reference to
`snd_pcm_nonblock'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x7c7): undefined reference to
`snd_pcm_pause'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x7d7): undefined reference to
`snd_pcm_nonblock'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Close':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x80a): undefined reference to
`snd_pcm_close'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x818): undefined reference to
`snd_pcm_hw_params_free'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x826): undefined reference to
`snd_pcm_sw_params_free'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x834): undefined reference to
`snd_pcm_status_free'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Open':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x906): undefined reference to
`snd_pcm_nonblock'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x90f): undefined reference to
`snd_pcm_hw_params_malloc'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x978): undefined reference to
`snd_pcm_hw_params_get_period_size'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x98c): undefined reference to
`snd_pcm_hw_params_get_periods'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x999): undefined reference to
`snd_pcm_hw_params_get_buffer_size'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x9b4): undefined reference to
`snd_pcm_sw_params_malloc'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x9d4): undefined reference to
`snd_pcm_prepare'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x9e5): undefined reference to
`snd_pcm_status_malloc'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0x9fa): undefined reference to
`snd_pcm_nonblock'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `xrun_recovery':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xa44): undefined reference to
`snd_pcm_prepare'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xa5c): undefined reference to
`snd_pcm_resume'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Write':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xac3): undefined reference to
`snd_pcm_writei'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Read':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xb6a): undefined reference to
`snd_pcm_readi'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_StillDraining':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xbd8): undefined reference to
`snd_pcm_state'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_Flush':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xc17): undefined reference to
`snd_pcm_drop'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_GetAvailable':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xc60): undefined reference to
`snd_pcm_state'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xc83): undefined reference to
`snd_pcm_avail_update'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCM.o:
In function `DAUDIO_GetBytePosition':
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xcf1): undefined reference to
`snd_pcm_state'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xd1f): undefined reference to
`snd_pcm_status'
PLATFORM_API_LinuxOS_ALSA_PCM.c:(.text+0xd2c): undefined reference to
`snd_pcm_status_get_avail'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCMUtils.o:
In function `deviceInfoIterator.part.0':
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0xdb): undefined reference
to `snd_ctl_card_info_get_id'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x131): undefined
reference to `snd_ctl_card_info_get_name'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x17a): undefined
reference to `snd_pcm_info_get_id'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x1c3): undefined
reference to `snd_pcm_info_get_name'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x20c): undefined
reference to `snd_pcm_info_get_subdevices_count'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x224): undefined
reference to `snd_pcm_info_get_id'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x234): undefined
reference to `snd_pcm_info_get_name'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCMUtils.o:
In function `iteratePCMDevices':
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x2ff): undefined
reference to `snd_pcm_info_malloc'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x308): undefined
reference to `snd_ctl_card_info_malloc'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x31f): undefined
reference to `snd_pcm_open'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x33c): undefined
reference to `snd_pcm_info'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x348): undefined
reference to `snd_pcm_close'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x35d): undefined
reference to `snd_pcm_info_get_card'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x395): undefined
reference to `snd_ctl_open'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x3a6): undefined
reference to `snd_ctl_card_info'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x3b6): undefined
reference to `snd_ctl_close'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x3f5): undefined
reference to `snd_card_next'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x438): undefined
reference to `snd_ctl_open'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x449): undefined
reference to `snd_ctl_card_info'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x469): undefined
reference to `snd_ctl_pcm_next_device'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x47d): undefined
reference to `snd_pcm_info_set_device'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x488): undefined
reference to `snd_pcm_info_set_subdevice'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x493): undefined
reference to `snd_pcm_info_set_stream'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x4a0): undefined
reference to `snd_ctl_pcm_info'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x512): undefined
reference to `snd_ctl_close'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x52a): undefined
reference to `snd_pcm_info_set_stream'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x537): undefined
reference to `snd_ctl_pcm_info'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x55d): undefined
reference to `snd_ctl_card_info_free'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x566): undefined
reference to `snd_pcm_info_free'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x595): undefined
reference to `snd_pcm_info_get_subdevices_count'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x5b7): undefined
reference to `snd_pcm_open'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCMUtils.o:
In function `openPCMfromDeviceID':
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x66c): undefined
reference to `snd_pcm_open'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCMUtils.o:
In function `getFormatFromAlsaFormat':
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x71f): undefined
reference to `snd_pcm_format_physical_width'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x736): undefined
reference to `snd_pcm_format_width'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x74b): undefined
reference to `snd_pcm_format_signed'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x75d): undefined
reference to `snd_pcm_format_big_endian'
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x779): undefined
reference to `snd_pcm_format_linear'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_PCMUtils.o:
In function `getAlsaFormatFromFormat':
PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:(.text+0x855): undefined
reference to `snd_pcm_build_linear_format'
/home/scheung/src/jdk7/build/linux-amd64/tmp/sun/javax.sound/jsoundalsa/obj64/PLATFORM_API_LinuxOS_ALSA_MidiIn.o:
In function `MIDI_IN_GetMessage':
PLATFORM_API_LinuxOS_ALSA_MidiIn.c:(.text+0x125): undefined reference
to `snd_rawmidi_read'
PLATFORM_API_LinuxOS_ALSA_MidiIn.c:(.text+0x13b): undefined reference
to `snd_midi_event_encode_byte'


From mark.reinhold at oracle.com  Fri Jan 13 17:54:20 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 13 Jan 2012 09:54:20 -0800
Subject: Build openjdk in Ubuntu 11.10
In-Reply-To: michael.j.silverstri@gmail.com; Fri, 13 Jan 2012 09:33:27 PST;
	<CABMudhTXxd8chBWMNOfrciiix8_OSyr73sT=uEfke6cD7Nj6Xg@mail.gmail.com>
Message-ID: <20120113175420.B43F2F21@eggemoggin.niobe.net>

2012/1/13 9:33 -0800, michael.j.silverstri at gmail.com:
> I am getting the following error when building openjdk 7.0 on ubuntu 11.10
> But I already have the package libasound2-dev installed.

This is 7110396.  You need this patch:

diff --git a/make/javax/sound/jsoundalsa/Makefile b/make/javax/sound/jsoundalsa/Makefile
--- a/make/javax/sound/jsoundalsa/Makefile
+++ b/make/javax/sound/jsoundalsa/Makefile
@@ -65,7 +65,7 @@
 	$(MIDIFILES_export) \
 	$(PORTFILES_export)
 
-LDFLAGS += -lasound
+OTHER_LDLIBS += -lasound
 
 CPPFLAGS += \
 	-DUSE_DAUDIO=TRUE \

This is a tiny revision of the patch I originally proposed [1].
If someone could review this then I'll merge and push it.

- Mark


[1] http://mail.openjdk.java.net/pipermail/build-dev/2011-November/005188.html


From david.holmes at oracle.com  Mon Jan 16 05:01:07 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jan 2012 15:01:07 +1000
Subject: Customized make file inclusion
Message-ID: <4F13AF13.2090004@oracle.com>

Presently the build system contains some files, and directives involving 
those files, that supports the building of the Java SE Embedded product. 
What I would like to do is remove direct support for this and replace it 
with a more general mechanism that allows for custom make files to be 
included from an arbitrary location - which then allows for the removal 
of the embedded specific files.

Initially I've modeled this on some other conditional mechanisms by 
defining the default location for non-OpenJDK builds, checking its 
existence and then using that as a guard for the individual files.

http://cr.openjdk.java.net/~dholmes/custom-make/webrev/

! ifneq ($(OPENJDK),true)
!   CUSTOM_MAKE_DIR_REL=closed
! else
!   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
! endif
! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)

+ # Use this variable to guard inclusion of the custom files
+ HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1; 
else echo 0; fi)

...

+ ifeq ($(HAS_CUSTOM_MAKE),1)
+   include $(CUSTOM_MAKE_DIR)/Defs.gmk
+ endif

Initially there are only two hooks for these custom files:

1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
2. In the top-level JDK Makefile, including a custom Release.gmk

Naturally these map to the existing uses of the *-embedded.gmk files.

It then occurred to me that if someone wanted to add an additional hook 
somewhere else, that it might be best to check for the existence of the 
actual file rather than a root directory for all such files. That led me 
to consider a function custom_include(<filename>) to hide the existence 
logic. But I wasn't sure if a function could contain an include 
directive and upon checking on that I discovered a much simpler 
approach: the -include directive. This is like the include directive but 
does not trigger an error if the file does not exist. So we would simply 
have this in Defs.gmk:

  ifneq ($(OPENJDK),true)
    CUSTOM_MAKE_DIR_REL=closed
  else
    CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
  endif
  CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)

and then

-include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>

wherever we needed it (again initially only the two locations I mentioned).

I'd like to hear people's opinions on this.

Thanks,
David


From Dmitry.Samersoff at oracle.com  Mon Jan 16 10:45:55 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 16 Jan 2012 14:45:55 +0400
Subject: Customized make file inclusion
In-Reply-To: <4F13AF13.2090004@oracle.com>
References: <4F13AF13.2090004@oracle.com>
Message-ID: <4F13FFE3.9080808@oracle.com>

David,

I'm not sure I catch you idea correct.
May be we can just create a directory, something like make.d
and then do

for i in make.d/*
do
   -include ...
done

-Dmitry




On 2012-01-16 09:01, David Holmes wrote:
> Presently the build system contains some files, and directives involving
> those files, that supports the building of the Java SE Embedded product.
> What I would like to do is remove direct support for this and replace it
> with a more general mechanism that allows for custom make files to be
> included from an arbitrary location - which then allows for the removal
> of the embedded specific files.
> 
> Initially I've modeled this on some other conditional mechanisms by
> defining the default location for non-OpenJDK builds, checking its
> existence and then using that as a guard for the individual files.
> 
> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
> 
> ! ifneq ($(OPENJDK),true)
> !   CUSTOM_MAKE_DIR_REL=closed
> ! else
> !   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
> ! endi
> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
> 
> + # Use this variable to guard inclusion of the custom files
> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1;
> else echo 0; fi)
> 
> ...
> 
> + ifeq ($(HAS_CUSTOM_MAKE),1)
> +   include $(CUSTOM_MAKE_DIR)/Defs.gmk
> + endif
> 
> Initially there are only two hooks for these custom files:
> 
> 1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
> 2. In the top-level JDK Makefile, including a custom Release.gmk
> 
> Naturally these map to the existing uses of the *-embedded.gmk files.
> 
> It then occurred to me that if someone wanted to add an additional hook
> somewhere else, that it might be best to check for the existence of the
> actual file rather than a root directory for all such files. That led me
> to consider a function custom_include(<filename>) to hide the existence
> logic. But I wasn't sure if a function could contain an include
> directive and upon checking on that I discovered a much simpler
> approach: the -include directive. This is like the include directive but
> does not trigger an error if the file does not exist. So we would simply
> have this in Defs.gmk:
> 
>  ifneq ($(OPENJDK),true)
>    CUSTOM_MAKE_DIR_REL=closed
>  else
>    CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>  endif
>  CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
> 
> and then
> 
> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
> 
> wherever we needed it (again initially only the two locations I mentioned).
> 
> I'd like to hear people's opinions on this.
> 
> Thanks,
> David


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


From david.holmes at oracle.com  Mon Jan 16 11:41:04 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jan 2012 21:41:04 +1000
Subject: Customized make file inclusion
In-Reply-To: <4F13FFE3.9080808@oracle.com>
References: <4F13AF13.2090004@oracle.com> <4F13FFE3.9080808@oracle.com>
Message-ID: <4F140CD0.4050406@oracle.com>

On 16/01/2012 8:45 PM, Dmitry Samersoff wrote:
> I'm not sure I catch you idea correct.
> May be we can just create a directory, something like make.d
> and then do
>
> for i in make.d/*
> do
>     -include ...
> done

No that's not what I'm trying to do. Take a look at where the existing 
Defs-embedded.gmk and Relese-embedded.gmk files get included and then 
consider generalizing that mechanism so that those files can reside in 
an entirely different repository. Those files have to be included at 
certain places for things to work correctly. Eg. The custom Defs.gmk has 
to be included by the main Defs.gmk file.

David
-----

> -Dmitry
>
>
>
>
> On 2012-01-16 09:01, David Holmes wrote:
>> Presently the build system contains some files, and directives involving
>> those files, that supports the building of the Java SE Embedded product.
>> What I would like to do is remove direct support for this and replace it
>> with a more general mechanism that allows for custom make files to be
>> included from an arbitrary location - which then allows for the removal
>> of the embedded specific files.
>>
>> Initially I've modeled this on some other conditional mechanisms by
>> defining the default location for non-OpenJDK builds, checking its
>> existence and then using that as a guard for the individual files.
>>
>> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
>>
>> ! ifneq ($(OPENJDK),true)
>> !   CUSTOM_MAKE_DIR_REL=closed
>> ! else
>> !   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>> ! endi
>> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>
>> + # Use this variable to guard inclusion of the custom files
>> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1;
>> else echo 0; fi)
>>
>> ...
>>
>> + ifeq ($(HAS_CUSTOM_MAKE),1)
>> +   include $(CUSTOM_MAKE_DIR)/Defs.gmk
>> + endif
>>
>> Initially there are only two hooks for these custom files:
>>
>> 1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
>> 2. In the top-level JDK Makefile, including a custom Release.gmk
>>
>> Naturally these map to the existing uses of the *-embedded.gmk files.
>>
>> It then occurred to me that if someone wanted to add an additional hook
>> somewhere else, that it might be best to check for the existence of the
>> actual file rather than a root directory for all such files. That led me
>> to consider a function custom_include(<filename>) to hide the existence
>> logic. But I wasn't sure if a function could contain an include
>> directive and upon checking on that I discovered a much simpler
>> approach: the -include directive. This is like the include directive but
>> does not trigger an error if the file does not exist. So we would simply
>> have this in Defs.gmk:
>>
>>   ifneq ($(OPENJDK),true)
>>     CUSTOM_MAKE_DIR_REL=closed
>>   else
>>     CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>   endif
>>   CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>
>> and then
>>
>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>
>> wherever we needed it (again initially only the two locations I mentioned).
>>
>> I'd like to hear people's opinions on this.
>>
>> Thanks,
>> David
>
>


From fredrik.ohrstrom at oracle.com  Mon Jan 16 16:17:00 2012
From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Mon, 16 Jan 2012 17:17:00 +0100
Subject: Does OpenJDK statically link the C++ runtime?
In-Reply-To: <20120105020321.GG18480@rivendell.middle-earth.co.uk>
References: <CANsuF7YBpT_zsDfOcFpyPyZPrrq8CNR5wOw+-8yRc7Qvo0Dp4g@mail.gmail.com>
	<F3D26BD4-6448-4EC1-AEE5-DCAEBD831593@oracle.com>
	<CANsuF7Z9=j8L8FPL-fXjq=ZfJsmCLzMnZwMhzOswO7unACksYw@mail.gmail.com>
	<20120105020321.GG18480@rivendell.middle-earth.co.uk>
Message-ID: <4F144D7C.2060903@oracle.com>

2012-01-05 03:03, Dr Andrew John Hughes skrev:

>Hence, it is in the provider's interest to make that blob compatible with
>as many systems as possible. This is done by statically linking libraries
>and is also the reason you'll find copies of system libraries
>(libpng, libjpeg, zlib, lcms) in the OpenJDK tree as well as libraries
like Gtk+
>(for the look and feel) being opened dynamically.

The configure script in build-infra/jdk7 has the option:
  --disable-static-link-stdc++
                Disable static linking to the c++ runtime on linux.

I also intend to support --enable-external-libpng etc

//Fredrik


From rickard.backman at oracle.com  Tue Jan 17 15:26:35 2012
From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=)
Date: Tue, 17 Jan 2012 16:26:35 +0100
Subject: RFR: 7115200
Message-ID: <4F15932B.5070107@oracle.com>

CR7115200: Add Java FlightRecorder phase 1
Makefile changes to enable builds of the JDK with JFR.

Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200

Thanks
Rickard


From kelly.ohair at oracle.com  Tue Jan 17 21:07:10 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 17 Jan 2012 13:07:10 -0800
Subject: Customized make file inclusion
In-Reply-To: <4F13AF13.2090004@oracle.com>
References: <4F13AF13.2090004@oracle.com>
Message-ID: <1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>

Generally, I have no objection to this change.

But instead of setting it to NO_SUCH_PATH, I would not set it at all, and avoid the $(shell) to see if it
exists completely.  Just don't set CUSTOM_MAKE_DIR if it does not exist.
Then you don't need the HAS_CUSTOM_MAKE, it can just be ifdef CUSTOM_MAKE_DIR

Not sure I like the word CUSTOM, but that's just a name debate.
Maybe ADDON or MODDING or MODS or oo oo PIGGYBACK? ;^)
http://3.bp.blogspot.com/-cHeD4qJSB44/TbMtSsAiY4I/AAAAAAAAA1c/gctQfVffu_o/s1600/PiggyBack.jpg

-kto

On Jan 15, 2012, at 9:01 PM, David Holmes wrote:

> Presently the build system contains some files, and directives involving those files, that supports the building of the Java SE Embedded product. What I would like to do is remove direct support for this and replace it with a more general mechanism that allows for custom make files to be included from an arbitrary location - which then allows for the removal of the embedded specific files.
> 
> Initially I've modeled this on some other conditional mechanisms by defining the default location for non-OpenJDK builds, checking its existence and then using that as a guard for the individual files.
> 
> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
> 
> ! ifneq ($(OPENJDK),true)
> !   CUSTOM_MAKE_DIR_REL=closed
> ! else
> !   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
> ! endif
> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
> 
> + # Use this variable to guard inclusion of the custom files
> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1; else echo 0; fi)
> 
> ...
> 
> + ifeq ($(HAS_CUSTOM_MAKE),1)
> +   include $(CUSTOM_MAKE_DIR)/Defs.gmk
> + endif
> 
> Initially there are only two hooks for these custom files:
> 
> 1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
> 2. In the top-level JDK Makefile, including a custom Release.gmk
> 
> Naturally these map to the existing uses of the *-embedded.gmk files.
> 
> It then occurred to me that if someone wanted to add an additional hook somewhere else, that it might be best to check for the existence of the actual file rather than a root directory for all such files. That led me to consider a function custom_include(<filename>) to hide the existence logic. But I wasn't sure if a function could contain an include directive and upon checking on that I discovered a much simpler approach: the -include directive. This is like the include directive but does not trigger an error if the file does not exist. So we would simply have this in Defs.gmk:
> 
> ifneq ($(OPENJDK),true)
>   CUSTOM_MAKE_DIR_REL=closed
> else
>   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
> endif
> CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
> 
> and then
> 
> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
> 
> wherever we needed it (again initially only the two locations I mentioned).
> 
> I'd like to hear people's opinions on this.
> 
> Thanks,
> David



From david.holmes at oracle.com  Wed Jan 18 03:17:50 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Jan 2012 13:17:50 +1000
Subject: Customized make file inclusion
In-Reply-To: <1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>
References: <4F13AF13.2090004@oracle.com>
	<1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>
Message-ID: <4F1639DE.5040909@oracle.com>

On 18/01/2012 7:07 AM, Kelly O'Hair wrote:
> Generally, I have no objection to this change.
>
> But instead of setting it to NO_SUCH_PATH, I would not set it at all, and avoid the $(shell) to see if it
> exists completely.  Just don't set CUSTOM_MAKE_DIR if it does not exist.
> Then you don't need the HAS_CUSTOM_MAKE, it can just be ifdef CUSTOM_MAKE_DIR

But I/we want the default setting to occur in the build files and not 
require that it be set externally. My final suggestion gets rid of the 
HAS_CUSTOM_MAKE and the shell usage. Incorporating your suggestion it 
simplifies to:

ifneq ($(OPENJDK),true)
   CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
endif

in Defs.gmk and then:

-include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>

as needed. Though I may get an error with CUSTOM_MAKE_DIR being 
undefined in which case I'll need to declare it for OpenJDK builds.

> Not sure I like the word CUSTOM, but that's just a name debate.

It customizes the build logic. I preferred it to the "alt" name we use 
for hotspot as here it isn't an alternative but an addition. Anyway just 
a name game.

Thanks,
David

> Maybe ADDON or MODDING or MODS or oo oo PIGGYBACK? ;^)
> http://3.bp.blogspot.com/-cHeD4qJSB44/TbMtSsAiY4I/AAAAAAAAA1c/gctQfVffu_o/s1600/PiggyBack.jpg
>
> -kto
>
> On Jan 15, 2012, at 9:01 PM, David Holmes wrote:
>
>> Presently the build system contains some files, and directives involving those files, that supports the building of the Java SE Embedded product. What I would like to do is remove direct support for this and replace it with a more general mechanism that allows for custom make files to be included from an arbitrary location - which then allows for the removal of the embedded specific files.
>>
>> Initially I've modeled this on some other conditional mechanisms by defining the default location for non-OpenJDK builds, checking its existence and then using that as a guard for the individual files.
>>
>> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
>>
>> ! ifneq ($(OPENJDK),true)
>> !   CUSTOM_MAKE_DIR_REL=closed
>> ! else
>> !   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>> ! endif
>> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>
>> + # Use this variable to guard inclusion of the custom files
>> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1; else echo 0; fi)
>>
>> ...
>>
>> + ifeq ($(HAS_CUSTOM_MAKE),1)
>> +   include $(CUSTOM_MAKE_DIR)/Defs.gmk
>> + endif
>>
>> Initially there are only two hooks for these custom files:
>>
>> 1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
>> 2. In the top-level JDK Makefile, including a custom Release.gmk
>>
>> Naturally these map to the existing uses of the *-embedded.gmk files.
>>
>> It then occurred to me that if someone wanted to add an additional hook somewhere else, that it might be best to check for the existence of the actual file rather than a root directory for all such files. That led me to consider a function custom_include(<filename>) to hide the existence logic. But I wasn't sure if a function could contain an include directive and upon checking on that I discovered a much simpler approach: the -include directive. This is like the include directive but does not trigger an error if the file does not exist. So we would simply have this in Defs.gmk:
>>
>> ifneq ($(OPENJDK),true)
>>    CUSTOM_MAKE_DIR_REL=closed
>> else
>>    CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>> endif
>> CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>
>> and then
>>
>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>
>> wherever we needed it (again initially only the two locations I mentioned).
>>
>> I'd like to hear people's opinions on this.
>>
>> Thanks,
>> David
>


From rickard.backman at oracle.com  Wed Jan 18 08:48:21 2012
From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=)
Date: Wed, 18 Jan 2012 09:48:21 +0100
Subject: RFR: 7115200
In-Reply-To: <4F15932B.5070107@oracle.com>
References: <4F15932B.5070107@oracle.com>
Message-ID: <4F168755.7030505@oracle.com>

Please review the updated webrev, David Holmes pointed out that we 
shouldn't build JFR for the embedded environments.

Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/

Thanks
Rickard

On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
> CR7115200: Add Java FlightRecorder phase 1
> Makefile changes to enable builds of the JDK with JFR.
>
> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>
> Thanks
> Rickard



From kelly.ohair at oracle.com  Wed Jan 18 16:22:29 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 18 Jan 2012 08:22:29 -0800
Subject: Customized make file inclusion
In-Reply-To: <4F1639DE.5040909@oracle.com>
References: <4F13AF13.2090004@oracle.com>
	<1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>
	<4F1639DE.5040909@oracle.com>
Message-ID: <84663C8D-C056-4B92-8B93-3D985C71E6A9@oracle.com>


On Jan 17, 2012, at 7:17 PM, David Holmes wrote:

> On 18/01/2012 7:07 AM, Kelly O'Hair wrote:
>> Generally, I have no objection to this change.
>> 
>> But instead of setting it to NO_SUCH_PATH, I would not set it at all, and avoid the $(shell) to see if it
>> exists completely.  Just don't set CUSTOM_MAKE_DIR if it does not exist.
>> Then you don't need the HAS_CUSTOM_MAKE, it can just be ifdef CUSTOM_MAKE_DIR
> 
> But I/we want the default setting to occur in the build files and not require that it be set externally. My final suggestion gets rid of the HAS_CUSTOM_MAKE and the shell usage. Incorporating your suggestion it simplifies to:
> 
> ifneq ($(OPENJDK),true)
>  CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
> endif

Or something like:

# Custom makefile additions
ifneq ($(OPENJDK),true)
  CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
  # This directory should exist if OPENJDK is not "true"
  ifeq ($(shell if [ ! -d $(CUSTOM_MAKE_DIR) ]; then echo "missing"; fi),missing)
    x:=$(error "ERROR: Not OPENJDK, and missing $(CUSTOM_MAKE_DIR)")
  endif
endif

> 
> in Defs.gmk and then:
> 
> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>

And:

# Custom makefile additions
ifdef CUSTOM_MAKE_DIR
  include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
endif

> 
> as needed. Though I may get an error with CUSTOM_MAKE_DIR being undefined in which case I'll need to declare it for OpenJDK builds.

Undefined is the same as being defined as empty in terms of expansion $(var)

> 
>> Not sure I like the word CUSTOM, but that's just a name debate.
> 
> It customizes the build logic. I preferred it to the "alt" name we use for hotspot as here it isn't an alternative but an addition. Anyway just a name game.

Not a big deal, but kind of liked the piggyback idea. ;^)

-kto

> 
> Thanks,
> David
> 
>> Maybe ADDON or MODDING or MODS or oo oo PIGGYBACK? ;^)
>> http://3.bp.blogspot.com/-cHeD4qJSB44/TbMtSsAiY4I/AAAAAAAAA1c/gctQfVffu_o/s1600/PiggyBack.jpg
>> 
>> -kto
>> 
>> On Jan 15, 2012, at 9:01 PM, David Holmes wrote:
>> 
>>> Presently the build system contains some files, and directives involving those files, that supports the building of the Java SE Embedded product. What I would like to do is remove direct support for this and replace it with a more general mechanism that allows for custom make files to be included from an arbitrary location - which then allows for the removal of the embedded specific files.
>>> 
>>> Initially I've modeled this on some other conditional mechanisms by defining the default location for non-OpenJDK builds, checking its existence and then using that as a guard for the individual files.
>>> 
>>> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
>>> 
>>> ! ifneq ($(OPENJDK),true)
>>> !   CUSTOM_MAKE_DIR_REL=closed
>>> ! else
>>> !   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>> ! endif
>>> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>> 
>>> + # Use this variable to guard inclusion of the custom files
>>> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1; else echo 0; fi)
>>> 
>>> ...
>>> 
>>> + ifeq ($(HAS_CUSTOM_MAKE),1)
>>> +   include $(CUSTOM_MAKE_DIR)/Defs.gmk
>>> + endif
>>> 
>>> Initially there are only two hooks for these custom files:
>>> 
>>> 1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
>>> 2. In the top-level JDK Makefile, including a custom Release.gmk
>>> 
>>> Naturally these map to the existing uses of the *-embedded.gmk files.
>>> 
>>> It then occurred to me that if someone wanted to add an additional hook somewhere else, that it might be best to check for the existence of the actual file rather than a root directory for all such files. That led me to consider a function custom_include(<filename>) to hide the existence logic. But I wasn't sure if a function could contain an include directive and upon checking on that I discovered a much simpler approach: the -include directive. This is like the include directive but does not trigger an error if the file does not exist. So we would simply have this in Defs.gmk:
>>> 
>>> ifneq ($(OPENJDK),true)
>>>   CUSTOM_MAKE_DIR_REL=closed
>>> else
>>>   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>> endif
>>> CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>> 
>>> and then
>>> 
>>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>> 
>>> wherever we needed it (again initially only the two locations I mentioned).
>>> 
>>> I'd like to hear people's opinions on this.
>>> 
>>> Thanks,
>>> David
>> 



From kelly.ohair at oracle.com  Wed Jan 18 17:38:36 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 18 Jan 2012 09:38:36 -0800
Subject: Build openjdk in Ubuntu 11.10
In-Reply-To: <20120113175420.B43F2F21@eggemoggin.niobe.net>
References: <20120113175420.B43F2F21@eggemoggin.niobe.net>
Message-ID: <B98A4187-0BD7-4286-B75A-27487B919FA4@oracle.com>

Patch looks fine to me.

-kto

On Jan 13, 2012, at 9:54 AM, mark.reinhold at oracle.com wrote:

> 2012/1/13 9:33 -0800, michael.j.silverstri at gmail.com:
>> I am getting the following error when building openjdk 7.0 on ubuntu 11.10
>> But I already have the package libasound2-dev installed.
> 
> This is 7110396.  You need this patch:
> 
> diff --git a/make/javax/sound/jsoundalsa/Makefile b/make/javax/sound/jsoundalsa/Makefile
> --- a/make/javax/sound/jsoundalsa/Makefile
> +++ b/make/javax/sound/jsoundalsa/Makefile
> @@ -65,7 +65,7 @@
> 	$(MIDIFILES_export) \
> 	$(PORTFILES_export)
> 
> -LDFLAGS += -lasound
> +OTHER_LDLIBS += -lasound
> 
> CPPFLAGS += \
> 	-DUSE_DAUDIO=TRUE \
> 
> This is a tiny revision of the patch I originally proposed [1].
> If someone could review this then I'll merge and push it.
> 
> - Mark
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/build-dev/2011-November/005188.html



From david.katleman at sun.com  Wed Jan 18 22:57:49 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 22:57:49 +0000
Subject: hg: jdk8/build: Added tag jdk8-b21 for changeset cc771d92284f
Message-ID: <20120118225749.E4987479DA@hg.openjdk.java.net>

Changeset: 7ad075c80995
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/rev/7ad075c80995

Added tag jdk8-b21 for changeset cc771d92284f

! .hgtags



From david.katleman at sun.com  Wed Jan 18 22:57:57 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 22:57:57 +0000
Subject: hg: jdk8/build/corba: Added tag jdk8-b21 for changeset f157fc2a71a3
Message-ID: <20120118225758.73478479DB@hg.openjdk.java.net>

Changeset: a11d0062c445
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/corba/rev/a11d0062c445

Added tag jdk8-b21 for changeset f157fc2a71a3

! .hgtags



From david.katleman at sun.com  Wed Jan 18 23:03:18 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 23:03:18 +0000
Subject: hg: jdk8/build/hotspot: 73 new changesets
Message-ID: <20120118230539.46DAB479DC@hg.openjdk.java.net>

Changeset: ed621d125d02
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ed621d125d02

Added tag jdk8-b21 for changeset 9952d1c439d6

! .hgtags

Changeset: 0841c0ec2ed6
Author:    amurillo
Date:      2011-12-23 15:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0841c0ec2ed6

7123810: new hotspot build - hs23-b10
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3b2b58fb1425
Author:    tonyp
Date:      2011-12-20 12:59 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3b2b58fb1425

7123165: G1: output during parallel verification can get messed up
Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent.
Reviewed-by: brutisso, johnc, jmasa

! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: d15b458c4225
Author:    jmasa
Date:      2011-12-20 20:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d15b458c4225

Merge


Changeset: 67fdcb391461
Author:    tonyp
Date:      2011-12-21 07:53 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/67fdcb391461

7119027: G1: use atomics to update RS length / predict time of inc CSet
Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way.
Reviewed-by: brutisso, iveresov

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

Changeset: 441e946dc1af
Author:    jmasa
Date:      2011-12-14 13:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/441e946dc1af

7121618: Change type of number of GC workers to unsigned int.
Summary: Change variables representing the number of GC workers to uint from int and size_t.  Change the parameter in work(int i) to work(uint worker_id).
Reviewed-by: brutisso, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! src/share/vm/utilities/yieldingWorkgroup.cpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: 1cbe7978b021
Author:    brutisso
Date:      2011-12-21 22:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1cbe7978b021

7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx
Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size
Reviewed-by: tonyp, johnc

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 7faca6dfa2ed
Author:    jmasa
Date:      2011-12-27 12:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7faca6dfa2ed

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 4ceaf61479fc
Author:    dcubed
Date:      2011-12-22 12:50 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4ceaf61479fc

7122253: Instrumentation.retransformClasses() leaks class bytes
Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache.
Reviewed-by: coleenp, acorn, poonam

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 4ec93d767458
Author:    vladidan
Date:      2011-12-26 20:36 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4ec93d767458

Merge


Changeset: 3db6ea5ce021
Author:    vladidan
Date:      2011-12-29 20:09 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3db6ea5ce021

Merge


Changeset: 20bfb6d15a94
Author:    iveresov
Date:      2011-12-27 16:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/20bfb6d15a94

7124829: NUMA: memory leak on Linux with large pages
Summary: In os::free_memory() use mmap with the same attributes as for the heap space
Reviewed-by: kvn
Contributed-by: Aleksey Ignatenko <aleksey.v.ignatenko at intel.com>

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_implementation/shared/mutableSpace.cpp
! src/share/vm/runtime/os.hpp

Changeset: 776173fc2df9
Author:    stefank
Date:      2011-12-29 07:37 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/776173fc2df9

7125516: G1: ~ConcurrentMark() frees incorrectly
Summary: Replaced the code with a ShouldNotReachHere
Reviewed-by: tonyp, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: 5ee33ff9b1c4
Author:    jmasa
Date:      2012-01-03 10:22 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5ee33ff9b1c4

Merge


Changeset: 75c0a73eee98
Author:    coleenp
Date:      2011-11-17 12:53 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/75c0a73eee98

7102776: Pack instanceKlass boolean fields into single u1 field
Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class.
Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: da4dd142ea01
Author:    bobv
Date:      2011-11-29 14:44 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/da4dd142ea01

Merge

! src/share/vm/code/dependencies.cpp

Changeset: 52b5d32fbfaf
Author:    coleenp
Date:      2011-12-06 18:28 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/52b5d32fbfaf

7117052: instanceKlass::_init_state can be u1 type
Summary: Change instanceKlass::_init_state field to u1 type.
Reviewed-by: bdelsart, coleenp, dholmes, phh, never
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/memory/dump.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: eccc4b1f8945
Author:    vladidan
Date:      2011-12-07 16:47 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/eccc4b1f8945

7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle
Summary: missing release barrier in Monitor::IUnlock
Reviewed-by: dholmes, dice

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

Changeset: 2685ea97b89f
Author:    jiangli
Date:      2011-12-09 11:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2685ea97b89f

Merge

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: 8fdf463085e1
Author:    jiangli
Date:      2011-12-16 17:33 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8fdf463085e1

Merge


Changeset: dca455dea3a7
Author:    bdelsart
Date:      2011-12-20 12:33 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dca455dea3a7

7116216: StackOverflow GC crash
Summary: GC crash for explicit stack overflow checks after a C2I transition.
Reviewed-by: coleenp, never
Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
+ test/compiler/7116216/LargeFrame.java
+ test/compiler/7116216/StackOverflow.java

Changeset: cd5d8cafcc84
Author:    jiangli
Date:      2011-12-28 12:15 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cd5d8cafcc84

7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type.
Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type.
Reviewed-by: never, bdelsart, dholmes
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 05de27e852c4
Author:    jiangli
Date:      2012-01-04 12:36 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/05de27e852c4

Merge

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

Changeset: b6a04c79ccbc
Author:    stefank
Date:      2012-01-02 10:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b6a04c79ccbc

7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1
Summary: Used uintptr_t and void* for all the casts and checks in test_is_in.
Reviewed-by: tonyp, jmasa

! src/share/vm/gc_interface/collectedHeap.cpp

Changeset: 4753e3dda3c8
Author:    jmasa
Date:      2012-01-04 07:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4753e3dda3c8

Merge


Changeset: 2ee4167627a3
Author:    jmasa
Date:      2012-01-05 21:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2ee4167627a3

Merge


Changeset: 7ab5f6318694
Author:    phh
Date:      2012-01-01 11:17 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7ab5f6318694

7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64
Summary: Add rdtsc detection and inline generation.
Reviewed-by: kamg, dholmes
Contributed-by: karen.kinnear at oracle.com

! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp
+ src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp
! src/os_cpu/linux_x86/vm/os_linux_x86.hpp
+ src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp
+ src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/os_cpu/solaris_x86/vm/solaris_x86_64.il
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
+ src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
+ src/share/vm/runtime/os_ext.hpp

Changeset: b16494a69d3d
Author:    phh
Date:      2012-01-03 15:11 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b16494a69d3d

7126185: Clean up lasterror handling, add os::get_last_error()
Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp.
Reviewed-by: kamg, dholmes
Contributed-by: erik.gahlin at oracle.com

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp

Changeset: 5b58979183f9
Author:    dcubed
Date:      2012-01-05 06:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5b58979183f9

7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary
Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for().
Reviewed-by: coleenp, poonam, acorn

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

Changeset: 8a63c6323842
Author:    fparain
Date:      2012-01-05 07:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8a63c6323842

7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint
Reviewed-by: sspitsyn, dcubed, mchung, dholmes

! src/share/vm/services/threadService.cpp

Changeset: 2e0ef19fc891
Author:    phh
Date:      2012-01-05 17:14 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2e0ef19fc891

7126480: Make JVM start time in milliseconds since the Java epoch available
Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time().
Reviewed-by: acorn, dcubed

! src/share/vm/services/management.hpp

Changeset: 66259eca2bf7
Author:    phh
Date:      2012-01-05 17:16 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/66259eca2bf7

Merge


Changeset: 2b3acb34791f
Author:    dcubed
Date:      2012-01-06 16:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2b3acb34791f

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/os.hpp

Changeset: abcceac2f7cd
Author:    iveresov
Date:      2011-12-12 12:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/abcceac2f7cd

7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop)
Summary: Added handles for references to methods in select_task()
Reviewed-by: twisti, kvn

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

Changeset: 7bca37d28f32
Author:    roland
Date:      2011-12-13 10:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7bca37d28f32

7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now
Summary: fix C1's CEE to take inlining into account when the stacks in states are compared.
Reviewed-by: iveresov, never

! src/share/vm/c1/c1_Optimizer.cpp

Changeset: d725f0affb1a
Author:    iveresov
Date:      2011-12-13 17:10 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d725f0affb1a

7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler
Summary: Exercise C2 more in tiered mode with Xcomp
Reviewed-by: kvn, never

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

Changeset: 127b3692c168
Author:    kvn
Date:      2011-12-14 14:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/127b3692c168

7116452: Add support for AVX instructions
Summary: Added support for AVX extension to the x86 instruction set.
Reviewed-by: never

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.hpp
! src/cpu/x86/vm/register_definitions_x86.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/runtime/globals.hpp

Changeset: 669f6a7d5b70
Author:    never
Date:      2011-12-19 14:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/669f6a7d5b70

7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type
Reviewed-by: kvn

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

Changeset: 65149e74c706
Author:    kvn
Date:      2011-12-20 00:55 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/65149e74c706

7121648: Use 3-operands SIMD instructions on x86 with AVX
Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX.
Reviewed-by: never

! make/bsd/makefiles/adlc.make
! make/linux/makefiles/adlc.make
! make/solaris/makefiles/adlc.make
! make/windows/makefiles/adlc.make
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
+ src/cpu/x86/vm/x86.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/matcher.cpp

Changeset: 069ab3f976d3
Author:    stefank
Date:      2011-12-07 11:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/069ab3f976d3

7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions
Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix.
Reviewed-by: never, bdelsart, coleenp, jrose

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassOop.hpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/shark/sharkIntrinsics.cpp
! src/share/vm/shark/sharkTopLevelBlock.cpp

Changeset: 1dc233a8c7fe
Author:    roland
Date:      2011-12-20 16:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1dc233a8c7fe

7121140: Allocation paths require explicit memory synchronization operations for RMO systems
Summary: adds store store barrier after initialization of header and body of objects.
Reviewed-by: never, kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.hpp

Changeset: e5ac210043cd
Author:    roland
Date:      2011-12-22 10:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e5ac210043cd

7123108: C1: assert(if_state != NULL) failed: states do not match up
Summary: In CEE, ensure if and common successor state are at the same inline level
Reviewed-by: never

! src/share/vm/c1/c1_Optimizer.cpp
+ test/compiler/7123108/Test7123108.java

Changeset: b642b49f9738
Author:    roland
Date:      2011-12-23 09:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b642b49f9738

7123253: C1: in store check code, usage of registers may be incorrect
Summary: fix usage of input register in assembly code for store check.
Reviewed-by: never

! src/share/vm/c1/c1_LIR.cpp

Changeset: 40c2484c09e1
Author:    kvn
Date:      2011-12-23 15:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/40c2484c09e1

7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM
Summary: Distance is too large for one short branch in string_indexofC8().
Reviewed-by: iveresov

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp

Changeset: d12a66fa3820
Author:    kvn
Date:      2011-12-27 15:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d12a66fa3820

7123954: Some CTW test crash with SIGSEGV
Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated.
Reviewed-by: iveresov

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/macro.cpp

Changeset: 8940fd98d540
Author:    kvn
Date:      2011-12-29 11:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8940fd98d540

Merge

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 9c87bcb3b4dd
Author:    kvn
Date:      2011-12-30 11:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9c87bcb3b4dd

7125879: assert(proj != NULL) failed: must be found
Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call.
Reviewed-by: iveresov, twisti

! src/share/vm/opto/macro.cpp
+ test/compiler/7125879/Test7125879.java

Changeset: 1cb50d7a9d95
Author:    iveresov
Date:      2012-01-05 17:25 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1cb50d7a9d95

7119294: Two command line options cause JVM to crash
Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64
Reviewed-by: kvn

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: 22cee0ee8927
Author:    kvn
Date:      2012-01-06 20:09 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/22cee0ee8927

Merge

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parseHelper.cpp

Changeset: 8f8b94305aff
Author:    dcubed
Date:      2012-01-11 19:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8f8b94305aff

7129240: backout fix for 7102776 until 7128770 is resolved
Reviewed-by: phh, bobv, coleenp, dcubed
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 4f25538b54c9
Author:    fparain
Date:      2012-01-09 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4f25538b54c9

7120511: Add diagnostic commands
Reviewed-by: acorn, phh, dcubed, sspitsyn

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/diagnosticFramework.cpp
! src/share/vm/services/diagnosticFramework.hpp
! src/share/vm/services/management.cpp

Changeset: 865e0817f32b
Author:    kamg
Date:      2012-01-10 15:47 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/865e0817f32b

Merge

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

Changeset: efdf6985a3a2
Author:    kamg
Date:      2012-01-12 09:59 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/efdf6985a3a2

Merge


Changeset: 5da7201222d5
Author:    kvn
Date:      2012-01-07 10:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5da7201222d5

7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM
Summary: Change yank_if_dead() to recursive method to remove all dead inputs.
Reviewed-by: never

! src/cpu/sparc/vm/sparc.ad
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/postaloc.cpp

Changeset: e9a5e0a812c8
Author:    kvn
Date:      2012-01-07 13:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e9a5e0a812c8

7125896: Eliminate nested locks
Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object.
Reviewed-by: never, twisti

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/ci/ciTypeFlow.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/deoptimization.cpp

Changeset: 35acf8f0a2e4
Author:    kvn
Date:      2012-01-10 18:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/35acf8f0a2e4

7128352: assert(obj_node == obj) failed
Summary: Compare uncasted object nodes.
Reviewed-by: never

! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/subnode.cpp
! test/compiler/7116216/StackOverflow.java

Changeset: c8d8e124380c
Author:    kvn
Date:      2012-01-12 12:28 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c8d8e124380c

7064302: JDK7 build 147 crashed after testing my java 6-compiled web app
Summary: Don't split CMove node if it's control edge is different from split region.
Reviewed-by: never

! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp

Changeset: 31a5b9aad4bc
Author:    jrose
Date:      2012-01-13 00:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/31a5b9aad4bc

Merge

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

Changeset: bacb651cf5bf
Author:    tonyp
Date:      2012-01-05 05:54 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bacb651cf5bf

7113006: G1: excessive ergo output when an evac failure happens
Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts.
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp

Changeset: 5fd354a959c5
Author:    jmasa
Date:      2012-01-05 21:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5fd354a959c5

Merge


Changeset: 023652e49ac0
Author:    johnc
Date:      2011-12-23 11:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/023652e49ac0

7121496: G1: do the per-region evacuation failure handling work in parallel
Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask.
Reviewed-by: tonyp, iveresov

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
+ src/share/vm/gc_implementation/g1/g1EvacFailure.hpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp

Changeset: 02838862dec8
Author:    tonyp
Date:      2012-01-07 00:43 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/02838862dec8

7121623: G1: always be able to reliably calculate the length of a forwarded chunked array
Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects.
Reviewed-by: johnc, ysr, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 97c00e21fecb
Author:    tonyp
Date:      2012-01-09 23:50 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/97c00e21fecb

7125281: G1: heap expansion code is replicated
Reviewed-by: brutisso, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 1d6185f732aa
Author:    brutisso
Date:      2012-01-10 20:02 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1d6185f732aa

7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80
Reviewed-by: tonyp, jmasa

! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 2ace1c4ee8da
Author:    tonyp
Date:      2012-01-10 18:58 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2ace1c4ee8da

6888336: G1: avoid explicitly marking and pushing objects in survivor spaces
Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object).
Reviewed-by: johnc, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.hpp
! src/share/vm/gc_implementation/g1/satbQueue.cpp
! src/share/vm/gc_implementation/g1/satbQueue.hpp

Changeset: 9d4f4a1825e4
Author:    brutisso
Date:      2012-01-13 01:55 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9d4f4a1825e4

Merge


Changeset: 5acd82522540
Author:    brutisso
Date:      2012-01-13 06:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5acd82522540

Merge


Changeset: b0ff910edfc9
Author:    kvn
Date:      2012-01-12 14:45 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b0ff910edfc9

7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed
Summary: Do not common BoxLock nodes and avoid creating phis of boxes.
Reviewed-by: never

! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/parse1.cpp

Changeset: f4d8930a45b9
Author:    jrose
Date:      2012-01-13 00:51 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f4d8930a45b9

Merge


Changeset: 89d0a5d40008
Author:    kvn
Date:      2012-01-13 12:58 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/89d0a5d40008

7129618: assert(obj_node->eqv_uncast(obj),"");
Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks).
Reviewed-by: iveresov

! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/macro.cpp

Changeset: e504fd26c073
Author:    kvn
Date:      2012-01-13 14:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e504fd26c073

Merge


Changeset: 513351373923
Author:    amurillo
Date:      2012-01-14 00:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/513351373923

Merge


Changeset: 24727fb37561
Author:    amurillo
Date:      2012-01-14 00:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/24727fb37561

Added tag hs23-b10 for changeset 513351373923

! .hgtags



From david.katleman at sun.com  Wed Jan 18 23:06:47 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 23:06:47 +0000
Subject: hg: jdk8/build/jaxp: Added tag jdk8-b21 for changeset d41eeadf5c13
Message-ID: <20120118230647.1C924479DD@hg.openjdk.java.net>

Changeset: cf9d6ec44f89
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxp/rev/cf9d6ec44f89

Added tag jdk8-b21 for changeset d41eeadf5c13

! .hgtags



From david.katleman at sun.com  Wed Jan 18 23:06:54 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 23:06:54 +0000
Subject: hg: jdk8/build/jaxws: Added tag jdk8-b21 for changeset c266cab0e3ff
Message-ID: <20120118230654.64C89479DE@hg.openjdk.java.net>

Changeset: 8d3df89b0f2d
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxws/rev/8d3df89b0f2d

Added tag jdk8-b21 for changeset c266cab0e3ff

! .hgtags



From david.katleman at sun.com  Wed Jan 18 23:07:04 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 23:07:04 +0000
Subject: hg: jdk8/build/jdk: Added tag jdk8-b21 for changeset 664fa4fb0ee4
Message-ID: <20120118230714.1F57D479DF@hg.openjdk.java.net>

Changeset: dda27c73d8db
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/dda27c73d8db

Added tag jdk8-b21 for changeset 664fa4fb0ee4

! .hgtags



From david.katleman at sun.com  Wed Jan 18 23:08:21 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 18 Jan 2012 23:08:21 +0000
Subject: hg: jdk8/build/langtools: Added tag jdk8-b21 for changeset
	bcb21abf1c41
Message-ID: <20120118230823.AD201479E1@hg.openjdk.java.net>

Changeset: 390a7828ae18
Author:    katleman
Date:      2012-01-13 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/390a7828ae18

Added tag jdk8-b21 for changeset bcb21abf1c41

! .hgtags



From david.holmes at oracle.com  Thu Jan 19 00:24:56 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Jan 2012 10:24:56 +1000
Subject: RFR: 7115200
In-Reply-To: <4F168755.7030505@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
Message-ID: <4F1762D8.6060003@oracle.com>

Rickard,

This looks okay to me (have you tested setting JAVASE_EMBEDDED?)

For the record once 7130909 is pushed I'll be looking at moving the JFR 
build rules, and the SE Embedded build rules out of the Open repository.

David

On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
> Please review the updated webrev, David Holmes pointed out that we
> shouldn't build JFR for the embedded environments.
>
> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>
> Thanks
> Rickard
>
> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>> CR7115200: Add Java FlightRecorder phase 1
>> Makefile changes to enable builds of the JDK with JFR.
>>
>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>
>> Thanks
>> Rickard
>


From david.holmes at oracle.com  Thu Jan 19 03:30:26 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Jan 2012 13:30:26 +1000
Subject: Customized make file inclusion
In-Reply-To: <84663C8D-C056-4B92-8B93-3D985C71E6A9@oracle.com>
References: <4F13AF13.2090004@oracle.com>
	<1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>
	<4F1639DE.5040909@oracle.com>
	<84663C8D-C056-4B92-8B93-3D985C71E6A9@oracle.com>
Message-ID: <4F178E52.5040503@oracle.com>

Hi Kelly,

On 19/01/2012 2:22 AM, Kelly O'Hair wrote:
>
> On Jan 17, 2012, at 7:17 PM, David Holmes wrote:
>
>> On 18/01/2012 7:07 AM, Kelly O'Hair wrote:
>>> Generally, I have no objection to this change.
>>>
>>> But instead of setting it to NO_SUCH_PATH, I would not set it at all, and avoid the $(shell) to see if it
>>> exists completely.  Just don't set CUSTOM_MAKE_DIR if it does not exist.
>>> Then you don't need the HAS_CUSTOM_MAKE, it can just be ifdef CUSTOM_MAKE_DIR
>>
>> But I/we want the default setting to occur in the build files and not require that it be set externally. My final suggestion gets rid of the HAS_CUSTOM_MAKE and the shell usage. Incorporating your suggestion it simplifies to:
>>
>> ifneq ($(OPENJDK),true)
>>   CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
>> endif
>
> Or something like:
>
> # Custom makefile additions
> ifneq ($(OPENJDK),true)
>    CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
>    # This directory should exist if OPENJDK is not "true"
>    ifeq ($(shell if [ ! -d $(CUSTOM_MAKE_DIR) ]; then echo "missing"; fi),missing)
>      x:=$(error "ERROR: Not OPENJDK, and missing $(CUSTOM_MAKE_DIR)")
>    endif
> endif

Not sure we need to force it to be available. Seems this kind of thing 
belongs in a sanity test if anywhere, but personally I don't think it 
has to be enforced.

>>
>> in Defs.gmk and then:
>>
>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>
> And:
>
> # Custom makefile additions
> ifdef CUSTOM_MAKE_DIR
>    include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
> endif

The -include is accounting not only for the directory not being present 
but also the actual file. Over time we may add these include hooks to 
support a number of different use-cases but that doesn't mean that 
anybody involved in any single use-case needs to provide every single 
custom file that might exist.

>>
>> as needed. Though I may get an error with CUSTOM_MAKE_DIR being undefined in which case I'll need to declare it for OpenJDK builds.
>
> Undefined is the same as being defined as empty in terms of expansion $(var)

Was unsure as I see examples where people ensure a variable is always 
defined in both an if and else clause - even if one is empty.

Thanks,
David
-----

>>
>>> Not sure I like the word CUSTOM, but that's just a name debate.
>>
>> It customizes the build logic. I preferred it to the "alt" name we use for hotspot as here it isn't an alternative but an addition. Anyway just a name game.
>
> Not a big deal, but kind of liked the piggyback idea. ;^)
>
> -kto
>
>>
>> Thanks,
>> David
>>
>>> Maybe ADDON or MODDING or MODS or oo oo PIGGYBACK? ;^)
>>> http://3.bp.blogspot.com/-cHeD4qJSB44/TbMtSsAiY4I/AAAAAAAAA1c/gctQfVffu_o/s1600/PiggyBack.jpg
>>>
>>> -kto
>>>
>>> On Jan 15, 2012, at 9:01 PM, David Holmes wrote:
>>>
>>>> Presently the build system contains some files, and directives involving those files, that supports the building of the Java SE Embedded product. What I would like to do is remove direct support for this and replace it with a more general mechanism that allows for custom make files to be included from an arbitrary location - which then allows for the removal of the embedded specific files.
>>>>
>>>> Initially I've modeled this on some other conditional mechanisms by defining the default location for non-OpenJDK builds, checking its existence and then using that as a guard for the individual files.
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
>>>>
>>>> ! ifneq ($(OPENJDK),true)
>>>> !   CUSTOM_MAKE_DIR_REL=closed
>>>> ! else
>>>> !   CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>>> ! endif
>>>> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>>>
>>>> + # Use this variable to guard inclusion of the custom files
>>>> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then echo 1; else echo 0; fi)
>>>>
>>>> ...
>>>>
>>>> + ifeq ($(HAS_CUSTOM_MAKE),1)
>>>> +   include $(CUSTOM_MAKE_DIR)/Defs.gmk
>>>> + endif
>>>>
>>>> Initially there are only two hooks for these custom files:
>>>>
>>>> 1. At the end common/Defs.gmk (as it gets included by all the Makefiles)
>>>> 2. In the top-level JDK Makefile, including a custom Release.gmk
>>>>
>>>> Naturally these map to the existing uses of the *-embedded.gmk files.
>>>>
>>>> It then occurred to me that if someone wanted to add an additional hook somewhere else, that it might be best to check for the existence of the actual file rather than a root directory for all such files. That led me to consider a function custom_include(<filename>) to hide the existence logic. But I wasn't sure if a function could contain an include directive and upon checking on that I discovered a much simpler approach: the -include directive. This is like the include directive but does not trigger an error if the file does not exist. So we would simply have this in Defs.gmk:
>>>>
>>>> ifneq ($(OPENJDK),true)
>>>>    CUSTOM_MAKE_DIR_REL=closed
>>>> else
>>>>    CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>>> endif
>>>> CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>>>
>>>> and then
>>>>
>>>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>>>
>>>> wherever we needed it (again initially only the two locations I mentioned).
>>>>
>>>> I'd like to hear people's opinions on this.
>>>>
>>>> Thanks,
>>>> David
>>>
>


From david.holmes at oracle.com  Thu Jan 19 05:29:26 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Jan 2012 15:29:26 +1000
Subject: Customized make file inclusion
In-Reply-To: <4F178E52.5040503@oracle.com>
References: <4F13AF13.2090004@oracle.com>
	<1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>
	<4F1639DE.5040909@oracle.com>
	<84663C8D-C056-4B92-8B93-3D985C71E6A9@oracle.com>
	<4F178E52.5040503@oracle.com>
Message-ID: <4F17AA36.4020801@oracle.com>

FYI here is proposed webrev:

http://cr.openjdk.java.net/~dholmes/7130909/webrev/

CR 7130909 was filed.

David

On 19/01/2012 1:30 PM, David Holmes wrote:
> Hi Kelly,
>
> On 19/01/2012 2:22 AM, Kelly O'Hair wrote:
>>
>> On Jan 17, 2012, at 7:17 PM, David Holmes wrote:
>>
>>> On 18/01/2012 7:07 AM, Kelly O'Hair wrote:
>>>> Generally, I have no objection to this change.
>>>>
>>>> But instead of setting it to NO_SUCH_PATH, I would not set it at
>>>> all, and avoid the $(shell) to see if it
>>>> exists completely. Just don't set CUSTOM_MAKE_DIR if it does not exist.
>>>> Then you don't need the HAS_CUSTOM_MAKE, it can just be ifdef
>>>> CUSTOM_MAKE_DIR
>>>
>>> But I/we want the default setting to occur in the build files and not
>>> require that it be set externally. My final suggestion gets rid of
>>> the HAS_CUSTOM_MAKE and the shell usage. Incorporating your
>>> suggestion it simplifies to:
>>>
>>> ifneq ($(OPENJDK),true)
>>> CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
>>> endif
>>
>> Or something like:
>>
>> # Custom makefile additions
>> ifneq ($(OPENJDK),true)
>> CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
>> # This directory should exist if OPENJDK is not "true"
>> ifeq ($(shell if [ ! -d $(CUSTOM_MAKE_DIR) ]; then echo "missing";
>> fi),missing)
>> x:=$(error "ERROR: Not OPENJDK, and missing $(CUSTOM_MAKE_DIR)")
>> endif
>> endif
>
> Not sure we need to force it to be available. Seems this kind of thing
> belongs in a sanity test if anywhere, but personally I don't think it
> has to be enforced.
>
>>>
>>> in Defs.gmk and then:
>>>
>>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>
>> And:
>>
>> # Custom makefile additions
>> ifdef CUSTOM_MAKE_DIR
>> include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>> endif
>
> The -include is accounting not only for the directory not being present
> but also the actual file. Over time we may add these include hooks to
> support a number of different use-cases but that doesn't mean that
> anybody involved in any single use-case needs to provide every single
> custom file that might exist.
>
>>>
>>> as needed. Though I may get an error with CUSTOM_MAKE_DIR being
>>> undefined in which case I'll need to declare it for OpenJDK builds.
>>
>> Undefined is the same as being defined as empty in terms of expansion
>> $(var)
>
> Was unsure as I see examples where people ensure a variable is always
> defined in both an if and else clause - even if one is empty.
>
> Thanks,
> David
> -----
>
>>>
>>>> Not sure I like the word CUSTOM, but that's just a name debate.
>>>
>>> It customizes the build logic. I preferred it to the "alt" name we
>>> use for hotspot as here it isn't an alternative but an addition.
>>> Anyway just a name game.
>>
>> Not a big deal, but kind of liked the piggyback idea. ;^)
>>
>> -kto
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Maybe ADDON or MODDING or MODS or oo oo PIGGYBACK? ;^)
>>>> http://3.bp.blogspot.com/-cHeD4qJSB44/TbMtSsAiY4I/AAAAAAAAA1c/gctQfVffu_o/s1600/PiggyBack.jpg
>>>>
>>>>
>>>> -kto
>>>>
>>>> On Jan 15, 2012, at 9:01 PM, David Holmes wrote:
>>>>
>>>>> Presently the build system contains some files, and directives
>>>>> involving those files, that supports the building of the Java SE
>>>>> Embedded product. What I would like to do is remove direct support
>>>>> for this and replace it with a more general mechanism that allows
>>>>> for custom make files to be included from an arbitrary location -
>>>>> which then allows for the removal of the embedded specific files.
>>>>>
>>>>> Initially I've modeled this on some other conditional mechanisms by
>>>>> defining the default location for non-OpenJDK builds, checking its
>>>>> existence and then using that as a guard for the individual files.
>>>>>
>>>>> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
>>>>>
>>>>> ! ifneq ($(OPENJDK),true)
>>>>> ! CUSTOM_MAKE_DIR_REL=closed
>>>>> ! else
>>>>> ! CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>>>> ! endif
>>>>> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>>>>
>>>>> + # Use this variable to guard inclusion of the custom files
>>>>> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then
>>>>> echo 1; else echo 0; fi)
>>>>>
>>>>> ...
>>>>>
>>>>> + ifeq ($(HAS_CUSTOM_MAKE),1)
>>>>> + include $(CUSTOM_MAKE_DIR)/Defs.gmk
>>>>> + endif
>>>>>
>>>>> Initially there are only two hooks for these custom files:
>>>>>
>>>>> 1. At the end common/Defs.gmk (as it gets included by all the
>>>>> Makefiles)
>>>>> 2. In the top-level JDK Makefile, including a custom Release.gmk
>>>>>
>>>>> Naturally these map to the existing uses of the *-embedded.gmk files.
>>>>>
>>>>> It then occurred to me that if someone wanted to add an additional
>>>>> hook somewhere else, that it might be best to check for the
>>>>> existence of the actual file rather than a root directory for all
>>>>> such files. That led me to consider a function
>>>>> custom_include(<filename>) to hide the existence logic. But I
>>>>> wasn't sure if a function could contain an include directive and
>>>>> upon checking on that I discovered a much simpler approach: the
>>>>> -include directive. This is like the include directive but does not
>>>>> trigger an error if the file does not exist. So we would simply
>>>>> have this in Defs.gmk:
>>>>>
>>>>> ifneq ($(OPENJDK),true)
>>>>> CUSTOM_MAKE_DIR_REL=closed
>>>>> else
>>>>> CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>>>> endif
>>>>> CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>>>>
>>>>> and then
>>>>>
>>>>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>>>>
>>>>> wherever we needed it (again initially only the two locations I
>>>>> mentioned).
>>>>>
>>>>> I'd like to hear people's opinions on this.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>>


From rickard.backman at oracle.com  Thu Jan 19 10:03:47 2012
From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=)
Date: Thu, 19 Jan 2012 11:03:47 +0100
Subject: RFR: 7115200
In-Reply-To: <4F1762D8.6060003@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
	<4F1762D8.6060003@oracle.com>
Message-ID: <4F17EA83.2090301@oracle.com>

David,

thanks for the review.
I've tested with JAVASE_EMBEDDED=true and there is no jfr.jar in 
j2sdk-image/jre/lib, the same is true with OPENJDK=true. Running without 
those creates the jfr.jar in that directory.

I added another set of ifndef's to get rid of warnings.
The change is here: 
http://http://cr.openjdk.java.net/~rbackman/7115200.u2/webrev/

Thanks
/R

On 01/19/2012 01:24 AM, David Holmes wrote:
> Rickard,
>
> This looks okay to me (have you tested setting JAVASE_EMBEDDED?)
>
> For the record once 7130909 is pushed I'll be looking at moving the JFR
> build rules, and the SE Embedded build rules out of the Open repository.
>
> David
>
> On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
>> Please review the updated webrev, David Holmes pointed out that we
>> shouldn't build JFR for the embedded environments.
>>
>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>>
>> Thanks
>> Rickard
>>
>> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>>> CR7115200: Add Java FlightRecorder phase 1
>>> Makefile changes to enable builds of the JDK with JFR.
>>>
>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>>
>>> Thanks
>>> Rickard
>>



From david.holmes at oracle.com  Thu Jan 19 11:29:15 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Jan 2012 21:29:15 +1000
Subject: RFR: 7115200
In-Reply-To: <4F17EA83.2090301@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
	<4F1762D8.6060003@oracle.com> <4F17EA83.2090301@oracle.com>
Message-ID: <4F17FE8B.2010204@oracle.com>

On 19/01/2012 8:03 PM, Rickard B?ckman wrote:
> David,
>
> thanks for the review.
> I've tested with JAVASE_EMBEDDED=true and there is no jfr.jar in
> j2sdk-image/jre/lib, the same is true with OPENJDK=true. Running without
> those creates the jfr.jar in that directory.
>
> I added another set of ifndef's to get rid of warnings.

I was wondering if those extra bits eg EXPORTED_PRIVATE_PKGS would cause 
a problem if they didn't exist.

Looks ok.

Thanks,
David

> The change is here:
> http://http://cr.openjdk.java.net/~rbackman/7115200.u2/webrev/



> Thanks
> /R
>
> On 01/19/2012 01:24 AM, David Holmes wrote:
>> Rickard,
>>
>> This looks okay to me (have you tested setting JAVASE_EMBEDDED?)
>>
>> For the record once 7130909 is pushed I'll be looking at moving the JFR
>> build rules, and the SE Embedded build rules out of the Open repository.
>>
>> David
>>
>> On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
>>> Please review the updated webrev, David Holmes pointed out that we
>>> shouldn't build JFR for the embedded environments.
>>>
>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>>>
>>> Thanks
>>> Rickard
>>>
>>> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>>>> CR7115200: Add Java FlightRecorder phase 1
>>>> Makefile changes to enable builds of the JDK with JFR.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>>>
>>>> Thanks
>>>> Rickard
>>>
>


From robert.ottenhag at oracle.com  Thu Jan 19 16:58:29 2012
From: robert.ottenhag at oracle.com (Robert Ottenhag)
Date: Thu, 19 Jan 2012 17:58:29 +0100
Subject: Build openjdk in Ubuntu 11.10
In-Reply-To: <B98A4187-0BD7-4286-B75A-27487B919FA4@oracle.com>
References: <20120113175420.B43F2F21@eggemoggin.niobe.net>
	<B98A4187-0BD7-4286-B75A-27487B919FA4@oracle.com>
Message-ID: <4F184BB5.5030500@oracle.com>

Yes, the patch looks good.

/Robert

On 01/18/2012 06:38 PM, Kelly O'Hair wrote:
> Patch looks fine to me.
>
> -kto
>
> On Jan 13, 2012, at 9:54 AM, mark.reinhold at oracle.com wrote:
>
>> 2012/1/13 9:33 -0800, michael.j.silverstri at gmail.com:
>>> I am getting the following error when building openjdk 7.0 on ubuntu 11.10
>>> But I already have the package libasound2-dev installed.
>> This is 7110396.  You need this patch:
>>
>> diff --git a/make/javax/sound/jsoundalsa/Makefile b/make/javax/sound/jsoundalsa/Makefile
>> --- a/make/javax/sound/jsoundalsa/Makefile
>> +++ b/make/javax/sound/jsoundalsa/Makefile
>> @@ -65,7 +65,7 @@
>> 	$(MIDIFILES_export) \
>> 	$(PORTFILES_export)
>>
>> -LDFLAGS += -lasound
>> +OTHER_LDLIBS += -lasound
>>
>> CPPFLAGS += \
>> 	-DUSE_DAUDIO=TRUE \
>>
>> This is a tiny revision of the patch I originally proposed [1].
>> If someone could review this then I'll merge and push it.
>>
>> - Mark
>>
>>
>> [1] http://mail.openjdk.java.net/pipermail/build-dev/2011-November/005188.html


-- 
Oracle
Robert Ottenhag | Senior Member of Technical Staff
Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
Oracle Java HotSpot Virtual Machine
ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm

Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746

Green Oracle

Oracle is committed to developing practices and products that help protect the environment
--



From robert.ottenhag at oracle.com  Thu Jan 19 17:14:53 2012
From: robert.ottenhag at oracle.com (Robert Ottenhag)
Date: Thu, 19 Jan 2012 18:14:53 +0100
Subject: RFR: 7115200
In-Reply-To: <4F17EA83.2090301@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
	<4F1762D8.6060003@oracle.com> <4F17EA83.2090301@oracle.com>
Message-ID: <4F184F8D.8040503@oracle.com>

Rickard,

* make/com/oracle/Makefile:
- just skip the separate JFR variable and use "SUBDIRS += jfr" to add to 
the previously defined SUBDIRS variable, or if necessary "SUBDIRS = jfr 
$(SUBDIRS)" if it is necessary to build it first, which I doubt.

+ ifndef OPENJDK
+   ifndef JAVASE_EMBEDDED
+     SUBDIRS += jfr
+   endif
+ endif

* make/common/Defs.gmk:
- skip VPATH0.h and prepend it using

+ ifndef OPENJDK
+   VPATH.h = $(CLOSED_SHARE_SRC)/javavm/export$(CLASSPATH_SEPARATOR)$(VPATH.h)
+ endif


/Robert


On 01/19/2012 11:03 AM, Rickard B?ckman wrote:
> David,
>
> thanks for the review.
> I've tested with JAVASE_EMBEDDED=true and there is no jfr.jar in 
> j2sdk-image/jre/lib, the same is true with OPENJDK=true. Running 
> without those creates the jfr.jar in that directory.
>
> I added another set of ifndef's to get rid of warnings.
> The change is here: 
> http://http://cr.openjdk.java.net/~rbackman/7115200.u2/webrev/
>
> Thanks
> /R
>
> On 01/19/2012 01:24 AM, David Holmes wrote:
>> Rickard,
>>
>> This looks okay to me (have you tested setting JAVASE_EMBEDDED?)
>>
>> For the record once 7130909 is pushed I'll be looking at moving the JFR
>> build rules, and the SE Embedded build rules out of the Open repository.
>>
>> David
>>
>> On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
>>> Please review the updated webrev, David Holmes pointed out that we
>>> shouldn't build JFR for the embedded environments.
>>>
>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>>>
>>> Thanks
>>> Rickard
>>>
>>> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>>>> CR7115200: Add Java FlightRecorder phase 1
>>>> Makefile changes to enable builds of the JDK with JFR.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>>>
>>>> Thanks
>>>> Rickard
>>>
>


-- 
Oracle
Robert Ottenhag | Senior Member of Technical Staff
Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
Oracle Java HotSpot Virtual Machine
ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm

Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746

Green Oracle

Oracle is committed to developing practices and products that help protect the environment
--



From kelly.ohair at oracle.com  Thu Jan 19 22:00:35 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 19 Jan 2012 14:00:35 -0800
Subject: RFR: 7115200
In-Reply-To: <4F184F8D.8040503@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
	<4F1762D8.6060003@oracle.com> <4F17EA83.2090301@oracle.com>
	<4F184F8D.8040503@oracle.com>
Message-ID: <B1D89839-2927-4E4B-B5C3-BC1344DEBA55@oracle.com>

I tend to agree with Robert.

-kto

On Jan 19, 2012, at 9:14 AM, Robert Ottenhag wrote:

> Rickard,
> 
> * make/com/oracle/Makefile:
> - just skip the separate JFR variable and use "SUBDIRS += jfr" to add to the previously defined SUBDIRS variable, or if necessary "SUBDIRS = jfr $(SUBDIRS)" if it is necessary to build it first, which I doubt.
> 
> + ifndef OPENJDK
> +   ifndef JAVASE_EMBEDDED
> +     SUBDIRS += jfr
> +   endif
> + endif
> 
> * make/common/Defs.gmk:
> - skip VPATH0.h and prepend it using
> 
> + ifndef OPENJDK
> +   VPATH.h = $(CLOSED_SHARE_SRC)/javavm/export$(CLASSPATH_SEPARATOR)$(VPATH.h)
> + endif
> 
> 
> /Robert
> 
> 
> On 01/19/2012 11:03 AM, Rickard B?ckman wrote:
>> David,
>> 
>> thanks for the review.
>> I've tested with JAVASE_EMBEDDED=true and there is no jfr.jar in j2sdk-image/jre/lib, the same is true with OPENJDK=true. Running without those creates the jfr.jar in that directory.
>> 
>> I added another set of ifndef's to get rid of warnings.
>> The change is here: http://http://cr.openjdk.java.net/~rbackman/7115200.u2/webrev/
>> 
>> Thanks
>> /R
>> 
>> On 01/19/2012 01:24 AM, David Holmes wrote:
>>> Rickard,
>>> 
>>> This looks okay to me (have you tested setting JAVASE_EMBEDDED?)
>>> 
>>> For the record once 7130909 is pushed I'll be looking at moving the JFR
>>> build rules, and the SE Embedded build rules out of the Open repository.
>>> 
>>> David
>>> 
>>> On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
>>>> Please review the updated webrev, David Holmes pointed out that we
>>>> shouldn't build JFR for the embedded environments.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>>>> 
>>>> Thanks
>>>> Rickard
>>>> 
>>>> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>>>>> CR7115200: Add Java FlightRecorder phase 1
>>>>> Makefile changes to enable builds of the JDK with JFR.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>>>> 
>>>>> Thanks
>>>>> Rickard
>>>> 
>> 
> 
> 
> -- 
> Oracle
> Robert Ottenhag | Senior Member of Technical Staff
> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
> Oracle Java HotSpot Virtual Machine
> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
> 
> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746
> 
> Green Oracle
> 
> Oracle is committed to developing practices and products that help protect the environment
> --
> 



From kelly.ohair at oracle.com  Thu Jan 19 22:05:37 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 19 Jan 2012 14:05:37 -0800
Subject: Customized make file inclusion
In-Reply-To: <4F17AA36.4020801@oracle.com>
References: <4F13AF13.2090004@oracle.com>
	<1DA22E00-6DEA-48D3-A781-8ED16CEC509B@oracle.com>
	<4F1639DE.5040909@oracle.com>
	<84663C8D-C056-4B92-8B93-3D985C71E6A9@oracle.com>
	<4F178E52.5040503@oracle.com> <4F17AA36.4020801@oracle.com>
Message-ID: <059ADCD7-9A83-41BC-B25C-059F883F349B@oracle.com>

I think that looks fine.

-kto

On Jan 18, 2012, at 9:29 PM, David Holmes wrote:

> FYI here is proposed webrev:
> 
> http://cr.openjdk.java.net/~dholmes/7130909/webrev/
> 
> CR 7130909 was filed.
> 
> David
> 
> On 19/01/2012 1:30 PM, David Holmes wrote:
>> Hi Kelly,
>> 
>> On 19/01/2012 2:22 AM, Kelly O'Hair wrote:
>>> 
>>> On Jan 17, 2012, at 7:17 PM, David Holmes wrote:
>>> 
>>>> On 18/01/2012 7:07 AM, Kelly O'Hair wrote:
>>>>> Generally, I have no objection to this change.
>>>>> 
>>>>> But instead of setting it to NO_SUCH_PATH, I would not set it at
>>>>> all, and avoid the $(shell) to see if it
>>>>> exists completely. Just don't set CUSTOM_MAKE_DIR if it does not exist.
>>>>> Then you don't need the HAS_CUSTOM_MAKE, it can just be ifdef
>>>>> CUSTOM_MAKE_DIR
>>>> 
>>>> But I/we want the default setting to occur in the build files and not
>>>> require that it be set externally. My final suggestion gets rid of
>>>> the HAS_CUSTOM_MAKE and the shell usage. Incorporating your
>>>> suggestion it simplifies to:
>>>> 
>>>> ifneq ($(OPENJDK),true)
>>>> CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
>>>> endif
>>> 
>>> Or something like:
>>> 
>>> # Custom makefile additions
>>> ifneq ($(OPENJDK),true)
>>> CUSTOM_MAKE_DIR = $(BUILDDIR)/closed
>>> # This directory should exist if OPENJDK is not "true"
>>> ifeq ($(shell if [ ! -d $(CUSTOM_MAKE_DIR) ]; then echo "missing";
>>> fi),missing)
>>> x:=$(error "ERROR: Not OPENJDK, and missing $(CUSTOM_MAKE_DIR)")
>>> endif
>>> endif
>> 
>> Not sure we need to force it to be available. Seems this kind of thing
>> belongs in a sanity test if anywhere, but personally I don't think it
>> has to be enforced.
>> 
>>>> 
>>>> in Defs.gmk and then:
>>>> 
>>>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>> 
>>> And:
>>> 
>>> # Custom makefile additions
>>> ifdef CUSTOM_MAKE_DIR
>>> include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>> endif
>> 
>> The -include is accounting not only for the directory not being present
>> but also the actual file. Over time we may add these include hooks to
>> support a number of different use-cases but that doesn't mean that
>> anybody involved in any single use-case needs to provide every single
>> custom file that might exist.
>> 
>>>> 
>>>> as needed. Though I may get an error with CUSTOM_MAKE_DIR being
>>>> undefined in which case I'll need to declare it for OpenJDK builds.
>>> 
>>> Undefined is the same as being defined as empty in terms of expansion
>>> $(var)
>> 
>> Was unsure as I see examples where people ensure a variable is always
>> defined in both an if and else clause - even if one is empty.
>> 
>> Thanks,
>> David
>> -----
>> 
>>>> 
>>>>> Not sure I like the word CUSTOM, but that's just a name debate.
>>>> 
>>>> It customizes the build logic. I preferred it to the "alt" name we
>>>> use for hotspot as here it isn't an alternative but an addition.
>>>> Anyway just a name game.
>>> 
>>> Not a big deal, but kind of liked the piggyback idea. ;^)
>>> 
>>> -kto
>>> 
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>> Maybe ADDON or MODDING or MODS or oo oo PIGGYBACK? ;^)
>>>>> http://3.bp.blogspot.com/-cHeD4qJSB44/TbMtSsAiY4I/AAAAAAAAA1c/gctQfVffu_o/s1600/PiggyBack.jpg
>>>>> 
>>>>> 
>>>>> -kto
>>>>> 
>>>>> On Jan 15, 2012, at 9:01 PM, David Holmes wrote:
>>>>> 
>>>>>> Presently the build system contains some files, and directives
>>>>>> involving those files, that supports the building of the Java SE
>>>>>> Embedded product. What I would like to do is remove direct support
>>>>>> for this and replace it with a more general mechanism that allows
>>>>>> for custom make files to be included from an arbitrary location -
>>>>>> which then allows for the removal of the embedded specific files.
>>>>>> 
>>>>>> Initially I've modeled this on some other conditional mechanisms by
>>>>>> defining the default location for non-OpenJDK builds, checking its
>>>>>> existence and then using that as a guard for the individual files.
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~dholmes/custom-make/webrev/
>>>>>> 
>>>>>> ! ifneq ($(OPENJDK),true)
>>>>>> ! CUSTOM_MAKE_DIR_REL=closed
>>>>>> ! else
>>>>>> ! CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>>>>> ! endif
>>>>>> ! CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>>>>> 
>>>>>> + # Use this variable to guard inclusion of the custom files
>>>>>> + HAS_CUSTOM_MAKE := $(shell if [ -d $(CUSTOM_MAKE_DIR) ]; then
>>>>>> echo 1; else echo 0; fi)
>>>>>> 
>>>>>> ...
>>>>>> 
>>>>>> + ifeq ($(HAS_CUSTOM_MAKE),1)
>>>>>> + include $(CUSTOM_MAKE_DIR)/Defs.gmk
>>>>>> + endif
>>>>>> 
>>>>>> Initially there are only two hooks for these custom files:
>>>>>> 
>>>>>> 1. At the end common/Defs.gmk (as it gets included by all the
>>>>>> Makefiles)
>>>>>> 2. In the top-level JDK Makefile, including a custom Release.gmk
>>>>>> 
>>>>>> Naturally these map to the existing uses of the *-embedded.gmk files.
>>>>>> 
>>>>>> It then occurred to me that if someone wanted to add an additional
>>>>>> hook somewhere else, that it might be best to check for the
>>>>>> existence of the actual file rather than a root directory for all
>>>>>> such files. That led me to consider a function
>>>>>> custom_include(<filename>) to hide the existence logic. But I
>>>>>> wasn't sure if a function could contain an include directive and
>>>>>> upon checking on that I discovered a much simpler approach: the
>>>>>> -include directive. This is like the include directive but does not
>>>>>> trigger an error if the file does not exist. So we would simply
>>>>>> have this in Defs.gmk:
>>>>>> 
>>>>>> ifneq ($(OPENJDK),true)
>>>>>> CUSTOM_MAKE_DIR_REL=closed
>>>>>> else
>>>>>> CUSTOM_MAKE_DIR_REL=NO_SUCH_PATH
>>>>>> endif
>>>>>> CUSTOM_MAKE_DIR=$(BUILDDIR)/$(CUSTOM_MAKE_DIR_REL)
>>>>>> 
>>>>>> and then
>>>>>> 
>>>>>> -include $(CUSTOM_MAKE_DIR)/<path-to-file.gmk>
>>>>>> 
>>>>>> wherever we needed it (again initially only the two locations I
>>>>>> mentioned).
>>>>>> 
>>>>>> I'd like to hear people's opinions on this.
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>> 
>>> 



From rickard.backman at oracle.com  Fri Jan 20 07:46:29 2012
From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=)
Date: Fri, 20 Jan 2012 08:46:29 +0100
Subject: RFR: 7115200
In-Reply-To: <B1D89839-2927-4E4B-B5C3-BC1344DEBA55@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
	<4F1762D8.6060003@oracle.com> <4F17EA83.2090301@oracle.com>
	<4F184F8D.8040503@oracle.com>
	<B1D89839-2927-4E4B-B5C3-BC1344DEBA55@oracle.com>
Message-ID: <4F191BD5.4080901@oracle.com>

Inline.

On 01/19/2012 11:00 PM, Kelly O'Hair wrote:
> I tend to agree with Robert.
>
> -kto
>
> On Jan 19, 2012, at 9:14 AM, Robert Ottenhag wrote:
>
>> Rickard,
>>
>> * make/com/oracle/Makefile:
>> - just skip the separate JFR variable and use "SUBDIRS += jfr" to add to the previously defined SUBDIRS variable, or if necessary "SUBDIRS = jfr $(SUBDIRS)" if it is necessary to build it first, which I doubt.
>>
>> + ifndef OPENJDK
>> +   ifndef JAVASE_EMBEDDED
>> +     SUBDIRS += jfr
>> +   endif
>> + endif

Sure, I just tried to follow the existing conventions of the file. I've 
changed it to be SUBDIRS += jfr.

>>
>> * make/common/Defs.gmk:
>> - skip VPATH0.h and prepend it using
>>
>> + ifndef OPENJDK
>> +   VPATH.h = $(CLOSED_SHARE_SRC)/javavm/export$(CLASSPATH_SEPARATOR)$(VPATH.h)
>> + endif
>>

Once again I tried to reuse existing patterns (VPATH.java). Using the 
suggested pattern also fails as makefile variables are "lazy", so rather 
than prepending you are creating an infinite loop.

/R

>>
>> /Robert
>>
>>
>> On 01/19/2012 11:03 AM, Rickard B?ckman wrote:
>>> David,
>>>
>>> thanks for the review.
>>> I've tested with JAVASE_EMBEDDED=true and there is no jfr.jar in j2sdk-image/jre/lib, the same is true with OPENJDK=true. Running without those creates the jfr.jar in that directory.
>>>
>>> I added another set of ifndef's to get rid of warnings.
>>> The change is here: http://http://cr.openjdk.java.net/~rbackman/7115200.u2/webrev/
>>>
>>> Thanks
>>> /R
>>>
>>> On 01/19/2012 01:24 AM, David Holmes wrote:
>>>> Rickard,
>>>>
>>>> This looks okay to me (have you tested setting JAVASE_EMBEDDED?)
>>>>
>>>> For the record once 7130909 is pushed I'll be looking at moving the JFR
>>>> build rules, and the SE Embedded build rules out of the Open repository.
>>>>
>>>> David
>>>>
>>>> On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
>>>>> Please review the updated webrev, David Holmes pointed out that we
>>>>> shouldn't build JFR for the embedded environments.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>>>>>
>>>>> Thanks
>>>>> Rickard
>>>>>
>>>>> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>>>>>> CR7115200: Add Java FlightRecorder phase 1
>>>>>> Makefile changes to enable builds of the JDK with JFR.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>>>>>
>>>>>> Thanks
>>>>>> Rickard
>>>>>
>>>
>>
>>
>> --
>> Oracle
>> Robert Ottenhag | Senior Member of Technical Staff
>> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
>> Oracle Java HotSpot Virtual Machine
>> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
>>
>> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746
>>
>> Green Oracle
>>
>> Oracle is committed to developing practices and products that help protect the environment
>> --
>>
>



From robert.ottenhag at oracle.com  Fri Jan 20 08:47:13 2012
From: robert.ottenhag at oracle.com (Robert Ottenhag)
Date: Fri, 20 Jan 2012 09:47:13 +0100
Subject: RFR: 7115200
In-Reply-To: <4F191BD5.4080901@oracle.com>
References: <4F15932B.5070107@oracle.com> <4F168755.7030505@oracle.com>
	<4F1762D8.6060003@oracle.com> <4F17EA83.2090301@oracle.com>
	<4F184F8D.8040503@oracle.com>
	<B1D89839-2927-4E4B-B5C3-BC1344DEBA55@oracle.com>
	<4F191BD5.4080901@oracle.com>
Message-ID: <4F192A11.2030102@oracle.com>

Rickard,

as discussed with you off-line, I see that you were only following 
existing patterns, which IMHO is a good thing and simplifies further 
maintenance.

So let's go with the with the changes in 7115200.u2.

Thanks

/Robert

On 01/20/2012 08:46 AM, Rickard B?ckman wrote:
> Inline.
>
> On 01/19/2012 11:00 PM, Kelly O'Hair wrote:
>> I tend to agree with Robert.
>>
>> -kto
>>
>> On Jan 19, 2012, at 9:14 AM, Robert Ottenhag wrote:
>>
>>> Rickard,
>>>
>>> * make/com/oracle/Makefile:
>>> - just skip the separate JFR variable and use "SUBDIRS += jfr" to 
>>> add to the previously defined SUBDIRS variable, or if necessary 
>>> "SUBDIRS = jfr $(SUBDIRS)" if it is necessary to build it first, 
>>> which I doubt.
>>>
>>> + ifndef OPENJDK
>>> +   ifndef JAVASE_EMBEDDED
>>> +     SUBDIRS += jfr
>>> +   endif
>>> + endif
>
> Sure, I just tried to follow the existing conventions of the file. 
> I've changed it to be SUBDIRS += jfr.
>
>>>
>>> * make/common/Defs.gmk:
>>> - skip VPATH0.h and prepend it using
>>>
>>> + ifndef OPENJDK
>>> +   VPATH.h = 
>>> $(CLOSED_SHARE_SRC)/javavm/export$(CLASSPATH_SEPARATOR)$(VPATH.h)
>>> + endif
>>>
>
> Once again I tried to reuse existing patterns (VPATH.java). Using the 
> suggested pattern also fails as makefile variables are "lazy", so 
> rather than prepending you are creating an infinite loop.
>
> /R
>
>>>
>>> /Robert
>>>
>>>
>>> On 01/19/2012 11:03 AM, Rickard B?ckman wrote:
>>>> David,
>>>>
>>>> thanks for the review.
>>>> I've tested with JAVASE_EMBEDDED=true and there is no jfr.jar in 
>>>> j2sdk-image/jre/lib, the same is true with OPENJDK=true. Running 
>>>> without those creates the jfr.jar in that directory.
>>>>
>>>> I added another set of ifndef's to get rid of warnings.
>>>> The change is here: 
>>>> http://http://cr.openjdk.java.net/~rbackman/7115200.u2/webrev/
>>>>
>>>> Thanks
>>>> /R
>>>>
>>>> On 01/19/2012 01:24 AM, David Holmes wrote:
>>>>> Rickard,
>>>>>
>>>>> This looks okay to me (have you tested setting JAVASE_EMBEDDED?)
>>>>>
>>>>> For the record once 7130909 is pushed I'll be looking at moving 
>>>>> the JFR
>>>>> build rules, and the SE Embedded build rules out of the Open 
>>>>> repository.
>>>>>
>>>>> David
>>>>>
>>>>> On 18/01/2012 6:48 PM, Rickard B?ckman wrote:
>>>>>> Please review the updated webrev, David Holmes pointed out that we
>>>>>> shouldn't build JFR for the embedded environments.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200.u1/webrev/
>>>>>>
>>>>>> Thanks
>>>>>> Rickard
>>>>>>
>>>>>> On 01/17/2012 04:26 PM, Rickard B?ckman wrote:
>>>>>>> CR7115200: Add Java FlightRecorder phase 1
>>>>>>> Makefile changes to enable builds of the JDK with JFR.
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/7115200/webrev/
>>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115200
>>>>>>>
>>>>>>> Thanks
>>>>>>> Rickard
>>>>>>
>>>>
>>>
>>>
>>> -- 
>>> Oracle
>>> Robert Ottenhag | Senior Member of Technical Staff
>>> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
>>> Oracle Java HotSpot Virtual Machine
>>> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
>>>
>>> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 
>>> 556254-6746
>>>
>>> Green Oracle
>>>
>>> Oracle is committed to developing practices and products that help 
>>> protect the environment
>>> -- 
>>>
>>
>


-- 
Oracle
Robert Ottenhag | Senior Member of Technical Staff
Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
Oracle Java HotSpot Virtual Machine
ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm

Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746

Green Oracle

Oracle is committed to developing practices and products that help protect the environment
--



From peter.brunet at oracle.com  Mon Jan 23 15:39:37 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 23 Jan 2012 09:39:37 -0600
Subject: building part of jdk 8
Message-ID: <4F1D7F39.8010502@oracle.com>

In the past I was able to build part of jdk 8 but that is not currently
working although I am able to do a full 32 bit build.  I've recently
moved from XP to W7 so my environment might not be set up quite right
yet.  Here's what I do...

// These are done in a bat file before I do any makes
set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
set CLASSPATH=
set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
set CYGWIN=nodosfilewarning
cd c:\Users\Pete\cygwin\bin
bash --login -i

// These are done at the command line
eval `bin/vsvars.sh -v10 -32`
cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log

The error I am getting is

make: *** No rule to make target
`../../../build/windows-i586/btjars/compileproperties.jar', needed by
`compile_all_props'.  Stop.

Since the above has windows-i586 instead of windows-i586-debug it looks
like I need to add another variable when invoking make.

Pete


From Alan.Bateman at oracle.com  Mon Jan 23 18:53:05 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Jan 2012 18:53:05 +0000
Subject: 7132204: Default testset in JPRT should not run all tests
Message-ID: <4F1DAC91.206@oracle.com>


Kelly - this is a change to the JPRT configuration to dial-down the 
number of test targets that are run by default. It also adds a new 
testset, called "core" that runs all langtools and jdk excepts except 
for the AWT/Swing/client tests. A couple of persistent offenders added 
to the ProblemList too. The webrev with the changes is here:

http://cr.openjdk.java.net/~alanb/7132204/webrev/

Thanks,

Alan.


From kelly.ohair at oracle.com  Mon Jan 23 19:04:34 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 23 Jan 2012 11:04:34 -0800
Subject: 7132204: Default testset in JPRT should not run all tests
In-Reply-To: <4F1DAC91.206@oracle.com>
References: <4F1DAC91.206@oracle.com>
Message-ID: <E9CA3423-5CF6-46C7-B729-4A5F53A56AED@oracle.com>

Looks good to me.

-kto

On Jan 23, 2012, at 10:53 AM, Alan Bateman wrote:

> 
> Kelly - this is a change to the JPRT configuration to dial-down the number of test targets that are run by default. It also adds a new testset, called "core" that runs all langtools and jdk excepts except for the AWT/Swing/client tests. A couple of persistent offenders added to the ProblemList too. The webrev with the changes is here:
> 
> http://cr.openjdk.java.net/~alanb/7132204/webrev/
> 
> Thanks,
> 
> Alan.



From peter.brunet at oracle.com  Mon Jan 23 22:54:06 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 23 Jan 2012 16:54:06 -0600
Subject: building part of jdk 8
In-Reply-To: <4F1D7F39.8010502@oracle.com>
References: <4F1D7F39.8010502@oracle.com>
Message-ID: <4F1DE50E.5010206@oracle.com>

Adding ALT_OUTPUTDIR didn't help, e.g.

make ARCH_DATA_MODEL=32 FASTDEBUG=true
ALT_OUTPUTDIR=C:/OpenJDK/jdk8/build/windows-i586-debug 2>&1 | tee build.log

On 1/23/12 9:39 AM, Pete Brunet wrote:
> In the past I was able to build part of jdk 8 but that is not currently
> working although I am able to do a full 32 bit build.  I've recently
> moved from XP to W7 so my environment might not be set up quite right
> yet.  Here's what I do...
>
> // These are done in a bat file before I do any makes
> set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
> set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
> set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
> set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
> set CLASSPATH=
> set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
> set CYGWIN=nodosfilewarning
> cd c:\Users\Pete\cygwin\bin
> bash --login -i
>
> // These are done at the command line
> eval `bin/vsvars.sh -v10 -32`
> cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
> make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>
> The error I am getting is
>
> make: *** No rule to make target
> `../../../build/windows-i586/btjars/compileproperties.jar', needed by
> `compile_all_props'.  Stop.
>
> Since the above has windows-i586 instead of windows-i586-debug it looks
> like I need to add another variable when invoking make.
>
> Pete


From mark.reinhold at oracle.com  Mon Jan 23 23:01:09 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 23 Jan 2012 23:01:09 +0000
Subject: hg: jdk8/build/jdk: 7110396: Sound code fails to build with gcc 4.6
	on multiarch Linux systems
Message-ID: <20120123230138.DB17C47144@hg.openjdk.java.net>

Changeset: d3b334e376d3
Author:    mr
Date:      2012-01-23 12:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/d3b334e376d3

7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems
Reviewed-by: ohair

! make/javax/sound/jsoundalsa/Makefile



From kelly.ohair at oracle.com  Tue Jan 24 02:09:26 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 23 Jan 2012 18:09:26 -0800
Subject: building part of jdk 8
In-Reply-To: <4F1D7F39.8010502@oracle.com>
References: <4F1D7F39.8010502@oracle.com>
Message-ID: <7DD0686B-D779-4CF8-B843-55B2E736CA71@oracle.com>

You need to build everything once first, e.g.
  cd /cygdrive/c/OpenJDK/jdk8/jdk/make/
  make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
then you can go into make/java/awt  and repeatedly
  cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
  make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log

-kto

On Jan 23, 2012, at 7:39 AM, Pete Brunet wrote:

> In the past I was able to build part of jdk 8 but that is not currently
> working although I am able to do a full 32 bit build.  I've recently
> moved from XP to W7 so my environment might not be set up quite right
> yet.  Here's what I do...
> 
> // These are done in a bat file before I do any makes
> set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
> set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
> set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
> set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
> set CLASSPATH=
> set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
> set CYGWIN=nodosfilewarning
> cd c:\Users\Pete\cygwin\bin
> bash --login -i
> 
> // These are done at the command line
> eval `bin/vsvars.sh -v10 -32`
> cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
> make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
> 
> The error I am getting is
> 
> make: *** No rule to make target
> `../../../build/windows-i586/btjars/compileproperties.jar', needed by
> `compile_all_props'.  Stop.
> 
> Since the above has windows-i586 instead of windows-i586-debug it looks
> like I need to add another variable when invoking make.
> 
> Pete



From peter.brunet at oracle.com  Tue Jan 24 03:13:01 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 23 Jan 2012 21:13:01 -0600
Subject: building part of jdk 8
In-Reply-To: <7DD0686B-D779-4CF8-B843-55B2E736CA71@oracle.com>
References: <4F1D7F39.8010502@oracle.com>
	<7DD0686B-D779-4CF8-B843-55B2E736CA71@oracle.com>
Message-ID: <4F1E21BD.8060208@oracle.com>

Hi Kelly, That's almost what I did.  The only difference is that for the
full build (which appears to have been successful) I used a target of
fastdebug_build instead of using FASTDEBUG=true, i.e.

make ARCH_DATA_MODEL=32 ALLOW_DOWNLOADS=true fastdebug_build 2>&1 | tee
build.log

I'll start over with this new approach.  -Pete

On 1/23/12 8:09 PM, Kelly O'Hair wrote:
> You need to build everything once first, e.g.
>   cd /cygdrive/c/OpenJDK/jdk8/jdk/make/
>   make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
> then you can go into make/java/awt  and repeatedly
>   cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
>   make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>
> -kto
>
> On Jan 23, 2012, at 7:39 AM, Pete Brunet wrote:
>
>> In the past I was able to build part of jdk 8 but that is not currently
>> working although I am able to do a full 32 bit build.  I've recently
>> moved from XP to W7 so my environment might not be set up quite right
>> yet.  Here's what I do...
>>
>> // These are done in a bat file before I do any makes
>> set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
>> set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
>> set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
>> set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
>> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
>> set CLASSPATH=
>> set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
>> set CYGWIN=nodosfilewarning
>> cd c:\Users\Pete\cygwin\bin
>> bash --login -i
>>
>> // These are done at the command line
>> eval `bin/vsvars.sh -v10 -32`
>> cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
>> make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>>
>> The error I am getting is
>>
>> make: *** No rule to make target
>> `../../../build/windows-i586/btjars/compileproperties.jar', needed by
>> `compile_all_props'.  Stop.
>>
>> Since the above has windows-i586 instead of windows-i586-debug it looks
>> like I need to add another variable when invoking make.
>>
>> Pete


From peter.brunet at oracle.com  Tue Jan 24 03:49:00 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 23 Jan 2012 21:49:00 -0600
Subject: building part of jdk 8
In-Reply-To: <4F1E21BD.8060208@oracle.com>
References: <4F1D7F39.8010502@oracle.com>
	<7DD0686B-D779-4CF8-B843-55B2E736CA71@oracle.com>
	<4F1E21BD.8060208@oracle.com>
Message-ID: <4F1E2A2C.3000305@oracle.com>

Correction...

My original approach was to do

cd /cygdrive/c/OpenJDK/jdk8
not
cd /cygdrive/c/OpenJDK/jdk8/jdk/make

and then

make ARCH_DATA_MODEL=32 ALLOW_DOWNLOADS=true fastdebug_build 2>&1 | tee
build.log

so I need to build the entire forest first, i.e. I'll try using
FASTDEBUG=true instead of the fastdebug_build target at the top level. 
Then I'll experiment and see if I need to rebuild at the .../jdk/make
level first and then at the .../jdk/make/java/awt level as I need rebuilds.

Pete

On 1/23/12 9:13 PM, Pete Brunet wrote:
> Hi Kelly, That's almost what I did.  The only difference is that for the
> full build (which appears to have been successful) I used a target of
> fastdebug_build instead of using FASTDEBUG=true, i.e.
>
> make ARCH_DATA_MODEL=32 ALLOW_DOWNLOADS=true fastdebug_build 2>&1 | tee
> build.log
>
> I'll start over with this new approach.  -Pete
>
> On 1/23/12 8:09 PM, Kelly O'Hair wrote:
>> You need to build everything once first, e.g.
>>   cd /cygdrive/c/OpenJDK/jdk8/jdk/make/
>>   make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>> then you can go into make/java/awt  and repeatedly
>>   cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
>>   make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>>
>> -kto
>>
>> On Jan 23, 2012, at 7:39 AM, Pete Brunet wrote:
>>
>>> In the past I was able to build part of jdk 8 but that is not currently
>>> working although I am able to do a full 32 bit build.  I've recently
>>> moved from XP to W7 so my environment might not be set up quite right
>>> yet.  Here's what I do...
>>>
>>> // These are done in a bat file before I do any makes
>>> set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
>>> set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
>>> set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
>>> set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
>>> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
>>> set CLASSPATH=
>>> set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
>>> set CYGWIN=nodosfilewarning
>>> cd c:\Users\Pete\cygwin\bin
>>> bash --login -i
>>>
>>> // These are done at the command line
>>> eval `bin/vsvars.sh -v10 -32`
>>> cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
>>> make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>>>
>>> The error I am getting is
>>>
>>> make: *** No rule to make target
>>> `../../../build/windows-i586/btjars/compileproperties.jar', needed by
>>> `compile_all_props'.  Stop.
>>>
>>> Since the above has windows-i586 instead of windows-i586-debug it looks
>>> like I need to add another variable when invoking make.
>>>
>>> Pete


From peter.brunet at oracle.com  Tue Jan 24 16:52:10 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 24 Jan 2012 10:52:10 -0600
Subject: Is anyone able to build on Win 7
Message-ID: <4F1EE1BA.7010805@oracle.com>

Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
the end and have seen these errors:

out of memory, 3 times - I have more than enough memory
fork: Resource temporarily unavailable, 3 times
error 126, once

I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
apparently something on my system is causing a problem but I haven't
been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
turned off.  It would be helpful to know if anyone has successfully
built on Win 7 and also if anyone has ideas on what I might look for
beyond what is listed in the cygwin FAQ.

Thanks, Pete




From erik.joelsson at oracle.com  Wed Jan 25 07:43:50 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 25 Jan 2012 08:43:50 +0100
Subject: Is anyone able to build on Win 7
In-Reply-To: <4F1EE1BA.7010805@oracle.com>
References: <4F1EE1BA.7010805@oracle.com>
Message-ID: <4F1FB2B6.20607@oracle.com>

Hello,

I'm regularly building on my win 7 x64 laptop as part of the build-infra 
project (when needing to compare build results of the new and old build 
system). I recognize your problems but am not experiencing them at the 
moment. At this point I'm usually building jdk8.

The fork problem is usually a sign of too long command lines. Moving 
your repo to a directory with a shorter path could help fixing that.

Out of memory errors could be dependent on which boot jdk you are using. 
When building jdk8 I'm currently using jdk7 release. If that doesn't 
help it might be faulty logic in the makefiles that just set the wrong 
mx flags for your particular system.

Hope that helps some!

/Erik

On 2012-01-24 17:52, Pete Brunet wrote:
> Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
> the end and have seen these errors:
>
> out of memory, 3 times - I have more than enough memory
> fork: Resource temporarily unavailable, 3 times
> error 126, once
>
> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
> apparently something on my system is causing a problem but I haven't
> been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
> turned off.  It would be helpful to know if anyone has successfully
> built on Win 7 and also if anyone has ideas on what I might look for
> beyond what is listed in the cygwin FAQ.
>
> Thanks, Pete
>
>


From volker.simonis at gmail.com  Wed Jan 25 15:06:29 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 25 Jan 2012 16:06:29 +0100
Subject: Is anyone able to build on Win 7
In-Reply-To: <4F1EE1BA.7010805@oracle.com>
References: <4F1EE1BA.7010805@oracle.com>
Message-ID: <CA+3eh119MdSdjmaOi8ndj0xQDR6MSTnGkTQFbV9dVEk5RZ1WDg@mail.gmail.com>

Hi Peter,

glad to see that other have the same problems:)

But seriously, on Windows 7 I'm currently experiencing the same
massive build problems and I'm not sure what the root cause of these
problems is.

I found the following bug which exactly describes the problems I'm facing:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517

Among others, these are:

- rm: cannot remove directory `META-INF': Directory not empty
- error:  cannot create example2.html: Permission denied
- [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
error: error while writing SharedNameTable:
c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
(Access is denied)

but I also saw the 'out of memory' and 'for' problems mentioned by you.

The description of bug 6903517 references the "Big List of Dodgy Apps"
(http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
in the Cygwin FAQ which lists applications like Virus Scanners which
can interfere with Cygwin in an unpredictable way. An indeed the
Windows 7 box on which I observe the problems has some of them
installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).

On the other hand, on the same Windows 7 box I have a virtual machine
running inside VirtualBox  with WindowsXP which has the same McAffe
software installed and it is running without any problems. The OpenJDK
build always succeeds in the virtual machine!

So I'm not quite sure of this is:
- a problem of some additional software which is running on my Windows
7 box and interferes with Cygwin
- a general Windows7 problem
- a problem of the specific Cygwin version I'm using
- a problem of Cygwin running on 64-bit Windows 7

I'll try to further narrow down the problem, but of course any hints
are highly welcome (unfortunately I can't easily get rid of the McAffe
stuff without losing my job, so please don't advise this:)

Regards,
Volker

PS: below you can find the exact versions of the software/hardware I'm using:

64-bit Windows 7, SP 1
Dual Core Intel i7, 8GB RAM

Cygwin (output of uname -a):
CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
bash 4.1.10(4)  // installed by Cygwin setup.exe
make 3.82  // compiled by myself

In the Virtual box VM I have the following system:

64-bit Windows XP Professional Version 2003 SP 2

Cygwin (output of uname -a):
CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
bash 4.1.10(4)  // installed by Cygwin setup.exe
make 3.82  // compiled by myself


On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote:
> Is anyone able to build on Win 7? ?I'm on my 8th build hoping to get to
> the end and have seen these errors:
>
> out of memory, 3 times - I have more than enough memory
> fork: Resource temporarily unavailable, 3 times
> error 126, once
>
> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
> apparently something on my system is causing a problem but I haven't
> been successful in finding it yet. ?I have my Norton 360 "Auto-Protect"
> turned off. ?It would be helpful to know if anyone has successfully
> built on Win 7 and also if anyone has ideas on what I might look for
> beyond what is listed in the cygwin FAQ.
>
> Thanks, Pete
>
>


From peter.brunet at oracle.com  Wed Jan 25 15:55:38 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 25 Jan 2012 09:55:38 -0600
Subject: Is anyone able to build on Win 7
In-Reply-To: <CA+3eh119MdSdjmaOi8ndj0xQDR6MSTnGkTQFbV9dVEk5RZ1WDg@mail.gmail.com>
References: <4F1EE1BA.7010805@oracle.com>
	<CA+3eh119MdSdjmaOi8ndj0xQDR6MSTnGkTQFbV9dVEk5RZ1WDg@mail.gmail.com>
Message-ID: <4F2025FA.2050609@oracle.com>

Thanks Volker, I was thinking I'm going to have to try using XP in a
VM.  My W7 config is very close to yours (make 3.81 instead of 3.82).

W7 Pro, 64 bit, SP1
Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
GNU Make 3.81

Pete

On 1/25/12 9:06 AM, Volker Simonis wrote:
> Hi Peter,
>
> glad to see that other have the same problems:)
>
> But seriously, on Windows 7 I'm currently experiencing the same
> massive build problems and I'm not sure what the root cause of these
> problems is.
>
> I found the following bug which exactly describes the problems I'm facing:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
>
> Among others, these are:
>
> - rm: cannot remove directory `META-INF': Directory not empty
> - error:  cannot create example2.html: Permission denied
> - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
> error: error while writing SharedNameTable:
> c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
> (Access is denied)
>
> but I also saw the 'out of memory' and 'for' problems mentioned by you.
>
> The description of bug 6903517 references the "Big List of Dodgy Apps"
> (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
> in the Cygwin FAQ which lists applications like Virus Scanners which
> can interfere with Cygwin in an unpredictable way. An indeed the
> Windows 7 box on which I observe the problems has some of them
> installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
> VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).
>
> On the other hand, on the same Windows 7 box I have a virtual machine
> running inside VirtualBox  with WindowsXP which has the same McAffe
> software installed and it is running without any problems. The OpenJDK
> build always succeeds in the virtual machine!
>
> So I'm not quite sure of this is:
> - a problem of some additional software which is running on my Windows
> 7 box and interferes with Cygwin
> - a general Windows7 problem
> - a problem of the specific Cygwin version I'm using
> - a problem of Cygwin running on 64-bit Windows 7
>
> I'll try to further narrow down the problem, but of course any hints
> are highly welcome (unfortunately I can't easily get rid of the McAffe
> stuff without losing my job, so please don't advise this:)
>
> Regards,
> Volker
>
> PS: below you can find the exact versions of the software/hardware I'm using:
>
> 64-bit Windows 7, SP 1
> Dual Core Intel i7, 8GB RAM
>
> Cygwin (output of uname -a):
> CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
> bash 4.1.10(4)  // installed by Cygwin setup.exe
> make 3.82  // compiled by myself
>
> In the Virtual box VM I have the following system:
>
> 64-bit Windows XP Professional Version 2003 SP 2
>
> Cygwin (output of uname -a):
> CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
> bash 4.1.10(4)  // installed by Cygwin setup.exe
> make 3.82  // compiled by myself
>
>
> On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote:
>> Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
>> the end and have seen these errors:
>>
>> out of memory, 3 times - I have more than enough memory
>> fork: Resource temporarily unavailable, 3 times
>> error 126, once
>>
>> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
>> apparently something on my system is causing a problem but I haven't
>> been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
>> turned off.  It would be helpful to know if anyone has successfully
>> built on Win 7 and also if anyone has ideas on what I might look for
>> beyond what is listed in the cygwin FAQ.
>>
>> Thanks, Pete
>>
>>


From peter.brunet at oracle.com  Wed Jan 25 17:09:55 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 25 Jan 2012 11:09:55 -0600
Subject: Is anyone able to build on Win 7
In-Reply-To: <4F2025FA.2050609@oracle.com>
References: <4F1EE1BA.7010805@oracle.com>
	<CA+3eh119MdSdjmaOi8ndj0xQDR6MSTnGkTQFbV9dVEk5RZ1WDg@mail.gmail.com>
	<4F2025FA.2050609@oracle.com>
Message-ID: <4F203763.8050807@oracle.com>

I started W7 in safe mode and the build failed with a fork failure.  I
think that eliminates things in the BLODA list.  If anyone out there is
building OK on W7 please send your configuration, e.g. as shown below. 
Maybe that will suggest a different version of cygwin or bash.  -Pete

On 1/25/12 9:55 AM, Pete Brunet wrote:
> Thanks Volker, I was thinking I'm going to have to try using XP in a
> VM.  My W7 config is very close to yours (make 3.81 instead of 3.82).
>
> W7 Pro, 64 bit, SP1
> Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
> CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
> GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
> GNU Make 3.81
>
> Pete
>
> On 1/25/12 9:06 AM, Volker Simonis wrote:
>> Hi Peter,
>>
>> glad to see that other have the same problems:)
>>
>> But seriously, on Windows 7 I'm currently experiencing the same
>> massive build problems and I'm not sure what the root cause of these
>> problems is.
>>
>> I found the following bug which exactly describes the problems I'm facing:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
>>
>> Among others, these are:
>>
>> - rm: cannot remove directory `META-INF': Directory not empty
>> - error:  cannot create example2.html: Permission denied
>> - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
>> error: error while writing SharedNameTable:
>> c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
>> (Access is denied)
>>
>> but I also saw the 'out of memory' and 'for' problems mentioned by you.
>>
>> The description of bug 6903517 references the "Big List of Dodgy Apps"
>> (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
>> in the Cygwin FAQ which lists applications like Virus Scanners which
>> can interfere with Cygwin in an unpredictable way. An indeed the
>> Windows 7 box on which I observe the problems has some of them
>> installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
>> VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).
>>
>> On the other hand, on the same Windows 7 box I have a virtual machine
>> running inside VirtualBox  with WindowsXP which has the same McAffe
>> software installed and it is running without any problems. The OpenJDK
>> build always succeeds in the virtual machine!
>>
>> So I'm not quite sure of this is:
>> - a problem of some additional software which is running on my Windows
>> 7 box and interferes with Cygwin
>> - a general Windows7 problem
>> - a problem of the specific Cygwin version I'm using
>> - a problem of Cygwin running on 64-bit Windows 7
>>
>> I'll try to further narrow down the problem, but of course any hints
>> are highly welcome (unfortunately I can't easily get rid of the McAffe
>> stuff without losing my job, so please don't advise this:)
>>
>> Regards,
>> Volker
>>
>> PS: below you can find the exact versions of the software/hardware I'm using:
>>
>> 64-bit Windows 7, SP 1
>> Dual Core Intel i7, 8GB RAM
>>
>> Cygwin (output of uname -a):
>> CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>> make 3.82  // compiled by myself
>>
>> In the Virtual box VM I have the following system:
>>
>> 64-bit Windows XP Professional Version 2003 SP 2
>>
>> Cygwin (output of uname -a):
>> CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>> make 3.82  // compiled by myself
>>
>>
>> On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote:
>>> Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
>>> the end and have seen these errors:
>>>
>>> out of memory, 3 times - I have more than enough memory
>>> fork: Resource temporarily unavailable, 3 times
>>> error 126, once
>>>
>>> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
>>> apparently something on my system is causing a problem but I haven't
>>> been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
>>> turned off.  It would be helpful to know if anyone has successfully
>>> built on Win 7 and also if anyone has ideas on what I might look for
>>> beyond what is listed in the cygwin FAQ.
>>>
>>> Thanks, Pete
>>>
>>>


From david.katleman at sun.com  Wed Jan 25 22:09:27 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:09:27 +0000
Subject: hg: jdk8/build: Added tag jdk8-b22 for changeset 7ad075c80995
Message-ID: <20120125220927.80836471A4@hg.openjdk.java.net>

Changeset: 60d6f64a86b1
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/rev/60d6f64a86b1

Added tag jdk8-b22 for changeset 7ad075c80995

! .hgtags



From david.katleman at sun.com  Wed Jan 25 22:09:33 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:09:33 +0000
Subject: hg: jdk8/build/corba: Added tag jdk8-b22 for changeset a11d0062c445
Message-ID: <20120125220934.6B0C5471A5@hg.openjdk.java.net>

Changeset: 5218eb256658
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/corba/rev/5218eb256658

Added tag jdk8-b22 for changeset a11d0062c445

! .hgtags



From david.katleman at sun.com  Wed Jan 25 22:10:21 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:10:21 +0000
Subject: hg: jdk8/build/hotspot: 15 new changesets
Message-ID: <20120125221050.E2A68471A6@hg.openjdk.java.net>

Changeset: 338d438ee229
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/338d438ee229

Added tag jdk8-b22 for changeset 24727fb37561

! .hgtags

Changeset: 4e80db53c323
Author:    amurillo
Date:      2012-01-14 00:52 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4e80db53c323

7129512: new hotspot build - hs23-b11
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 94ec88ca68e2
Author:    phh
Date:      2012-01-11 17:34 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/94ec88ca68e2

7115199: Add event tracing hooks and Java Flight Recorder infrastructure
Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR.
Reviewed-by: acorn, sspitsyn
Contributed-by: markus.gronlund at oracle.com

! make/Makefile
! make/bsd/makefiles/vm.make
! make/defs.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! make/windows/build.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/prims/jni.cpp
+ src/share/vm/prims/jniExport.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vm_operations.hpp
+ src/share/vm/trace/traceEventTypes.hpp
+ src/share/vm/trace/traceMacros.hpp
+ src/share/vm/trace/tracing.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 4f3ce9284781
Author:    phh
Date:      2012-01-11 17:58 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4f3ce9284781

Merge

! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp

Changeset: f1cd52d6ce02
Author:    kamg
Date:      2012-01-17 10:16 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f1cd52d6ce02

Merge


Changeset: d7e3846464d0
Author:    zgu
Date:      2012-01-17 13:08 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d7e3846464d0

7071311: Decoder enhancement
Summary: Made decoder thread-safe
Reviewed-by: coleenp, kamg

- src/os/bsd/vm/decoder_bsd.cpp
+ src/os/bsd/vm/decoder_machO.cpp
+ src/os/bsd/vm/decoder_machO.hpp
! src/os/linux/vm/decoder_linux.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/decoder_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/decoder_windows.cpp
+ src/os/windows/vm/decoder_windows.hpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder.hpp
+ src/share/vm/utilities/decoder_elf.cpp
+ src/share/vm/utilities/decoder_elf.hpp
! src/share/vm/utilities/elfFile.cpp
! src/share/vm/utilities/elfFile.hpp
! src/share/vm/utilities/elfStringTable.cpp
! src/share/vm/utilities/elfStringTable.hpp
! src/share/vm/utilities/elfSymbolTable.cpp
! src/share/vm/utilities/elfSymbolTable.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 6520f9861937
Author:    kamg
Date:      2012-01-17 21:25 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6520f9861937

Merge


Changeset: db18ca98d237
Author:    zgu
Date:      2012-01-18 11:45 -0500
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/db18ca98d237

7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X
Summary: Decoder API changes did not reflect in os_bsd
Reviewed-by: kamg, dcubed

! src/os/bsd/vm/os_bsd.cpp

Changeset: eaa9557116a2
Author:    bdelsart
Date:      2012-01-18 16:18 +0100
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/eaa9557116a2

7120448: Fix FP values for compiled frames in frame::describe
Summary: fix for debug method frame::describe
Reviewed-by: never, kvn

! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp

Changeset: 15d394228cfa
Author:    jrose
Date:      2012-01-19 13:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/15d394228cfa

7111138: delete the obsolete flag -XX:+UseRicochetFrames
Reviewed-by: dholmes, bdelsart, kvn, twisti

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/zero/vm/methodHandles_zero.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 898522ae3c32
Author:    iveresov
Date:      2012-01-19 10:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/898522ae3c32

7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier)
Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future
Reviewed-by: kvn, never, twisti

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 469e0a46f2fe
Author:    jrose
Date:      2012-01-19 17:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/469e0a46f2fe

Merge


Changeset: 50d9b7a0072c
Author:    jrose
Date:      2012-01-19 18:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/50d9b7a0072c

Merge


Changeset: dcc292399a39
Author:    amurillo
Date:      2012-01-20 16:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dcc292399a39

Merge

- src/os/bsd/vm/decoder_bsd.cpp

Changeset: e850d8e7ea54
Author:    amurillo
Date:      2012-01-20 16:56 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e850d8e7ea54

Added tag hs23-b11 for changeset dcc292399a39

! .hgtags



From david.katleman at sun.com  Wed Jan 25 22:12:07 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:12:07 +0000
Subject: hg: jdk8/build/jaxp: Added tag jdk8-b22 for changeset cf9d6ec44f89
Message-ID: <20120125221207.AFA69471A7@hg.openjdk.java.net>

Changeset: 95102fd33418
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxp/rev/95102fd33418

Added tag jdk8-b22 for changeset cf9d6ec44f89

! .hgtags



From david.katleman at sun.com  Wed Jan 25 22:12:13 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:12:13 +0000
Subject: hg: jdk8/build/jaxws: Added tag jdk8-b22 for changeset 8d3df89b0f2d
Message-ID: <20120125221213.D8116471A8@hg.openjdk.java.net>

Changeset: 25ce7a000487
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jaxws/rev/25ce7a000487

Added tag jdk8-b22 for changeset 8d3df89b0f2d

! .hgtags



From david.katleman at sun.com  Wed Jan 25 22:13:09 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:13:09 +0000
Subject: hg: jdk8/build/jdk: 46 new changesets
Message-ID: <20120125222026.2A131471A9@hg.openjdk.java.net>

Changeset: 76bfd08d8cc5
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/76bfd08d8cc5

Added tag jdk8-b22 for changeset dda27c73d8db

! .hgtags

Changeset: 44bd765c22f4
Author:    prr
Date:      2012-01-13 13:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/44bd765c22f4

7127827: JRE8: javaws fails to launch on oracle linux due to XRender
Reviewed-by: bae, jgodinez

! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java

Changeset: b566004bcb1a
Author:    dbuck
Date:      2012-01-16 11:52 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/b566004bcb1a

7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates
Reviewed-by: bae, prr

! make/sun/awt/Makefile

Changeset: 397667460892
Author:    lana
Date:      2012-01-18 11:27 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/397667460892

Merge

- test/tools/launcher/DefaultLocaleTest.sh

Changeset: e0f94b9c53a8
Author:    alexsch
Date:      2012-01-10 15:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/e0f94b9c53a8

7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS
Reviewed-by: kizune

+ test/javax/swing/JSplitPane/4885629/bug4885629.java

Changeset: 79d14e328670
Author:    alexsch
Date:      2012-01-10 17:11 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/79d14e328670

6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
+ test/javax/swing/JTree/6505523/bug6505523.java

Changeset: ce32a4e1be1d
Author:    alexsch
Date:      2012-01-13 12:39 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/ce32a4e1be1d

7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F
Reviewed-by: rupashka

+ test/javax/swing/JTextArea/4697612/bug4697612.java
+ test/javax/swing/JTextArea/4697612/bug4697612.txt

Changeset: 59b8875949e1
Author:    malenkov
Date:      2012-01-16 18:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/59b8875949e1

7122740: PropertyDescriptor Performance Slow
Reviewed-by: rupashka

! src/share/classes/com/sun/beans/TypeResolver.java

Changeset: 3e9d35e6ee4f
Author:    denis
Date:      2012-01-17 19:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/3e9d35e6ee4f

7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException
Reviewed-by: art

! src/share/classes/java/awt/AWTKeyStroke.java

Changeset: 89bc9d08fe82
Author:    anthony
Date:      2012-01-18 19:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/89bc9d08fe82

7130662: GTK file dialog crashes with a NPE
Summary: Guard adding a back slash to the directory name with an if (!= null) check
Reviewed-by: anthony, art
Contributed-by: Matt <melkor at orangepalantir.org>

! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java

Changeset: fe1278123fbb
Author:    lana
Date:      2012-01-18 11:41 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/fe1278123fbb

Merge

- test/tools/launcher/DefaultLocaleTest.sh

Changeset: 4d8b49a45cff
Author:    lana
Date:      2012-01-18 20:23 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/4d8b49a45cff

Merge


Changeset: 400cc379adb5
Author:    alanb
Date:      2012-01-06 15:00 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/400cc379adb5

7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed
Reviewed-by: forax, chegar

! src/share/classes/java/nio/file/FileTreeWalker.java

Changeset: cdc128128044
Author:    valeriep
Date:      2012-01-05 18:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/cdc128128044

6414899: P11Digest  should support cloning
Summary: Enhanced the PKCS11 Digest implementation to support cloning
Reviewed-by: vinnie

! make/sun/security/pkcs11/mapfile-vers
! src/share/classes/sun/security/pkcs11/P11Digest.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/share/lib/security/sunpkcs11-solaris.cfg
! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
+ test/sun/security/pkcs11/MessageDigest/TestCloning.java

Changeset: e6ef778c1df4
Author:    valeriep
Date:      2012-01-06 11:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/e6ef778c1df4

Merge


Changeset: 6720ae7b1448
Author:    valeriep
Date:      2012-01-06 16:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/6720ae7b1448

7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException
Summary: Changed to always use full transformation as provider properties.
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs11/SunPKCS11.java
! test/javax/crypto/Cipher/GetMaxAllowed.java

Changeset: 2050ff9dfc92
Author:    darcy
Date:      2012-01-06 18:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/2050ff9dfc92

7123649: Remove public modifier from Math.powerOfTwoF.
Reviewed-by: smarks, alanb

! src/share/classes/java/lang/Math.java

Changeset: 74c92c3e66ad
Author:    gadams
Date:      2012-01-09 19:33 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/74c92c3e66ad

7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space
Reviewed-by: alanb

! test/java/io/FileInputStream/LargeFileAvailable.java

Changeset: 858038d89fd5
Author:    darcy
Date:      2012-01-09 15:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/858038d89fd5

7128441: StrictMath performance improvement note shared with Math
Reviewed-by: darcy
Contributed-by: Martin Desruisseaux <martin.desruisseaux at geomatys.fr>

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java

Changeset: dd69d3695cee
Author:    darcy
Date:      2012-01-09 20:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/dd69d3695cee

7128512: Javadoc typo in java.lang.invoke.MethodHandle
Reviewed-by: mduigou

! src/share/classes/java/lang/invoke/MethodHandle.java

Changeset: d72de8b3fe36
Author:    chegar
Date:      2012-01-10 10:57 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/d72de8b3fe36

7123415: Some cases of network interface indexes being read incorrectly
Reviewed-by: chegar
Contributed-by: brandon.passanisi at oracle.com

! src/solaris/native/java/net/net_util_md.c

Changeset: bba276a6aa0d
Author:    chegar
Date:      2012-01-10 12:48 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/bba276a6aa0d

7128584: Typo in sun.misc.VM's private directMemory field comment
Reviewed-by: forax, chegar
Contributed-by: Krystal Mok <sajia at taobao.com>

! src/share/classes/sun/misc/VM.java

Changeset: 49e64a8fc18f
Author:    darcy
Date:      2012-01-10 17:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/49e64a8fc18f

7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances
Reviewed-by: mduigou

! src/share/classes/java/lang/Object.java

Changeset: 62dbcbe4c446
Author:    darcy
Date:      2012-01-10 17:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/62dbcbe4c446

7128931: Bad HTML escaping in java.lang.Throwable javadoc
Reviewed-by: mduigou

! src/share/classes/java/lang/Throwable.java

Changeset: 31a1fc60a895
Author:    chegar
Date:      2012-01-11 10:52 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/31a1fc60a895

7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/java/net/HttpURLConnection/UnmodifiableMaps.java

Changeset: 82144054d2d8
Author:    alanb
Date:      2012-01-11 13:07 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/82144054d2d8

7068856: (fs) Typo in Files.isSameFile() javadoc
7099208: (fs) Files.newBufferedReader has typo in javadoc
Reviewed-by: forax

! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/Path.java

Changeset: 96fe796fd242
Author:    ksrini
Date:      2012-01-11 08:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/96fe796fd242

7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2
Reviewed-by: sherman, mchung, darcy

! src/share/bin/java.c
+ test/tools/launcher/I18NJarTest.java
! test/tools/launcher/TestHelper.java

Changeset: 11e52d5ba64e
Author:    xuelei
Date:      2012-01-12 03:39 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/11e52d5ba64e

7106773: 512 bits RSA key cannot work with SHA384 and SHA512
Reviewed-by: weijun

! src/share/classes/sun/security/pkcs11/P11Cipher.java
! src/share/classes/sun/security/pkcs11/P11Key.java
! src/share/classes/sun/security/pkcs11/P11RSACipher.java
! src/share/classes/sun/security/pkcs11/P11Signature.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
+ src/share/classes/sun/security/util/KeyLength.java
+ src/share/classes/sun/security/util/Length.java
! src/windows/classes/sun/security/mscapi/Key.java
! src/windows/classes/sun/security/mscapi/RSACipher.java
! src/windows/classes/sun/security/mscapi/RSASignature.java
+ test/sun/security/mscapi/ShortRSAKey1024.sh
+ test/sun/security/mscapi/ShortRSAKey512.sh
+ test/sun/security/mscapi/ShortRSAKey768.sh
+ test/sun/security/mscapi/ShortRSAKeyWithinTLS.java
! test/sun/security/pkcs11/KeyStore/ClientAuth.java
! test/sun/security/pkcs11/KeyStore/ClientAuth.sh
! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java

Changeset: 38bf1e9b6979
Author:    weijun
Date:      2012-01-13 09:50 +0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/38bf1e9b6979

7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests
Reviewed-by: mullan

+ test/javax/security/auth/x500/X500Principal/NameFormat.java

Changeset: ef3b6736c074
Author:    valeriep
Date:      2012-01-12 16:04 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/ef3b6736c074

7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs
Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API.
Reviewed-by: weijun

! make/com/oracle/Makefile
+ make/com/oracle/net/Makefile
+ make/com/oracle/nio/Makefile
+ make/com/oracle/security/ucrypto/FILES_c.gmk
+ make/com/oracle/security/ucrypto/Makefile
+ make/com/oracle/security/ucrypto/mapfile-vers
+ make/com/oracle/util/Makefile
! src/share/lib/security/java.security-solaris
! test/Makefile
+ test/com/oracle/security/ucrypto/TestAES.java
+ test/com/oracle/security/ucrypto/TestDigest.java
+ test/com/oracle/security/ucrypto/TestRSA.java
+ test/com/oracle/security/ucrypto/UcryptoTest.java
! test/java/security/Provider/DefaultPKCS11.java

Changeset: a7ad2fcd7291
Author:    valeriep
Date:      2012-01-12 18:49 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/a7ad2fcd7291

Merge


Changeset: 7e593aa6ad41
Author:    littlee
Date:      2012-01-13 13:20 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/7e593aa6ad41

7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW
Reviewed-by: alanb

! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/native/sun/nio/fs/genUnixConstants.c

Changeset: e8e08d46cc37
Author:    weijun
Date:      2012-01-16 10:10 +0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/e8e08d46cc37

7118809: rcache deadlock
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
! test/sun/security/krb5/auto/Context.java
+ test/sun/security/krb5/auto/ReplayCache.java

Changeset: d1b0bda3a3c7
Author:    alanb
Date:      2012-01-16 16:30 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/d1b0bda3a3c7

7130398: ProblemList.txt updates (1/2012)
Reviewed-by: chegar

! test/ProblemList.txt

Changeset: e8a143213c65
Author:    chegar
Date:      2012-01-16 18:05 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/e8a143213c65

7129083: CookieManager does not store cookies if url is read before setting cookie manager
Reviewed-by: michaelm

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
+ test/sun/net/www/http/HttpClient/CookieHttpClientTest.java
+ test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java

Changeset: 40d699d7f6a1
Author:    chegar
Date:      2012-01-17 14:10 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/40d699d7f6a1

6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol)
Reviewed-by: alanb

! test/ProblemList.txt
- test/java/io/File/BlockIsDirectory.java

Changeset: 2f096eb72520
Author:    mchung
Date:      2012-01-17 15:55 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/2f096eb72520

7117570: Warnings in sun.mangement.* and its subpackages
Reviewed-by: mchung, dsamersoff
Contributed-by: kurchi.subhra.hazra at oracle.com

! src/share/classes/sun/management/Agent.java
! src/share/classes/sun/management/ConnectorAddressLink.java
! src/share/classes/sun/management/Flag.java
! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java
! src/share/classes/sun/management/GarbageCollectorImpl.java
! src/share/classes/sun/management/GcInfoBuilder.java
! src/share/classes/sun/management/GcInfoCompositeData.java
! src/share/classes/sun/management/HotSpotDiagnostic.java
! src/share/classes/sun/management/HotspotCompilation.java
! src/share/classes/sun/management/HotspotThread.java
! src/share/classes/sun/management/LazyCompositeData.java
! src/share/classes/sun/management/ManagementFactoryHelper.java
! src/share/classes/sun/management/MappedMXBeanType.java
! src/share/classes/sun/management/MonitorInfoCompositeData.java
! src/share/classes/sun/management/NotificationEmitterSupport.java
! src/share/classes/sun/management/RuntimeImpl.java
! src/share/classes/sun/management/ThreadInfoCompositeData.java
! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java
! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java
! src/share/classes/sun/management/snmp/AdaptorBootstrap.java
! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java
! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java
! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java
! src/share/classes/sun/management/snmp/util/MibLogger.java
! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java
! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java
! src/share/classes/sun/management/snmp/util/SnmpTableCache.java

Changeset: b14e13237498
Author:    lana
Date:      2012-01-18 11:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/b14e13237498

Merge


Changeset: e6614f361127
Author:    lana
Date:      2012-01-18 20:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/e6614f361127

Merge

- test/java/io/File/BlockIsDirectory.java

Changeset: 227fcf5d0bec
Author:    lana
Date:      2012-01-24 13:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/227fcf5d0bec

Merge

- test/java/io/File/BlockIsDirectory.java

Changeset: db189e2f3cdb
Author:    jrose
Date:      2012-01-18 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/db189e2f3cdb

7117167: Misc warnings in java.lang.invoke and sun.invoke.*
Reviewed-by: smarks

! src/share/classes/java/lang/invoke/AdapterMethodHandle.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/invoke/util/Wrapper.java
! test/java/lang/invoke/CallSiteTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/RicochetTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java
! test/sun/invoke/util/ValueConversionsTest.java

Changeset: 01014596ada1
Author:    jrose
Date:      2012-01-18 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/01014596ada1

7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init
Summary: Use correct access token for unreflecting MHs where setAccessible(true)
Reviewed-by: never, twisti

! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 92d2cba30f08
Author:    jrose
Date:      2012-01-18 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/92d2cba30f08

7030453: JSR 292 ClassValue.get method is too slow
Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread.
Reviewed-by: twisti, mduigou

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassValue.java
! test/java/lang/invoke/ClassValueTest.java

Changeset: 81a2629aa2a2
Author:    amurillo
Date:      2012-01-20 14:31 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/81a2629aa2a2

Merge


Changeset: 954a1c535730
Author:    amurillo
Date:      2012-01-25 12:36 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/954a1c535730

Merge

- test/java/io/File/BlockIsDirectory.java

Changeset: 54202e0148ec
Author:    katleman
Date:      2012-01-25 13:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/jdk/rev/54202e0148ec

Merge




From david.katleman at sun.com  Wed Jan 25 22:22:43 2012
From: david.katleman at sun.com (david.katleman at sun.com)
Date: Wed, 25 Jan 2012 22:22:43 +0000
Subject: hg: jdk8/build/langtools: 8 new changesets
Message-ID: <20120125222259.9AE3B471AA@hg.openjdk.java.net>

Changeset: f6191bad139a
Author:    katleman
Date:      2012-01-20 13:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/f6191bad139a

Added tag jdk8-b22 for changeset 390a7828ae18

! .hgtags

Changeset: 70d92518063e
Author:    mcimadamore
Date:      2012-01-11 18:23 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/70d92518063e

7126754: Generics compilation failure casting List<? extends Set...> to List<Set...>
Summary: Problems with Types.rewriteQuantifiers not preserving variance
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/7126754/T7126754.java
+ test/tools/javac/cast/7126754/T7126754.out

Changeset: 133744729455
Author:    mcimadamore
Date:      2012-01-12 15:28 +0000
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/133744729455

7123100: javac fails with java.lang.StackOverflowError
Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/cast/7123100/T7123100a.java
+ test/tools/javac/cast/7123100/T7123100a.out
+ test/tools/javac/cast/7123100/T7123100b.java
+ test/tools/javac/cast/7123100/T7123100b.out
+ test/tools/javac/cast/7123100/T7123100c.java
+ test/tools/javac/cast/7123100/T7123100c.out
+ test/tools/javac/cast/7123100/T7123100d.java
+ test/tools/javac/cast/7123100/T7123100d.out

Changeset: 1e2f4f4fb9f7
Author:    jjh
Date:      2012-01-17 17:14 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/1e2f4f4fb9f7

7127924: langtools regression tests sometimes fail en-masse on windows
Reviewed-by: jjg

! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/RunExamples.java

Changeset: f00afa80f1f0
Author:    lana
Date:      2012-01-18 11:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/f00afa80f1f0

Merge


Changeset: cf2496340fef
Author:    darcy
Date:      2012-01-18 16:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/cf2496340fef

7130768: Clarify behavior of Element.getEnclosingElements in subtypes
Reviewed-by: mcimadamore, jjg

! src/share/classes/javax/lang/model/element/Element.java
! src/share/classes/javax/lang/model/element/PackageElement.java
! src/share/classes/javax/lang/model/element/TypeElement.java

Changeset: 99261fc7d95d
Author:    jjh
Date:      2012-01-18 18:26 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/99261fc7d95d

7131308: Three regression tests fail due to bad fix for 7127924
Reviewed-by: jjg

! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/RunExamples.java

Changeset: 601ffcc6551d
Author:    lana
Date:      2012-01-24 13:44 -0800
URL:       http://hg.openjdk.java.net/jdk8/build/langtools/rev/601ffcc6551d

Merge




From kelly.ohair at oracle.com  Thu Jan 26 00:17:52 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 25 Jan 2012 16:17:52 -0800
Subject: Is anyone able to build on Win 7
In-Reply-To: <4F203763.8050807@oracle.com>
References: <4F1EE1BA.7010805@oracle.com>
	<CA+3eh119MdSdjmaOi8ndj0xQDR6MSTnGkTQFbV9dVEk5RZ1WDg@mail.gmail.com>
	<4F2025FA.2050609@oracle.com> <4F203763.8050807@oracle.com>
Message-ID: <7012C95D-45EC-4D1D-BFF1-0AF05CE46232@oracle.com>

Sorry guys, I don't have the time or priority to track this down.
Official builds are still happening on Windows XP and Windows 2003 X64 and these
problems are not being seen on those systems.... yet... 
although we recently have been visited by the McAfee plague so maybe it's just a matter of time. ;^(

Someone with some strong Windows experience needs to run this to ground.
We do need this to work, eventually.

-kto

On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote:

> I started W7 in safe mode and the build failed with a fork failure.  I
> think that eliminates things in the BLODA list.  If anyone out there is
> building OK on W7 please send your configuration, e.g. as shown below. 
> Maybe that will suggest a different version of cygwin or bash.  -Pete
> 
> On 1/25/12 9:55 AM, Pete Brunet wrote:
>> Thanks Volker, I was thinking I'm going to have to try using XP in a
>> VM.  My W7 config is very close to yours (make 3.81 instead of 3.82).
>> 
>> W7 Pro, 64 bit, SP1
>> Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
>> CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>> GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
>> GNU Make 3.81
>> 
>> Pete
>> 
>> On 1/25/12 9:06 AM, Volker Simonis wrote:
>>> Hi Peter,
>>> 
>>> glad to see that other have the same problems:)
>>> 
>>> But seriously, on Windows 7 I'm currently experiencing the same
>>> massive build problems and I'm not sure what the root cause of these
>>> problems is.
>>> 
>>> I found the following bug which exactly describes the problems I'm facing:
>>> 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
>>> 
>>> Among others, these are:
>>> 
>>> - rm: cannot remove directory `META-INF': Directory not empty
>>> - error:  cannot create example2.html: Permission denied
>>> - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
>>> error: error while writing SharedNameTable:
>>> c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
>>> (Access is denied)
>>> 
>>> but I also saw the 'out of memory' and 'for' problems mentioned by you.
>>> 
>>> The description of bug 6903517 references the "Big List of Dodgy Apps"
>>> (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
>>> in the Cygwin FAQ which lists applications like Virus Scanners which
>>> can interfere with Cygwin in an unpredictable way. An indeed the
>>> Windows 7 box on which I observe the problems has some of them
>>> installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
>>> VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).
>>> 
>>> On the other hand, on the same Windows 7 box I have a virtual machine
>>> running inside VirtualBox  with WindowsXP which has the same McAffe
>>> software installed and it is running without any problems. The OpenJDK
>>> build always succeeds in the virtual machine!
>>> 
>>> So I'm not quite sure of this is:
>>> - a problem of some additional software which is running on my Windows
>>> 7 box and interferes with Cygwin
>>> - a general Windows7 problem
>>> - a problem of the specific Cygwin version I'm using
>>> - a problem of Cygwin running on 64-bit Windows 7
>>> 
>>> I'll try to further narrow down the problem, but of course any hints
>>> are highly welcome (unfortunately I can't easily get rid of the McAffe
>>> stuff without losing my job, so please don't advise this:)
>>> 
>>> Regards,
>>> Volker
>>> 
>>> PS: below you can find the exact versions of the software/hardware I'm using:
>>> 
>>> 64-bit Windows 7, SP 1
>>> Dual Core Intel i7, 8GB RAM
>>> 
>>> Cygwin (output of uname -a):
>>> CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>>> make 3.82  // compiled by myself
>>> 
>>> In the Virtual box VM I have the following system:
>>> 
>>> 64-bit Windows XP Professional Version 2003 SP 2
>>> 
>>> Cygwin (output of uname -a):
>>> CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>>> make 3.82  // compiled by myself
>>> 
>>> 
>>> On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote:
>>>> Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
>>>> the end and have seen these errors:
>>>> 
>>>> out of memory, 3 times - I have more than enough memory
>>>> fork: Resource temporarily unavailable, 3 times
>>>> error 126, once
>>>> 
>>>> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
>>>> apparently something on my system is causing a problem but I haven't
>>>> been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
>>>> turned off.  It would be helpful to know if anyone has successfully
>>>> built on Win 7 and also if anyone has ideas on what I might look for
>>>> beyond what is listed in the cygwin FAQ.
>>>> 
>>>> Thanks, Pete
>>>> 
>>>> 



From peter.brunet at oracle.com  Thu Jan 26 01:10:46 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 25 Jan 2012 19:10:46 -0600
Subject: Is anyone able to build on Win 7
In-Reply-To: <7012C95D-45EC-4D1D-BFF1-0AF05CE46232@oracle.com>
References: <4F1EE1BA.7010805@oracle.com>
	<CA+3eh119MdSdjmaOi8ndj0xQDR6MSTnGkTQFbV9dVEk5RZ1WDg@mail.gmail.com>
	<4F2025FA.2050609@oracle.com> <4F203763.8050807@oracle.com>
	<7012C95D-45EC-4D1D-BFF1-0AF05CE46232@oracle.com>
Message-ID: <4F20A816.4030108@oracle.com>

I just had success with the following changes:
- downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash
3.2.49)
- changed ...\jdk\make\docs\Makefile line 74

ifeq ($(ARCH_DATA_MODEL),64)
  MAX_VM_MEMORY = 1024
else
  MAX_VM_MEMORY = 1024 <--- This was 512
endif

I've only done one build and in prior builds had other issues besides
the memory problem, i.e. fork and error 126, but there's always hope.

If others could report their W7 configurations and whether or not there
were problems, that would be helpful.

Pete

On 1/25/12 6:17 PM, Kelly O'Hair wrote:
> Sorry guys, I don't have the time or priority to track this down.
> Official builds are still happening on Windows XP and Windows 2003 X64 and these
> problems are not being seen on those systems.... yet... 
> although we recently have been visited by the McAfee plague so maybe it's just a matter of time. ;^(
>
> Someone with some strong Windows experience needs to run this to ground.
> We do need this to work, eventually.
>
> -kto
>
> On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote:
>
>> I started W7 in safe mode and the build failed with a fork failure.  I
>> think that eliminates things in the BLODA list.  If anyone out there is
>> building OK on W7 please send your configuration, e.g. as shown below. 
>> Maybe that will suggest a different version of cygwin or bash.  -Pete
>>
>> On 1/25/12 9:55 AM, Pete Brunet wrote:
>>> Thanks Volker, I was thinking I'm going to have to try using XP in a
>>> VM.  My W7 config is very close to yours (make 3.81 instead of 3.82).
>>>
>>> W7 Pro, 64 bit, SP1
>>> Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM
>>> CYGWIN_NT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>> GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
>>> GNU Make 3.81
>>>
>>> Pete
>>>
>>> On 1/25/12 9:06 AM, Volker Simonis wrote:
>>>> Hi Peter,
>>>>
>>>> glad to see that other have the same problems:)
>>>>
>>>> But seriously, on Windows 7 I'm currently experiencing the same
>>>> massive build problems and I'm not sure what the root cause of these
>>>> problems is.
>>>>
>>>> I found the following bug which exactly describes the problems I'm facing:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6903517
>>>>
>>>> Among others, these are:
>>>>
>>>> - rm: cannot remove directory `META-INF': Directory not empty
>>>> - error:  cannot create example2.html: Permission denied
>>>> - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40:
>>>> error: error while writing SharedNameTable:
>>>> c:\Software\OpenJDK\output_amd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class
>>>> (Access is denied)
>>>>
>>>> but I also saw the 'out of memory' and 'for' problems mentioned by you.
>>>>
>>>> The description of bug 6903517 references the "Big List of Dodgy Apps"
>>>> (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list
>>>> in the Cygwin FAQ which lists applications like Virus Scanners which
>>>> can interfere with Cygwin in an unpredictable way. An indeed the
>>>> Windows 7 box on which I observe the problems has some of them
>>>> installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention,
>>>> VirusScan Enterprise, AntySpywaare Enterprise} to name just a few).
>>>>
>>>> On the other hand, on the same Windows 7 box I have a virtual machine
>>>> running inside VirtualBox  with WindowsXP which has the same McAffe
>>>> software installed and it is running without any problems. The OpenJDK
>>>> build always succeeds in the virtual machine!
>>>>
>>>> So I'm not quite sure of this is:
>>>> - a problem of some additional software which is running on my Windows
>>>> 7 box and interferes with Cygwin
>>>> - a general Windows7 problem
>>>> - a problem of the specific Cygwin version I'm using
>>>> - a problem of Cygwin running on 64-bit Windows 7
>>>>
>>>> I'll try to further narrow down the problem, but of course any hints
>>>> are highly welcome (unfortunately I can't easily get rid of the McAffe
>>>> stuff without losing my job, so please don't advise this:)
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>> PS: below you can find the exact versions of the software/hardware I'm using:
>>>>
>>>> 64-bit Windows 7, SP 1
>>>> Dual Core Intel i7, 8GB RAM
>>>>
>>>> Cygwin (output of uname -a):
>>>> CYGWIN_NT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>>>> make 3.82  // compiled by myself
>>>>
>>>> In the Virtual box VM I have the following system:
>>>>
>>>> 64-bit Windows XP Professional Version 2003 SP 2
>>>>
>>>> Cygwin (output of uname -a):
>>>> CYGWIN_NT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>>>> bash 4.1.10(4)  // installed by Cygwin setup.exe
>>>> make 3.82  // compiled by myself
>>>>
>>>>
>>>> On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote:
>>>>> Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to
>>>>> the end and have seen these errors:
>>>>>
>>>>> out of memory, 3 times - I have more than enough memory
>>>>> fork: Resource temporarily unavailable, 3 times
>>>>> error 126, once
>>>>>
>>>>> I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so
>>>>> apparently something on my system is causing a problem but I haven't
>>>>> been successful in finding it yet.  I have my Norton 360 "Auto-Protect"
>>>>> turned off.  It would be helpful to know if anyone has successfully
>>>>> built on Win 7 and also if anyone has ideas on what I might look for
>>>>> beyond what is listed in the cygwin FAQ.
>>>>>
>>>>> Thanks, Pete
>>>>>
>>>>>


From peter.brunet at oracle.com  Thu Jan 26 02:26:45 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 25 Jan 2012 20:26:45 -0600
Subject: building part of jdk 8
In-Reply-To: <7DD0686B-D779-4CF8-B843-55B2E736CA71@oracle.com>
References: <4F1D7F39.8010502@oracle.com>
	<7DD0686B-D779-4CF8-B843-55B2E736CA71@oracle.com>
Message-ID: <4F20B9E5.5080805@oracle.com>


On 1/23/12 8:09 PM, Kelly O'Hair wrote:
> You need to build everything once first, e.g.
>   cd /cygdrive/c/OpenJDK/jdk8/jdk/make/
>   make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
When I do this I get:

ERROR: HOTSPOT_CLIENT_PATH does not point to a valid HotSpot VM.
       Please check your access to
          
J:/re/jdk/1.8.0/promoted/latest/binaries/windows-i586/fastdebug/jre/bin/client/jvm.dll
       and/or check your value of ALT_HOTSPOT_CLIENT_PATH.

ERROR: HOTSPOT_SERVER_PATH does not point to a valid HotSpot VM.
       Please check your access to
          
J:/re/jdk/1.8.0/promoted/latest/binaries/windows-i586/fastdebug/jre/bin/server/jvm.dll
       and/or check your value of ALT_HOTSPOT_SERVER_PATH.

ERROR: HOTSPOT_LIB_PATH does not point to a valid HotSpot library.
       Please check your access to
          
J:/re/jdk/1.8.0/promoted/latest/binaries/windows-i586/fastdebug/lib/jvm.lib
       and/or check your value of ALT_HOTSPOT_LIB_PATH.

Exiting because of the above error(s).

make: *** [sane-lastrule] Error 1

Note that this is after a successful build of the entire forest, i.e.
running the same make command at the top level, i.e. .../jdk8

Pete
> then you can go into make/java/awt  and repeatedly
>   cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
>   make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>
> -kto
>
> On Jan 23, 2012, at 7:39 AM, Pete Brunet wrote:
>
>> In the past I was able to build part of jdk 8 but that is not currently
>> working although I am able to do a full 32 bit build.  I've recently
>> moved from XP to W7 so my environment might not be set up quite right
>> yet.  Here's what I do...
>>
>> // These are done in a bat file before I do any makes
>> set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02
>> set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include
>> set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010
>> set ANT_HOME=C:/Progra~2/apache-ant-1.7.1
>> set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin
>> set CLASSPATH=
>> set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;
>> set CYGWIN=nodosfilewarning
>> cd c:\Users\Pete\cygwin\bin
>> bash --login -i
>>
>> // These are done at the command line
>> eval `bin/vsvars.sh -v10 -32`
>> cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/
>> make ARCH_DATA_MODEL=32 FASTDEBUG=true 2>&1 | tee build.log
>>
>> The error I am getting is
>>
>> make: *** No rule to make target
>> `../../../build/windows-i586/btjars/compileproperties.jar', needed by
>> `compile_all_props'.  Stop.
>>
>> Since the above has windows-i586 instead of windows-i586-debug it looks
>> like I need to add another variable when invoking make.
>>
>> Pete


From rickard.backman at oracle.com  Thu Jan 26 09:44:10 2012
From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=)
Date: Thu, 26 Jan 2012 10:44:10 +0100
Subject: RFR: 7133124 Remove redundant packages from JAR command line
Message-ID: <4F21206A.1040907@oracle.com>

Hi,

We have a problem with some versions of jar reporting errors when trying 
to run jar cf <some.jar> com/test com/test/foo

This fix removes the redundant subdirectories from the command.

Webrev is here:
http://cr.openjdk.java.net/~rbackman/7133124/webrev/

Thanks
/Rickard


From Alan.Bateman at oracle.com  Thu Jan 26 09:51:43 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Jan 2012 09:51:43 +0000
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21206A.1040907@oracle.com>
References: <4F21206A.1040907@oracle.com>
Message-ID: <4F21222F.5070605@oracle.com>

On 26/01/2012 09:44, Rickard B?ckman wrote:
> Hi,
>
> We have a problem with some versions of jar reporting errors when 
> trying to run jar cf <some.jar> com/test com/test/foo
>
> This fix removes the redundant subdirectories from the command.
>
> Webrev is here:
> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>
> Thanks
> /Rickard
Looks okay to me.

-Alan.


From rickard.backman at oracle.com  Thu Jan 26 09:58:55 2012
From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=)
Date: Thu, 26 Jan 2012 10:58:55 +0100
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21222F.5070605@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F21222F.5070605@oracle.com>
Message-ID: <4F2123DF.7060206@oracle.com>

On 01/26/2012 10:51 AM, Alan Bateman wrote:
> On 26/01/2012 09:44, Rickard B?ckman wrote:
>> Hi,
>>
>> We have a problem with some versions of jar reporting errors when
>> trying to run jar cf <some.jar> com/test com/test/foo
>>
>> This fix removes the redundant subdirectories from the command.
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>>
>> Thanks
>> /Rickard
> Looks okay to me.
>
> -Alan.

Thank you for your quick review & response Alan!

/R


From david.holmes at oracle.com  Thu Jan 26 11:50:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Jan 2012 21:50:49 +1000
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21206A.1040907@oracle.com>
References: <4F21206A.1040907@oracle.com>
Message-ID: <4F213E19.90508@oracle.com>

On 26/01/2012 7:44 PM, Rickard B?ckman wrote:
> We have a problem with some versions of jar reporting errors when trying
> to run jar cf <some.jar> com/test com/test/foo
>
> This fix removes the redundant subdirectories from the command.
>
> Webrev is here:
> http://cr.openjdk.java.net/~rbackman/7133124/webrev/

Change looks fine, but then so did the original! Will this be handled 
correctly by all versions of the jar command?

David

> Thanks
> /Rickard


From rickard.backman at oracle.com  Thu Jan 26 12:02:40 2012
From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=)
Date: Thu, 26 Jan 2012 13:02:40 +0100
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F213E19.90508@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
Message-ID: <4F2140E0.5040802@oracle.com>

On 01/26/2012 12:50 PM, David Holmes wrote:
> On 26/01/2012 7:44 PM, Rickard B?ckman wrote:
>> We have a problem with some versions of jar reporting errors when trying
>> to run jar cf <some.jar> com/test com/test/foo
>>
>> This fix removes the redundant subdirectories from the command.
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>
> Change looks fine, but then so did the original! Will this be handled
> correctly by all versions of the jar command?
>
> David

David,

thanks for the review.

We, have checked the contents of the version that RE is using (1.6.0_1 
or something like that) and the one JPRT is using (1.6.0_18) and locally 
on my machine (1.7.0) I don't think I'll be able to verify _all_ 
versions of jar. It seems the "faulty" behavior of "jar" was fixed in 
1.6.0_18 which is the first version I could find that didn't cause the 
error on the previous code. I would rather hope that we could try to use 
one and the same version across all kind of builds of the same jdk 
version. It would help to catch this kind of errors earlier...

Thanks
/R

>
>> Thanks
>> /Rickard



From rickard.backman at oracle.com  Thu Jan 26 12:03:49 2012
From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=)
Date: Thu, 26 Jan 2012 13:03:49 +0100
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com>
References: <4F21206A.1040907@oracle.com>
	<6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com>
Message-ID: <4F214125.7080803@oracle.com>

On 01/26/2012 12:53 PM, Karen Kinnear wrote:
> Code change looks good.
> I assume you want to put this fix back to JDK8 as well.
>
> thank you for the quick fix!
> Karen

Thanks for the review Karen,

I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a 
fixed version of jar.

I'll try to find out if we need to fix it in 8 as well.

/R

>
> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote:
>
>> Hi,
>>
>> We have a problem with some versions of jar reporting errors when trying to run jar cf<some.jar>  com/test com/test/foo
>>
>> This fix removes the redundant subdirectories from the command.
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>>
>> Thanks
>> /Rickard
>



From rickard.backman at oracle.com  Thu Jan 26 12:37:51 2012
From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=)
Date: Thu, 26 Jan 2012 13:37:51 +0100
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com>
References: <4F21206A.1040907@oracle.com>
	<6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com>
	<4F214125.7080803@oracle.com>
	<1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com>
Message-ID: <4F21491F.8020608@oracle.com>

Karen,

that makes sense, I'll push to 8 as well.

Thanks
/R

On 01/26/2012 01:20 PM, Karen Kinnear wrote:
> Thanks Rickard.
>
> My guess is that if it works with all version of jar which you've tested, then it will
> be easier going forward to maintain the file consistently, and it causes no harm.
>
> thanks,
> Karen
>
> On Jan 26, 2012, at 7:03 AM, Rickard B?ckman wrote:
>
>> On 01/26/2012 12:53 PM, Karen Kinnear wrote:
>>> Code change looks good.
>>> I assume you want to put this fix back to JDK8 as well.
>>>
>>> thank you for the quick fix!
>>> Karen
>>
>> Thanks for the review Karen,
>>
>> I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a fixed version of jar.
>>
>> I'll try to find out if we need to fix it in 8 as well.
>>
>> /R
>>
>>>
>>> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote:
>>>
>>>> Hi,
>>>>
>>>> We have a problem with some versions of jar reporting errors when trying to run jar cf<some.jar>   com/test com/test/foo
>>>>
>>>> This fix removes the redundant subdirectories from the command.
>>>>
>>>> Webrev is here:
>>>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>>>>
>>>> Thanks
>>>> /Rickard
>>>
>>
>



From paul.hohensee at oracle.com  Thu Jan 26 14:14:51 2012
From: paul.hohensee at oracle.com (Paul Hohensee)
Date: Thu, 26 Jan 2012 09:14:51 -0500
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21206A.1040907@oracle.com>
References: <4F21206A.1040907@oracle.com>
Message-ID: <4F215FDB.8090209@oracle.com>

Will this fix the jdk7u-dev build problem?

Thanks,

paul

On 1/26/12 4:44 AM, Rickard B?ckman wrote:
> Hi,
>
> We have a problem with some versions of jar reporting errors when 
> trying to run jar cf <some.jar> com/test com/test/foo
>
> This fix removes the redundant subdirectories from the command.
>
> Webrev is here:
> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>
> Thanks
> /Rickard


From paul.hohensee at oracle.com  Thu Jan 26 14:18:50 2012
From: paul.hohensee at oracle.com (Paul Hohensee)
Date: Thu, 26 Jan 2012 09:18:50 -0500
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F215FDB.8090209@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F215FDB.8090209@oracle.com>
Message-ID: <4F2160CA.4090702@oracle.com>

Apparently yes.  Thanks,

paul

On 1/26/12 9:14 AM, Paul Hohensee wrote:
> Will this fix the jdk7u-dev build problem?
>
> Thanks,
>
> paul
>
> On 1/26/12 4:44 AM, Rickard B?ckman wrote:
>> Hi,
>>
>> We have a problem with some versions of jar reporting errors when 
>> trying to run jar cf <some.jar> com/test com/test/foo
>>
>> This fix removes the redundant subdirectories from the command.
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>>
>> Thanks
>> /Rickard


From markus.gronlund at oracle.com  Thu Jan 26 09:57:47 2012
From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=)
Date: Thu, 26 Jan 2012 01:57:47 -0800 (PST)
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21222F.5070605@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F21222F.5070605@oracle.com>
Message-ID: <d40f868d-9eff-45bd-8a9d-edefeaedf5d2@default>

Thanks Alan for quick response, much appreciated.

Markus

> -----Original Message-----
> From: Alan Bateman
> Sent: den 26 januari 2012 10:52
> To: Rickard B?ckman
> Cc: serviceability-dev at openjdk.java.net; build-dev at openjdk.java.net
> Subject: Re: RFR: 7133124 Remove redundant packages from JAR command
> line
> 
> On 26/01/2012 09:44, Rickard B?ckman wrote:
> > Hi,
> >
> > We have a problem with some versions of jar reporting errors when
> > trying to run jar cf <some.jar> com/test com/test/foo
> >
> > This fix removes the redundant subdirectories from the command.
> >
> > Webrev is here:
> > http://cr.openjdk.java.net/~rbackman/7133124/webrev/
> >
> > Thanks
> > /Rickard
> Looks okay to me.
> 
> -Alan.


From karen.kinnear at oracle.com  Thu Jan 26 11:53:58 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 26 Jan 2012 06:53:58 -0500
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21206A.1040907@oracle.com>
References: <4F21206A.1040907@oracle.com>
Message-ID: <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com>

Code change looks good.
I assume you want to put this fix back to JDK8 as well.

thank you for the quick fix!
Karen

On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote:

> Hi,
> 
> We have a problem with some versions of jar reporting errors when trying to run jar cf <some.jar> com/test com/test/foo
> 
> This fix removes the redundant subdirectories from the command.
> 
> Webrev is here:
> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
> 
> Thanks
> /Rickard



From karen.kinnear at oracle.com  Thu Jan 26 12:20:39 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 26 Jan 2012 07:20:39 -0500
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F214125.7080803@oracle.com>
References: <4F21206A.1040907@oracle.com>
	<6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com>
	<4F214125.7080803@oracle.com>
Message-ID: <1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com>

Thanks Rickard.

My guess is that if it works with all version of jar which you've tested, then it will
be easier going forward to maintain the file consistently, and it causes no harm.

thanks,
Karen

On Jan 26, 2012, at 7:03 AM, Rickard B?ckman wrote:

> On 01/26/2012 12:53 PM, Karen Kinnear wrote:
>> Code change looks good.
>> I assume you want to put this fix back to JDK8 as well.
>> 
>> thank you for the quick fix!
>> Karen
> 
> Thanks for the review Karen,
> 
> I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a fixed version of jar.
> 
> I'll try to find out if we need to fix it in 8 as well.
> 
> /R
> 
>> 
>> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote:
>> 
>>> Hi,
>>> 
>>> We have a problem with some versions of jar reporting errors when trying to run jar cf<some.jar>  com/test com/test/foo
>>> 
>>> This fix removes the redundant subdirectories from the command.
>>> 
>>> Webrev is here:
>>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>>> 
>>> Thanks
>>> /Rickard
>> 
> 



From david.holmes at oracle.com  Thu Jan 26 21:43:53 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Jan 2012 07:43:53 +1000
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21491F.8020608@oracle.com>
References: <4F21206A.1040907@oracle.com>
	<6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com>
	<4F214125.7080803@oracle.com>
	<1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com>
	<4F21491F.8020608@oracle.com>
Message-ID: <4F21C919.8030802@oracle.com>

On 26/01/2012 10:37 PM, Rickard B?ckman wrote:
> Karen,
>
> that makes sense, I'll push to 8 as well.

Recall that I plan to change all this by moving it into make/closed for 
8 (and then 7u). So this could be cleaned up then.

David
-----

> Thanks
> /R
>
> On 01/26/2012 01:20 PM, Karen Kinnear wrote:
>> Thanks Rickard.
>>
>> My guess is that if it works with all version of jar which you've
>> tested, then it will
>> be easier going forward to maintain the file consistently, and it
>> causes no harm.
>>
>> thanks,
>> Karen
>>
>> On Jan 26, 2012, at 7:03 AM, Rickard B?ckman wrote:
>>
>>> On 01/26/2012 12:53 PM, Karen Kinnear wrote:
>>>> Code change looks good.
>>>> I assume you want to put this fix back to JDK8 as well.
>>>>
>>>> thank you for the quick fix!
>>>> Karen
>>>
>>> Thanks for the review Karen,
>>>
>>> I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a
>>> fixed version of jar.
>>>
>>> I'll try to find out if we need to fix it in 8 as well.
>>>
>>> /R
>>>
>>>>
>>>> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We have a problem with some versions of jar reporting errors when
>>>>> trying to run jar cf<some.jar> com/test com/test/foo
>>>>>
>>>>> This fix removes the redundant subdirectories from the command.
>>>>>
>>>>> Webrev is here:
>>>>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/
>>>>>
>>>>> Thanks
>>>>> /Rickard
>>>>
>>>
>>
>


From david.holmes at oracle.com  Thu Jan 26 21:56:02 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Jan 2012 07:56:02 +1000
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F2140E0.5040802@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com>
Message-ID: <4F21CBF2.1040407@oracle.com>

On 26/01/2012 10:02 PM, Rickard B?ckman wrote:
> On 01/26/2012 12:50 PM, David Holmes wrote:
>> Change looks fine, but then so did the original! Will this be handled
>> correctly by all versions of the jar command?
>
> We, have checked the contents of the version that RE is using (1.6.0_1
> or something like that) and the one JPRT is using (1.6.0_18) and locally
> on my machine (1.7.0) I don't think I'll be able to verify _all_
> versions of jar. It seems the "faulty" behavior of "jar" was fixed in
> 1.6.0_18 which is the first version I could find that didn't cause the
> error on the previous code. I would rather hope that we could try to use
> one and the same version across all kind of builds of the same jdk
> version. It would help to catch this kind of errors earlier...

Sorry I meant "all versions of jar that we might build with" :)

I think the normal RE process is to build JDK N with the FCS version of 
JDK N-1, which would explain why the old JDK 6 jar is being used. JPRT 
has changes to the bootjdks made "on demand".

As long as we target both 7u and 8 we will be using two different 
toolsets. But I agree that JPRT and RE should be using the same tools. 
That needs to be taken up with RE and Kelly.

Thanks,
David

> Thanks
> /R
>
>>
>>> Thanks
>>> /Rickard
>


From georges.saab at oracle.com  Thu Jan 26 22:47:24 2012
From: georges.saab at oracle.com (Georges Saab)
Date: Thu, 26 Jan 2012 14:47:24 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F21CBF2.1040407@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
Message-ID: <B9199527-AA65-4295-8B59-A99082558435@oracle.com>


On 26 jan 2012, at 13:56, David Holmes wrote:

> On 26/01/2012 10:02 PM, Rickard B?ckman wrote:
>> On 01/26/2012 12:50 PM, David Holmes wrote:
>>> Change looks fine, but then so did the original! Will this be handled
>>> correctly by all versions of the jar command?
>> 
>> We, have checked the contents of the version that RE is using (1.6.0_1
>> or something like that) and the one JPRT is using (1.6.0_18) and locally
>> on my machine (1.7.0) I don't think I'll be able to verify _all_
>> versions of jar. It seems the "faulty" behavior of "jar" was fixed in
>> 1.6.0_18 which is the first version I could find that didn't cause the
>> error on the previous code. I would rather hope that we could try to use
>> one and the same version across all kind of builds of the same jdk
>> version. It would help to catch this kind of errors earlier...
> 
> Sorry I meant "all versions of jar that we might build with" :)
> 
> I think the normal RE process is to build JDK N with the FCS version of JDK N-1, which would explain why the old JDK 6 jar is being used. JPRT has changes to the bootjdks made "on demand".
> 
> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly.

Ideally not just using the same tools, but they should _be_ the same systems.  But I digress...


> 
> Thanks,
> David
> 
>> Thanks
>> /R
>> 
>>> 
>>>> Thanks
>>>> /Rickard
>> 



From kelly.ohair at oracle.com  Fri Jan 27 20:40:49 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 27 Jan 2012 12:40:49 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <B9199527-AA65-4295-8B59-A99082558435@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
Message-ID: <F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>


On Jan 26, 2012, at 2:47 PM, Georges Saab wrote:

>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly.
> 
> Ideally not just using the same tools, but they should _be_ the same systems.  But I digress...


I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct.

However, it is literally impossible to keep any two systems identical all the time, and many products used by RE
(like PocketSoft RTPATCH) are simply not available to all JPRT systems.
So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure
that RE builds will be successful.

We also have little control on when PDIT/GIT system maintenance could change the system
by installing patches or updates on systems. So there is always some randomness to the systems.

-kto


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120127/b0d13cef/attachment.htm>

From georges.saab at oracle.com  Sat Jan 28 05:52:57 2012
From: georges.saab at oracle.com (Georges Saab)
Date: Fri, 27 Jan 2012 21:52:57 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
Message-ID: <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>


On 27 jan 2012, at 12:40, Kelly O'Hair wrote:

> 
> On Jan 26, 2012, at 2:47 PM, Georges Saab wrote:
> 
>>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly.
>> 
>> Ideally not just using the same tools, but they should _be_ the same systems.  But I digress...
> 
> 
> I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct.
> 
> However, it is literally impossible to keep any two systems identical all the time,

Exactly.  If the same system is used for checkin-test builds and production builds then you no
longer have two systems that need to be 'kept in sync'.  


> and many products used by RE
> (like PocketSoft RTPATCH) are simply not available to all JPRT systems.
> So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure
> that RE builds will be successful.
> 
> We also have little control on when PDIT/GIT system maintenance could change the system
> by installing patches or updates on systems. So there is always some randomness to the systems.
> 
> -kto
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120127/e8ded2cd/attachment.htm>

From kelly.ohair at oracle.com  Sat Jan 28 17:46:35 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sat, 28 Jan 2012 09:46:35 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
Message-ID: <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>


On Jan 27, 2012, at 9:52 PM, Georges Saab wrote:

> 
> On 27 jan 2012, at 12:40, Kelly O'Hair wrote:
> 
>> 
>> On Jan 26, 2012, at 2:47 PM, Georges Saab wrote:
>> 
>>>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly.
>>> 
>>> Ideally not just using the same tools, but they should _be_ the same systems.  But I digress...
>> 
>> 
>> I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct.
>> 
>> However, it is literally impossible to keep any two systems identical all the time,
> 
> Exactly.  If the same system is used for checkin-test builds and production builds then you no
> longer have two systems that need to be 'kept in sync'.  

I'm missing something. How can everybody using the exact same system scale to 100's of developers?

And that one system will naturally change over time too, so unless you are able to prevent all change
to a system (impossible with security updates etc) every use of that 'same system' will be different.

-kto
 
> 
> 
>> and many products used by RE
>> (like PocketSoft RTPATCH) are simply not available to all JPRT systems.
>> So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure
>> that RE builds will be successful.
>> 
>> We also have little control on when PDIT/GIT system maintenance could change the system
>> by installing patches or updates on systems. So there is always some randomness to the systems.
>> 
>> -kto
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120128/04598258/attachment.htm>

From georges.saab at oracle.com  Sun Jan 29 18:23:18 2012
From: georges.saab at oracle.com (Georges Saab)
Date: Sun, 29 Jan 2012 10:23:18 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
Message-ID: <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>


On 28 jan 2012, at 09:46, Kelly O'Hair wrote:

> 
> On Jan 27, 2012, at 9:52 PM, Georges Saab wrote:
> 
>> 
>> On 27 jan 2012, at 12:40, Kelly O'Hair wrote:
>> 
>>> 
>>> On Jan 26, 2012, at 2:47 PM, Georges Saab wrote:
>>> 
>>>>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly.
>>>> 
>>>> Ideally not just using the same tools, but they should _be_ the same systems.  But I digress...
>>> 
>>> 
>>> I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct.
>>> 
>>> However, it is literally impossible to keep any two systems identical all the time,
>> 
>> Exactly.  If the same system is used for checkin-test builds and production builds then you no
>> longer have two systems that need to be 'kept in sync'.  
> 
> I'm missing something. How can everybody using the exact same system scale to 100's of developers?

System = distributed build and test of OpenJDK

Developers send in jobs 
Jobs are distribute across a pool of (HW/OS) resources
The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress)
The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage
No assumptions made about what exists on the machine other than HW/OS
The build and test tasks are self sufficient, i.e. bootstrap themselves 
The bootstrapping is done in the same way for different build and test tasks

The only scaling aspect that seems at all challenging is that the current checkin system is designed to serialize checkins in a way that apparently does not scale -- here there are some decisions to be made and tradeoffs but this is nothing new in the world of Open community development (or any large team development for that matter)

> 
> And that one system will naturally change over time too, so unless you are able to prevent all change
> to a system (impossible with security updates etc) every use of that 'same system' will be different.

Yes, but it is possible to control this update and have a staging environment so you know that a HW/OS update will not break the existing successful build when rolled out to the build/test farm.

> 
> -kto
>  
>> 
>> 
>>> and many products used by RE
>>> (like PocketSoft RTPATCH) are simply not available to all JPRT systems.
>>> So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure
>>> that RE builds will be successful.
>>> 
>>> We also have little control on when PDIT/GIT system maintenance could change the system
>>> by installing patches or updates on systems. So there is always some randomness to the systems.
>>> 
>>> -kto
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120129/0cb9beb1/attachment.htm>

From kelly.ohair at oracle.com  Sun Jan 29 19:52:17 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Sun, 29 Jan 2012 11:52:17 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
Message-ID: <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>


On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:

>> 
>> I'm missing something. How can everybody using the exact same system scale to 100's of developers?
> 
> System = distributed build and test of OpenJDK

Ah ha...   I'm down in the trenches dealing with dozens of different OS's arch's variation machines.
You are speaking to a higher level, I need to crawl out of the basement.

> 
> Developers send in jobs 
> Jobs are distribute across a pool of (HW/OS) resources
> The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress)
> The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage
> No assumptions made about what exists on the machine other than HW/OS
> The build and test tasks are self sufficient, i.e. bootstrap themselves 
> The bootstrapping is done in the same way for different build and test tasks

Understood. We have talked about this before.  I have also been on the search for the Holy Grail. ;^)
This is why I keep working on JPRT.

> 
> The only scaling aspect that seems at all challenging is that the current checkin system is designed to serialize checkins in a way that apparently does not scale -- here there are some decisions to be made and tradeoffs but this is nothing new in the world of Open community development (or any large team development for that matter)

The serialize checkins issue can be minimized some by using distributed SCMs (Mercurial, Git, etc)
and using separate forests (fewer developers per source repository means fewer merge/sync issues)
and having an integrator merge into a master. This has proven to work in many situations but it
also creates delivery to master delays, especially if the integration process is too heavyweight.

The JDK projects has been doing this for a long time, I'm sure many people have opinions as to how
successful it is or isn't.

It is my opinion that merges/syncs are some of the most dangerous things you can do to a source base,
and anything we can do to avoid them is usually goodness, I don't think you should scale this without some
very great care.

> 
>> 
>> And that one system will naturally change over time too, so unless you are able to prevent all change
>> to a system (impossible with security updates etc) every use of that 'same system' will be different.
> 
> Yes, but it is possible to control this update and have a staging environment so you know that a HW/OS update will not break the existing successful build when rolled out to the build/test farm.

Possible but not always easy. The auto updating of everything has increased significantly over the years,
making it harder to control completely.

I've been doing this build&test stuff long enough to never expect anything to be 100% reliable.
Hardware fails, software updates regress functionality, networks become unreliable, humans trip over
power cords, virus scanners break things, etc. It just happens, and often, it's not very predictable or reproducible.
You can do lots of things to minimize issues, but at some point you just have to accept a few risks because
the alternative just isn't feasible or just can't happen with the resources we have.

-kto


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120129/f61468c7/attachment.htm>

From Dmitry.Samersoff at oracle.com  Sun Jan 29 21:51:32 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 30 Jan 2012 01:51:32 +0400
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
Message-ID: <4F25BF64.6070802@oracle.com>

Kelly,

> The serialize checkins issue can be minimized some by using
> distributed SCMs (Mercurial, Git, etc)

We have chosen a model:

build->test->integrate

but we may consider different approach:

integrate->build->test->[backout if necessary]

i.e.

  Developer (A) integrate his changeset to an integration workspace
  Bot takes snapshot and start building/testing
  Developer (B) integrate his changeset to an integration workspace
  Bot takes snapshot and start building/testing

  if Job A failed, bot lock integration ws, restore it to pre-A state,
  apply B-patch. unlock ws.

-Dmitry


On 2012-01-29 23:52, Kelly O'Hair wrote:
> 
> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
> 
>>>
>>> I'm missing something. How can everybody using the exact same system
>>> scale to 100's of developers?
>>
>> System = distributed build and test of OpenJDK
> 
> Ah ha...   I'm down in the trenches dealing with dozens of different
> OS's arch's variation machines.
> You are speaking to a higher level, I need to crawl out of the basement.
> 
>>
>> Developers send in jobs 
>> Jobs are distribute across a pool of (HW/OS) resources
>> The resources may be divided into pools dedicated to different tasks
>> (RE/checkin/perf/stress)
>> The pools are populated initially according to predictions of load and
>> then increased/rebalanced according to data on actual usage
>> No assumptions made about what exists on the machine other than HW/OS
>> The build and test tasks are self sufficient, i.e. bootstrap themselves 
>> The bootstrapping is done in the same way for different build and test
>> tasks
> 
> Understood. We have talked about this before.  I have also been on the
> search for the Holy Grail. ;^)
> This is why I keep working on JPRT.
> 
>>
>> The only scaling aspect that seems at all challenging is that the
>> current checkin system is designed to serialize checkins in a way that
>> apparently does not scale -- here there are some decisions to be made
>> and tradeoffs but this is nothing new in the world of Open community
>> development (or any large team development for that matter)
> 
> The serialize checkins issue can be minimized some by using distributed
> SCMs (Mercurial, Git, etc)
> and using separate forests (fewer developers per source repository means
> fewer merge/sync issues)
> and having an integrator merge into a master. This has proven to work in
> many situations but it
> also creates delivery to master delays, especially if the integration
> process is too heavyweight.
> 
> The JDK projects has been doing this for a long time, I'm sure many
> people have opinions as to how
> successful it is or isn't.
> 
> It is my opinion that merges/syncs are some of the most dangerous things
> you can do to a source base,
> and anything we can do to avoid them is usually goodness, I don't think
> you should scale this without some
> very great care.
> 
>>
>>>
>>> And that one system will naturally change over time too, so unless
>>> you are able to prevent all change
>>> to a system (impossible with security updates etc) every use of that
>>> 'same system' will be different.
>>
>> Yes, but it is possible to control this update and have a staging
>> environment so you know that a HW/OS update will not break the
>> existing successful build when rolled out to the build/test farm.
> 
> Possible but not always easy. The auto updating of everything has
> increased significantly over the years,
> making it harder to control completely.
> 
> I've been doing this build&test stuff long enough to never expect
> anything to be 100% reliable.
> Hardware fails, software updates regress functionality, networks become
> unreliable, humans trip over
> power cords, virus scanners break things, etc. It just happens, and
> often, it's not very predictable or reproducible.
> You can do lots of things to minimize issues, but at some point you just
> have to accept a few risks because
> the alternative just isn't feasible or just can't happen with the
> resources we have.
> 
> -kto
> 
> 


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


From John.Coomes at oracle.com  Mon Jan 30 02:35:52 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Sun, 29 Jan 2012 18:35:52 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F25BF64.6070802@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
	<4F25BF64.6070802@oracle.com>
Message-ID: <20262.520.379715.707949@oracle.com>

Dmitry Samersoff (Dmitry.Samersoff at oracle.com) wrote:
> Kelly,
> 
> > The serialize checkins issue can be minimized some by using
> > distributed SCMs (Mercurial, Git, etc)
> 
> We have chosen a model:
> 
> build->test->integrate
> 
> but we may consider different approach:
> 
> integrate->build->test->[backout if necessary]

In that model, you can never rely on the repository having any degree
of stability.  It may not even build at a given moment.

>   Developer (A) integrate his changeset to an integration workspace
>   Bot takes snapshot and start building/testing
>   Developer (B) integrate his changeset to an integration workspace
>   Bot takes snapshot and start building/testing
> 
>   if Job A failed, bot lock integration ws, restore it to pre-A state,
>   apply B-patch. unlock ws.

Don't forget the trusting souls that pulled from the integration repo
after A inflicted the breakage:  they each waste time cleaning up a
copy of A's mess.

-John

> On 2012-01-29 23:52, Kelly O'Hair wrote:
> > 
> > On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
> > 
> >>>
> >>> I'm missing something. How can everybody using the exact same system
> >>> scale to 100's of developers?
> >>
> >> System = distributed build and test of OpenJDK
> > 
> > Ah ha...   I'm down in the trenches dealing with dozens of different
> > OS's arch's variation machines.
> > You are speaking to a higher level, I need to crawl out of the basement.
> > 
> >>
> >> Developers send in jobs 
> >> Jobs are distribute across a pool of (HW/OS) resources
> >> The resources may be divided into pools dedicated to different tasks
> >> (RE/checkin/perf/stress)
> >> The pools are populated initially according to predictions of load and
> >> then increased/rebalanced according to data on actual usage
> >> No assumptions made about what exists on the machine other than HW/OS
> >> The build and test tasks are self sufficient, i.e. bootstrap themselves 
> >> The bootstrapping is done in the same way for different build and test
> >> tasks
> > 
> > Understood. We have talked about this before.  I have also been on the
> > search for the Holy Grail. ;^)
> > This is why I keep working on JPRT.
> > 
> >>
> >> The only scaling aspect that seems at all challenging is that the
> >> current checkin system is designed to serialize checkins in a way that
> >> apparently does not scale -- here there are some decisions to be made
> >> and tradeoffs but this is nothing new in the world of Open community
> >> development (or any large team development for that matter)
> > 
> > The serialize checkins issue can be minimized some by using distributed
> > SCMs (Mercurial, Git, etc)
> > and using separate forests (fewer developers per source repository means
> > fewer merge/sync issues)
> > and having an integrator merge into a master. This has proven to work in
> > many situations but it
> > also creates delivery to master delays, especially if the integration
> > process is too heavyweight.
> > 
> > The JDK projects has been doing this for a long time, I'm sure many
> > people have opinions as to how
> > successful it is or isn't.
> > 
> > It is my opinion that merges/syncs are some of the most dangerous things
> > you can do to a source base,
> > and anything we can do to avoid them is usually goodness, I don't think
> > you should scale this without some
> > very great care.
> > 
> >>
> >>>
> >>> And that one system will naturally change over time too, so unless
> >>> you are able to prevent all change
> >>> to a system (impossible with security updates etc) every use of that
> >>> 'same system' will be different.
> >>
> >> Yes, but it is possible to control this update and have a staging
> >> environment so you know that a HW/OS update will not break the
> >> existing successful build when rolled out to the build/test farm.
> > 
> > Possible but not always easy. The auto updating of everything has
> > increased significantly over the years,
> > making it harder to control completely.
> > 
> > I've been doing this build&test stuff long enough to never expect
> > anything to be 100% reliable.
> > Hardware fails, software updates regress functionality, networks become
> > unreliable, humans trip over
> > power cords, virus scanners break things, etc. It just happens, and
> > often, it's not very predictable or reproducible.
> > You can do lots of things to minimize issues, but at some point you just
> > have to accept a few risks because
> > the alternative just isn't feasible or just can't happen with the
> > resources we have.
> > 
> > -kto
> > 
> > 
> 
> 
> -- 
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...


From Dmitry.Samersoff at oracle.com  Mon Jan 30 09:09:50 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 30 Jan 2012 13:09:50 +0400
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <20262.520.379715.707949@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
	<4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com>
Message-ID: <4F265E5E.3010308@oracle.com>

John,

Actually the goal of my letter is not to promote new integration scheme. 
Just to remind that we need to put some efforts to internal process 
review and optimization.

But, see answers below (inline):

Integration method I mentioned often used in open source projects,
because it doesn't require any special infrastructure for external 
commiters. The only necessary thing to do safe commit is a write access 
to integration (-gate) workspace.

On 2012-01-30 06:35, John Coomes wrote:
>> We have chosen a model:
>>
>> build->test->integrate
>>
>> but we may consider different approach:
>>
>> integrate->build->test->[backout if necessary]
>
> In that model, you can never rely on the repository having any degree
> of stability.  It may not even build at a given moment.

What happens today if Developer A and Developer B changes the same line 
of a source?

What happens today if Developer A changes some_func() but Developer B
rely on some_func() ?

We would get a fault *after* all integration tests and SQE file one more 
nightly bug. To the time someone investigate it and give the fix, bad 
code will be distributed to all dev workspaces.


>>    Developer (A) integrate his changeset to an integration workspace
>>    Bot takes snapshot and start building/testing
>>    Developer (B) integrate his changeset to an integration workspace
>>    Bot takes snapshot and start building/testing
>>
>>    if Job A failed, bot lock integration ws, restore it to pre-A state,
>>    apply B-patch. unlock ws.
>
> Don't forget the trusting souls that pulled from the integration repo
> after A inflicted the breakage:  they each waste time cleaning up a
> copy of A's mess.

Nobody pulls from -gate repository today and nobody expected to do it.
-gate to ws merge continues as usual.

To remove faulty changeset we need about fifteen minutes for whole jdk 
at worst.

-Dmitry

>
> -John
>
>> On 2012-01-29 23:52, Kelly O'Hair wrote:
>>>
>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
>>>
>>>>>
>>>>> I'm missing something. How can everybody using the exact same system
>>>>> scale to 100's of developers?
>>>>
>>>> System = distributed build and test of OpenJDK
>>>
>>> Ah ha...   I'm down in the trenches dealing with dozens of different
>>> OS's arch's variation machines.
>>> You are speaking to a higher level, I need to crawl out of the basement.
>>>
>>>>
>>>> Developers send in jobs
>>>> Jobs are distribute across a pool of (HW/OS) resources
>>>> The resources may be divided into pools dedicated to different tasks
>>>> (RE/checkin/perf/stress)
>>>> The pools are populated initially according to predictions of load and
>>>> then increased/rebalanced according to data on actual usage
>>>> No assumptions made about what exists on the machine other than HW/OS
>>>> The build and test tasks are self sufficient, i.e. bootstrap themselves
>>>> The bootstrapping is done in the same way for different build and test
>>>> tasks
>>>
>>> Understood. We have talked about this before.  I have also been on the
>>> search for the Holy Grail. ;^)
>>> This is why I keep working on JPRT.
>>>
>>>>
>>>> The only scaling aspect that seems at all challenging is that the
>>>> current checkin system is designed to serialize checkins in a way that
>>>> apparently does not scale -- here there are some decisions to be made
>>>> and tradeoffs but this is nothing new in the world of Open community
>>>> development (or any large team development for that matter)
>>>
>>> The serialize checkins issue can be minimized some by using distributed
>>> SCMs (Mercurial, Git, etc)
>>> and using separate forests (fewer developers per source repository means
>>> fewer merge/sync issues)
>>> and having an integrator merge into a master. This has proven to work in
>>> many situations but it
>>> also creates delivery to master delays, especially if the integration
>>> process is too heavyweight.
>>>
>>> The JDK projects has been doing this for a long time, I'm sure many
>>> people have opinions as to how
>>> successful it is or isn't.
>>>
>>> It is my opinion that merges/syncs are some of the most dangerous things
>>> you can do to a source base,
>>> and anything we can do to avoid them is usually goodness, I don't think
>>> you should scale this without some
>>> very great care.
>>>
>>>>
>>>>>
>>>>> And that one system will naturally change over time too, so unless
>>>>> you are able to prevent all change
>>>>> to a system (impossible with security updates etc) every use of that
>>>>> 'same system' will be different.
>>>>
>>>> Yes, but it is possible to control this update and have a staging
>>>> environment so you know that a HW/OS update will not break the
>>>> existing successful build when rolled out to the build/test farm.
>>>
>>> Possible but not always easy. The auto updating of everything has
>>> increased significantly over the years,
>>> making it harder to control completely.
>>>
>>> I've been doing this build&test stuff long enough to never expect
>>> anything to be 100% reliable.
>>> Hardware fails, software updates regress functionality, networks become
>>> unreliable, humans trip over
>>> power cords, virus scanners break things, etc. It just happens, and
>>> often, it's not very predictable or reproducible.
>>> You can do lots of things to minimize issues, but at some point you just
>>> have to accept a few risks because
>>> the alternative just isn't feasible or just can't happen with the
>>> resources we have.
>>>
>>> -kto
>>>
>>>
>>
>>
>> --
>> Dmitry Samersoff
>> Java Hotspot development team, SPB04
>> * There will come soft rains ...


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


From robert.ottenhag at oracle.com  Mon Jan 30 10:00:46 2012
From: robert.ottenhag at oracle.com (Robert Ottenhag)
Date: Mon, 30 Jan 2012 11:00:46 +0100
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F265E5E.3010308@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
	<4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com>
	<4F265E5E.3010308@oracle.com>
Message-ID: <4F266A4E.9030902@oracle.com>

Dmitry,

I think this discussion diverged somewhat from the original topic, but I 
do agree with you that we must also attack the problem on a process level.

With the model you propose (and also the existing model) I would also 
like to stress the need for continuous and automatic builds triggered by 
incoming new changes compared to the last working change. Having that, 
it is possible to update labels (tags) for "last_clean_build", 
"last_nightly_build", etc. That way any build breakage would only be 
visible at the tip.

However, when submitting a new change care should be taken to do it 
against a working tip, that it builds and tests correctly (personal 
check-in testing). Actually, this is close to the model we had for the 
JRockit source base. WLS also uses the model of sliding labels for 
"last_clean_build" where developers most often only do partial builds 
themselves.

Regarding external committers, I think they need both the option of 
building and testing locally, as well as access to an Open JDK specific 
queue for build and test submissions.

By making use of cross compilation and open tools it is possible to at 
least verify that the product builds locally. Even better is to also 
supply preconfigured VMs with the necessary standard build and test 
environment (e.g. obsolete Solaris or Linux distros that we require). In 
general, having a build and test setup that is automatically 
configurable (including Windows) will help both internal and external 
developers (see also the build-infra project).

/Robert

On 01/30/2012 10:09 AM, Dmitry Samersoff wrote:
> John,
>
> Actually the goal of my letter is not to promote new integration 
> scheme. Just to remind that we need to put some efforts to internal 
> process review and optimization.
>
> But, see answers below (inline):
>
> Integration method I mentioned often used in open source projects,
> because it doesn't require any special infrastructure for external 
> commiters. The only necessary thing to do safe commit is a write 
> access to integration (-gate) workspace.
>
> On 2012-01-30 06:35, John Coomes wrote:
>>> We have chosen a model:
>>>
>>> build->test->integrate
>>>
>>> but we may consider different approach:
>>>
>>> integrate->build->test->[backout if necessary]
>>
>> In that model, you can never rely on the repository having any degree
>> of stability.  It may not even build at a given moment.
>
> What happens today if Developer A and Developer B changes the same 
> line of a source?
>
> What happens today if Developer A changes some_func() but Developer B
> rely on some_func() ?
>
> We would get a fault *after* all integration tests and SQE file one 
> more nightly bug. To the time someone investigate it and give the fix, 
> bad code will be distributed to all dev workspaces.
>
>
>>>    Developer (A) integrate his changeset to an integration workspace
>>>    Bot takes snapshot and start building/testing
>>>    Developer (B) integrate his changeset to an integration workspace
>>>    Bot takes snapshot and start building/testing
>>>
>>>    if Job A failed, bot lock integration ws, restore it to pre-A state,
>>>    apply B-patch. unlock ws.
>>
>> Don't forget the trusting souls that pulled from the integration repo
>> after A inflicted the breakage:  they each waste time cleaning up a
>> copy of A's mess.
>
> Nobody pulls from -gate repository today and nobody expected to do it.
> -gate to ws merge continues as usual.
>
> To remove faulty changeset we need about fifteen minutes for whole jdk 
> at worst.
>
> -Dmitry
>
>>
>> -John
>>
>>> On 2012-01-29 23:52, Kelly O'Hair wrote:
>>>>
>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
>>>>
>>>>>>
>>>>>> I'm missing something. How can everybody using the exact same system
>>>>>> scale to 100's of developers?
>>>>>
>>>>> System = distributed build and test of OpenJDK
>>>>
>>>> Ah ha...   I'm down in the trenches dealing with dozens of different
>>>> OS's arch's variation machines.
>>>> You are speaking to a higher level, I need to crawl out of the 
>>>> basement.
>>>>
>>>>>
>>>>> Developers send in jobs
>>>>> Jobs are distribute across a pool of (HW/OS) resources
>>>>> The resources may be divided into pools dedicated to different tasks
>>>>> (RE/checkin/perf/stress)
>>>>> The pools are populated initially according to predictions of load 
>>>>> and
>>>>> then increased/rebalanced according to data on actual usage
>>>>> No assumptions made about what exists on the machine other than HW/OS
>>>>> The build and test tasks are self sufficient, i.e. bootstrap 
>>>>> themselves
>>>>> The bootstrapping is done in the same way for different build and 
>>>>> test
>>>>> tasks
>>>>
>>>> Understood. We have talked about this before.  I have also been on the
>>>> search for the Holy Grail. ;^)
>>>> This is why I keep working on JPRT.
>>>>
>>>>>
>>>>> The only scaling aspect that seems at all challenging is that the
>>>>> current checkin system is designed to serialize checkins in a way 
>>>>> that
>>>>> apparently does not scale -- here there are some decisions to be made
>>>>> and tradeoffs but this is nothing new in the world of Open community
>>>>> development (or any large team development for that matter)
>>>>
>>>> The serialize checkins issue can be minimized some by using 
>>>> distributed
>>>> SCMs (Mercurial, Git, etc)
>>>> and using separate forests (fewer developers per source repository 
>>>> means
>>>> fewer merge/sync issues)
>>>> and having an integrator merge into a master. This has proven to 
>>>> work in
>>>> many situations but it
>>>> also creates delivery to master delays, especially if the integration
>>>> process is too heavyweight.
>>>>
>>>> The JDK projects has been doing this for a long time, I'm sure many
>>>> people have opinions as to how
>>>> successful it is or isn't.
>>>>
>>>> It is my opinion that merges/syncs are some of the most dangerous 
>>>> things
>>>> you can do to a source base,
>>>> and anything we can do to avoid them is usually goodness, I don't 
>>>> think
>>>> you should scale this without some
>>>> very great care.
>>>>
>>>>>
>>>>>>
>>>>>> And that one system will naturally change over time too, so unless
>>>>>> you are able to prevent all change
>>>>>> to a system (impossible with security updates etc) every use of that
>>>>>> 'same system' will be different.
>>>>>
>>>>> Yes, but it is possible to control this update and have a staging
>>>>> environment so you know that a HW/OS update will not break the
>>>>> existing successful build when rolled out to the build/test farm.
>>>>
>>>> Possible but not always easy. The auto updating of everything has
>>>> increased significantly over the years,
>>>> making it harder to control completely.
>>>>
>>>> I've been doing this build&test stuff long enough to never expect
>>>> anything to be 100% reliable.
>>>> Hardware fails, software updates regress functionality, networks 
>>>> become
>>>> unreliable, humans trip over
>>>> power cords, virus scanners break things, etc. It just happens, and
>>>> often, it's not very predictable or reproducible.
>>>> You can do lots of things to minimize issues, but at some point you 
>>>> just
>>>> have to accept a few risks because
>>>> the alternative just isn't feasible or just can't happen with the
>>>> resources we have.
>>>>
>>>> -kto
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Dmitry Samersoff
>>> Java Hotspot development team, SPB04
>>> * There will come soft rains ...
>
>


-- 
Oracle
Robert Ottenhag | Senior Member of Technical Staff
Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
Oracle Java HotSpot Virtual Machine
ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm

Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746

Green Oracle

Oracle is committed to developing practices and products that help protect the environment
--



From Alan.Bateman at oracle.com  Mon Jan 30 15:08:51 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jan 2012 15:08:51 +0000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
Message-ID: <4F26B283.8090103@oracle.com>


The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed) 
to remove the JAX-WS dependency on apt and the com.sun.mirror API:

http://cr.openjdk.java.net/~alanb/7140918/webrev/

This is needed before Joe Darcy can wield his machete.

Please cc'ed Miran and Martin on my review comments.

-Alan.


From joe.darcy at oracle.com  Mon Jan 30 16:26:04 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 08:26:04 -0800
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F26B283.8090103@oracle.com>
References: <4F26B283.8090103@oracle.com>
Message-ID: <4F26C49C.4050600@oracle.com>

On 01/30/2012 07:08 AM, Alan Bateman wrote:
>
> The following webrev is a patch from Miran Kos and Martin Grebac 
> (cc'ed) to remove the JAX-WS dependency on apt and the com.sun.mirror 
> API:
>
> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>
> This is needed before Joe Darcy can wield his machete.
>
> Please cc'ed Miran and Martin on my review comments.
>
> -Alan.

Hi Alan,

In Release.gmk, there seems to be inconsistent indention on these two lines:

  368     com/sun/tools/internal/jxc/ap   \
  369     com/sun/tools/internal/ws/wscompile/plugin/at_generated \

Likewise at Defs-jaxws.gmk:

   58          
META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin \
   59          META-INF/services/com.sun.tools.internal.xjc.Plugin \

Otherwise, the changes look okay.

Thanks,

-Joe


From kelly.ohair at oracle.com  Mon Jan 30 17:26:49 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 30 Jan 2012 09:26:49 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F266A4E.9030902@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
	<4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com>
	<4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com>
Message-ID: <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>

Diverged and in transit to another planet. :^(

A push to a shared repo without verifying it builds on all supported platforms is risky behavior, and one that can
consume needless resources finding out it doesn't build, and more importantly waste your co-worker's time undoing it.
We have the ability to prevent that, and we should.

And the JDK is not just a VM, and cross compilation does not address Windows or Solaris.
This is a much more difficult situation than most people think it is.
Yes we can change things to simplify it, make it better, but don't kid yourself, this is more complex than most people think.

Anyone that hasn't built the entire JDK on Windows, successfully, should try it.

-kto

On Jan 30, 2012, at 2:00 AM, Robert Ottenhag wrote:

> Dmitry,
> 
> I think this discussion diverged somewhat from the original topic, but I do agree with you that we must also attack the problem on a process level.
> 
> With the model you propose (and also the existing model) I would also like to stress the need for continuous and automatic builds triggered by incoming new changes compared to the last working change. Having that, it is possible to update labels (tags) for "last_clean_build", "last_nightly_build", etc. That way any build breakage would only be visible at the tip.
> 
> However, when submitting a new change care should be taken to do it against a working tip, that it builds and tests correctly (personal check-in testing). Actually, this is close to the model we had for the JRockit source base. WLS also uses the model of sliding labels for "last_clean_build" where developers most often only do partial builds themselves.
> 
> Regarding external committers, I think they need both the option of building and testing locally, as well as access to an Open JDK specific queue for build and test submissions.
> 
> By making use of cross compilation and open tools it is possible to at least verify that the product builds locally. Even better is to also supply preconfigured VMs with the necessary standard build and test environment (e.g. obsolete Solaris or Linux distros that we require). In general, having a build and test setup that is automatically configurable (including Windows) will help both internal and external developers (see also the build-infra project).
> 
> /Robert
> 
> On 01/30/2012 10:09 AM, Dmitry Samersoff wrote:
>> John,
>> 
>> Actually the goal of my letter is not to promote new integration scheme. Just to remind that we need to put some efforts to internal process review and optimization.
>> 
>> But, see answers below (inline):
>> 
>> Integration method I mentioned often used in open source projects,
>> because it doesn't require any special infrastructure for external commiters. The only necessary thing to do safe commit is a write access to integration (-gate) workspace.
>> 
>> On 2012-01-30 06:35, John Coomes wrote:
>>>> We have chosen a model:
>>>> 
>>>> build->test->integrate
>>>> 
>>>> but we may consider different approach:
>>>> 
>>>> integrate->build->test->[backout if necessary]
>>> 
>>> In that model, you can never rely on the repository having any degree
>>> of stability.  It may not even build at a given moment.
>> 
>> What happens today if Developer A and Developer B changes the same line of a source?
>> 
>> What happens today if Developer A changes some_func() but Developer B
>> rely on some_func() ?
>> 
>> We would get a fault *after* all integration tests and SQE file one more nightly bug. To the time someone investigate it and give the fix, bad code will be distributed to all dev workspaces.
>> 
>> 
>>>>   Developer (A) integrate his changeset to an integration workspace
>>>>   Bot takes snapshot and start building/testing
>>>>   Developer (B) integrate his changeset to an integration workspace
>>>>   Bot takes snapshot and start building/testing
>>>> 
>>>>   if Job A failed, bot lock integration ws, restore it to pre-A state,
>>>>   apply B-patch. unlock ws.
>>> 
>>> Don't forget the trusting souls that pulled from the integration repo
>>> after A inflicted the breakage:  they each waste time cleaning up a
>>> copy of A's mess.
>> 
>> Nobody pulls from -gate repository today and nobody expected to do it.
>> -gate to ws merge continues as usual.
>> 
>> To remove faulty changeset we need about fifteen minutes for whole jdk at worst.
>> 
>> -Dmitry
>> 
>>> 
>>> -John
>>> 
>>>> On 2012-01-29 23:52, Kelly O'Hair wrote:
>>>>> 
>>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
>>>>> 
>>>>>>> 
>>>>>>> I'm missing something. How can everybody using the exact same system
>>>>>>> scale to 100's of developers?
>>>>>> 
>>>>>> System = distributed build and test of OpenJDK
>>>>> 
>>>>> Ah ha...   I'm down in the trenches dealing with dozens of different
>>>>> OS's arch's variation machines.
>>>>> You are speaking to a higher level, I need to crawl out of the basement.
>>>>> 
>>>>>> 
>>>>>> Developers send in jobs
>>>>>> Jobs are distribute across a pool of (HW/OS) resources
>>>>>> The resources may be divided into pools dedicated to different tasks
>>>>>> (RE/checkin/perf/stress)
>>>>>> The pools are populated initially according to predictions of load and
>>>>>> then increased/rebalanced according to data on actual usage
>>>>>> No assumptions made about what exists on the machine other than HW/OS
>>>>>> The build and test tasks are self sufficient, i.e. bootstrap themselves
>>>>>> The bootstrapping is done in the same way for different build and test
>>>>>> tasks
>>>>> 
>>>>> Understood. We have talked about this before.  I have also been on the
>>>>> search for the Holy Grail. ;^)
>>>>> This is why I keep working on JPRT.
>>>>> 
>>>>>> 
>>>>>> The only scaling aspect that seems at all challenging is that the
>>>>>> current checkin system is designed to serialize checkins in a way that
>>>>>> apparently does not scale -- here there are some decisions to be made
>>>>>> and tradeoffs but this is nothing new in the world of Open community
>>>>>> development (or any large team development for that matter)
>>>>> 
>>>>> The serialize checkins issue can be minimized some by using distributed
>>>>> SCMs (Mercurial, Git, etc)
>>>>> and using separate forests (fewer developers per source repository means
>>>>> fewer merge/sync issues)
>>>>> and having an integrator merge into a master. This has proven to work in
>>>>> many situations but it
>>>>> also creates delivery to master delays, especially if the integration
>>>>> process is too heavyweight.
>>>>> 
>>>>> The JDK projects has been doing this for a long time, I'm sure many
>>>>> people have opinions as to how
>>>>> successful it is or isn't.
>>>>> 
>>>>> It is my opinion that merges/syncs are some of the most dangerous things
>>>>> you can do to a source base,
>>>>> and anything we can do to avoid them is usually goodness, I don't think
>>>>> you should scale this without some
>>>>> very great care.
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> And that one system will naturally change over time too, so unless
>>>>>>> you are able to prevent all change
>>>>>>> to a system (impossible with security updates etc) every use of that
>>>>>>> 'same system' will be different.
>>>>>> 
>>>>>> Yes, but it is possible to control this update and have a staging
>>>>>> environment so you know that a HW/OS update will not break the
>>>>>> existing successful build when rolled out to the build/test farm.
>>>>> 
>>>>> Possible but not always easy. The auto updating of everything has
>>>>> increased significantly over the years,
>>>>> making it harder to control completely.
>>>>> 
>>>>> I've been doing this build&test stuff long enough to never expect
>>>>> anything to be 100% reliable.
>>>>> Hardware fails, software updates regress functionality, networks become
>>>>> unreliable, humans trip over
>>>>> power cords, virus scanners break things, etc. It just happens, and
>>>>> often, it's not very predictable or reproducible.
>>>>> You can do lots of things to minimize issues, but at some point you just
>>>>> have to accept a few risks because
>>>>> the alternative just isn't feasible or just can't happen with the
>>>>> resources we have.
>>>>> 
>>>>> -kto
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Dmitry Samersoff
>>>> Java Hotspot development team, SPB04
>>>> * There will come soft rains ...
>> 
>> 
> 
> 
> -- 
> Oracle
> Robert Ottenhag | Senior Member of Technical Staff
> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
> Oracle Java HotSpot Virtual Machine
> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
> 
> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746
> 
> Green Oracle
> 
> Oracle is committed to developing practices and products that help protect the environment
> --
> 



From robert.ottenhag at oracle.com  Mon Jan 30 17:41:27 2012
From: robert.ottenhag at oracle.com (Robert Ottenhag)
Date: Mon, 30 Jan 2012 09:41:27 -0800 (PST)
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
	<4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com>
	<4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com>
	<59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>
Message-ID: <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>

Inline,

> -----Original Message-----
> From: Kelly O'Hair
> Sent: Monday, January 30, 2012 6:27 PM
> To: Robert Ottenhag
> Cc: Dmitry Samersoff; serviceability-dev at openjdk.java.net; John Coomes;
> build-dev at openjdk.java.net
> Subject: Re: RFR: 7133124 Remove redundant packages from JAR command line
> 
> Diverged and in transit to another planet. :^(
> 
> A push to a shared repo without verifying it builds on all supported
> platforms is risky behavior, and one that can
> consume needless resources finding out it doesn't build, and more
> importantly waste your co-worker's time undoing it.
> We have the ability to prevent that, and we should.

I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a _bad_ thing).

> And the JDK is not just a VM, and cross compilation does not address
> Windows or Solaris.

It does not, but it can limit the number of build platforms that need to be maintained. See also my suggestion on an open JRPT queue and preconfigured virtual machines for build and test. Windows and Linux should cross build 32_to_64bit and 64_to_32bit, and Solaris can be helped by a virtual box installation of Solaris/{i586,x64}.

> This is a much more difficult situation than most people think it is.
> Yes we can change things to simplify it, make it better, but don't kid
> yourself, this is more complex than most people think.

True, but aiming for simpler and better is always beneficial.

> 
> Anyone that hasn't built the entire JDK on Windows, successfully, should
> try it.

I have ;-)

/Robert

> 
> -kto
> 
> On Jan 30, 2012, at 2:00 AM, Robert Ottenhag wrote:
> 
> > Dmitry,
> >
> > I think this discussion diverged somewhat from the original topic, but I
> do agree with you that we must also attack the problem on a process level.
> >
> > With the model you propose (and also the existing model) I would also
> like to stress the need for continuous and automatic builds triggered by
> incoming new changes compared to the last working change. Having that, it
> is possible to update labels (tags) for "last_clean_build",
> "last_nightly_build", etc. That way any build breakage would only be
> visible at the tip.
> >
> > However, when submitting a new change care should be taken to do it
> against a working tip, that it builds and tests correctly (personal check-
> in testing). Actually, this is close to the model we had for the JRockit
> source base. WLS also uses the model of sliding labels for
> "last_clean_build" where developers most often only do partial builds
> themselves.
> >
> > Regarding external committers, I think they need both the option of
> building and testing locally, as well as access to an Open JDK specific
> queue for build and test submissions.
> >
> > By making use of cross compilation and open tools it is possible to at
> least verify that the product builds locally. Even better is to also
> supply preconfigured VMs with the necessary standard build and test
> environment (e.g. obsolete Solaris or Linux distros that we require). In
> general, having a build and test setup that is automatically configurable
> (including Windows) will help both internal and external developers (see
> also the build-infra project).
> >
> > /Robert
> >
> > On 01/30/2012 10:09 AM, Dmitry Samersoff wrote:
> >> John,
> >>
> >> Actually the goal of my letter is not to promote new integration
> scheme. Just to remind that we need to put some efforts to internal
> process review and optimization.
> >>
> >> But, see answers below (inline):
> >>
> >> Integration method I mentioned often used in open source projects,
> >> because it doesn't require any special infrastructure for external
> commiters. The only necessary thing to do safe commit is a write access to
> integration (-gate) workspace.
> >>
> >> On 2012-01-30 06:35, John Coomes wrote:
> >>>> We have chosen a model:
> >>>>
> >>>> build->test->integrate
> >>>>
> >>>> but we may consider different approach:
> >>>>
> >>>> integrate->build->test->[backout if necessary]
> >>>
> >>> In that model, you can never rely on the repository having any degree
> >>> of stability.  It may not even build at a given moment.
> >>
> >> What happens today if Developer A and Developer B changes the same line
> of a source?
> >>
> >> What happens today if Developer A changes some_func() but Developer B
> >> rely on some_func() ?
> >>
> >> We would get a fault *after* all integration tests and SQE file one
> more nightly bug. To the time someone investigate it and give the fix, bad
> code will be distributed to all dev workspaces.
> >>
> >>
> >>>>   Developer (A) integrate his changeset to an integration workspace
> >>>>   Bot takes snapshot and start building/testing
> >>>>   Developer (B) integrate his changeset to an integration workspace
> >>>>   Bot takes snapshot and start building/testing
> >>>>
> >>>>   if Job A failed, bot lock integration ws, restore it to pre-A
> state,
> >>>>   apply B-patch. unlock ws.
> >>>
> >>> Don't forget the trusting souls that pulled from the integration repo
> >>> after A inflicted the breakage:  they each waste time cleaning up a
> >>> copy of A's mess.
> >>
> >> Nobody pulls from -gate repository today and nobody expected to do it.
> >> -gate to ws merge continues as usual.
> >>
> >> To remove faulty changeset we need about fifteen minutes for whole jdk
> at worst.
> >>
> >> -Dmitry
> >>
> >>>
> >>> -John
> >>>
> >>>> On 2012-01-29 23:52, Kelly O'Hair wrote:
> >>>>>
> >>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
> >>>>>
> >>>>>>>
> >>>>>>> I'm missing something. How can everybody using the exact same
> system
> >>>>>>> scale to 100's of developers?
> >>>>>>
> >>>>>> System = distributed build and test of OpenJDK
> >>>>>
> >>>>> Ah ha...   I'm down in the trenches dealing with dozens of different
> >>>>> OS's arch's variation machines.
> >>>>> You are speaking to a higher level, I need to crawl out of the
> basement.
> >>>>>
> >>>>>>
> >>>>>> Developers send in jobs
> >>>>>> Jobs are distribute across a pool of (HW/OS) resources
> >>>>>> The resources may be divided into pools dedicated to different
> tasks
> >>>>>> (RE/checkin/perf/stress)
> >>>>>> The pools are populated initially according to predictions of load
> and
> >>>>>> then increased/rebalanced according to data on actual usage
> >>>>>> No assumptions made about what exists on the machine other than
> HW/OS
> >>>>>> The build and test tasks are self sufficient, i.e. bootstrap
> themselves
> >>>>>> The bootstrapping is done in the same way for different build and
> test
> >>>>>> tasks
> >>>>>
> >>>>> Understood. We have talked about this before.  I have also been on
> the
> >>>>> search for the Holy Grail. ;^)
> >>>>> This is why I keep working on JPRT.
> >>>>>
> >>>>>>
> >>>>>> The only scaling aspect that seems at all challenging is that the
> >>>>>> current checkin system is designed to serialize checkins in a way
> that
> >>>>>> apparently does not scale -- here there are some decisions to be
> made
> >>>>>> and tradeoffs but this is nothing new in the world of Open
> community
> >>>>>> development (or any large team development for that matter)
> >>>>>
> >>>>> The serialize checkins issue can be minimized some by using
> distributed
> >>>>> SCMs (Mercurial, Git, etc)
> >>>>> and using separate forests (fewer developers per source repository
> means
> >>>>> fewer merge/sync issues)
> >>>>> and having an integrator merge into a master. This has proven to
> work in
> >>>>> many situations but it
> >>>>> also creates delivery to master delays, especially if the
> integration
> >>>>> process is too heavyweight.
> >>>>>
> >>>>> The JDK projects has been doing this for a long time, I'm sure many
> >>>>> people have opinions as to how
> >>>>> successful it is or isn't.
> >>>>>
> >>>>> It is my opinion that merges/syncs are some of the most dangerous
> things
> >>>>> you can do to a source base,
> >>>>> and anything we can do to avoid them is usually goodness, I don't
> think
> >>>>> you should scale this without some
> >>>>> very great care.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> And that one system will naturally change over time too, so unless
> >>>>>>> you are able to prevent all change
> >>>>>>> to a system (impossible with security updates etc) every use of
> that
> >>>>>>> 'same system' will be different.
> >>>>>>
> >>>>>> Yes, but it is possible to control this update and have a staging
> >>>>>> environment so you know that a HW/OS update will not break the
> >>>>>> existing successful build when rolled out to the build/test farm.
> >>>>>
> >>>>> Possible but not always easy. The auto updating of everything has
> >>>>> increased significantly over the years,
> >>>>> making it harder to control completely.
> >>>>>
> >>>>> I've been doing this build&test stuff long enough to never expect
> >>>>> anything to be 100% reliable.
> >>>>> Hardware fails, software updates regress functionality, networks
> become
> >>>>> unreliable, humans trip over
> >>>>> power cords, virus scanners break things, etc. It just happens, and
> >>>>> often, it's not very predictable or reproducible.
> >>>>> You can do lots of things to minimize issues, but at some point you
> just
> >>>>> have to accept a few risks because
> >>>>> the alternative just isn't feasible or just can't happen with the
> >>>>> resources we have.
> >>>>>
> >>>>> -kto
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Dmitry Samersoff
> >>>> Java Hotspot development team, SPB04
> >>>> * There will come soft rains ...
> >>
> >>
> >
> >
> > --
> > Oracle
> > Robert Ottenhag | Senior Member of Technical Staff
> > Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
> > Oracle Java HotSpot Virtual Machine
> > ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
> >
> > Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-
> 6746
> >
> > Green Oracle
> >
> > Oracle is committed to developing practices and products that help
> protect the environment
> > --
> >
> 


From jonathan.gibbons at oracle.com  Mon Jan 30 18:02:40 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 30 Jan 2012 10:02:40 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>
References: <4F21206A.1040907@oracle.com>
	<4F213E19.90508@oracle.com>	<4F2140E0.5040802@oracle.com>
	<4F21CBF2.1040407@oracle.com>	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>	<4F25BF64.6070802@oracle.com>
	<20262.520.379715.707949@oracle.com>	<4F265E5E.3010308@oracle.com>
	<4F266A4E.9030902@oracle.com>	<59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>
	<4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>
Message-ID: <4F26DB40.9090300@oracle.com>

On 01/30/2012 09:41 AM, Robert Ottenhag wrote:
>> >  A push to a shared repo without verifying it builds on all supported
>> >  platforms is risky behavior, and one that can
>> >  consume needless resources finding out it doesn't build, and more
>> >  importantly waste your co-worker's time undoing it.
>> >  We have the ability to prevent that, and we should.
> I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a_bad_  thing).
>

We need to be careful here. We have the ability to totally overload any 
reasonable build system, and going through a full build and test for 
what are sometimes small changes may be impractical (having 100+ 
developers waiting for the build queue is also a _bad_ thing.)

As Joe Darcy often points out, we need to be careful that we are not so 
afraid of doing anything bad that we prevent anything good from happening.

Note, I am /not/ saying we don't need a good build and test system.  We 
do.  We just need to be careful how we mandate its use.

-- Jon


From kelly.ohair at oracle.com  Mon Jan 30 23:41:23 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 30 Jan 2012 15:41:23 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4F26DB40.9090300@oracle.com>
References: <4F21206A.1040907@oracle.com>
	<4F213E19.90508@oracle.com>	<4F2140E0.5040802@oracle.com>
	<4F21CBF2.1040407@oracle.com>	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>	<4F25BF64.6070802@oracle.com>
	<20262.520.379715.707949@oracle.com>	<4F265E5E.3010308@oracle.com>
	<4F266A4E.9030902@oracle.com>	<59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>
	<4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>
	<4F26DB40.9090300@oracle.com>
Message-ID: <BF58B82B-A1D6-4E53-A6F6-0E297F23B65F@oracle.com>


On Jan 30, 2012, at 10:02 AM, Jonathan Gibbons wrote:

> On 01/30/2012 09:41 AM, Robert Ottenhag wrote:
>>> >  A push to a shared repo without verifying it builds on all supported
>>> >  platforms is risky behavior, and one that can
>>> >  consume needless resources finding out it doesn't build, and more
>>> >  importantly waste your co-worker's time undoing it.
>>> >  We have the ability to prevent that, and we should.
>> I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a_bad_  thing).
>> 
> 
> We need to be careful here. We have the ability to totally overload any reasonable build system, and going through a full build and test for what are sometimes small changes may be impractical (having 100+ developers waiting for the build queue is also a _bad_ thing.)
> 
> As Joe Darcy often points out, we need to be careful that we are not so afraid of doing anything bad that we prevent anything good from happening.
> 
> Note, I am /not/ saying we don't need a good build and test system.  We do.  We just need to be careful how we mandate its use.
> 
> -- Jon

Totally agree Jon, it's a balancing act, we do what makes sense and what gives us the best chance of keeping
poison or broken changesets from getting into circulation. We cannot run all the tests all the time.

I also think that extremely low or no risk changes need not follow this rule, but the problem is getting people
to agree with 'no risk changes' are. I've seen enough 'low risk' changes bring the house down that I'm on the
paranoid side. :^(

-kto



From jonathan.gibbons at oracle.com  Mon Jan 30 23:43:27 2012
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 30 Jan 2012 15:43:27 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <BF58B82B-A1D6-4E53-A6F6-0E297F23B65F@oracle.com>
References: <4F21206A.1040907@oracle.com>
	<4F213E19.90508@oracle.com>	<4F2140E0.5040802@oracle.com>
	<4F21CBF2.1040407@oracle.com>	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>	<4F25BF64.6070802@oracle.com>
	<20262.520.379715.707949@oracle.com>	<4F265E5E.3010308@oracle.com>
	<4F266A4E.9030902@oracle.com>	<59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>
	<4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>
	<4F26DB40.9090300@oracle.com>
	<BF58B82B-A1D6-4E53-A6F6-0E297F23B65F@oracle.com>
Message-ID: <4F272B1F.3090904@oracle.com>

On 01/30/2012 03:41 PM, Kelly O'Hair wrote:
> I also think that extremely low or no risk changes need not follow this rule, but the problem is getting people
> to agree with 'no risk changes' are. I've seen enough 'low risk' changes bring the house down that I'm on the
> paranoid side. :^(

How does the saying go:
     Just because you're paranoid doesn't mean that folk won't break the 
build?

;-)

-- Jon


From david.holmes at oracle.com  Tue Jan 31 00:50:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 10:50:27 +1000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F26B283.8090103@oracle.com>
References: <4F26B283.8090103@oracle.com>
Message-ID: <4F273AD3.5070207@oracle.com>

On 31/01/2012 1:08 AM, Alan Bateman wrote:
>
> The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
> to remove the JAX-WS dependency on apt and the com.sun.mirror API:
>
> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>
> This is needed before Joe Darcy can wield his machete.
>
> Please cc'ed Miran and Martin on my review comments.

One question: how does this change:

jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip

impact day to day builds? Do we need to have some internal locations 
updated with this new zip file? JPRT?

Thanks,
David

> -Alan.


From david.holmes at oracle.com  Tue Jan 31 00:57:18 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 10:57:18 +1000
Subject: Patch to fix build breakage with GCC 4.7
In-Reply-To: <20120130152052.GE3179@redhat.com>
References: <20120130152052.GE3179@redhat.com>
Message-ID: <4F273C6E.30801@oracle.com>

Hi Deepak,

The primary change here is a build change so I've cc'ed build-dev.

The majority of the changes are to JVMTI demo files hence I've cc'd 
serviceability-dev.

I think JDK8-dev doesn't need to be included now so I've bcc'd it.

While gcc compilation on sparc is rare I'm not sure that simply deleting 
the sparc-only option unconditionally is the right thing to do.

David

On 31/01/2012 1:20 AM, Deepak Bhole wrote:
> Hi,
>
> JDK builds currently fail with GCC 4.7 due to its stricter option
> checking.
>
> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain
> files in JDK supply the -mimpure-text option to GCC. This option is only
> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build
> on Linux (I suppose .
>
> This patch removes the option:
> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00
>
> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
>
> If OK for push, please feel free to do so (I don't have commit access).
>
> Cheers,
> Deepak


From joe.darcy at oracle.com  Tue Jan 31 01:12:50 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 17:12:50 -0800
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F273AD3.5070207@oracle.com>
References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com>
Message-ID: <4F274012.7090904@oracle.com>

On 01/30/2012 04:50 PM, David Holmes wrote:
> On 31/01/2012 1:08 AM, Alan Bateman wrote:
>>
>> The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
>> to remove the JAX-WS dependency on apt and the com.sun.mirror API:
>>
>> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>>
>> This is needed before Joe Darcy can wield his machete.
>>
>> Please cc'ed Miran and Martin on my review comments.
>
> One question: how does this change:
>
> jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip
>
> impact day to day builds? Do we need to have some internal locations 
> updated with this new zip file? JPRT?
>

Yes, there is an Oracle-internal directory location where the zip files 
are stored and where the build looks for the files by default.  
Otherwise, for a build outside of Oracle, you can run with 
ALLOW_DOWNLOADS=true or download the file into a directory named by the 
the DROPS_DIR variable (which is what I do for my builds).

-Joe


From david.holmes at oracle.com  Tue Jan 31 01:17:58 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 11:17:58 +1000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F274012.7090904@oracle.com>
References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com>
	<4F274012.7090904@oracle.com>
Message-ID: <4F274146.9050103@oracle.com>

On 31/01/2012 11:12 AM, Joe Darcy wrote:
> On 01/30/2012 04:50 PM, David Holmes wrote:
>> On 31/01/2012 1:08 AM, Alan Bateman wrote:
>>>
>>> The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
>>> to remove the JAX-WS dependency on apt and the com.sun.mirror API:
>>>
>>> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>>>
>>> This is needed before Joe Darcy can wield his machete.
>>>
>>> Please cc'ed Miran and Martin on my review comments.
>>
>> One question: how does this change:
>>
>> jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip
>>
>> impact day to day builds? Do we need to have some internal locations
>> updated with this new zip file? JPRT?
>>
>
> Yes, there is an Oracle-internal directory location where the zip files
> are stored and where the build looks for the files by default.

Okay. So as part of this will the new zip file be installed before the 
change gets pushed?

Thanks,
David

> Otherwise, for a build outside of Oracle, you can run with
> ALLOW_DOWNLOADS=true or download the file into a directory named by the
> the DROPS_DIR variable (which is what I do for my builds).
>
> -Joe


From kelly.ohair at oracle.com  Tue Jan 31 01:23:06 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 30 Jan 2012 17:23:06 -0800
Subject: RFR: 7133124 Remove redundant packages from JAR command line
In-Reply-To: <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>
References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com>
	<4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com>
	<B9199527-AA65-4295-8B59-A99082558435@oracle.com>
	<F55BB6D5-B5BE-44B5-BB0E-CB147DD668EE@oracle.com>
	<4E51D843-A417-422C-9207-DF130D605DCC@oracle.com>
	<7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com>
	<63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com>
	<13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com>
	<4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com>
	<4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com>
	<59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com>
	<4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default>
Message-ID: <E254D1E7-06F3-4B44-9BA4-120CB8C0931B@oracle.com>


On Jan 30, 2012, at 9:41 AM, Robert Ottenhag wrote:

> Inline,
> 
>> -----Original Message-----
>> From: Kelly O'Hair
>> Sent: Monday, January 30, 2012 6:27 PM
>> To: Robert Ottenhag
>> Cc: Dmitry Samersoff; serviceability-dev at openjdk.java.net; John Coomes;
>> build-dev at openjdk.java.net
>> Subject: Re: RFR: 7133124 Remove redundant packages from JAR command line
>> 
>> Diverged and in transit to another planet. :^(
>> 
>> A push to a shared repo without verifying it builds on all supported
>> platforms is risky behavior, and one that can
>> consume needless resources finding out it doesn't build, and more
>> importantly waste your co-worker's time undoing it.
>> We have the ability to prevent that, and we should.
> 
> I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a _bad_ thing).
> 
>> And the JDK is not just a VM, and cross compilation does not address
>> Windows or Solaris.
> 
> It does not, but it can limit the number of build platforms that need to be maintained. See also my suggestion on an open JRPT queue and preconfigured virtual machines for build and test. Windows and Linux should cross build 32_to_64bit and 64_to_32bit, and Solaris can be helped by a virtual box installation of Solaris/{i586,x64}.

32 to 64 may be a problem. As much as I have tried to keep the build just a build, we continue to run what we build
in order to create the build. This will happen more going forward unfortunately, impacting our ability to cross compile
on platforms that can't run what you are building. The current thinking is that an initial build for the host would be
done first, and then that would be used to create the cross compiled build. But that's all up in the air, depends on
when the jigsaw and jdk modularization work starts showing up in jdk8.

In general Solaris has always been an x64 system where you build both. There really is no Solaris 32bit systems used anymore.
I'd like to change it so that there is just one pass, and both 32bit and 64bit native pieces are created at the same time.
Dito for Linux and Windows, e.g. you just build Windows, or Linux, or Solaris.
But if you are limited, i.e. running on a 32bit system, you only build 32bit.

I'm of the opinion that most desktop systems will be 64bit, or should be.

> 
>> This is a much more difficult situation than most people think it is.
>> Yes we can change things to simplify it, make it better, but don't kid
>> yourself, this is more complex than most people think.
> 
> True, but aiming for simpler and better is always beneficial.

Simpler is better, I agree.

> 
>> 
>> Anyone that hasn't built the entire JDK on Windows, successfully, should
>> try it.
> 
> I have ;-)

I did not know you had the jdk windows merit badge, congrads, or is it 'my sympathies'. ;^)

-kto

> 
> /Robert
> 
>> 
>> -kto
>> 
>> On Jan 30, 2012, at 2:00 AM, Robert Ottenhag wrote:
>> 
>>> Dmitry,
>>> 
>>> I think this discussion diverged somewhat from the original topic, but I
>> do agree with you that we must also attack the problem on a process level.
>>> 
>>> With the model you propose (and also the existing model) I would also
>> like to stress the need for continuous and automatic builds triggered by
>> incoming new changes compared to the last working change. Having that, it
>> is possible to update labels (tags) for "last_clean_build",
>> "last_nightly_build", etc. That way any build breakage would only be
>> visible at the tip.
>>> 
>>> However, when submitting a new change care should be taken to do it
>> against a working tip, that it builds and tests correctly (personal check-
>> in testing). Actually, this is close to the model we had for the JRockit
>> source base. WLS also uses the model of sliding labels for
>> "last_clean_build" where developers most often only do partial builds
>> themselves.
>>> 
>>> Regarding external committers, I think they need both the option of
>> building and testing locally, as well as access to an Open JDK specific
>> queue for build and test submissions.
>>> 
>>> By making use of cross compilation and open tools it is possible to at
>> least verify that the product builds locally. Even better is to also
>> supply preconfigured VMs with the necessary standard build and test
>> environment (e.g. obsolete Solaris or Linux distros that we require). In
>> general, having a build and test setup that is automatically configurable
>> (including Windows) will help both internal and external developers (see
>> also the build-infra project).
>>> 
>>> /Robert
>>> 
>>> On 01/30/2012 10:09 AM, Dmitry Samersoff wrote:
>>>> John,
>>>> 
>>>> Actually the goal of my letter is not to promote new integration
>> scheme. Just to remind that we need to put some efforts to internal
>> process review and optimization.
>>>> 
>>>> But, see answers below (inline):
>>>> 
>>>> Integration method I mentioned often used in open source projects,
>>>> because it doesn't require any special infrastructure for external
>> commiters. The only necessary thing to do safe commit is a write access to
>> integration (-gate) workspace.
>>>> 
>>>> On 2012-01-30 06:35, John Coomes wrote:
>>>>>> We have chosen a model:
>>>>>> 
>>>>>> build->test->integrate
>>>>>> 
>>>>>> but we may consider different approach:
>>>>>> 
>>>>>> integrate->build->test->[backout if necessary]
>>>>> 
>>>>> In that model, you can never rely on the repository having any degree
>>>>> of stability.  It may not even build at a given moment.
>>>> 
>>>> What happens today if Developer A and Developer B changes the same line
>> of a source?
>>>> 
>>>> What happens today if Developer A changes some_func() but Developer B
>>>> rely on some_func() ?
>>>> 
>>>> We would get a fault *after* all integration tests and SQE file one
>> more nightly bug. To the time someone investigate it and give the fix, bad
>> code will be distributed to all dev workspaces.
>>>> 
>>>> 
>>>>>>  Developer (A) integrate his changeset to an integration workspace
>>>>>>  Bot takes snapshot and start building/testing
>>>>>>  Developer (B) integrate his changeset to an integration workspace
>>>>>>  Bot takes snapshot and start building/testing
>>>>>> 
>>>>>>  if Job A failed, bot lock integration ws, restore it to pre-A
>> state,
>>>>>>  apply B-patch. unlock ws.
>>>>> 
>>>>> Don't forget the trusting souls that pulled from the integration repo
>>>>> after A inflicted the breakage:  they each waste time cleaning up a
>>>>> copy of A's mess.
>>>> 
>>>> Nobody pulls from -gate repository today and nobody expected to do it.
>>>> -gate to ws merge continues as usual.
>>>> 
>>>> To remove faulty changeset we need about fifteen minutes for whole jdk
>> at worst.
>>>> 
>>>> -Dmitry
>>>> 
>>>>> 
>>>>> -John
>>>>> 
>>>>>> On 2012-01-29 23:52, Kelly O'Hair wrote:
>>>>>>> 
>>>>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote:
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I'm missing something. How can everybody using the exact same
>> system
>>>>>>>>> scale to 100's of developers?
>>>>>>>> 
>>>>>>>> System = distributed build and test of OpenJDK
>>>>>>> 
>>>>>>> Ah ha...   I'm down in the trenches dealing with dozens of different
>>>>>>> OS's arch's variation machines.
>>>>>>> You are speaking to a higher level, I need to crawl out of the
>> basement.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Developers send in jobs
>>>>>>>> Jobs are distribute across a pool of (HW/OS) resources
>>>>>>>> The resources may be divided into pools dedicated to different
>> tasks
>>>>>>>> (RE/checkin/perf/stress)
>>>>>>>> The pools are populated initially according to predictions of load
>> and
>>>>>>>> then increased/rebalanced according to data on actual usage
>>>>>>>> No assumptions made about what exists on the machine other than
>> HW/OS
>>>>>>>> The build and test tasks are self sufficient, i.e. bootstrap
>> themselves
>>>>>>>> The bootstrapping is done in the same way for different build and
>> test
>>>>>>>> tasks
>>>>>>> 
>>>>>>> Understood. We have talked about this before.  I have also been on
>> the
>>>>>>> search for the Holy Grail. ;^)
>>>>>>> This is why I keep working on JPRT.
>>>>>>> 
>>>>>>>> 
>>>>>>>> The only scaling aspect that seems at all challenging is that the
>>>>>>>> current checkin system is designed to serialize checkins in a way
>> that
>>>>>>>> apparently does not scale -- here there are some decisions to be
>> made
>>>>>>>> and tradeoffs but this is nothing new in the world of Open
>> community
>>>>>>>> development (or any large team development for that matter)
>>>>>>> 
>>>>>>> The serialize checkins issue can be minimized some by using
>> distributed
>>>>>>> SCMs (Mercurial, Git, etc)
>>>>>>> and using separate forests (fewer developers per source repository
>> means
>>>>>>> fewer merge/sync issues)
>>>>>>> and having an integrator merge into a master. This has proven to
>> work in
>>>>>>> many situations but it
>>>>>>> also creates delivery to master delays, especially if the
>> integration
>>>>>>> process is too heavyweight.
>>>>>>> 
>>>>>>> The JDK projects has been doing this for a long time, I'm sure many
>>>>>>> people have opinions as to how
>>>>>>> successful it is or isn't.
>>>>>>> 
>>>>>>> It is my opinion that merges/syncs are some of the most dangerous
>> things
>>>>>>> you can do to a source base,
>>>>>>> and anything we can do to avoid them is usually goodness, I don't
>> think
>>>>>>> you should scale this without some
>>>>>>> very great care.
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> And that one system will naturally change over time too, so unless
>>>>>>>>> you are able to prevent all change
>>>>>>>>> to a system (impossible with security updates etc) every use of
>> that
>>>>>>>>> 'same system' will be different.
>>>>>>>> 
>>>>>>>> Yes, but it is possible to control this update and have a staging
>>>>>>>> environment so you know that a HW/OS update will not break the
>>>>>>>> existing successful build when rolled out to the build/test farm.
>>>>>>> 
>>>>>>> Possible but not always easy. The auto updating of everything has
>>>>>>> increased significantly over the years,
>>>>>>> making it harder to control completely.
>>>>>>> 
>>>>>>> I've been doing this build&test stuff long enough to never expect
>>>>>>> anything to be 100% reliable.
>>>>>>> Hardware fails, software updates regress functionality, networks
>> become
>>>>>>> unreliable, humans trip over
>>>>>>> power cords, virus scanners break things, etc. It just happens, and
>>>>>>> often, it's not very predictable or reproducible.
>>>>>>> You can do lots of things to minimize issues, but at some point you
>> just
>>>>>>> have to accept a few risks because
>>>>>>> the alternative just isn't feasible or just can't happen with the
>>>>>>> resources we have.
>>>>>>> 
>>>>>>> -kto
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Dmitry Samersoff
>>>>>> Java Hotspot development team, SPB04
>>>>>> * There will come soft rains ...
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Oracle
>>> Robert Ottenhag | Senior Member of Technical Staff
>>> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161
>>> Oracle Java HotSpot Virtual Machine
>>> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
>>> 
>>> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-
>> 6746
>>> 
>>> Green Oracle
>>> 
>>> Oracle is committed to developing practices and products that help
>> protect the environment
>>> --
>>> 
>> 



From kelly.ohair at oracle.com  Tue Jan 31 01:29:28 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 30 Jan 2012 17:29:28 -0800
Subject: Patch to fix build breakage with GCC 4.7
In-Reply-To: <4F273C6E.30801@oracle.com>
References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com>
Message-ID: <52B55BCB-C670-4F08-8D12-DE6FC4A69E95@oracle.com>

This change looks fine to me.

It would be ok with me for this change to be pushed into the jdk8/build forest.
Once there, I can do a JPRT run to verify it, but I really don't seen any issue here.

-kto

On Jan 30, 2012, at 4:57 PM, David Holmes wrote:

> Hi Deepak,
> 
> The primary change here is a build change so I've cc'ed build-dev.
> 
> The majority of the changes are to JVMTI demo files hence I've cc'd serviceability-dev.
> 
> I think JDK8-dev doesn't need to be included now so I've bcc'd it.
> 
> While gcc compilation on sparc is rare I'm not sure that simply deleting the sparc-only option unconditionally is the right thing to do.
> 
> David
> 
> On 31/01/2012 1:20 AM, Deepak Bhole wrote:
>> Hi,
>> 
>> JDK builds currently fail with GCC 4.7 due to its stricter option
>> checking.
>> 
>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain
>> files in JDK supply the -mimpure-text option to GCC. This option is only
>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build
>> on Linux (I suppose .
>> 
>> This patch removes the option:
>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00
>> 
>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
>> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
>> 
>> If OK for push, please feel free to do so (I don't have commit access).
>> 
>> Cheers,
>> Deepak



From peter.brunet at oracle.com  Tue Jan 31 02:45:13 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 30 Jan 2012 20:45:13 -0600
Subject: How to handle a merge problem
Message-ID: <4F2755B9.6050305@oracle.com>

I just did the following:
sh ./get_source.sh

and got this:
<snip>
# cd ./jdk && hg pull -u
pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
searching for changes
adding changesets
adding manifests
adding file changes
added 563 changesets with 3123 changes to 2661 files (+1 heads)
not updating: crosses branches (merge branches or update --check to
force update)
# exit code 0

How do I fix this?  I haven't found instructions on the various OpenJDK
sites.

Pete


From david.holmes at oracle.com  Tue Jan 31 02:49:45 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 12:49:45 +1000
Subject: Patch to fix build breakage with GCC 4.7
In-Reply-To: <20120131023642.GO16474@redhat.com>
References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com>
	<20120131023642.GO16474@redhat.com>
Message-ID: <4F2756C9.4000304@oracle.com>

On 31/01/2012 12:36 PM, Deepak Bhole wrote:
> * David Holmes<david.holmes at oracle.com>  [2012-01-30 19:57]:
>> While gcc compilation on sparc is rare I'm not sure that simply
>> deleting the sparc-only option unconditionally is the right thing to
>> do.
>>
>
> I thought about that too. But I was unable to find info on OpenJDK +
> SPARC + Linux. Is that combination even supported? The README doesn't
> list it:
> http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE

Linux-sparc is not one of Oracle's supported OpenJDK platforms. However 
AFAIK there are people in the community building OpenJDK on Linux-sparc 
using the Zero interpreter. I don't know if this would affect them but 
it still seems to me that we should be careful not to break other 
people's builds.

David
-----

> The option seemed more like a relic from Solaris + SPARC config rather
> than a requirement for Linux + SPARC.



> Cheers,
> Deepak
>
>> David
>>
>> On 31/01/2012 1:20 AM, Deepak Bhole wrote:
>>> Hi,
>>>
>>> JDK builds currently fail with GCC 4.7 due to its stricter option
>>> checking.
>>>
>>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain
>>> files in JDK supply the -mimpure-text option to GCC. This option is only
>>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build
>>> on Linux (I suppose .
>>>
>>> This patch removes the option:
>>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00
>>>
>>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
>>> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
>>>
>>> If OK for push, please feel free to do so (I don't have commit access).
>>>
>>> Cheers,
>>> Deepak


From david.holmes at oracle.com  Tue Jan 31 02:56:38 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 12:56:38 +1000
Subject: How to handle a merge problem
In-Reply-To: <4F2755B9.6050305@oracle.com>
References: <4F2755B9.6050305@oracle.com>
Message-ID: <4F275866.9050605@oracle.com>

Pete,

On 31/01/2012 12:45 PM, Pete Brunet wrote:
> I just did the following:
> sh ./get_source.sh
>
> and got this:
> <snip>
> # cd ./jdk&&  hg pull -u
> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 563 changesets with 3123 changes to 2661 files (+1 heads)
> not updating: crosses branches (merge branches or update --check to
> force update)
> # exit code 0

This shouldn't be possible. get_source will first clone the repos then 
do a hg pull (why? Given it just cloned it!)

It may be that you were extremely unlucky and between the clone and the 
pull there was an integration push to the repo. Even so you shouldn't 
get multiple heads. ???

> How do I fix this?  I haven't found instructions on the various OpenJDK
> sites.

Delete the jdk repo and start again is all I can suggested to get back 
to a sane state.

David
-----

> Pete


From peter.brunet at oracle.com  Tue Jan 31 04:50:14 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Mon, 30 Jan 2012 22:50:14 -0600
Subject: How to handle a merge problem
In-Reply-To: <4F275866.9050605@oracle.com>
References: <4F2755B9.6050305@oracle.com> <4F275866.9050605@oracle.com>
Message-ID: <4F277306.5080206@oracle.com>

Hi David, It might help to know that I had pulled the code back in
September or so, made several changes, and then got diverted onto
another project for a while.  So now I'm trying to get back in sync with
the latest code.  The first thing I did was update my patch with hg
qrefresh and then from cygwin ran get_source to update the code.  So
it's quite possible I will have merge conflicts, but I don't know the
process to find and fix them in this case.  Or maybe I should start from
scratch, apply my patch and fix the issues that way.  I seem to remember
that the one time I did have a problem applying a patch to fresh clone I
was able to fix them.  -Pete

On 1/30/12 8:56 PM, David Holmes wrote:
> Pete,
>
> On 31/01/2012 12:45 PM, Pete Brunet wrote:
>> I just did the following:
>> sh ./get_source.sh
>>
>> and got this:
>> <snip>
>> # cd ./jdk&&  hg pull -u
>> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
>> searching for changes
>> adding changesets
>> adding manifests
>> adding file changes
>> added 563 changesets with 3123 changes to 2661 files (+1 heads)
>> not updating: crosses branches (merge branches or update --check to
>> force update)
>> # exit code 0
>
> This shouldn't be possible. get_source will first clone the repos then
> do a hg pull (why? Given it just cloned it!)
>
> It may be that you were extremely unlucky and between the clone and
> the pull there was an integration push to the repo. Even so you
> shouldn't get multiple heads. ???
>
>> How do I fix this?  I haven't found instructions on the various OpenJDK
>> sites.
>
> Delete the jdk repo and start again is all I can suggested to get back
> to a sane state.
>
> David
> -----
>
>> Pete


From david.holmes at oracle.com  Tue Jan 31 05:01:13 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 15:01:13 +1000
Subject: How to handle a merge problem
In-Reply-To: <4F277306.5080206@oracle.com>
References: <4F2755B9.6050305@oracle.com> <4F275866.9050605@oracle.com>
	<4F277306.5080206@oracle.com>
Message-ID: <4F277599.1030601@oracle.com>

On 31/01/2012 2:50 PM, Pete Brunet wrote:
> Hi David, It might help to know that I had pulled the code back in
> September or so, made several changes, and then got diverted onto
> another project for a while.  So now I'm trying to get back in sync with
> the latest code.  The first thing I did was update my patch with hg
> qrefresh and then from cygwin ran get_source to update the code.

AFAIK youshould  only ever use get_source once as it will do a clone 
followed by an update. Maybe subsequent clone attempt just cause an 
error and are ignored?

All you needed to do with issue the "hg pull -u" for each repo, which 
you could do with either the forest extension ("hg fpull") or using the 
make/scripts/hgforest.sh helper.

> it's quite possible I will have merge conflicts, but I don't know the
> process to find and fix them in this case.

If you do an update and there are conflicts then it won't update and 
will tell you to run hg merge. hg merge will then show you what 
conflicts there are and get you to resolve them. If you have the 
filemerge tool configured it will use the filemerge tool for that.

> Or maybe I should start from
> scratch, apply my patch and fix the issues that way.  I seem to remember
> that the one time I did have a problem applying a patch to fresh clone I
> was able to fix them.  -Pete

Might be easiest depending on how many files are in conflict.

David
-----


>
> On 1/30/12 8:56 PM, David Holmes wrote:
>> Pete,
>>
>> On 31/01/2012 12:45 PM, Pete Brunet wrote:
>>> I just did the following:
>>> sh ./get_source.sh
>>>
>>> and got this:
>>> <snip>
>>> # cd ./jdk&&   hg pull -u
>>> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
>>> searching for changes
>>> adding changesets
>>> adding manifests
>>> adding file changes
>>> added 563 changesets with 3123 changes to 2661 files (+1 heads)
>>> not updating: crosses branches (merge branches or update --check to
>>> force update)
>>> # exit code 0
>>
>> This shouldn't be possible. get_source will first clone the repos then
>> do a hg pull (why? Given it just cloned it!)
>>
>> It may be that you were extremely unlucky and between the clone and
>> the pull there was an integration push to the repo. Even so you
>> shouldn't get multiple heads. ???
>>
>>> How do I fix this?  I haven't found instructions on the various OpenJDK
>>> sites.
>>
>> Delete the jdk repo and start again is all I can suggested to get back
>> to a sane state.
>>
>> David
>> -----
>>
>>> Pete


From Dmitry.Samersoff at oracle.com  Tue Jan 31 07:15:05 2012
From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 31 Jan 2012 11:15:05 +0400
Subject: How to handle a merge problem
In-Reply-To: <4F277306.5080206@oracle.com>
References: <4F2755B9.6050305@oracle.com> <4F275866.9050605@oracle.com>
	<4F277306.5080206@oracle.com>
Message-ID: <4F2794F9.7060605@oracle.com>

Pete,

1. Do hg diff in your workspace, save the patch somewhere
2. Do hg fclone http://<openjdk_ws_your_need
3. Try to apply your patch

PS:
  Personally, I tried mq but don't find it useful

-Dmitry

On 2012-01-31 08:50, Pete Brunet wrote:
> Hi David, It might help to know that I had pulled the code back in
> September or so, made several changes, and then got diverted onto
> another project for a while.  So now I'm trying to get back in sync with
> the latest code.  The first thing I did was update my patch with hg
> qrefresh and then from cygwin ran get_source to update the code.  So
> it's quite possible I will have merge conflicts, but I don't know the
> process to find and fix them in this case.  Or maybe I should start from
> scratch, apply my patch and fix the issues that way.  I seem to remember
> that the one time I did have a problem applying a patch to fresh clone I
> was able to fix them.  -Pete
>
> On 1/30/12 8:56 PM, David Holmes wrote:
>> Pete,
>>
>> On 31/01/2012 12:45 PM, Pete Brunet wrote:
>>> I just did the following:
>>> sh ./get_source.sh
>>>
>>> and got this:
>>> <snip>
>>> # cd ./jdk&&   hg pull -u
>>> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
>>> searching for changes
>>> adding changesets
>>> adding manifests
>>> adding file changes
>>> added 563 changesets with 3123 changes to 2661 files (+1 heads)
>>> not updating: crosses branches (merge branches or update --check to
>>> force update)
>>> # exit code 0
>>
>> This shouldn't be possible. get_source will first clone the repos then
>> do a hg pull (why? Given it just cloned it!)
>>
>> It may be that you were extremely unlucky and between the clone and
>> the pull there was an integration push to the repo. Even so you
>> shouldn't get multiple heads. ???
>>
>>> How do I fix this?  I haven't found instructions on the various OpenJDK
>>> sites.
>>
>> Delete the jdk repo and start again is all I can suggested to get back
>> to a sane state.
>>
>> David
>> -----
>>
>>> Pete


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


From Alan.Bateman at oracle.com  Tue Jan 31 08:08:26 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Jan 2012 08:08:26 +0000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F274146.9050103@oracle.com>
References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com>
	<4F274012.7090904@oracle.com> <4F274146.9050103@oracle.com>
Message-ID: <4F27A17A.1020809@oracle.com>

On 31/01/2012 01:17, David Holmes wrote:
> :
> Okay. So as part of this will the new zip file be installed before the 
> change gets pushed?
Yes, that's right.

-Alan


From weijun.wang at oracle.com  Tue Jan 31 09:21:14 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 31 Jan 2012 17:21:14 +0800
Subject: How to handle a merge problem
In-Reply-To: <4F277306.5080206@oracle.com>
References: <4F2755B9.6050305@oracle.com> <4F275866.9050605@oracle.com>
	<4F277306.5080206@oracle.com>
Message-ID: <4F27B28A.9060103@oracle.com>

Maybe you should call "hg qpop -a" before pulling from the source.

I don't know how to fix a damaged repo, but you can always re-clone the 
repos to a new directory, and then copy your old .hg/patches directory 
to the new repo. Please do not copy the status file otherwise Mercurial 
might be confused. Then you should be able to qseries/qpush them.

Hope this helps.

-Max

On 01/31/2012 12:50 PM, Pete Brunet wrote:
> Hi David, It might help to know that I had pulled the code back in
> September or so, made several changes, and then got diverted onto
> another project for a while.  So now I'm trying to get back in sync with
> the latest code.  The first thing I did was update my patch with hg
> qrefresh and then from cygwin ran get_source to update the code.  So
> it's quite possible I will have merge conflicts, but I don't know the
> process to find and fix them in this case.  Or maybe I should start from
> scratch, apply my patch and fix the issues that way.  I seem to remember
> that the one time I did have a problem applying a patch to fresh clone I
> was able to fix them.  -Pete
>
> On 1/30/12 8:56 PM, David Holmes wrote:
>> Pete,
>>
>> On 31/01/2012 12:45 PM, Pete Brunet wrote:
>>> I just did the following:
>>> sh ./get_source.sh
>>>
>>> and got this:
>>> <snip>
>>> # cd ./jdk&&   hg pull -u
>>> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
>>> searching for changes
>>> adding changesets
>>> adding manifests
>>> adding file changes
>>> added 563 changesets with 3123 changes to 2661 files (+1 heads)
>>> not updating: crosses branches (merge branches or update --check to
>>> force update)
>>> # exit code 0
>>
>> This shouldn't be possible. get_source will first clone the repos then
>> do a hg pull (why? Given it just cloned it!)
>>
>> It may be that you were extremely unlucky and between the clone and
>> the pull there was an integration push to the repo. Even so you
>> shouldn't get multiple heads. ???
>>
>>> How do I fix this?  I haven't found instructions on the various OpenJDK
>>> sites.
>>
>> Delete the jdk repo and start again is all I can suggested to get back
>> to a sane state.
>>
>> David
>> -----
>>
>>> Pete


From fredrik.ohrstrom at oracle.com  Tue Jan 31 12:31:34 2012
From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=)
Date: Tue, 31 Jan 2012 13:31:34 +0100
Subject: Patch for: 7132779: build-infra merge: Enable ccache to work for
	most developer builds.
Message-ID: <4F27DF26.7060808@oracle.com>

Hello hotspot-runtime-dev and build-dev!

This is a patch to enable ccache to work for all builds,
not only builds where the build number has been explicitly set.

Webrev is here:

http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/

Exported hg patch is here:

http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch

Is it good enough, so that you can commit for me Robert?

Thanks!
//Fredrik



From ahughes at redhat.com  Tue Jan 31 15:18:20 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 31 Jan 2012 10:18:20 -0500 (EST)
Subject: Patch to fix build breakage with GCC 4.7
In-Reply-To: <4F2756C9.4000304@oracle.com>
Message-ID: <3f4e79e0-949e-4eaf-8320-1794e294bfc7@zmail16.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 31/01/2012 12:36 PM, Deepak Bhole wrote:
> > * David Holmes<david.holmes at oracle.com>  [2012-01-30 19:57]:
> >> While gcc compilation on sparc is rare I'm not sure that simply
> >> deleting the sparc-only option unconditionally is the right thing
> >> to
> >> do.
> >>
> >
> > I thought about that too. But I was unable to find info on OpenJDK
> > +
> > SPARC + Linux. Is that combination even supported? The README
> > doesn't
> > list it:
> > http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE
> 
> Linux-sparc is not one of Oracle's supported OpenJDK platforms.
> However
> AFAIK there are people in the community building OpenJDK on
> Linux-sparc
> using the Zero interpreter. I don't know if this would affect them
> but
> it still seems to me that we should be careful not to break other
> people's builds.
> 

Yes.  Including people in Fedora and Matthias Klose on Debian.

> David
> -----
> 
> > The option seemed more like a relic from Solaris + SPARC config
> > rather
> > than a requirement for Linux + SPARC.
> 
> 
> 
> > Cheers,
> > Deepak
> >
> >> David
> >>
> >> On 31/01/2012 1:20 AM, Deepak Bhole wrote:
> >>> Hi,
> >>>
> >>> JDK builds currently fail with GCC 4.7 due to its stricter option
> >>> checking.
> >>>
> >>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not.
> >>> Certain
> >>> files in JDK supply the -mimpure-text option to GCC. This option
> >>> is only
> >>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during
> >>> build
> >>> on Linux (I suppose .
> >>>
> >>> This patch removes the option:
> >>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00
> >>>
> >>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
> >>> 2:
> >>> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
> >>>
> >>> If OK for push, please feel free to do so (I don't have commit
> >>> access).
> >>>
> >>> Cheers,
> >>> Deepak
> 

-- 
Andrew :)

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

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From peter.brunet at oracle.com  Tue Jan 31 17:02:09 2012
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 31 Jan 2012 11:02:09 -0600
Subject: How to handle a merge problem
In-Reply-To: <4F277599.1030601@oracle.com>
References: <4F2755B9.6050305@oracle.com> <4F275866.9050605@oracle.com>
	<4F277306.5080206@oracle.com> <4F277599.1030601@oracle.com>
Message-ID: <4F281E91.4080904@oracle.com>

Thanks David, I did the following and with a simple 3 way merge fix on
one file I'm now back in sync.

cd ...\jdk
hg merge

Pete

On 1/30/12 11:01 PM, David Holmes wrote:
> On 31/01/2012 2:50 PM, Pete Brunet wrote:
>> Hi David, It might help to know that I had pulled the code back in
>> September or so, made several changes, and then got diverted onto
>> another project for a while.  So now I'm trying to get back in sync with
>> the latest code.  The first thing I did was update my patch with hg
>> qrefresh and then from cygwin ran get_source to update the code.
>
> AFAIK youshould  only ever use get_source once as it will do a clone
> followed by an update. Maybe subsequent clone attempt just cause an
> error and are ignored?
>
> All you needed to do with issue the "hg pull -u" for each repo, which
> you could do with either the forest extension ("hg fpull") or using
> the make/scripts/hgforest.sh helper.
>
>> it's quite possible I will have merge conflicts, but I don't know the
>> process to find and fix them in this case.
>
> If you do an update and there are conflicts then it won't update and
> will tell you to run hg merge. hg merge will then show you what
> conflicts there are and get you to resolve them. If you have the
> filemerge tool configured it will use the filemerge tool for that.
>
>> Or maybe I should start from
>> scratch, apply my patch and fix the issues that way.  I seem to remember
>> that the one time I did have a problem applying a patch to fresh clone I
>> was able to fix them.  -Pete
>
> Might be easiest depending on how many files are in conflict.
>
> David
> -----
>
>
>>
>> On 1/30/12 8:56 PM, David Holmes wrote:
>>> Pete,
>>>
>>> On 31/01/2012 12:45 PM, Pete Brunet wrote:
>>>> I just did the following:
>>>> sh ./get_source.sh
>>>>
>>>> and got this:
>>>> <snip>
>>>> # cd ./jdk&&   hg pull -u
>>>> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
>>>> searching for changes
>>>> adding changesets
>>>> adding manifests
>>>> adding file changes
>>>> added 563 changesets with 3123 changes to 2661 files (+1 heads)
>>>> not updating: crosses branches (merge branches or update --check to
>>>> force update)
>>>> # exit code 0
>>>
>>> This shouldn't be possible. get_source will first clone the repos then
>>> do a hg pull (why? Given it just cloned it!)
>>>
>>> It may be that you were extremely unlucky and between the clone and
>>> the pull there was an integration push to the repo. Even so you
>>> shouldn't get multiple heads. ???
>>>
>>>> How do I fix this?  I haven't found instructions on the various
>>>> OpenJDK
>>>> sites.
>>>
>>> Delete the jdk repo and start again is all I can suggested to get back
>>> to a sane state.
>>>
>>> David
>>> -----
>>>
>>>> Pete


From John.Coomes at oracle.com  Tue Jan 31 17:35:25 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Tue, 31 Jan 2012 09:35:25 -0800
Subject: How to handle a merge problem
In-Reply-To: <4F277599.1030601@oracle.com>
References: <4F2755B9.6050305@oracle.com> <4F275866.9050605@oracle.com>
	<4F277306.5080206@oracle.com> <4F277599.1030601@oracle.com>
Message-ID: <20264.9821.565425.83176@oracle.com>

David Holmes (david.holmes at oracle.com) wrote:
> On 31/01/2012 2:50 PM, Pete Brunet wrote:
> ...
> > Or maybe I should start from
> > scratch, apply my patch and fix the issues that way.  I seem to remember
> > that the one time I did have a problem applying a patch to fresh clone I
> > was able to fix them.  -Pete
> 
> Might be easiest depending on how many files are in conflict.

If you have committed changes and want to sync with the upstream repo,
the easiest way is to use the rebase extension (works best in hg 1.6
and later).  You have to enable rebase in your .hgrc file, then you
can run

	hg pull --rebase

It will invoke your merge tool to resolve conflicts if necessary, and
move your changesets to tip.

Given that you've already pulled, you can still rebase your changesets
so they are at tip, but you have to identify them and provide them on
the command line.  See 'hg help rebase.'

-John

> > On 1/30/12 8:56 PM, David Holmes wrote:
> >> Pete,
> >>
> >> On 31/01/2012 12:45 PM, Pete Brunet wrote:
> >>> I just did the following:
> >>> sh ./get_source.sh
> >>>
> >>> and got this:
> >>> <snip>
> >>> # cd ./jdk&&   hg pull -u
> >>> pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk
> >>> searching for changes
> >>> adding changesets
> >>> adding manifests
> >>> adding file changes
> >>> added 563 changesets with 3123 changes to 2661 files (+1 heads)
> >>> not updating: crosses branches (merge branches or update --check to
> >>> force update)
> >>> # exit code 0
> >>
> >> This shouldn't be possible. get_source will first clone the repos then
> >> do a hg pull (why? Given it just cloned it!)
> >>
> >> It may be that you were extremely unlucky and between the clone and
> >> the pull there was an integration push to the repo. Even so you
> >> shouldn't get multiple heads. ???
> >>
> >>> How do I fix this?  I haven't found instructions on the various OpenJDK
> >>> sites.
> >>
> >> Delete the jdk repo and start again is all I can suggested to get back
> >> to a sane state.
> >>
> >> David
> >> -----
> >>
> >>> Pete


From staffan.larsen at oracle.com  Tue Jan 31 19:53:52 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 31 Jan 2012 20:53:52 +0100
Subject: Patch for: 7132779: build-infra merge: Enable ccache to work for
	most developer builds.
In-Reply-To: <4F27DF26.7060808@oracle.com>
References: <4F27DF26.7060808@oracle.com>
Message-ID: <A2F1E31A-06EA-42FC-BEF1-4F7432796382@oracle.com>

Looks good, but where is the new jre_release_version() method used?

/Staffan

On 31 jan 2012, at 13:31, Fredrik ?hrstr?m wrote:

> Hello hotspot-runtime-dev and build-dev!
> 
> This is a patch to enable ccache to work for all builds,
> not only builds where the build number has been explicitly set.
> 
> Webrev is here:
> 
> http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/
> 
> Exported hg patch is here:
> 
> http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch
> 
> Is it good enough, so that you can commit for me Robert?
> 
> Thanks!
> //Fredrik
> 



From david.holmes at oracle.com  Tue Jan 31 21:38:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 01 Feb 2012 07:38:27 +1000
Subject: Patch for: 7132779: build-infra merge: Enable ccache to work
	for most developer builds.
In-Reply-To: <A2F1E31A-06EA-42FC-BEF1-4F7432796382@oracle.com>
References: <4F27DF26.7060808@oracle.com>
	<A2F1E31A-06EA-42FC-BEF1-4F7432796382@oracle.com>
Message-ID: <4F285F53.8070306@oracle.com>

On 1/02/2012 5:53 AM, Staffan Larsen wrote:
> Looks good, but where is the new jre_release_version() method used?

It's currently only used in some closed code. The new method avoids the 
need to make the JRE_RELEASE_VERSION define available to that closed code.

I don't understand the comment on the new method though. Not sure what 
stringstream has to do with this actual method.

Otherwise looks good to me. I'm assuming that the actual problem is the 
ccache compares the defines used for a compilation and so if the version 
string contains a timestamp and gets updated on each (incremental?) 
build then ccache thinks it has to recompile.

David
-----

> /Staffan
>
> On 31 jan 2012, at 13:31, Fredrik ?hrstr?m wrote:
>
>> Hello hotspot-runtime-dev and build-dev!
>>
>> This is a patch to enable ccache to work for all builds,
>> not only builds where the build number has been explicitly set.
>>
>> Webrev is here:
>>
>> http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/
>>
>> Exported hg patch is here:
>>
>> http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch
>>
>> Is it good enough, so that you can commit for me Robert?
>>
>> Thanks!
>> //Fredrik
>>
>


From dbhole at redhat.com  Tue Jan 31 02:36:42 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 30 Jan 2012 21:36:42 -0500
Subject: Patch to fix build breakage with GCC 4.7
In-Reply-To: <4F273C6E.30801@oracle.com>
References: <20120130152052.GE3179@redhat.com>
 <4F273C6E.30801@oracle.com>
Message-ID: <20120131023642.GO16474@redhat.com>

* David Holmes <david.holmes at oracle.com> [2012-01-30 19:57]:
> Hi Deepak,
> 
> The primary change here is a build change so I've cc'ed build-dev.
> 
> The majority of the changes are to JVMTI demo files hence I've cc'd
> serviceability-dev.
> 
> I think JDK8-dev doesn't need to be included now so I've bcc'd it.
> 
> While gcc compilation on sparc is rare I'm not sure that simply
> deleting the sparc-only option unconditionally is the right thing to
> do.
> 

Hi David,

I thought about that too. But I was unable to find info on OpenJDK +
SPARC + Linux. Is that combination even supported? The README doesn't
list it:
http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE

The option seemed more like a relic from Solaris + SPARC config rather
than a requirement for Linux + SPARC.

Cheers,
Deepak

> David
> 
> On 31/01/2012 1:20 AM, Deepak Bhole wrote:
> >Hi,
> >
> >JDK builds currently fail with GCC 4.7 due to its stricter option
> >checking.
> >
> >GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain
> >files in JDK supply the -mimpure-text option to GCC. This option is only
> >valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build
> >on Linux (I suppose .
> >
> >This patch removes the option:
> >http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00
> >
> >1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
> >2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
> >
> >If OK for push, please feel free to do so (I don't have commit access).
> >
> >Cheers,
> >Deepak


From dbhole at redhat.com  Tue Jan 31 15:23:37 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 31 Jan 2012 10:23:37 -0500
Subject: Patch to fix build breakage with GCC 4.7
In-Reply-To: <4F2756C9.4000304@oracle.com>
References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com>
	<20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com>
Message-ID: <20120131152335.GA7700@redhat.com>

* David Holmes <david.holmes at oracle.com> [2012-01-30 21:50]:
> On 31/01/2012 12:36 PM, Deepak Bhole wrote:
> >* David Holmes<david.holmes at oracle.com>  [2012-01-30 19:57]:
> >>While gcc compilation on sparc is rare I'm not sure that simply
> >>deleting the sparc-only option unconditionally is the right thing to
> >>do.
> >>
> >
> >I thought about that too. But I was unable to find info on OpenJDK +
> >SPARC + Linux. Is that combination even supported? The README doesn't
> >list it:
> >http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE
> 
> Linux-sparc is not one of Oracle's supported OpenJDK platforms.
> However AFAIK there are people in the community building OpenJDK on
> Linux-sparc using the Zero interpreter. I don't know if this would
> affect them but it still seems to me that we should be careful not
> to break other people's builds.
> 

Ah fair enough. If it is supported, the patch definitely needs to be
fixed. I will re-post.

Thanks for taking a look!

Deepak

> David
> -----
> 
> >The option seemed more like a relic from Solaris + SPARC config rather
> >than a requirement for Linux + SPARC.
> 
> 
> 
> >Cheers,
> >Deepak
> >
> >>David
> >>
> >>On 31/01/2012 1:20 AM, Deepak Bhole wrote:
> >>>Hi,
> >>>
> >>>JDK builds currently fail with GCC 4.7 due to its stricter option
> >>>checking.
> >>>
> >>>GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain
> >>>files in JDK supply the -mimpure-text option to GCC. This option is only
> >>>valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build
> >>>on Linux (I suppose .
> >>>
> >>>This patch removes the option:
> >>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00
> >>>
> >>>1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
> >>>2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
> >>>
> >>>If OK for push, please feel free to do so (I don't have commit access).
> >>>
> >>>Cheers,
> >>>Deepak