From nils.eliasson at oracle.com Wed May 1 20:41:17 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 01 May 2013 22:41:17 +0200 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <5176D417.3040202@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> Message-ID: <51817DED.2050603@oracle.com> Hi, Here is a patch that fixes so that it still works to create vcprojs, and also sets defaults for the debugger commands. I have verified with creating vcprojs and debugging hotspot in VS 2010. Works great except for an annoying pop-up that warns that the launcher doesn't have debug symbols (if the target jdk doesn't). It will still be some extra work for those using the commandlines plugin. All saved command lines need the be prepended with "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK set as executable to work. We should update the plugin to help with that. A big thank you to Christian T?rnqvist for the proposal! //Nils On 2013-04-23 20:33, Mikael Gerdin wrote: > > On 2013-04-23 20:28, Christian Thalinger wrote: >> >> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >> wrote: >> >>> As long as we fix it first and remove gamma after - I would love to >>> have some redundant code removed. I would fix it myself, I just >>> don't think I will have the time before I go on parental leave. >> >> First, I'm not removing it tomorrow. I expected a long discussion :-) >> >> What exactly is the problem with Visual Studio? Why can't you just >> run the java launcher instead? >> > > I don't know if there actually is a problem, but I don't think > anyone's actually tried to tell it to use the java launcher. > The VS project is automatically setup to launch "hotspot.exe" from the > IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT > (IIRC) which involves linking all the VM object files into the launcher. > > Nils, perhaps you can at least try this before you leave? > > /Mikael > >> -- Chris >> >>> >>> //Nils >>> >>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>> >>>> >>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>> Studio. >>>>> So removing gamma effectively kills the working environment for a >>>>> number >>>>> of people that use it daily. So I am strongly against removing it. >>>> >>>> Maybe the visual studio project generator could be updated to >>>> create a a "launch configuration" for launching java.exe from a JDK >>>> and use the XXaltJVM flag on to select the correct jvm.dll? >>>> >>>> I agree that we shouldn't break the visual studio project but >>>> currently there's nothing indicating that we can't fix it. >>>> >>>> >>>> /Mikael >>>> >>>>> >>>>> Most people working on Windows use Cygwin as the last resort since it >>>>> makes a lot of thing excruciatingly slow. >>>>> >>>>> //Nils >>>>> >>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>> wrote: >>>>>> >>>>>>> Chris, >>>>>>> >>>>>>> Just an observation and not a review. >>>>>>> >>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>> Am I missing something? >>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>> near >>>>>> me is one) I have no idea how people are using the gamma launcher on >>>>>> Windows (or the hotspot script for that matter). >>>>>> >>>>>> I presume most people doing debugging on the command line are >>>>>> already >>>>>> in cygwin? But I might be wrong. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>> >>>>>>>> 8008772: remove gamma launcher >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>> files. >>>>>>>> >>>>>>>> make/Makefile >>>>>>>> make/bsd/makefiles/launcher.make >>>>>>>> make/bsd/makefiles/vm.make >>>>>>>> make/hotspot.script >>>>>>>> make/linux/makefiles/launcher.make >>>>>>>> make/linux/makefiles/vm.make >>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>> make/solaris/makefiles/vm.make >>>>>>>> make/windows/makefiles/debug.make >>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>> make/windows/makefiles/launcher.make >>>>>>>> make/windows/makefiles/product.make >>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>> src/share/tools/launcher/java.c >>>>>>>> src/share/tools/launcher/java.h >>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>> >>>>>>>> This change removes the duplicated java launcher files (which were >>>>>>>> subject to bit-rot) and modifies the hotspot script to pick up the >>>>>>>> libjvm in the current build directory. >>>>>>>> >>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>> >>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772/build/linux_i486_compiler2/debug$ >>>>>>>> >>>>>>>> ./hotspot -gdb -version >>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) >>>>>>>> Copyright (C) 2010 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show >>>>>>>> copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>> For bug reporting instructions, please see: >>>>>>>> . >>>>>>>> Missing separate debuginfo for >>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binaries/linux-i586/bin/java >>>>>>>> >>>>>>>> >>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e31a3.debug >>>>>>>> >>>>>>>> >>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>> [Thread debugging using libthread_db enabled] >>>>>>>> [New Thread 0xf7fe4b70 (LWP 13459)] >>>>>>>> [Switching to Thread 0xf7fe4b70 (LWP 13459)] >>>>>>>> >>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, penv=0xf7fe4374, >>>>>>>> args=0xf7fe4364) >>>>>>>> at >>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/prims/jni.cpp:5062 >>>>>>>> >>>>>>>> >>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>> (gdb) break CompileBroker::compile_method >>>>>>>> Breakpoint 2 at 0xaef852: file >>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/compiler/compileBroker.cpp, >>>>>>>> >>>>>>>> line 1205. >>>>>>>> (gdb) c >>>>>>>> Continuing. >>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] >>>>>>>> [New Thread 0xb4398b70 (LWP 13461)] >>>>>>>> [New Thread 0xb41ffb70 (LWP 13462)] >>>>>>>> [New Thread 0xb3effb70 (LWP 13463)] >>>>>>>> [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] >>>>>>>> [New Thread 0xb38ffb70 (LWP 13466)] >>>>>>>> [New Thread 0xb36ffb70 (LWP 13467)] >>>>>>>> [New Thread 0xb34ffb70 (LWP 13468)] >>>>>>>> [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] >>>>>>>> [New Thread 0xb2effb70 (LWP 13471)] >>>>>>>> [New Thread 0xb2cffb70 (LWP 13472)] >>>>>>>> [New Thread 0xaf8e8b70 (LWP 13473)] >>>>>>>> [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] >>>>>>>> [New Thread 0xb3a7eb70 (LWP 13476)] >>>>>>>> [New Thread 0xaeeffb70 (LWP 13477)] >>>>>>>> [New Thread 0xaecffb70 (LWP 13478)] >>>>>>>> [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] >>>>>>>> java version "1.8.0-ea" >>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) >>>>>>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, >>>>>>>> mixed mode) >>>>>>>> [Thread 0xaeaffb70 (LWP 13480) exited] >>>>>>>> [Thread 0xb3a7eb70 (LWP 13476) exited] >>>>>>>> [Thread 0xaf8e8b70 (LWP 13473) exited] >>>>>>>> [Thread 0xf7fe4b70 (LWP 13459) exited] >>>>>>>> [Thread 0xb2cffb70 (LWP 13472) exited] >>>>>>>> [Thread 0xb2effb70 (LWP 13471) exited] >>>>>>>> [Thread 0xaecffb70 (LWP 13478) exited] >>>>>>>> [Thread 0xb387eb70 (LWP 13479) exited] >>>>>>>> [Thread 0xaeeffb70 (LWP 13477) exited] >>>>>>>> [Thread 0xb3c7eb70 (LWP 13475) exited] >>>>>>>> [Thread 0xb4156b70 (LWP 13474) exited] >>>>>>>> [Thread 0xb32ffb70 (LWP 13469) exited] >>>>>>>> [Thread 0xb34ffb70 (LWP 13468) exited] >>>>>>>> [Thread 0xb36ffb70 (LWP 13467) exited] >>>>>>>> [Thread 0xb38ffb70 (LWP 13466) exited] >>>>>>>> [Thread 0xb3affb70 (LWP 13465) exited] >>>>>>>> [Thread 0xb3cffb70 (LWP 13464) exited] >>>>>>>> [Thread 0xb3effb70 (LWP 13463) exited] >>>>>>>> [Thread 0xb41ffb70 (LWP 13462) exited] >>>>>>>> [Thread 0xb4398b70 (LWP 13461) exited] >>>>>>>> [Thread 0xf7f93b70 (LWP 13460) exited] >>>>>>>> [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>> >>>>>>>> Program exited normally. >>>>>>>> (gdb) >>>>>>>> >>>>>>>> >>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris_i486_compiler2/debug$ >>>>>>>> >>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>> dbx: warning: using the alternate init file: /home/cthaling/.dbxrc >>>>>>>> Reading java >>>>>>>> Reading ld.so.1 >>>>>>>> Reading libjli.so >>>>>>>> Reading libthread.so.1 >>>>>>>> Reading libdl.so.1 >>>>>>>> Reading libc.so.1 >>>>>>>> Reading libjvm.so >>>>>>>> Loaded loadobject: >>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debug/libjvm.so >>>>>>>> >>>>>>>> >>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_compiler2/debug >>>>>>>> >>>>>>>> -version >>>>>>>> (process id 29613) >>>>>>>> Reading libsocket.so.1 >>>>>>>> Reading libsched.so.1 >>>>>>>> Reading libm.so.1 >>>>>>>> Reading libCrun.so.1 >>>>>>>> Reading libdoor.so.1 >>>>>>>> Reading libdemangle.so.1 >>>>>>>> Reading libnsl.so.1 >>>>>>>> Reading libm.so.2 >>>>>>>> Reading libscf.so.1 >>>>>>>> Reading libuutil.so.1 >>>>>>>> Reading libgen.so.1 >>>>>>>> Reading libmd.so.1 >>>>>>>> Reading libmp.so.2 >>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>> "jni.cpp" >>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>> (2) stop in >>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandle,int,const >>>>>>>> >>>>>>>> char*,Thread*) >>>>>>>> (dbx) c >>>>>>>> Reading libverify.so >>>>>>>> Reading libjava.so >>>>>>>> Reading libzip.so >>>>>>>> java version "1.8.0-ea" >>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) >>>>>>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, >>>>>>>> mixed mode) >>>>>>>> >>>>>>>> execution completed, exit code is 0 >>>>>>>> (dbx) >>>>>>>> >>>>> >>> >> From vladimir.kozlov at oracle.com Wed May 1 21:21:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 May 2013 14:21:42 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <51817DED.2050603@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> Message-ID: <51818766.20604@oracle.com> Nils, I don't see attached patch or webrev link. thanks, Vladimir On 5/1/13 1:41 PM, Nils Eliasson wrote: > Hi, > > Here is a patch that fixes so that it still works to create vcprojs, and > also sets defaults for the debugger commands. > > I have verified with creating vcprojs and debugging hotspot in VS 2010. > Works great except for an annoying pop-up that warns that the launcher > doesn't have debug symbols (if the target jdk doesn't). > > It will still be some extra work for those using the commandlines > plugin. All saved command lines need the be prepended with > "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK > set as executable to work. We should update the plugin to help with that. > > A big thank you to Christian T?rnqvist for the proposal! > > //Nils > > > On 2013-04-23 20:33, Mikael Gerdin wrote: >> >> On 2013-04-23 20:28, Christian Thalinger wrote: >>> >>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>> wrote: >>> >>>> As long as we fix it first and remove gamma after - I would love to >>>> have some redundant code removed. I would fix it myself, I just >>>> don't think I will have the time before I go on parental leave. >>> >>> First, I'm not removing it tomorrow. I expected a long discussion :-) >>> >>> What exactly is the problem with Visual Studio? Why can't you just >>> run the java launcher instead? >>> >> >> I don't know if there actually is a problem, but I don't think >> anyone's actually tried to tell it to use the java launcher. >> The VS project is automatically setup to launch "hotspot.exe" from the >> IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >> (IIRC) which involves linking all the VM object files into the launcher. >> >> Nils, perhaps you can at least try this before you leave? >> >> /Mikael >> >>> -- Chris >>> >>>> >>>> //Nils >>>> >>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>> >>>>> >>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>> Studio. >>>>>> So removing gamma effectively kills the working environment for a >>>>>> number >>>>>> of people that use it daily. So I am strongly against removing it. >>>>> >>>>> Maybe the visual studio project generator could be updated to >>>>> create a a "launch configuration" for launching java.exe from a JDK >>>>> and use the XXaltJVM flag on to select the correct jvm.dll? >>>>> >>>>> I agree that we shouldn't break the visual studio project but >>>>> currently there's nothing indicating that we can't fix it. >>>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Most people working on Windows use Cygwin as the last resort since it >>>>>> makes a lot of thing excruciatingly slow. >>>>>> >>>>>> //Nils >>>>>> >>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>> wrote: >>>>>>> >>>>>>>> Chris, >>>>>>>> >>>>>>>> Just an observation and not a review. >>>>>>>> >>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>> Am I missing something? >>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>> near >>>>>>> me is one) I have no idea how people are using the gamma launcher on >>>>>>> Windows (or the hotspot script for that matter). >>>>>>> >>>>>>> I presume most people doing debugging on the command line are >>>>>>> already >>>>>>> in cygwin? But I might be wrong. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>> >>>>>>>>> 8008772: remove gamma launcher >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>> files. >>>>>>>>> >>>>>>>>> make/Makefile >>>>>>>>> make/bsd/makefiles/launcher.make >>>>>>>>> make/bsd/makefiles/vm.make >>>>>>>>> make/hotspot.script >>>>>>>>> make/linux/makefiles/launcher.make >>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>> make/windows/makefiles/product.make >>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>> >>>>>>>>> This change removes the duplicated java launcher files (which were >>>>>>>>> subject to bit-rot) and modifies the hotspot script to pick up the >>>>>>>>> libjvm in the current build directory. >>>>>>>>> >>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>> >>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772/build/linux_i486_compiler2/debug$ >>>>>>>>> >>>>>>>>> ./hotspot -gdb -version >>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) >>>>>>>>> Copyright (C) 2010 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> >>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show >>>>>>>>> copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>> For bug reporting instructions, please see: >>>>>>>>> . >>>>>>>>> Missing separate debuginfo for >>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binaries/linux-i586/bin/java >>>>>>>>> >>>>>>>>> >>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e31a3.debug >>>>>>>>> >>>>>>>>> >>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>> [Thread debugging using libthread_db enabled] >>>>>>>>> [New Thread 0xf7fe4b70 (LWP 13459)] >>>>>>>>> [Switching to Thread 0xf7fe4b70 (LWP 13459)] >>>>>>>>> >>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, penv=0xf7fe4374, >>>>>>>>> args=0xf7fe4364) >>>>>>>>> at >>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/prims/jni.cpp:5062 >>>>>>>>> >>>>>>>>> >>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>> (gdb) break CompileBroker::compile_method >>>>>>>>> Breakpoint 2 at 0xaef852: file >>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/compiler/compileBroker.cpp, >>>>>>>>> >>>>>>>>> line 1205. >>>>>>>>> (gdb) c >>>>>>>>> Continuing. >>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] >>>>>>>>> [New Thread 0xb4398b70 (LWP 13461)] >>>>>>>>> [New Thread 0xb41ffb70 (LWP 13462)] >>>>>>>>> [New Thread 0xb3effb70 (LWP 13463)] >>>>>>>>> [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] >>>>>>>>> [New Thread 0xb38ffb70 (LWP 13466)] >>>>>>>>> [New Thread 0xb36ffb70 (LWP 13467)] >>>>>>>>> [New Thread 0xb34ffb70 (LWP 13468)] >>>>>>>>> [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] >>>>>>>>> [New Thread 0xb2effb70 (LWP 13471)] >>>>>>>>> [New Thread 0xb2cffb70 (LWP 13472)] >>>>>>>>> [New Thread 0xaf8e8b70 (LWP 13473)] >>>>>>>>> [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] >>>>>>>>> [New Thread 0xb3a7eb70 (LWP 13476)] >>>>>>>>> [New Thread 0xaeeffb70 (LWP 13477)] >>>>>>>>> [New Thread 0xaecffb70 (LWP 13478)] >>>>>>>>> [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] >>>>>>>>> java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) >>>>>>>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, >>>>>>>>> mixed mode) >>>>>>>>> [Thread 0xaeaffb70 (LWP 13480) exited] >>>>>>>>> [Thread 0xb3a7eb70 (LWP 13476) exited] >>>>>>>>> [Thread 0xaf8e8b70 (LWP 13473) exited] >>>>>>>>> [Thread 0xf7fe4b70 (LWP 13459) exited] >>>>>>>>> [Thread 0xb2cffb70 (LWP 13472) exited] >>>>>>>>> [Thread 0xb2effb70 (LWP 13471) exited] >>>>>>>>> [Thread 0xaecffb70 (LWP 13478) exited] >>>>>>>>> [Thread 0xb387eb70 (LWP 13479) exited] >>>>>>>>> [Thread 0xaeeffb70 (LWP 13477) exited] >>>>>>>>> [Thread 0xb3c7eb70 (LWP 13475) exited] >>>>>>>>> [Thread 0xb4156b70 (LWP 13474) exited] >>>>>>>>> [Thread 0xb32ffb70 (LWP 13469) exited] >>>>>>>>> [Thread 0xb34ffb70 (LWP 13468) exited] >>>>>>>>> [Thread 0xb36ffb70 (LWP 13467) exited] >>>>>>>>> [Thread 0xb38ffb70 (LWP 13466) exited] >>>>>>>>> [Thread 0xb3affb70 (LWP 13465) exited] >>>>>>>>> [Thread 0xb3cffb70 (LWP 13464) exited] >>>>>>>>> [Thread 0xb3effb70 (LWP 13463) exited] >>>>>>>>> [Thread 0xb41ffb70 (LWP 13462) exited] >>>>>>>>> [Thread 0xb4398b70 (LWP 13461) exited] >>>>>>>>> [Thread 0xf7f93b70 (LWP 13460) exited] >>>>>>>>> [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>> >>>>>>>>> Program exited normally. >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris_i486_compiler2/debug$ >>>>>>>>> >>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>> dbx: warning: using the alternate init file: /home/cthaling/.dbxrc >>>>>>>>> Reading java >>>>>>>>> Reading ld.so.1 >>>>>>>>> Reading libjli.so >>>>>>>>> Reading libthread.so.1 >>>>>>>>> Reading libdl.so.1 >>>>>>>>> Reading libc.so.1 >>>>>>>>> Reading libjvm.so >>>>>>>>> Loaded loadobject: >>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debug/libjvm.so >>>>>>>>> >>>>>>>>> >>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_compiler2/debug >>>>>>>>> >>>>>>>>> -version >>>>>>>>> (process id 29613) >>>>>>>>> Reading libsocket.so.1 >>>>>>>>> Reading libsched.so.1 >>>>>>>>> Reading libm.so.1 >>>>>>>>> Reading libCrun.so.1 >>>>>>>>> Reading libdoor.so.1 >>>>>>>>> Reading libdemangle.so.1 >>>>>>>>> Reading libnsl.so.1 >>>>>>>>> Reading libm.so.2 >>>>>>>>> Reading libscf.so.1 >>>>>>>>> Reading libuutil.so.1 >>>>>>>>> Reading libgen.so.1 >>>>>>>>> Reading libmd.so.1 >>>>>>>>> Reading libmp.so.2 >>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>> "jni.cpp" >>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>> (2) stop in >>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandle,int,const >>>>>>>>> >>>>>>>>> char*,Thread*) >>>>>>>>> (dbx) c >>>>>>>>> Reading libverify.so >>>>>>>>> Reading libjava.so >>>>>>>>> Reading libzip.so >>>>>>>>> java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) >>>>>>>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, >>>>>>>>> mixed mode) >>>>>>>>> >>>>>>>>> execution completed, exit code is 0 >>>>>>>>> (dbx) >>>>>>>>> >>>>>> >>>> >>> > From christian.tornqvist at oracle.com Wed May 1 21:30:44 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 1 May 2013 17:30:44 -0400 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <51818766.20604@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> Message-ID: <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> Hi Vladimir, Nils attached the patch to the email, but I've put the patch at http://cr.openjdk.java.net/~ctornqvi/webrev/vs.patch also Thanks, Christian -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: den 1 maj 2013 17:22 To: Nils Eliasson Cc: build-dev at openjdk.java.net; hotspot-dev developers; Christian Thalinger Subject: Re: RFR (M): 8008772: remove gamma launcher Nils, I don't see attached patch or webrev link. thanks, Vladimir On 5/1/13 1:41 PM, Nils Eliasson wrote: > Hi, > > Here is a patch that fixes so that it still works to create vcprojs, > and also sets defaults for the debugger commands. > > I have verified with creating vcprojs and debugging hotspot in VS 2010. > Works great except for an annoying pop-up that warns that the launcher > doesn't have debug symbols (if the target jdk doesn't). > > It will still be some extra work for those using the commandlines > plugin. All saved command lines need the be prepended with > "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK > set as executable to work. We should update the plugin to help with that. > > A big thank you to Christian T?rnqvist for the proposal! > > //Nils > > > On 2013-04-23 20:33, Mikael Gerdin wrote: >> >> On 2013-04-23 20:28, Christian Thalinger wrote: >>> >>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>> wrote: >>> >>>> As long as we fix it first and remove gamma after - I would love to >>>> have some redundant code removed. I would fix it myself, I just >>>> don't think I will have the time before I go on parental leave. >>> >>> First, I'm not removing it tomorrow. I expected a long discussion >>> :-) >>> >>> What exactly is the problem with Visual Studio? Why can't you just >>> run the java launcher instead? >>> >> >> I don't know if there actually is a problem, but I don't think >> anyone's actually tried to tell it to use the java launcher. >> The VS project is automatically setup to launch "hotspot.exe" from >> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >> (IIRC) which involves linking all the VM object files into the launcher. >> >> Nils, perhaps you can at least try this before you leave? >> >> /Mikael >> >>> -- Chris >>> >>>> >>>> //Nils >>>> >>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>> >>>>> >>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>> Studio. >>>>>> So removing gamma effectively kills the working environment for a >>>>>> number of people that use it daily. So I am strongly against >>>>>> removing it. >>>>> >>>>> Maybe the visual studio project generator could be updated to >>>>> create a a "launch configuration" for launching java.exe from a >>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>> >>>>> I agree that we shouldn't break the visual studio project but >>>>> currently there's nothing indicating that we can't fix it. >>>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Most people working on Windows use Cygwin as the last resort >>>>>> since it makes a lot of thing excruciatingly slow. >>>>>> >>>>>> //Nils >>>>>> >>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>> wrote: >>>>>>> >>>>>>>> Chris, >>>>>>>> >>>>>>>> Just an observation and not a review. >>>>>>>> >>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>> Am I missing something? >>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>> near me is one) I have no idea how people are using the gamma >>>>>>> launcher on Windows (or the hotspot script for that matter). >>>>>>> >>>>>>> I presume most people doing debugging on the command line are >>>>>>> already in cygwin? But I might be wrong. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>> >>>>>>>>> 8008772: remove gamma launcher >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>> files. >>>>>>>>> >>>>>>>>> make/Makefile >>>>>>>>> make/bsd/makefiles/launcher.make make/bsd/makefiles/vm.make >>>>>>>>> make/hotspot.script make/linux/makefiles/launcher.make >>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>> make/windows/makefiles/product.make >>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>> >>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>> were subject to bit-rot) and modifies the hotspot script to >>>>>>>>> pick up the libjvm in the current build directory. >>>>>>>>> >>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>> >>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772 >>>>>>>>> /build/linux_i486_compiler2/debug$ >>>>>>>>> >>>>>>>>> ./hotspot -gdb -version >>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) Copyright >>>>>>>>> (C) 2010 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> >>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>> "show copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>> For bug reporting instructions, please see: >>>>>>>>> . >>>>>>>>> Missing separate debuginfo for >>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binar >>>>>>>>> ies/linux-i586/bin/java >>>>>>>>> >>>>>>>>> >>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e >>>>>>>>> 31a3.debug >>>>>>>>> >>>>>>>>> >>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>> [Thread debugging using libthread_db enabled] [New Thread >>>>>>>>> 0xf7fe4b70 (LWP 13459)] [Switching to Thread 0xf7fe4b70 (LWP >>>>>>>>> 13459)] >>>>>>>>> >>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, >>>>>>>>> penv=0xf7fe4374, >>>>>>>>> args=0xf7fe4364) >>>>>>>>> at >>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/pri >>>>>>>>> ms/jni.cpp:5062 >>>>>>>>> >>>>>>>>> >>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>> (gdb) break CompileBroker::compile_method Breakpoint 2 at >>>>>>>>> 0xaef852: file >>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/com >>>>>>>>> piler/compileBroker.cpp, >>>>>>>>> >>>>>>>>> line 1205. >>>>>>>>> (gdb) c >>>>>>>>> Continuing. >>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] [New Thread 0xb4398b70 >>>>>>>>> (LWP 13461)] [New Thread 0xb41ffb70 (LWP 13462)] [New Thread >>>>>>>>> 0xb3effb70 (LWP 13463)] [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] [New Thread 0xb38ffb70 >>>>>>>>> (LWP 13466)] [New Thread 0xb36ffb70 (LWP 13467)] [New Thread >>>>>>>>> 0xb34ffb70 (LWP 13468)] [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] [New Thread 0xb2effb70 >>>>>>>>> (LWP 13471)] [New Thread 0xb2cffb70 (LWP 13472)] [New Thread >>>>>>>>> 0xaf8e8b70 (LWP 13473)] [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] [New Thread 0xb3a7eb70 >>>>>>>>> (LWP 13476)] [New Thread 0xaeeffb70 (LWP 13477)] [New Thread >>>>>>>>> 0xaecffb70 (LWP 13478)] [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>> mode) [Thread 0xaeaffb70 (LWP 13480) exited] [Thread >>>>>>>>> 0xb3a7eb70 (LWP 13476) exited] [Thread 0xaf8e8b70 (LWP 13473) >>>>>>>>> exited] [Thread 0xf7fe4b70 (LWP 13459) exited] [Thread >>>>>>>>> 0xb2cffb70 (LWP 13472) exited] [Thread 0xb2effb70 (LWP 13471) >>>>>>>>> exited] [Thread 0xaecffb70 (LWP 13478) exited] [Thread >>>>>>>>> 0xb387eb70 (LWP 13479) exited] [Thread 0xaeeffb70 (LWP 13477) >>>>>>>>> exited] [Thread 0xb3c7eb70 (LWP 13475) exited] [Thread >>>>>>>>> 0xb4156b70 (LWP 13474) exited] [Thread 0xb32ffb70 (LWP 13469) >>>>>>>>> exited] [Thread 0xb34ffb70 (LWP 13468) exited] [Thread >>>>>>>>> 0xb36ffb70 (LWP 13467) exited] [Thread 0xb38ffb70 (LWP 13466) >>>>>>>>> exited] [Thread 0xb3affb70 (LWP 13465) exited] [Thread >>>>>>>>> 0xb3cffb70 (LWP 13464) exited] [Thread 0xb3effb70 (LWP 13463) >>>>>>>>> exited] [Thread 0xb41ffb70 (LWP 13462) exited] [Thread >>>>>>>>> 0xb4398b70 (LWP 13461) exited] [Thread 0xf7f93b70 (LWP 13460) >>>>>>>>> exited] [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>> >>>>>>>>> Program exited normally. >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris >>>>>>>>> _i486_compiler2/debug$ >>>>>>>>> >>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>> /home/cthaling/.dbxrc Reading java Reading ld.so.1 Reading >>>>>>>>> libjli.so Reading libthread.so.1 Reading libdl.so.1 Reading >>>>>>>>> libc.so.1 Reading libjvm.so Loaded loadobject: >>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debu >>>>>>>>> g/libjvm.so >>>>>>>>> >>>>>>>>> >>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_comp >>>>>>>>> iler2/debug >>>>>>>>> >>>>>>>>> -version >>>>>>>>> (process id 29613) >>>>>>>>> Reading libsocket.so.1 >>>>>>>>> Reading libsched.so.1 >>>>>>>>> Reading libm.so.1 >>>>>>>>> Reading libCrun.so.1 >>>>>>>>> Reading libdoor.so.1 >>>>>>>>> Reading libdemangle.so.1 >>>>>>>>> Reading libnsl.so.1 >>>>>>>>> Reading libm.so.2 >>>>>>>>> Reading libscf.so.1 >>>>>>>>> Reading libuutil.so.1 >>>>>>>>> Reading libgen.so.1 >>>>>>>>> Reading libmd.so.1 >>>>>>>>> Reading libmp.so.2 >>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>> "jni.cpp" >>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>> (2) stop in >>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandl >>>>>>>>> e,int,const >>>>>>>>> >>>>>>>>> char*,Thread*) >>>>>>>>> (dbx) c >>>>>>>>> Reading libverify.so >>>>>>>>> Reading libjava.so >>>>>>>>> Reading libzip.so >>>>>>>>> java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>> mode) >>>>>>>>> >>>>>>>>> execution completed, exit code is 0 >>>>>>>>> (dbx) >>>>>>>>> >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Wed May 1 21:51:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 May 2013 14:51:03 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> Message-ID: <51818E47.1050605@oracle.com> Somehow I got Nils's mail without attachment. On 5/1/13 2:30 PM, Christian Tornqvist wrote: > Hi Vladimir, > > Nils attached the patch to the email, but I've put the patch at > http://cr.openjdk.java.net/~ctornqvi/webrev/vs.patch also This looks good. Christian Thalinger will be happy :) Thanks, Vladimir > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: den 1 maj 2013 17:22 > To: Nils Eliasson > Cc: build-dev at openjdk.java.net; hotspot-dev developers; Christian Thalinger > Subject: Re: RFR (M): 8008772: remove gamma launcher > > Nils, > > I don't see attached patch or webrev link. > > thanks, > Vladimir > > On 5/1/13 1:41 PM, Nils Eliasson wrote: >> Hi, >> >> Here is a patch that fixes so that it still works to create vcprojs, >> and also sets defaults for the debugger commands. >> >> I have verified with creating vcprojs and debugging hotspot in VS 2010. >> Works great except for an annoying pop-up that warns that the launcher >> doesn't have debug symbols (if the target jdk doesn't). >> >> It will still be some extra work for those using the commandlines >> plugin. All saved command lines need the be prepended with >> "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK >> set as executable to work. We should update the plugin to help with that. >> >> A big thank you to Christian T?rnqvist for the proposal! >> >> //Nils >> >> >> On 2013-04-23 20:33, Mikael Gerdin wrote: >>> >>> On 2013-04-23 20:28, Christian Thalinger wrote: >>>> >>>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>>> wrote: >>>> >>>>> As long as we fix it first and remove gamma after - I would love to >>>>> have some redundant code removed. I would fix it myself, I just >>>>> don't think I will have the time before I go on parental leave. >>>> >>>> First, I'm not removing it tomorrow. I expected a long discussion >>>> :-) >>>> >>>> What exactly is the problem with Visual Studio? Why can't you just >>>> run the java launcher instead? >>>> >>> >>> I don't know if there actually is a problem, but I don't think >>> anyone's actually tried to tell it to use the java launcher. >>> The VS project is automatically setup to launch "hotspot.exe" from >>> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >>> (IIRC) which involves linking all the VM object files into the launcher. >>> >>> Nils, perhaps you can at least try this before you leave? >>> >>> /Mikael >>> >>>> -- Chris >>>> >>>>> >>>>> //Nils >>>>> >>>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>>> >>>>>> >>>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>>> Studio. >>>>>>> So removing gamma effectively kills the working environment for a >>>>>>> number of people that use it daily. So I am strongly against >>>>>>> removing it. >>>>>> >>>>>> Maybe the visual studio project generator could be updated to >>>>>> create a a "launch configuration" for launching java.exe from a >>>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>>> >>>>>> I agree that we shouldn't break the visual studio project but >>>>>> currently there's nothing indicating that we can't fix it. >>>>>> >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> Most people working on Windows use Cygwin as the last resort >>>>>>> since it makes a lot of thing excruciatingly slow. >>>>>>> >>>>>>> //Nils >>>>>>> >>>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Chris, >>>>>>>>> >>>>>>>>> Just an observation and not a review. >>>>>>>>> >>>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>>> Am I missing something? >>>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>>> near me is one) I have no idea how people are using the gamma >>>>>>>> launcher on Windows (or the hotspot script for that matter). >>>>>>>> >>>>>>>> I presume most people doing debugging on the command line are >>>>>>>> already in cygwin? But I might be wrong. >>>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>>> >>>>>>>>>> 8008772: remove gamma launcher >>>>>>>>>> Reviewed-by: >>>>>>>>>> >>>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>>> files. >>>>>>>>>> >>>>>>>>>> make/Makefile >>>>>>>>>> make/bsd/makefiles/launcher.make make/bsd/makefiles/vm.make >>>>>>>>>> make/hotspot.script make/linux/makefiles/launcher.make >>>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>>> make/windows/makefiles/product.make >>>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>>> >>>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>>> were subject to bit-rot) and modifies the hotspot script to >>>>>>>>>> pick up the libjvm in the current build directory. >>>>>>>>>> >>>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>>> >>>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772 >>>>>>>>>> /build/linux_i486_compiler2/debug$ >>>>>>>>>> >>>>>>>>>> ./hotspot -gdb -version >>>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) Copyright >>>>>>>>>> (C) 2010 Free Software Foundation, Inc. >>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>> >>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>> "show copying" >>>>>>>>>> and "show warranty" for details. >>>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>>> For bug reporting instructions, please see: >>>>>>>>>> . >>>>>>>>>> Missing separate debuginfo for >>>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binar >>>>>>>>>> ies/linux-i586/bin/java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e >>>>>>>>>> 31a3.debug >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>>> [Thread debugging using libthread_db enabled] [New Thread >>>>>>>>>> 0xf7fe4b70 (LWP 13459)] [Switching to Thread 0xf7fe4b70 (LWP >>>>>>>>>> 13459)] >>>>>>>>>> >>>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, >>>>>>>>>> penv=0xf7fe4374, >>>>>>>>>> args=0xf7fe4364) >>>>>>>>>> at >>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/pri >>>>>>>>>> ms/jni.cpp:5062 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>>> (gdb) break CompileBroker::compile_method Breakpoint 2 at >>>>>>>>>> 0xaef852: file >>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/com >>>>>>>>>> piler/compileBroker.cpp, >>>>>>>>>> >>>>>>>>>> line 1205. >>>>>>>>>> (gdb) c >>>>>>>>>> Continuing. >>>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] [New Thread 0xb4398b70 >>>>>>>>>> (LWP 13461)] [New Thread 0xb41ffb70 (LWP 13462)] [New Thread >>>>>>>>>> 0xb3effb70 (LWP 13463)] [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] [New Thread 0xb38ffb70 >>>>>>>>>> (LWP 13466)] [New Thread 0xb36ffb70 (LWP 13467)] [New Thread >>>>>>>>>> 0xb34ffb70 (LWP 13468)] [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] [New Thread 0xb2effb70 >>>>>>>>>> (LWP 13471)] [New Thread 0xb2cffb70 (LWP 13472)] [New Thread >>>>>>>>>> 0xaf8e8b70 (LWP 13473)] [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] [New Thread 0xb3a7eb70 >>>>>>>>>> (LWP 13476)] [New Thread 0xaeeffb70 (LWP 13477)] [New Thread >>>>>>>>>> 0xaecffb70 (LWP 13478)] [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] java version "1.8.0-ea" >>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>> mode) [Thread 0xaeaffb70 (LWP 13480) exited] [Thread >>>>>>>>>> 0xb3a7eb70 (LWP 13476) exited] [Thread 0xaf8e8b70 (LWP 13473) >>>>>>>>>> exited] [Thread 0xf7fe4b70 (LWP 13459) exited] [Thread >>>>>>>>>> 0xb2cffb70 (LWP 13472) exited] [Thread 0xb2effb70 (LWP 13471) >>>>>>>>>> exited] [Thread 0xaecffb70 (LWP 13478) exited] [Thread >>>>>>>>>> 0xb387eb70 (LWP 13479) exited] [Thread 0xaeeffb70 (LWP 13477) >>>>>>>>>> exited] [Thread 0xb3c7eb70 (LWP 13475) exited] [Thread >>>>>>>>>> 0xb4156b70 (LWP 13474) exited] [Thread 0xb32ffb70 (LWP 13469) >>>>>>>>>> exited] [Thread 0xb34ffb70 (LWP 13468) exited] [Thread >>>>>>>>>> 0xb36ffb70 (LWP 13467) exited] [Thread 0xb38ffb70 (LWP 13466) >>>>>>>>>> exited] [Thread 0xb3affb70 (LWP 13465) exited] [Thread >>>>>>>>>> 0xb3cffb70 (LWP 13464) exited] [Thread 0xb3effb70 (LWP 13463) >>>>>>>>>> exited] [Thread 0xb41ffb70 (LWP 13462) exited] [Thread >>>>>>>>>> 0xb4398b70 (LWP 13461) exited] [Thread 0xf7f93b70 (LWP 13460) >>>>>>>>>> exited] [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>>> >>>>>>>>>> Program exited normally. >>>>>>>>>> (gdb) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris >>>>>>>>>> _i486_compiler2/debug$ >>>>>>>>>> >>>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>>> /home/cthaling/.dbxrc Reading java Reading ld.so.1 Reading >>>>>>>>>> libjli.so Reading libthread.so.1 Reading libdl.so.1 Reading >>>>>>>>>> libc.so.1 Reading libjvm.so Loaded loadobject: >>>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debu >>>>>>>>>> g/libjvm.so >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_comp >>>>>>>>>> iler2/debug >>>>>>>>>> >>>>>>>>>> -version >>>>>>>>>> (process id 29613) >>>>>>>>>> Reading libsocket.so.1 >>>>>>>>>> Reading libsched.so.1 >>>>>>>>>> Reading libm.so.1 >>>>>>>>>> Reading libCrun.so.1 >>>>>>>>>> Reading libdoor.so.1 >>>>>>>>>> Reading libdemangle.so.1 >>>>>>>>>> Reading libnsl.so.1 >>>>>>>>>> Reading libm.so.2 >>>>>>>>>> Reading libscf.so.1 >>>>>>>>>> Reading libuutil.so.1 >>>>>>>>>> Reading libgen.so.1 >>>>>>>>>> Reading libmd.so.1 >>>>>>>>>> Reading libmp.so.2 >>>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>>> "jni.cpp" >>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>>> (2) stop in >>>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandl >>>>>>>>>> e,int,const >>>>>>>>>> >>>>>>>>>> char*,Thread*) >>>>>>>>>> (dbx) c >>>>>>>>>> Reading libverify.so >>>>>>>>>> Reading libjava.so >>>>>>>>>> Reading libzip.so >>>>>>>>>> java version "1.8.0-ea" >>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>> mode) >>>>>>>>>> >>>>>>>>>> execution completed, exit code is 0 >>>>>>>>>> (dbx) >>>>>>>>>> >>>>>>> >>>>> >>>> >> > From tim.bell at oracle.com Wed May 1 22:03:14 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 01 May 2013 15:03:14 -0700 Subject: Somehow I got Nils's mail without attachment. [RFR (M): 8008772: remove gamma launcher] In-Reply-To: <51818E47.1050605@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> Message-ID: <51819122.5030109@oracle.com> Off topic (sorry) but as a mail.ojn list administrator, I can't help it. the attachment was not one of these MIME types: multipart/mixed multipart/alternative text/plain message/rfc822 As such, it was filtered (removed) by the mailing list. What is the MIME type of a .patch file? Maybe we can modify the filter rules to pass them through. Tim On 05/ 1/13 02:51 PM, Vladimir Kozlov wrote: > Somehow I got Nils's mail without attachment. > > On 5/1/13 2:30 PM, Christian Tornqvist wrote: >> Hi Vladimir, >> >> Nils attached the patch to the email, but I've put the patch at >> http://cr.openjdk.java.net/~ctornqvi/webrev/vs.patch also > > This looks good. Christian Thalinger will be happy :) > > Thanks, > Vladimir > >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >> Kozlov >> Sent: den 1 maj 2013 17:22 >> To: Nils Eliasson >> Cc: build-dev at openjdk.java.net; hotspot-dev developers; Christian >> Thalinger >> Subject: Re: RFR (M): 8008772: remove gamma launcher >> >> Nils, >> >> I don't see attached patch or webrev link. >> >> thanks, >> Vladimir >> >> On 5/1/13 1:41 PM, Nils Eliasson wrote: >>> Hi, >>> >>> Here is a patch that fixes so that it still works to create vcprojs, >>> and also sets defaults for the debugger commands. >>> >>> I have verified with creating vcprojs and debugging hotspot in VS 2010. >>> Works great except for an annoying pop-up that warns that the launcher >>> doesn't have debug symbols (if the target jdk doesn't). >>> >>> It will still be some extra work for those using the commandlines >>> plugin. All saved command lines need the be prepended with >>> "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK >>> set as executable to work. We should update the plugin to help with >>> that. >>> >>> A big thank you to Christian T?rnqvist for the proposal! >>> >>> //Nils >>> >>> >>> On 2013-04-23 20:33, Mikael Gerdin wrote: >>>> >>>> On 2013-04-23 20:28, Christian Thalinger wrote: >>>>> >>>>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>>>> wrote: >>>>> >>>>>> As long as we fix it first and remove gamma after - I would love to >>>>>> have some redundant code removed. I would fix it myself, I just >>>>>> don't think I will have the time before I go on parental leave. >>>>> >>>>> First, I'm not removing it tomorrow. I expected a long discussion >>>>> :-) >>>>> >>>>> What exactly is the problem with Visual Studio? Why can't you just >>>>> run the java launcher instead? >>>>> >>>> >>>> I don't know if there actually is a problem, but I don't think >>>> anyone's actually tried to tell it to use the java launcher. >>>> The VS project is automatically setup to launch "hotspot.exe" from >>>> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >>>> (IIRC) which involves linking all the VM object files into the >>>> launcher. >>>> >>>> Nils, perhaps you can at least try this before you leave? >>>> >>>> /Mikael >>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> //Nils >>>>>> >>>>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>>>> >>>>>>> >>>>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>>>> Studio. >>>>>>>> So removing gamma effectively kills the working environment for a >>>>>>>> number of people that use it daily. So I am strongly against >>>>>>>> removing it. >>>>>>> >>>>>>> Maybe the visual studio project generator could be updated to >>>>>>> create a a "launch configuration" for launching java.exe from a >>>>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>>>> >>>>>>> I agree that we shouldn't break the visual studio project but >>>>>>> currently there's nothing indicating that we can't fix it. >>>>>>> >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> Most people working on Windows use Cygwin as the last resort >>>>>>>> since it makes a lot of thing excruciatingly slow. >>>>>>>> >>>>>>>> //Nils >>>>>>>> >>>>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Chris, >>>>>>>>>> >>>>>>>>>> Just an observation and not a review. >>>>>>>>>> >>>>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>>>> Am I missing something? >>>>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>>>> near me is one) I have no idea how people are using the gamma >>>>>>>>> launcher on Windows (or the hotspot script for that matter). >>>>>>>>> >>>>>>>>> I presume most people doing debugging on the command line are >>>>>>>>> already in cygwin? But I might be wrong. >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>>>> >>>>>>>>>>> 8008772: remove gamma launcher >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> >>>>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>>>> files. >>>>>>>>>>> >>>>>>>>>>> make/Makefile >>>>>>>>>>> make/bsd/makefiles/launcher.make make/bsd/makefiles/vm.make >>>>>>>>>>> make/hotspot.script make/linux/makefiles/launcher.make >>>>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>>>> make/windows/makefiles/product.make >>>>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>>>> >>>>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>>>> were subject to bit-rot) and modifies the hotspot script to >>>>>>>>>>> pick up the libjvm in the current build directory. >>>>>>>>>>> >>>>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>>>> >>>>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772 >>>>>>>>>>> /build/linux_i486_compiler2/debug$ >>>>>>>>>>> >>>>>>>>>>> ./hotspot -gdb -version >>>>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) Copyright >>>>>>>>>>> (C) 2010 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> >>>>>>>>>>> This is free software: you are free to change and >>>>>>>>>>> redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>>>> For bug reporting instructions, please see: >>>>>>>>>>> . >>>>>>>>>>> Missing separate debuginfo for >>>>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binar >>>>>>>>>>> ies/linux-i586/bin/java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e >>>>>>>>>>> 31a3.debug >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>>>> [Thread debugging using libthread_db enabled] [New Thread >>>>>>>>>>> 0xf7fe4b70 (LWP 13459)] [Switching to Thread 0xf7fe4b70 (LWP >>>>>>>>>>> 13459)] >>>>>>>>>>> >>>>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, >>>>>>>>>>> penv=0xf7fe4374, >>>>>>>>>>> args=0xf7fe4364) >>>>>>>>>>> at >>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/pri >>>>>>>>>>> ms/jni.cpp:5062 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>>>> (gdb) break CompileBroker::compile_method Breakpoint 2 at >>>>>>>>>>> 0xaef852: file >>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/com >>>>>>>>>>> piler/compileBroker.cpp, >>>>>>>>>>> >>>>>>>>>>> line 1205. >>>>>>>>>>> (gdb) c >>>>>>>>>>> Continuing. >>>>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] [New Thread 0xb4398b70 >>>>>>>>>>> (LWP 13461)] [New Thread 0xb41ffb70 (LWP 13462)] [New Thread >>>>>>>>>>> 0xb3effb70 (LWP 13463)] [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] [New Thread 0xb38ffb70 >>>>>>>>>>> (LWP 13466)] [New Thread 0xb36ffb70 (LWP 13467)] [New Thread >>>>>>>>>>> 0xb34ffb70 (LWP 13468)] [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] [New Thread 0xb2effb70 >>>>>>>>>>> (LWP 13471)] [New Thread 0xb2cffb70 (LWP 13472)] [New Thread >>>>>>>>>>> 0xaf8e8b70 (LWP 13473)] [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] [New Thread 0xb3a7eb70 >>>>>>>>>>> (LWP 13476)] [New Thread 0xaeeffb70 (LWP 13477)] [New Thread >>>>>>>>>>> 0xaecffb70 (LWP 13478)] [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] java version "1.8.0-ea" >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>> mode) [Thread 0xaeaffb70 (LWP 13480) exited] [Thread >>>>>>>>>>> 0xb3a7eb70 (LWP 13476) exited] [Thread 0xaf8e8b70 (LWP 13473) >>>>>>>>>>> exited] [Thread 0xf7fe4b70 (LWP 13459) exited] [Thread >>>>>>>>>>> 0xb2cffb70 (LWP 13472) exited] [Thread 0xb2effb70 (LWP 13471) >>>>>>>>>>> exited] [Thread 0xaecffb70 (LWP 13478) exited] [Thread >>>>>>>>>>> 0xb387eb70 (LWP 13479) exited] [Thread 0xaeeffb70 (LWP 13477) >>>>>>>>>>> exited] [Thread 0xb3c7eb70 (LWP 13475) exited] [Thread >>>>>>>>>>> 0xb4156b70 (LWP 13474) exited] [Thread 0xb32ffb70 (LWP 13469) >>>>>>>>>>> exited] [Thread 0xb34ffb70 (LWP 13468) exited] [Thread >>>>>>>>>>> 0xb36ffb70 (LWP 13467) exited] [Thread 0xb38ffb70 (LWP 13466) >>>>>>>>>>> exited] [Thread 0xb3affb70 (LWP 13465) exited] [Thread >>>>>>>>>>> 0xb3cffb70 (LWP 13464) exited] [Thread 0xb3effb70 (LWP 13463) >>>>>>>>>>> exited] [Thread 0xb41ffb70 (LWP 13462) exited] [Thread >>>>>>>>>>> 0xb4398b70 (LWP 13461) exited] [Thread 0xf7f93b70 (LWP 13460) >>>>>>>>>>> exited] [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>>>> >>>>>>>>>>> Program exited normally. >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris >>>>>>>>>>> _i486_compiler2/debug$ >>>>>>>>>>> >>>>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>>>> /home/cthaling/.dbxrc Reading java Reading ld.so.1 Reading >>>>>>>>>>> libjli.so Reading libthread.so.1 Reading libdl.so.1 Reading >>>>>>>>>>> libc.so.1 Reading libjvm.so Loaded loadobject: >>>>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debu >>>>>>>>>>> g/libjvm.so >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_comp >>>>>>>>>>> iler2/debug >>>>>>>>>>> >>>>>>>>>>> -version >>>>>>>>>>> (process id 29613) >>>>>>>>>>> Reading libsocket.so.1 >>>>>>>>>>> Reading libsched.so.1 >>>>>>>>>>> Reading libm.so.1 >>>>>>>>>>> Reading libCrun.so.1 >>>>>>>>>>> Reading libdoor.so.1 >>>>>>>>>>> Reading libdemangle.so.1 >>>>>>>>>>> Reading libnsl.so.1 >>>>>>>>>>> Reading libm.so.2 >>>>>>>>>>> Reading libscf.so.1 >>>>>>>>>>> Reading libuutil.so.1 >>>>>>>>>>> Reading libgen.so.1 >>>>>>>>>>> Reading libmd.so.1 >>>>>>>>>>> Reading libmp.so.2 >>>>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>>>> "jni.cpp" >>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>>>> (2) stop in >>>>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandl >>>>>>>>>>> e,int,const >>>>>>>>>>> >>>>>>>>>>> char*,Thread*) >>>>>>>>>>> (dbx) c >>>>>>>>>>> Reading libverify.so >>>>>>>>>>> Reading libjava.so >>>>>>>>>>> Reading libzip.so >>>>>>>>>>> java version "1.8.0-ea" >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>> mode) >>>>>>>>>>> >>>>>>>>>>> execution completed, exit code is 0 >>>>>>>>>>> (dbx) >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From david.katleman at oracle.com Wed May 1 22:19:13 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 May 2013 22:19:13 +0000 Subject: hg: jdk8/build/hotspot: 51 new changesets Message-ID: <20130501222054.BD2FB4875B@hg.openjdk.java.net> Changeset: c60f69931e1a Author: amurillo Date: 2013-04-11 21:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c60f69931e1a 8011949: new hotspot build - hs25-b29 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 35f8765422b9 Author: zgu Date: 2013-04-10 08:55 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/35f8765422b9 8010151: nsk/regression/b6653214 fails "assert(snapshot != NULL) failed: Worker should not be started" Summary: Fixed a racing condition when shutting down NMT while worker thread is being started, also fixed a few mis-declared volatile pointers. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f2c0ccccc6b6 Author: rdurbin Date: 2013-04-16 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f2c0ccccc6b6 Merge Changeset: 71013d764f6e Author: johnc Date: 2013-04-10 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/71013d764f6e 8010780: G1: Eden occupancy/capacity output wrong after a full GC Summary: Move the calculation and recording of eden capacity to the start of a GC and print a detailed heap transition for full GCs. Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: c0000f77bc6d Author: johnc Date: 2013-04-11 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c0000f77bc6d Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9aa8d8037ee3 Author: mgerdin Date: 2013-04-16 12:46 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9aa8d8037ee3 Merge ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: df254344edf1 Author: jmasa Date: 2013-04-01 10:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/df254344edf1 8011173: NPG: Replace the ChunkList implementation with class FreeList Reviewed-by: mgerdin, tschatzl, johnc, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: f2e682ef3156 Author: johnc Date: 2013-04-17 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f2e682ef3156 8012335: G1: Fix bug with compressed oops in template interpreter on x86 and sparc. Summary: In do_oop_store the uncompressed value of the oop being stored needs to be preserved and passed to g1_write_barrier_post. This is necessary for the heap region cross check to work correctly. Reviewed-by: coleenp, johnc Contributed-by: Martin Doerr ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 07a4efc5ed14 Author: brutisso Date: 2013-04-18 06:50 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/07a4efc5ed14 8012455: Missing time and date stamps for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime Summary: also reviewed by: kirk at kodewerk.com, brandon at twitter.com Reviewed-by: tschatzl, stefank, johnc ! src/share/vm/services/runtimeService.cpp Changeset: cbf8c8c25bbe Author: mgerdin Date: 2013-04-18 14:38 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cbf8c8c25bbe Merge Changeset: aeaca88565e6 Author: jiangli Date: 2013-04-09 17:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aeaca88565e6 8010862: The Method counter fields used for profiling can be allocated lazily. Summary: Allocate the method's profiling related metadata until they are needed. Reviewed-by: coleenp, roland ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java + agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! 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/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp + src/share/vm/oops/methodCounters.cpp + src/share/vm/oops/methodCounters.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 42a42da29fd7 Author: jiangli Date: 2013-04-11 23:06 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/42a42da29fd7 8012052: java/lang/invoke/6987555/Test6987555.java crashes with assert(mcs != NULL) failed: MethodCounters cannot be NULL. Summary: Skip counter decay if the MethodCounters is NULL in NonTieredCompPolicy::delay_compilation(). Reviewed-by: kvn, dholmes ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 8df6ddda8090 Author: jiangli Date: 2013-04-15 21:25 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8df6ddda8090 Merge ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 9500809ceead Author: jiangli Date: 2013-04-18 17:00 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9500809ceead Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: b8b081e53312 Author: twisti Date: 2013-04-12 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b8b081e53312 8011933: add number of classes, methods and time spent to CompileTheWorld Reviewed-by: jrose, kvn ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 393fd4ef89c4 Author: twisti Date: 2013-04-12 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/393fd4ef89c4 8011678: test/Makefile should pick up JT_HOME environment variable Reviewed-by: kvn ! test/Makefile Changeset: f36e073d56a4 Author: drchase Date: 2013-04-12 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f36e073d56a4 7104565: trim jprt build targets Summary: remove JPRT debug builds, remove -DDEBUG -DFASTDEBUG and use ASSERT instead in sources Reviewed-by: dholmes, kvn, coleenp ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/fastdebug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/fastdebug.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/fastdebug.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make ! make/windows/build.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/hsdis/Makefile ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: bc63dd2539a4 Author: kvn Date: 2013-04-12 20:37 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bc63dd2539a4 Merge ! make/bsd/makefiles/debug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make ! make/linux/makefiles/debug.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make ! make/solaris/makefiles/debug.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make Changeset: 886d1fd67dc3 Author: drchase Date: 2013-04-12 19:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/886d1fd67dc3 6443505: Ideal() function for CmpLTMask Summary: Repair wrong code generation, added new matching rule Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/cfgnode.cpp + test/compiler/6443505/Test6443505.java Changeset: bb4a966cc68f Author: roland Date: 2013-04-15 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bb4a966cc68f 8011582: assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range Summary: c1 runtime's predicate_failed_trap should use jump_to on sparc Reviewed-by: kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 1c6887c9afaa Author: twisti Date: 2013-04-15 16:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1c6887c9afaa 7172922: export_ makefile targets do not work unless all supported variants are built Reviewed-by: dholmes, kvn ! make/Makefile Changeset: acadb114c818 Author: roland Date: 2013-04-15 17:17 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/acadb114c818 8011648: C1: optimized build is broken after 7153771 Summary: missing #ifdef ASSERT Reviewed-by: kvn ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: b105029fdbfd Author: roland Date: 2013-04-15 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b105029fdbfd Merge Changeset: 8373c19be854 Author: neliasso Date: 2013-04-16 10:08 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8373c19be854 8011621: live_ranges_in_separate_class.patch Reviewed-by: kvn, roland Contributed-by: niclas.adlertz at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c89eab0b6b30 Author: neliasso Date: 2013-04-16 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c89eab0b6b30 Merge - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 4b2eebe03f93 Author: iignatyev Date: 2013-04-16 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4b2eebe03f93 8011971: WB API doesn't accept j.l.reflect.Constructor Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: a7fb14888912 Author: neliasso Date: 2013-04-11 13:57 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a7fb14888912 8006952: Slow VM due to excessive code cache freelist iteration Summary: Remove continous free block requirement Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/opto/output.cpp Changeset: dedc8563e33d Author: bharadwaj Date: 2013-04-18 16:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dedc8563e33d Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 2a9d97b57920 Author: bharadwaj Date: 2013-04-19 03:13 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2a9d97b57920 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 01d5f04e64dc Author: amurillo Date: 2013-04-19 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/01d5f04e64dc Merge ! make/bsd/makefiles/fastdebug.make - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 0491c26b1f1d Author: amurillo Date: 2013-04-19 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0491c26b1f1d Added tag hs25-b29 for changeset 01d5f04e64dc ! .hgtags Changeset: f78763f49817 Author: amurillo Date: 2013-04-19 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f78763f49817 8012559: new hotspot build - hs25-b30 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63e31ce40bdb Author: hseigel Date: 2013-04-17 08:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/63e31ce40bdb 8009928: PSR:PERF Increase default string table size Summary: Increase default string table size to 60013 for 64-bit platforms. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b80cc96882f7 Author: zgu Date: 2013-04-18 10:04 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b80cc96882f7 8012464: NMT: classes should not derive from _ValueObj, use VALUE_OBJ_CLASS_SPEC instead Summary: NMT value objects should use VALUE_OBJ_CLASS_SPEC instead of deriving from _ValueObj Reviewed-by: coleenp, hseigel, dholmes ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.hpp Changeset: 41ed397cc0cd Author: bharadwaj Date: 2013-04-18 08:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/41ed397cc0cd 8006267: InterfaceMethod_ref should allow invokestatic and invokespecial Summary: Lambda changes; spec 0.6.2 - Allow static invokestatic and invokespecial calls to InterfaceMethod_ref Reviewed-by: dholmes, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/genericSignatures.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp Changeset: 7815eaceaa8c Author: bharadwaj Date: 2013-04-18 14:03 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7815eaceaa8c Merge Changeset: 6f817ce50129 Author: minqi Date: 2013-04-19 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6f817ce50129 8010992: Remove calls to global ::operator new[] and new Summary: disable use of global operator new and new[] which could cause unexpected exception and escape from NMT tracking. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 17c51f84773a Author: dcubed Date: 2013-04-19 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/17c51f84773a Merge Changeset: 5b6512efcdc4 Author: dcubed Date: 2013-04-19 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5b6512efcdc4 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6337ca4dcad8 Author: sspitsyn Date: 2013-04-20 04:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6337ca4dcad8 8008511: JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition Summary: Lazily create and maintain the MemberNameTable to be able to update MemberName's Reviewed-by: coleenp, jrose, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: a527ddd44e07 Author: mgronlun Date: 2013-04-20 19:02 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a527ddd44e07 6729929: I18N - Taking Heap Dump failed if project path contains multibyte characters Reviewed-by: dholmes, rbackman Contributed-by: peter.allwin at oracle.com ! src/share/vm/services/management.cpp Changeset: 5a9fa2ba85f0 Author: dcubed Date: 2013-04-21 20:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5a9fa2ba85f0 8012907: anti-delta fix for 8010992 Summary: anti-delta fix for 8010992 until 8012902 can be fixed Reviewed-by: acorn, minqi, rdurbin ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: cc12becb22e7 Author: dcubed Date: 2013-04-21 21:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cc12becb22e7 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce6d7e43501c Author: bharadwaj Date: 2013-04-23 08:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ce6d7e43501c 8012961: Do not restrict static interface methods to be private Summary: Lambda changes; spec 0.6.2 - remove the restriction that was added as part of recent changes made to support upcoming changes to compilation of lambda methods. Reviewed-by: dholmes, acorn ! src/share/vm/prims/methodHandles.cpp Changeset: 1ea6a35dcbe5 Author: jiangli Date: 2013-04-23 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1ea6a35dcbe5 8012927: 'assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range' in interpreter initialization. Summary: Change br_null_short() to br_null(). Reviewed-by: coleenp, hseigel ! src/cpu/sparc/vm/interp_masm_sparc.cpp Changeset: 35c15dad89ea Author: roland Date: 2013-04-16 17:06 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/35c15dad89ea 8011901: Unsafe.getAndAddLong(obj, off, delta) does not work properly with long deltas Summary: instruct xaddL_no_res shouldn't allow 64 bit constants. Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad + test/compiler/8011901/Test8011901.java Changeset: 6a3629cf7075 Author: roland Date: 2013-04-24 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6a3629cf7075 8011771: runThese crashed with EAV Summary: Array bound check elimination's in block motion doesn't always reset its data structures from one step to the other. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_RangeCheckElimination.cpp Changeset: 47766e2d2527 Author: jiangli Date: 2013-04-24 18:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/47766e2d2527 8013041: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset. Summary: Change jmpb() to jmp(). Reviewed-by: coleenp, rdurbin, dcubed ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: e8a7a5995e65 Author: bharadwaj Date: 2013-04-25 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e8a7a5995e65 Merge Changeset: c4af77d20454 Author: amurillo Date: 2013-04-26 00:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c4af77d20454 Merge ! .hgtags - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp Changeset: 8482058e74bc Author: amurillo Date: 2013-04-26 00:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8482058e74bc Added tag hs25-b30 for changeset c4af77d20454 ! .hgtags From david.katleman at oracle.com Wed May 1 22:22:42 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 01 May 2013 22:22:42 +0000 Subject: hg: jdk8/build/jdk: 4 new changesets Message-ID: <20130501222341.20F274875C@hg.openjdk.java.net> Changeset: 78d08fc2dd12 Author: mullan Date: 2013-04-25 11:18 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/78d08fc2dd12 8011313: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout not defined Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 3e282678a885 Author: mullan Date: 2013-04-25 15:48 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3e282678a885 8013228: Create new system properties to control allowable OCSP clock skew and CRL connection timeout Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java Changeset: 7c4eb715c5e8 Author: ngthomas Date: 2013-04-30 21:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7c4eb715c5e8 Merge Changeset: 55c7b90fe57e Author: katleman Date: 2013-05-01 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/55c7b90fe57e Merge From mikael.gerdin at oracle.com Thu May 2 07:27:20 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 02 May 2013 09:27:20 +0200 Subject: Somehow I got Nils's mail without attachment. [RFR (M): 8008772: remove gamma launcher] In-Reply-To: <51819122.5030109@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <51819122.5030109@oracle.com> Message-ID: <51821558.6080106@oracle.com> Tim, On 2013-05-02 00:03, Tim Bell wrote: > Off topic (sorry) but as a mail.ojn list administrator, I can't help it. > > the attachment was not one of these MIME types: > > multipart/mixed > multipart/alternative > text/plain > message/rfc822 > > As such, it was filtered (removed) by the mailing list. > > What is the MIME type of a .patch file? Maybe we can modify the filter > rules to pass them through. In Nils' mail the patch had the following header: Content-Type: text/x-patch; name="VS with JDK launcher.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="VS with JDK launcher.patch" I've also seen patches with MIME type text/x-diff /Mikael > > Tim > > > On 05/ 1/13 02:51 PM, Vladimir Kozlov wrote: >> Somehow I got Nils's mail without attachment. >> >> On 5/1/13 2:30 PM, Christian Tornqvist wrote: >>> Hi Vladimir, >>> >>> Nils attached the patch to the email, but I've put the patch at >>> http://cr.openjdk.java.net/~ctornqvi/webrev/vs.patch also >> >> This looks good. Christian Thalinger will be happy :) >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >>> Kozlov >>> Sent: den 1 maj 2013 17:22 >>> To: Nils Eliasson >>> Cc: build-dev at openjdk.java.net; hotspot-dev developers; Christian >>> Thalinger >>> Subject: Re: RFR (M): 8008772: remove gamma launcher >>> >>> Nils, >>> >>> I don't see attached patch or webrev link. >>> >>> thanks, >>> Vladimir >>> >>> On 5/1/13 1:41 PM, Nils Eliasson wrote: >>>> Hi, >>>> >>>> Here is a patch that fixes so that it still works to create vcprojs, >>>> and also sets defaults for the debugger commands. >>>> >>>> I have verified with creating vcprojs and debugging hotspot in VS 2010. >>>> Works great except for an annoying pop-up that warns that the launcher >>>> doesn't have debug symbols (if the target jdk doesn't). >>>> >>>> It will still be some extra work for those using the commandlines >>>> plugin. All saved command lines need the be prepended with >>>> "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK >>>> set as executable to work. We should update the plugin to help with >>>> that. >>>> >>>> A big thank you to Christian T?rnqvist for the proposal! >>>> >>>> //Nils >>>> >>>> >>>> On 2013-04-23 20:33, Mikael Gerdin wrote: >>>>> >>>>> On 2013-04-23 20:28, Christian Thalinger wrote: >>>>>> >>>>>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>>>>> wrote: >>>>>> >>>>>>> As long as we fix it first and remove gamma after - I would love to >>>>>>> have some redundant code removed. I would fix it myself, I just >>>>>>> don't think I will have the time before I go on parental leave. >>>>>> >>>>>> First, I'm not removing it tomorrow. I expected a long discussion >>>>>> :-) >>>>>> >>>>>> What exactly is the problem with Visual Studio? Why can't you just >>>>>> run the java launcher instead? >>>>>> >>>>> >>>>> I don't know if there actually is a problem, but I don't think >>>>> anyone's actually tried to tell it to use the java launcher. >>>>> The VS project is automatically setup to launch "hotspot.exe" from >>>>> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >>>>> (IIRC) which involves linking all the VM object files into the >>>>> launcher. >>>>> >>>>> Nils, perhaps you can at least try this before you leave? >>>>> >>>>> /Mikael >>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> //Nils >>>>>>> >>>>>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>>>>> Studio. >>>>>>>>> So removing gamma effectively kills the working environment for a >>>>>>>>> number of people that use it daily. So I am strongly against >>>>>>>>> removing it. >>>>>>>> >>>>>>>> Maybe the visual studio project generator could be updated to >>>>>>>> create a a "launch configuration" for launching java.exe from a >>>>>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>>>>> >>>>>>>> I agree that we shouldn't break the visual studio project but >>>>>>>> currently there's nothing indicating that we can't fix it. >>>>>>>> >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> Most people working on Windows use Cygwin as the last resort >>>>>>>>> since it makes a lot of thing excruciatingly slow. >>>>>>>>> >>>>>>>>> //Nils >>>>>>>>> >>>>>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Chris, >>>>>>>>>>> >>>>>>>>>>> Just an observation and not a review. >>>>>>>>>>> >>>>>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>>>>> Am I missing something? >>>>>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>>>>> near me is one) I have no idea how people are using the gamma >>>>>>>>>> launcher on Windows (or the hotspot script for that matter). >>>>>>>>>> >>>>>>>>>> I presume most people doing debugging on the command line are >>>>>>>>>> already in cygwin? But I might be wrong. >>>>>>>>>> >>>>>>>>>> -- Chris >>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>>>>> >>>>>>>>>>>> 8008772: remove gamma launcher >>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>> >>>>>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>>>>> files. >>>>>>>>>>>> >>>>>>>>>>>> make/Makefile >>>>>>>>>>>> make/bsd/makefiles/launcher.make make/bsd/makefiles/vm.make >>>>>>>>>>>> make/hotspot.script make/linux/makefiles/launcher.make >>>>>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>>>>> make/windows/makefiles/product.make >>>>>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>>>>> >>>>>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>>>>> were subject to bit-rot) and modifies the hotspot script to >>>>>>>>>>>> pick up the libjvm in the current build directory. >>>>>>>>>>>> >>>>>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>>>>> >>>>>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772 >>>>>>>>>>>> /build/linux_i486_compiler2/debug$ >>>>>>>>>>>> >>>>>>>>>>>> ./hotspot -gdb -version >>>>>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) Copyright >>>>>>>>>>>> (C) 2010 Free Software Foundation, Inc. >>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>>> >>>>>>>>>>>> This is free software: you are free to change and >>>>>>>>>>>> redistribute it. >>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>>> "show copying" >>>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>>>>> For bug reporting instructions, please see: >>>>>>>>>>>> . >>>>>>>>>>>> Missing separate debuginfo for >>>>>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binar >>>>>>>>>>>> ies/linux-i586/bin/java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e >>>>>>>>>>>> 31a3.debug >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>>>>> [Thread debugging using libthread_db enabled] [New Thread >>>>>>>>>>>> 0xf7fe4b70 (LWP 13459)] [Switching to Thread 0xf7fe4b70 (LWP >>>>>>>>>>>> 13459)] >>>>>>>>>>>> >>>>>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, >>>>>>>>>>>> penv=0xf7fe4374, >>>>>>>>>>>> args=0xf7fe4364) >>>>>>>>>>>> at >>>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/pri >>>>>>>>>>>> ms/jni.cpp:5062 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>>>>> (gdb) break CompileBroker::compile_method Breakpoint 2 at >>>>>>>>>>>> 0xaef852: file >>>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/com >>>>>>>>>>>> piler/compileBroker.cpp, >>>>>>>>>>>> >>>>>>>>>>>> line 1205. >>>>>>>>>>>> (gdb) c >>>>>>>>>>>> Continuing. >>>>>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] [New Thread 0xb4398b70 >>>>>>>>>>>> (LWP 13461)] [New Thread 0xb41ffb70 (LWP 13462)] [New Thread >>>>>>>>>>>> 0xb3effb70 (LWP 13463)] [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] [New Thread 0xb38ffb70 >>>>>>>>>>>> (LWP 13466)] [New Thread 0xb36ffb70 (LWP 13467)] [New Thread >>>>>>>>>>>> 0xb34ffb70 (LWP 13468)] [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] [New Thread 0xb2effb70 >>>>>>>>>>>> (LWP 13471)] [New Thread 0xb2cffb70 (LWP 13472)] [New Thread >>>>>>>>>>>> 0xaf8e8b70 (LWP 13473)] [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] [New Thread 0xb3a7eb70 >>>>>>>>>>>> (LWP 13476)] [New Thread 0xaeeffb70 (LWP 13477)] [New Thread >>>>>>>>>>>> 0xaecffb70 (LWP 13478)] [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] java version "1.8.0-ea" >>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>>> mode) [Thread 0xaeaffb70 (LWP 13480) exited] [Thread >>>>>>>>>>>> 0xb3a7eb70 (LWP 13476) exited] [Thread 0xaf8e8b70 (LWP 13473) >>>>>>>>>>>> exited] [Thread 0xf7fe4b70 (LWP 13459) exited] [Thread >>>>>>>>>>>> 0xb2cffb70 (LWP 13472) exited] [Thread 0xb2effb70 (LWP 13471) >>>>>>>>>>>> exited] [Thread 0xaecffb70 (LWP 13478) exited] [Thread >>>>>>>>>>>> 0xb387eb70 (LWP 13479) exited] [Thread 0xaeeffb70 (LWP 13477) >>>>>>>>>>>> exited] [Thread 0xb3c7eb70 (LWP 13475) exited] [Thread >>>>>>>>>>>> 0xb4156b70 (LWP 13474) exited] [Thread 0xb32ffb70 (LWP 13469) >>>>>>>>>>>> exited] [Thread 0xb34ffb70 (LWP 13468) exited] [Thread >>>>>>>>>>>> 0xb36ffb70 (LWP 13467) exited] [Thread 0xb38ffb70 (LWP 13466) >>>>>>>>>>>> exited] [Thread 0xb3affb70 (LWP 13465) exited] [Thread >>>>>>>>>>>> 0xb3cffb70 (LWP 13464) exited] [Thread 0xb3effb70 (LWP 13463) >>>>>>>>>>>> exited] [Thread 0xb41ffb70 (LWP 13462) exited] [Thread >>>>>>>>>>>> 0xb4398b70 (LWP 13461) exited] [Thread 0xf7f93b70 (LWP 13460) >>>>>>>>>>>> exited] [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>>>>> >>>>>>>>>>>> Program exited normally. >>>>>>>>>>>> (gdb) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris >>>>>>>>>>>> _i486_compiler2/debug$ >>>>>>>>>>>> >>>>>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>>>>> /home/cthaling/.dbxrc Reading java Reading ld.so.1 Reading >>>>>>>>>>>> libjli.so Reading libthread.so.1 Reading libdl.so.1 Reading >>>>>>>>>>>> libc.so.1 Reading libjvm.so Loaded loadobject: >>>>>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debu >>>>>>>>>>>> g/libjvm.so >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_comp >>>>>>>>>>>> iler2/debug >>>>>>>>>>>> >>>>>>>>>>>> -version >>>>>>>>>>>> (process id 29613) >>>>>>>>>>>> Reading libsocket.so.1 >>>>>>>>>>>> Reading libsched.so.1 >>>>>>>>>>>> Reading libm.so.1 >>>>>>>>>>>> Reading libCrun.so.1 >>>>>>>>>>>> Reading libdoor.so.1 >>>>>>>>>>>> Reading libdemangle.so.1 >>>>>>>>>>>> Reading libnsl.so.1 >>>>>>>>>>>> Reading libm.so.2 >>>>>>>>>>>> Reading libscf.so.1 >>>>>>>>>>>> Reading libuutil.so.1 >>>>>>>>>>>> Reading libgen.so.1 >>>>>>>>>>>> Reading libmd.so.1 >>>>>>>>>>>> Reading libmp.so.2 >>>>>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>>>>> "jni.cpp" >>>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>>>>> (2) stop in >>>>>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandl >>>>>>>>>>>> e,int,const >>>>>>>>>>>> >>>>>>>>>>>> char*,Thread*) >>>>>>>>>>>> (dbx) c >>>>>>>>>>>> Reading libverify.so >>>>>>>>>>>> Reading libjava.so >>>>>>>>>>>> Reading libzip.so >>>>>>>>>>>> java version "1.8.0-ea" >>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>>> mode) >>>>>>>>>>>> >>>>>>>>>>>> execution completed, exit code is 0 >>>>>>>>>>>> (dbx) >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From erik.joelsson at oracle.com Thu May 2 07:46:57 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 02 May 2013 09:46:57 +0200 Subject: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security In-Reply-To: <97A613D6-5F6F-4433-91B7-D1E2B75B2479@oracle.com> References: <517FD910.6050908@oracle.com> <97A613D6-5F6F-4433-91B7-D1E2B75B2479@oracle.com> Message-ID: <518219F1.1020302@oracle.com> I agree the dependencies in BuildJdk.gmk are messed up but I didn't think this bug was the correct place to clean it up so I just followed the existing pattern, which is a strict linear dependency chain. /Erik On 2013-04-30 17:58, Mike Duigou wrote: > It's very nice to see this resolved. Hopefully one more nail in the old build's coffin. > > The jdk target should depend upon genclasses. It seems really strange to have this as a dependency for securityjars and not jdk. > > Mike > > On Apr 30 2013, at 07:45 , Erik Joelsson wrote: > >> With this patch the security tests will again be runnable on the exploded jdk image. The main changes are: >> >> * The security classes are compiled separately to a different output directory. >> * The security jars are created in the jdk target (instead of images) and put in the jdk/lib/... directories. >> >> Also did: >> * Removed now redundant entries in rt.jar exclude list >> * Changed source location for signing unsigned jars >> * Made the SetupJavaCompilation macro more friendly with multiple setups sharing output directories. >> >> http://cr.openjdk.java.net/~erikj/8009280/webrev.jdk.01/ >> http://cr.openjdk.java.net/~erikj/8009280/webrev.root.01/ >> >> /Erik From erik.joelsson at oracle.com Thu May 2 12:28:29 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 02 May 2013 14:28:29 +0200 Subject: RFR: 8013786: JDK-8013480 broke configure on solaris Message-ID: <51825BED.9050301@oracle.com> Unfortunately the change for bug JDK-8013480 broke the build on Solaris: Configure no longer looks for cc and CC instead of gcc and g++ on solaris. This is caused by use of the macro AC_COMPILE_IFELSE in platform.m4, before the compilers have been initialized. We have implemented our platform dependent initialization of the compilers in toolchain.m4, which is executed after platform.m4. The macro AC_COMPILE_IFELSE runs AC_PROG_CC implicitly and sets CC to gcc, which is the default. Once done, AC_PROG_CC cannot be run again and so we get stuck with that value. This patch moves these checks to toolchain.m4, after the compilers have been initialized. I'm currently running a jprt job verifying that this indeed works on all platforms. http://cr.openjdk.java.net/~erikj/8013786/webrev.root.01/ /Erik From tim.bell at oracle.com Thu May 2 13:27:59 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 May 2013 06:27:59 -0700 Subject: RFR: 8013786: JDK-8013480 broke configure on solaris In-Reply-To: <51825BED.9050301@oracle.com> References: <51825BED.9050301@oracle.com> Message-ID: <518269DF.9010900@oracle.com> Erik: > Unfortunately the change for bug JDK-8013480 broke the build on Solaris: > > Configure no longer looks for cc and CC instead of gcc and g++ on > solaris. This is caused by use of the macro AC_COMPILE_IFELSE in > platform.m4, before the compilers have been initialized. We have > implemented our platform dependent initialization of the compilers in > toolchain.m4, which is executed after platform.m4. The macro > AC_COMPILE_IFELSE runs AC_PROG_CC implicitly and sets CC to gcc, which > is the default. Once done, AC_PROG_CC cannot be run again and so we > get stuck with that value. > > This patch moves these checks to toolchain.m4, after the compilers > have been initialized. I'm currently running a jprt job verifying that > this indeed works on all platforms. > > http://cr.openjdk.java.net/~erikj/8013786/webrev.root.01 Looks good. Thanks, Erik Tim From erik.joelsson at oracle.com Thu May 2 13:49:09 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 02 May 2013 13:49:09 +0000 Subject: hg: jdk8/build: 8013786: JDK-8013480 broke configure on solaris Message-ID: <20130502134910.47E184877A@hg.openjdk.java.net> Changeset: e404d321abc6 Author: erikj Date: 2013-05-02 15:46 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/e404d321abc6 8013786: JDK-8013480 broke configure on solaris Reviewed-by: tbell ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/toolchain.m4 From gnu.andrew at redhat.com Thu May 2 15:58:58 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 2 May 2013 11:58:58 -0400 (EDT) Subject: RFR: 8013552: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <517FD9CD.4070605@oracle.com> References: <517F9598.4050905@oracle.com> <517FD49E.9050909@redhat.com> <517FD9CD.4070605@oracle.com> Message-ID: <1184933167.6077096.1367510338648.JavaMail.root@redhat.com> ----- Original Message ----- > On 2013-04-30 16:26, Omair Majid wrote: > > On 04/30/2013 05:57 AM, Erik Joelsson wrote: > >> Open part of this review: > >> > >> The docs team will start producing separate man pages for openjdk and > >> oraclejdk. Here are the necessary changes to the makefiles to support > >> this. This was already done for 7u, but these are the changes for 8. > >> > >> http://cr.openjdk.java.net/~erikj/8013552/webrev.jdk.01/ > > Looks okay to me, assuming the corresponding man pages are present under > > the closed directory. > > > Thanks! > > On a slight tangent, when I last tried to push fixes (mainly typos and > > spelling errors) to the man pages, I was informed that this is taken > > care of by the documentation team who sync official documentation with > > the man pages periodically. Are they still going to be maintaining both > > open and closed man pages? > > > Yes, they are and that's the reason I'm doing this. The man pages in the > jdk source tree are generated files that the docs team periodically updates. > Will the source files be added to the OpenJDK trees at some point? > /Erik > > -- 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 gnu.andrew at redhat.com Thu May 2 16:06:23 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 2 May 2013 12:06:23 -0400 (EDT) Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: <51662722.8010309@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <1646204162.769290.1365440387286.JavaMail.root@redhat.com> <5163661C.5080700@oracle.com> <516396F6.30707@oracle.com> <1135652122.2176747.1365600923712.JavaMail.root@redhat.com> <5166205F.4060300@oracle.com> <51662722.8010309@oracle.com> Message-ID: <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > My sincerest apologies. As long as pushes are to jdk8/build then there > is indeed scope for deferring broad testing until after the push - any > failures will only affect users of the jdk8/build and a fix will likely > swiftly occur. In any case that is for the build folk to concern > themselves with. > > Having been burnt by some recent build issues in other repos I > overlooked the key factor as to which repo is involved. > > Again my apologies. > Thanks, much appreciated and no harm done. My apologies too if I came over a little strongly, and I realise I'm probably directing my comments at the wrong people. It just gets a bit frustrating after six years :-) HotSpot is even more of a problem because not being able to commit directly risks people losing credit for the work they've done and, with an open source project, credit is the only reward. Frther apologies from me too, as I still haven't actually pushed this after all this fuss; the security errata intervened. I'll try and get it in later today. > David > > On 11/04/2013 12:30 PM, David Holmes wrote: > > Hi Andrew, > > > > We live/work in an imperfect world. The shortcomings you outline below > > are well known and steps are being taken to address at least some of > > them. That has taken time and will continue to take time - there is > > nothing I can do about that - sorry. I too would love to see an > > automatic submission system (like JPRT) that is accessible to all so > > that I don't have to ever worry about build failures getting through. > > > > In the meantime I don't think my request to work with others to ensure > > broader test coverage of build changes is unreasonable. > > > > I can't force anyone's cooperation I can only request it. > > > > Thanks, > > David > > > > On 10/04/2013 11:35 PM, Andrew Hughes wrote: > >> ----- Original Message ----- > >>> On 9/04/2013 11:06 AM, Martin Buchholz wrote: > >>>> On Mon, Apr 8, 2013 at 5:51 PM, David Holmes >>>> > wrote: > >>>> > >>>> On 9/04/2013 2:59 AM, Andrew Hughes wrote: > >>>> > >>>> Well, if I push it, it will be, no? > >>>> > >>>> Testing comes before pushing - thank you. > >> > >> And I have built and tested it. You are trying to impose additional > >> requirements > >> for building on platforms we don't use. This simply does not scale. > >> You can't > >> expect every OpenJDK committer to build on four operating systems and > >> however > >> many architectures (potentially any in existence, given the presence > >> of Zero). > >> > >> If I'm a little unforgiving here, it's because I don't see the same > >> thought being > >> applied in the other direction. This is not a patch to add a new > >> feature, but > >> to fix a build regression introduced by Oracle engineers (and one of > >> many we've > >> found). I wouldn't even have to submit this if debugging had not been > >> completely > >> broken in our builds with little clear explanation as to why. > >> > >>>> > >>>> > >>>> This issue keeps coming up. > >>>> > >>>> Non-Oracle committers have no access to the Oracle automated testing > >>>> submission system, so I suggest giving developers some slack when > >>>> submitting (as I did when I was TL integrator). Or provide some other > >>>> simple mechanism for handing off risky patches to the integration > >>>> pipeline. Or provide some easy way to roll back breaking changes. > >> > >> +1. > >> > >>> > >>> If you are submitting a build patch that affects multiple platforms and > >>> you can not test on all the platforms yourself then you should work with > >>> someone who can assist in ensuring sufficient testing is carried out. I > >>> don't think that is at all unreasonable. > >> > >> The problem here is not the concept in general, but that both "someone" > >> and "sufficient testing" are defined relative to Oracle. Could I work > >> with someone at Red Hat, Google or IBM to carry out "sufficient testing"? > >> It seems doubtful to me, and that's without even considering > >> contributions > >> from those not working for a company. > >> > >> As far as I can see, "sufficient testing", from an Oracle perspective, > >> would include > >> testing on e.g. Solaris/SPARC, which is mainly of relevance to them, but > >> not testing on Linux/SPARC (which Debian & Fedora build) or AIX/PPC > >> (which > >> IBM are working on). > >> > >> I agree build testing is important, and no-one wants to find the build > >> broken > >> (I've hit it enough times as the result of work from Oracle > >> engineers), but such > >> a restriction can't be imposed unless resources are available to > >> support it. > >> Pushing a patch and having automated build systems test it on all the > >> various > >> setups is a lot more scalable than waiting for someone else to apply > >> and build it > >> locally. It's not like anyone's going to release binaries if OpenJDK > >> is not buildable, > >> is it? > >> > >> This issue is important not for people like me who have to work on > >> OpenJDK anyway, no > >> matter how much pain and aggravation it is, but in terms of the > >> "onboarding" of new > >> developers. These sort of issues are acceptable in a new project. > >> OpenJDK is now six > >> years old, but non-Oracle users can't even create bugs or commit to > >> HotSpot. I'm not > >> even talking about new committers but people like me who have been > >> working on OpenJDK > >> for all of those six years and have reviewer status. I can review a > >> patch for OpenJDK > >> but the person I reviewed it for can't then commit it until an Oracle > >> employee gives > >> them a bug ID for it. > >> > >> If OpenJDK is going to grow and attract new developers, these issues > >> need to be sorted. > >> > >>> > >>> We have had a number of build related changesets recently (Oracle > >>> generated!) that have caused significant build failures on some > >>> platforms, which in turn causes significant disruption to a number of > >>> teams. So I don't think the importance of testing before pushing can be > >>> overstated here. > >> > >> But if they were Oracle generated, surely they went through your tests > >> and > >> they didn't catch it? Or are you referring to testing prior to commit? > >> > >>> > >>>> There's a far greater risk from changes that pass all the tests today, > >>>> but have a fatal flaw that won't be discovered till after release, IMO. > >>> > >>> Totally different problem. > >> > >> Not really, because this includes build issues that occur from paths > >> through > >> the build that Oracle just don't test. An example would be the recent > >> timezone > >> tool issue that we picked up because we do a build with the just-built > >> JDK but > >> slipped through Oracle's testing to the point of being in a promoted > >> build. > >> > >> > >>> > >>> David > >>> > >> > -- 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 jonathan.gibbons at oracle.com Thu May 2 16:38:52 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 02 May 2013 09:38:52 -0700 Subject: RFR: 8013552: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <1184933167.6077096.1367510338648.JavaMail.root@redhat.com> References: <517F9598.4050905@oracle.com> <517FD49E.9050909@redhat.com> <517FD9CD.4070605@oracle.com> <1184933167.6077096.1367510338648.JavaMail.root@redhat.com> Message-ID: <5182969C.6070704@oracle.com> On 05/02/2013 08:58 AM, Andrew Hughes wrote: >> The man pages in the >> >jdk source tree are generated files that the docs team periodically updates. >> > > Will the source files be added to the OpenJDK trees at some point? > Purely from a curiosity point of view, this also begs the side question of what format are the source files in... -- Jon From omajid at redhat.com Thu May 2 16:44:58 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 02 May 2013 12:44:58 -0400 Subject: RFR: 8013552: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <5182969C.6070704@oracle.com> References: <517F9598.4050905@oracle.com> <517FD49E.9050909@redhat.com> <517FD9CD.4070605@oracle.com> <1184933167.6077096.1367510338648.JavaMail.root@redhat.com> <5182969C.6070704@oracle.com> Message-ID: <5182980A.2050800@redhat.com> On 05/02/2013 12:38 PM, Jonathan Gibbons wrote: > On 05/02/2013 08:58 AM, Andrew Hughes wrote: >>> The man pages in the >>> >jdk source tree are generated files that the docs team periodically >>> updates. >>> > >> Will the source files be added to the OpenJDK trees at some point? >> > > Purely from a curiosity point of view, this also begs the side question of > what format are the source files in... .. and whether the community can submit fixes for them. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From Alan.Bateman at oracle.com Thu May 2 16:45:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 May 2013 17:45:43 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51829725.9090406@oracle.com> References: <51829725.9090406@oracle.com> Message-ID: <51829837.9090406@oracle.com> On 02/05/2013 17:41, A. Sundararajan wrote: > Hi, > > Oracle JDK includes Rhino based javax.script implementation (which > lives mostly in "closed" code). Rhino is being removed from Oracle JDK > builds and there are the changes to the jdk open repository as well > like com.sun.script.javascript package, makefiles etc. Please review > the open jdk changes here: > > http://cr.openjdk.java.net/~sundar/8012975/ In profiles-rtjar-includes.txt then you also need to remove META-INF/services/javax.script.ScriptEngineFactory from PROFILE_3_INCLUDE_METAINF_SERVICES. Otherwise good fine. -Alan. From erik.joelsson at oracle.com Thu May 2 17:08:48 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 02 May 2013 17:08:48 +0000 Subject: hg: jdk8/build: 8011687: Support correct dependencies from header files on windows and solaris Message-ID: <20130502170848.7097C48785@hg.openjdk.java.net> Changeset: e1a929afcfc4 Author: erikj Date: 2013-05-02 15:56 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/e1a929afcfc4 8011687: Support correct dependencies from header files on windows and solaris Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/makefiles/NativeCompilation.gmk From erik.joelsson at oracle.com Thu May 2 17:09:04 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 02 May 2013 17:09:04 +0000 Subject: hg: jdk8/build/jdk: 8013552: Add build support for different man pages for OpenJDK and OracleJDK Message-ID: <20130502170937.7F62B48786@hg.openjdk.java.net> Changeset: 8dbb4b159e04 Author: erikj Date: 2013-05-02 15:59 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8dbb4b159e04 8013552: Add build support for different man pages for OpenJDK and OracleJDK Reviewed-by: tbell, omajid ! makefiles/Images.gmk From joe.darcy at oracle.com Thu May 2 17:23:58 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 02 May 2013 10:23:58 -0700 Subject: RFR: 8013552: Add build support for different man pages for OpenJDK and OracleJDK In-Reply-To: <5182969C.6070704@oracle.com> References: <517F9598.4050905@oracle.com> <517FD49E.9050909@redhat.com> <517FD9CD.4070605@oracle.com> <1184933167.6077096.1367510338648.JavaMail.root@redhat.com> <5182969C.6070704@oracle.com> Message-ID: <5182A12E.8050607@oracle.com> On 05/02/2013 09:38 AM, Jonathan Gibbons wrote: > On 05/02/2013 08:58 AM, Andrew Hughes wrote: >>> The man pages in the >>> >jdk source tree are generated files that the docs team periodically >>> updates. >>> > >> Will the source files be added to the OpenJDK trees at some point? >> > > Purely from a curiosity point of view, this also begs the side > question of > what format are the source files in... > The original source of the man pages is a stylized subset of HTML. -Joe From sundararajan.athijegannathan at oracle.com Thu May 2 16:41:09 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 02 May 2013 22:11:09 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 Message-ID: <51829725.9090406@oracle.com> Hi, Oracle JDK includes Rhino based javax.script implementation (which lives mostly in "closed" code). Rhino is being removed from Oracle JDK builds and there are the changes to the jdk open repository as well like com.sun.script.javascript package, makefiles etc. Please review the open jdk changes here: http://cr.openjdk.java.net/~sundar/8012975/ Thanks, -Sundar From mike.duigou at oracle.com Thu May 2 18:29:22 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 2 May 2013 11:29:22 -0700 Subject: RFR: 8011814/8013271/8013272: Three improvements to J2SE Netbeans project In-Reply-To: <5867A704-95D9-4D38-AA10-78CE8CD7C1FE@oracle.com> References: <5867A704-95D9-4D38-AA10-78CE8CD7C1FE@oracle.com> Message-ID: <3506B092-C05B-44D8-A67E-9ADCA52FFBD8@oracle.com> As a followup to this issue it's been pointed out that I pushed this patch with source-level set to "1.8" which is not supported by Netbeans 7.2 or 7.3. Source 1.8 is supported by the development version of Netbeans which is what I use primarily. There's a problem here: - The JDK repo now contains Java 8 source and over time will include much more Java 8 source (lambdas, default methods, static methods on interfaces, etc.). - The release versions of Netbeans don't understand Java 8 source. So we have to choose between using release versions of Netbeans and accept broken source parsing and using dev versions of Netbeans and the likely bugs (and missing extensions) that will be encountered. Should we change the source level back to 1.7 for now? My vote is "No", but I'm not the decider. Mike On Apr 29 2013, at 19:11 , Mike Duigou wrote: > Hello All; > > This is a review for three changes to the J2SE Netbeans project. If necessary I can break this up into three separate patches but I would rather not if possible. > > > http://cr.openjdk.java.net/~mduigou/JDK-8011814/0/webrev/ > > > 8011814: Add testng.jar to Netbeans projects test compile classpath > > An increasing number of jtreg tests now use TestNG. This change adds the TestNG jar from you JTReg installation to the tests classpath. The location of JTReg is specified in build.properties using jtreg.home or from the environment via JT_HOME. > > > 8013271: Add OS X sources to J2SE Netbeans project > > Adds as source entry for Apple OS X sources to match the Unix and Windows entries. I checked the trademark with the Apple Trademarks page to make sure I got it correct. > > > 8013272: JDK Netbeans projects should use ASCII encoding for sources > > The build scripts compile all OpenJDK java sources using the US-ASCII encoding. This change causes Netbeans to respect this encoding. Whether US-ASCII is the awesomest encoding is certainly debatable, but all editors and IDEs should use what the compiler uses. > > > Thanks for reviewing, > > Mike From tim.bell at oracle.com Thu May 2 20:24:02 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 May 2013 13:24:02 -0700 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51829725.9090406@oracle.com> References: <51829725.9090406@oracle.com> Message-ID: <5182CB62.30307@oracle.com> Hi Sundar: > Oracle JDK includes Rhino based javax.script implementation (which > lives mostly in "closed" code). Rhino is being removed from Oracle JDK > builds and there are the changes to the jdk open repository as well > like com.sun.script.javascript package, makefiles etc. Please review > the open jdk changes here: > > http://cr.openjdk.java.net/~sundar/8012975/ This looks good. Approved. Tim From nils.eliasson at oracle.com Thu May 2 20:52:30 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 02 May 2013 22:52:30 +0200 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <51817DED.2050603@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> Message-ID: <5182D20E.4000600@oracle.com> Upload as a webrev too. http://cr.openjdk.java.net/~neliasso/vs_fix/webrev.01/ //N On 2013-05-01 22:41, Nils Eliasson wrote: > Hi, > > Here is a patch that fixes so that it still works to create vcprojs, > and also sets defaults for the debugger commands. > > I have verified with creating vcprojs and debugging hotspot in VS > 2010. Works great except for an annoying pop-up that warns that the > launcher doesn't have debug symbols (if the target jdk doesn't). > > It will still be some extra work for those using the commandlines > plugin. All saved command lines need the be prepended with > "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK > set as executable to work. We should update the plugin to help with that. > > A big thank you to Christian T?rnqvist for the proposal! > > //Nils > > > On 2013-04-23 20:33, Mikael Gerdin wrote: >> >> On 2013-04-23 20:28, Christian Thalinger wrote: >>> >>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>> wrote: >>> >>>> As long as we fix it first and remove gamma after - I would love to >>>> have some redundant code removed. I would fix it myself, I just >>>> don't think I will have the time before I go on parental leave. >>> >>> First, I'm not removing it tomorrow. I expected a long discussion :-) >>> >>> What exactly is the problem with Visual Studio? Why can't you just >>> run the java launcher instead? >>> >> >> I don't know if there actually is a problem, but I don't think >> anyone's actually tried to tell it to use the java launcher. >> The VS project is automatically setup to launch "hotspot.exe" from >> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >> (IIRC) which involves linking all the VM object files into the launcher. >> >> Nils, perhaps you can at least try this before you leave? >> >> /Mikael >> >>> -- Chris >>> >>>> >>>> //Nils >>>> >>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>> >>>>> >>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>> Studio. >>>>>> So removing gamma effectively kills the working environment for a >>>>>> number >>>>>> of people that use it daily. So I am strongly against removing it. >>>>> >>>>> Maybe the visual studio project generator could be updated to >>>>> create a a "launch configuration" for launching java.exe from a >>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>> >>>>> I agree that we shouldn't break the visual studio project but >>>>> currently there's nothing indicating that we can't fix it. >>>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Most people working on Windows use Cygwin as the last resort >>>>>> since it >>>>>> makes a lot of thing excruciatingly slow. >>>>>> >>>>>> //Nils >>>>>> >>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>> wrote: >>>>>>> >>>>>>>> Chris, >>>>>>>> >>>>>>>> Just an observation and not a review. >>>>>>>> >>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>> Am I missing something? >>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>> near >>>>>>> me is one) I have no idea how people are using the gamma >>>>>>> launcher on >>>>>>> Windows (or the hotspot script for that matter). >>>>>>> >>>>>>> I presume most people doing debugging on the command line are >>>>>>> already >>>>>>> in cygwin? But I might be wrong. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>> >>>>>>>>> 8008772: remove gamma launcher >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>> files. >>>>>>>>> >>>>>>>>> make/Makefile >>>>>>>>> make/bsd/makefiles/launcher.make >>>>>>>>> make/bsd/makefiles/vm.make >>>>>>>>> make/hotspot.script >>>>>>>>> make/linux/makefiles/launcher.make >>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>> make/windows/makefiles/product.make >>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>> >>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>> were >>>>>>>>> subject to bit-rot) and modifies the hotspot script to pick up >>>>>>>>> the >>>>>>>>> libjvm in the current build directory. >>>>>>>>> >>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>> >>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772/build/linux_i486_compiler2/debug$ >>>>>>>>> >>>>>>>>> ./hotspot -gdb -version >>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) >>>>>>>>> Copyright (C) 2010 Free Software Foundation, Inc. >>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>> >>>>>>>>> This is free software: you are free to change and redistribute >>>>>>>>> it. >>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show >>>>>>>>> copying" >>>>>>>>> and "show warranty" for details. >>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>> For bug reporting instructions, please see: >>>>>>>>> . >>>>>>>>> Missing separate debuginfo for >>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binaries/linux-i586/bin/java >>>>>>>>> >>>>>>>>> >>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e31a3.debug >>>>>>>>> >>>>>>>>> >>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>> [Thread debugging using libthread_db enabled] >>>>>>>>> [New Thread 0xf7fe4b70 (LWP 13459)] >>>>>>>>> [Switching to Thread 0xf7fe4b70 (LWP 13459)] >>>>>>>>> >>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, penv=0xf7fe4374, >>>>>>>>> args=0xf7fe4364) >>>>>>>>> at >>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/prims/jni.cpp:5062 >>>>>>>>> >>>>>>>>> >>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>> (gdb) break CompileBroker::compile_method >>>>>>>>> Breakpoint 2 at 0xaef852: file >>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/compiler/compileBroker.cpp, >>>>>>>>> >>>>>>>>> line 1205. >>>>>>>>> (gdb) c >>>>>>>>> Continuing. >>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] >>>>>>>>> [New Thread 0xb4398b70 (LWP 13461)] >>>>>>>>> [New Thread 0xb41ffb70 (LWP 13462)] >>>>>>>>> [New Thread 0xb3effb70 (LWP 13463)] >>>>>>>>> [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] >>>>>>>>> [New Thread 0xb38ffb70 (LWP 13466)] >>>>>>>>> [New Thread 0xb36ffb70 (LWP 13467)] >>>>>>>>> [New Thread 0xb34ffb70 (LWP 13468)] >>>>>>>>> [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] >>>>>>>>> [New Thread 0xb2effb70 (LWP 13471)] >>>>>>>>> [New Thread 0xb2cffb70 (LWP 13472)] >>>>>>>>> [New Thread 0xaf8e8b70 (LWP 13473)] >>>>>>>>> [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] >>>>>>>>> [New Thread 0xb3a7eb70 (LWP 13476)] >>>>>>>>> [New Thread 0xaeeffb70 (LWP 13477)] >>>>>>>>> [New Thread 0xaecffb70 (LWP 13478)] >>>>>>>>> [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] >>>>>>>>> java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) >>>>>>>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, >>>>>>>>> mixed mode) >>>>>>>>> [Thread 0xaeaffb70 (LWP 13480) exited] >>>>>>>>> [Thread 0xb3a7eb70 (LWP 13476) exited] >>>>>>>>> [Thread 0xaf8e8b70 (LWP 13473) exited] >>>>>>>>> [Thread 0xf7fe4b70 (LWP 13459) exited] >>>>>>>>> [Thread 0xb2cffb70 (LWP 13472) exited] >>>>>>>>> [Thread 0xb2effb70 (LWP 13471) exited] >>>>>>>>> [Thread 0xaecffb70 (LWP 13478) exited] >>>>>>>>> [Thread 0xb387eb70 (LWP 13479) exited] >>>>>>>>> [Thread 0xaeeffb70 (LWP 13477) exited] >>>>>>>>> [Thread 0xb3c7eb70 (LWP 13475) exited] >>>>>>>>> [Thread 0xb4156b70 (LWP 13474) exited] >>>>>>>>> [Thread 0xb32ffb70 (LWP 13469) exited] >>>>>>>>> [Thread 0xb34ffb70 (LWP 13468) exited] >>>>>>>>> [Thread 0xb36ffb70 (LWP 13467) exited] >>>>>>>>> [Thread 0xb38ffb70 (LWP 13466) exited] >>>>>>>>> [Thread 0xb3affb70 (LWP 13465) exited] >>>>>>>>> [Thread 0xb3cffb70 (LWP 13464) exited] >>>>>>>>> [Thread 0xb3effb70 (LWP 13463) exited] >>>>>>>>> [Thread 0xb41ffb70 (LWP 13462) exited] >>>>>>>>> [Thread 0xb4398b70 (LWP 13461) exited] >>>>>>>>> [Thread 0xf7f93b70 (LWP 13460) exited] >>>>>>>>> [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>> >>>>>>>>> Program exited normally. >>>>>>>>> (gdb) >>>>>>>>> >>>>>>>>> >>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris_i486_compiler2/debug$ >>>>>>>>> >>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>> /home/cthaling/.dbxrc >>>>>>>>> Reading java >>>>>>>>> Reading ld.so.1 >>>>>>>>> Reading libjli.so >>>>>>>>> Reading libthread.so.1 >>>>>>>>> Reading libdl.so.1 >>>>>>>>> Reading libc.so.1 >>>>>>>>> Reading libjvm.so >>>>>>>>> Loaded loadobject: >>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debug/libjvm.so >>>>>>>>> >>>>>>>>> >>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_compiler2/debug >>>>>>>>> >>>>>>>>> -version >>>>>>>>> (process id 29613) >>>>>>>>> Reading libsocket.so.1 >>>>>>>>> Reading libsched.so.1 >>>>>>>>> Reading libm.so.1 >>>>>>>>> Reading libCrun.so.1 >>>>>>>>> Reading libdoor.so.1 >>>>>>>>> Reading libdemangle.so.1 >>>>>>>>> Reading libnsl.so.1 >>>>>>>>> Reading libm.so.2 >>>>>>>>> Reading libscf.so.1 >>>>>>>>> Reading libuutil.so.1 >>>>>>>>> Reading libgen.so.1 >>>>>>>>> Reading libmd.so.1 >>>>>>>>> Reading libmp.so.2 >>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>> "jni.cpp" >>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>> (2) stop in >>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandle,int,const >>>>>>>>> >>>>>>>>> char*,Thread*) >>>>>>>>> (dbx) c >>>>>>>>> Reading libverify.so >>>>>>>>> Reading libjava.so >>>>>>>>> Reading libzip.so >>>>>>>>> java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) >>>>>>>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal-debug, >>>>>>>>> mixed mode) >>>>>>>>> >>>>>>>>> execution completed, exit code is 0 >>>>>>>>> (dbx) >>>>>>>>> >>>>>> >>>> >>> > From christian.thalinger at oracle.com Thu May 2 22:50:47 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 2 May 2013 15:50:47 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <51818E47.1050605@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> Message-ID: <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> On May 1, 2013, at 2:51 PM, Vladimir Kozlov wrote: > Somehow I got Nils's mail without attachment. > > On 5/1/13 2:30 PM, Christian Tornqvist wrote: >> Hi Vladimir, >> >> Nils attached the patch to the email, but I've put the patch at >> http://cr.openjdk.java.net/~ctornqvi/webrev/vs.patch also > > This looks good. Christian Thalinger will be happy :) Indeed :-) Thanks Nils and Christian for making that work! -- Chris > > Thanks, > Vladimir > >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: den 1 maj 2013 17:22 >> To: Nils Eliasson >> Cc: build-dev at openjdk.java.net; hotspot-dev developers; Christian Thalinger >> Subject: Re: RFR (M): 8008772: remove gamma launcher >> >> Nils, >> >> I don't see attached patch or webrev link. >> >> thanks, >> Vladimir >> >> On 5/1/13 1:41 PM, Nils Eliasson wrote: >>> Hi, >>> >>> Here is a patch that fixes so that it still works to create vcprojs, >>> and also sets defaults for the debugger commands. >>> >>> I have verified with creating vcprojs and debugging hotspot in VS 2010. >>> Works great except for an annoying pop-up that warns that the launcher >>> doesn't have debug symbols (if the target jdk doesn't). >>> >>> It will still be some extra work for those using the commandlines >>> plugin. All saved command lines need the be prepended with >>> "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK >>> set as executable to work. We should update the plugin to help with that. >>> >>> A big thank you to Christian T?rnqvist for the proposal! >>> >>> //Nils >>> >>> >>> On 2013-04-23 20:33, Mikael Gerdin wrote: >>>> >>>> On 2013-04-23 20:28, Christian Thalinger wrote: >>>>> >>>>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>>>> wrote: >>>>> >>>>>> As long as we fix it first and remove gamma after - I would love to >>>>>> have some redundant code removed. I would fix it myself, I just >>>>>> don't think I will have the time before I go on parental leave. >>>>> >>>>> First, I'm not removing it tomorrow. I expected a long discussion >>>>> :-) >>>>> >>>>> What exactly is the problem with Visual Studio? Why can't you just >>>>> run the java launcher instead? >>>>> >>>> >>>> I don't know if there actually is a problem, but I don't think >>>> anyone's actually tried to tell it to use the java launcher. >>>> The VS project is automatically setup to launch "hotspot.exe" from >>>> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >>>> (IIRC) which involves linking all the VM object files into the launcher. >>>> >>>> Nils, perhaps you can at least try this before you leave? >>>> >>>> /Mikael >>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> //Nils >>>>>> >>>>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>>>> >>>>>>> >>>>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>>>> Studio. >>>>>>>> So removing gamma effectively kills the working environment for a >>>>>>>> number of people that use it daily. So I am strongly against >>>>>>>> removing it. >>>>>>> >>>>>>> Maybe the visual studio project generator could be updated to >>>>>>> create a a "launch configuration" for launching java.exe from a >>>>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>>>> >>>>>>> I agree that we shouldn't break the visual studio project but >>>>>>> currently there's nothing indicating that we can't fix it. >>>>>>> >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> Most people working on Windows use Cygwin as the last resort >>>>>>>> since it makes a lot of thing excruciatingly slow. >>>>>>>> >>>>>>>> //Nils >>>>>>>> >>>>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Chris, >>>>>>>>>> >>>>>>>>>> Just an observation and not a review. >>>>>>>>>> >>>>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>>>> Am I missing something? >>>>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>>>> near me is one) I have no idea how people are using the gamma >>>>>>>>> launcher on Windows (or the hotspot script for that matter). >>>>>>>>> >>>>>>>>> I presume most people doing debugging on the command line are >>>>>>>>> already in cygwin? But I might be wrong. >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>>>> >>>>>>>>>>> 8008772: remove gamma launcher >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> >>>>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>>>> files. >>>>>>>>>>> >>>>>>>>>>> make/Makefile >>>>>>>>>>> make/bsd/makefiles/launcher.make make/bsd/makefiles/vm.make >>>>>>>>>>> make/hotspot.script make/linux/makefiles/launcher.make >>>>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>>>> make/windows/makefiles/product.make >>>>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>>>> >>>>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>>>> were subject to bit-rot) and modifies the hotspot script to >>>>>>>>>>> pick up the libjvm in the current build directory. >>>>>>>>>>> >>>>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>>>> >>>>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772 >>>>>>>>>>> /build/linux_i486_compiler2/debug$ >>>>>>>>>>> >>>>>>>>>>> ./hotspot -gdb -version >>>>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) Copyright >>>>>>>>>>> (C) 2010 Free Software Foundation, Inc. >>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>> >>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>> "show copying" >>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>>>> For bug reporting instructions, please see: >>>>>>>>>>> . >>>>>>>>>>> Missing separate debuginfo for >>>>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binar >>>>>>>>>>> ies/linux-i586/bin/java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e >>>>>>>>>>> 31a3.debug >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>>>> [Thread debugging using libthread_db enabled] [New Thread >>>>>>>>>>> 0xf7fe4b70 (LWP 13459)] [Switching to Thread 0xf7fe4b70 (LWP >>>>>>>>>>> 13459)] >>>>>>>>>>> >>>>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, >>>>>>>>>>> penv=0xf7fe4374, >>>>>>>>>>> args=0xf7fe4364) >>>>>>>>>>> at >>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/pri >>>>>>>>>>> ms/jni.cpp:5062 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>>>> (gdb) break CompileBroker::compile_method Breakpoint 2 at >>>>>>>>>>> 0xaef852: file >>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/com >>>>>>>>>>> piler/compileBroker.cpp, >>>>>>>>>>> >>>>>>>>>>> line 1205. >>>>>>>>>>> (gdb) c >>>>>>>>>>> Continuing. >>>>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] [New Thread 0xb4398b70 >>>>>>>>>>> (LWP 13461)] [New Thread 0xb41ffb70 (LWP 13462)] [New Thread >>>>>>>>>>> 0xb3effb70 (LWP 13463)] [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] [New Thread 0xb38ffb70 >>>>>>>>>>> (LWP 13466)] [New Thread 0xb36ffb70 (LWP 13467)] [New Thread >>>>>>>>>>> 0xb34ffb70 (LWP 13468)] [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] [New Thread 0xb2effb70 >>>>>>>>>>> (LWP 13471)] [New Thread 0xb2cffb70 (LWP 13472)] [New Thread >>>>>>>>>>> 0xaf8e8b70 (LWP 13473)] [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] [New Thread 0xb3a7eb70 >>>>>>>>>>> (LWP 13476)] [New Thread 0xaeeffb70 (LWP 13477)] [New Thread >>>>>>>>>>> 0xaecffb70 (LWP 13478)] [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] java version "1.8.0-ea" >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>> mode) [Thread 0xaeaffb70 (LWP 13480) exited] [Thread >>>>>>>>>>> 0xb3a7eb70 (LWP 13476) exited] [Thread 0xaf8e8b70 (LWP 13473) >>>>>>>>>>> exited] [Thread 0xf7fe4b70 (LWP 13459) exited] [Thread >>>>>>>>>>> 0xb2cffb70 (LWP 13472) exited] [Thread 0xb2effb70 (LWP 13471) >>>>>>>>>>> exited] [Thread 0xaecffb70 (LWP 13478) exited] [Thread >>>>>>>>>>> 0xb387eb70 (LWP 13479) exited] [Thread 0xaeeffb70 (LWP 13477) >>>>>>>>>>> exited] [Thread 0xb3c7eb70 (LWP 13475) exited] [Thread >>>>>>>>>>> 0xb4156b70 (LWP 13474) exited] [Thread 0xb32ffb70 (LWP 13469) >>>>>>>>>>> exited] [Thread 0xb34ffb70 (LWP 13468) exited] [Thread >>>>>>>>>>> 0xb36ffb70 (LWP 13467) exited] [Thread 0xb38ffb70 (LWP 13466) >>>>>>>>>>> exited] [Thread 0xb3affb70 (LWP 13465) exited] [Thread >>>>>>>>>>> 0xb3cffb70 (LWP 13464) exited] [Thread 0xb3effb70 (LWP 13463) >>>>>>>>>>> exited] [Thread 0xb41ffb70 (LWP 13462) exited] [Thread >>>>>>>>>>> 0xb4398b70 (LWP 13461) exited] [Thread 0xf7f93b70 (LWP 13460) >>>>>>>>>>> exited] [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>>>> >>>>>>>>>>> Program exited normally. >>>>>>>>>>> (gdb) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris >>>>>>>>>>> _i486_compiler2/debug$ >>>>>>>>>>> >>>>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>>>> /home/cthaling/.dbxrc Reading java Reading ld.so.1 Reading >>>>>>>>>>> libjli.so Reading libthread.so.1 Reading libdl.so.1 Reading >>>>>>>>>>> libc.so.1 Reading libjvm.so Loaded loadobject: >>>>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debu >>>>>>>>>>> g/libjvm.so >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_comp >>>>>>>>>>> iler2/debug >>>>>>>>>>> >>>>>>>>>>> -version >>>>>>>>>>> (process id 29613) >>>>>>>>>>> Reading libsocket.so.1 >>>>>>>>>>> Reading libsched.so.1 >>>>>>>>>>> Reading libm.so.1 >>>>>>>>>>> Reading libCrun.so.1 >>>>>>>>>>> Reading libdoor.so.1 >>>>>>>>>>> Reading libdemangle.so.1 >>>>>>>>>>> Reading libnsl.so.1 >>>>>>>>>>> Reading libm.so.2 >>>>>>>>>>> Reading libscf.so.1 >>>>>>>>>>> Reading libuutil.so.1 >>>>>>>>>>> Reading libgen.so.1 >>>>>>>>>>> Reading libmd.so.1 >>>>>>>>>>> Reading libmp.so.2 >>>>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>>>> "jni.cpp" >>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>>>> (2) stop in >>>>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandl >>>>>>>>>>> e,int,const >>>>>>>>>>> >>>>>>>>>>> char*,Thread*) >>>>>>>>>>> (dbx) c >>>>>>>>>>> Reading libverify.so >>>>>>>>>>> Reading libjava.so >>>>>>>>>>> Reading libzip.so >>>>>>>>>>> java version "1.8.0-ea" >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>> mode) >>>>>>>>>>> >>>>>>>>>>> execution completed, exit code is 0 >>>>>>>>>>> (dbx) >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From christian.thalinger at oracle.com Thu May 2 23:44:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 2 May 2013 16:44:28 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> Message-ID: <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> Mikael Gerdin pointed out that when JAVA_HOME is not set during a build JDK ends up being empty in jdkpath.sh. Actually, why do we have jdkpath.sh? Can't we put the path directly into the hotspot script? Here is a new webrev including the Windows patch, additionally removes jdkpath.sh and sets JDK to JDK_IMPORT_PATH if ALT_JAVA_HOME is not set: http://cr.openjdk.java.net/~twisti/8008772/ Next question: is anyone using env.{sh,csh}? Since we removed test_gamma these files are unused and we could stop generating them. -- Chris On May 2, 2013, at 3:50 PM, Christian Thalinger wrote: > > On May 1, 2013, at 2:51 PM, Vladimir Kozlov wrote: > >> Somehow I got Nils's mail without attachment. >> >> On 5/1/13 2:30 PM, Christian Tornqvist wrote: >>> Hi Vladimir, >>> >>> Nils attached the patch to the email, but I've put the patch at >>> http://cr.openjdk.java.net/~ctornqvi/webrev/vs.patch also >> >> This looks good. Christian Thalinger will be happy :) > > Indeed :-) Thanks Nils and Christian for making that work! > > -- Chris > >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>> Sent: den 1 maj 2013 17:22 >>> To: Nils Eliasson >>> Cc: build-dev at openjdk.java.net; hotspot-dev developers; Christian Thalinger >>> Subject: Re: RFR (M): 8008772: remove gamma launcher >>> >>> Nils, >>> >>> I don't see attached patch or webrev link. >>> >>> thanks, >>> Vladimir >>> >>> On 5/1/13 1:41 PM, Nils Eliasson wrote: >>>> Hi, >>>> >>>> Here is a patch that fixes so that it still works to create vcprojs, >>>> and also sets defaults for the debugger commands. >>>> >>>> I have verified with creating vcprojs and debugging hotspot in VS 2010. >>>> Works great except for an annoying pop-up that warns that the launcher >>>> doesn't have debug symbols (if the target jdk doesn't). >>>> >>>> It will still be some extra work for those using the commandlines >>>> plugin. All saved command lines need the be prepended with >>>> "-XXaltjvm=$(TargetDir) -Dsun.java.launcher=gamma" and the target JDK >>>> set as executable to work. We should update the plugin to help with that. >>>> >>>> A big thank you to Christian T?rnqvist for the proposal! >>>> >>>> //Nils >>>> >>>> >>>> On 2013-04-23 20:33, Mikael Gerdin wrote: >>>>> >>>>> On 2013-04-23 20:28, Christian Thalinger wrote: >>>>>> >>>>>> On Apr 23, 2013, at 11:06 AM, Nils Eliasson >>>>>> wrote: >>>>>> >>>>>>> As long as we fix it first and remove gamma after - I would love to >>>>>>> have some redundant code removed. I would fix it myself, I just >>>>>>> don't think I will have the time before I go on parental leave. >>>>>> >>>>>> First, I'm not removing it tomorrow. I expected a long discussion >>>>>> :-) >>>>>> >>>>>> What exactly is the problem with Visual Studio? Why can't you just >>>>>> run the java launcher instead? >>>>>> >>>>> >>>>> I don't know if there actually is a problem, but I don't think >>>>> anyone's actually tried to tell it to use the java launcher. >>>>> The VS project is automatically setup to launch "hotspot.exe" from >>>>> the IDE. "hotspot.exe" is equivalent to the old option LINK_INTO=AOUT >>>>> (IIRC) which involves linking all the VM object files into the launcher. >>>>> >>>>> Nils, perhaps you can at least try this before you leave? >>>>> >>>>> /Mikael >>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> //Nils >>>>>>> >>>>>>> On 2013-04-23 12:59, Mikael Gerdin wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2013-04-23 11:09, Nils Eliasson wrote: >>>>>>>>> The gamma launcher is used to run and debug hotspot from Visual >>>>>>>>> Studio. >>>>>>>>> So removing gamma effectively kills the working environment for a >>>>>>>>> number of people that use it daily. So I am strongly against >>>>>>>>> removing it. >>>>>>>> >>>>>>>> Maybe the visual studio project generator could be updated to >>>>>>>> create a a "launch configuration" for launching java.exe from a >>>>>>>> JDK and use the XXaltJVM flag on to select the correct jvm.dll? >>>>>>>> >>>>>>>> I agree that we shouldn't break the visual studio project but >>>>>>>> currently there's nothing indicating that we can't fix it. >>>>>>>> >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> Most people working on Windows use Cygwin as the last resort >>>>>>>>> since it makes a lot of thing excruciatingly slow. >>>>>>>>> >>>>>>>>> //Nils >>>>>>>>> >>>>>>>>> On 2013-04-22 22:55, Christian Thalinger wrote: >>>>>>>>>> On Apr 22, 2013, at 1:36 PM, Daniel D. Daugherty >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Chris, >>>>>>>>>>> >>>>>>>>>>> Just an observation and not a review. >>>>>>>>>>> >>>>>>>>>>> Looks like you're removing launcher support on Windows, but it >>>>>>>>>>> looks like the new hotspot.script doesn't support Windows... >>>>>>>>>>> Am I missing something? >>>>>>>>>> Almost certainly true. Since I'm not a Windows user (and nobody >>>>>>>>>> near me is one) I have no idea how people are using the gamma >>>>>>>>>> launcher on Windows (or the hotspot script for that matter). >>>>>>>>>> >>>>>>>>>> I presume most people doing debugging on the command line are >>>>>>>>>> already in cygwin? But I might be wrong. >>>>>>>>>> >>>>>>>>>> -- Chris >>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/22/13 1:47 PM, Christian Thalinger wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>>>>>>>>>> >>>>>>>>>>>> 8008772: remove gamma launcher >>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>> >>>>>>>>>>>> Remove linking the gamma launcher and it's associated source >>>>>>>>>>>> files. >>>>>>>>>>>> >>>>>>>>>>>> make/Makefile >>>>>>>>>>>> make/bsd/makefiles/launcher.make make/bsd/makefiles/vm.make >>>>>>>>>>>> make/hotspot.script make/linux/makefiles/launcher.make >>>>>>>>>>>> make/linux/makefiles/vm.make >>>>>>>>>>>> make/solaris/makefiles/launcher.make >>>>>>>>>>>> make/solaris/makefiles/vm.make >>>>>>>>>>>> make/windows/makefiles/debug.make >>>>>>>>>>>> make/windows/makefiles/fastdebug.make >>>>>>>>>>>> make/windows/makefiles/launcher.make >>>>>>>>>>>> make/windows/makefiles/product.make >>>>>>>>>>>> make/windows/makefiles/projectcreator.make >>>>>>>>>>>> make/windows/projectfiles/common/Makefile >>>>>>>>>>>> src/os/posix/launcher/java_md.c >>>>>>>>>>>> src/os/posix/launcher/java_md.h >>>>>>>>>>>> src/os/posix/launcher/launcher.script >>>>>>>>>>>> src/os/windows/launcher/java_md.c >>>>>>>>>>>> src/os/windows/launcher/java_md.h >>>>>>>>>>>> src/share/tools/launcher/java.c >>>>>>>>>>>> src/share/tools/launcher/java.h >>>>>>>>>>>> src/share/tools/launcher/jli_util.c >>>>>>>>>>>> src/share/tools/launcher/jli_util.h >>>>>>>>>>>> src/share/tools/launcher/wildcard.c >>>>>>>>>>>> src/share/tools/launcher/wildcard.h >>>>>>>>>>>> >>>>>>>>>>>> This change removes the duplicated java launcher files (which >>>>>>>>>>>> were subject to bit-rot) and modifies the hotspot script to >>>>>>>>>>>> pick up the libjvm in the current build directory. >>>>>>>>>>>> >>>>>>>>>>>> The modified hotspot script works with GDB and DBX: >>>>>>>>>>>> >>>>>>>>>>>> cthaling at intelsdv03.us.oracle.com:/export/twisti/build/8008772 >>>>>>>>>>>> /build/linux_i486_compiler2/debug$ >>>>>>>>>>>> >>>>>>>>>>>> ./hotspot -gdb -version >>>>>>>>>>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6) Copyright >>>>>>>>>>>> (C) 2010 Free Software Foundation, Inc. >>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>>>>>> >>>>>>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type >>>>>>>>>>>> "show copying" >>>>>>>>>>>> and "show warranty" for details. >>>>>>>>>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>>>>>>>>> For bug reporting instructions, please see: >>>>>>>>>>>> . >>>>>>>>>>>> Missing separate debuginfo for >>>>>>>>>>>> /net/scanas404.us.oracle.com/export/java-re/jdk/8/ea/b86/binar >>>>>>>>>>>> ies/linux-i586/bin/java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install >>>>>>>>>>>> /usr/lib/debug/.build-id/5e/85e6dced3b388a7b0e50630242f4c7ee5e >>>>>>>>>>>> 31a3.debug >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Function "JNI_CreateJavaVM" not defined. >>>>>>>>>>>> Breakpoint 1 (JNI_CreateJavaVM) pending. >>>>>>>>>>>> [Thread debugging using libthread_db enabled] [New Thread >>>>>>>>>>>> 0xf7fe4b70 (LWP 13459)] [Switching to Thread 0xf7fe4b70 (LWP >>>>>>>>>>>> 13459)] >>>>>>>>>>>> >>>>>>>>>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0xf7fe4378, >>>>>>>>>>>> penv=0xf7fe4374, >>>>>>>>>>>> args=0xf7fe4364) >>>>>>>>>>>> at >>>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/pri >>>>>>>>>>>> ms/jni.cpp:5062 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>>>>>> glibc-2.12-1.7.el6.i686 >>>>>>>>>>>> (gdb) break CompileBroker::compile_method Breakpoint 2 at >>>>>>>>>>>> 0xaef852: file >>>>>>>>>>>> /net/10.159.161.234/Users/cthaling/ws/8008772/src/share/vm/com >>>>>>>>>>>> piler/compileBroker.cpp, >>>>>>>>>>>> >>>>>>>>>>>> line 1205. >>>>>>>>>>>> (gdb) c >>>>>>>>>>>> Continuing. >>>>>>>>>>>> [New Thread 0xf7f93b70 (LWP 13460)] [New Thread 0xb4398b70 >>>>>>>>>>>> (LWP 13461)] [New Thread 0xb41ffb70 (LWP 13462)] [New Thread >>>>>>>>>>>> 0xb3effb70 (LWP 13463)] [New Thread 0xb3cffb70 (LWP 13464)] >>>>>>>>>>>> [New Thread 0xb3affb70 (LWP 13465)] [New Thread 0xb38ffb70 >>>>>>>>>>>> (LWP 13466)] [New Thread 0xb36ffb70 (LWP 13467)] [New Thread >>>>>>>>>>>> 0xb34ffb70 (LWP 13468)] [New Thread 0xb32ffb70 (LWP 13469)] >>>>>>>>>>>> [New Thread 0xb30ffb70 (LWP 13470)] [New Thread 0xb2effb70 >>>>>>>>>>>> (LWP 13471)] [New Thread 0xb2cffb70 (LWP 13472)] [New Thread >>>>>>>>>>>> 0xaf8e8b70 (LWP 13473)] [New Thread 0xb4156b70 (LWP 13474)] >>>>>>>>>>>> [New Thread 0xb3c7eb70 (LWP 13475)] [New Thread 0xb3a7eb70 >>>>>>>>>>>> (LWP 13476)] [New Thread 0xaeeffb70 (LWP 13477)] [New Thread >>>>>>>>>>>> 0xaecffb70 (LWP 13478)] [New Thread 0xb387eb70 (LWP 13479)] >>>>>>>>>>>> [New Thread 0xaeaffb70 (LWP 13480)] java version "1.8.0-ea" >>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>>> mode) [Thread 0xaeaffb70 (LWP 13480) exited] [Thread >>>>>>>>>>>> 0xb3a7eb70 (LWP 13476) exited] [Thread 0xaf8e8b70 (LWP 13473) >>>>>>>>>>>> exited] [Thread 0xf7fe4b70 (LWP 13459) exited] [Thread >>>>>>>>>>>> 0xb2cffb70 (LWP 13472) exited] [Thread 0xb2effb70 (LWP 13471) >>>>>>>>>>>> exited] [Thread 0xaecffb70 (LWP 13478) exited] [Thread >>>>>>>>>>>> 0xb387eb70 (LWP 13479) exited] [Thread 0xaeeffb70 (LWP 13477) >>>>>>>>>>>> exited] [Thread 0xb3c7eb70 (LWP 13475) exited] [Thread >>>>>>>>>>>> 0xb4156b70 (LWP 13474) exited] [Thread 0xb32ffb70 (LWP 13469) >>>>>>>>>>>> exited] [Thread 0xb34ffb70 (LWP 13468) exited] [Thread >>>>>>>>>>>> 0xb36ffb70 (LWP 13467) exited] [Thread 0xb38ffb70 (LWP 13466) >>>>>>>>>>>> exited] [Thread 0xb3affb70 (LWP 13465) exited] [Thread >>>>>>>>>>>> 0xb3cffb70 (LWP 13464) exited] [Thread 0xb3effb70 (LWP 13463) >>>>>>>>>>>> exited] [Thread 0xb41ffb70 (LWP 13462) exited] [Thread >>>>>>>>>>>> 0xb4398b70 (LWP 13461) exited] [Thread 0xf7f93b70 (LWP 13460) >>>>>>>>>>>> exited] [Thread 0xb30ffb70 (LWP 13470) exited] >>>>>>>>>>>> >>>>>>>>>>>> Program exited normally. >>>>>>>>>>>> (gdb) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> cthaling at intelsdv01:/export/twisti/build/8008772/build/solaris >>>>>>>>>>>> _i486_compiler2/debug$ >>>>>>>>>>>> >>>>>>>>>>>> /bin/bash ./hotspot -dbx -version >>>>>>>>>>>> dbx: warning: using the alternate init file: >>>>>>>>>>>> /home/cthaling/.dbxrc Reading java Reading ld.so.1 Reading >>>>>>>>>>>> libjli.so Reading libthread.so.1 Reading libdl.so.1 Reading >>>>>>>>>>>> libc.so.1 Reading libjvm.so Loaded loadobject: >>>>>>>>>>>> /export/twisti/build/8008772/build/solaris_i486_compiler2/debu >>>>>>>>>>>> g/libjvm.so >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Running: java -Dsun.java.launcher=gamma >>>>>>>>>>>> -XXaltjvm=/export/twisti/build/8008772/build/solaris_i486_comp >>>>>>>>>>>> iler2/debug >>>>>>>>>>>> >>>>>>>>>>>> -version >>>>>>>>>>>> (process id 29613) >>>>>>>>>>>> Reading libsocket.so.1 >>>>>>>>>>>> Reading libsched.so.1 >>>>>>>>>>>> Reading libm.so.1 >>>>>>>>>>>> Reading libCrun.so.1 >>>>>>>>>>>> Reading libdoor.so.1 >>>>>>>>>>>> Reading libdemangle.so.1 >>>>>>>>>>>> Reading libnsl.so.1 >>>>>>>>>>>> Reading libm.so.2 >>>>>>>>>>>> Reading libscf.so.1 >>>>>>>>>>>> Reading libuutil.so.1 >>>>>>>>>>>> Reading libgen.so.1 >>>>>>>>>>>> Reading libmd.so.1 >>>>>>>>>>>> Reading libmp.so.2 >>>>>>>>>>>> t at 2 (l at 2) stopped in JNI_CreateJavaVM at line 5062 in file >>>>>>>>>>>> "jni.cpp" >>>>>>>>>>>> 5062 jint result = JNI_ERR; >>>>>>>>>>>> (dbx) stop in CompileBroker::compile_method >>>>>>>>>>>> (2) stop in >>>>>>>>>>>> CompileBroker::compile_method(methodHandle,int,int,methodHandl >>>>>>>>>>>> e,int,const >>>>>>>>>>>> >>>>>>>>>>>> char*,Thread*) >>>>>>>>>>>> (dbx) c >>>>>>>>>>>> Reading libverify.so >>>>>>>>>>>> Reading libjava.so >>>>>>>>>>>> Reading libzip.so >>>>>>>>>>>> java version "1.8.0-ea" >>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b86) Java >>>>>>>>>>>> HotSpot(TM) Server VM (build 25.0-b29-internal-debug, mixed >>>>>>>>>>>> mode) >>>>>>>>>>>> >>>>>>>>>>>> execution completed, exit code is 0 >>>>>>>>>>>> (dbx) >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From john.r.rose at oracle.com Fri May 3 00:25:34 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 May 2013 17:25:34 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> Message-ID: <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: > is anyone using env.{sh,csh}? I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John From christian.thalinger at oracle.com Fri May 3 00:28:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 2 May 2013 17:28:50 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> Message-ID: <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> On May 2, 2013, at 5:25 PM, John Rose wrote: > On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: > >> is anyone using env.{sh,csh}? > > I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John I think you're right. Let's remove them with this change then. -- Chris From tim.bell at oracle.com Fri May 3 06:23:51 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 May 2013 23:23:51 -0700 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <5182CB62.30307@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> Message-ID: <518357F7.80203@oracle.com> On 05/ 2/13 01:24 PM, I wrote: > Hi Sundar: > >> Oracle JDK includes Rhino based javax.script implementation (which >> lives mostly in "closed" code). Rhino is being removed from Oracle >> JDK builds and there are the changes to the jdk open repository as >> well like com.sun.script.javascript package, makefiles etc. Please >> review the open jdk changes here: >> >> http://cr.openjdk.java.net/~sundar/8012975/ > > This looks good. Approved. > > Tim Sundar - we have had some breakage in the build forest recently, so to be extra careful I created a forest and then added your changes. I also did some blasting away with 'find ... -print | xargs egrep ...' commands to look for traces of rhino or javascript. I think you need to look at removing these files as well: jdk/make/com/sun/script/Makefile jdk/make/sun/org/mozilla/javascript/Makefile Tim From sundararajan.athijegannathan at oracle.com Fri May 3 06:47:50 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 03 May 2013 12:17:50 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518357F7.80203@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> Message-ID: <51835D96.3060209@oracle.com> On Friday 03 May 2013 11:53 AM, Tim Bell wrote: > On 05/ 2/13 01:24 PM, I wrote: >> Hi Sundar: >> >>> Oracle JDK includes Rhino based javax.script implementation (which >>> lives mostly in "closed" code). Rhino is being removed from Oracle >>> JDK builds and there are the changes to the jdk open repository as >>> well like com.sun.script.javascript package, makefiles etc. Please >>> review the open jdk changes here: >>> >>> http://cr.openjdk.java.net/~sundar/8012975/ >> >> This looks good. Approved. >> >> Tim > > Sundar - we have had some breakage in the build forest recently, so to > be extra careful I created a forest and then added your changes. I > also did some blasting away with 'find ... -print | xargs egrep ...' > commands to look for traces of rhino or javascript. > > I think you need to look at removing these files as well: > > jdk/make/com/sun/script/Makefile > jdk/make/sun/org/mozilla/javascript/Makefile > > Tim > Thanks. Looks like the first one has not been removed. But second one was removed: hg stat shows R make/sun/org/mozilla/javascript/Makefile (also the webrev shows it as removed). Perhaps patch does not take care of deleted files?? I am not sure. Also, build seems to go through without removing first one!! I'll remove that, build/test again and send another webrev. Thanks -Sundar From Alan.Bateman at oracle.com Fri May 3 09:26:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 May 2013 10:26:09 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51835D96.3060209@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> Message-ID: <518382B1.6040501@oracle.com> On 03/05/2013 07:47, A. Sundararajan wrote: > > Thanks. Looks like the first one has not been removed. But second one > was removed: hg stat shows > > R make/sun/org/mozilla/javascript/Makefile > > (also the webrev shows it as removed). Perhaps patch does not take > care of deleted files?? I am not sure. Also, build seems to go through > without removing first one!! > > I'll remove that, build/test again and send another webrev. One other one is make/tools/src/build/tools/deps/refs.allowed. The last two lines can be replaced with: java.beans.PropertyChangeListener=java.util.logging.LogManager,compact1,compact2,compact3 and the comment line about Rhino can be removed. -Alan. From peter.brunet at oracle.com Fri May 3 15:42:55 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 03 May 2013 10:42:55 -0500 Subject: AdapterMethodHandle not found Message-ID: <5183DAFF.3020405@oracle.com> I cloned jdk7u-dev today, via get_source.sh and then built from the jdk/make directory using: make ARCH_DATA_MODEL=32 ALLOW_DOWNLOADS=true NO_DOCS=true The build ran a long time and then failed with: make[3]: Entering directory `/cygdrive/c/Users/Pete/JDK7u/jdk7u-dev/jdk/make/com/sun/jmx' ../../../../build/windows-i586/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp ../../../../build/windows-i586/classes sun.rmi.rmic.Main -classpath "../../../../build/windows-i586/classes" \ -d ../../../../build/windows-i586/classes \ -v1.2 \ -keepgenerated \ javax.management.remote.rmi.RMIConnectionImpl Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle .../jdk/build/windows-i586/classes/java/lang/invoke has a lot of classes, but not that one. Any ideas on how to get past this? Pete From valerie.peng at oracle.com Fri May 3 18:23:03 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 03 May 2013 11:23:03 -0700 Subject: Code review request: 8010192: Enable native JGSS provider on Mac In-Reply-To: <51470ADD.1040001@oracle.com> References: <5146F3CD.3000903@oracle.com> <51470ADD.1040001@oracle.com> Message-ID: <51840087.6090703@oracle.com> So, has this changes been tested against the existing regression tests on Mac? After this, is the native JGSS provider get used on Mac for most if not all Kerberos operation or is it still Java Kerberos? Otherwise, changes look ok to me. Valerie On 03/18/13 05:38, Erik Joelsson wrote: > The build changes look ok. > > /Erik > > On 2013-03-18 12:00, Weijun Wang wrote: >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8010192/webrev.00/ >> >> The Mac native JGSS provider is back. Besides reverting changes made >> in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106, there are: >> >> 1. GSSManagerImpl.java: enable the provider >> 2. SunNativeProvider.java: library name from MIT added >> 3. Update gssapi.h, new lines copied from Mac's gssapi.h >> 4. Liberate a test. >> >> Thanks >> Max From john.r.rose at oracle.com Sat May 4 03:40:29 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 3 May 2013 20:40:29 -0700 Subject: AdapterMethodHandle not found In-Reply-To: <5183DAFF.3020405@oracle.com> References: <5183DAFF.3020405@oracle.com> Message-ID: <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> On May 3, 2013, at 8:42 AM, Pete Brunet wrote: > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle It's a micro-version mismatch, from running a down-rev JVM on an up-rev rt.jar (JDK). But I don't understand why your makefile is running an old JVM on a new rt.jar. That's build voodoo, I presume. ? John From ahughes at redhat.com Sat May 4 16:05:50 2013 From: ahughes at redhat.com (ahughes at redhat.com) Date: Sat, 04 May 2013 16:05:50 +0000 Subject: hg: jdk8/build/jdk: 8011366: Enable debug info on all libraries for OpenJDK builds Message-ID: <20130504160718.DAB8C48811@hg.openjdk.java.net> Changeset: 88125d32eb06 Author: andrew Date: 2013-05-04 17:04 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/88125d32eb06 8011366: Enable debug info on all libraries for OpenJDK builds Summary: The build should not be turning off debugging if it has been requested. Reviewed-by: erikj, dholmes ! makefiles/CompileNativeLibraries.gmk From weijun.wang at oracle.com Sun May 5 13:34:43 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 05 May 2013 21:34:43 +0800 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument Message-ID: <51865FF3.5020907@oracle.com> I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as boot jdk, "bash configure" prompted me to install several packages but running make shows: -----START----- Building Java(TM) for target 'default' in configuration 'linux-x86-normal-server-release' ## Starting langtools make: the `-j' option requires a positive integral argument ... This program built for i686-pc-linux-gnu Report bugs to make: *** [langtools-only] Error 2 -----END----- What's wrong here? Thanks Max From jonathan.gibbons at oracle.com Sun May 5 17:22:18 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 05 May 2013 10:22:18 -0700 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument In-Reply-To: <51865FF3.5020907@oracle.com> References: <51865FF3.5020907@oracle.com> Message-ID: <5186954A.2030002@oracle.com> You should run the build with more logging, to see what actually followed the -j argument. At a guess I would wonder if the intended argument was empty, so -j is trying to read the following option as a positive integer, and reporting the message you see. -- Jon On 05/05/2013 06:34 AM, Weijun Wang wrote: > I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as > boot jdk, "bash configure" prompted me to install several packages but > running make shows: > > -----START----- > Building Java(TM) for target 'default' in configuration > 'linux-x86-normal-server-release' > > ## Starting langtools > make: the `-j' option requires a positive integral argument > ... > This program built for i686-pc-linux-gnu > Report bugs to > make: *** [langtools-only] Error 2 > -----END----- > > What's wrong here? > > Thanks > Max From erik.joelsson at oracle.com Mon May 6 07:35:05 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 06 May 2013 09:35:05 +0200 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument In-Reply-To: <51865FF3.5020907@oracle.com> References: <51865FF3.5020907@oracle.com> Message-ID: <51875D29.4010702@oracle.com> I would be interested to see the spec.gmk generated in the build output directory. Specifically the value of the JOBS variable. /Erik On 2013-05-05 15:34, Weijun Wang wrote: > I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as > boot jdk, "bash configure" prompted me to install several packages but > running make shows: > > -----START----- > Building Java(TM) for target 'default' in configuration > 'linux-x86-normal-server-release' > > ## Starting langtools > make: the `-j' option requires a positive integral argument > ... > This program built for i686-pc-linux-gnu > Report bugs to > make: *** [langtools-only] Error 2 > -----END----- > > What's wrong here? > > Thanks > Max From volker.simonis at gmail.com Mon May 6 08:38:30 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 6 May 2013 10:38:30 +0200 Subject: AdapterMethodHandle not found In-Reply-To: <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> References: <5183DAFF.3020405@oracle.com> <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> Message-ID: What does "../../../../build/windows-i586/bin/java -version" return? That must be HotSpot 24 (i.e. something like '..build 24.0-b34..'). How did you specify your boot-jdk? Maybe you didn't really build a new hotspot but imported it from the boot-jdk and that was too old? If you want you can compare your build logs with our nightly build logs of jdk7u on windows at:http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz Regards Volker On Sat, May 4, 2013 at 5:40 AM, John Rose wrote: > > On May 3, 2013, at 8:42 AM, Pete Brunet wrote: > >> Error occurred during initialization of VM >> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle > > It's a micro-version mismatch, from running a down-rev JVM on an up-rev rt.jar (JDK). > > But I don't understand why your makefile is running an old JVM on a new rt.jar. That's build voodoo, I presume. > > ? John From Sergey.Bylokhov at oracle.com Mon May 6 10:08:09 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 06 May 2013 14:08:09 +0400 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument In-Reply-To: <51865FF3.5020907@oracle.com> References: <51865FF3.5020907@oracle.com> Message-ID: <51878109.5020408@oracle.com> Hi. Weijun. Try to run it with this option: ./configure --with-jobs=1 On 05.05.2013 17:34, Weijun Wang wrote: > I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as > boot jdk, "bash configure" prompted me to install several packages but > running make shows: > > -----START----- > Building Java(TM) for target 'default' in configuration > 'linux-x86-normal-server-release' > > ## Starting langtools > make: the `-j' option requires a positive integral argument > ... > This program built for i686-pc-linux-gnu > Report bugs to > make: *** [langtools-only] Error 2 > -----END----- > > What's wrong here? > > Thanks > Max -- Best regards, Sergey. From weijun.wang at oracle.com Mon May 6 11:01:55 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 06 May 2013 19:01:55 +0800 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument In-Reply-To: <51875D29.4010702@oracle.com> References: <51865FF3.5020907@oracle.com> <51875D29.4010702@oracle.com> Message-ID: <51878DA3.7050200@oracle.com> On 5/6/13 3:35 PM, Erik Joelsson wrote: > I would be interested to see the spec.gmk generated in the build output > directory. Specifically the value of the JOBS variable. JOBS?=0 I noticed the configure output includes checking for number of cores... 1 checking for memory size... 1002 MB checking for appropriate number of jobs to run in parallel... 0 This is a VirtualBox guest. Maybe the memory is too low for a build. With Sergey's suggestion: > Try to run it with this option: > ./configure --with-jobs=1 It becomes JOBS?=1 and make is running now. Anyway, I think I should give it more memory. Thanks Max > > /Erik > > On 2013-05-05 15:34, Weijun Wang wrote: >> I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as >> boot jdk, "bash configure" prompted me to install several packages but >> running make shows: >> >> -----START----- >> Building Java(TM) for target 'default' in configuration >> 'linux-x86-normal-server-release' >> >> ## Starting langtools >> make: the `-j' option requires a positive integral argument >> ... >> This program built for i686-pc-linux-gnu >> Report bugs to >> make: *** [langtools-only] Error 2 >> -----END----- >> >> What's wrong here? >> >> Thanks >> Max From erik.joelsson at oracle.com Mon May 6 11:41:36 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 06 May 2013 13:41:36 +0200 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument In-Reply-To: <51878DA3.7050200@oracle.com> References: <51865FF3.5020907@oracle.com> <51875D29.4010702@oracle.com> <51878DA3.7050200@oracle.com> Message-ID: <518796F0.4050200@oracle.com> On 2013-05-06 13:01, Weijun Wang wrote: > > > On 5/6/13 3:35 PM, Erik Joelsson wrote: >> I would be interested to see the spec.gmk generated in the build output >> directory. Specifically the value of the JOBS variable. > > JOBS?=0 > > I noticed the configure output includes > > checking for number of cores... 1 > checking for memory size... 1002 MB > checking for appropriate number of jobs to run in parallel... 0 > > This is a VirtualBox guest. Maybe the memory is too low for a build. > That looks like a bug in configure. Will file it. Giving it a bit more memory will help though. /Erik > With Sergey's suggestion: > >> Try to run it with this option: >> ./configure --with-jobs=1 > > It becomes > > JOBS?=1 > > and make is running now. Anyway, I think I should give it more memory. > > Thanks > Max > >> >> /Erik >> >> On 2013-05-05 15:34, Weijun Wang wrote: >>> I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as >>> boot jdk, "bash configure" prompted me to install several packages but >>> running make shows: >>> >>> -----START----- >>> Building Java(TM) for target 'default' in configuration >>> 'linux-x86-normal-server-release' >>> >>> ## Starting langtools >>> make: the `-j' option requires a positive integral argument >>> ... >>> This program built for i686-pc-linux-gnu >>> Report bugs to >>> make: *** [langtools-only] Error 2 >>> -----END----- >>> >>> What's wrong here? >>> >>> Thanks >>> Max From weijun.wang at oracle.com Mon May 6 12:32:36 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 06 May 2013 20:32:36 +0800 Subject: Another Ubuntu 13.04 32 bit build failure: No X11/Intrinsic.h Message-ID: <5187A2E4.5090609@oracle.com> Build failed during jdk. Re-run shows $ make jdk-only LOG=debug Running make as '/usr/bin/make VERBOSE= -R -I /mnt/h/more/space/repos/jdk8/tl/common/makefiles SPEC=/space/repos/jdk8/tl/build/linux-x86-normal-server-release/spec.gmk -j1' Building Java(TM) for target 'jdk-only' in configuration '/space/repos/jdk8/tl/build/linux-x86-normal-server-release' ## Starting jdk make[1]: Entering directory `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' /usr/bin/make VERBOSE="" -R -I /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f Import.gmk make[2]: Entering directory `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' make[2]: Nothing to be done for `default'. make[2]: Leaving directory `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' /usr/bin/make VERBOSE="" -R -I /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f GenerateJavaSources.gmk make[2]: Entering directory `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' /bin/mkdir -p /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers (cd /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers && /usr/bin/gcc-4.7 -m32 -o /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c \ \ \ -I/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/include \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/javavm/export \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/javavm/export \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/common \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/common \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/debug \ -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/image/cvutils -lc) In file included from /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c:11:0: /mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt/awt_p.h:44:27: fatal error: X11/Intrinsic.h: No such file or directory compilation terminated. make[2]: *** [/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe] Error 1 make[2]: Leaving directory `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' make[1]: *** [gensrc-only] Error 2 make[1]: Leaving directory `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' make: *** [jdk-only] Error 2 During the configure process, it has asked me to install several packages sudo apt-get install build-essential sudo apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev sudo apt-get install libcups2-dev sudo apt-get install libasound2-dev Still not enough? Thanks Max From Sergey.Bylokhov at oracle.com Mon May 6 12:51:41 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 06 May 2013 16:51:41 +0400 Subject: Another Ubuntu 13.04 32 bit build failure: No X11/Intrinsic.h In-Reply-To: <5187A2E4.5090609@oracle.com> References: <5187A2E4.5090609@oracle.com> Message-ID: <5187A75D.9080101@oracle.com> Hi, Weijun. Try to install libxt-dev. On 06.05.2013 16:32, Weijun Wang wrote: > Build failed during jdk. Re-run shows > > $ make jdk-only LOG=debug > Running make as '/usr/bin/make VERBOSE= -R -I > /mnt/h/more/space/repos/jdk8/tl/common/makefiles > SPEC=/space/repos/jdk8/tl/build/linux-x86-normal-server-release/spec.gmk > -j1' > Building Java(TM) for target 'jdk-only' in configuration > '/space/repos/jdk8/tl/build/linux-x86-normal-server-release' > > ## Starting jdk > make[1]: Entering directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > /usr/bin/make VERBOSE="" -R -I > /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f Import.gmk > make[2]: Entering directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > make[2]: Nothing to be done for `default'. > make[2]: Leaving directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > /usr/bin/make VERBOSE="" -R -I > /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f > GenerateJavaSources.gmk > make[2]: Entering directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > /bin/mkdir -p > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers > (cd > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers > && /usr/bin/gcc-4.7 -m32 -o > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c > \ > \ > \ > > -I/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/include > \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/javavm/export \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/javavm/export \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/common \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/common \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt \ > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/debug \ > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/image/cvutils > -lc) > In file included from > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c:11:0: > /mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt/awt_p.h:44:27: > fatal error: X11/Intrinsic.h: No such file or directory > compilation terminated. > make[2]: *** > [/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe] > Error 1 > make[2]: Leaving directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > make[1]: *** [gensrc-only] Error 2 > make[1]: Leaving directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > make: *** [jdk-only] Error 2 > > During the configure process, it has asked me to install several packages > > sudo apt-get install build-essential > sudo apt-get install libX11-dev libxext-dev libxrender-dev > libxtst-dev > sudo apt-get install libcups2-dev > sudo apt-get install libasound2-dev > > Still not enough? > > Thanks > Max -- Best regards, Sergey. From erik.joelsson at oracle.com Mon May 6 12:56:41 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 06 May 2013 14:56:41 +0200 Subject: Another Ubuntu 13.04 32 bit build failure: No X11/Intrinsic.h In-Reply-To: <5187A2E4.5090609@oracle.com> References: <5187A2E4.5090609@oracle.com> Message-ID: <5187A889.4090006@oracle.com> Unfortunately the list of packages in configure is not complete. On my older ubuntu, that file comes from libxt-dev. /Erik On 2013-05-06 14:32, Weijun Wang wrote: > Build failed during jdk. Re-run shows > > $ make jdk-only LOG=debug > Running make as '/usr/bin/make VERBOSE= -R -I > /mnt/h/more/space/repos/jdk8/tl/common/makefiles > SPEC=/space/repos/jdk8/tl/build/linux-x86-normal-server-release/spec.gmk > -j1' > Building Java(TM) for target 'jdk-only' in configuration > '/space/repos/jdk8/tl/build/linux-x86-normal-server-release' > > ## Starting jdk > make[1]: Entering directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > /usr/bin/make VERBOSE="" -R -I > /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f Import.gmk > make[2]: Entering directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > make[2]: Nothing to be done for `default'. > make[2]: Leaving directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > /usr/bin/make VERBOSE="" -R -I > /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f > GenerateJavaSources.gmk > make[2]: Entering directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > /bin/mkdir -p > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers > (cd > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers > && /usr/bin/gcc-4.7 -m32 -o > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c > \ > \ > \ > > -I/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/include > \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/javavm/export \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/javavm/export \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/common \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/common \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/debug \ > > -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/image/cvutils > -lc) > In file included from > /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c:11:0: > /mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt/awt_p.h:44:27: > fatal error: X11/Intrinsic.h: No such file or directory > compilation terminated. > make[2]: *** > [/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe] > Error 1 > make[2]: Leaving directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > make[1]: *** [gensrc-only] Error 2 > make[1]: Leaving directory > `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' > make: *** [jdk-only] Error 2 > > During the configure process, it has asked me to install several packages > > sudo apt-get install build-essential > sudo apt-get install libX11-dev libxext-dev libxrender-dev > libxtst-dev > sudo apt-get install libcups2-dev > sudo apt-get install libasound2-dev > > Still not enough? > > Thanks > Max From weijun.wang at oracle.com Mon May 6 13:29:23 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 06 May 2013 21:29:23 +0800 Subject: Another Ubuntu 13.04 32 bit build failure: No X11/Intrinsic.h In-Reply-To: <5187A75D.9080101@oracle.com> References: <5187A2E4.5090609@oracle.com> <5187A75D.9080101@oracle.com> Message-ID: <5187B033.40806@oracle.com> On 5/6/13 8:51 PM, Sergey Bylokhov wrote: > Hi, Weijun. > Try to install libxt-dev. Great. It now goes on. Thanks Weijun aka Max > > On 06.05.2013 16:32, Weijun Wang wrote: >> Build failed during jdk. Re-run shows >> >> $ make jdk-only LOG=debug >> Running make as '/usr/bin/make VERBOSE= -R -I >> /mnt/h/more/space/repos/jdk8/tl/common/makefiles >> SPEC=/space/repos/jdk8/tl/build/linux-x86-normal-server-release/spec.gmk >> -j1' >> Building Java(TM) for target 'jdk-only' in configuration >> '/space/repos/jdk8/tl/build/linux-x86-normal-server-release' >> >> ## Starting jdk >> make[1]: Entering directory >> `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' >> /usr/bin/make VERBOSE="" -R -I >> /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f Import.gmk >> make[2]: Entering directory >> `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' >> make[2]: Nothing to be done for `default'. >> make[2]: Leaving directory >> `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' >> /usr/bin/make VERBOSE="" -R -I >> /mnt/h/more/space/repos/jdk8/tl/common/makefiles -f >> GenerateJavaSources.gmk >> make[2]: Entering directory >> `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' >> /bin/mkdir -p >> /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers >> >> (cd >> /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers >> && /usr/bin/gcc-4.7 -m32 -o >> /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe >> /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c >> \ >> \ >> \ >> >> -I/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/include >> \ >> >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/javavm/export \ >> >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/javavm/export \ >> >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/common \ >> >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/common \ >> >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt \ >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/debug \ >> -I/mnt/h/more/space/repos/jdk8/tl/jdk/src/share/native/sun/awt/image/cvutils >> -lc) >> In file included from >> /space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.c:11:0: >> >> /mnt/h/more/space/repos/jdk8/tl/jdk/src/solaris/native/sun/awt/awt_p.h:44:27: >> fatal error: X11/Intrinsic.h: No such file or directory >> compilation terminated. >> make[2]: *** >> [/space/repos/jdk8/tl/build/linux-x86-normal-server-release/jdk/gensrc_x11wrappers/sizer.32.exe] >> Error 1 >> make[2]: Leaving directory >> `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' >> make[1]: *** [gensrc-only] Error 2 >> make[1]: Leaving directory >> `/mnt/h/more/space/repos/jdk8/tl/jdk/makefiles' >> make: *** [jdk-only] Error 2 >> >> During the configure process, it has asked me to install several packages >> >> sudo apt-get install build-essential >> sudo apt-get install libX11-dev libxext-dev libxrender-dev >> libxtst-dev >> sudo apt-get install libcups2-dev >> sudo apt-get install libasound2-dev >> >> Still not enough? >> >> Thanks >> Max > > From weijun.wang at oracle.com Mon May 6 13:44:10 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 06 May 2013 21:44:10 +0800 Subject: jdk8 build failure on xubuntu 13.04 32 bit: make: the `-j' option requires a positive integral argument In-Reply-To: <518796F0.4050200@oracle.com> References: <51865FF3.5020907@oracle.com> <51875D29.4010702@oracle.com> <51878DA3.7050200@oracle.com> <518796F0.4050200@oracle.com> Message-ID: <5187B3AA.3030606@oracle.com> By setting --with-jobs=1, even with only 1GB of memory, build is complete. jdk-only itself takes 15 minutes though. -Max On 5/6/13 7:41 PM, Erik Joelsson wrote: > On 2013-05-06 13:01, Weijun Wang wrote: >> >> >> On 5/6/13 3:35 PM, Erik Joelsson wrote: >>> I would be interested to see the spec.gmk generated in the build output >>> directory. Specifically the value of the JOBS variable. >> >> JOBS?=0 >> >> I noticed the configure output includes >> >> checking for number of cores... 1 >> checking for memory size... 1002 MB >> checking for appropriate number of jobs to run in parallel... 0 >> >> This is a VirtualBox guest. Maybe the memory is too low for a build. >> > That looks like a bug in configure. Will file it. > > Giving it a bit more memory will help though. > > /Erik >> With Sergey's suggestion: >> >>> Try to run it with this option: >>> ./configure --with-jobs=1 >> >> It becomes >> >> JOBS?=1 >> >> and make is running now. Anyway, I think I should give it more memory. >> >> Thanks >> Max >> >>> >>> /Erik >>> >>> On 2013-05-05 15:34, Weijun Wang wrote: >>>> I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as >>>> boot jdk, "bash configure" prompted me to install several packages but >>>> running make shows: >>>> >>>> -----START----- >>>> Building Java(TM) for target 'default' in configuration >>>> 'linux-x86-normal-server-release' >>>> >>>> ## Starting langtools >>>> make: the `-j' option requires a positive integral argument >>>> ... >>>> This program built for i686-pc-linux-gnu >>>> Report bugs to >>>> make: *** [langtools-only] Error 2 >>>> -----END----- >>>> >>>> What's wrong here? >>>> >>>> Thanks >>>> Max From christian.thalinger at oracle.com Mon May 6 16:35:42 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 09:35:42 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> Message-ID: <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> Last warning! If nobody speaks up today I'm going to push this later: http://cr.openjdk.java.net/~twisti/8008772/ -- Chris On May 2, 2013, at 5:28 PM, Christian Thalinger wrote: > > On May 2, 2013, at 5:25 PM, John Rose wrote: > >> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: >> >>> is anyone using env.{sh,csh}? >> >> I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John > > I think you're right. Let's remove them with this change then. > > -- Chris From vladimir.kozlov at oracle.com Mon May 6 16:50:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 May 2013 09:50:16 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> Message-ID: <5187DF48.5070206@oracle.com> Did you use 'hg rename' to move hotspot.script? We need to preserve history. Thanks, Vladimir On 5/6/13 9:35 AM, Christian Thalinger wrote: > Last warning! If nobody speaks up today I'm going to push this later: > > http://cr.openjdk.java.net/~twisti/8008772/ > > -- Chris > > On May 2, 2013, at 5:28 PM, Christian Thalinger wrote: > >> >> On May 2, 2013, at 5:25 PM, John Rose wrote: >> >>> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: >>> >>>> is anyone using env.{sh,csh}? >>> >>> I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John >> >> I think you're right. Let's remove them with this change then. >> >> -- Chris > From christian.thalinger at oracle.com Mon May 6 17:20:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 10:20:55 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <5187DF48.5070206@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> <5187DF48.5070206@oracle.com> Message-ID: <86D5AC97-5DE8-4E96-9B56-F7F75066302E@oracle.com> On May 6, 2013, at 9:50 AM, Vladimir Kozlov wrote: > Did you use 'hg rename' to move hotspot.script? We need to preserve history. hg move, yes. An hg diff on my machine shows a diff: cthaling at macbook:~/ws/8008772$ hg di make/hotspot.script diff --git a/src/os/posix/launcher/launcher.script b/make/hotspot.script copy from src/os/posix/launcher/launcher.script copy to make/hotspot.script --- a/src/os/posix/launcher/launcher.script +++ b/make/hotspot.script @@ -72,6 +72,7 @@ REL_MYDIR=`dirname $0` MYDIR=`cd $REL_MYDIR && pwd` +# # Look whether the user wants to run inside gdb case "$1" in -gdb) @@ -95,16 +96,14 @@ -- Chris > > Thanks, > Vladimir > > > On 5/6/13 9:35 AM, Christian Thalinger wrote: >> Last warning! If nobody speaks up today I'm going to push this later: >> >> http://cr.openjdk.java.net/~twisti/8008772/ >> >> -- Chris >> >> On May 2, 2013, at 5:28 PM, Christian Thalinger wrote: >> >>> >>> On May 2, 2013, at 5:25 PM, John Rose wrote: >>> >>>> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: >>>> >>>>> is anyone using env.{sh,csh}? >>>> >>>> I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John >>> >>> I think you're right. Let's remove them with this change then. >>> >>> -- Chris >> From vladimir.kozlov at oracle.com Mon May 6 17:34:41 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 May 2013 10:34:41 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <86D5AC97-5DE8-4E96-9B56-F7F75066302E@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> <5187DF48.5070206@oracle.com> <86D5AC97-5DE8-4E96-9B56-F7F75066302E@oracle.com> Message-ID: <5187E9B1.8070707@oracle.com> I see, you also modified it. Okay I agree with changes. Thanks Vladimir On 5/6/13 10:20 AM, Christian Thalinger wrote: > > On May 6, 2013, at 9:50 AM, Vladimir Kozlov wrote: > >> Did you use 'hg rename' to move hotspot.script? We need to preserve history. > > hg move, yes. An hg diff on my machine shows a diff: > > cthaling at macbook:~/ws/8008772$ hg di make/hotspot.script > diff --git a/src/os/posix/launcher/launcher.script b/make/hotspot.script > copy from src/os/posix/launcher/launcher.script > copy to make/hotspot.script > --- a/src/os/posix/launcher/launcher.script > +++ b/make/hotspot.script > @@ -72,6 +72,7 @@ > REL_MYDIR=`dirname $0` > MYDIR=`cd $REL_MYDIR && pwd` > > +# > # Look whether the user wants to run inside gdb > case "$1" in > -gdb) > @@ -95,16 +96,14 @@ > > -- Chris > >> >> Thanks, >> Vladimir >> >> >> On 5/6/13 9:35 AM, Christian Thalinger wrote: >>> Last warning! If nobody speaks up today I'm going to push this later: >>> >>> http://cr.openjdk.java.net/~twisti/8008772/ >>> >>> -- Chris >>> >>> On May 2, 2013, at 5:28 PM, Christian Thalinger wrote: >>> >>>> >>>> On May 2, 2013, at 5:25 PM, John Rose wrote: >>>> >>>>> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: >>>>> >>>>>> is anyone using env.{sh,csh}? >>>>> >>>>> I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John >>>> >>>> I think you're right. Let's remove them with this change then. >>>> >>>> -- Chris >>> > From mike.duigou at oracle.com Mon May 6 17:40:08 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 6 May 2013 10:40:08 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <86D5AC97-5DE8-4E96-9B56-F7F75066302E@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> <5187DF48.5070206@oracle.com> <86D5AC97-5DE8-4E96-9B56-F7F75066302E@oracle.com> Message-ID: <6EF8A2BF-E71B-429A-98B9-FA4F913BD3D8@oracle.com> You may wish to sync your custom webrev script with the mainline webrev.ksh. It recently improved it's support for including a proper hg changeset rather than the patches that webrev has traditional generated. The improved changeset support handles hg copies and moves correctly whereas legacy webrev generated patches do not. Mike On May 6 2013, at 10:20 , Christian Thalinger wrote: > > On May 6, 2013, at 9:50 AM, Vladimir Kozlov wrote: > >> Did you use 'hg rename' to move hotspot.script? We need to preserve history. > > hg move, yes. An hg diff on my machine shows a diff: > > cthaling at macbook:~/ws/8008772$ hg di make/hotspot.script > diff --git a/src/os/posix/launcher/launcher.script b/make/hotspot.script > copy from src/os/posix/launcher/launcher.script > copy to make/hotspot.script > --- a/src/os/posix/launcher/launcher.script > +++ b/make/hotspot.script > @@ -72,6 +72,7 @@ > REL_MYDIR=`dirname $0` > MYDIR=`cd $REL_MYDIR && pwd` > > +# > # Look whether the user wants to run inside gdb > case "$1" in > -gdb) > @@ -95,16 +96,14 @@ > > -- Chris > >> >> Thanks, >> Vladimir >> >> >> On 5/6/13 9:35 AM, Christian Thalinger wrote: >>> Last warning! If nobody speaks up today I'm going to push this later: >>> >>> http://cr.openjdk.java.net/~twisti/8008772/ >>> >>> -- Chris >>> >>> On May 2, 2013, at 5:28 PM, Christian Thalinger wrote: >>> >>>> >>>> On May 2, 2013, at 5:25 PM, John Rose wrote: >>>> >>>>> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: >>>>> >>>>>> is anyone using env.{sh,csh}? >>>>> >>>>> I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John >>>> >>>> I think you're right. Let's remove them with this change then. >>>> >>>> -- Chris >>> > From christian.thalinger at oracle.com Mon May 6 21:26:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 14:26:40 -0700 Subject: RFR (M): 8008772: remove gamma launcher In-Reply-To: <5187E9B1.8070707@oracle.com> References: <5C64AF5E-EDD5-4669-9777-5FF7CE6E615F@oracle.com> <51759F6B.7080808@oracle.com> <764DA08E-5A58-4FD4-BB48-0F4F13401BCC@oracle.com> <51764FDE.2090205@oracle.com> <517669A6.8030705@oracle.com> <5176CD8E.5060704@oracle.com> <1897490C-0C9E-4E70-BA70-22C5CB1CDAE3@oracle.com> <5176D417.3040202@oracle.com> <51817DED.2050603@oracle.com> <51818766.20604@oracle.com> <00d901ce46b3$28037a90$780a6fb0$@tornqvist@oracle.com> <51818E47.1050605@oracle.com> <96D28554-AC5A-40EA-A763-ABC554D650DC@oracle.com> <9626A9E3-7FE7-49AA-80B2-ACA6BC01EFD1@oracle.com> <47BCCD49-D0D9-45C2-9DC8-9A96F1094F35@oracle.com> <920F24B7-3D5C-4170-8BAC-1E3D88AAEBE9@oracle.com> <7AC60D13-DEFF-41F0-9511-E19882879965@oracle.com> <5187DF48.5070206@oracle.com> <86D5AC97-5DE8-4E96-9B56-F7F75066302E@oracle.com> <5187E9B1.8070707@oracle.com> Message-ID: On May 6, 2013, at 10:34 AM, Vladimir Kozlov wrote: > I see, you also modified it. Okay I agree with changes. FTR: diff --git a/src/os/posix/launcher/launcher.script b/make/hotspot.script copy from src/os/posix/launcher/launcher.script copy to make/hotspot.script --- a/src/os/posix/launcher/launcher.script +++ b/make/hotspot.script @@ -72,6 +72,7 @@ REL_MYDIR=`dirname $0` MYDIR=`cd $REL_MYDIR && pwd` +# # Look whether the user wants to run inside gdb case "$1" in -gdb) @@ -95,16 +96,14 @@ ;; esac -JDK= -if [ "${ALT_JAVA_HOME}" = "" ]; then - . ${MYDIR}/jdkpath.sh +if [ "${ALT_JAVA_HOME}" != "" ]; then + JDK=${ALT_JAVA_HOME%%/jre} else - JDK=${ALT_JAVA_HOME%%/jre}; + JDK=@@JDK_IMPORT_PATH@@ fi if [ "${JDK}" = "" ]; then - echo Failed to find JDK. ALT_JAVA_HOME is not set or ./jdkpath.sh is empty or not found. - exit 1 + echo "Failed to find JDK. Either ALT_JAVA_HOME is not set or JDK_IMPORT_PATH is empty." fi # We will set the LD_LIBRARY_PATH as follows: @@ -142,12 +141,12 @@ export LD_LIBRARY_PATH fi -JPARMS="$@ $JAVA_ARGS"; +JPARMS="-Dsun.java.launcher=gamma -XXaltjvm=$MYDIR $@ $JAVA_ARGS"; -# Locate the gamma development launcher -LAUNCHER=${MYDIR}/gamma +# Locate the java launcher +LAUNCHER=$JDK/bin/java if [ ! -x $LAUNCHER ] ; then - echo Error: Cannot find the gamma development launcher \"$LAUNCHER\" + echo Error: Cannot find the java launcher \"$LAUNCHER\" exit 1 fi @@ -166,9 +165,10 @@ file $LAUNCHER directory $GDBSRCDIR # Get us to a point where we can set breakpoints in libjvm.so -break InitializeJVM +set breakpoint pending on +break JNI_CreateJavaVM run -# Stop in InitializeJVM +# Stop in JNI_CreateJavaVM delete 1 # We can now set breakpoints wherever we like EOF @@ -199,7 +199,7 @@ rm -f $GDBSCR ;; dbx) - $DBX -s $HOME/.dbxrc $LAUNCHER $JPARMS + $DBX -s $HOME/.dbxrc -c "loadobject -load libjvm.so; stop in JNI_CreateJavaVM; run $JPARMS; delete all" $LAUNCHER ;; valgrind) echo Warning: Defaulting to 16Mb heap to make Valgrind run faster, use -Xmx for larger heap > > Thanks > Vladimir > > On 5/6/13 10:20 AM, Christian Thalinger wrote: >> >> On May 6, 2013, at 9:50 AM, Vladimir Kozlov wrote: >> >>> Did you use 'hg rename' to move hotspot.script? We need to preserve history. >> >> hg move, yes. An hg diff on my machine shows a diff: >> >> cthaling at macbook:~/ws/8008772$ hg di make/hotspot.script >> diff --git a/src/os/posix/launcher/launcher.script b/make/hotspot.script >> copy from src/os/posix/launcher/launcher.script >> copy to make/hotspot.script >> --- a/src/os/posix/launcher/launcher.script >> +++ b/make/hotspot.script >> @@ -72,6 +72,7 @@ >> REL_MYDIR=`dirname $0` >> MYDIR=`cd $REL_MYDIR && pwd` >> >> +# >> # Look whether the user wants to run inside gdb >> case "$1" in >> -gdb) >> @@ -95,16 +96,14 @@ >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 5/6/13 9:35 AM, Christian Thalinger wrote: >>>> Last warning! If nobody speaks up today I'm going to push this later: >>>> >>>> http://cr.openjdk.java.net/~twisti/8008772/ >>>> >>>> -- Chris >>>> >>>> On May 2, 2013, at 5:28 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On May 2, 2013, at 5:25 PM, John Rose wrote: >>>>> >>>>>> On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: >>>>>> >>>>>>> is anyone using env.{sh,csh}? >>>>>> >>>>>> I'll suggest that the answer is going to be "no". I think very few people have ever used them. ? John >>>>> >>>>> I think you're right. Let's remove them with this change then. >>>>> >>>>> -- Chris >>>> >> From peter.brunet at oracle.com Tue May 7 01:10:09 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Mon, 06 May 2013 20:10:09 -0500 Subject: AdapterMethodHandle not found In-Reply-To: References: <5183DAFF.3020405@oracle.com> <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> Message-ID: <51885471.40001@oracle.com> I tried changing my ALT_BOOTDIR from my normal 64 bit 7u21 installation to the 7u80 tarball I extracted, but got: make[2]: *** No rule to make target `../../../build/windows-i586/btjars/addjsum.jar', needed by `../../../build/windows-i586/lib/classlist'. Stop. FWIW, my ALT_JDK_IMPORT_PATH points at 7u80. I changed my ALT_BOOTDIR back to 7u21 and did a full build, not just jdk, and after a three hour build time all is well. Pete On 5/6/13 3:38 AM, Volker Simonis wrote: > What does "../../../../build/windows-i586/bin/java -version" return? > That must be HotSpot 24 (i.e. something like '..build 24.0-b34..'). > > How did you specify your boot-jdk? Maybe you didn't really build a new > hotspot but imported it from the boot-jdk and that was too old? > > If you want you can compare your build logs with our nightly build > logs of jdk7u on windows > at:http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz > > Regards > Volker > > > On Sat, May 4, 2013 at 5:40 AM, John Rose wrote: >> On May 3, 2013, at 8:42 AM, Pete Brunet wrote: >> >>> Error occurred during initialization of VM >>> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle >> It's a micro-version mismatch, from running a down-rev JVM on an up-rev rt.jar (JDK). >> >> But I don't understand why your makefile is running an old JVM on a new rt.jar. That's build voodoo, I presume. >> >> ? John From martinrb at google.com Tue May 7 03:19:56 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 May 2013 20:19:56 -0700 Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <1646204162.769290.1365440387286.JavaMail.root@redhat.com> <5163661C.5080700@oracle.com> <516396F6.30707@oracle.com> <1135652122.2176747.1365600923712.JavaMail.root@redhat.com> <5166205F.4060300@oracle.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> Message-ID: On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes wrote: > HotSpot is even more of a problem because not being able to commit directly > risks people losing credit for the work they've done and, with an open > source > project, credit is the only reward. > It *is* possible with mercurial to create/import/manipulate changesets with a different user, so that credit remains with the true author even when first submitted into mercurial by an Oracle employee. And that should be the standard practice. From david.holmes at oracle.com Tue May 7 04:10:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 May 2013 14:10:20 +1000 Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <1646204162.769290.1365440387286.JavaMail.root@redhat.com> <5163661C.5080700@oracle.com> <516396F6.30707@oracle.com> <1135652122.2176747.1365600923712.JavaMail.root@redhat.com> <5166205F.4060300@oracle.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> Message-ID: <51887EAC.60804@oracle.com> On 7/05/2013 1:19 PM, Martin Buchholz wrote: > On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes > wrote: > > HotSpot is even more of a problem because not being able to commit > directly > risks people losing credit for the work they've done and, with an > open source > project, credit is the only reward. > > > It *is* possible with mercurial to create/import/manipulate changesets > with a different user, so that credit remains with the true author even > when first submitted into mercurial by an Oracle employee. And that > should be the standard practice. Absolutely! If a non-Oracle person can create a changeset then the Oracle sponsor can import it and push via JPRT. Otherwise the sponsor should create a changeset with a Contributed-by attribution. David From david.holmes at oracle.com Tue May 7 05:33:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 May 2013 15:33:29 +1000 Subject: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security In-Reply-To: <517FD910.6050908@oracle.com> References: <517FD910.6050908@oracle.com> Message-ID: <51889229.9090801@oracle.com> Erik, Was this tested with a Profiles build? The changes to the RT_JAR_INCLUDES variable has me concerned. Thanks, David On 1/05/2013 12:45 AM, Erik Joelsson wrote: > With this patch the security tests will again be runnable on the > exploded jdk image. The main changes are: > > * The security classes are compiled separately to a different output > directory. > * The security jars are created in the jdk target (instead of images) > and put in the jdk/lib/... directories. > > Also did: > * Removed now redundant entries in rt.jar exclude list > * Changed source location for signing unsigned jars > * Made the SetupJavaCompilation macro more friendly with multiple setups > sharing output directories. > > http://cr.openjdk.java.net/~erikj/8009280/webrev.jdk.01/ > http://cr.openjdk.java.net/~erikj/8009280/webrev.root.01/ > > /Erik From volker.simonis at gmail.com Tue May 7 08:59:57 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 7 May 2013 10:59:57 +0200 Subject: AdapterMethodHandle not found In-Reply-To: <51885471.40001@oracle.com> References: <5183DAFF.3020405@oracle.com> <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> <51885471.40001@oracle.com> Message-ID: On Tue, May 7, 2013 at 3:10 AM, Pete Brunet wrote: > I tried changing my ALT_BOOTDIR from my normal 64 bit 7u21 installation > to the 7u80 tarball I extracted, but got: > make[2]: *** No rule to make target > `../../../build/windows-i586/btjars/addjsum.jar', needed by > `../../../build/windows-i586/lib/classlist'. Stop. > > FWIW, my ALT_JDK_IMPORT_PATH points at 7u80. > > Using an IMPORT_JDK has become quite tricky and it seems that it only works reliable if you use a build of the exact same version you are building as import jdk. Just yesterday I had a similar problem with JDK8 where I used a 4 weeks old import jdk to build a brand new version of the 'jdk' forest. It failed because during the build the VM from the import JDK is used together with the newly build jdk classes but there was a mismatch in the unsafe primitives requested by the Unsafe class and those provided by the VM. So the interface between the HotSpot VM and the class library has become quite volatile (and it is still not documented anywhere:( > I changed my ALT_BOOTDIR back to 7u21 and did a full build, not just > jdk, and after a three hour build time all is well. > > Pete > > On 5/6/13 3:38 AM, Volker Simonis wrote: > > What does "../../../../build/windows-i586/bin/java -version" return? > > That must be HotSpot 24 (i.e. something like '..build 24.0-b34..'). > > > > How did you specify your boot-jdk? Maybe you didn't really build a new > > hotspot but imported it from the boot-jdk and that was too old? > > > > If you want you can compare your build logs with our nightly build > > logs of jdk7u on windows > > at: > http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz > > > > Regards > > Volker > > > > > > On Sat, May 4, 2013 at 5:40 AM, John Rose > wrote: > >> On May 3, 2013, at 8:42 AM, Pete Brunet > wrote: > >> > >>> Error occurred during initialization of VM > >>> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle > >> It's a micro-version mismatch, from running a down-rev JVM on an up-rev > rt.jar (JDK). > >> > >> But I don't understand why your makefile is running an old JVM on a new > rt.jar. That's build voodoo, I presume. > >> > >> ? John > > From erik.joelsson at oracle.com Tue May 7 09:22:04 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 May 2013 11:22:04 +0200 Subject: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security In-Reply-To: <51889229.9090801@oracle.com> References: <517FD910.6050908@oracle.com> <51889229.9090801@oracle.com> Message-ID: <5188C7BC.7020804@oracle.com> It seems to work for me. The reason I removed things from RT_JAR_EXCLUDES that are no longer present in jdk/classes outputdir. /Erik On 2013-05-07 07:33, David Holmes wrote: > Erik, > > Was this tested with a Profiles build? The changes to the > RT_JAR_INCLUDES variable has me concerned. > > Thanks, > David > > On 1/05/2013 12:45 AM, Erik Joelsson wrote: >> With this patch the security tests will again be runnable on the >> exploded jdk image. The main changes are: >> >> * The security classes are compiled separately to a different output >> directory. >> * The security jars are created in the jdk target (instead of images) >> and put in the jdk/lib/... directories. >> >> Also did: >> * Removed now redundant entries in rt.jar exclude list >> * Changed source location for signing unsigned jars >> * Made the SetupJavaCompilation macro more friendly with multiple setups >> sharing output directories. >> >> http://cr.openjdk.java.net/~erikj/8009280/webrev.jdk.01/ >> http://cr.openjdk.java.net/~erikj/8009280/webrev.root.01/ >> >> /Erik From david.holmes at oracle.com Tue May 7 09:37:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 May 2013 19:37:41 +1000 Subject: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security In-Reply-To: <5188C7BC.7020804@oracle.com> References: <517FD910.6050908@oracle.com> <51889229.9090801@oracle.com> <5188C7BC.7020804@oracle.com> Message-ID: <5188CB65.8040107@oracle.com> On 7/05/2013 7:22 PM, Erik Joelsson wrote: > It seems to work for me. > > The reason I removed things from RT_JAR_EXCLUDES that are no longer > present in jdk/classes outputdir. Ah okay that should be fine then. If they aren't there in the first place then no need to exclude :) Thanks, David > /Erik > > On 2013-05-07 07:33, David Holmes wrote: >> Erik, >> >> Was this tested with a Profiles build? The changes to the >> RT_JAR_INCLUDES variable has me concerned. >> >> Thanks, >> David >> >> On 1/05/2013 12:45 AM, Erik Joelsson wrote: >>> With this patch the security tests will again be runnable on the >>> exploded jdk image. The main changes are: >>> >>> * The security classes are compiled separately to a different output >>> directory. >>> * The security jars are created in the jdk target (instead of images) >>> and put in the jdk/lib/... directories. >>> >>> Also did: >>> * Removed now redundant entries in rt.jar exclude list >>> * Changed source location for signing unsigned jars >>> * Made the SetupJavaCompilation macro more friendly with multiple setups >>> sharing output directories. >>> >>> http://cr.openjdk.java.net/~erikj/8009280/webrev.jdk.01/ >>> http://cr.openjdk.java.net/~erikj/8009280/webrev.root.01/ >>> >>> /Erik From david.holmes at oracle.com Tue May 7 11:54:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 May 2013 21:54:21 +1000 Subject: Exporting symbols on OSX ? Message-ID: <5188EB6D.7050100@oracle.com> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported. However the OSX linker does support -exported_symbols_list https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ). Does anyone have experience using this such that we can get the hotspot build fixed? Thanks, David From Alan.Bateman at oracle.com Tue May 7 13:05:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 May 2013 14:05:13 +0100 Subject: 8013652: (profiles) Add javax.script to compact1 Message-ID: <5188FC09.2050501@oracle.com> I'd like to propose adding javax.script to the compact1 builds (it has been in compact3 to date). The rational is to provide a supported way for applications running on the smallest profile make use of scripting languages. The original goal of compact1 was to provide a migration target for applications that are currently running on CDC / Foundation Profile so this change does broaden its potential usage a bit. In footprint terms then javax.script is tiny so it doesn't make a significant difference. The build changes requires are trivial (see attached) and just move java.script from PROFILE_3_RTJAR_INCLUDE_PACKAGES to PROFILE_1_RTJAR_INCLUDE_PACKAGES. Note that the changes assume that Sundar's removing of Rhino (JDK-7175133) is complete. This work is currently in review on core-libs-dev and build-dev. -Alan. diff --git a/makefiles/profile-rtjar-includes.txt b/makefiles/profile-rtjar-includes.txt --- a/makefiles/profile-rtjar-includes.txt +++ b/makefiles/profile-rtjar-includes.txt @@ -57,6 +57,7 @@ java/time \ java/util \ javax/net \ + javax/script \ javax/security \ jdk \ sun/invoke \ @@ -124,7 +125,6 @@ javax/lang/model \ javax/management \ javax/naming \ - javax/script \ javax/security/auth/kerberos \ javax/security/sasl \ javax/smartcardio \ From erik.joelsson at oracle.com Tue May 7 13:56:35 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 May 2013 15:56:35 +0200 Subject: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security In-Reply-To: <517FD910.6050908@oracle.com> References: <517FD910.6050908@oracle.com> Message-ID: <51890813.3050707@oracle.com> This patch didn't work with sjavac enabled. Back to the drawing board. /Erik On 2013-04-30 16:45, Erik Joelsson wrote: > With this patch the security tests will again be runnable on the > exploded jdk image. The main changes are: > > * The security classes are compiled separately to a different output > directory. > * The security jars are created in the jdk target (instead of images) > and put in the jdk/lib/... directories. > > Also did: > * Removed now redundant entries in rt.jar exclude list > * Changed source location for signing unsigned jars > * Made the SetupJavaCompilation macro more friendly with multiple > setups sharing output directories. > > http://cr.openjdk.java.net/~erikj/8009280/webrev.jdk.01/ > http://cr.openjdk.java.net/~erikj/8009280/webrev.root.01/ > > /Erik From gnu.andrew at redhat.com Tue May 7 13:57:50 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 7 May 2013 09:57:50 -0400 (EDT) Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: <51887EAC.60804@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <516396F6.30707@oracle.com> <1135652122.2176747.1365600923712.JavaMail.root@redhat.com> <5166205F.4060300@oracle.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> Message-ID: <630646019.8220662.1367935070589.JavaMail.root@redhat.com> ----- Original Message ----- > On 7/05/2013 1:19 PM, Martin Buchholz wrote: > > On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes > > wrote: > > > > HotSpot is even more of a problem because not being able to commit > > directly > > risks people losing credit for the work they've done and, with an > > open source > > project, credit is the only reward. > > > > > > It *is* possible with mercurial to create/import/manipulate changesets > > with a different user, so that credit remains with the true author even > > when first submitted into mercurial by an Oracle employee. And that > > should be the standard practice. > > Absolutely! If a non-Oracle person can create a changeset then the > Oracle sponsor can import it and push via JPRT. Otherwise the sponsor > should create a changeset with a Contributed-by attribution. > Indeed. I do this with the Oracle patches when applying them to IcedTea. The problem is how this gets done is down to the sponsor; I've had ones that have been imported, ones where I've just been giving the Contributed-by attribution (despite having commit rights) and at least one with no credit at all. A simple solution to this would be to setup a hotspot-jprt tree where non-Oracle people can commit their changesets. An Oracle employee can then run it through JPRT and pull it into one of the other trees, in much the same way trees are already promoted to the main HotSpot & jdk8 trees. This has the advantage that the committer retains control of their changeset and also means that bulk JPRT processing could be performed if appropriate. > David > -- 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 mandy.chung at oracle.com Tue May 7 15:05:54 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 07 May 2013 08:05:54 -0700 Subject: 8013652: (profiles) Add javax.script to compact1 In-Reply-To: <5188FC09.2050501@oracle.com> References: <5188FC09.2050501@oracle.com> Message-ID: <51891852.2000903@oracle.com> Looks good to me. Mandy On 5/7/2013 6:05 AM, Alan Bateman wrote: > > I'd like to propose adding javax.script to the compact1 builds (it has > been in compact3 to date). The rational is to provide a supported way > for applications running on the smallest profile make use of scripting > languages. The original goal of compact1 was to provide a migration > target for applications that are currently running on CDC / Foundation > Profile so this change does broaden its potential usage a bit. In > footprint terms then javax.script is tiny so it doesn't make a > significant difference. > > The build changes requires are trivial (see attached) and just move > java.script from PROFILE_3_RTJAR_INCLUDE_PACKAGES to > PROFILE_1_RTJAR_INCLUDE_PACKAGES. Note that the changes assume that > Sundar's removing of Rhino (JDK-7175133) is complete. This work is > currently in review on core-libs-dev and build-dev. > > -Alan. > > > diff --git a/makefiles/profile-rtjar-includes.txt > b/makefiles/profile-rtjar-includes.txt > --- a/makefiles/profile-rtjar-includes.txt > +++ b/makefiles/profile-rtjar-includes.txt > @@ -57,6 +57,7 @@ > java/time \ > java/util \ > javax/net \ > + javax/script \ > javax/security \ > jdk \ > sun/invoke \ > @@ -124,7 +125,6 @@ > javax/lang/model \ > javax/management \ > javax/naming \ > - javax/script \ > javax/security/auth/kerberos \ > javax/security/sasl \ > javax/smartcardio \ From david.dehaven at oracle.com Tue May 7 16:55:04 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 7 May 2013 09:55:04 -0700 Subject: Exporting symbols on OSX ? In-Reply-To: <5188EB6D.7050100@oracle.com> References: <5188EB6D.7050100@oracle.com> Message-ID: <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> > We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported. > > However the OSX linker does support -exported_symbols_list > > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html > > so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ). > > Does anyone have experience using this such that we can get the hotspot build fixed? Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling. Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not. -DrD- From daniel.daugherty at oracle.com Tue May 7 17:05:01 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 07 May 2013 11:05:01 -0600 Subject: Exporting symbols on OSX ? In-Reply-To: <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> References: <5188EB6D.7050100@oracle.com> <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> Message-ID: <5189343D.10403@oracle.com> On 5/7/13 10:55 AM, David DeHaven wrote: >> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported. >> >> However the OSX linker does support -exported_symbols_list >> >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html >> >> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ). >> >> Does anyone have experience using this such that we can get the hotspot build fixed? > Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling. > > Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not. > > -DrD- > The HotSpot fix is being reviewed on hotspot-runtime-dev at openjdk.java.net under the following subject line: Review request for JDK-8009729: Refix hotspot jni_.h JNIEXPORT and JNIIMPORT definitions to match jdk version Dan From david.katleman at oracle.com Tue May 7 18:04:03 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:04:03 +0000 Subject: hg: jdk8/build: Added tag jdk8-b88 for changeset e1a929afcfc4 Message-ID: <20130507180403.91EE348887@hg.openjdk.java.net> Changeset: 8fb91165e596 Author: katleman Date: 2013-05-02 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/8fb91165e596 Added tag jdk8-b88 for changeset e1a929afcfc4 ! .hgtags From david.katleman at oracle.com Tue May 7 18:04:20 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:04:20 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b88 for changeset 4e3a881ebb1e Message-ID: <20130507180421.9CB6948888@hg.openjdk.java.net> Changeset: 1f13a798d1b8 Author: katleman Date: 2013-05-02 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/1f13a798d1b8 Added tag jdk8-b88 for changeset 4e3a881ebb1e ! .hgtags From david.katleman at oracle.com Tue May 7 18:06:04 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:06:04 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b88 for changeset 24fa5452e5d4 Message-ID: <20130507180607.46C8A4888B@hg.openjdk.java.net> Changeset: 88838e08e4ef Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/88838e08e4ef Added tag jdk8-b88 for changeset 24fa5452e5d4 ! .hgtags From david.katleman at oracle.com Tue May 7 18:04:58 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:04:58 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b88 for changeset 8482058e74bc Message-ID: <20130507180505.CE32F48889@hg.openjdk.java.net> Changeset: d0081bfc425c Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d0081bfc425c Added tag jdk8-b88 for changeset 8482058e74bc ! .hgtags From david.katleman at oracle.com Tue May 7 18:05:55 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:05:55 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b88 for changeset 7122f7bb0fcc Message-ID: <20130507180600.0D0624888A@hg.openjdk.java.net> Changeset: 21f75e572cb3 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/21f75e572cb3 Added tag jdk8-b88 for changeset 7122f7bb0fcc ! .hgtags From david.katleman at oracle.com Tue May 7 18:06:16 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:06:16 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130507180648.351854888C@hg.openjdk.java.net> Changeset: 1daef88acff2 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1daef88acff2 Added tag jdk8-b88 for changeset 8dbb4b159e04 ! .hgtags Changeset: 7ba77fff0ef6 Author: katleman Date: 2013-05-07 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7ba77fff0ef6 Merge From david.katleman at oracle.com Tue May 7 18:08:46 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:08:46 +0000 Subject: hg: jdk8/build/nashorn: Added tag jdk8-b88 for changeset 40c107d1ae6f Message-ID: <20130507180848.0E8C14888E@hg.openjdk.java.net> Changeset: 501bc4aeb1b1 Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/501bc4aeb1b1 Added tag jdk8-b88 for changeset 40c107d1ae6f ! .hgtags From david.dehaven at oracle.com Tue May 7 18:12:12 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 7 May 2013 11:12:12 -0700 Subject: Exporting symbols on OSX ? In-Reply-To: <5189343D.10403@oracle.com> References: <5188EB6D.7050100@oracle.com> <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> <5189343D.10403@oracle.com> Message-ID: >>> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported. >>> >>> However the OSX linker does support -exported_symbols_list >>> >>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html >>> >>> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ). >>> >>> Does anyone have experience using this such that we can get the hotspot build fixed? >> Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling. >> >> Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not. >> >> -DrD- >> > The HotSpot fix is being reviewed on hotspot-runtime-dev at openjdk.java.net > under the following subject line: > > Review request for JDK-8009729: Refix hotspot jni_.h JNIEXPORT and JNIIMPORT definitions to match jdk version Ok, good. The next step would be to modify the build system to set -fvisibility=hidden in the CFLAGS. There were a couple issues in jdk with this, but they should be easily resolved (some might have been already along with the JNIEXPORT patch). (Insert standard disclaimer of needing a full round of SQE testing, etc, so on and so forth, yadda yadda yadda...) I'm curious how much this will shrink the JRE image... two level namespace symbols can take up quite a bit of space. -DrD- From david.katleman at oracle.com Tue May 7 18:08:24 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 18:08:24 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b88 for changeset a1e10f3adc47 Message-ID: <20130507180830.BFC124888D@hg.openjdk.java.net> Changeset: adec2a5d510a Author: katleman Date: 2013-05-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/adec2a5d510a Added tag jdk8-b88 for changeset a1e10f3adc47 ! .hgtags From kellyohair at gmail.com Tue May 7 20:13:09 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Tue, 7 May 2013 13:13:09 -0700 Subject: AdapterMethodHandle not found In-Reply-To: References: <5183DAFF.3020405@oracle.com> <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> <51885471.40001@oracle.com> Message-ID: On May 7, 2013, at 1:59 AM, Volker Simonis wrote: > On Tue, May 7, 2013 at 3:10 AM, Pete Brunet wrote: > >> I tried changing my ALT_BOOTDIR from my normal 64 bit 7u21 installation >> to the 7u80 tarball I extracted, but got: >> make[2]: *** No rule to make target >> `../../../build/windows-i586/btjars/addjsum.jar', needed by >> `../../../build/windows-i586/lib/classlist'. Stop. >> >> FWIW, my ALT_JDK_IMPORT_PATH points at 7u80. >> >> > Using an IMPORT_JDK has become quite tricky and it seems that it only works > reliable if you use a build of the exact same version you are building as > import jdk. That IS the way IMPORT_JDK is defined, it must be a recent JDK build, anything else can be unreliable. Any flag day changes (like jdk<->vm interface changes) will mess you up. I thought that was well documented somewhere. -kto > > Just yesterday I had a similar problem with JDK8 where I used a 4 weeks old > import jdk to build a brand new version of the 'jdk' forest. It failed > because during the build the VM from the import JDK is used together with > the newly build jdk classes but there was a mismatch in the unsafe > primitives requested by the Unsafe class and those provided by the VM. > > So the interface between the HotSpot VM and the class library has become > quite volatile (and it is still not documented anywhere:( > > >> I changed my ALT_BOOTDIR back to 7u21 and did a full build, not just >> jdk, and after a three hour build time all is well. >> >> Pete >> >> On 5/6/13 3:38 AM, Volker Simonis wrote: >>> What does "../../../../build/windows-i586/bin/java -version" return? >>> That must be HotSpot 24 (i.e. something like '..build 24.0-b34..'). >>> >>> How did you specify your boot-jdk? Maybe you didn't really build a new >>> hotspot but imported it from the boot-jdk and that was too old? >>> >>> If you want you can compare your build logs with our nightly build >>> logs of jdk7u on windows >>> at: >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz >>> >>> Regards >>> Volker >>> >>> >>> On Sat, May 4, 2013 at 5:40 AM, John Rose >> wrote: >>>> On May 3, 2013, at 8:42 AM, Pete Brunet >> wrote: >>>> >>>>> Error occurred during initialization of VM >>>>> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle >>>> It's a micro-version mismatch, from running a down-rev JVM on an up-rev >> rt.jar (JDK). >>>> >>>> But I don't understand why your makefile is running an old JVM on a new >> rt.jar. That's build voodoo, I presume. >>>> >>>> ? John >> >> From peter.brunet at oracle.com Tue May 7 21:10:29 2013 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 07 May 2013 16:10:29 -0500 Subject: AdapterMethodHandle not found In-Reply-To: References: <5183DAFF.3020405@oracle.com> <05313662-2DB3-4EEC-B5F6-51E64E93314B@oracle.com> <51885471.40001@oracle.com> Message-ID: <51896DC5.9020800@oracle.com> If I clone the current code, where to I find the equivalent import? I have been going to jre.us.oracle.com/java/re/jdk/ and looking for the highest numbered 7u directory, 7u80 in this case. I just sorted the jdk directory by date though and I see 7u40 has a more recent date. But that might not be reliable because the sort shows this order, starting with most recent: 7u40, 7u22, 7u23, 7u45, 7u18, 7u19, ... Pete On 5/7/13 3:13 PM, Kelly O'Hair wrote: > On May 7, 2013, at 1:59 AM, Volker Simonis wrote: > >> On Tue, May 7, 2013 at 3:10 AM, Pete Brunet wrote: >> >>> I tried changing my ALT_BOOTDIR from my normal 64 bit 7u21 installation >>> to the 7u80 tarball I extracted, but got: >>> make[2]: *** No rule to make target >>> `../../../build/windows-i586/btjars/addjsum.jar', needed by >>> `../../../build/windows-i586/lib/classlist'. Stop. >>> >>> FWIW, my ALT_JDK_IMPORT_PATH points at 7u80. >>> >>> >> Using an IMPORT_JDK has become quite tricky and it seems that it only works >> reliable if you use a build of the exact same version you are building as >> import jdk. > That IS the way IMPORT_JDK is defined, it must be a recent JDK build, anything else can be unreliable. > Any flag day changes (like jdk<->vm interface changes) will mess you up. > > I thought that was well documented somewhere. > > -kto > > >> Just yesterday I had a similar problem with JDK8 where I used a 4 weeks old >> import jdk to build a brand new version of the 'jdk' forest. It failed >> because during the build the VM from the import JDK is used together with >> the newly build jdk classes but there was a mismatch in the unsafe >> primitives requested by the Unsafe class and those provided by the VM. >> >> So the interface between the HotSpot VM and the class library has become >> quite volatile (and it is still not documented anywhere:( >> >> >>> I changed my ALT_BOOTDIR back to 7u21 and did a full build, not just >>> jdk, and after a three hour build time all is well. >>> >>> Pete >>> >>> On 5/6/13 3:38 AM, Volker Simonis wrote: >>>> What does "../../../../build/windows-i586/bin/java -version" return? >>>> That must be HotSpot 24 (i.e. something like '..build 24.0-b34..'). >>>> >>>> How did you specify your boot-jdk? Maybe you didn't really build a new >>>> hotspot but imported it from the boot-jdk and that was too old? >>>> >>>> If you want you can compare your build logs with our nightly build >>>> logs of jdk7u on windows >>>> at: >>> http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz >>>> Regards >>>> Volker >>>> >>>> >>>> On Sat, May 4, 2013 at 5:40 AM, John Rose >>> wrote: >>>>> On May 3, 2013, at 8:42 AM, Pete Brunet >>> wrote: >>>>>> Error occurred during initialization of VM >>>>>> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle >>>>> It's a micro-version mismatch, from running a down-rev JVM on an up-rev >>> rt.jar (JDK). >>>>> But I don't understand why your makefile is running an old JVM on a new >>> rt.jar. That's build voodoo, I presume. >>>>> ? John >>> From david.katleman at oracle.com Tue May 7 21:51:51 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 21:51:51 +0000 Subject: hg: jdk8/build: 7 new changesets Message-ID: <20130507215151.E286D488A9@hg.openjdk.java.net> Changeset: e34781a0566b Author: mduigou Date: 2013-04-24 21:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/e34781a0566b 8013185: Add java.util.stream to CORE_PKGS.gmk in root repo Reviewed-by: mduigou Contributed-by: Henry Jen ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: e4794ae1016e Author: mduigou Date: 2013-04-24 21:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/e4794ae1016e Merge Changeset: 10775618db00 Author: aharlap Date: 2013-04-26 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/build/rev/10775618db00 8011152: Precision problems on sflt builds Summary: Need to add global flag to the linker Reviewed-by: tbell, dholmes ! common/makefiles/NativeCompilation.gmk Changeset: a7a8302473d3 Author: mduigou Date: 2013-04-29 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/a7a8302473d3 8008632: Additional JavaDoc tags @apiNote, @implSpec and @implNote Reviewed-by: briangoetz, alanb, rriggs ! common/makefiles/javadoc/Javadoc.gmk Changeset: f171aa801ea5 Author: mduigou Date: 2013-04-29 14:21 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/f171aa801ea5 Merge Changeset: 1603c9216e83 Author: lana Date: 2013-04-30 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/1603c9216e83 Merge Changeset: 892a0196d10c Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/892a0196d10c Merge ! common/makefiles/NativeCompilation.gmk From david.katleman at oracle.com Tue May 7 21:52:52 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 21:52:52 +0000 Subject: hg: jdk8/build/jaxp: 5 new changesets Message-ID: <20130507215305.608D9488AB@hg.openjdk.java.net> Changeset: fad6560cb32a Author: dfuchs Date: 2013-04-17 15:23 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/fad6560cb32a 8005954: JAXP Plugability Layer should use java.util.ServiceLoader Summary: This fix replaces manual processing of files under META-INF/services in JAXP factories by calls to java.util.ServiceLoader. Reviewed-by: alanb, joehw, mchung ! src/javax/xml/datatype/DatatypeFactory.java ! src/javax/xml/datatype/FactoryFinder.java ! src/javax/xml/parsers/DocumentBuilderFactory.java ! src/javax/xml/parsers/FactoryFinder.java ! src/javax/xml/parsers/SAXParserFactory.java ! src/javax/xml/stream/FactoryFinder.java ! src/javax/xml/stream/XMLEventFactory.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/stream/XMLOutputFactory.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/transform/TransformerFactory.java ! src/javax/xml/validation/SchemaFactory.java + src/javax/xml/validation/SchemaFactoryConfigurationError.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactory.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 1c2079d11a79 Author: dfuchs Date: 2013-04-19 17:22 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/1c2079d11a79 8010495: Update JAXP NetBeans project - add support for generating javadoc Summary: Make it possible to use NetBeans to edit the jaxp sources and to generate a preview of the associated javadoc. Reviewed-by: joehw, alanb ! build.xml ! nbproject/project.xml Changeset: 6c6411a7070f Author: lana Date: 2013-04-23 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/6c6411a7070f Merge Changeset: be5d6853d821 Author: lana Date: 2013-04-30 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/be5d6853d821 Merge Changeset: 893d2ba8bbea Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/893d2ba8bbea Merge From david.katleman at oracle.com Tue May 7 21:51:59 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 21:51:59 +0000 Subject: hg: jdk8/build/corba: 4 new changesets Message-ID: <20130507215202.87ECB488AA@hg.openjdk.java.net> Changeset: 8f0a461776a9 Author: dmeetry Date: 2013-04-29 16:44 +0400 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/8f0a461776a9 4504275: CORBA boolean type unions do not generate compilable code from idlj Summary: JLS doesn't allow boolean type in switch statement, hence substituted by if statement. Reviewed-by: lancea ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/UnionGen.java Changeset: 846aaf02e516 Author: dmeetry Date: 2013-04-29 16:51 +0400 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/846aaf02e516 8011986: [corba] idlj generates read/write union helper methods that throw wrong exception in some cases Reviewed-by: lancea ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/UnionGen.java Changeset: ed59110eecdb Author: lana Date: 2013-04-30 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/ed59110eecdb Merge Changeset: fe4150590ee5 Author: lana Date: 2013-05-06 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/fe4150590ee5 Merge From david.katleman at oracle.com Tue May 7 21:57:51 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 21:57:51 +0000 Subject: hg: jdk8/build/jdk: 75 new changesets Message-ID: <20130507221235.EDC82488AC@hg.openjdk.java.net> Changeset: b0c41789f500 Author: jgodinez Date: 2013-04-25 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b0c41789f500 8009199: Printed text become garbage on Mac OSX Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: f4aa34a7a44d Author: jchen Date: 2013-04-29 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f4aa34a7a44d 8005302: [findbugs] public methods return internal arrays; may be private Reviewed-by: bae, prr ! src/share/classes/sun/java2d/pipe/AAShapePipe.java Changeset: 46686202aa23 Author: lana Date: 2013-04-30 22:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/46686202aa23 Merge Changeset: c70346f4c0a9 Author: pchelko Date: 2013-04-18 15:09 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c70346f4c0a9 8011686: AWT accidentally disables the NSApplicationDelegate of SWT, causing loss of OS X integration functionality Reviewed-by: anthony, serb Contributed-by: Markus Persson ! src/macosx/native/sun/awt/awt.m Changeset: ac92ac05dde4 Author: kshefov Date: 2013-04-22 18:39 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ac92ac05dde4 8011230: [TEST_BUG] java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java failed on solaris Reviewed-by: serb, anthony ! test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 578fb8766200 Author: leonidr Date: 2013-04-22 19:24 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/578fb8766200 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 0894b8476a49 Author: lana Date: 2013-04-23 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0894b8476a49 Merge - src/share/classes/java/time/chrono/HijrahDeviationReader.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java - src/share/classes/java/time/temporal/Adjusters.java - src/share/classes/java/time/temporal/Queries.java - src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM - src/share/native/java/lang/ResourceBundle.c - test/java/time/tck/java/time/TestChronology.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/java/util/ComparatorsTest.java Changeset: 7103434eefe2 Author: kshefov Date: 2013-04-24 11:48 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7103434eefe2 8011186: [TEST_BUG] java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java failed on windows 8 Reviewed-by: anthony, serb, ant - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java + test/java/awt/Focus/SimpleWindowActivationTest/SimpleWindowActivationTest.java Changeset: 854f60ec4bfb Author: anthony Date: 2013-04-26 18:48 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/854f60ec4bfb 8012586: [x11] Modal dialogs for fullscreen window may show behind its owner Summary: Use the _NET_WM_WINDOW_TYPE_DIALOG type for owned windows Reviewed-by: anthony, art, serb Contributed-by: Vladimir Kravets ! src/solaris/classes/sun/awt/X11/XWindowPeer.java + test/java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java Changeset: e76f3e8e653f Author: malenkov Date: 2013-04-29 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e76f3e8e653f 8007458: [findbugs] One more beans issue, with ReflectionUtils Reviewed-by: art, alexsch ! src/share/classes/java/beans/MetaData.java - src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLEncoder.java ! test/java/beans/XMLEncoder/AbstractTest.java ! test/java/beans/XMLEncoder/BeanValidator.java ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4679556.java ! test/java/beans/XMLEncoder/java_awt_BorderLayout.java + test/java/beans/XMLEncoder/java_awt_CardLayout.java + test/java/beans/XMLEncoder/java_awt_GridBagLayout.java ! test/java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java Changeset: 358acb00cb2d Author: mcherkas Date: 2013-04-30 13:24 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/358acb00cb2d 8012004: JInternalFrame not being finalized after closing Reviewed-by: alexsch, alexp ! src/share/classes/javax/swing/JDesktopPane.java + test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: 31e111f82993 Author: serb Date: 2013-04-30 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/31e111f82993 7166296: closed/java/awt/Frame/DisabledParentOfToplevel/DisabledParentOfToplevel.html failed since 1.8.0b36 Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: caeedce39396 Author: serb Date: 2013-05-01 12:19 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/caeedce39396 8009012: [macosx] DisplayChangedListener is not implemented in LWWindowPeer/CGraphicsEnvironment Reviewed-by: anthony, bae ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/CGraphicsEnv.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: c357c11f076f Author: lana Date: 2013-05-01 09:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c357c11f076f Merge Changeset: 920ad6c95d93 Author: lana Date: 2013-05-01 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/920ad6c95d93 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 296c9ec816c6 Author: alanb Date: 2013-04-18 11:13 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/296c9ec816c6 8011536: (fs) BasicFileAttributes.creationTime() should return birth time (mac) Reviewed-by: chegar ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.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/UnixNativeDispatcher.c ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java + test/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java Changeset: 3c8724085cf7 Author: alanb Date: 2013-04-18 12:24 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3c8724085cf7 8009648: Tests fail in -agentvm -concurrency mode Reviewed-by: alanb Contributed-by: roger.riggs at oracle.com ! test/Makefile ! test/java/time/TEST.properties Changeset: 3cc833b1fd0c Author: dxu Date: 2013-04-18 10:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3cc833b1fd0c 8011946: java.util.Currency javadoc has broken link to iso.org Reviewed-by: mduigou ! src/share/classes/java/util/Currency.java Changeset: 32c3a580812b Author: mchung Date: 2013-04-18 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/32c3a580812b 8012624: Add sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java in ProblemList.txt Reviewed-by: lancea, alanb ! test/ProblemList.txt Changeset: 3b81fac25d26 Author: mchung Date: 2013-04-18 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3b81fac25d26 8011934: sun.misc.PerfCounter calls Perf.createLong with incorrect parameters Reviewed-by: mchung Contributed-by: Yasumasa Suenaga ! src/share/classes/sun/misc/PerfCounter.java Changeset: 3e4a0fddeb00 Author: jgish Date: 2013-04-18 16:33 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3e4a0fddeb00 8012005: LogManager needs test to ensure stack trace is not being done to find bundle Reviewed-by: mchung + test/java/util/logging/bundlesearch/ClassPathTestBundle_en.properties + test/java/util/logging/bundlesearch/IndirectlyLoadABundle.java + test/java/util/logging/bundlesearch/LoadItUp.java + test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java + test/java/util/logging/bundlesearch/resources/ContextClassLoaderTestBundle_en.properties + test/java/util/logging/bundlesearch/resources/StackSearchableResource_en.properties Changeset: 7bdb3e186497 Author: xuelei Date: 2013-04-18 22:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7bdb3e186497 8006935: Need to take care of long secret keys in HMAC/PRF compuation Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java Changeset: 778b16225d85 Author: weijun Date: 2013-04-19 15:41 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/778b16225d85 8009636: JARSigner including TimeStamp PolicyID (TSAPolicyID) as defined in RFC3161 Reviewed-by: mullan ! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TimestampToken.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/ts.sh Changeset: 90b03f9a2e77 Author: jzavgren Date: 2013-04-17 11:47 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/90b03f9a2e77 8010505: HTTP DIGEST implementation incorrectly quotes header values, fails auth Summary: The extraneous quotes were removed. Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java Changeset: 6139f8fb0137 Author: mduigou Date: 2013-04-16 22:50 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6139f8fb0137 8008670: Initial java.util.stream putback -- internal API classes Reviewed-by: mduigou, dholmes Contributed-by: Brian Goetz , Doug Lea
, Paul Sandoz + src/share/classes/java/util/stream/AbstractShortCircuitTask.java + src/share/classes/java/util/stream/AbstractTask.java + src/share/classes/java/util/stream/FindOps.java + src/share/classes/java/util/stream/ForEachOps.java + src/share/classes/java/util/stream/MatchOps.java + src/share/classes/java/util/stream/Node.java + src/share/classes/java/util/stream/PipelineHelper.java + src/share/classes/java/util/stream/Sink.java + src/share/classes/java/util/stream/StreamOpFlag.java + src/share/classes/java/util/stream/StreamShape.java + src/share/classes/java/util/stream/TerminalOp.java + src/share/classes/java/util/stream/TerminalSink.java + src/share/classes/java/util/stream/Tripwire.java Changeset: e8f1dc6d0c0c Author: jgish Date: 2013-04-19 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e8f1dc6d0c0c 8010939: Deadlock in LogManager Summary: re-order locks to avoid deadlock Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/DrainFindDeadlockTest.java Changeset: 22a27dfd0510 Author: weijun Date: 2013-04-22 11:39 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/22a27dfd0510 8005527: [TEST_BUG] console.sh failed Automatically with exit code 1. Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: 3ca33647db95 Author: akhil Date: 2013-04-22 09:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3ca33647db95 8001647: default methods for Collections - forEach, removeIf, replaceAll, sort Reviewed-by: alanb, dholmes, mduigou, psandoz, smarks Contributed-by: Akhil Arora , Arne Siegel , Brian Goetz ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java + test/java/util/Collection/CollectionDefaults.java + test/java/util/Collection/ListDefaults.java + test/java/util/Collection/testlibrary/CollectionAsserts.java + test/java/util/Collection/testlibrary/CollectionSupplier.java Changeset: 2a78d8f1fec1 Author: briangoetz Date: 2013-04-17 14:39 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2a78d8f1fec1 8008682: Inital Streams public API Reviewed-by: mduigou, dholmes, darcy Contributed-by: Brian Goetz , Mike Duigou , Paul Sandoz , JSR-335 EG + src/share/classes/java/util/stream/BaseStream.java + src/share/classes/java/util/stream/CloseableStream.java + src/share/classes/java/util/stream/Collector.java + src/share/classes/java/util/stream/DelegatingStream.java + src/share/classes/java/util/stream/DoubleStream.java + src/share/classes/java/util/stream/IntStream.java + src/share/classes/java/util/stream/LongStream.java + src/share/classes/java/util/stream/Stream.java + src/share/classes/java/util/stream/package-info.java Changeset: 98a7bb7baa76 Author: psandoz Date: 2013-04-17 11:34 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/98a7bb7baa76 8011426: java.util collection Spliterator implementations Summary: Spliterator implementations for collection classes in java.util. Reviewed-by: mduigou, briangoetz Contributed-by: Doug Lea
, Paul Sandoz ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 62fb9e2b5da1 Author: naoto Date: 2013-04-22 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/62fb9e2b5da1 8010666: Implement Currency/LocaleNameProvider in Windows Host LocaleProviderAdapter Reviewed-by: okutsu ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: 8b07b318f713 Author: alanb Date: 2013-04-23 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8b07b318f713 8012930: (fs) Eliminate recursion from FileTreeWalker Reviewed-by: chegar ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/walkFileTree/CreateFileTree.java ! test/java/nio/file/Files/walkFileTree/MaxDepth.java ! test/java/nio/file/Files/walkFileTree/SkipSiblings.java + test/java/nio/file/Files/walkFileTree/SkipSubtree.java ! test/java/nio/file/Files/walkFileTree/TerminateWalk.java + test/java/nio/file/Files/walkFileTree/find.sh - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh Changeset: b456f25c2075 Author: lancea Date: 2013-04-23 11:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b456f25c2075 8011620: adding free form netbeans project for jdbc to jdk/make/netbeans Reviewed-by: chegar ! make/netbeans/common/shared.xml + make/netbeans/jdbc/README + make/netbeans/jdbc/build.properties + make/netbeans/jdbc/build.xml + make/netbeans/jdbc/nbproject/project.xml Changeset: 57b02a7558f3 Author: lana Date: 2013-04-23 15:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/57b02a7558f3 Merge - src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM Changeset: 754c9bb4f085 Author: sla Date: 2013-04-24 14:49 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/754c9bb4f085 8009985: [parfait] Uninitialised variable at jdk/src/solaris/native/com/sun/management/UnixOperatingSystem_md.c Reviewed-by: sla, rbackman, alanb, dholmes, rdurbin Contributed-by: peter.allwin at oracle.com ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c Changeset: bbcebf893b83 Author: alanb Date: 2013-04-24 19:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bbcebf893b83 8005555: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java should be removed Reviewed-by: chegar - test/java/io/Serializable/accessConstants/AccessConstants.java Changeset: 8c06a38aa2c5 Author: sherman Date: 2013-04-24 21:27 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8c06a38aa2c5 8012638: test/java/time/test/java/util/TestFormatter fails in UTC TZ Summary: updated the offending test case Reviewed-by: alanb ! test/java/time/test/java/util/TestFormatter.java Changeset: 4da1d43f5843 Author: darcy Date: 2013-04-25 09:37 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4da1d43f5843 8012044: Give more information about self-suppression from Throwable.addSuppressed Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java Changeset: ca0957f0d408 Author: emc Date: 2013-04-25 14:23 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ca0957f0d408 8012937: Correct errors in javadoc comments. Summary: Correct some errors in the javadoc comments for parameter reflection. Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Parameter.java Changeset: 5871d7b1673c Author: coffeys Date: 2013-04-25 21:12 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5871d7b1673c 8000529: Regression: SimpleDateFormat incorrectly parses dates formatted with Z and z pattern letters Reviewed-by: okutsu ! src/share/classes/java/text/CalendarBuilder.java ! src/share/classes/java/text/SimpleDateFormat.java ! test/java/text/Format/DateFormat/Bug7130335.java Changeset: b600d637ef77 Author: wetmore Date: 2013-04-25 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b600d637ef77 8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing Reviewed-by: wetmore Contributed-by: alan.bateman at oracle.com ! test/sun/security/provider/SecureRandom/StrongSeedReader.java Changeset: a8da4e516bc3 Author: akhil Date: 2013-04-23 11:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a8da4e516bc3 8005051: optimized defaults for Iterator.forEachRemaining Reviewed-by: alanb, mduigou, psandoz, ulfzibis Contributed-by: Akhil Arora ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java Changeset: ceeed0fcb371 Author: jgish Date: 2013-04-02 18:41 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ceeed0fcb371 5015163: (str) String merge/join that is the inverse of String.split() 7172553: A utility class that forms the basis of a String.join() operation Summary: Integrate StringJoiner changes from lambda Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/String.java + src/share/classes/java/util/StringJoiner.java + test/java/lang/String/StringJoinTest.java + test/java/util/StringJoiner/StringJoinerTest.java Changeset: 2cb55846c9bb Author: mduigou Date: 2013-04-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2cb55846c9bb 8011920: Main streams implementation 8012542: Stream methods on Collection Reviewed-by: dholmes, mduigou Contributed-by: Brian Goetz , Mike Duigou , Paul Sandoz ! make/docs/CORE_PKGS.gmk ! src/share/classes/java/util/Collection.java + src/share/classes/java/util/stream/AbstractPipeline.java + src/share/classes/java/util/stream/AbstractSpinedBuffer.java + src/share/classes/java/util/stream/DistinctOps.java + src/share/classes/java/util/stream/DoublePipeline.java + src/share/classes/java/util/stream/IntPipeline.java + src/share/classes/java/util/stream/LongPipeline.java + src/share/classes/java/util/stream/Nodes.java + src/share/classes/java/util/stream/ReduceOps.java + src/share/classes/java/util/stream/ReferencePipeline.java + src/share/classes/java/util/stream/SliceOps.java + src/share/classes/java/util/stream/SortedOps.java + src/share/classes/java/util/stream/SpinedBuffer.java + src/share/classes/java/util/stream/StreamSpliterators.java + src/share/classes/java/util/stream/StreamSupport.java Changeset: 5144db7f0f88 Author: sherman Date: 2013-04-26 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5144db7f0f88 8007395: StringIndexOutofBoundsException in Match.find() when input String contains surrogate UTF-16 characters Summary: updated GroupCurly.match0() to backtrack correctly Reviewed-by: mchung ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: f5fbd8065920 Author: mfang Date: 2013-03-25 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f5fbd8065920 8010521: jdk8 l10n resource file translation update 2 Reviewed-by: naoto, yhuang + src/macosx/classes/com/apple/laf/resources/aqua_de.properties + src/macosx/classes/com/apple/laf/resources/aqua_es.properties + src/macosx/classes/com/apple/laf/resources/aqua_fr.properties + src/macosx/classes/com/apple/laf/resources/aqua_it.properties + src/macosx/classes/com/apple/laf/resources/aqua_ja.properties + src/macosx/classes/com/apple/laf/resources/aqua_ko.properties + src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties + src/macosx/classes/com/apple/laf/resources/aqua_sv.properties + src/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties + src/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/awt/resources/awt_de.properties ! src/share/classes/sun/awt/resources/awt_es.properties ! src/share/classes/sun/awt/resources/awt_pt_BR.properties ! src/share/classes/sun/awt/resources/awt_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties Changeset: 6d8cd4f28a2f Author: mfang Date: 2013-04-22 23:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6d8cd4f28a2f Merge - make/com/sun/servicetag/Makefile - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - src/share/classes/java/time/chrono/HijrahDeviationReader.java - src/share/classes/java/time/format/DateTimeBuilder.java - src/share/classes/java/time/format/DateTimeFormatStyleProvider.java - src/share/classes/java/time/temporal/Adjusters.java - src/share/classes/java/time/temporal/Queries.java ! src/share/classes/sun/security/ssl/Authenticator.java - src/share/classes/sun/security/util/KeyLength.java - src/share/native/java/lang/ResourceBundle.c - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/java/time/tck/java/time/TestChronology.java - test/java/time/tck/java/time/chrono/TestChronoLocalDate.java - test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TestHijrahChronology.java - test/java/time/tck/java/time/chrono/TestJapaneseChronology.java - test/java/time/tck/java/time/chrono/TestMinguoChronology.java - test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java - test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java - test/java/time/tck/java/time/temporal/TestChronoLocalDate.java - test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java - test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java - test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java - test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/java/util/ComparatorsTest.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java - test/sun/tools/jstat/gcPermCapacityOutput1.awk - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh Changeset: a6781797ae53 Author: mfang Date: 2013-04-26 09:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a6781797ae53 Merge Changeset: 890485cafb8b Author: mfang Date: 2013-04-26 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/890485cafb8b Merge Changeset: 5e7ae178b24d Author: plevart Date: 2013-04-26 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e7ae178b24d 7123493: (proxy) Proxy.getProxyClass doesn't scale under high load Reviewed-by: mchung ! src/share/classes/java/lang/reflect/Proxy.java + src/share/classes/java/lang/reflect/WeakCache.java Changeset: 964b95a59656 Author: weijun Date: 2013-04-27 18:25 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/964b95a59656 8005523: Unbound krb5 for TLS Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/Krb5Proxy.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! test/sun/security/krb5/auto/SSL.java Changeset: c5d7bdee8c64 Author: alanb Date: 2013-04-28 21:06 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c5d7bdee8c64 8013413: javadoc warnings Reviewed-by: lancea, chegar ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/util/Spliterator.java Changeset: 94b05be10eec Author: alanb Date: 2013-04-29 10:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/94b05be10eec 8013415: Changes for JDK-8005523 requires updates to refs.allowed Reviewed-by: chegar ! make/tools/src/build/tools/deps/refs.allowed Changeset: 138f767b8eff Author: dholmes Date: 2013-04-29 07:40 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/138f767b8eff 8010280: jvm.cfg needs updating for non-server builds Summary: Generate jvm.cfg based on chosen VMs for non-"standard" builds and remove legacy entries from committed jvm.cfg files Reviewed-by: mduigou, tbell ! makefiles/CopyFiles.gmk ! src/macosx/bin/x86_64/jvm.cfg ! src/solaris/bin/amd64/jvm.cfg ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ia64/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg ! src/solaris/bin/sparcv9/jvm.cfg ! src/solaris/bin/zero/jvm.cfg ! src/windows/bin/amd64/jvm.cfg ! src/windows/bin/i586/jvm.cfg ! src/windows/bin/ia64/jvm.cfg Changeset: 9d324d667bb3 Author: jzavgren Date: 2013-04-29 08:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9d324d667bb3 8012108: Memory leak in jdk/src/windows/native/java/net/NetworkInterface_winXP.c Summary: Modified code to fix this leak and then proactively fixed improper calls to realloc() in the windows native code that can also cause leaks. Reviewed-by: chegar, khazra, dsamersoff ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c Changeset: b013d7433184 Author: chegar Date: 2013-04-29 18:12 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b013d7433184 Merge Changeset: 7857129859bd Author: briangoetz Date: 2013-04-20 18:53 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7857129859bd 8012650: Arrays streams methods 8011918: java.util.stream.Streams Reviewed-by: alanb, mduigou, darcy, henryjen Contributed-by: brian.goetz at oracle.com, paul.sandoz at oracle.com ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java + src/share/classes/java/util/stream/StreamBuilder.java + src/share/classes/java/util/stream/Streams.java + test/java/util/Arrays/SetAllTest.java Changeset: 46ddd9d272b5 Author: mduigou Date: 2013-04-29 22:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/46ddd9d272b5 8011917: Add java.util.stream.Collectors utilities Reviewed-by: darcy, mduigou Contributed-by: Brian Goetz + src/share/classes/java/util/stream/Collectors.java Changeset: fff665e54df0 Author: sla Date: 2013-04-30 10:48 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fff665e54df0 8003671: [findbugs] sun.management.AgentConfigurationError.getParams() may expose internal representation by returning AgentConfigurationError.params Reviewed-by: mchung, rbackman, jbachorik ! src/share/classes/sun/management/AgentConfigurationError.java Changeset: 49d6596100db Author: msheppar Date: 2013-04-29 23:07 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/49d6596100db 8007373: Inet6Address serialization incompatibility Reviewed-by: alanb, chegar ! src/share/classes/java/net/Inet6Address.java + test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java Changeset: ac3e189c9099 Author: lancea Date: 2013-04-30 14:44 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ac3e189c9099 8010416: Add a way for java.sql.Driver to be notified when it is deregistered Reviewed-by: alanb, ulfzibis ! src/share/classes/java/sql/Driver.java + src/share/classes/java/sql/DriverAction.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/SQLPermission.java Changeset: 0e6f412f5536 Author: mduigou Date: 2013-04-30 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0e6f412f5536 8011814: Add testng.jar to Netbeans projects test compile classpath 8013271: Add MacOS sources to J2SE Netbeans project 8013272: JDK Netbeans projects should use ASCII encoding for sources Reviewed-by: lancea ! make/netbeans/common/closed-share-sources.ent ! make/netbeans/common/demo-view.ent ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/jtreg-view.ent + make/netbeans/common/macosx-sources.ent + make/netbeans/common/macosx-view.ent ! make/netbeans/common/properties.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-sources.ent ! make/netbeans/common/unix-sources.ent ! make/netbeans/common/windows-sources.ent ! make/netbeans/j2se/nbproject/project.xml ! make/netbeans/world/nbproject/project.xml Changeset: 2fba6ae13ed8 Author: mduigou Date: 2013-04-30 12:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2fba6ae13ed8 Merge Changeset: 1432a6247ac9 Author: ksrini Date: 2013-04-30 13:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1432a6247ac9 8009389: Unpack200 native library should be removed from profiles Reviewed-by: alanb, bobv, jrose ! makefiles/profile-includes.txt ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java Changeset: eda99449ab26 Author: alanb Date: 2013-04-30 21:19 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/eda99449ab26 8013647: JPRT unable to clean-up after tests that leave file trees with loops Reviewed-by: chegar, tbell ! test/java/nio/file/Files/walkFileTree/MaxDepth.java ! test/java/nio/file/Files/walkFileTree/SkipSiblings.java ! test/java/nio/file/Files/walkFileTree/SkipSubtree.java ! test/java/nio/file/Files/walkFileTree/TerminateWalk.java Changeset: 4a82d2b86c75 Author: mchung Date: 2013-04-30 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4a82d2b86c75 8013531: Provide a utility class in com.sun.tools.classfile to find field/method references Reviewed-by: alanb ! test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java - test/sun/reflect/CallerSensitive/MethodFinder.java ! test/sun/reflect/CallerSensitive/MissingCallerSensitive.java Changeset: 4550ba263cbf Author: lana Date: 2013-04-30 17:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4550ba263cbf Merge Changeset: dddd17cf61ff Author: chegar Date: 2013-05-01 10:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/dddd17cf61ff 6594296: NetworkInterface.getHardwareAddress returns zero length byte array Reviewed-by: alanb ! src/windows/native/java/net/NetworkInterface_winXP.c ! test/java/net/NetworkInterface/Test.java Changeset: 73793f2af80a Author: msheppar Date: 2013-04-30 16:24 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/73793f2af80a 8007799: Base64.getEncoder(0, byte[]) returns an encoder that unexpectedly inserts line separators Reviewed-by: sherman, iris ! src/share/classes/java/util/Base64.java + test/java/util/Base64/Base64GetEncoderTest.java Changeset: 5941f7c9c76a Author: chegar Date: 2013-05-01 11:15 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5941f7c9c76a 8013723: ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: ae4a82e69da2 Author: weijun Date: 2013-05-01 21:05 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ae4a82e69da2 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt Reviewed-by: vinnie ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java + test/sun/security/krb5/auto/SaslGSS.java Changeset: c6aef650e615 Author: mduigou Date: 2013-05-01 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c6aef650e615 8012665: add CharSequence.chars, CharSequence.codePoints Reviewed-by: martin, alanb, ulfzibis, mduigou Contributed-by: Stuart Marks , Henry Jen ! src/share/classes/java/lang/CharSequence.java + test/java/lang/CharSequence/DefaultTest.java ! test/java/lang/StringBuffer/TestSynchronization.java Changeset: f6f2802f980c Author: lana Date: 2013-05-01 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f6f2802f980c Merge - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 336a110f1196 Author: lana Date: 2013-05-06 11:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/336a110f1196 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 845025546e35 Author: katleman Date: 2013-05-07 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/845025546e35 Merge From david.katleman at oracle.com Tue May 7 22:16:30 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 22:16:30 +0000 Subject: hg: jdk8/build/nashorn: 38 new changesets Message-ID: <20130507221659.5856B488AE@hg.openjdk.java.net> Changeset: aa8170c0dec9 Author: sundar Date: 2013-04-15 20:12 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/aa8170c0dec9 8012240: Array.prototype.map.call({length: -1, get 0(){throw 0}}, function(){}).length does not throw error Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java + test/script/basic/JDK-8012240.js Changeset: 486d92559c37 Author: sundar Date: 2013-04-17 16:52 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/486d92559c37 8012457: Function.prototype.apply should accept any array-like argument for function arguments Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeFunction.java + test/script/basic/JDK-8012457.js Changeset: d4468316fe73 Author: jlaskey Date: 2013-04-17 08:48 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d4468316fe73 Merge Changeset: 04b36c02c0e2 Author: jlaskey Date: 2013-04-17 15:36 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/04b36c02c0e2 8012529: Remove -esa from testing jvmargs Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/project.properties Changeset: 2bb3b22392d7 Author: sundar Date: 2013-04-18 15:47 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/2bb3b22392d7 Merge Changeset: ac309d492b8d Author: sundar Date: 2013-04-18 15:50 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ac309d492b8d 8012462: Date.prototype.toJSON does not handle non-Date 'this' as per the spec. Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8012462.js Changeset: d1d564f5cf82 Author: hannesw Date: 2013-04-18 14:25 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d1d564f5cf82 8012460: RegExp regression Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + test/script/basic/JDK-8012460.js + test/script/basic/JDK-8012460.js.EXPECTED Changeset: bc251a7b5103 Author: sundar Date: 2013-04-19 17:46 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/bc251a7b5103 8012612: Compile failed Reviewed-by: hannesw, jlaskey, attila ! src/jdk/nashorn/internal/runtime/Context.java Changeset: c8460f668d0c Author: sundar Date: 2013-04-19 18:23 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c8460f668d0c 8012593: JSAdapter overrides impacts strongly construction time Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java Changeset: 3a209cbd1d8f Author: lagergren Date: 2013-04-19 16:11 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3a209cbd1d8f 8010701: Immutable nodes - final iteration Reviewed-by: sundar, hannesw, jlaskey ! bin/verbose_octane.sh ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java - src/jdk/nashorn/internal/codegen/Frame.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java + src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java - src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/Flags.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java - src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java + src/jdk/nashorn/internal/ir/LexicalContextNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java + src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java + src/jdk/nashorn/internal/ir/annotations/Immutable.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/try2.js + test/script/basic/try2.js.EXPECTED Changeset: e599a1cad89a Author: jlaskey Date: 2013-04-20 08:54 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e599a1cad89a 8011578: -Dnashorn.unstable.relink.threshold=1 causes tests to fail. Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8011578.js + test/script/basic/JDK-8011578.js.EXPECTED Changeset: ead94bc57939 Author: sundar Date: 2013-04-22 18:09 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ead94bc57939 8012673: Nashorn's package name vs class name inferring logic is wrong Reviewed-by: hannesw, jlaskey, attila ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java Changeset: 812e9cc70320 Author: jlaskey Date: 2013-04-22 10:37 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/812e9cc70320 8012919: findMegaMorphicSetMethod should not cast result type Reviewed-by: attila, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java Changeset: cfda59f3d827 Author: sundar Date: 2013-04-22 19:57 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/cfda59f3d827 Merge - src/jdk/nashorn/internal/codegen/Frame.java - src/jdk/nashorn/internal/ir/DoWhileNode.java - src/jdk/nashorn/internal/ir/LabeledNode.java Changeset: 08143fa6b3da Author: lana Date: 2013-04-23 15:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/08143fa6b3da Merge Changeset: 0547a1c76259 Author: attila Date: 2013-04-23 12:52 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/0547a1c76259 8011065: Problems when script implements an interface with variadic methods Reviewed-by: jlaskey, hannesw, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/VariableArityTestInterface.java Changeset: 32036918585d Author: attila Date: 2013-04-23 16:48 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/32036918585d 8010731: Don't expose internal symbols to scripts Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java Changeset: a6c53280343d Author: hannesw Date: 2013-04-24 13:28 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a6c53280343d 8012334: ToUint32, ToInt32, and ToUint16 don't conform to spec Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + test/examples/int-micro.js + test/script/basic/JDK-8012334.js + test/script/basic/JDK-8012334.js.EXPECTED ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java Changeset: 3974ce844f17 Author: hannesw Date: 2013-04-24 13:34 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3974ce844f17 8012931: NativeDate.safeToString() throws RangeError for invalid date Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8012931.js + test/script/basic/JDK-8012931.js.EXPECTED Changeset: e959c7969f3b Author: hannesw Date: 2013-04-24 13:36 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e959c7969f3b 8008238: Labeled break in finally causes stack overflow in Node copy Reviewed-by: lagergren, attila + test/script/basic/JDK-8008238.js Changeset: c0a10bbf6752 Author: jlaskey Date: 2013-04-24 14:25 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c0a10bbf6752 8012251: jjs should support -fx option Reviewed-by: sundar, attila, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + src/jdk/nashorn/internal/runtime/resources/fx/base.js + src/jdk/nashorn/internal/runtime/resources/fx/bootstrap.js + src/jdk/nashorn/internal/runtime/resources/fx/controls.js + src/jdk/nashorn/internal/runtime/resources/fx/fxml.js + src/jdk/nashorn/internal/runtime/resources/fx/graphics.js + src/jdk/nashorn/internal/runtime/resources/fx/media.js + src/jdk/nashorn/internal/runtime/resources/fx/swing.js + src/jdk/nashorn/internal/runtime/resources/fx/swt.js + src/jdk/nashorn/internal/runtime/resources/fx/web.js ! src/jdk/nashorn/tools/Shell.java ! tools/fxshell/jdk/nashorn/tools/FXShell.java Changeset: 9ad1ebb44c86 Author: hannesw Date: 2013-04-25 14:20 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9ad1ebb44c86 8013131: Various compatibility issues in String.prototype.split() Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/JDK-8013131.js + test/script/basic/JDK-8013131.js.EXPECTED Changeset: ff1e4655a57f Author: attila Date: 2013-04-25 14:47 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ff1e4655a57f 8013203: A collection of smaller speedups to compilation pipeline Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java Changeset: fd0b969a6d07 Author: attila Date: 2013-04-25 15:31 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/fd0b969a6d07 8013167: Vararg constructor not found Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java + test/script/basic/JDK-8013167.js + test/script/basic/JDK-8013167.js.EXPECTED + test/src/jdk/nashorn/test/models/VarArgConstructor.java Changeset: 215d9b042cb6 Author: sundar Date: 2013-04-26 12:17 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/215d9b042cb6 8013295: ScriptEngineTest.java fails with compilation error when running under jtreg Reviewed-by: attila, hannesw ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 7917ef020898 Author: attila Date: 2013-04-26 09:20 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/7917ef020898 8013325: function named 'arguments' should set DEFINES_ARGUMENTS flag in its parent, not itself Reviewed-by: hannesw, sundar ! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8013325.js + test/script/basic/JDK-8013325.js.EXPECTED Changeset: 5c98cc846f92 Author: jlaskey Date: 2013-04-26 09:48 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5c98cc846f92 8013208: Octane performance regression Reviewed-by: hannesw, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java Changeset: b532eeab085f Author: sundar Date: 2013-04-26 18:31 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b532eeab085f 8013337: Issues with Date.prototype's get, set functions Reviewed-by: jlaskey, hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8013337.js + test/script/basic/JDK-8013337.js.EXPECTED Changeset: c62144b08c65 Author: hannesw Date: 2013-04-26 17:35 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c62144b08c65 8006559: Octane:pdfjs leaks memory, runs slower iteration to iteration Reviewed-by: attila, sundar, jlaskey ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java Changeset: 241904013024 Author: sundar Date: 2013-04-26 22:29 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/241904013024 8013369: nashorn build failure with jdk8 b84 Reviewed-by: hannesw ! make/build-nasgen.xml Changeset: ef4c1f3aa9ed Author: jlaskey Date: 2013-04-26 15:13 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ef4c1f3aa9ed 8013360: Should be using JavaFX 8 classes for -fx support Reviewed-by: hannesw, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/base.js ! src/jdk/nashorn/internal/runtime/resources/fx/controls.js ! src/jdk/nashorn/internal/runtime/resources/fx/fxml.js ! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js ! src/jdk/nashorn/internal/runtime/resources/fx/media.js ! src/jdk/nashorn/internal/runtime/resources/fx/swing.js ! src/jdk/nashorn/internal/runtime/resources/fx/swt.js ! src/jdk/nashorn/internal/runtime/resources/fx/web.js Changeset: e8d7298f29a1 Author: attila Date: 2013-04-29 13:21 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e8d7298f29a1 8013419: Streamline handling of with and eval Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: ada2ca9aeac5 Author: sundar Date: 2013-04-29 18:40 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ada2ca9aeac5 8013444: JSON.parse does not invoke "reviver" callback as per spec. Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/JSONFunctions.java + test/script/basic/JDK-8013444.js + test/script/basic/JDK-8013444.js.EXPECTED Changeset: 630372cb8f2a Author: attila Date: 2013-04-29 23:22 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/630372cb8f2a 8008814: Configurable ignore/warning/error behavior for function declaration as statement Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8008814-3.js + test/script/basic/JDK-8008814-3.js.EXPECTED + test/script/basic/JDK-8008814-4.js + test/script/basic/JDK-8008814-4.js.EXPECTED + test/script/error/JDK-8008814-1.js + test/script/error/JDK-8008814-1.js.EXPECTED + test/script/error/JDK-8008814-2.js + test/script/error/JDK-8008814-2.js.EXPECTED Changeset: 3f339ab2d050 Author: jlaskey Date: 2013-04-29 21:38 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3f339ab2d050 Merge Changeset: ad28f2b52b12 Author: lagergren Date: 2013-04-30 09:42 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ad28f2b52b12 8013533: Increase code coverage report for types and logging Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! test/script/error/JDK-8008814-1.js.EXPECTED ! test/script/error/JDK-8008814-2.js.EXPECTED + test/script/trusted/logcoverage.js + test/script/trusted/logcoverage.js.EXPECTED Changeset: 9fee4992f796 Author: lana Date: 2013-04-30 17:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9fee4992f796 Merge Changeset: 45ce27fbe272 Author: lana Date: 2013-05-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/45ce27fbe272 Merge - src/jdk/nashorn/internal/codegen/Frame.java - src/jdk/nashorn/internal/ir/DoWhileNode.java - src/jdk/nashorn/internal/ir/LabeledNode.java From david.katleman at oracle.com Tue May 7 22:15:32 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 07 May 2013 22:15:32 +0000 Subject: hg: jdk8/build/langtools: 15 new changesets Message-ID: <20130507221615.F3137488AD@hg.openjdk.java.net> Changeset: ed918a442b83 Author: jlahoda Date: 2013-04-17 15:54 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ed918a442b83 8008174: DocTree API should provide start and end positions for tree nodes Summary: Adding DocSourcePositions to allow access to DocTree starting/ending position Reviewed-by: jjg, darcy Contributed-by: Ralph Benjamin Ruijs , Jan Lahoda + src/share/classes/com/sun/source/util/DocSourcePositions.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/tree/DCTree.java + test/tools/javac/doctree/positions/TestPosition.java + test/tools/javac/doctree/positions/TestPosition.out + test/tools/javac/doctree/positions/TestPositionSource.java Changeset: 891b88acf47a Author: jjg Date: 2013-04-18 19:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/891b88acf47a 8012658: Change default langtools source level to 7 Reviewed-by: darcy ! make/netbeans/langtools/nbproject/project.xml Changeset: 95d29b99e5b3 Author: jjg Date: 2013-04-18 20:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/95d29b99e5b3 8012656: cache frequently used name strings for DocImpl classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java Changeset: a3655c24e232 Author: jfranck Date: 2013-04-19 11:57 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a3655c24e232 8012681: Commit for JDK-8012656 breaks tl build Reviewed-by: vromero, chegar, alanb ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java Changeset: d59730bd3162 Author: jjg Date: 2013-04-19 11:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d59730bd3162 8012661: remove langtools Makefile-classic Reviewed-by: erikj, tbell - make/Makefile-classic Changeset: bae8387d16aa Author: jfranck Date: 2013-04-22 10:24 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bae8387d16aa 8011027: Type parameter annotations not passed through to javax.lang.model Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java + test/tools/javac/processing/model/element/TestTypeParameterAnnotations.java Changeset: da0bd69335d4 Author: lana Date: 2013-04-23 15:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/da0bd69335d4 Merge Changeset: 4b0038f66d66 Author: jjg Date: 2013-04-25 17:45 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/4b0038f66d66 8013256: javac test failing after Lambda changes to java.util.List Reviewed-by: mduigou ! test/tools/javac/api/TestJavacTaskScanner.java Changeset: 3c02d2f1a421 Author: vromero Date: 2013-04-26 10:04 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3c02d2f1a421 8012723: strictfp interface misses strictfp modifer on default method Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/defaultMethods/CheckACC_STRICTFlagOnDefaultMethodTest.java Changeset: 2ca9e7d50136 Author: vromero Date: 2013-04-26 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/2ca9e7d50136 8008562: javac, a refactoring to Bits is necessary in order to provide a change history Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/util/Bits.java Changeset: f3f3ac1273e8 Author: vromero Date: 2013-04-26 15:59 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f3f3ac1273e8 8010304: javac should detect all mutable implicit static fields in langtools using a plugin Reviewed-by: jjg ! make/build.xml + make/tools/crules/AbstractCodingRulesAnalyzer.java + make/tools/crules/MutableFieldsAnalyzer.java + make/tools/crules/resources/crules.properties Changeset: 57648bad3287 Author: mchung Date: 2013-04-30 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/57648bad3287 8013531: Provide a utility class in com.sun.tools.classfile to find field/method references Reviewed-by: alanb ! src/share/classes/com/sun/tools/classfile/Dependencies.java + src/share/classes/com/sun/tools/classfile/ReferenceFinder.java Changeset: 260013a710ef Author: lana Date: 2013-04-30 17:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/260013a710ef Merge Changeset: 8e27e84de2e9 Author: rfield Date: 2013-05-01 08:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8e27e84de2e9 8011591: BootstrapMethodError when capturing constructor ref to local classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNewInnerImplicitArgs.java Changeset: ec434cfd2752 Author: lana Date: 2013-05-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ec434cfd2752 Merge - make/Makefile-classic From david.holmes at oracle.com Tue May 7 22:49:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 May 2013 08:49:56 +1000 Subject: 8013652: (profiles) Add javax.script to compact1 In-Reply-To: <5188FC09.2050501@oracle.com> References: <5188FC09.2050501@oracle.com> Message-ID: <51898514.8050900@oracle.com> Ship it! :) David On 7/05/2013 11:05 PM, Alan Bateman wrote: > > I'd like to propose adding javax.script to the compact1 builds (it has > been in compact3 to date). The rational is to provide a supported way > for applications running on the smallest profile make use of scripting > languages. The original goal of compact1 was to provide a migration > target for applications that are currently running on CDC / Foundation > Profile so this change does broaden its potential usage a bit. In > footprint terms then javax.script is tiny so it doesn't make a > significant difference. > > The build changes requires are trivial (see attached) and just move > java.script from PROFILE_3_RTJAR_INCLUDE_PACKAGES to > PROFILE_1_RTJAR_INCLUDE_PACKAGES. Note that the changes assume that > Sundar's removing of Rhino (JDK-7175133) is complete. This work is > currently in review on core-libs-dev and build-dev. > > -Alan. > > > diff --git a/makefiles/profile-rtjar-includes.txt > b/makefiles/profile-rtjar-includes.txt > --- a/makefiles/profile-rtjar-includes.txt > +++ b/makefiles/profile-rtjar-includes.txt > @@ -57,6 +57,7 @@ > java/time \ > java/util \ > javax/net \ > + javax/script \ > javax/security \ > jdk \ > sun/invoke \ > @@ -124,7 +125,6 @@ > javax/lang/model \ > javax/management \ > javax/naming \ > - javax/script \ > javax/security/auth/kerberos \ > javax/security/sasl \ > javax/smartcardio \ From david.holmes at oracle.com Tue May 7 23:00:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 May 2013 09:00:33 +1000 Subject: Exporting symbols on OSX ? In-Reply-To: <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> References: <5188EB6D.7050100@oracle.com> <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> Message-ID: <51898791.1090305@oracle.com> On 8/05/2013 2:55 AM, David DeHaven wrote: > >> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported. >> >> However the OSX linker does support -exported_symbols_list >> >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html >> >> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ). >> >> Does anyone have experience using this such that we can get the hotspot build fixed? > > Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling. > > Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not. The visibility setting changes should aid with the primary exported interfaces (JNI_ and JVM_) but looking at the build there are other symbols (for Serviceability Agent I think) that get dynamically added to the mapfiles - so I'm not sure if the visibility setting alone will help here. I think we will still want the "exported_symbol_file" (but it seems whatever ld we are using for OSX builds doesn't actually recognize that option ?? :( Or I'm doing something wrong in trying to pass it) Thanks, David > -DrD- > From david.dehaven at oracle.com Tue May 7 23:53:49 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 7 May 2013 16:53:49 -0700 Subject: Exporting symbols on OSX ? In-Reply-To: <51898791.1090305@oracle.com> References: <5188EB6D.7050100@oracle.com> <4D160B15-081F-4520-8B18-D5BF6FD922E6@oracle.com> <51898791.1090305@oracle.com> Message-ID: <4FF40AC6-E30A-4D5D-9115-D68206954247@oracle.com> >>> We just discovered that every symbol is libjvm is being exported on OSX. The OSX/BSD makefiles were copied from the linux ones and so have the options for linker scripts and mapfiles, but as OSX doesn't support linker scripts this is disabled by setting LDNOMAP=true - hence all symbols are exported. >>> >>> However the OSX linker does support -exported_symbols_list >>> >>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ld.1.html >>> >>> so I was wondering why the build wasn't modified to use that so that we only export the JVM symbols we intend to export? (That's a question for the macosx-port-dev folk :) ). >>> >>> Does anyone have experience using this such that we can get the hotspot build fixed? >> >> Exports should be handled by the visibility settings. Until recently the JNIEXPORT macro resolved to nothing, now it sets __attribute__(("visibility" ("default))) (at least in 8, that should be backported to 7u if it hasn't already). The "default" visibility means export that symbol. To hide non-exported symbols you need to provide --fvisibility=hidden to gcc or clang when compiling. >> >> Hotspot has it's own jni_md.h headers with macros to determine JNIEXPORT, but they were wrong last I checked. It appears they attempted to clear the macro if a certain version of gcc was used, but what happens is it disables it for all versions of gcc above a particular release (which hasn't been used on Mac is quite some time). I pointed this out when the JNIEXPORT patch was posted for review to core-libs-dev (I think...), it was CC'd to the hotspot list too so someone has to have seen it. I'm not sure if it's been fixed or not. > > The visibility setting changes should aid with the primary exported interfaces (JNI_ and JVM_) but looking at the build there are other symbols (for Serviceability Agent I think) that get dynamically added to the mapfiles - so I'm not sure if the visibility setting alone will help here. I think we will still want the "exported_symbol_file" (but it seems whatever ld we are using for OSX builds doesn't actually recognize that option ?? :( Or I'm doing something wrong in trying to pass it) Apple's ld supports "-exported_symbols_list filename" which is similar to (but not the same as) export map files for GNU ld. I don't know if the use of that argument overrides the -fvisibility setting though. Some minor experimentation should provide answers to that question... Can those symbols just be marked with JNIEXPORT or some similar macro? -DrD- From david.katleman at oracle.com Wed May 8 00:11:19 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 08 May 2013 00:11:19 +0000 Subject: hg: jdk8/build/hotspot: 65 new changesets Message-ID: <20130508001324.8A0FB488BA@hg.openjdk.java.net> Changeset: 57ac6a688ae6 Author: amurillo Date: 2013-04-26 00:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/57ac6a688ae6 8013227: new hotspot build - hs25-b31 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cc70cbbd422e Author: hseigel Date: 2013-04-24 09:00 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cc70cbbd422e 8012695: Assertion message displays %u and %s text instead of actual values Summary: USe err_msg() to create a proper assertion message. Reviewed-by: twisti, coleenp, iklam ! src/share/vm/classfile/classFileParser.hpp Changeset: fbca7eaeac2e Author: zgu Date: 2013-04-24 14:55 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fbca7eaeac2e 8011218: Kitchensink hanged, likely NMT is to blame Summary: Made NMT query safepoint aware. Reviewed-by: dholmes, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memTracker.cpp Changeset: d587a5c30bd8 Author: coleenp Date: 2013-04-24 16:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d587a5c30bd8 8011803: release_C_heap_structures is never called for anonymous classes. Summary: Call this function from the ClassLoaderData destructor instead of the system dictionary walk. Reviewed-by: stefank, mgerdin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: d66a24adbe3f Author: coleenp Date: 2013-04-24 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d66a24adbe3f Merge Changeset: 15a99ca4ee34 Author: sspitsyn Date: 2013-04-25 03:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/15a99ca4ee34 8007037: JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands Summary: References from operands to CP entries and back must be correct after CP merge Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: c115fac239eb Author: iklam Date: 2013-04-25 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c115fac239eb 8008962: NPG: Memory regression: One extra Monitor per ConstantPool Summary: Re-use InstanceKlass::_init_lock locking ConstantPool as well. Reviewed-by: dholmes, coleenp, acorn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 3c9b7ef92c61 Author: dcubed Date: 2013-04-26 08:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c9b7ef92c61 Merge Changeset: d1644a010f52 Author: emc Date: 2013-04-26 07:34 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d1644a010f52 8007154: Remove support for u4 MethodParameter flags fields Summary: Remove support for parsing class files with four-byte flags fields in MethodParameters attributes Reviewed-by: jrose, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: f258c5828eb8 Author: hseigel Date: 2013-04-29 16:13 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f258c5828eb8 8011773: Some tests on Interned String crashed JVM with OOM Summary: Instead of terminating the VM, throw OutOfMemoryError exceptions. Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/whitebox.cpp Changeset: c53e49efe6a8 Author: hseigel Date: 2013-04-29 16:36 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c53e49efe6a8 Merge Changeset: f32b6c267d2e Author: mikael Date: 2013-04-29 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f32b6c267d2e 8012015: Use PROT_NONE when reserving memory Summary: Reserved memory had PROT_READ+PROT_WRITE access on Linux/bsd, now changed to PROT_NONE. Reviewed-by: dholmes, ctornqvi ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReserveMemory.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 9f96b7a853bc Author: sla Date: 2013-04-30 10:53 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9f96b7a853bc 8013466: SA crashes when attaching to a process on OS X Reviewed-by: coleenp, rbackman, minqi ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 409d4b59e095 Author: sla Date: 2013-04-30 02:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/409d4b59e095 Merge Changeset: ed5a590835a4 Author: zgu Date: 2013-04-30 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ed5a590835a4 8013214: BigApps fails due to 'fatal error: Illegal threadstate encountered: 6' Summary: Grab and drop SR_lock to get the thread to honor the safepoint protocol Reviewed-by: dcubed, coleenp ! src/share/vm/services/memBaseline.cpp Changeset: 746b070f5022 Author: ccheung Date: 2013-04-30 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/746b070f5022 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" Reviewed-by: coleenp, zgu, hseigel ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp Changeset: e4614b063fe1 Author: sla Date: 2013-04-30 21:47 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e4614b063fe1 8013364: SA-JDI exceptions caused by lack of permissions on OSX should be more verbose about issue cause Reviewed-by: coleenp, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: 376ff861f611 Author: sla Date: 2013-05-01 01:07 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/376ff861f611 Merge Changeset: b4081e9714ec Author: vladidan Date: 2013-04-30 17:36 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b4081e9714ec 8013398: Adjust number of stack guard pages on systems with large memory page size Summary: Auto adjust number of stack guard pages on systems with large memory page size Reviewed-by: bobv, coleenp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 1847df492437 Author: vladidan Date: 2013-05-01 10:10 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1847df492437 Merge Changeset: 08236d966eea Author: bharadwaj Date: 2013-05-01 08:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/08236d966eea 8013418: assert(i == total_args_passed) in AdapterHandlerLibrary::get_adapter since 8-b87 Summary: Do not treat static methods as miranda methods. Reviewed-by: dholmes, acorn ! src/share/vm/oops/klassVtable.cpp + test/runtime/lambda-features/PublicStaticInterfaceMethodHandling.java Changeset: 8fe2542bdc8d Author: bharadwaj Date: 2013-05-01 09:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8fe2542bdc8d Merge Changeset: a6e09d6dd8e5 Author: dlong Date: 2013-04-24 20:55 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a6e09d6dd8e5 8003853: specify offset of IC load in java_to_interp stub Summary: refactored code to allow platform-specific differences Reviewed-by: dlong, twisti Contributed-by: Goetz Lindenmaier + src/cpu/sparc/vm/compiledIC_sparc.cpp ! src/cpu/sparc/vm/sparc.ad + src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + src/cpu/zero/vm/compiledIC_zero.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/opto/output.cpp Changeset: e10e43e58e92 Author: dlong Date: 2013-04-24 21:11 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e10e43e58e92 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/opto/output.cpp - test/gc/6941923/test6941923.sh - test/gc/TestVerifyBeforeGCDuringStartup.java - test/runtime/NMT/AllocTestType.java Changeset: 3c0584fec1e6 Author: dholmes Date: 2013-04-28 18:24 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c0584fec1e6 8010428: Special -agentpath checks needed with minimal VM to produce proper error message Reviewed-by: dholmes, alanb, cjplummer, olagneau Contributed-by: Carlos Lucasius ! src/share/vm/runtime/arguments.cpp Changeset: 78603aa58b1e Author: jiangli Date: 2013-04-26 16:58 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/78603aa58b1e Merge ! src/cpu/x86/vm/x86_64.ad Changeset: e01e02a9fcb6 Author: jiangli Date: 2013-04-29 01:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e01e02a9fcb6 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 052caeaeb771 Author: jiangli Date: 2013-05-02 12:16 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/052caeaeb771 Merge Changeset: 8f9fae155577 Author: jiangli Date: 2013-05-02 13:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8f9fae155577 Merge Changeset: c23dbf0e8ab7 Author: jmasa Date: 2013-03-01 10:19 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c23dbf0e8ab7 8011268: NPG: Free unused VirtualSpaceNodes Reviewed-by: mgerdin, coleenp, johnc ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: bfe3be9ebd6c Author: kevinw Date: 2013-04-18 17:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bfe3be9ebd6c 7109087: gc/7072527/TestFullGCCount.java fails when GC is set in command-line Reviewed-by: mgerdin ! test/gc/7072527/TestFullGCCount.java Changeset: 12927badda81 Author: kevinw Date: 2013-04-19 05:14 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/12927badda81 Merge Changeset: d391427ddc29 Author: mgerdin Date: 2013-04-22 10:10 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d391427ddc29 Merge Changeset: a08c80e9e1e5 Author: stefank Date: 2013-04-22 20:27 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a08c80e9e1e5 8012687: Remove unused is_root checks and closures Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp Changeset: ebded0261dfc Author: jmasa Date: 2013-04-22 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ebded0261dfc 8012111: Remove warning about CMS generation shrinking. Reviewed-by: johnc, brutisso, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/GuardShrinkWarning.java Changeset: 1cb4795305b9 Author: mgerdin Date: 2013-04-23 08:39 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1cb4795305b9 8011802: NPG: init_dependencies in class loader data graph can cause invalid CLD Summary: Restructure initialization of ClassLoaderData to not add a new instance if init_dependencies fail Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp Changeset: 5c93c1f61226 Author: johnc Date: 2013-04-18 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5c93c1f61226 8011724: G1: Stack allocate instances of HeapRegionRemSetIterator Summary: Stack allocate instances of HeapRegionRemSetIterator during RSet scanning. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 868d87ed63c8 Author: jmasa Date: 2013-02-12 14:15 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/868d87ed63c8 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions Reviewed-by: mgerdin, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 9d75bcd7c890 Author: mgerdin Date: 2013-04-24 19:55 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9d75bcd7c890 8013136: NPG: Parallel class loading tests fail after fix for JDK-8011802 Summary: Move initialization of dependencies to before allocation of CLD Reviewed-by: stefank, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp Changeset: d50cc62e94ff Author: johnc Date: 2013-04-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d50cc62e94ff 8012715: G1: GraphKit accesses PtrQueue::_index as int but is size_t Summary: In graphKit INT operations were generated to access PtrQueue::_index which has type size_t. This is 64 bit on 64-bit machines. No problems occur on little endian machines as long as the index fits into 32 bit, but on big endian machines the upper part is read, which is zero. This leads to unnecessary branches to the slow path in the runtime. Reviewed-by: twisti, johnc Contributed-by: Martin Doerr ! src/share/vm/opto/graphKit.cpp Changeset: b06ac540229e Author: stefank Date: 2013-04-24 20:13 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b06ac540229e 8013132: Add a flag to turn off the output of the verbose verification code Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: b294421fa3c5 Author: brutisso Date: 2013-04-26 09:53 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b294421fa3c5 8012915: ReservedSpace::align_reserved_region() broken on Windows Summary: remove unused constructors and helper methods for ReservedHeapSpace and ReservedSpace Reviewed-by: mgerdin, jmasa, johnc, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 2f50bc369470 Author: stefank Date: 2013-04-26 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2f50bc369470 8013160: NPG: Remove unnecessary mark stack draining after CodeCache::do_unloading Reviewed-by: coleenp, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: 3edf23423bb2 Author: johnc Date: 2013-04-26 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3edf23423bb2 8011898: gc/TestVerifyBeforeGCDuringStartup.java: java.lang.RuntimeException: '[Verifying' missing from stdout/stderr: [Error: Could not find or load main class] Summary: System.getProperty("test.java.opts") can return NULL, which gets converted to to the empty string, and the child java command then interprets that as the name of the main class. Reviewed-by: jmasa, brutisso ! test/gc/TestVerifyDuringStartup.java Changeset: caac22686b17 Author: mgerdin Date: 2013-04-29 09:31 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/caac22686b17 Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/runtime/thread.cpp Changeset: 601183f604b2 Author: mgerdin Date: 2013-04-29 13:07 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/601183f604b2 8013129: Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking Summary: Change Metaspace::deallocate to take lock with _no_safepoint_check_flag Reviewed-by: coleenp, jmasa, dholmes ! src/share/vm/memory/metaspace.cpp Changeset: 9075044ed66b Author: ehelin Date: 2013-04-30 16:36 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9075044ed66b 8008541: Remove old code in HotSpot that supported the jmap -permstat functionality Reviewed-by: sla, brutisso ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java Changeset: d58c62b7447d Author: mgerdin Date: 2013-05-02 19:28 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d58c62b7447d Merge ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: cbd4ce58f1f3 Author: mgerdin Date: 2013-05-02 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cbd4ce58f1f3 Merge Changeset: e12c9b3740db Author: vlivanov Date: 2013-04-25 11:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e12c9b3740db 8012260: ciReplay: Include PID into the name of replay data file Reviewed-by: kvn, twisti ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: dc7db03f5aa2 Author: iignatyev Date: 2013-04-25 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dc7db03f5aa2 8012337: Change Whitebox implementation to make absence of method in Whitebox.class not fatal Reviewed-by: kvn, vlivanov ! src/share/vm/prims/whitebox.cpp + test/sanity/WhiteBox.java Changeset: 7b23cb975cf2 Author: iignatyev Date: 2013-04-25 11:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7b23cb975cf2 8011675: adding compilation level to replay data Reviewed-by: kvn, vlivanov - agent/doc/c2replay.html + agent/doc/cireplay.html ! agent/doc/clhsdb.html ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/ciReplay/TestSA.sh + test/compiler/ciReplay/TestVM.sh + test/compiler/ciReplay/TestVM_no_comp_level.sh + test/compiler/ciReplay/common.sh Changeset: 247342108a11 Author: neliasso Date: 2013-04-23 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/247342108a11 8010332: removed unused method: ciMethod::uses_monitors Reviewed-by: twisti, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/ci/ciMethod.hpp Changeset: a5c95fcf7cb7 Author: neliasso Date: 2013-04-23 18:06 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a5c95fcf7cb7 8012157: removed unused code in SharedRuntime::handle_wrong_method Reviewed-by: kvn, roland, rbackman Contributed-by: albert.noll at oracle.com ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d1c9384eecb4 Author: iignatyev Date: 2013-04-26 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d1c9384eecb4 8012322: Tiered: CompilationPolicy::can_be_compiled(CompLevel_all) mistakenly return false Reviewed-by: kvn, vlivanov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: 93b8272814cf Author: vlivanov Date: 2013-04-26 08:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/93b8272814cf Merge Changeset: 0b55a78c6be5 Author: bharadwaj Date: 2013-04-26 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0b55a78c6be5 Merge - agent/doc/c2replay.html ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fd49109d0d88 Author: bharadwaj Date: 2013-04-26 14:50 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fd49109d0d88 Merge Changeset: 487d442ef257 Author: jiangli Date: 2013-04-26 16:21 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/487d442ef257 8013036: vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL). Summary: Change the assert to if check as MethodCounters could be NULL under TieredCompilation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 62b683108582 Author: jiangli Date: 2013-04-26 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/62b683108582 Merge Changeset: 0cfa93c2fcc4 Author: neliasso Date: 2013-04-29 13:20 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0cfa93c2fcc4 8012547: Code cache flushing can get stuck reclaming of memory Summary: Keep sweeping regardless of if we are flushing Reviewed-by: kvn, twisti ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: e4e131b15d5c Author: roland Date: 2013-05-02 10:27 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e4e131b15d5c 8013532: Remove unused parameter "compiler" from DTRACE_METHOD_COMPILE* macros Summary: remove unused parameter in dtrace macros Reviewed-by: kvn, roland Contributed-by: albert.noll at oracle.com ! src/share/vm/compiler/compileBroker.cpp Changeset: 9ce110b1d14a Author: kvn Date: 2013-05-02 18:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9ce110b1d14a Merge - agent/doc/c2replay.html ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 4ec913499722 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4ec913499722 Merge - agent/doc/c2replay.html Changeset: 9c1fe0b419b4 Author: amurillo Date: 2013-05-03 08:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9c1fe0b419b4 Added tag hs25-b31 for changeset 4ec913499722 ! .hgtags From dalibor.topic at oracle.com Wed May 8 10:10:50 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 08 May 2013 12:10:50 +0200 Subject: Review Request : CR8014129 In-Reply-To: <51896DB4.8070200@oracle.com> References: <51896DB4.8070200@oracle.com> Message-ID: <518A24AA.2090607@oracle.com> On 5/7/13 11:10 PM, Amy Wang wrote: > Hi, All, > > Please help review the following changes: > > CR8014129 : makefile changes to allow integration of new features > Looks OK. CC:ing build-dev for a second review from there, and Alejandro as a heads up that this change touches Hotspot makefiles. cheers, dalibor topic > The changes are at : > http://cr.openjdk.java.net/~katleman/8014129/hotspot/webrev/ > http://cr.openjdk.java.net/~katleman/8014129/jdk/webrev/ > http://cr.openjdk.java.net/~katleman/8014129/make/webrev/ > > Thank you! > Amy > -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From ahughes at redhat.com Wed May 8 11:12:15 2013 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 8 May 2013 07:12:15 -0400 (EDT) Subject: 8011346: build-infra: While Constructing Javadoc information, JSpinner.java error: package sun.util.locale.provider does not exist In-Reply-To: <517F827A.3040001@oracle.com> References: <517F827A.3040001@oracle.com> Message-ID: <241731481.8660362.1368011535123.JavaMail.root@redhat.com> ----- Original Message ----- > This patch removes the annoying Error output from javadoc during source > generation. > > http://cr.openjdk.java.net/~erikj/8011346/webrev.jdk.01/ > > /Erik > Looks good to me too. Will be good to see this error fixed. -- 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 mike.duigou at oracle.com Thu May 9 04:00:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 8 May 2013 21:00:20 -0700 Subject: RFR :8014269: (XXS) Add missing .PHONY targets to Main.gmk Message-ID: Hello all; Small issue for review. Some of the Main.gmk targets aren't mentioned in the PHONY targets as they should be. http://cr.openjdk.java.net/~mduigou/JDK-8014269/0/webrev/ Mike From mandy.chung at oracle.com Thu May 9 04:21:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 May 2013 21:21:16 -0700 Subject: RFR :8014269: (XXS) Add missing .PHONY targets to Main.gmk In-Reply-To: References: Message-ID: <518B243C.8070109@oracle.com> Looks good. Mandy On 5/8/2013 9:00 PM, Mike Duigou wrote: > Hello all; > > Small issue for review. Some of the Main.gmk targets aren't mentioned in the PHONY targets as they should be. > > http://cr.openjdk.java.net/~mduigou/JDK-8014269/0/webrev/ > > Mike From tim.bell at oracle.com Thu May 9 04:37:35 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 08 May 2013 21:37:35 -0700 Subject: RFR :8014269: (XXS) Add missing .PHONY targets to Main.gmk In-Reply-To: References: Message-ID: <518B280F.8090303@oracle.com> Hi Mike: > Small issue for review. Some of the Main.gmk targets aren't mentioned in the PHONY targets as they should be. > > http://cr.openjdk.java.net/~mduigou/JDK-8014269/0/webrev/ Looks good. Tim From gnu.andrew at redhat.com Thu May 9 16:10:06 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 9 May 2013 12:10:06 -0400 (EDT) Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: <630646019.8220662.1367935070589.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <1135652122.2176747.1365600923712.JavaMail.root@redhat.com> <5166205F.4060300@oracle.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> Message-ID: <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > On 7/05/2013 1:19 PM, Martin Buchholz wrote: > > > On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes > > > wrote: > > > > > > HotSpot is even more of a problem because not being able to commit > > > directly > > > risks people losing credit for the work they've done and, with an > > > open source > > > project, credit is the only reward. > > > > > > > > > It *is* possible with mercurial to create/import/manipulate changesets > > > with a different user, so that credit remains with the true author even > > > when first submitted into mercurial by an Oracle employee. And that > > > should be the standard practice. > > > > Absolutely! If a non-Oracle person can create a changeset then the > > Oracle sponsor can import it and push via JPRT. Otherwise the sponsor > > should create a changeset with a Contributed-by attribution. > > > > Indeed. I do this with the Oracle patches when applying them to IcedTea. > The problem is how this gets done is down to the sponsor; I've had ones > that have been imported, ones where I've just been giving the Contributed-by > attribution (despite having commit rights) and at least one with no credit at > all. > > A simple solution to this would be to setup a hotspot-jprt tree where > non-Oracle > people can commit their changesets. An Oracle employee can then run it > through > JPRT and pull it into one of the other trees, in much the same way trees are > already > promoted to the main HotSpot & jdk8 trees. This has the advantage that the > committer > retains control of their changeset and also means that bulk JPRT processing > could be > performed if appropriate. > > > David > > An example I just came across when looking into an issue: changeset: 2657:46cb9a7b8b01 parent: 2647:ca1f1753c866 user: dsamersoff date: Wed Aug 10 15:04:21 2011 +0400 files: src/share/vm/runtime/os.cpp description: 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: aph at redhat.com That should have had 'aph' as the user. If you get the default output: changeset: 2657:46cb9a7b8b01 parent: 2647:ca1f1753c866 user: dsamersoff date: Wed Aug 10 15:04:21 2011 +0400 summary: 7073913: The fix for 7017193 causes segfaults it looks like Dmitry wrote the fix. -- 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 david.r.chase at oracle.com Thu May 9 18:10:37 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 9 May 2013 14:10:37 -0400 Subject: Is slowdebug supposed to also compile JNI portions of JDK with -g? Message-ID: Because for me it did not, at least not on a Mac. My workaround, which was not too painful because the new build seems to use fully-qualified path names: touch jdk/src/share/native/java/util/zip/CRC32.c make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug ... touch jdk/src/share/native/java/util/zip/CRC32.c # copy compilation command line from above log, add -g, paste ... /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -g ... /Users/dr2chase/work/jdk8tl-full/jdk/src/share/native/java/util/zip/CRC32.c make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug and now I am debugging. But it would be better yet to compile those files for debugging. David From boaznahum at gmail.com Thu May 9 18:15:00 2013 From: boaznahum at gmail.com (Boaz Nahum) Date: Thu, 9 May 2013 21:15:00 +0300 Subject: make clean images fails on windows 8 Message-ID: e:\dev\jdkbuild\ll5\hotspot\src\share\vm\classfile\defaultmethods.cpp(1082) : error C4716: 'ShadowChecker::path_has_shadow' : must return a value Compiling... verificationType.cpp verifier.cpp Known issue or I'm doing wrong ? Thanks Boaz From dmitry.samersoff at oracle.com Thu May 9 19:02:08 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 09 May 2013 23:02:08 +0400 Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <1135652122.2176747.1365600923712.JavaMail.root@redhat.com> <5166205F.4060300@oracle.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> Message-ID: <518BF2B0.5020904@oracle.com> Andrew, Never plan to steel your credit - so please, accept my apologies. The problem with external contributors is going to be solved but unfortunately it couldn't be done just over a weekend. -Dmitry On 2013-05-09 20:10, Andrew Hughes wrote: > > > ----- Original Message ----- >> >> >> ----- Original Message ----- >>> On 7/05/2013 1:19 PM, Martin Buchholz wrote: >>>> On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes >>> > wrote: >>>> >>>> HotSpot is even more of a problem because not being able to commit >>>> directly >>>> risks people losing credit for the work they've done and, with an >>>> open source >>>> project, credit is the only reward. >>>> >>>> >>>> It *is* possible with mercurial to create/import/manipulate changesets >>>> with a different user, so that credit remains with the true author even >>>> when first submitted into mercurial by an Oracle employee. And that >>>> should be the standard practice. >>> >>> Absolutely! If a non-Oracle person can create a changeset then the >>> Oracle sponsor can import it and push via JPRT. Otherwise the sponsor >>> should create a changeset with a Contributed-by attribution. >>> >> >> Indeed. I do this with the Oracle patches when applying them to IcedTea. >> The problem is how this gets done is down to the sponsor; I've had ones >> that have been imported, ones where I've just been giving the Contributed-by >> attribution (despite having commit rights) and at least one with no credit at >> all. >> >> A simple solution to this would be to setup a hotspot-jprt tree where >> non-Oracle >> people can commit their changesets. An Oracle employee can then run it >> through >> JPRT and pull it into one of the other trees, in much the same way trees are >> already >> promoted to the main HotSpot & jdk8 trees. This has the advantage that the >> committer >> retains control of their changeset and also means that bulk JPRT processing >> could be >> performed if appropriate. >> >>> David >>> > > An example I just came across when looking into an issue: > > changeset: 2657:46cb9a7b8b01 > parent: 2647:ca1f1753c866 > user: dsamersoff > date: Wed Aug 10 15:04:21 2011 +0400 > files: src/share/vm/runtime/os.cpp > description: > 7073913: The fix for 7017193 causes segfaults > Summary: Buffer overflow in os::get_line_chars > Reviewed-by: coleenp, dholmes, dcubed > Contributed-by: aph at redhat.com > > That should have had 'aph' as the user. If you get the default output: > > changeset: 2657:46cb9a7b8b01 > parent: 2647:ca1f1753c866 > user: dsamersoff > date: Wed Aug 10 15:04:21 2011 +0400 > summary: 7073913: The fix for 7017193 causes segfaults > > it looks like Dmitry wrote the fix. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From maurizio.cimadamore at oracle.com Thu May 9 19:42:04 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 09 May 2013 20:42:04 +0100 Subject: make clean images fails on windows 8 In-Reply-To: References: Message-ID: <518BFC0C.8010204@oracle.com> On 09/05/13 19:15, Boaz Nahum wrote: > e:\dev\jdkbuild\ll5\hotspot\src\share\vm\classfile\defaultmethods.cpp(1082) > : error C4716: 'ShadowChecker::path_has_shadow' : must return a value > Compiling... > verificationType.cpp > verifier.cpp > > Known issue or I'm doing wrong ? > > Thanks > Boaz Yep we know about those failures, working on it. Maurizio From mark.reinhold at oracle.com Thu May 9 21:47:41 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 09 May 2013 14:47:41 -0700 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com>, <1135652122.2176747.1365600923712.JavaMail.root@redhat.com>, <5166205F.4060300@oracle.com>, <51662722.8010309@oracle.com>, <1249884052.6079602.1367510783555.JavaMail.root@redhat.com>, , <51887EAC.60804@oracle.com>, <630646019.8220662.1367935070589.JavaMail.root@redhat.com>, <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> Message-ID: <20130509144741.733107@eggemoggin.niobe.net> 2013/5/9 2:10 -0700, gnu.andrew at redhat.com: >> Indeed. I do this with the Oracle patches when applying them to IcedTea. >> The problem is how this gets done is down to the sponsor; I've had ones >> that have been imported, ones where I've just been giving the Contributed-by >> attribution (despite having commit rights) and at least one with no credit at > ... > > An example I just came across when looking into an issue: > > changeset: 2657:46cb9a7b8b01 > parent: 2647:ca1f1753c866 > user: dsamersoff > date: Wed Aug 10 15:04:21 2011 +0400 > files: src/share/vm/runtime/os.cpp > description: > 7073913: The fix for 7017193 causes segfaults > Summary: Buffer overflow in os::get_line_chars > Reviewed-by: coleenp, dholmes, dcubed > Contributed-by: aph at redhat.com > > That should have had 'aph' as the user. If you get the default output: > > changeset: 2657:46cb9a7b8b01 > parent: 2647:ca1f1753c866 > user: dsamersoff > date: Wed Aug 10 15:04:21 2011 +0400 > summary: 7073913: The fix for 7017193 causes segfaults > > it looks like Dmitry wrote the fix. I'm sure there was no intent on Dmitry's part to try to claim credit for this fix. The most important principle to be maintained here is that people get proper credit for their work, as you wrote earlier. Beyond that, it's reasonable to prefer that credit be given in the "most obvious" way, in particular by using proper usernames, when available, in changesets. If a sponsor makes a mistake, however, and winds up using a Contributed-by: line instead, then that's unfortunate but not, in my view, the end of the world. In general, if you have the Author role (or higher) in some OpenJDK Project then when you submit a change that requires a sponsor's help you should send a Mercurial patch (hg export) or bundle (hg bundle) with the proper username, summary, etc. In normal circumstances the sponsor should not change the patch but merely make sure that it's properly tested, merged, and pushed. If a change is required then the sponsor should ask the submitter to create a new patch or bundle. If for some reason the sponsor must modify the patch directly then the hg -u option should be used, as appropriate, to preserve the submitter's user name in the changeset. (Yes, this is one of those rare cases in which a sponsor should use the -u option.) Iris -- Could you please make a note to add guidance on this issue to the next revision of the developers' guide? Thanks. - Mark From david.katleman at oracle.com Thu May 9 22:05:36 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Thu, 09 May 2013 22:05:36 +0000 Subject: hg: jdk8/build/jdk: 8014289: JDK8 b89 source with GPL header errors Message-ID: <20130509220603.891EA4895F@hg.openjdk.java.net> Changeset: 1f1699686504 Author: katleman Date: 2013-05-09 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1f1699686504 8014289: JDK8 b89 source with GPL header errors Reviewed-by: mchung, mduigou, tbell, dsamersoff ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/StringJoiner.java ! test/java/lang/CharSequence/DefaultTest.java ! test/java/util/StringJoiner/StringJoinerTest.java From philip.race at oracle.com Thu May 9 22:14:26 2013 From: philip.race at oracle.com (Phil Race) Date: Thu, 09 May 2013 15:14:26 -0700 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <20130509144741.733107@eggemoggin.niobe.net> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com>, <1135652122.2176747.1365600923712.JavaMail.root@redhat.com>, <5166205F.4060300@oracle.com>, <51662722.8010309@oracle.com>, <1249884052.6079602.1367510783555.JavaMail.root@redhat.com>, , <51887EAC.60804@oracle.com>, <630646019.8220662.1367935070589.JavaMail.root@redhat.com>, <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> Message-ID: <518C1FC2.5030401@oracle.com> > (Yes, this is one of those rare cases in which a sponsor should use the -u option.) I'd hazard a guess that there are number of people who overlook this option in part because they don't realise you can do hg commit -u ... I was kind of surprised myself when I first learned to do this as it seemed odd that someone else could claim a changeset was from another person. I thought you would need their private key to be able to do that. -phil. On 5/9/2013 2:47 PM, mark.reinhold at oracle.com wrote: > 2013/5/9 2:10 -0700, gnu.andrew at redhat.com: >>> Indeed. I do this with the Oracle patches when applying them to IcedTea. >>> The problem is how this gets done is down to the sponsor; I've had ones >>> that have been imported, ones where I've just been giving the Contributed-by >>> attribution (despite having commit rights) and at least one with no credit at >> ... >> >> An example I just came across when looking into an issue: >> >> changeset: 2657:46cb9a7b8b01 >> parent: 2647:ca1f1753c866 >> user: dsamersoff >> date: Wed Aug 10 15:04:21 2011 +0400 >> files: src/share/vm/runtime/os.cpp >> description: >> 7073913: The fix for 7017193 causes segfaults >> Summary: Buffer overflow in os::get_line_chars >> Reviewed-by: coleenp, dholmes, dcubed >> Contributed-by: aph at redhat.com >> >> That should have had 'aph' as the user. If you get the default output: >> >> changeset: 2657:46cb9a7b8b01 >> parent: 2647:ca1f1753c866 >> user: dsamersoff >> date: Wed Aug 10 15:04:21 2011 +0400 >> summary: 7073913: The fix for 7017193 causes segfaults >> >> it looks like Dmitry wrote the fix. > I'm sure there was no intent on Dmitry's part to try to claim credit for > this fix. > > The most important principle to be maintained here is that people get > proper credit for their work, as you wrote earlier. > > Beyond that, it's reasonable to prefer that credit be given in the "most > obvious" way, in particular by using proper usernames, when available, > in changesets. If a sponsor makes a mistake, however, and winds up > using a Contributed-by: line instead, then that's unfortunate but not, > in my view, the end of the world. > > In general, if you have the Author role (or higher) in some OpenJDK > Project then when you submit a change that requires a sponsor's help you > should send a Mercurial patch (hg export) or bundle (hg bundle) with the > proper username, summary, etc. In normal circumstances the sponsor > should not change the patch but merely make sure that it's properly > tested, merged, and pushed. If a change is required then the sponsor > should ask the submitter to create a new patch or bundle. If for some > reason the sponsor must modify the patch directly then the hg -u option > should be used, as appropriate, to preserve the submitter's user name in > the changeset. (Yes, this is one of those rare cases in which a sponsor > should use the -u option.) > > Iris -- Could you please make a note to add guidance on this issue to > the next revision of the developers' guide? Thanks. > > - Mark From mark.reinhold at oracle.com Thu May 9 22:20:11 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 09 May 2013 15:20:11 -0700 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <518C1FC2.5030401@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com>, <20130509144741.733107@eggemoggin.niobe.net>, <518C1FC2.5030401@oracle.com> Message-ID: <20130509152011.762696@eggemoggin.niobe.net> 2013/5/9 8:14 -0700, philip.race at oracle.com: >> (Yes, this is one of those rare cases in which a sponsor should use >> the -u option.) > > I'd hazard a guess that there are number of people who overlook this option > in part because they don't realise you can do > > hg commit -u ... > > I was kind of surprised myself when I first learned to do this as it > seemed odd that someone else could claim a changeset was from > another person. I thought you would need their private key to > be able to do that. No, your ssh key is used only to authenticate you to the hg server when you do a push. Modulo the constraints imposed by jcheck, you can use the -u option to set the username string to anything you want. FYI, in recent versions of Mercurial the -u option is, conveniently, supported in commands other than commit, e.g., import, qnew, and qref. - Mark From sundararajan.athijegannathan at oracle.com Fri May 10 09:26:05 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 May 2013 14:56:05 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518382B1.6040501@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> Message-ID: <518CBD2D.4000301@oracle.com> Please review the updated webrev @ http://cr.openjdk.java.net/~sundar/8012975/webrev.01/ Thanks -Sundar On Friday 03 May 2013 02:56 PM, Alan Bateman wrote: > On 03/05/2013 07:47, A. Sundararajan wrote: >> >> Thanks. Looks like the first one has not been removed. But second one >> was removed: hg stat shows >> >> R make/sun/org/mozilla/javascript/Makefile >> >> (also the webrev shows it as removed). Perhaps patch does not take >> care of deleted files?? I am not sure. Also, build seems to go >> through without removing first one!! >> >> I'll remove that, build/test again and send another webrev. > One other one is make/tools/src/build/tools/deps/refs.allowed. The > last two lines can be replaced with: > > java.beans.PropertyChangeListener=java.util.logging.LogManager,compact1,compact2,compact3 > > > and the comment line about Rhino can be removed. > > -Alan. From Alan.Bateman at oracle.com Fri May 10 09:33:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 May 2013 10:33:05 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CBD2D.4000301@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> Message-ID: <518CBED1.8010609@oracle.com> On 10/05/2013 10:26, A. Sundararajan wrote: > Please review the updated webrev @ > http://cr.openjdk.java.net/~sundar/8012975/webrev.01/ > > Thanks > -Sundar > PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script removed. refs.allowed isn't quite right, the last line needs to be removed completely. Otherwise looks okay to me. -Alan. From sundararajan.athijegannathan at oracle.com Fri May 10 10:23:33 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 May 2013 15:53:33 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CBED1.8010609@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> Message-ID: <518CCAA5.3060205@oracle.com> com/sun/script/util is generic utility package for script engine implementations. Only com/sun/script/javascript package is being removed. Since we include javax/script for profile 3, should we also include com/sun/script/util ? On refs.allowed, I'll remove it. How should I check this? Thanks -Sundar On Friday 10 May 2013 03:03 PM, Alan Bateman wrote: > On 10/05/2013 10:26, A. Sundararajan wrote: >> Please review the updated webrev @ >> http://cr.openjdk.java.net/~sundar/8012975/webrev.01/ >> >> Thanks >> -Sundar >> > PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script removed. > > refs.allowed isn't quite right, the last line needs to be removed > completely. > > Otherwise looks okay to me. > > -Alan. > From Alan.Bateman at oracle.com Fri May 10 10:39:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 May 2013 11:39:04 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CCAA5.3060205@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> Message-ID: <518CCE48.3090309@oracle.com> On 10/05/2013 11:23, A. Sundararajan wrote: > com/sun/script/util is generic utility package for script engine > implementations. Only com/sun/script/javascript package is being > removed. Since we include javax/script for profile 3, should we also > include com/sun/script/util ? Is com.sun.script.util meant to be a supported/documented API? Do you know if anything outside of the JDK is using it? Is Nashorn using it? The only usage I see is in com.sun.script.javascript so this is why I assumed that com.sun.script.** would go away. As you know, we moved javax.script to compact1. It doesn't require com.sun.script.util of course but if this is used by 3rd party scripting engines then it may have to be added to compact1 builds to get them working. > > On refs.allowed, I'll remove it. How should I check this? "make profiles" on Linux should be fine. As part of the profiles build it will run a dependency analyzer that checks for references to types that do not exist (this is catch configuration issues). -Alan From gnu.andrew at redhat.com Fri May 10 11:38:51 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 10 May 2013 07:38:51 -0400 (EDT) Subject: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds In-Reply-To: <518BF2B0.5020904@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <518BF2B0.5020904@oracle.com> Message-ID: <705890829.9816399.1368185931259.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > Never plan to steel your credit - so please, accept my apologies. > I wasn't saying you did. It was just an example that we get a mix of authorship, Contributed-By and no credit at all. It happened to be that one because I was looking up the fix for other reasons (we've had to revert 7017193 due to the performance issues). > The problem with external contributors is going to be solved but > unfortunately it couldn't be done just over a weekend. > Er.. yes it can. Just add a HotSpot tree, as I suggested, that non-Oracle people can commit to and which is then run through JPRT. That doesn't take a weekend. It takes like all of five minutes to add a new tree on the hg servers. > -Dmitry > > On 2013-05-09 20:10, Andrew Hughes wrote: > > > > > > ----- Original Message ----- > >> > >> > >> ----- Original Message ----- > >>> On 7/05/2013 1:19 PM, Martin Buchholz wrote: > >>>> On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes >>>> > wrote: > >>>> > >>>> HotSpot is even more of a problem because not being able to commit > >>>> directly > >>>> risks people losing credit for the work they've done and, with an > >>>> open source > >>>> project, credit is the only reward. > >>>> > >>>> > >>>> It *is* possible with mercurial to create/import/manipulate changesets > >>>> with a different user, so that credit remains with the true author even > >>>> when first submitted into mercurial by an Oracle employee. And that > >>>> should be the standard practice. > >>> > >>> Absolutely! If a non-Oracle person can create a changeset then the > >>> Oracle sponsor can import it and push via JPRT. Otherwise the sponsor > >>> should create a changeset with a Contributed-by attribution. > >>> > >> > >> Indeed. I do this with the Oracle patches when applying them to IcedTea. > >> The problem is how this gets done is down to the sponsor; I've had ones > >> that have been imported, ones where I've just been giving the > >> Contributed-by > >> attribution (despite having commit rights) and at least one with no credit > >> at > >> all. > >> > >> A simple solution to this would be to setup a hotspot-jprt tree where > >> non-Oracle > >> people can commit their changesets. An Oracle employee can then run it > >> through > >> JPRT and pull it into one of the other trees, in much the same way trees > >> are > >> already > >> promoted to the main HotSpot & jdk8 trees. This has the advantage that > >> the > >> committer > >> retains control of their changeset and also means that bulk JPRT > >> processing > >> could be > >> performed if appropriate. > >> > >>> David > >>> > > > > An example I just came across when looking into an issue: > > > > changeset: 2657:46cb9a7b8b01 > > parent: 2647:ca1f1753c866 > > user: dsamersoff > > date: Wed Aug 10 15:04:21 2011 +0400 > > files: src/share/vm/runtime/os.cpp > > description: > > 7073913: The fix for 7017193 causes segfaults > > Summary: Buffer overflow in os::get_line_chars > > Reviewed-by: coleenp, dholmes, dcubed > > Contributed-by: aph at redhat.com > > > > That should have had 'aph' as the user. If you get the default output: > > > > changeset: 2657:46cb9a7b8b01 > > parent: 2647:ca1f1753c866 > > user: dsamersoff > > date: Wed Aug 10 15:04:21 2011 +0400 > > summary: 7073913: The fix for 7017193 causes segfaults > > > > it looks like Dmitry wrote the fix. > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the source code. > -- 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 andrew_nuss at yahoo.com Fri May 10 11:58:16 2013 From: andrew_nuss at yahoo.com (Andy Nuss) Date: Fri, 10 May 2013 04:58:16 -0700 (PDT) Subject: how to install and build Message-ID: <1368187096.36725.YahooMailNeo@web141101.mail.bf1.yahoo.com> Hi, I want to install jdk 7 project for linux 64, and make a simple change to Object.java and test it.? What do I do? Andy From sundararajan.athijegannathan at oracle.com Fri May 10 12:47:33 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 May 2013 18:17:33 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CCE48.3090309@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> Message-ID: <518CEC65.7050006@oracle.com> Okay, thanks. com.sun.script.util is not supported API (no CCC done for it in the past). I'll remove it as suggested and run "make profiles" to check Thanks -Sundar On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: > On 10/05/2013 11:23, A. Sundararajan wrote: >> com/sun/script/util is generic utility package for script engine >> implementations. Only com/sun/script/javascript package is being >> removed. Since we include javax/script for profile 3, should we also >> include com/sun/script/util ? > Is com.sun.script.util meant to be a supported/documented API? Do you > know if anything outside of the JDK is using it? Is Nashorn using it? > The only usage I see is in com.sun.script.javascript so this is why I > assumed that com.sun.script.** would go away. > > As you know, we moved javax.script to compact1. It doesn't require > com.sun.script.util of course but if this is used by 3rd party > scripting engines then it may have to be added to compact1 builds to > get them working. > >> >> On refs.allowed, I'll remove it. How should I check this? > "make profiles" on Linux should be fine. As part of the profiles build > it will run a dependency analyzer that checks for references to types > that do not exist (this is catch configuration issues). > > -Alan From weijun.wang at oracle.com Fri May 10 13:17:50 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 10 May 2013 21:17:50 +0800 Subject: how to install and build In-Reply-To: <1368187096.36725.YahooMailNeo@web141101.mail.bf1.yahoo.com> References: <1368187096.36725.YahooMailNeo@web141101.mail.bf1.yahoo.com> Message-ID: <518CF37E.1050504@oracle.com> Hi Andy If you only want to make small changes to .java files, just download the source code for those files, compile them with javac -d /tmp Those.java and call java -Xbootclasspath/p:/tmp YourApp to try out. If you don't like the -X option, you can call "jar uvf" to update the class files inside rt.jar with your newly built ones. -Max On 5/10/13 7:58 PM, Andy Nuss wrote: > Hi, > > I want to install jdk 7 project for linux 64, and make a simple change to Object.java and test it. What do I do? > > Andy > From tim.bell at oracle.com Fri May 10 14:46:51 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 10 May 2013 07:46:51 -0700 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CEC65.7050006@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> Message-ID: <518D085B.2090301@oracle.com> Hi Sundar Looks like you have resolved the subtleties of profiles with Alan. The rest looks good to me. Tim On 05/10/13 05:47 AM, A. Sundararajan wrote: > Okay, thanks. com.sun.script.util is not supported API (no CCC done > for it in the past). I'll remove it as suggested and run "make > profiles" to check > > Thanks > -Sundar > > On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: >> On 10/05/2013 11:23, A. Sundararajan wrote: >>> com/sun/script/util is generic utility package for script engine >>> implementations. Only com/sun/script/javascript package is being >>> removed. Since we include javax/script for profile 3, should we also >>> include com/sun/script/util ? >> Is com.sun.script.util meant to be a supported/documented API? Do you >> know if anything outside of the JDK is using it? Is Nashorn using it? >> The only usage I see is in com.sun.script.javascript so this is why I >> assumed that com.sun.script.** would go away. >> >> As you know, we moved javax.script to compact1. It doesn't require >> com.sun.script.util of course but if this is used by 3rd party >> scripting engines then it may have to be added to compact1 builds to >> get them working. >> >>> >>> On refs.allowed, I'll remove it. How should I check this? >> "make profiles" on Linux should be fine. As part of the profiles >> build it will run a dependency analyzer that checks for references to >> types that do not exist (this is catch configuration issues). >> >> -Alan > From gnu.andrew at redhat.com Fri May 10 16:53:40 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 10 May 2013 12:53:40 -0400 (EDT) Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <20130509144741.733107@eggemoggin.niobe.net> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> Message-ID: <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> ----- Original Message ----- > 2013/5/9 2:10 -0700, gnu.andrew at redhat.com: > >> Indeed. I do this with the Oracle patches when applying them to IcedTea. > >> The problem is how this gets done is down to the sponsor; I've had ones > >> that have been imported, ones where I've just been giving the > >> Contributed-by > >> attribution (despite having commit rights) and at least one with no credit > >> at > > ... > > > > An example I just came across when looking into an issue: > > > > changeset: 2657:46cb9a7b8b01 > > parent: 2647:ca1f1753c866 > > user: dsamersoff > > date: Wed Aug 10 15:04:21 2011 +0400 > > files: src/share/vm/runtime/os.cpp > > description: > > 7073913: The fix for 7017193 causes segfaults > > Summary: Buffer overflow in os::get_line_chars > > Reviewed-by: coleenp, dholmes, dcubed > > Contributed-by: aph at redhat.com > > > > That should have had 'aph' as the user. If you get the default output: > > > > changeset: 2657:46cb9a7b8b01 > > parent: 2647:ca1f1753c866 > > user: dsamersoff > > date: Wed Aug 10 15:04:21 2011 +0400 > > summary: 7073913: The fix for 7017193 causes segfaults > > > > it looks like Dmitry wrote the fix. > > I'm sure there was no intent on Dmitry's part to try to claim credit for > this fix. > I didn't say there was. All I said was it looks, from that output, like Dmitry wrote it. I was actually puzzled by it myself, which is why I ran the command again with -v. > The most important principle to be maintained here is that people get > proper credit for their work, as you wrote earlier. > > Beyond that, it's reasonable to prefer that credit be given in the "most > obvious" way, in particular by using proper usernames, when available, > in changesets. If a sponsor makes a mistake, however, and winds up > using a Contributed-by: line instead, then that's unfortunate but not, > in my view, the end of the world. I didn't say it was. It is, however, something that could easily be avoided. There's also a third possibility, which I mentioned but you didn't comment on, which is that neither credit is given. People do make mistakes. > > In general, if you have the Author role (or higher) in some OpenJDK > Project then when you submit a change that requires a sponsor's help you > should send a Mercurial patch (hg export) or bundle (hg bundle) with the > proper username, summary, etc. In normal circumstances the sponsor > should not change the patch but merely make sure that it's properly > tested, merged, and pushed. If a change is required then the sponsor > should ask the submitter to create a new patch or bundle. If for some > reason the sponsor must modify the patch directly then the hg -u option > should be used, as appropriate, to preserve the submitter's user name in > the changeset. (Yes, this is one of those rare cases in which a sponsor > should use the -u option.) > It was my understanding that patches should be submitted as "webrevs". Has this changed? This discussion was not about authors who need a sponsor, but about those with commit rights and should be able to push, according to the bylaws, but can't due to additional restrictions imposed on top of the bylaws by Oracle (and only for HotSpot). I have offered a very simple solution to that problem to which no-one has yet given any reason as to why we should not implemented it; simply add a HotSpot tree where pushes can be made prior to JPRT runs, then perform the JPRT runs on the commits in that tree before merging to the main HotSpot tree. Problem solved. > Iris -- Could you please make a note to add guidance on this issue to > the next revision of the developers' guide? Thanks. > > - Mark > -- 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 joe.darcy at oracle.com Fri May 10 21:06:27 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2013 14:06:27 -0700 Subject: JDK 8 code review request of langtools build changes for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) Message-ID: <518D6153.1020001@oracle.com> Hello, Please review the patch below for JDK-8014365 "Restore Objects.requireNonNull(T, Supplier)" which addresses the issue tripped over during JDK-8012344 "Backout 8011800 until langtools genstubs updated." A full build with the below patch to langtools and the update JDK library succeeds. Thanks, -Joe diff -r ce7e1674eb73 makefiles/BuildLangtools.gmk --- a/makefiles/BuildLangtools.gmk Fri May 10 16:10:20 2013 +0100 +++ b/makefiles/BuildLangtools.gmk Fri May 10 14:04:29 2013 -0700 @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2012, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2013, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -123,10 +123,10 @@ genstubs.GenStubs # We fetch source from the JDK... JDKS=$(JDK_TOPDIR)/src/share/classes - # Build the list of classes to generate stubs from. java/util/Objects.java isn't + # Build the list of classes to generate stubs from. java/util/function/Predicate.java isn't # currently needed, but is used as a demo for now. STUBSOURCES:=$(shell $(FIND) $(JDKS) -name "*.java" | $(GREP) \ - -e "$(JDKS)/java/util/Objects.java") + -e "$(JDKS)/java/util/function/Predicate.java") # Rewrite the file names into class names because the GenStubs tool require this. STUBCLASSES:=$(subst /,.,$(patsubst $(JDKS)/%.java,%,$(STUBSOURCES))) From jonathan.gibbons at oracle.com Fri May 10 21:20:13 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 10 May 2013 14:20:13 -0700 Subject: JDK 8 code review request of langtools build changes for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <518D6153.1020001@oracle.com> References: <518D6153.1020001@oracle.com> Message-ID: <518D648D.9040203@oracle.com> Looks good to me. -- Jon On 05/10/2013 02:06 PM, Joe Darcy wrote: > Hello, > > Please review the patch below for JDK-8014365 "Restore > Objects.requireNonNull(T, Supplier)" which addresses the issue > tripped over during JDK-8012344 "Backout 8011800 until langtools > genstubs updated." > > A full build with the below patch to langtools and the update JDK > library succeeds. > > Thanks, > > -Joe > > diff -r ce7e1674eb73 makefiles/BuildLangtools.gmk > --- a/makefiles/BuildLangtools.gmk Fri May 10 16:10:20 2013 +0100 > +++ b/makefiles/BuildLangtools.gmk Fri May 10 14:04:29 2013 -0700 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2012, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -123,10 +123,10 @@ > genstubs.GenStubs > # We fetch source from the JDK... > JDKS=$(JDK_TOPDIR)/src/share/classes > - # Build the list of classes to generate stubs from. > java/util/Objects.java isn't > + # Build the list of classes to generate stubs from. > java/util/function/Predicate.java isn't > # currently needed, but is used as a demo for now. > STUBSOURCES:=$(shell $(FIND) $(JDKS) -name "*.java" | $(GREP) \ > - -e "$(JDKS)/java/util/Objects.java") > + -e "$(JDKS)/java/util/function/Predicate.java") > # Rewrite the file names into class names because the > GenStubs tool require this. > STUBCLASSES:=$(subst /,.,$(patsubst > $(JDKS)/%.java,%,$(STUBSOURCES))) > From tim.bell at oracle.com Fri May 10 22:16:49 2013 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 10 May 2013 15:16:49 -0700 Subject: MacOS build tool selections for JDK8 Message-ID: <518D71D1.3080706@oracle.com> All- The question of what toolchain to use on MacOS when building JDK8 is in play. This is important because the decisions we make in the next few weeks will be in place for the lifetime of JDK8, including all future JDK8 update releases. I have a few different pieces of feedback at this point, and (due to my own ignorance of the developer environment choices on MacOS), I'd like to throw the discussion out to a larger audience of MacOS developers. 1) Use gcc as the build does today. 2) Use Clang. 3) Support both (since they should both compile the same source) but identify Clang as the official tool. 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) As part of the build-infrastructure team, my #1 concern is getting solid, repeatable builds from the toolchain, every time, that that's what I mean by 'official'. If developers feel adventurous and want to run out ahead using bleeding edge tools, good for them - have fun. What we would like to define here is a solid baseline of what we use to run the official from-scratch JDK8 builds. That said, I'd like to nail down the tools used, and the specific version of the tools. Thanks in advance for any feedback. Tim Bell Java Platform Group Infrastructure From david.r.chase at oracle.com Sat May 11 12:00:35 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 11 May 2013 08:00:35 -0400 Subject: MacOS build tool selections for JDK8 In-Reply-To: <518D71D1.3080706@oracle.com> References: <518D71D1.3080706@oracle.com> Message-ID: <158B7607-FD89-48A5-937F-108652540479@oracle.com> Which version of MacOS? 10.8.3 is current, rumor is 10.9 is coming sometime later this year, and we had problems obtaining boxes running 10.7 for testing purposes. We may have a similar problem later this year; I imagine that new Macs for testing and/or development get purchased after June, 10.9 is released in July, and the paper-shuffling pipeline takes long enough that the boxes arrive with 10.9 pre-installed. One reason to prefer clang is that it is somewhat more modern; if you wanted to take advantage of some of the newer Intel instruction set features using intrinsics, you would need to use clang, and not the default gcc that ships with XCode. The default gnu assembler on the Mac (not what you could get if you installed binutils yourself) also fails to recognize these intrinsics. Clang apparently warns more often and somewhat incompatibly. See this recent thread (which it turns out is about warnings from clang): http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-May/006995.html My mother-and-apple-pie instincts say to clean up code till clang is happy with it. Whether you go with clang or gcc, you probably want to specify a particular version of XCode, since that is the usual source (I think) of both. Another option is MacPorts, which provides access to (at least) gcc/++ 4.5 and gcc/++ 4.8, though it does not configure them to use a sufficiently modern assembler to access the intrinsics. One difficulty here, speaking as a habitual Mac user (I can stop any time I want to), is that the behavior that is promoted by the App Store is upgrade-upgrade-upgrade, and that includes XCode, which means gcc and clang. David From david.r.chase at oracle.com Sun May 12 15:04:12 2013 From: david.r.chase at oracle.com (David Chase) Date: Sun, 12 May 2013 11:04:12 -0400 Subject: MacOS build tool selections for JDK8 In-Reply-To: <158B7607-FD89-48A5-937F-108652540479@oracle.com> References: <518D71D1.3080706@oracle.com> <158B7607-FD89-48A5-937F-108652540479@oracle.com> Message-ID: <1C68A18A-8BB9-460B-B664-BC23205CF45E@oracle.com> A problem with gcc-4.8 as installed by MacPorts, if we ever intended to build 32-bit binaries: gcc-mp-4.8 -O -m32 -msse -mpclmul -mavx TryLoop.c -lz ld: warning: ignoring file /opt/local/lib/gcc48/libgcc_ext.10.5.dylib, missing required architecture i386 in file /opt/local/lib/gcc48/libgcc_ext.10.5.dylib (1 slices) ld: warning: ignoring file /opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.1/libgcc.a, file was built for archive which is not the architecture being linked (i386): /opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.1/libgcc.a clang handles both the shiny new intrinsics AND the -m32 correctly, and at the same time. David From dmitry.samersoff at oracle.com Sun May 12 22:42:27 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 13 May 2013 02:42:27 +0400 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <20130509144741.733107@eggemoggin.niobe.net> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com>, <1135652122.2176747.1365600923712.JavaMail.root@redhat.com>, <5166205F.4060300@oracle.com>, <51662722.8010309@oracle.com>, <1249884052.6079602.1367510783555.JavaMail.root@redhat.com>, , <51887EAC.60804@oracle.com>, <630646019.8220662.1367935070589.JavaMail.root@redhat.com>, <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> Message-ID: <51901AD3.5010004@oracle.com> Mark, I did some experiments on weekends and I'm against of using -u option under any circumstances. People sponsoring changeset can make a mistake - most obvious one is wrong merge conflict resolution. If it happens we are loosing the way to solve the problem quickly - author know nothing about conflict but we have no obvious record about sponsor. So I think we have only two options (leaving aside extra repo) - a) author prepare changeset by it's own and sponsor acts just as slow bot - all problems transmitted back to author. b) author send a webrev and sponsor uses Contributed-by: field to respect credits. -Dmitry On 2013-05-10 01:47, mark.reinhold at oracle.com wrote: > 2013/5/9 2:10 -0700, gnu.andrew at redhat.com: >>> Indeed. I do this with the Oracle patches when applying them to IcedTea. >>> The problem is how this gets done is down to the sponsor; I've had ones >>> that have been imported, ones where I've just been giving the Contributed-by >>> attribution (despite having commit rights) and at least one with no credit at >> ... >> >> An example I just came across when looking into an issue: >> >> changeset: 2657:46cb9a7b8b01 >> parent: 2647:ca1f1753c866 >> user: dsamersoff >> date: Wed Aug 10 15:04:21 2011 +0400 >> files: src/share/vm/runtime/os.cpp >> description: >> 7073913: The fix for 7017193 causes segfaults >> Summary: Buffer overflow in os::get_line_chars >> Reviewed-by: coleenp, dholmes, dcubed >> Contributed-by: aph at redhat.com >> >> That should have had 'aph' as the user. If you get the default output: >> >> changeset: 2657:46cb9a7b8b01 >> parent: 2647:ca1f1753c866 >> user: dsamersoff >> date: Wed Aug 10 15:04:21 2011 +0400 >> summary: 7073913: The fix for 7017193 causes segfaults >> >> it looks like Dmitry wrote the fix. > > I'm sure there was no intent on Dmitry's part to try to claim credit for > this fix. > > The most important principle to be maintained here is that people get > proper credit for their work, as you wrote earlier. > > Beyond that, it's reasonable to prefer that credit be given in the "most > obvious" way, in particular by using proper usernames, when available, > in changesets. If a sponsor makes a mistake, however, and winds up > using a Contributed-by: line instead, then that's unfortunate but not, > in my view, the end of the world. > > In general, if you have the Author role (or higher) in some OpenJDK > Project then when you submit a change that requires a sponsor's help you > should send a Mercurial patch (hg export) or bundle (hg bundle) with the > proper username, summary, etc. In normal circumstances the sponsor > should not change the patch but merely make sure that it's properly > tested, merged, and pushed. If a change is required then the sponsor > should ask the submitter to create a new patch or bundle. If for some > reason the sponsor must modify the patch directly then the hg -u option > should be used, as appropriate, to preserve the submitter's user name in > the changeset. (Yes, this is one of those rare cases in which a sponsor > should use the -u option.) > > Iris -- Could you please make a note to add guidance on this issue to > the next revision of the developers' guide? Thanks. > > - Mark > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From david.holmes at oracle.com Mon May 13 02:21:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2013 12:21:31 +1000 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <51662722.8010309@oracle.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> Message-ID: <51904E2B.2050505@oracle.com> On 11/05/2013 2:53 AM, Andrew Hughes wrote: > I have offered a very simple solution to that problem to which no-one has yet > given any reason as to why we should not implemented it; simply add a HotSpot tree > where pushes can be made prior to JPRT runs, then perform the JPRT runs on the commits > in that tree before merging to the main HotSpot tree. Problem solved. You need one of these repos for each of the hotspot group repos, otherwise the changesets won't be correct. You also need an Oracle employee to then push the change through JPRT - and that would be a lot more effort than the existing processes as "we" would need to clone the external repo first, re-parent the clone to the group repo, re-sync from parent if needed, then do JPRT submit. Plus you need someone to update these repos each time the "parent" gets updated. So a simple enough idea, but the logistics are more complex. David From erik.joelsson at oracle.com Mon May 13 08:29:39 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 13 May 2013 10:29:39 +0200 Subject: Is slowdebug supposed to also compile JNI portions of JDK with -g? In-Reply-To: References: Message-ID: <5190A473.5080106@oracle.com> It is supposed to compile everything with debug turned on AFAIK. I will take a look. /Erik On 2013-05-09 20:10, David Chase wrote: > Because for me it did not, at least not on a Mac. > > My workaround, which was not too painful because the new build seems to use fully-qualified path names: > > touch jdk/src/share/native/java/util/zip/CRC32.c > make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug > ... > > touch jdk/src/share/native/java/util/zip/CRC32.c > # copy compilation command line from above log, add -g, paste > ... /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -g ... /Users/dr2chase/work/jdk8tl-full/jdk/src/share/native/java/util/zip/CRC32.c > make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug > > and now I am debugging. > But it would be better yet to compile those files for debugging. > > David > From chris.hegarty at oracle.com Mon May 13 08:32:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 09:32:39 +0100 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <51901AD3.5010004@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com>, <1135652122.2176747.1365600923712.JavaMail.root@redhat.com>, <5166205F.4060300@oracle.com>, <51662722.8010309@oracle.com>, <1249884052.6079602.1367510783555.JavaMail.root@redhat.com>, , <51887EAC.60804@oracle.com>, <630646019.8220662.1367935070589.JavaMail.root@redhat.com>, <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <51901AD3.5010004@oracle.com> Message-ID: <5190A527.3090708@oracle.com> Dmitry, On 12/05/2013 23:42, Dmitry Samersoff wrote: > Mark, > > I did some experiments on weekends and I'm against of using -u option > under any circumstances. There are valid usecases for '-u'. For one, sync'ing from upstream projects, Doug's CVS comes to mind. -Chris. > > People sponsoring changeset can make a mistake - most obvious one is > wrong merge conflict resolution. If it happens we are loosing the way to > solve the problem quickly - author know nothing about conflict but we > have no obvious record about sponsor. > > So I think we have only two options (leaving aside extra repo) - > > a) author prepare changeset by it's own and sponsor acts just as slow > bot - all problems transmitted back to author. > > b) author send a webrev and sponsor uses Contributed-by: field to > respect credits. > > -Dmitry > > > On 2013-05-10 01:47, mark.reinhold at oracle.com wrote: >> 2013/5/9 2:10 -0700, gnu.andrew at redhat.com: >>>> Indeed. I do this with the Oracle patches when applying them to IcedTea. >>>> The problem is how this gets done is down to the sponsor; I've had ones >>>> that have been imported, ones where I've just been giving the Contributed-by >>>> attribution (despite having commit rights) and at least one with no credit at >>> ... >>> >>> An example I just came across when looking into an issue: >>> >>> changeset: 2657:46cb9a7b8b01 >>> parent: 2647:ca1f1753c866 >>> user: dsamersoff >>> date: Wed Aug 10 15:04:21 2011 +0400 >>> files: src/share/vm/runtime/os.cpp >>> description: >>> 7073913: The fix for 7017193 causes segfaults >>> Summary: Buffer overflow in os::get_line_chars >>> Reviewed-by: coleenp, dholmes, dcubed >>> Contributed-by: aph at redhat.com >>> >>> That should have had 'aph' as the user. If you get the default output: >>> >>> changeset: 2657:46cb9a7b8b01 >>> parent: 2647:ca1f1753c866 >>> user: dsamersoff >>> date: Wed Aug 10 15:04:21 2011 +0400 >>> summary: 7073913: The fix for 7017193 causes segfaults >>> >>> it looks like Dmitry wrote the fix. >> >> I'm sure there was no intent on Dmitry's part to try to claim credit for >> this fix. >> >> The most important principle to be maintained here is that people get >> proper credit for their work, as you wrote earlier. >> >> Beyond that, it's reasonable to prefer that credit be given in the "most >> obvious" way, in particular by using proper usernames, when available, >> in changesets. If a sponsor makes a mistake, however, and winds up >> using a Contributed-by: line instead, then that's unfortunate but not, >> in my view, the end of the world. >> >> In general, if you have the Author role (or higher) in some OpenJDK >> Project then when you submit a change that requires a sponsor's help you >> should send a Mercurial patch (hg export) or bundle (hg bundle) with the >> proper username, summary, etc. In normal circumstances the sponsor >> should not change the patch but merely make sure that it's properly >> tested, merged, and pushed. If a change is required then the sponsor >> should ask the submitter to create a new patch or bundle. If for some >> reason the sponsor must modify the patch directly then the hg -u option >> should be used, as appropriate, to preserve the submitter's user name in >> the changeset. (Yes, this is one of those rare cases in which a sponsor >> should use the -u option.) >> >> Iris -- Could you please make a note to add guidance on this issue to >> the next revision of the developers' guide? Thanks. >> >> - Mark >> > > From erik.joelsson at oracle.com Mon May 13 08:53:28 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 13 May 2013 10:53:28 +0200 Subject: JDK 8 code review request of langtools build changes for JDK-8014365 Restore Objects.requireNonNull(T, Supplier) In-Reply-To: <518D6153.1020001@oracle.com> References: <518D6153.1020001@oracle.com> Message-ID: <5190AA08.90506@oracle.com> Looks good to me. On 2013-05-10 23:06, Joe Darcy wrote: > Hello, > > Please review the patch below for JDK-8014365 "Restore > Objects.requireNonNull(T, Supplier)" which addresses the issue > tripped over during JDK-8012344 "Backout 8011800 until langtools > genstubs updated." > > A full build with the below patch to langtools and the update JDK > library succeeds. > > Thanks, > > -Joe > > diff -r ce7e1674eb73 makefiles/BuildLangtools.gmk > --- a/makefiles/BuildLangtools.gmk Fri May 10 16:10:20 2013 +0100 > +++ b/makefiles/BuildLangtools.gmk Fri May 10 14:04:29 2013 -0700 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2012, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2013, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -123,10 +123,10 @@ > genstubs.GenStubs > # We fetch source from the JDK... > JDKS=$(JDK_TOPDIR)/src/share/classes > - # Build the list of classes to generate stubs from. > java/util/Objects.java isn't > + # Build the list of classes to generate stubs from. > java/util/function/Predicate.java isn't > # currently needed, but is used as a demo for now. > STUBSOURCES:=$(shell $(FIND) $(JDKS) -name "*.java" | $(GREP) \ > - -e "$(JDKS)/java/util/Objects.java") > + -e "$(JDKS)/java/util/function/Predicate.java") > # Rewrite the file names into class names because the > GenStubs tool require this. > STUBCLASSES:=$(subst /,.,$(patsubst > $(JDKS)/%.java,%,$(STUBSOURCES))) > From erik.joelsson at oracle.com Mon May 13 10:35:51 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 13 May 2013 12:35:51 +0200 Subject: Is slowdebug supposed to also compile JNI portions of JDK with -g? In-Reply-To: <5190A473.5080106@oracle.com> References: <5190A473.5080106@oracle.com> Message-ID: <5190C207.4000809@oracle.com> I've reproduced your problem. Looks like a mistake in common/autoconf/toolchain.m4. Filed JDK-8014404. /Erik On 2013-05-13 10:29, Erik Joelsson wrote: > It is supposed to compile everything with debug turned on AFAIK. I > will take a look. > > /Erik > > On 2013-05-09 20:10, David Chase wrote: >> Because for me it did not, at least not on a Mac. >> >> My workaround, which was not too painful because the new build seems >> to use fully-qualified path names: >> >> touch jdk/src/share/native/java/util/zip/CRC32.c >> make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug >> ... >> >> touch jdk/src/share/native/java/util/zip/CRC32.c >> # copy compilation command line from above log, add -g, paste >> ... /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -g ... >> /Users/dr2chase/work/jdk8tl-full/jdk/src/share/native/java/util/zip/CRC32.c >> make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug >> >> and now I am debugging. >> But it would be better yet to compile those files for debugging. >> >> David >> From sundararajan.athijegannathan at oracle.com Mon May 13 12:14:24 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 May 2013 17:44:24 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <518CEC65.7050006@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> Message-ID: <5190D920.7090902@oracle.com> Incorporated changes as suggested. Uploaded webrev for historical purpose: http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ PS. I am going ahead with push.. Thanks -Sundar On Friday 10 May 2013 06:17 PM, A. Sundararajan wrote: > Okay, thanks. com.sun.script.util is not supported API (no CCC done > for it in the past). I'll remove it as suggested and run "make > profiles" to check > > Thanks > -Sundar > > On Friday 10 May 2013 04:09 PM, Alan Bateman wrote: >> On 10/05/2013 11:23, A. Sundararajan wrote: >>> com/sun/script/util is generic utility package for script engine >>> implementations. Only com/sun/script/javascript package is being >>> removed. Since we include javax/script for profile 3, should we also >>> include com/sun/script/util ? >> Is com.sun.script.util meant to be a supported/documented API? Do you >> know if anything outside of the JDK is using it? Is Nashorn using it? >> The only usage I see is in com.sun.script.javascript so this is why I >> assumed that com.sun.script.** would go away. >> >> As you know, we moved javax.script to compact1. It doesn't require >> com.sun.script.util of course but if this is used by 3rd party >> scripting engines then it may have to be added to compact1 builds to >> get them working. >> >>> >>> On refs.allowed, I'll remove it. How should I check this? >> "make profiles" on Linux should be fine. As part of the profiles >> build it will run a dependency analyzer that checks for references to >> types that do not exist (this is catch configuration issues). >> >> -Alan > From Alan.Bateman at oracle.com Mon May 13 12:26:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 13:26:05 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <5190D920.7090902@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> <5190D920.7090902@oracle.com> Message-ID: <5190DBDD.2080602@oracle.com> On 13/05/2013 13:14, A. Sundararajan wrote: > Incorporated changes as suggested. Uploaded webrev for historical > purpose: > > http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ > > PS. I am going ahead with push.. > Thanks for fixing up refs.allowed, that one looks fine okay. Did you decide to keep com.sun.script.util? Just wondering because it appears that only com.sun.script.javascript is being removed. If the util API is going away then I assume that make/com/sun/script/Makefile should be removed (although we don't really care about the old build anymore). On the other, if the util API is staying then we need to figure out which profile is should go in. If nothing is using it then I assume it should be listed in FULL_JRE_RTJAR_INCLUDE_PACKAGES. -Alan From andrew_nuss at yahoo.com Mon May 13 13:38:37 2013 From: andrew_nuss at yahoo.com (Andy Nuss) Date: Mon, 13 May 2013 06:38:37 -0700 (PDT) Subject: how to install and build In-Reply-To: <518CF37E.1050504@oracle.com> References: <1368187096.36725.YahooMailNeo@web141101.mail.bf1.yahoo.com> <518CF37E.1050504@oracle.com> Message-ID: <1368452317.18000.YahooMailNeo@web141102.mail.bf1.yahoo.com> I set up the openjdk7 mercurial project and did "make all". Now, I want to edit the appropriate Object.java file that make is using and issue "make". Is this possible? ________________________________ From: Weijun Wang To: Andy Nuss Cc: "build-dev at openjdk.java.net" Sent: Friday, May 10, 2013 6:17 AM Subject: Re: how to install and build Hi Andy If you only want to make small changes to .java files, just download the source code for those files, compile them with ? ? javac -d /tmp Those.java and call ? ? java -Xbootclasspath/p:/tmp YourApp to try out. If you don't like the -X option, you can call "jar uvf" to update the class files inside rt.jar with your newly built ones. -Max On 5/10/13 7:58 PM, Andy Nuss wrote: > Hi, > > I want to install jdk 7 project for linux 64, and make a simple change to Object.java and test it.? What do I do? > > Andy > From chris.hegarty at oracle.com Mon May 13 13:53:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 14:53:36 +0100 Subject: Disable overrides during jdk build Message-ID: <5190F060.8090604@oracle.com> Please hold your fire! This is not a suggestion to about general handling of warnings during the build, just a specific gripe I have when trying to find genuine build failures among the noise. Would there be any objection to adding '-overrides' to the jdk build? This lint warning was added after the new build was introduced. I suspect it would have been suppressed originally if it was supported at the time. diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk --- a/makefiles/Setup.gmk +++ b/makefiles/Setup.gmk @@ -23,7 +23,7 @@ # questions. # -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. -Chris. P.S. how to handle warnings generally will have to be addressed at some point, but I am not making any proposal at this time. From staffan.larsen at oracle.com Mon May 13 09:42:45 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 May 2013 11:42:45 +0200 Subject: MacOS build tool selections for JDK8 In-Reply-To: <518D71D1.3080706@oracle.com> References: <518D71D1.3080706@oracle.com> Message-ID: <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> One reason to use gcc instead of clang would be to have one less difference between platforms. It's always annoying when different compilers have a different set of warnings (even if the warnings are correct and useful) and you try to get something to compile on all platforms. I don't know if there is any performance difference between the two - either in compile time or runtime performance of the generated code. /Staffan On 11 maj 2013, at 00:16, Tim Bell wrote: > All- > > The question of what toolchain to use on MacOS when building JDK8 is in play. > > This is important because the decisions we make in the next few weeks will be in place for the lifetime of JDK8, including all future JDK8 update releases. > > I have a few different pieces of feedback at this point, and (due to my own ignorance of the developer environment choices on MacOS), I'd like to throw the discussion out to a larger audience of MacOS developers. > > 1) Use gcc as the build does today. > > 2) Use Clang. > > 3) Support both (since they should both compile the same source) but identify Clang as the official tool. > > 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) > > > As part of the build-infrastructure team, my #1 concern is getting solid, repeatable builds from the toolchain, every time, that that's what I mean by 'official'. > > If developers feel adventurous and want to run out ahead using bleeding edge tools, good for them - have fun. > > What we would like to define here is a solid baseline of what we use to run the official from-scratch JDK8 builds. That said, I'd like to nail down the tools used, and the specific version of the tools. > > Thanks in advance for any feedback. > > Tim Bell > Java Platform Group Infrastructure > From maurizio.cimadamore at oracle.com Mon May 13 14:24:35 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 May 2013 15:24:35 +0100 Subject: Disable overrides during jdk build In-Reply-To: <5190F060.8090604@oracle.com> References: <5190F060.8090604@oracle.com> Message-ID: <5190F7A3.9060201@oracle.com> I think it makes sense, esp. if the messages appear to be redundant. The compiler logic is very strict and there are cases where it comes down to guessing user intent and compilers are notoriously bad at doing that. In the long term, I'd like to see @SuppressWarnings("overrides") applied in those cases where the impl knows what it's doing. Maurizio On 13/05/13 14:53, Chris Hegarty wrote: > Please hold your fire! This is not a suggestion to about general > handling of warnings during the build, just a specific gripe I have > when trying to find genuine build failures among the noise. > > Would there be any objection to adding '-overrides' to the jdk build? > > This lint warning was added after the new build was introduced. I > suspect it would have been suppressed originally if it was supported > at the time. > > diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk > --- a/makefiles/Setup.gmk > +++ b/makefiles/Setup.gmk > @@ -23,7 +23,7 @@ > # questions. > # > > -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides > > > # The generate old bytecode javac setup uses the new compiler to > compile for the > # boot jdk to generate tools that need to be run with the boot jdk. > > -Chris. > > P.S. how to handle warnings generally will have to be addressed at > some point, but I am not making any proposal at this time. From chris.hegarty at oracle.com Mon May 13 14:41:10 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 15:41:10 +0100 Subject: Disable overrides during jdk build In-Reply-To: <5190F7A3.9060201@oracle.com> References: <5190F060.8090604@oracle.com> <5190F7A3.9060201@oracle.com> Message-ID: <5190FB86.3050402@oracle.com> On 13/05/2013 15:24, Maurizio Cimadamore wrote: > I think it makes sense, esp. if the messages appear to be redundant. The > compiler logic is very strict and there are cases where it comes down to > guessing user intent and compilers are notoriously bad at doing that. In > the long term, I'd like to see @SuppressWarnings("overrides") applied in > those cases where the impl knows what it's doing. Agreed. Tackling warnings, on a per area basis, is something that we need to spend more time on. I have not taken a look at the reason for the specific overrides warnings. It is just that it appears the intent of the new build was to suppress as many warnings as necessary, to make the output reasonable. Since this warning was not in existence at the time, I could not be suppressed. @SuppressWarnings("overrides") can be added, where appropriate, during future warning cleanup events. -Chris. > > Maurizio > > On 13/05/13 14:53, Chris Hegarty wrote: >> Please hold your fire! This is not a suggestion to about general >> handling of warnings during the build, just a specific gripe I have >> when trying to find genuine build failures among the noise. >> >> Would there be any objection to adding '-overrides' to the jdk build? >> >> This lint warning was added after the new build was introduced. I >> suspect it would have been suppressed originally if it was supported >> at the time. >> >> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk >> --- a/makefiles/Setup.gmk >> +++ b/makefiles/Setup.gmk >> @@ -23,7 +23,7 @@ >> # questions. >> # >> >> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >> >> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides >> >> >> # The generate old bytecode javac setup uses the new compiler to >> compile for the >> # boot jdk to generate tools that need to be run with the boot jdk. >> >> -Chris. >> >> P.S. how to handle warnings generally will have to be addressed at >> some point, but I am not making any proposal at this time. > From Alan.Bateman at oracle.com Mon May 13 15:08:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 16:08:05 +0100 Subject: Disable overrides during jdk build In-Reply-To: <5190F060.8090604@oracle.com> References: <5190F060.8090604@oracle.com> Message-ID: <519101D5.9070806@oracle.com> No objection although it feels like we are going backwards rather than forwards. I submitted a few bugs on this topic recently as it seems to me that there aren't too many override warnings to kill off. Daniel Fuchs has a patch out for review today that fixes these warnings in the jaxp repository. The overrides warnings were also fixed in the jaxws repository as part of the bulk update a few weeks ago. That leaves 12 for the corba repository and about 29 in the jdk repository (29 on Linux at least, it varies by platform). I completely agree with you that the noise is high. On several occasions I've had to edit the build log to find the errors when they get lots in the warnings. I just wonder whether we should just fix what seems like a small number of warnings. -Alan On 13/05/2013 14:53, Chris Hegarty wrote: > Please hold your fire! This is not a suggestion to about general > handling of warnings during the build, just a specific gripe I have > when trying to find genuine build failures among the noise. > > Would there be any objection to adding '-overrides' to the jdk build? > > This lint warning was added after the new build was introduced. I > suspect it would have been suppressed originally if it was supported > at the time. > > diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk > --- a/makefiles/Setup.gmk > +++ b/makefiles/Setup.gmk > @@ -23,7 +23,7 @@ > # questions. > # > > -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides > > > # The generate old bytecode javac setup uses the new compiler to > compile for the > # boot jdk to generate tools that need to be run with the boot jdk. > > -Chris. > > P.S. how to handle warnings generally will have to be addressed at > some point, but I am not making any proposal at this time. From chris.hegarty at oracle.com Mon May 13 15:36:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 May 2013 16:36:56 +0100 Subject: Disable overrides during jdk build In-Reply-To: <519101D5.9070806@oracle.com> References: <5190F060.8090604@oracle.com> <519101D5.9070806@oracle.com> Message-ID: <51910898.2090205@oracle.com> I have no objection to someone fixing these warnings. They are across a number of different areas, and could take an amount of time to resolve. If we are to have a concerted effort, I'm not sure that I would start with these warnings. I too feel the pain, and it does appear that we are moving backwards on this problem, I just don't see that this is the right place to start. I'm just after a slightly easier life here, but I understand that this is a hot topic ;-) -Chris. On 13/05/2013 16:08, Alan Bateman wrote: > > No objection although it feels like we are going backwards rather than > forwards. > > I submitted a few bugs on this topic recently as it seems to me that > there aren't too many override warnings to kill off. Daniel Fuchs has a > patch out for review today that fixes these warnings in the jaxp > repository. The overrides warnings were also fixed in the jaxws > repository as part of the bulk update a few weeks ago. That leaves 12 > for the corba repository and about 29 in the jdk repository (29 on Linux > at least, it varies by platform). > > I completely agree with you that the noise is high. On several occasions > I've had to edit the build log to find the errors when they get lots in > the warnings. I just wonder whether we should just fix what seems like a > small number of warnings. > > -Alan > > > On 13/05/2013 14:53, Chris Hegarty wrote: >> Please hold your fire! This is not a suggestion to about general >> handling of warnings during the build, just a specific gripe I have >> when trying to find genuine build failures among the noise. >> >> Would there be any objection to adding '-overrides' to the jdk build? >> >> This lint warning was added after the new build was introduced. I >> suspect it would have been suppressed originally if it was supported >> at the time. >> >> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk >> --- a/makefiles/Setup.gmk >> +++ b/makefiles/Setup.gmk >> @@ -23,7 +23,7 @@ >> # questions. >> # >> >> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >> >> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides >> >> >> # The generate old bytecode javac setup uses the new compiler to >> compile for the >> # boot jdk to generate tools that need to be run with the boot jdk. >> >> -Chris. >> >> P.S. how to handle warnings generally will have to be addressed at >> some point, but I am not making any proposal at this time. > From sundararajan.athijegannathan at oracle.com Mon May 13 15:40:24 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 May 2013 21:10:24 +0530 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <5190DBDD.2080602@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> <5190D920.7090902@oracle.com> <5190DBDD.2080602@oracle.com> Message-ID: <51910968.9090706@oracle.com> I agree that it is better to remove com.sun.script.util package as well. It is not used elsewhere and was never declared as supported API. I've removed the same and re-generated webrev. http://cr.openjdk.java.net/~sundar/8012975/webrev.03/ I ran NEWBUILD=false as well as NEWBUILD=true to make sure build finishes fine. Please review. Thanks -Sundar On Monday 13 May 2013 05:56 PM, Alan Bateman wrote: > On 13/05/2013 13:14, A. Sundararajan wrote: >> Incorporated changes as suggested. Uploaded webrev for historical >> purpose: >> >> http://cr.openjdk.java.net/~sundar/8012975/webrev.02/ >> >> PS. I am going ahead with push.. >> > Thanks for fixing up refs.allowed, that one looks fine okay. > > Did you decide to keep com.sun.script.util? Just wondering because it > appears that only com.sun.script.javascript is being removed. If the > util API is going away then I assume that make/com/sun/script/Makefile > should be removed (although we don't really care about the old build > anymore). On the other, if the util API is staying then we need to > figure out which profile is should go in. If nothing is using it then > I assume it should be listed in FULL_JRE_RTJAR_INCLUDE_PACKAGES. > > -Alan From david.dehaven at oracle.com Mon May 13 15:59:57 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 13 May 2013 08:59:57 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> Message-ID: <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> Clang emulates gcc (even so far as identifying itself as GCC for source level compatibility), they use the same command line arguments. Internally, clang has a somewhat better optimizer than gcc and feedback to the developer (warnings, error, etc..) is generally more useful than gcc. They both feed llvm so the backend is the same in either case. Apple seems to have a bigger investment in pushing clang forward than gcc, which generally means it has more of a future (there's never a guarantee though). I've been developing Mac OS X software since before the release of 10.0 and quite frankly the underlying tools haven't changed *that* much, the notable exception being when they dropped jam as the project tool. Windows has undergone far greater changes in that same time period.. If it were my choice, Mac OS X 10.8 would be the base OS with Xcode 4.6.1 (current) with clang as the officially supported compiler and with an option to use gcc. I don't see why that would't last at least the public lifecycle of JDK8. What I would be more concerned with is the apparent drift from what we know as Mac OS X towards something more iOS-like, that could mean libraries and frameworks we depend on no longer being available, but at that point it wouldn't be the same OS and we'd have to re-evaluate anyways. Sort of like what's happening with Windows 8 right now. -DrD- > One reason to use gcc instead of clang would be to have one less difference between platforms. It's always annoying when different compilers have a different set of warnings (even if the warnings are correct and useful) and you try to get something to compile on all platforms. > > I don't know if there is any performance difference between the two - either in compile time or runtime performance of the generated code. > > /Staffan > > On 11 maj 2013, at 00:16, Tim Bell wrote: > >> All- >> >> The question of what toolchain to use on MacOS when building JDK8 is in play. >> >> This is important because the decisions we make in the next few weeks will be in place for the lifetime of JDK8, including all future JDK8 update releases. >> >> I have a few different pieces of feedback at this point, and (due to my own ignorance of the developer environment choices on MacOS), I'd like to throw the discussion out to a larger audience of MacOS developers. >> >> 1) Use gcc as the build does today. >> >> 2) Use Clang. >> >> 3) Support both (since they should both compile the same source) but identify Clang as the official tool. >> >> 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) >> >> >> As part of the build-infrastructure team, my #1 concern is getting solid, repeatable builds from the toolchain, every time, that that's what I mean by 'official'. >> >> If developers feel adventurous and want to run out ahead using bleeding edge tools, good for them - have fun. >> >> What we would like to define here is a solid baseline of what we use to run the official from-scratch JDK8 builds. That said, I'd like to nail down the tools used, and the specific version of the tools. >> >> Thanks in advance for any feedback. >> >> Tim Bell >> Java Platform Group Infrastructure >> > From Alan.Bateman at oracle.com Mon May 13 16:44:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 May 2013 17:44:17 +0100 Subject: Please review changes for JDK-8012975: Remove rhino from jdk8 In-Reply-To: <51910968.9090706@oracle.com> References: <51829725.9090406@oracle.com> <5182CB62.30307@oracle.com> <518357F7.80203@oracle.com> <51835D96.3060209@oracle.com> <518382B1.6040501@oracle.com> <518CBD2D.4000301@oracle.com> <518CBED1.8010609@oracle.com> <518CCAA5.3060205@oracle.com> <518CCE48.3090309@oracle.com> <518CEC65.7050006@oracle.com> <5190D920.7090902@oracle.com> <5190DBDD.2080602@oracle.com> <51910968.9090706@oracle.com> Message-ID: <51911861.6010504@oracle.com> On 13/05/2013 16:40, A. Sundararajan wrote: > I agree that it is better to remove com.sun.script.util package as > well. It is not used elsewhere and was never declared as supported > API. I've removed the same and re-generated webrev. > > http://cr.openjdk.java.net/~sundar/8012975/webrev.03/ > > I ran NEWBUILD=false as well as NEWBUILD=true to make sure build > finishes fine. > > Please review. Looks good to me. -Alan From mike.duigou at oracle.com Mon May 13 18:07:02 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 13 May 2013 11:07:02 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <518D71D1.3080706@oracle.com> References: <518D71D1.3080706@oracle.com> Message-ID: On May 10 2013, at 15:16 , Tim Bell wrote: > All- > > The question of what toolchain to use on MacOS when building JDK8 is in play. > > This is important because the decisions we make in the next few weeks will be in place for the lifetime of JDK8, including all future JDK8 update releases. > > I have a few different pieces of feedback at this point, and (due to my own ignorance of the developer environment choices on MacOS), I'd like to throw the discussion out to a larger audience of MacOS developers. > > 1) Use gcc as the build does today. Does this mean the gcc+clang provided by XCode or some random port of GCC (fink/macports)? I would be concerned with using "cygwin quality" (if that doesn't make you cringe you haven't been using cygwin long enough) GCC port rather than the Apple port. > 2) Use Clang. Is there any way to get clang for MacOS other than via XCode? Like using macports or fink GCC port I would be concerned about quality, stability and updates. > 3) Support both (since they should both compile the same source) but identify Clang as the official tool. We're currently using the gcc front end. I think it would take signifiant work to switch to the clang front end. > 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) This seems to be the only supported option. For Java 8 we have a mandate to support 10.7 which the current XCode tools allow us to do. I assume that the requirement to support 10.7 will remain through all of Java 8's support lifetime. It's unclear when XCode will stop supporting 10.7 though it would seem that when/if that happens we will be stuck with the last-supporting-10.7 version. > As part of the build-infrastructure team, my #1 concern is getting solid, repeatable builds from the toolchain, every time, that that's what I mean by 'official'. > > If developers feel adventurous and want to run out ahead using bleeding edge tools, good for them - have fun. > > What we would like to define here is a solid baseline of what we use to run the official from-scratch JDK8 builds. That said, I'd like to nail down the tools used, and the specific version of the tools. > > Thanks in advance for any feedback. > > Tim Bell > Java Platform Group Infrastructure > From joe.darcy at oracle.com Mon May 13 19:02:59 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 May 2013 12:02:59 -0700 Subject: Disable overrides during jdk build In-Reply-To: <51910898.2090205@oracle.com> References: <5190F060.8090604@oracle.com> <519101D5.9070806@oracle.com> <51910898.2090205@oracle.com> Message-ID: <519138E3.40002@oracle.com> Failure to have proper equals / hashCode behaviors can create hard to discover bugs if such objects are ever put in collections. By default, I would categorize these as real problems to be fixed and for a @SuppressWarning annotation to be wrong approach to resolve the warning. Since its initial implementation, the javac warning generation has been tuned to be smarter; it only reports a problem if hashCode isn't overridden anywhere in the superclass chain. (It is often possible to have more sharing among hashCode implementation than among equals implementations.) Regards, -Joe On 5/13/2013 8:36 AM, Chris Hegarty wrote: > I have no objection to someone fixing these warnings. They are across > a number of different areas, and could take an amount of time to resolve. > > If we are to have a concerted effort, I'm not sure that I would start > with these warnings. I too feel the pain, and it does appear that we > are moving backwards on this problem, I just don't see that this is > the right place to start. > > I'm just after a slightly easier life here, but I understand that this > is a hot topic ;-) > > -Chris. > > On 13/05/2013 16:08, Alan Bateman wrote: >> >> No objection although it feels like we are going backwards rather than >> forwards. >> >> I submitted a few bugs on this topic recently as it seems to me that >> there aren't too many override warnings to kill off. Daniel Fuchs has a >> patch out for review today that fixes these warnings in the jaxp >> repository. The overrides warnings were also fixed in the jaxws >> repository as part of the bulk update a few weeks ago. That leaves 12 >> for the corba repository and about 29 in the jdk repository (29 on Linux >> at least, it varies by platform). >> >> I completely agree with you that the noise is high. On several occasions >> I've had to edit the build log to find the errors when they get lots in >> the warnings. I just wonder whether we should just fix what seems like a >> small number of warnings. >> >> -Alan >> >> >> On 13/05/2013 14:53, Chris Hegarty wrote: >>> Please hold your fire! This is not a suggestion to about general >>> handling of warnings during the build, just a specific gripe I have >>> when trying to find genuine build failures among the noise. >>> >>> Would there be any objection to adding '-overrides' to the jdk build? >>> >>> This lint warning was added after the new build was introduced. I >>> suspect it would have been suppressed originally if it was supported >>> at the time. >>> >>> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk >>> --- a/makefiles/Setup.gmk >>> +++ b/makefiles/Setup.gmk >>> @@ -23,7 +23,7 @@ >>> # questions. >>> # >>> >>> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >>> >>> >>> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides >>> >>> >>> >>> # The generate old bytecode javac setup uses the new compiler to >>> compile for the >>> # boot jdk to generate tools that need to be run with the boot jdk. >>> >>> -Chris. >>> >>> P.S. how to handle warnings generally will have to be addressed at >>> some point, but I am not making any proposal at this time. >> From david.dehaven at oracle.com Mon May 13 20:21:49 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 13 May 2013 13:21:49 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: References: <518D71D1.3080706@oracle.com> Message-ID: >> 1) Use gcc as the build does today. > > Does this mean the gcc+clang provided by XCode or some random port of GCC (fink/macports)? I would be concerned with using "cygwin quality" (if that doesn't make you cringe you haven't been using cygwin long enough) GCC port rather than the Apple port. GCC as provided by Apple in Xcode. >> 2) Use Clang. > > Is there any way to get clang for MacOS other than via XCode? Like using macports or fink GCC port I would be concerned about quality, stability and updates. Not with any assurance of quality. I would not condone the use of any tools outside of what Apple delivers, just as you don't condone the use of Cygwin tools on Windows :) As was said before, if someone wants to use a different compiler they're free to, but they're entirely on their own. >> 3) Support both (since they should both compile the same source) but identify Clang as the official tool. > > We're currently using the gcc front end. I think it would take signifiant work to switch to the clang front end. In my experience it takes no work at all... > 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) > > This seems to be the only supported option. For Java 8 we have a mandate to support 10.7 which the current XCode tools allow us to do. I assume that the requirement to support 10.7 will remain through all of Java 8's support lifetime. It's unclear when XCode will stop supporting 10.7 though it would seem that when/if that happens we will be stuck with the last-supporting-10.7 version. The way Apple has developed their Mac OS X SDK, they never stop "supporting" a specific version of an OS. You can still build code that will run on 10.4 and later even with the 10.8 SDK (if targeting Intel), so ensuring our code will continue to work on 10.7 should not be a huge concern. That's what the -mmacosx-version-min argument is for. -DrD- From david.katleman at oracle.com Mon May 13 22:01:55 2013 From: david.katleman at oracle.com (David Katleman) Date: Mon, 13 May 2013 15:01:55 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: References: <518D71D1.3080706@oracle.com> Message-ID: <519162D3.5040008@oracle.com> On 5/13/2013 1:21 PM, David DeHaven wrote: >>> 3) Support both (since they should both compile the same source) but identify Clang as the official tool. >> We're currently using the gcc front end. I think it would take signifiant work to switch to the clang front end. > In my experience it takes no work at all... Anyone attempted to build/test hotspot using clang rather than gcc? >> 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) >> >> This seems to be the only supported option. For Java 8 we have a mandate to support 10.7 which the current XCode tools allow us to do. I assume that the requirement to support 10.7 will remain through all of Java 8's support lifetime. It's unclear when XCode will stop supporting 10.7 though it would seem that when/if that happens we will be stuck with the last-supporting-10.7 version. > The way Apple has developed their Mac OS X SDK, they never stop "supporting" a specific version of an OS. You can still build code that will run on 10.4 and later even with the 10.8 SDK (if targeting Intel), so ensuring our code will continue to work on 10.7 should not be a huge concern. That's what the -mmacosx-version-min argument is for. Does this imply the underlying version of macosx doesn't matter, as long as you're using Xcode 4.6.1 (or what ever we have standardized upon for JDK8) with -mmacosx-version-min=10.7? That would solve our new machines always having the latest macosx issue, that is as long as our instance of Xcode is supported. (the iOS-ifying of macosx) Thanks Dave From david.holmes at oracle.com Tue May 14 00:19:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2013 10:19:25 +1000 Subject: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it Message-ID: <5191830D.2070808@oracle.com> Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. webrev: http://cr.openjdk.java.net/~dholmes/8014460/webrev/ Pushing to hotspot-emb. Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM builds Thanks, David From tim.bell at oracle.com Tue May 14 00:35:01 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 13 May 2013 17:35:01 -0700 Subject: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it In-Reply-To: <5191830D.2070808@oracle.com> References: <5191830D.2070808@oracle.com> Message-ID: <519186B5.9030907@oracle.com> Hi David: > Trivial fix for the open arm.make files - we should only update the > LIBS variable when EXT_LIBS_PATH is defined. > > webrev: > > http://cr.openjdk.java.net/~dholmes/8014460/webrev/ > > Pushing to hotspot-emb. > > Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM build Looks good from the build side. Tim From jonathan.gibbons at oracle.com Tue May 14 01:23:21 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 May 2013 18:23:21 -0700 Subject: RFR: 8014461 genstubs creates default native methods Message-ID: <51919209.1010600@oracle.com> genstubs is a utility used to help javac through the bootstrap process. It needs to be updated to strip the default modifier and method body from default methods in interfaces. I'm not sure if this should be a build-dev review or a compiler-dev review. -- Jon From jonathan.gibbons at oracle.com Tue May 14 01:26:35 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 May 2013 18:26:35 -0700 Subject: RFR: 8014461 genstubs creates default native methods In-Reply-To: <51919209.1010600@oracle.com> References: <51919209.1010600@oracle.com> Message-ID: <519192CB.6090203@oracle.com> On 05/13/2013 06:23 PM, Jonathan Gibbons wrote: > genstubs is a utility used to help javac through the bootstrap > process. It needs to be updated to strip the default modifier and > method body from default methods in interfaces. > > I'm not sure if this should be a build-dev review or a compiler-dev > review. > > -- Jon Oops, I guess this would help: http://cr.openjdk.java.net/~jjg/8014461 From gary.collins at oracle.com Tue May 14 02:11:35 2013 From: gary.collins at oracle.com (Gary Collins) Date: Mon, 13 May 2013 19:11:35 -0700 Subject: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it In-Reply-To: <519186B5.9030907@oracle.com> References: <5191830D.2070808@oracle.com> <519186B5.9030907@oracle.com> Message-ID: <7DF42398-240C-428E-A9A9-37D172FBFF3F@oracle.com> Looks good.. Don't think I count though Gary Sent from my iPad On May 13, 2013, at 5:35 PM, Tim Bell wrote: > Hi David: > >> Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. >> >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8014460/webrev/ >> >> Pushing to hotspot-emb. >> >> Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM build > > Looks good from the build side. > > Tim > From staffan.larsen at oracle.com Tue May 14 05:14:55 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 May 2013 07:14:55 +0200 Subject: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it In-Reply-To: <5191830D.2070808@oracle.com> References: <5191830D.2070808@oracle.com> Message-ID: <614E759C-F961-429B-9404-BF3BD1185BF1@oracle.com> Looks good. /Staffan On 14 maj 2013, at 02:19, David Holmes wrote: > Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. > > webrev: > > http://cr.openjdk.java.net/~dholmes/8014460/webrev/ > > Pushing to hotspot-emb. > > Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM builds > > Thanks, > David From david.holmes at oracle.com Tue May 14 05:25:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2013 15:25:28 +1000 Subject: XS RFR: 8014460 Need to check for non-empty EXT_LIBS_PATH before using it In-Reply-To: <614E759C-F961-429B-9404-BF3BD1185BF1@oracle.com> References: <5191830D.2070808@oracle.com> <614E759C-F961-429B-9404-BF3BD1185BF1@oracle.com> Message-ID: <5191CAC8.2020406@oracle.com> Thanks Staffan, and Gary and Tim. Unfortunately I still need a hsx Reviewer - thanks. David On 14/05/2013 3:14 PM, Staffan Larsen wrote: > Looks good. > > /Staffan > > On 14 maj 2013, at 02:19, David Holmes wrote: > >> Trivial fix for the open arm.make files - we should only update the LIBS variable when EXT_LIBS_PATH is defined. >> >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/8014460/webrev/ >> >> Pushing to hotspot-emb. >> >> Testing: local builds with/without EXT_LIBS_PATH set; jprt ARM builds >> >> Thanks, >> David > From chris.hegarty at oracle.com Tue May 14 11:35:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 May 2013 12:35:00 +0100 Subject: Disable overrides during jdk build In-Reply-To: <519138E3.40002@oracle.com> References: <5190F060.8090604@oracle.com> <519101D5.9070806@oracle.com> <51910898.2090205@oracle.com> <519138E3.40002@oracle.com> Message-ID: <51922164.6020405@oracle.com> Thanks Joe, The consensus seems to be to keep these warnings, and have them fixed at some point in the relatively near future. I'm ok with that, I've disable them locally for now, when trying to fix real failures, and see if I can address some of them over the next few weeks. -Chris. On 05/13/2013 08:02 PM, Joe Darcy wrote: > Failure to have proper equals / hashCode behaviors can create hard to > discover bugs if such objects are ever put in collections. > > By default, I would categorize these as real problems to be fixed and > for a @SuppressWarning annotation to be wrong approach to resolve the > warning. > > Since its initial implementation, the javac warning generation has been > tuned to be smarter; it only reports a problem if hashCode isn't > overridden anywhere in the superclass chain. (It is often possible to > have more sharing among hashCode implementation than among equals > implementations.) > > Regards, > > -Joe > > On 5/13/2013 8:36 AM, Chris Hegarty wrote: >> I have no objection to someone fixing these warnings. They are across >> a number of different areas, and could take an amount of time to resolve. >> >> If we are to have a concerted effort, I'm not sure that I would start >> with these warnings. I too feel the pain, and it does appear that we >> are moving backwards on this problem, I just don't see that this is >> the right place to start. >> >> I'm just after a slightly easier life here, but I understand that this >> is a hot topic ;-) >> >> -Chris. >> >> On 13/05/2013 16:08, Alan Bateman wrote: >>> >>> No objection although it feels like we are going backwards rather than >>> forwards. >>> >>> I submitted a few bugs on this topic recently as it seems to me that >>> there aren't too many override warnings to kill off. Daniel Fuchs has a >>> patch out for review today that fixes these warnings in the jaxp >>> repository. The overrides warnings were also fixed in the jaxws >>> repository as part of the bulk update a few weeks ago. That leaves 12 >>> for the corba repository and about 29 in the jdk repository (29 on Linux >>> at least, it varies by platform). >>> >>> I completely agree with you that the noise is high. On several occasions >>> I've had to edit the build log to find the errors when they get lots in >>> the warnings. I just wonder whether we should just fix what seems like a >>> small number of warnings. >>> >>> -Alan >>> >>> >>> On 13/05/2013 14:53, Chris Hegarty wrote: >>>> Please hold your fire! This is not a suggestion to about general >>>> handling of warnings during the build, just a specific gripe I have >>>> when trying to find genuine build failures among the noise. >>>> >>>> Would there be any objection to adding '-overrides' to the jdk build? >>>> >>>> This lint warning was added after the new build was introduced. I >>>> suspect it would have been suppressed originally if it was supported >>>> at the time. >>>> >>>> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk >>>> --- a/makefiles/Setup.gmk >>>> +++ b/makefiles/Setup.gmk >>>> @@ -23,7 +23,7 @@ >>>> # questions. >>>> # >>>> >>>> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >>>> >>>> >>>> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides >>>> >>>> >>>> >>>> # The generate old bytecode javac setup uses the new compiler to >>>> compile for the >>>> # boot jdk to generate tools that need to be run with the boot jdk. >>>> >>>> -Chris. >>>> >>>> P.S. how to handle warnings generally will have to be addressed at >>>> some point, but I am not making any proposal at this time. >>> > From Sergey.Bylokhov at oracle.com Tue May 14 11:48:46 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 May 2013 15:48:46 +0400 Subject: MacOS build tool selections for JDK8 In-Reply-To: <519162D3.5040008@oracle.com> References: <518D71D1.3080706@oracle.com> <519162D3.5040008@oracle.com> Message-ID: <5192249E.1030709@oracle.com> On 14.05.2013 2:01, David Katleman wrote: > Does this imply the underlying version of macosx doesn't matter, as > long as you're using Xcode 4.6.1 (or what ever we have standardized > upon for JDK8) with -mmacosx-version-min=10.7? > > That would solve our new machines always having the latest macosx > issue, that is as long as our instance of Xcode is supported. But what about the jdk 7? At least for now, if I build it in macosx 10.8, it does not work om macosx 10.7.(old build system) > Thanks > Dave -- Best regards, Sergey. From Alan.Bateman at oracle.com Tue May 14 12:16:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 13:16:30 +0100 Subject: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Message-ID: <51922B1E.9080906@oracle.com> The bootcycle-images target is currently broken in jdk8/tl. Jon has taken 8014461 to fix genstubs but once you get past that then the CLDRConverter fails parsing LDML due to DTD references that aren't allowed by the default policy in jdk8 (since the update to JAXP 1.5). This policy is due to be re-visited later in jdk8 and I expect it will need to allow at least access to the DTDs on the file system. For now, and to get the boot cycle builds going again, I propose to update the CLDRConverter to set the accessExternalDTD property. Attached is the proposed patch. It uses a hard-coded string rather than XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely have an older version of JAXP where this constant isn't defined. Thanks, Alan. diff --git a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java @@ -34,6 +34,8 @@ import java.util.*; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; +import org.xml.sax.SAXNotRecognizedException; +import org.xml.sax.SAXNotSupportedException; /** @@ -234,6 +236,17 @@ } } + /** + * Configure the parser to allow access to DTDs on the file system. + */ + private static void enableFileAccess(SAXParser parser) throws SAXNotSupportedException { + try { + parser.setProperty("http://javax.xml.XMLConstants/property/accessExternalDTD", "file"); + } catch (SAXNotRecognizedException ignore) { + // property requires >= JAXP 1.5 + } + } + private static List readBundleList() throws Exception { ResourceBundle.Control defCon = ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT); List retList = new ArrayList<>(); @@ -279,6 +292,7 @@ SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setValidating(true); SAXParser parser = factory.newSAXParser(); + enableFileAccess(parser); LDMLParseHandler handler = new LDMLParseHandler(id); File file = new File(SOURCE_FILE_DIR + File.separator + id + ".xml"); if (!file.exists()) { @@ -314,6 +328,7 @@ SAXParserFactory factorySuppl = SAXParserFactory.newInstance(); factorySuppl.setValidating(true); SAXParser parserSuppl = factorySuppl.newSAXParser(); + enableFileAccess(parserSuppl); handlerSuppl = new SupplementDataParseHandler(); File fileSupply = new File(SPPL_SOURCE_FILE); parserSuppl.parse(fileSupply, handlerSuppl); @@ -322,6 +337,7 @@ SAXParserFactory numberingParser = SAXParserFactory.newInstance(); numberingParser.setValidating(true); SAXParser parserNumbering = numberingParser.newSAXParser(); + enableFileAccess(parserNumbering); handlerNumbering = new NumberingSystemsParseHandler(); File fileNumbering = new File(NUMBERING_SOURCE_FILE); parserNumbering.parse(fileNumbering, handlerNumbering); @@ -330,6 +346,7 @@ SAXParserFactory metazonesParser = SAXParserFactory.newInstance(); metazonesParser.setValidating(true); SAXParser parserMetaZones = metazonesParser.newSAXParser(); + enableFileAccess(parserMetaZones); handlerMetaZones = new MetaZonesParseHandler(); File fileMetaZones = new File(METAZONES_SOURCE_FILE); parserNumbering.parse(fileMetaZones, handlerMetaZones); From Lance.Andersen at oracle.com Tue May 14 12:27:05 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 14 May 2013 08:27:05 -0400 Subject: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 In-Reply-To: <51922B1E.9080906@oracle.com> References: <51922B1E.9080906@oracle.com> Message-ID: <1DD757D6-CB7C-4B22-996E-B2F65FD4BAD0@oracle.com> +1 On May 14, 2013, at 8:16 AM, Alan Bateman wrote: > > The bootcycle-images target is currently broken in jdk8/tl. > > Jon has taken 8014461 to fix genstubs but once you get past that then the CLDRConverter fails parsing LDML due to DTD references that aren't allowed by the default policy in jdk8 (since the update to JAXP 1.5). This policy is due to be re-visited later in jdk8 and I expect it will need to allow at least access to the DTDs on the file system. For now, and to get the boot cycle builds going again, I propose to update the CLDRConverter to set the accessExternalDTD property. > > Attached is the proposed patch. It uses a hard-coded string rather than XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely have an older version of JAXP where this constant isn't defined. > > Thanks, > Alan. > > > > diff --git a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > @@ -34,6 +34,8 @@ > import java.util.*; > import javax.xml.parsers.SAXParser; > import javax.xml.parsers.SAXParserFactory; > +import org.xml.sax.SAXNotRecognizedException; > +import org.xml.sax.SAXNotSupportedException; > > > /** > @@ -234,6 +236,17 @@ > } > } > > + /** > + * Configure the parser to allow access to DTDs on the file system. > + */ > + private static void enableFileAccess(SAXParser parser) throws SAXNotSupportedException { > + try { > + parser.setProperty("http://javax.xml.XMLConstants/property/accessExternalDTD", "file"); > + } catch (SAXNotRecognizedException ignore) { > + // property requires >= JAXP 1.5 > + } > + } > + > private static List readBundleList() throws Exception { > ResourceBundle.Control defCon = ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT); > List retList = new ArrayList<>(); > @@ -279,6 +292,7 @@ > SAXParserFactory factory = SAXParserFactory.newInstance(); > factory.setValidating(true); > SAXParser parser = factory.newSAXParser(); > + enableFileAccess(parser); > LDMLParseHandler handler = new LDMLParseHandler(id); > File file = new File(SOURCE_FILE_DIR + File.separator + id + ".xml"); > if (!file.exists()) { > @@ -314,6 +328,7 @@ > SAXParserFactory factorySuppl = SAXParserFactory.newInstance(); > factorySuppl.setValidating(true); > SAXParser parserSuppl = factorySuppl.newSAXParser(); > + enableFileAccess(parserSuppl); > handlerSuppl = new SupplementDataParseHandler(); > File fileSupply = new File(SPPL_SOURCE_FILE); > parserSuppl.parse(fileSupply, handlerSuppl); > @@ -322,6 +337,7 @@ > SAXParserFactory numberingParser = SAXParserFactory.newInstance(); > numberingParser.setValidating(true); > SAXParser parserNumbering = numberingParser.newSAXParser(); > + enableFileAccess(parserNumbering); > handlerNumbering = new NumberingSystemsParseHandler(); > File fileNumbering = new File(NUMBERING_SOURCE_FILE); > parserNumbering.parse(fileNumbering, handlerNumbering); > @@ -330,6 +346,7 @@ > SAXParserFactory metazonesParser = SAXParserFactory.newInstance(); > metazonesParser.setValidating(true); > SAXParser parserMetaZones = metazonesParser.newSAXParser(); > + enableFileAccess(parserMetaZones); > handlerMetaZones = new MetaZonesParseHandler(); > File fileMetaZones = new File(METAZONES_SOURCE_FILE); > parserNumbering.parse(fileMetaZones, handlerMetaZones); -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Tue May 14 14:28:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 15:28:36 +0100 Subject: Disable overrides during jdk build In-Reply-To: <51922164.6020405@oracle.com> References: <5190F060.8090604@oracle.com> <519101D5.9070806@oracle.com> <51910898.2090205@oracle.com> <519138E3.40002@oracle.com> <51922164.6020405@oracle.com> Message-ID: <51924A14.6040504@oracle.com> On 14/05/2013 12:35, Chris Hegarty wrote: > Thanks Joe, > > The consensus seems to be to keep these warnings, and have them fixed > at some point in the relatively near future. I'm ok with that, I've > disable them locally for now, when trying to fix real failures, and > see if I can address some of them over the next few weeks. > > -Chris. I think that would be best as the number of manageable. -Alan. From erik.joelsson at oracle.com Tue May 14 14:34:48 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 May 2013 16:34:48 +0200 Subject: RFR: 8014514: Fix jvm args for sjavac Message-ID: <51924B88.2080700@oracle.com> This patch tries to be smarter when figuring out optimal jvm args for sjavac, especially if the jvm used is 32bit. http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/ For this to work properly, two patches to the sjavac src langtools are also needed, but they will be handled in separate bugs and code reviews. /Erik From erik.joelsson at oracle.com Tue May 14 14:36:42 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 May 2013 16:36:42 +0200 Subject: 8014500: bootcycle-images fails after upgrade to JAXP 1.5 In-Reply-To: <51922B1E.9080906@oracle.com> References: <51922B1E.9080906@oracle.com> Message-ID: <51924BFA.3060800@oracle.com> Looks good from the build side. /Erik On 2013-05-14 14:16, Alan Bateman wrote: > > The bootcycle-images target is currently broken in jdk8/tl. > > Jon has taken 8014461 to fix genstubs but once you get past that then > the CLDRConverter fails parsing LDML due to DTD references that aren't > allowed by the default policy in jdk8 (since the update to JAXP 1.5). > This policy is due to be re-visited later in jdk8 and I expect it will > need to allow at least access to the DTDs on the file system. For now, > and to get the boot cycle builds going again, I propose to update the > CLDRConverter to set the accessExternalDTD property. > > Attached is the proposed patch. It uses a hard-coded string rather > than XMLConstants.ACCESS_EXTERNAL_DTD because the boot JDK will likely > have an older version of JAXP where this constant isn't defined. > > Thanks, > Alan. > > > > diff --git > a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > --- a/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > +++ b/make/tools/src/build/tools/cldrconverter/CLDRConverter.java > @@ -34,6 +34,8 @@ > import java.util.*; > import javax.xml.parsers.SAXParser; > import javax.xml.parsers.SAXParserFactory; > +import org.xml.sax.SAXNotRecognizedException; > +import org.xml.sax.SAXNotSupportedException; > > > /** > @@ -234,6 +236,17 @@ > } > } > > + /** > + * Configure the parser to allow access to DTDs on the file system. > + */ > + private static void enableFileAccess(SAXParser parser) throws > SAXNotSupportedException { > + try { > + > parser.setProperty("http://javax.xml.XMLConstants/property/accessExternalDTD", > "file"); > + } catch (SAXNotRecognizedException ignore) { > + // property requires >= JAXP 1.5 > + } > + } > + > private static List readBundleList() throws Exception { > ResourceBundle.Control defCon = > ResourceBundle.Control.getControl(ResourceBundle.Control.FORMAT_DEFAULT); > List retList = new ArrayList<>(); > @@ -279,6 +292,7 @@ > SAXParserFactory factory = SAXParserFactory.newInstance(); > factory.setValidating(true); > SAXParser parser = factory.newSAXParser(); > + enableFileAccess(parser); > LDMLParseHandler handler = new LDMLParseHandler(id); > File file = new File(SOURCE_FILE_DIR + File.separator + id + > ".xml"); > if (!file.exists()) { > @@ -314,6 +328,7 @@ > SAXParserFactory factorySuppl = SAXParserFactory.newInstance(); > factorySuppl.setValidating(true); > SAXParser parserSuppl = factorySuppl.newSAXParser(); > + enableFileAccess(parserSuppl); > handlerSuppl = new SupplementDataParseHandler(); > File fileSupply = new File(SPPL_SOURCE_FILE); > parserSuppl.parse(fileSupply, handlerSuppl); > @@ -322,6 +337,7 @@ > SAXParserFactory numberingParser = > SAXParserFactory.newInstance(); > numberingParser.setValidating(true); > SAXParser parserNumbering = numberingParser.newSAXParser(); > + enableFileAccess(parserNumbering); > handlerNumbering = new NumberingSystemsParseHandler(); > File fileNumbering = new File(NUMBERING_SOURCE_FILE); > parserNumbering.parse(fileNumbering, handlerNumbering); > @@ -330,6 +346,7 @@ > SAXParserFactory metazonesParser = > SAXParserFactory.newInstance(); > metazonesParser.setValidating(true); > SAXParser parserMetaZones = metazonesParser.newSAXParser(); > + enableFileAccess(parserMetaZones); > handlerMetaZones = new MetaZonesParseHandler(); > File fileMetaZones = new File(METAZONES_SOURCE_FILE); > parserNumbering.parse(fileMetaZones, handlerMetaZones); From tim.bell at oracle.com Tue May 14 15:11:01 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 14 May 2013 08:11:01 -0700 Subject: RFR: 8014514: Fix jvm args for sjavac In-Reply-To: <51924B88.2080700@oracle.com> References: <51924B88.2080700@oracle.com> Message-ID: <51925405.7020309@oracle.com> Erik: > This patch tries to be smarter when figuring out optimal jvm args for > sjavac, especially if the jvm used is 32bit. > > http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/ Looks good. Tim From Alan.Bateman at oracle.com Tue May 14 15:47:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2013 16:47:41 +0100 Subject: RFR: 8014461 genstubs creates default native methods In-Reply-To: <519192CB.6090203@oracle.com> References: <51919209.1010600@oracle.com> <519192CB.6090203@oracle.com> Message-ID: <51925C9D.7090205@oracle.com> On 14/05/2013 02:26, Jonathan Gibbons wrote: > On 05/13/2013 06:23 PM, Jonathan Gibbons wrote: >> genstubs is a utility used to help javac through the bootstrap >> process. It needs to be updated to strip the default modifier and >> method body from default methods in interfaces. >> >> I'm not sure if this should be a build-dev review or a compiler-dev >> review. >> >> -- Jon > > Oops, I guess this would help: > http://cr.openjdk.java.net/~jjg/8014461 This looks okay to me. -Alan. From david.dehaven at oracle.com Tue May 14 17:28:44 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 14 May 2013 10:28:44 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <5192249E.1030709@oracle.com> References: <518D71D1.3080706@oracle.com> <519162D3.5040008@oracle.com> <5192249E.1030709@oracle.com> Message-ID: <0D7820B0-19D2-42DC-B31A-62C2A896CEDA@oracle.com> >> Does this imply the underlying version of macosx doesn't matter, as long as you're using Xcode 4.6.1 (or what ever we have standardized upon for JDK8) with -mmacosx-version-min=10.7? >> >> That would solve our new machines always having the latest macosx issue, that is as long as our instance of Xcode is supported. > But what about the jdk 7? At least for now, if I build it in macosx 10.8, it does not work om macosx 10.7.(old build system) Try this: export MACOSX_DEPLOYMENT_TARGET=10.7 before running make, that's the same as providing -mmacosx-version-min=10.7 to gcc on the command line. The JDK7 build machines should continue using 10.7 unless OBS is modified to explicitly set that env variable. -DrD- From david.dehaven at oracle.com Tue May 14 17:40:02 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 14 May 2013 10:40:02 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <519162D3.5040008@oracle.com> References: <518D71D1.3080706@oracle.com> <519162D3.5040008@oracle.com> Message-ID: <3ECF97C9-B047-446C-9E1D-EF165CE4D039@oracle.com> >>>> 3) Support both (since they should both compile the same source) but identify Clang as the official tool. >>> We're currently using the gcc front end. I think it would take signifiant work to switch to the clang front end. >> In my experience it takes no work at all... > > Anyone attempted to build/test hotspot using clang rather than gcc? I've been curious of that myself. I've noticed some code is built using "cc" which is symlinked to clang in the current command line tools, so some stuff is already using clang (that might only be in JavaFX..). >>> 4) Use Xcode (er - wait - isn't Clang a part of Xcode? Please correct me if I am mistaken here....) >>> >>> This seems to be the only supported option. For Java 8 we have a mandate to support 10.7 which the current XCode tools allow us to do. I assume that the requirement to support 10.7 will remain through all of Java 8's support lifetime. It's unclear when XCode will stop supporting 10.7 though it would seem that when/if that happens we will be stuck with the last-supporting-10.7 version. >> The way Apple has developed their Mac OS X SDK, they never stop "supporting" a specific version of an OS. You can still build code that will run on 10.4 and later even with the 10.8 SDK (if targeting Intel), so ensuring our code will continue to work on 10.7 should not be a huge concern. That's what the -mmacosx-version-min argument is for. > > Does this imply the underlying version of macosx doesn't matter, as long as you're using Xcode 4.6.1 (or what ever we have standardized upon for JDK8) with -mmacosx-version-min=10.7? Underlying OS and the SDK used to build against, so long as they're at least the target OS version or later. IOW, you can build for 10.7 on 10.7 or later with the 10.7 SDK or later. Currently, we set both -mmacosx-version-min=10.7 and define MAC_OS_X_VERSION_MAX_ALLOWED as 1070, this prevents the use of any 10.8+ features while still allowing it to be built on any system or SDK >= 10.7. > That would solve our new machines always having the latest macosx issue, that is as long as our instance of Xcode is supported. (the iOS-ifying of macosx) Correct. We can cross the "next generation OSX" issue when we get there :) -DrD- From david.katleman at oracle.com Tue May 14 19:31:31 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:31:31 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b89 for changeset fe4150590ee5 Message-ID: <20130514193132.C401C48A85@hg.openjdk.java.net> Changeset: c8286839d0df Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/c8286839d0df Added tag jdk8-b89 for changeset fe4150590ee5 ! .hgtags From david.katleman at oracle.com Tue May 14 19:31:27 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:31:27 +0000 Subject: hg: jdk8/build: Added tag jdk8-b89 for changeset 892a0196d10c Message-ID: <20130514193128.1528448A84@hg.openjdk.java.net> Changeset: 69b773a221b9 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/69b773a221b9 Added tag jdk8-b89 for changeset 892a0196d10c ! .hgtags From david.katleman at oracle.com Tue May 14 19:32:15 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:32:15 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b89 for changeset 9c1fe0b419b4 Message-ID: <20130514193218.EEC3648A86@hg.openjdk.java.net> Changeset: 7d56b68a9672 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7d56b68a9672 Added tag jdk8-b89 for changeset 9c1fe0b419b4 ! .hgtags From david.katleman at oracle.com Tue May 14 19:33:55 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:33:55 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130514193429.ED38748A89@hg.openjdk.java.net> Changeset: b8e7d145abc2 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b8e7d145abc2 Added tag jdk8-b89 for changeset 845025546e35 ! .hgtags Changeset: c63eda8f6300 Author: katleman Date: 2013-05-14 12:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c63eda8f6300 Merge From david.katleman at oracle.com Tue May 14 19:33:39 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:33:39 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b89 for changeset 88838e08e4ef Message-ID: <20130514193343.A48C748A88@hg.openjdk.java.net> Changeset: 3e5b9ea5ac35 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/3e5b9ea5ac35 Added tag jdk8-b89 for changeset 88838e08e4ef ! .hgtags From david.katleman at oracle.com Tue May 14 19:33:29 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:33:29 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b89 for changeset 893d2ba8bbea Message-ID: <20130514193334.32E2148A87@hg.openjdk.java.net> Changeset: 668acc0e1034 Author: katleman Date: 2013-05-09 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/668acc0e1034 Added tag jdk8-b89 for changeset 893d2ba8bbea ! .hgtags From david.katleman at oracle.com Tue May 14 19:35:46 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:35:46 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b89 for changeset ec434cfd2752 Message-ID: <20130514193552.6E71148A8A@hg.openjdk.java.net> Changeset: e19283cd30a4 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e19283cd30a4 Added tag jdk8-b89 for changeset ec434cfd2752 ! .hgtags From david.katleman at oracle.com Tue May 14 19:35:57 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 14 May 2013 19:35:57 +0000 Subject: hg: jdk8/build/nashorn: Added tag jdk8-b89 for changeset 45ce27fbe272 Message-ID: <20130514193558.BDB8048A8B@hg.openjdk.java.net> Changeset: 67ca019e3713 Author: katleman Date: 2013-05-09 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/67ca019e3713 Added tag jdk8-b89 for changeset 45ce27fbe272 ! .hgtags From david.holmes at oracle.com Wed May 15 04:21:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2013 14:21:02 +1000 Subject: RFR: 8014514: Fix jvm args for sjavac In-Reply-To: <51924B88.2080700@oracle.com> References: <51924B88.2080700@oracle.com> Message-ID: <51930D2E.4040600@oracle.com> On 15/05/2013 12:34 AM, Erik Joelsson wrote: > This patch tries to be smarter when figuring out optimal jvm args for > sjavac, especially if the jvm used is 32bit. > > http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/ > > For this to work properly, two patches to the sjavac src langtools are > also needed, but they will be handled in separate bugs and code reviews. can't really comment but does sjavac really need to mess with these: ! ADD_JVM_ARG_IF_OK([-XX:PermSize=32m],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) ! ADD_JVM_ARG_IF_OK([-XX:MaxPermSize=160m],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) ! ADD_JVM_ARG_IF_OK([-XX:ThreadStackSize=$STACK_SIZE],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) ?? David > /Erik From erik.joelsson at oracle.com Wed May 15 07:01:35 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 May 2013 09:01:35 +0200 Subject: RFR: 8014514: Fix jvm args for sjavac In-Reply-To: <51930D2E.4040600@oracle.com> References: <51924B88.2080700@oracle.com> <51930D2E.4040600@oracle.com> Message-ID: <519332CF.9030901@oracle.com> On 2013-05-15 06:21, David Holmes wrote: > On 15/05/2013 12:34 AM, Erik Joelsson wrote: >> This patch tries to be smarter when figuring out optimal jvm args for >> sjavac, especially if the jvm used is 32bit. >> >> http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/ >> >> For this to work properly, two patches to the sjavac src langtools are >> also needed, but they will be handled in separate bugs and code reviews. > > can't really comment but does sjavac really need to mess with these: > > ! > ADD_JVM_ARG_IF_OK([-XX:PermSize=32m],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) > ! > ADD_JVM_ARG_IF_OK([-XX:MaxPermSize=160m],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) > ! > ADD_JVM_ARG_IF_OK([-XX:ThreadStackSize=$STACK_SIZE],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) > I honestly don't know. Fredrik added those way back in the beginning when Hotspot had trouble running the javac server. I know he got much better performance with JRockit as the server compiler runtime at the time. I will remove them and run another jprt job and see if something nasty happens. Getting rid of it would be nice. /Erik From erik.joelsson at oracle.com Wed May 15 11:31:55 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 May 2013 13:31:55 +0200 Subject: RFR: 8014514: Fix jvm args for sjavac In-Reply-To: <519332CF.9030901@oracle.com> References: <51924B88.2080700@oracle.com> <51930D2E.4040600@oracle.com> <519332CF.9030901@oracle.com> Message-ID: <5193722B.2000606@oracle.com> On 2013-05-15 09:01, Erik Joelsson wrote: > > > On 2013-05-15 06:21, David Holmes wrote: >> On 15/05/2013 12:34 AM, Erik Joelsson wrote: >>> This patch tries to be smarter when figuring out optimal jvm args for >>> sjavac, especially if the jvm used is 32bit. >>> >>> http://cr.openjdk.java.net/~erikj/8014514/webrev.root.01/ >>> >>> For this to work properly, two patches to the sjavac src langtools are >>> also needed, but they will be handled in separate bugs and code >>> reviews. >> >> can't really comment but does sjavac really need to mess with these: >> >> ! >> ADD_JVM_ARG_IF_OK([-XX:PermSize=32m],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) >> ! >> ADD_JVM_ARG_IF_OK([-XX:MaxPermSize=160m],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) >> ! >> ADD_JVM_ARG_IF_OK([-XX:ThreadStackSize=$STACK_SIZE],SJAVAC_SERVER_JAVA,[$SJAVAC_SERVER_JAVA]) >> > I honestly don't know. Fredrik added those way back in the beginning > when Hotspot had trouble running the javac server. I know he got much > better performance with JRockit as the server compiler runtime at the > time. I will remove them and run another jprt job and see if something > nasty happens. Getting rid of it would be nice. > It worked just as well so I will declare those args as no longer needed legacy and remove them. New webrev: http://cr.openjdk.java.net/~erikj/8014514/webrev.root.02/ /Erik From erik.joelsson at oracle.com Wed May 15 13:58:05 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 May 2013 15:58:05 +0200 Subject: RFR: 8014508: Fix log levels in make Message-ID: <5193946D.9090709@oracle.com> in JDK-8010465, an attempt was made to clear up log level handling. It wasn't completely successful. The log level isn't available to sjavac and probably not in several other places that needs it. I solved it by adding LOG_LEVEL=$(LOG_LEVEL) to the MAKE variable in spec.gmk, much like the VERBOSE variable is propagated. http://cr.openjdk.java.net/~erikj/8014508/webrev.root.01/ /Erik From gnu.andrew at redhat.com Wed May 15 15:12:52 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 15 May 2013 11:12:52 -0400 (EDT) Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <51901AD3.5010004@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <1249884052.6079602.1367510783555.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <51901AD3.5010004@oracle.com> Message-ID: <1165449513.2245691.1368630771975.JavaMail.root@redhat.com> ----- Original Message ----- > Mark, > > I did some experiments on weekends and I'm against of using -u option > under any circumstances. > > People sponsoring changeset can make a mistake - most obvious one is > wrong merge conflict resolution. If it happens we are loosing the way to > solve the problem quickly - author know nothing about conflict but we > have no obvious record about sponsor. > I'm talking about cases where a sponsor isn't needed; where the person who wrote the changeset has commit rights and, if we were talking about the JDK, would be able to commit the change, given one or more reviews. In a case where the author doesn't have commit rights and a sponsor is required, it makes sense that contributed-by is used and the sponsor is the changeset author. FWIW, I've tended to stop using -u with IcedTea if the changeset needs to be altered due to merge issues, in order to signify that such changes were necessary. The original author can still be found in the original changeset. > So I think we have only two options (leaving aside extra repo) - > > a) author prepare changeset by it's own and sponsor acts just as slow > bot - all problems transmitted back to author. > > b) author send a webrev and sponsor uses Contributed-by: field to > respect credits. > These are fine for one-off patches. For regular committers, this process is not scalable. There is an option c; the author decides that they don't want to go through the huge amount of effort involved, not to mention the risk of not getting credit for it, and decides not to contribute the patch at all. This is one of our onboarding problems, IMHO. > -Dmitry > > > On 2013-05-10 01:47, mark.reinhold at oracle.com wrote: > > 2013/5/9 2:10 -0700, gnu.andrew at redhat.com: > >>> Indeed. I do this with the Oracle patches when applying them to IcedTea. > >>> The problem is how this gets done is down to the sponsor; I've had ones > >>> that have been imported, ones where I've just been giving the > >>> Contributed-by > >>> attribution (despite having commit rights) and at least one with no > >>> credit at > >> ... > >> > >> An example I just came across when looking into an issue: > >> > >> changeset: 2657:46cb9a7b8b01 > >> parent: 2647:ca1f1753c866 > >> user: dsamersoff > >> date: Wed Aug 10 15:04:21 2011 +0400 > >> files: src/share/vm/runtime/os.cpp > >> description: > >> 7073913: The fix for 7017193 causes segfaults > >> Summary: Buffer overflow in os::get_line_chars > >> Reviewed-by: coleenp, dholmes, dcubed > >> Contributed-by: aph at redhat.com > >> > >> That should have had 'aph' as the user. If you get the default output: > >> > >> changeset: 2657:46cb9a7b8b01 > >> parent: 2647:ca1f1753c866 > >> user: dsamersoff > >> date: Wed Aug 10 15:04:21 2011 +0400 > >> summary: 7073913: The fix for 7017193 causes segfaults > >> > >> it looks like Dmitry wrote the fix. > > > > I'm sure there was no intent on Dmitry's part to try to claim credit for > > this fix. > > > > The most important principle to be maintained here is that people get > > proper credit for their work, as you wrote earlier. > > > > Beyond that, it's reasonable to prefer that credit be given in the "most > > obvious" way, in particular by using proper usernames, when available, > > in changesets. If a sponsor makes a mistake, however, and winds up > > using a Contributed-by: line instead, then that's unfortunate but not, > > in my view, the end of the world. > > > > In general, if you have the Author role (or higher) in some OpenJDK > > Project then when you submit a change that requires a sponsor's help you > > should send a Mercurial patch (hg export) or bundle (hg bundle) with the > > proper username, summary, etc. In normal circumstances the sponsor > > should not change the patch but merely make sure that it's properly > > tested, merged, and pushed. If a change is required then the sponsor > > should ask the submitter to create a new patch or bundle. If for some > > reason the sponsor must modify the patch directly then the hg -u option > > should be used, as appropriate, to preserve the submitter's user name in > > the changeset. (Yes, this is one of those rare cases in which a sponsor > > should use the -u option.) > > > > Iris -- Could you please make a note to add guidance on this issue to > > the next revision of the developers' guide? Thanks. > > > > - Mark > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the source code. > -- 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 gnu.andrew at redhat.com Wed May 15 15:31:43 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 15 May 2013 11:31:43 -0400 (EDT) Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <51904E2B.2050505@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> <51904E2B.2050505@oracle.com> Message-ID: <610430170.2257586.1368631903161.JavaMail.root@redhat.com> ----- Original Message ----- > On 11/05/2013 2:53 AM, Andrew Hughes wrote: > > > I have offered a very simple solution to that problem to which no-one has > > yet > > given any reason as to why we should not implemented it; simply add a > > HotSpot tree > > where pushes can be made prior to JPRT runs, then perform the JPRT runs on > > the commits > > in that tree before merging to the main HotSpot tree. Problem solved. > > You need one of these repos for each of the hotspot group repos, > otherwise the changesets won't be correct. I'm not sure I follow this. I envision this repository as being equivalent to e.g. hotspot-gc and merged into the main HotSpot tree in the same way. > You also need an Oracle > employee to then push the change through JPRT - and that would be a lot > more effort than the existing processes as "we" would need to clone the > external repo first, re-parent the clone to the group repo, re-sync from > parent if needed, then do JPRT submit. Plus you need someone to update > these repos each time the "parent" gets updated. > I'm not saying it's an ideal solution; the ideal would be to allow everyone to submit their own JPRT runs. But, in six years, there seems to be have been no progress on this from an external standpoint. > So a simple enough idea, but the logistics are more complex. > > David > -- 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 david.katleman at oracle.com Wed May 15 18:44:53 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 15 May 2013 18:44:53 +0000 Subject: hg: jdk8/build/hotspot: 38 new changesets Message-ID: <20130515184613.2076748AD9@hg.openjdk.java.net> Changeset: 625ddb0052e1 Author: amurillo Date: 2013-05-03 08:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/625ddb0052e1 8013800: new hotspot build - hs25-b32 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c456f4510385 Author: sla Date: 2013-05-03 12:24 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c456f4510385 8008453: JvmtiClassFileReconstituter does not recognize default methods Reviewed-by: acorn, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 0380df7c3cd0 Author: sla Date: 2013-05-03 12:26 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0380df7c3cd0 8013785: Respect EXTRA_CFLAGS on windows Reviewed-by: mgronlun, rbackman, kvn ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make Changeset: 31a4e55f8c9d Author: fparain Date: 2013-05-03 05:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/31a4e55f8c9d 8004095: Add support for JMX interface to Diagnostic Framework and Commands Reviewed-by: acorn, sla ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/serviceThread.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/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/nmtDCmd.cpp ! src/share/vm/services/nmtDCmd.hpp Changeset: 39fba0d6d9ad Author: fparain Date: 2013-05-03 05:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/39fba0d6d9ad Merge Changeset: bf089b838c9e Author: ccheung Date: 2013-05-02 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bf089b838c9e 8012641: Perf_CreateLong creates perf counter of incorrect type Reviewed-by: mchung, hseigel, coleenp ! src/share/vm/prims/perf.cpp Changeset: a55b7b8c34af Author: zgu Date: 2013-05-03 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a55b7b8c34af Merge Changeset: 9c8e2f44228d Author: dcubed Date: 2013-05-03 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9c8e2f44228d Merge Changeset: 800078be49d2 Author: hseigel Date: 2013-05-06 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/800078be49d2 8013648: Guarantee(VerifyBeforeGC || VerifyDuringGC || VerifyBeforeExit || VerifyAfterGC) failed: too expensive Summary: Fix code to call correct version of function find_class(). Reviewed-by: coleenp, rdurbin, dcubed ! src/share/vm/classfile/systemDictionary.cpp Changeset: c18152e0554e Author: zgu Date: 2013-05-06 11:15 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c18152e0554e 8013120: NMT: Kitchensink crashes with assert(next_region == NULL || !next_region->is_committed_region()) failed: Sanity check Summary: Fixed NMT to deal with releasing virtual memory region when there are still committed regions within it Reviewed-by: acorn, coleenp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/services/memSnapshot.cpp + test/runtime/NMT/ReleaseCommittedMemory.java Changeset: da4d87770781 Author: zgu Date: 2013-05-06 08:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/da4d87770781 Merge Changeset: d9b08d62b95e Author: acorn Date: 2013-05-02 10:58 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d9b08d62b95e 8010783: assert(s->refcount() != 0) failed: for create_overpasses Reviewed-by: kvn, dcubed ! src/share/vm/classfile/bytecodeAssembler.cpp Changeset: b7f3bf2ba33b Author: acorn Date: 2013-05-06 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b7f3bf2ba33b Merge - agent/doc/c2replay.html Changeset: f916d5986c86 Author: acorn Date: 2013-05-06 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f916d5986c86 Merge Changeset: 187154b7a226 Author: sla Date: 2013-05-06 19:49 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/187154b7a226 8009615: JvmtiClassFileReconstituter does not create BootstrapMethod attributes Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: 3ecc6b9940de Author: sla Date: 2013-05-07 01:25 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3ecc6b9940de Merge Changeset: b5fef8013a95 Author: sla Date: 2013-05-07 14:04 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5fef8013a95 8014044: Spelling error in JDK-8009615: boostrapmethod Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: f6a055fcf47d Author: sla Date: 2013-05-07 14:33 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f6a055fcf47d 8005038: remove crufty '_g' support from SA Reviewed-by: coleenp, mgronlun, rbackman ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java Changeset: 33bcd9ead1d5 Author: ctornqvi Date: 2013-05-07 21:36 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/33bcd9ead1d5 8009577: Test test/closed/runtime/classunload broken Summary: Fixed tests to use new way of utilizing the WB API, fixed issue with where custom classloader got the classes from Reviewed-by: collins, mgerdin, zgu + test/runtime/ClassUnload/KeepAliveClass.java + test/runtime/ClassUnload/KeepAliveClassLoader.java + test/runtime/ClassUnload/KeepAliveObject.java + test/runtime/ClassUnload/KeepAliveSoftReference.java + test/runtime/ClassUnload/UnloadTest.java + test/runtime/ClassUnload/classes/test/Empty.java + test/runtime/testlibrary/ClassUnloadCommon.java Changeset: 58bb870a0cbd Author: emc Date: 2013-05-07 13:45 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/58bb870a0cbd 8009729: Refix hotspot jni_.h JNIEXPORT and JNIIMPORT definitions to match jdk version Summary: Update JNIEXPORT and JNIIMPORT to work with other compilers that don't necessarily have the __attribute__ type qualifier Reviewed-by: dholmes, dcubed, coleenp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h Changeset: 7243490a6847 Author: coleenp Date: 2013-05-07 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7243490a6847 Merge Changeset: e60b3fce2b02 Author: jiangli Date: 2013-05-06 19:57 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e60b3fce2b02 8013067: Zero builds are broken after 8010862. Summary: Fixed broken Zero build. Reviewed-by: twisti, coleenp, kvn ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/oops/method.hpp Changeset: 27d2d456cd96 Author: jiangli Date: 2013-05-06 20:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/27d2d456cd96 Merge Changeset: 6b388e7d4905 Author: bpittore Date: 2013-05-07 10:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6b388e7d4905 8013633: Cleanup platform ifdefs in unsafe.cpp Summary: Replace ifdefs with SUPPORTS_NATIVE_CX8 set in platform include file Reviewed-by: dholmes, dlong ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/share/vm/prims/unsafe.cpp Changeset: a258a8351528 Author: vladidan Date: 2013-05-07 10:36 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a258a8351528 Merge - agent/doc/c2replay.html Changeset: d3c98423c146 Author: jiangli Date: 2013-05-09 16:27 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d3c98423c146 Merge Changeset: 1d0fba8a2a6d Author: brutisso Date: 2013-05-02 22:35 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1d0fba8a2a6d 8013574: PrintMalloc conflicts with the command line parsing Summary: Make sure that _num_jvm_args is not updated until the new entry to _jvm_args_array has been added Reviewed-by: johnc, tamao, tschatzl ! src/share/vm/runtime/arguments.cpp Changeset: f14063dcd52a Author: brutisso Date: 2013-05-06 09:16 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f14063dcd52a 8013791: G1: G1CollectorPolicy::initialize_flags() may set min_alignment > max_alignment Summary: Make sure max alignemnt is at least as large as min alignment Reviewed-by: johnc, jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp + test/gc/g1/TestRegionAlignment.java Changeset: 30860066ae8f Author: jwilhelm Date: 2013-05-06 13:03 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/30860066ae8f Merge ! src/share/vm/runtime/arguments.cpp Changeset: d17700c82d7d Author: tschatzl Date: 2013-05-06 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d17700c82d7d 8006088: Incompatible heap size flags accepted by VM Summary: Make processing of minimum, initial and maximum heap size more intiutive by removing previous limitations on allowed values, and make error reporting consistent. Further, fix errors in ergonomic heap sizing. Reviewed-by: johnc, jwilhelm, tamao ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: b0d20fa374b4 Author: brutisso Date: 2013-05-06 21:30 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b0d20fa374b4 8013872: G1: HeapRegionSeq::shrink_by() has invalid assert Summary: Refactored shrink_by() to only use region counts and not byte sizes Reviewed-by: johnc, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + test/gc/g1/TestShrinkToOneRegion.java Changeset: a9d568b7df60 Author: jmasa Date: 2013-05-08 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a9d568b7df60 8013032: CMS: assert(used() == used_after_gc && used_after_gc <= capacity()) failed: used: 0 used_after_gc: 292080 capacity: 1431699456 Reviewed-by: tschatzl, mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp + test/gc/concurrentMarkSweep/CheckAllocateAndSystemGC.java Changeset: 06ab37f08701 Author: jmasa Date: 2013-05-08 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/06ab37f08701 8013184: CMS: Call reset_after_compaction() only if a compaction has been done Reviewed-by: mgerdin, johnc, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/concurrentMarkSweep/SystemGCOnForegroundCollector.java Changeset: 923ac8d1df95 Author: jwilhelm Date: 2013-05-09 12:23 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/923ac8d1df95 Merge Changeset: 194f52aa2f23 Author: johnc Date: 2013-05-09 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/194f52aa2f23 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap Summary: Refactor G1's hot card cache and card counts table into their own files. Simplify the card counts table, including removing the encoding of the card index in each entry. The card counts table now has a 1:1 correspondence with the cards spanned by heap. Space for the card counts table is reserved from virtual memory (rather than C heap) during JVM startup and is committed/expanded when the heap is expanded. Changes were also reviewed-by Vitaly Davidovich. Reviewed-by: tschatzl, jmasa ! make/excludeSrc.make ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp + src/share/vm/gc_implementation/g1/g1CardCounts.cpp + src/share/vm/gc_implementation/g1/g1CardCounts.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp + src/share/vm/gc_implementation/g1/g1HotCardCache.cpp + src/share/vm/gc_implementation/g1/g1HotCardCache.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 73652d89e7c4 Author: stefank Date: 2013-05-10 09:24 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/73652d89e7c4 Merge Changeset: 69494caf5790 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/69494caf5790 Merge Changeset: 1ae0472ff3a0 Author: amurillo Date: 2013-05-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1ae0472ff3a0 Added tag hs25-b32 for changeset 69494caf5790 ! .hgtags From tim.bell at oracle.com Wed May 15 18:49:22 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 15 May 2013 11:49:22 -0700 Subject: RFR: 8014508: Fix log levels in make In-Reply-To: <5193946D.9090709@oracle.com> References: <5193946D.9090709@oracle.com> Message-ID: <5193D8B2.6090002@oracle.com> Erik: > in JDK-8010465, an attempt was made to clear up log level handling. It > wasn't completely successful. The log level isn't available to sjavac > and probably not in several other places that needs it. > > I solved it by adding LOG_LEVEL=$(LOG_LEVEL) to the MAKE variable in > spec.gmk, much like the VERBOSE variable is propagated. > > http://cr.openjdk.java.net/~erikj/8014508/webrev.root.01 Looks good. Tim From tim.bell at oracle.com Wed May 15 21:07:38 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 15 May 2013 14:07:38 -0700 Subject: Fix for 8014669, build flags issue In-Reply-To: <5193F495.2020600@oracle.com> References: <5193F495.2020600@oracle.com> Message-ID: <5193F91A.3050105@oracle.com> Hi Bill: > Some architecture dependent flags do not make it through to the > libjsig.so and libsaproc.so makefiles. As a result, the libs are not > compiled/linked with the correct flags for that particular variant. > Fix is to make sure EXTRA_CFLAGS propogates down correctly. > > http://cr.openjdk.java.net/~bpittore/8014669/webrev.00 Looks good to me on the build side.. Tim From bill.pittore at oracle.com Wed May 15 21:16:22 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 15 May 2013 17:16:22 -0400 Subject: Fix for 8014669, build flags issue In-Reply-To: <5193F91A.3050105@oracle.com> References: <5193F495.2020600@oracle.com> <5193F91A.3050105@oracle.com> Message-ID: <5193FB26.8090501@oracle.com> Thanks! bill On 5/15/2013 5:07 PM, Tim Bell wrote: > Hi Bill: > >> Some architecture dependent flags do not make it through to the >> libjsig.so and libsaproc.so makefiles. As a result, the libs are not >> compiled/linked with the correct flags for that particular variant. >> Fix is to make sure EXTRA_CFLAGS propogates down correctly. >> >> http://cr.openjdk.java.net/~bpittore/8014669/webrev.00 > > Looks good to me on the build side.. > > Tim > From david.holmes at oracle.com Thu May 16 00:05:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 10:05:47 +1000 Subject: Fix for 8014669, build flags issue In-Reply-To: <5193F495.2020600@oracle.com> References: <5193F495.2020600@oracle.com> Message-ID: <519422DB.705@oracle.com> Hi Bill, (re-fixed the build-dev alias) On 16/05/2013 6:48 AM, BILL PITTORE wrote: > Some architecture dependent flags do not make it through to the > libjsig.so and libsaproc.so makefiles. As a result, the libs are not > compiled/linked with the correct flags for that particular variant. Fix > is to make sure EXTRA_CFLAGS propogates down correctly. > > http://cr.openjdk.java.net/~bpittore/8014669/webrev.00/ I need to look closer at this. Passing all of the EXTRA_CFLAGS as link options seems wrong to me as they may not be valid linker options. That said I see that in this case we are actually using the C compiler to do the linking. But that said, in the saproc case we are also compiling C source files at the same time which means that EXTRA_CFLAGS is needed on the main command line, not tucked onto the LD flags. And the implication here is that cross-compilation of libsaproc has been broken all this time for any platform where the default gcc output would be wrong! David From david.katleman at oracle.com Thu May 16 00:22:30 2013 From: david.katleman at oracle.com (David Katleman) Date: Wed, 15 May 2013 17:22:30 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> Message-ID: <519426C6.5030702@oracle.com> On 5/13/2013 8:59 AM, David DeHaven wrote: > If it were my choice, Mac OS X 10.8 would be the base OS with Xcode 4.6.1 (current) with clang as the officially supported compiler and with an option to use gcc. I don't see why that would't last at least the public lifecycle of JDK8. What I would be more concerned with is the apparent drift from what we know as Mac OS X towards something more iOS-like, that could mean libraries and frameworks we depend on no longer being available, but at that point it wouldn't be the same OS and we'd have to re-evaluate anyways. Sort of like what's happening with Windows 8 right now. Sorry for what may be considered muddying the waters, since this is a JDK8 discussion. What about JDK7 update builds? We currently use the same set of macosx hardware for both 7u & 8. Does JPRT / others do so as well, or do they maintain separate systems for 7u. Dave From david.holmes at oracle.com Thu May 16 00:43:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 10:43:14 +1000 Subject: Fix for 8014669, build flags issue In-Reply-To: <519422DB.705@oracle.com> References: <5193F495.2020600@oracle.com> <519422DB.705@oracle.com> Message-ID: <51942BA2.4030209@oracle.com> Hi Bill, On 16/05/2013 10:05 AM, David Holmes wrote: > Hi Bill, > > (re-fixed the build-dev alias) > > On 16/05/2013 6:48 AM, BILL PITTORE wrote: >> Some architecture dependent flags do not make it through to the >> libjsig.so and libsaproc.so makefiles. As a result, the libs are not >> compiled/linked with the correct flags for that particular variant. Fix >> is to make sure EXTRA_CFLAGS propogates down correctly. >> >> http://cr.openjdk.java.net/~bpittore/8014669/webrev.00/ > > I need to look closer at this. Passing all of the EXTRA_CFLAGS as link > options seems wrong to me as they may not be valid linker options. That > said I see that in this case we are actually using the C compiler to do > the linking. But that said, in the saproc case we are also compiling C > source files at the same time which means that EXTRA_CFLAGS is needed on > the main command line, not tucked onto the LD flags. And the implication > here is that cross-compilation of libsaproc has been broken all this > time for any platform where the default gcc output would be wrong! Given in both cases we use CC to compile and link I think the more explicit solution here is to add EXTRA_CFLAGS as a primary argument to the $(CC) invocation - see below. Thanks, David diff -r 293b99787401 make/linux/makefiles/jsig.make --- a/make/linux/makefiles/jsig.make +++ b/make/linux/makefiles/jsig.make @@ -54,7 +54,7 @@ $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) @echo Making signal interposition lib... $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< -ldl + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) $(EXTRA_CFLAGS) -o $@ $< -ldl ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJSIG_DEBUGINFO) $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJSIG_DEBUGINFO) $@ diff -r 293b99787401 make/linux/makefiles/saproc.make --- a/make/linux/makefiles/saproc.make +++ b/make/linux/makefiles/saproc.make @@ -92,6 +92,7 @@ $(SASRCFILES) \ $(SA_LFLAGS) \ $(SA_DEBUG_CFLAGS) \ + $(EXTRA_CFLAGS) \ -o $@ \ -lthread_db ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) From bill.pittore at oracle.com Thu May 16 01:20:43 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 15 May 2013 21:20:43 -0400 Subject: Fix for 8014669, build flags issue In-Reply-To: <519422DB.705@oracle.com> References: <5193F495.2020600@oracle.com> <519422DB.705@oracle.com> Message-ID: <5194346B.8080904@oracle.com> On 5/15/2013 8:05 PM, David Holmes wrote: > Hi Bill, > > (re-fixed the build-dev alias) > > On 16/05/2013 6:48 AM, BILL PITTORE wrote: >> Some architecture dependent flags do not make it through to the >> libjsig.so and libsaproc.so makefiles. As a result, the libs are not >> compiled/linked with the correct flags for that particular variant. Fix >> is to make sure EXTRA_CFLAGS propogates down correctly. >> >> http://cr.openjdk.java.net/~bpittore/8014669/webrev.00/ > > I need to look closer at this. Passing all of the EXTRA_CFLAGS as link > options seems wrong to me as they may not be valid linker options. > That said I see that in this case we are actually using the C compiler > to do the linking. But that said, in the saproc case we are also > compiling C source files at the same time which means that > EXTRA_CFLAGS is needed on the main command line, not tucked onto the > LD flags. And the implication here is that cross-compilation of > libsaproc has been broken all this time for any platform where the > default gcc output would be wrong! Just took a look at an ARM build with and without my changes and without the changes you do not get any of the EXTRA_CFLAGS options when you compile the libjsig or libsaproc sources. You basically get the default for the cross tool gcc you are using, in this case ARM v5t. Could be different for other cross tools. We've just been lucky I guess. bill > > David > From bill.pittore at oracle.com Thu May 16 01:37:36 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 15 May 2013 21:37:36 -0400 Subject: Fix for 8014669, build flags issue In-Reply-To: <51942BA2.4030209@oracle.com> References: <5193F495.2020600@oracle.com> <519422DB.705@oracle.com> <51942BA2.4030209@oracle.com> Message-ID: <51943860.3020301@oracle.com> I'm fine with these changes. I can commit if someone can do the push if you think we need to get this in tonight. bill On 5/15/2013 8:43 PM, David Holmes wrote: > Hi Bill, > > On 16/05/2013 10:05 AM, David Holmes wrote: >> Hi Bill, >> >> (re-fixed the build-dev alias) >> >> On 16/05/2013 6:48 AM, BILL PITTORE wrote: >>> Some architecture dependent flags do not make it through to the >>> libjsig.so and libsaproc.so makefiles. As a result, the libs are not >>> compiled/linked with the correct flags for that particular variant. Fix >>> is to make sure EXTRA_CFLAGS propogates down correctly. >>> >>> http://cr.openjdk.java.net/~bpittore/8014669/webrev.00/ >> >> I need to look closer at this. Passing all of the EXTRA_CFLAGS as link >> options seems wrong to me as they may not be valid linker options. That >> said I see that in this case we are actually using the C compiler to do >> the linking. But that said, in the saproc case we are also compiling C >> source files at the same time which means that EXTRA_CFLAGS is needed on >> the main command line, not tucked onto the LD flags. And the implication >> here is that cross-compilation of libsaproc has been broken all this >> time for any platform where the default gcc output would be wrong! > > Given in both cases we use CC to compile and link I think the more > explicit solution here is to add EXTRA_CFLAGS as a primary argument to > the $(CC) invocation - see below. > > Thanks, > David > > diff -r 293b99787401 make/linux/makefiles/jsig.make > --- a/make/linux/makefiles/jsig.make > +++ b/make/linux/makefiles/jsig.make > @@ -54,7 +54,7 @@ > $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) > @echo Making signal interposition lib... > $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) > $(PICFLAG) \ > - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< > -ldl > + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > $(EXTRA_CFLAGS) -o $@ $< -ldl > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJSIG_DEBUGINFO) > $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJSIG_DEBUGINFO) $@ > diff -r 293b99787401 make/linux/makefiles/saproc.make > --- a/make/linux/makefiles/saproc.make > +++ b/make/linux/makefiles/saproc.make > @@ -92,6 +92,7 @@ > $(SASRCFILES) \ > $(SA_LFLAGS) \ > $(SA_DEBUG_CFLAGS) \ > + $(EXTRA_CFLAGS) \ > -o $@ \ > -lthread_db > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > From david.holmes at oracle.com Thu May 16 02:34:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 12:34:17 +1000 Subject: Fix for 8014669, build flags issue In-Reply-To: <51943860.3020301@oracle.com> References: <5193F495.2020600@oracle.com> <519422DB.705@oracle.com> <51942BA2.4030209@oracle.com> <51943860.3020301@oracle.com> Message-ID: <519445A9.1090501@oracle.com> On 16/05/2013 11:37 AM, BILL PITTORE wrote: > I'm fine with these changes. I can commit if someone can do the push if > you think we need to get this in tonight. I can push for you but I don't think this will get in "tonight" nor in time for this week's build. We also need a backport for hs24. Thanks, David > bill > > On 5/15/2013 8:43 PM, David Holmes wrote: >> Hi Bill, >> >> On 16/05/2013 10:05 AM, David Holmes wrote: >>> Hi Bill, >>> >>> (re-fixed the build-dev alias) >>> >>> On 16/05/2013 6:48 AM, BILL PITTORE wrote: >>>> Some architecture dependent flags do not make it through to the >>>> libjsig.so and libsaproc.so makefiles. As a result, the libs are not >>>> compiled/linked with the correct flags for that particular variant. Fix >>>> is to make sure EXTRA_CFLAGS propogates down correctly. >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014669/webrev.00/ >>> >>> I need to look closer at this. Passing all of the EXTRA_CFLAGS as link >>> options seems wrong to me as they may not be valid linker options. That >>> said I see that in this case we are actually using the C compiler to do >>> the linking. But that said, in the saproc case we are also compiling C >>> source files at the same time which means that EXTRA_CFLAGS is needed on >>> the main command line, not tucked onto the LD flags. And the implication >>> here is that cross-compilation of libsaproc has been broken all this >>> time for any platform where the default gcc output would be wrong! >> >> Given in both cases we use CC to compile and link I think the more >> explicit solution here is to add EXTRA_CFLAGS as a primary argument to >> the $(CC) invocation - see below. >> >> Thanks, >> David >> >> diff -r 293b99787401 make/linux/makefiles/jsig.make >> --- a/make/linux/makefiles/jsig.make >> +++ b/make/linux/makefiles/jsig.make >> @@ -54,7 +54,7 @@ >> $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) >> @echo Making signal interposition lib... >> $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) >> $(PICFLAG) \ >> - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< >> -ldl >> + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) >> $(EXTRA_CFLAGS) -o $@ $< -ldl >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJSIG_DEBUGINFO) >> $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJSIG_DEBUGINFO) $@ >> diff -r 293b99787401 make/linux/makefiles/saproc.make >> --- a/make/linux/makefiles/saproc.make >> +++ b/make/linux/makefiles/saproc.make >> @@ -92,6 +92,7 @@ >> $(SASRCFILES) \ >> $(SA_LFLAGS) \ >> $(SA_DEBUG_CFLAGS) \ >> + $(EXTRA_CFLAGS) \ >> -o $@ \ >> -lthread_db >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> > > From david.dehaven at oracle.com Thu May 16 03:35:26 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 15 May 2013 20:35:26 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <519426C6.5030702@oracle.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> <519426C6.5030702@oracle.com> Message-ID: >> If it were my choice, Mac OS X 10.8 would be the base OS with Xcode 4.6.1 (current) with clang as the officially supported compiler and with an option to use gcc. I don't see why that would't last at least the public lifecycle of JDK8. What I would be more concerned with is the apparent drift from what we know as Mac OS X towards something more iOS-like, that could mean libraries and frameworks we depend on no longer being available, but at that point it wouldn't be the same OS and we'd have to re-evaluate anyways. Sort of like what's happening with Windows 8 right now. > > Sorry for what may be considered muddying the waters, since this is a JDK8 discussion. > > What about JDK7 update builds? We currently use the same set of macosx hardware for both 7u & 8. Does JPRT / others do so as well, or do they maintain separate systems for 7u. My understanding is the 7u build systems (and requirements) will remain as they are, since the OBS is not as flexible and is sensitive to what version OS it's building on. There could be justification for fixing the OS version requirement, but keeping a 10.7 machine running isn't a problem yet. The Xcode version requirement is distantly secondary. Actually the fix could be as easy as setting environment variables on the system, so maybe there's nothing to it at all. -DrD- From david.holmes at oracle.com Thu May 16 04:18:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 14:18:40 +1000 Subject: MacOS build tool selections for JDK8 In-Reply-To: <519426C6.5030702@oracle.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> <519426C6.5030702@oracle.com> Message-ID: <51945E20.2000600@oracle.com> On 16/05/2013 10:22 AM, David Katleman wrote: > > On 5/13/2013 8:59 AM, David DeHaven wrote: >> If it were my choice, Mac OS X 10.8 would be the base OS with Xcode >> 4.6.1 (current) with clang as the officially supported compiler and >> with an option to use gcc. I don't see why that would't last at least >> the public lifecycle of JDK8. What I would be more concerned with is >> the apparent drift from what we know as Mac OS X towards something >> more iOS-like, that could mean libraries and frameworks we depend on >> no longer being available, but at that point it wouldn't be the same >> OS and we'd have to re-evaluate anyways. Sort of like what's happening >> with Windows 8 right now. > > Sorry for what may be considered muddying the waters, since this is a > JDK8 discussion. > > What about JDK7 update builds? We currently use the same set of macosx > hardware for both 7u & 8. Does JPRT / others do so as well, or do > they maintain separate systems for 7u. JPRT as far as I know only uses 10.7 systems for builds. The 10.8 systems can only be used for testing. David > Dave > From staffan.larsen at oracle.com Thu May 16 06:24:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 16 May 2013 08:24:07 +0200 Subject: Fix for 8014669, build flags issue In-Reply-To: <51943860.3020301@oracle.com> References: <5193F495.2020600@oracle.com> <519422DB.705@oracle.com> <51942BA2.4030209@oracle.com> <51943860.3020301@oracle.com> Message-ID: <2015F2D2-584C-4A1B-894C-64BEBCEBF66B@oracle.com> David's change looks good to me. /Staffan On 16 maj 2013, at 03:37, BILL PITTORE wrote: > I'm fine with these changes. I can commit if someone can do the push if you think we need to get this in tonight. > > bill > > On 5/15/2013 8:43 PM, David Holmes wrote: >> Hi Bill, >> >> On 16/05/2013 10:05 AM, David Holmes wrote: >>> Hi Bill, >>> >>> (re-fixed the build-dev alias) >>> >>> On 16/05/2013 6:48 AM, BILL PITTORE wrote: >>>> Some architecture dependent flags do not make it through to the >>>> libjsig.so and libsaproc.so makefiles. As a result, the libs are not >>>> compiled/linked with the correct flags for that particular variant. Fix >>>> is to make sure EXTRA_CFLAGS propogates down correctly. >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014669/webrev.00/ >>> >>> I need to look closer at this. Passing all of the EXTRA_CFLAGS as link >>> options seems wrong to me as they may not be valid linker options. That >>> said I see that in this case we are actually using the C compiler to do >>> the linking. But that said, in the saproc case we are also compiling C >>> source files at the same time which means that EXTRA_CFLAGS is needed on >>> the main command line, not tucked onto the LD flags. And the implication >>> here is that cross-compilation of libsaproc has been broken all this >>> time for any platform where the default gcc output would be wrong! >> >> Given in both cases we use CC to compile and link I think the more explicit solution here is to add EXTRA_CFLAGS as a primary argument to the $(CC) invocation - see below. >> >> Thanks, >> David >> >> diff -r 293b99787401 make/linux/makefiles/jsig.make >> --- a/make/linux/makefiles/jsig.make >> +++ b/make/linux/makefiles/jsig.make >> @@ -54,7 +54,7 @@ >> $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) >> @echo Making signal interposition lib... >> $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ >> - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< -ldl >> + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) $(EXTRA_CFLAGS) -o $@ $< -ldl >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJSIG_DEBUGINFO) >> $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJSIG_DEBUGINFO) $@ >> diff -r 293b99787401 make/linux/makefiles/saproc.make >> --- a/make/linux/makefiles/saproc.make >> +++ b/make/linux/makefiles/saproc.make >> @@ -92,6 +92,7 @@ >> $(SASRCFILES) \ >> $(SA_LFLAGS) \ >> $(SA_DEBUG_CFLAGS) \ >> + $(EXTRA_CFLAGS) \ >> -o $@ \ >> -lthread_db >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> > > From david.holmes at oracle.com Thu May 16 10:23:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2013 20:23:55 +1000 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <610430170.2257586.1368631903161.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <51887EAC.60804@oracle.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> <51904E2B.2050505@oracle.com> <610430170.2257586.1368631903161.JavaMail.root@redhat.com> Message-ID: <5194B3BB.7070002@oracle.com> On 16/05/2013 1:31 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 11/05/2013 2:53 AM, Andrew Hughes wrote: >> >>> I have offered a very simple solution to that problem to which no-one has >>> yet >>> given any reason as to why we should not implemented it; simply add a >>> HotSpot tree >>> where pushes can be made prior to JPRT runs, then perform the JPRT runs on >>> the commits >>> in that tree before merging to the main HotSpot tree. Problem solved. >> >> You need one of these repos for each of the hotspot group repos, >> otherwise the changesets won't be correct. > > I'm not sure I follow this. I envision this repository as being equivalent > to e.g. hotspot-gc and merged into the main HotSpot tree in the same way. The group repos, like hotspot-gc, only accept changes that pass JPRT and only sync up to hotspot-main after successful bouts of nightly testing. Your proposed repo would need an equivalent level of testing before changes could go straight to hotspot-main, so I can only see it working if it is treated as a child of one of the existing group repos and so we have: external repo -> jprt -> group repo [testing] -> jprt -> hotspot-main But as we have multiple group repos you then need an external repo per group - which in turn will require a "gatekeeper" from each group to manage the logistics of the actual jprt submissions and keeping things in sync. David ----- >> You also need an Oracle >> employee to then push the change through JPRT - and that would be a lot >> more effort than the existing processes as "we" would need to clone the >> external repo first, re-parent the clone to the group repo, re-sync from >> parent if needed, then do JPRT submit. Plus you need someone to update >> these repos each time the "parent" gets updated. >> > > I'm not saying it's an ideal solution; the ideal would be to allow everyone > to submit their own JPRT runs. But, in six years, there seems to be have > been no progress on this from an external standpoint. > >> So a simple enough idea, but the logistics are more complex. >> >> David >> > From Sergey.Bylokhov at oracle.com Thu May 16 16:12:17 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 May 2013 20:12:17 +0400 Subject: webrev failure? In-Reply-To: <5FC8F64F-77BB-4537-B286-B0533AA97D3F@oracle.com> References: <5027939A.8060209@oracle.com> <20120813160521.GE2509@toonder.wildebeest.org> <5FC8F64F-77BB-4537-B286-B0533AA97D3F@oracle.com> Message-ID: <51950561.6050808@oracle.com> Hi, Staffan. Try this version: http://cr.openjdk.java.net/~serb/forest.py I update forest extension a little bit to work with mercurial 2.3+. ps: It was my first code on python. > Mercurial 2.3 seems to have changed quite a bit on the inside. I spent an hour or so (without knowing anything about the mercurial insides) trying to patch forest to work with 2.3 but failed. Perhaps someone with better mercurial knowledge can take a look. > > I ended up downgrading to 2.2. > > /Staffan > -- Best regards, Sergey. From staffan.larsen at oracle.com Thu May 16 16:30:41 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 16 May 2013 18:30:41 +0200 Subject: webrev failure? In-Reply-To: <51950561.6050808@oracle.com> References: <5027939A.8060209@oracle.com> <20120813160521.GE2509@toonder.wildebeest.org> <5FC8F64F-77BB-4537-B286-B0533AA97D3F@oracle.com> <51950561.6050808@oracle.com> Message-ID: Thanks! Can you contribute it to the version at http://icedtea.classpath.org/hg/hgforest ? /Staffan On 16 maj 2013, at 18:12, Sergey Bylokhov wrote: > Hi, Staffan. > Try this version: http://cr.openjdk.java.net/~serb/forest.py > I update forest extension a little bit to work with mercurial 2.3+. > ps: It was my first code on python. > >> Mercurial 2.3 seems to have changed quite a bit on the inside. I spent an hour or so (without knowing anything about the mercurial insides) trying to patch forest to work with 2.3 but failed. Perhaps someone with better mercurial knowledge can take a look. >> >> I ended up downgrading to 2.2. >> >> /Staffan >> > > > -- > Best regards, Sergey. > From klara.ward at oracle.com Thu May 16 20:18:47 2013 From: klara.ward at oracle.com (Klara Ward) Date: Thu, 16 May 2013 22:18:47 +0200 Subject: Please review changes for JDK-8014762: Add JMC configure option mapping to Jprt.gmk Message-ID: <51953F27.7090009@oracle.com> Need to add the mapping between JPRT env var and configure flag for JMC, from ALT_JMC_ZIP_DIR to --with-jmc-zip-dir (same pattern as for Javafx) http://javaweb.us.oracle.com/~klward/webrev/make_jprt_jdk8/ Thanks, Klara From tim.bell at oracle.com Thu May 16 22:44:55 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 16 May 2013 15:44:55 -0700 Subject: Please review changes for JDK-8014762: Add JMC configure option mapping to Jprt.gmk In-Reply-To: <51953F27.7090009@oracle.com> References: <51953F27.7090009@oracle.com> Message-ID: <51956167.8070504@oracle.com> Hi Klara: > Need to add the mapping between JPRT env var and configure flag for JMC, > from ALT_JMC_ZIP_DIR to --with-jmc-zip-dir > (same pattern as for Javafx) > > http://javaweb.us.oracle.com/~klward/webrev/make_jprt_jdk8 This looks fine. Thanks- Tim From Alan.Bateman at oracle.com Sun May 19 14:32:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 May 2013 15:32:23 +0100 Subject: BUILD_JOBJC woes on Mac Message-ID: <5198E277.9090202@oracle.com> I've have an up-to-date clone of jdk8/tl + a patch to code in the jdk repository that makes use of APIs that are new in jdk8. It builds/run happily on all platforms except Mac where it needs to build JObjC.jar. Attached is the tail of "make LOG=trace" where it looks like JObjC.jar involves compiling jdk8 classes with -source/target 1.5. In this case the boot JDK is an update to date build of jdk7u-dev. Does anyone have any insight in how JObjC.jar should be built? I remember Dan Xu ran into something similar recently with @Native and I suspect this is the same underlying issue (in Dan's case then the code didn't need @Native). Thanks, -Alan Compiling 886 files for BUILD_JOBJC( /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/bin/javac -source 1.5 -target 1.5 -g -bootclasspath /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar -cp /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/../langtools/dist/lib/classes.jar -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally -implicit:none -sourcepath "/u/alanb/ws/tl/jdk/src/macosx/native/jobjc/src/core/java:/u/alanb/ws/tl/jdk/src/macosx/native/jobjc/src/runtime-additions/java:/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc" -d /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes @/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch.tmp && /bin/mv /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch.tmp /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch) /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:34: error: cannot find symbol import java.util.Spliterator; ^ symbol: class Spliterator location: package java.util /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:35: error: package java.util.stream does not exist import java.util.stream.StreamSupport; ^ /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:36: error: package java.util.stream does not exist import java.util.stream.IntStream; ^ /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1481: error: cannot find symbol public IntStream chars() { ^ symbol: class IntStream location: class CharBuffer /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1482: error: cannot find symbol CharBufferSpliterator spliterator = new CharBufferSpliterator(this); ^ symbol: class CharBufferSpliterator location: class CharBuffer /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1482: error: cannot find symbol CharBufferSpliterator spliterator = new CharBufferSpliterator(this); ^ symbol: class CharBufferSpliterator location: class CharBuffer /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1483: error: cannot find symbol return StreamSupport.intStream(spliterator); ^ symbol: variable StreamSupport location: class CharBuffer Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 7 errors make[2]: *** [/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] Error 1 make[1]: *** [classes-only] Error 2 make: *** [jdk-only] Error 2 From david.r.chase at oracle.com Sun May 19 20:58:46 2013 From: david.r.chase at oracle.com (David Chase) Date: Sun, 19 May 2013 16:58:46 -0400 Subject: Windows configure "issues" Message-ID: This is for Windows 7, following instructions, mostly vanilla. I restarted after all the various installations. I'm "following" the instructions at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html The non-vanilla step, inspired by the cautionary warnings about paths with spaces in them and cygwin, was to install Java and VS10 express in C:\PFx86, not C:\Program Files. #1, after setting the path explicitly, it was ignored and "not found". $ bash configure --with-boot-jdk=$J --with-tools-dir="C:\\PFx86\\MVS10.0\\VC\\bin" configure: Found Visual Studio installation at /cygdrive/c/PFx86/MVS10.0/ using VS100COMNTOOLS variable configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring configure: Found Visual Studio installation at /cygdrive/c/Program Files/Microsoft Visual Studio 10.0 using well-known name configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring configure: Cannot locate a valid Visual Studio installation, checking current environment checking for Visual Studio variables... not found configure: Cannot locate a valid Visual Studio or Windows SDK installation on disk, configure: nor is this script run from a Visual Studio command prompt. configure: Try setting --with-tools-dir to the VC/bin directory within the VS installation configure: or run "bash.exe -l" from a VS command prompt and then run configure from there. configure: error: Cannot continue configure exiting with result code 1 My understanding of what happened is that it found, both from the tools dir and from the environment variable, an Express install, but because it was an Express install it kept looking, and was misled by something dribbled in Program Files by my non-standard-installation-location install, and did not then backtrack to the perfectly good Express install that I instructed it to use. I told it exactly what to do, in exactly the way that I was instructed, and it ignored my good advice. If the answer is "fails if not installed in the default location, even if you direct it to the non-default location" (i.e., ProgramSPACEFiles, despite our worrying language about the dangers of SPACEs in paths), then we should be sure to say so. #2, if you fire up a Visual Studio command prompt and say "bash.exe -l", it will not find it and will not run it. If you naively attempt to reverse engineer the "which base" from your Cygwin window, you will be lead astray and go looking for C:\cygwin\usr\bin\bash.exe", which does not exist. What does exist, what you should tell people to type, and what works, is: C:\cygwin\bin\bash.exe . So the instructions should say that, instead. However, once reverse-engineered, it did seem work (if this is working): configure: Found Visual Studio installation at /cygdrive/c/PFx86/MVS10.0/ using VS100COMNTOOLS variable configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring configure: Found Visual Studio installation at /cygdrive/c/Program Files/Microsoft Visual Studio 10.0 using well-known name configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring configure: Cannot locate a valid Visual Studio installation, checking current environment checking for Visual Studio variables... ok checking for msvcr100.dll... configure: Warning: msvcr100.dll not found in VCINSTALLDIR: C:\PFx86\MVS10.0\VC\ configure: msvcr100.dll found in C:\windows/system32 C:\windows/system32/msvcr100.dll configure: Rewriting MSVCR_DLL to "/cygdrive/c/windows/system32/msvcr100.dll" #3, the DirectX 9.0 link is not maybe dead, it is dead. The search for "DirectX 9.0 SDK Update Summer 2004" is also dead; nothing is found. Searches for "DirectX 9" yield downloads that are not SDKs, searches for "DirectX 9 SDK" and "DirectX 9.0 SDK" leads to SDKs that are not version 9. Does it still work with somewhat newer (e.g., April 2006, version "DX")? http://www.microsoft.com/en-us/download/details.aspx?id=24982 If it does, we should say so, because currently the instructions lead to dead ends. David From david.r.chase at oracle.com Mon May 20 08:56:02 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 20 May 2013 04:56:02 -0400 Subject: Windows configure "issues" In-Reply-To: References: Message-ID: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> On 2013-05-19, at 4:58 PM, David Chase wrote: > #3, the DirectX 9.0 link is not maybe dead, it is dead. > The search for "DirectX 9.0 SDK Update Summer 2004" is also dead; nothing is found. > Searches for "DirectX 9" yield downloads that are not SDKs, searches for "DirectX 9 SDK" and "DirectX 9.0 SDK" leads to SDKs that are not version 9. > > Does it still work with somewhat newer (e.g., April 2006, version "DX")? > http://www.microsoft.com/en-us/download/details.aspx?id=24982 > If it does, we should say so, because currently the instructions lead to dead ends. I found this one, version 9.29.1962 . http://www.microsoft.com/en-us/download/details.aspx?id=6812 Is this likely to be an acceptable version? David From victor.lavaud at gmail.com Mon May 20 09:57:43 2013 From: victor.lavaud at gmail.com (Victor Lavaud) Date: Mon, 20 May 2013 11:57:43 +0200 Subject: Why is CUPS required? Message-ID: <1369043863.4924.17.camel@nomada> Hello, I find it intriguing that ./configure fails when it cannot find CUPS, and I wonder if this is because I did something wrong, or the configure script is not flexible enough, or the underlying source code cannot work without cups. I believe there is a number of cases where CUPS has no reason to be present: servers, printerless computers. Other Java implementations don?t require it either. Cheers, Victor From david.r.chase at oracle.com Mon May 20 13:04:26 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 20 May 2013 09:04:26 -0400 Subject: Windows configure "issues" In-Reply-To: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> Message-ID: In addition, the instructions must note that if the Express compiler is used, the 64-bit compiler is (apparently, according to configure) not provided, and hence --with-target-bits=32 is required. David From philip.race at oracle.com Mon May 20 13:36:58 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 May 2013 06:36:58 -0700 Subject: Why is CUPS required? In-Reply-To: <1369043863.4924.17.camel@nomada> References: <1369043863.4924.17.camel@nomada> Message-ID: <519A26FA.9010800@oracle.com> CUPS is used by the Java 2D printing APIs on Solaris & Linux and similar. If you want to build an implementation of "Java SE" on a platform where printing is supported and you do not enable printing, then you will fail the JCK. The suggestion that servers don't print is odd. They sometimes do, and server-side control of printing was a long ago RFE - and has been there since 1.4. CUPS was needed in the 'old' build system too, so while 'build-dev' can answer questions about how the JDK is built, but that doesn't make it the place to ask about why the JDK needs certain platform APIs in order to build. That is a matter for the relevant groups which depend on those APIs. In this case 2d-dev. -phil. On 5/20/13 2:57 AM, Victor Lavaud wrote: > Hello, > I find it intriguing that ./configure fails when it cannot find CUPS, > and I wonder if this is because I did something wrong, or the configure > script is not flexible enough, or the underlying source code cannot work > without cups. > I believe there is a number of cases where CUPS has no reason to be > present: servers, printerless computers. > Other Java implementations don?t require it either. > > Cheers, > Victor From philip.race at oracle.com Mon May 20 20:04:01 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 May 2013 13:04:01 -0700 Subject: Compiling 10459 java files when 1 is all that is needed. Message-ID: <519A81B1.9010205@oracle.com> I am getting very frustrated trying to do some simple work on my Mac using JDK 8. I touch *one* .java source file and I have to wait > 4 minutes for the build system which goes off and compiles everything. I have an SSD and i7 chip so I don't want to imagine what it would be like on a slower system : ## Starting jdk Compiling 10459 files for BUILD_JDK .... .... .... ## Finished jdk (build time 00:04:07) Why is it doing this ? -phil. From jonathan.gibbons at oracle.com Mon May 20 20:07:07 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 May 2013 13:07:07 -0700 Subject: Compiling 10459 java files when 1 is all that is needed. In-Reply-To: <519A81B1.9010205@oracle.com> References: <519A81B1.9010205@oracle.com> Message-ID: <519A826B.2030907@oracle.com> On 05/20/2013 01:04 PM, Phil Race wrote: > I am getting very frustrated trying to do some simple work > on my Mac using JDK 8. I touch *one* .java source file and > I have to wait > 4 minutes for the build system which goes > off and compiles everything. I have an SSD and i7 chip > so I don't want to imagine what it would be like on a slower > system : > > ## Starting jdk > Compiling 10459 files for BUILD_JDK > .... > .... > .... > ## Finished jdk (build time 00:04:07) > > Why is it doing this ? > > -phil. > > Phil, The plan is to get sjavac running reliably on all platforms and enabled by default. In the meantime, you can try it out by using --enable-sjavac when you run configure. -- Jon From philip.race at oracle.com Mon May 20 20:26:45 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 May 2013 13:26:45 -0700 Subject: Compiling 10459 java files when 1 is all that is needed. In-Reply-To: <519A826B.2030907@oracle.com> References: <519A81B1.9010205@oracle.com> <519A826B.2030907@oracle.com> Message-ID: <519A8705.3070204@oracle.com> Jon, That should make it faster but does it fix what seems like non-existent dependency analysis in the build ? -phil. On 5/20/2013 1:07 PM, Jonathan Gibbons wrote: > On 05/20/2013 01:04 PM, Phil Race wrote: >> I am getting very frustrated trying to do some simple work >> on my Mac using JDK 8. I touch *one* .java source file and >> I have to wait > 4 minutes for the build system which goes >> off and compiles everything. I have an SSD and i7 chip >> so I don't want to imagine what it would be like on a slower >> system : >> >> ## Starting jdk >> Compiling 10459 files for BUILD_JDK >> .... >> .... >> .... >> ## Finished jdk (build time 00:04:07) >> >> Why is it doing this ? >> >> -phil. >> >> > > Phil, > > The plan is to get sjavac running reliably on all platforms > and enabled by default. > > In the meantime, you can try it out by using --enable-sjavac > when you run configure. > > -- Jon From Sergey.Bylokhov at oracle.com Mon May 20 21:44:08 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 May 2013 01:44:08 +0400 Subject: Compiling 10459 java files when 1 is all that is needed. In-Reply-To: <519A81B1.9010205@oracle.com> References: <519A81B1.9010205@oracle.com> Message-ID: <519A9928.9030602@oracle.com> Hi, Phil. You can try to use filter option: For example: make JDK_FILTER=sun/java2d/loops On 21.05.2013 0:04, Phil Race wrote: > I am getting very frustrated trying to do some simple work > on my Mac using JDK 8. I touch *one* .java source file and > I have to wait > 4 minutes for the build system which goes > off and compiles everything. I have an SSD and i7 chip > so I don't want to imagine what it would be like on a slower > system : > > ## Starting jdk > Compiling 10459 files for BUILD_JDK > .... > .... > .... > ## Finished jdk (build time 00:04:07) > > Why is it doing this ? > > -phil. > > -- Best regards, Sergey. From philip.race at oracle.com Mon May 20 21:55:26 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 20 May 2013 14:55:26 -0700 Subject: Compiling 10459 java files when 1 is all that is needed. In-Reply-To: <519A9928.9030602@oracle.com> References: <519A81B1.9010205@oracle.com> <519A9928.9030602@oracle.com> Message-ID: <519A9BCE.80707@oracle.com> That helps a *lot* ! Only 84 files being compiled for my case. -phil. On 5/20/2013 2:44 PM, Sergey Bylokhov wrote: > Hi, Phil. > You can try to use filter option: > For example: > make JDK_FILTER=sun/java2d/loops > > On 21.05.2013 0:04, Phil Race wrote: >> I am getting very frustrated trying to do some simple work >> on my Mac using JDK 8. I touch *one* .java source file and >> I have to wait > 4 minutes for the build system which goes >> off and compiles everything. I have an SSD and i7 chip >> so I don't want to imagine what it would be like on a slower >> system : >> >> ## Starting jdk >> Compiling 10459 files for BUILD_JDK >> .... >> .... >> .... >> ## Finished jdk (build time 00:04:07) >> >> Why is it doing this ? >> >> -phil. >> >> > > From tim.bell at oracle.com Mon May 20 21:58:40 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 20 May 2013 14:58:40 -0700 Subject: Compiling 10459 java files when 1 is all that is needed. In-Reply-To: <519A8705.3070204@oracle.com> References: <519A81B1.9010205@oracle.com> <519A826B.2030907@oracle.com> <519A8705.3070204@oracle.com> Message-ID: <519A9C90.8050804@oracle.com> Phil: > That should make it faster but does it fix what seems like > non-existent dependency analysis in the build ? sjavac will be the tool providing that accurate dependency analysis. It is perfectly positioned to understand what needs to be done. Tim > -phil. > > On 5/20/2013 1:07 PM, Jonathan Gibbons wrote: >> On 05/20/2013 01:04 PM, Phil Race wrote: >>> I am getting very frustrated trying to do some simple work >>> on my Mac using JDK 8. I touch *one* .java source file and >>> I have to wait > 4 minutes for the build system which goes >>> off and compiles everything. I have an SSD and i7 chip >>> so I don't want to imagine what it would be like on a slower >>> system : >>> >>> ## Starting jdk >>> Compiling 10459 files for BUILD_JDK >>> .... >>> .... >>> .... >>> ## Finished jdk (build time 00:04:07) >>> >>> Why is it doing this ? >>> >>> -phil. >>> >>> >> >> Phil, >> >> The plan is to get sjavac running reliably on all platforms >> and enabled by default. >> >> In the meantime, you can try it out by using --enable-sjavac >> when you run configure. >> >> -- Jon > From jonathan.gibbons at oracle.com Mon May 20 22:03:03 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 20 May 2013 15:03:03 -0700 Subject: Compiling 10459 java files when 1 is all that is needed. In-Reply-To: <519A8705.3070204@oracle.com> References: <519A81B1.9010205@oracle.com> <519A826B.2030907@oracle.com> <519A8705.3070204@oracle.com> Message-ID: <519A9D97.4030102@oracle.com> On 05/20/2013 01:26 PM, Phil Race wrote: > Jon, > > That should make it faster but does it fix what seems like > non-existent dependency analysis in the build ? > > -phil. > > On 5/20/2013 1:07 PM, Jonathan Gibbons wrote: >> On 05/20/2013 01:04 PM, Phil Race wrote: >>> I am getting very frustrated trying to do some simple work >>> on my Mac using JDK 8. I touch *one* .java source file and >>> I have to wait > 4 minutes for the build system which goes >>> off and compiles everything. I have an SSD and i7 chip >>> so I don't want to imagine what it would be like on a slower >>> system : >>> >>> ## Starting jdk >>> Compiling 10459 files for BUILD_JDK >>> .... >>> .... >>> .... >>> ## Finished jdk (build time 00:04:07) >>> >>> Why is it doing this ? >>> >>> -phil. >>> >>> >> >> Phil, >> >> The plan is to get sjavac running reliably on all platforms >> and enabled by default. >> >> In the meantime, you can try it out by using --enable-sjavac >> when you run configure. >> >> -- Jon > Yes, sjavac does package-level dependency analysis. -- Jon From david.holmes at oracle.com Tue May 21 05:00:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 15:00:53 +1000 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <5198E277.9090202@oracle.com> References: <5198E277.9090202@oracle.com> Message-ID: <519AFF85.9030602@oracle.com> Hi Alan, That log looks correct to me. can you verify if the missing types are indeed within: /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar ? David On 20/05/2013 12:32 AM, Alan Bateman wrote: > > I've have an up-to-date clone of jdk8/tl + a patch to code in the jdk > repository that makes use of APIs that are new in jdk8. It builds/run > happily on all platforms except Mac where it needs to build JObjC.jar. > > Attached is the tail of "make LOG=trace" where it looks like JObjC.jar > involves compiling jdk8 classes with -source/target 1.5. In this case > the boot JDK is an update to date build of jdk7u-dev. > > Does anyone have any insight in how JObjC.jar should be built? I > remember Dan Xu ran into something similar recently with @Native and I > suspect this is the same underlying issue (in Dan's case then the code > didn't need @Native). > > Thanks, > > -Alan > > > Compiling 886 files for BUILD_JOBJC( > /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/bin/javac -source > 1.5 -target 1.5 -g -bootclasspath > /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar -cp > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/../langtools/dist/lib/classes.jar > -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > -implicit:none -sourcepath > "/u/alanb/ws/tl/jdk/src/macosx/native/jobjc/src/core/java:/u/alanb/ws/tl/jdk/src/macosx/native/jobjc/src/runtime-additions/java:/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc" > -d > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes > @/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch.tmp > && /bin/mv > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch.tmp > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch) > > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:34: > error: cannot find symbol > import java.util.Spliterator; > ^ > symbol: class Spliterator > location: package java.util > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:35: > error: package java.util.stream does not exist > import java.util.stream.StreamSupport; > ^ > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:36: > error: package java.util.stream does not exist > import java.util.stream.IntStream; > ^ > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1481: > error: cannot find symbol > public IntStream chars() { > ^ > symbol: class IntStream > location: class CharBuffer > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1482: > error: cannot find symbol > CharBufferSpliterator spliterator = new > CharBufferSpliterator(this); > ^ > symbol: class CharBufferSpliterator > location: class CharBuffer > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1482: > error: cannot find symbol > CharBufferSpliterator spliterator = new > CharBufferSpliterator(this); > ^ > symbol: class CharBufferSpliterator > location: class CharBuffer > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc/java/nio/CharBuffer.java:1483: > error: cannot find symbol > return StreamSupport.intStream(spliterator); > ^ > symbol: variable StreamSupport > location: class CharBuffer > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 7 errors > make[2]: *** > [/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] > Error 1 > make[1]: *** [classes-only] Error 2 > make: *** [jdk-only] Error 2 From Alan.Bateman at oracle.com Tue May 21 07:15:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2013 08:15:28 +0100 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519AFF85.9030602@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> Message-ID: <519B1F10.6090400@oracle.com> On 21/05/2013 06:00, David Holmes wrote: > Hi Alan, > > That log looks correct to me. can you verify if the missing types are > indeed within: > > /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar > > ? > > David > That's the boot JDK so it isn't going to have types that are new in jdk8. So I think the issue that both jdk8 classes and apple classes used by jobjc are be generated to gensrc. It just happened to work previously because gensrc/** didn't reference anything that is new in jdk8. -Alan. From david.holmes at oracle.com Tue May 21 07:36:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 17:36:19 +1000 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B1F10.6090400@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> Message-ID: <519B23F3.1090700@oracle.com> On 21/05/2013 5:15 PM, Alan Bateman wrote: > On 21/05/2013 06:00, David Holmes wrote: >> Hi Alan, >> >> That log looks correct to me. can you verify if the missing types are >> indeed within: >> >> /u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar >> >> ? >> >> David >> > That's the boot JDK so it isn't going to have types that are new in Doh! Sorry it looked like something you had built (well maybe you did). > jdk8. So I think the issue that both jdk8 classes and apple classes used > by jobjc are be generated to gensrc. It just happened to work previously > because gensrc/** didn't reference anything that is new in jdk8. While that is probably true, it seems to me that the cause of the problem here is that the javac source path includes /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc - and that seems wrong to me. It comes from CompileJavaClasses.gmk: $(eval $(call SetupJavaCompilation,BUILD_JOBJC,\ SETUP:=GENERATE_15BYTECODE,\ DISABLE_SJAVAC:=true,\ SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ $(JDK_OUTPUTDIR)/gensrc, \ INCLUDES := com/apple/jobjc,\ EXCLUDES := tests/java/com/apple/jobjc,\ BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ JAR:=$(JDK_OUTPUTDIR)/lib/JObjC.jar, \ JARINDEX := true)) No idea why JObjC.jar has to be built as 1.5. But in that case it should be able to compile against the boot JDK and not put gensrc on the sourcepath. (Maybe it was meant to be gensrc_jobjc/src ?) David ----- > -Alan. > > From volker.simonis at gmail.com Tue May 21 08:28:03 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 May 2013 10:28:03 +0200 Subject: Why is CUPS required? In-Reply-To: <1369043863.4924.17.camel@nomada> References: <1369043863.4924.17.camel@nomada> Message-ID: Hi Victor, actually you only need the CUPS headers, so the dependencies on CUPS are really not a big problem, even on exotic platforms. Just download and unpack cups (e.g. http://www.cups.org/software.php?VERSION=1.6.2&FILE=1.6.1/cups-1.6.1-source.tar.gz) unpack it, create a symlink in the created directory (i.e. cd cups-1.6.1 && ln -s . include) and point configure to it (i.e. --with-cups=cups-1-6-1). That's it. You can use the same include files for different platform builds if you copy them to a network share. Regards, Volker On Mon, May 20, 2013 at 11:57 AM, Victor Lavaud wrote: > Hello, > I find it intriguing that ./configure fails when it cannot find CUPS, > and I wonder if this is because I did something wrong, or the configure > script is not flexible enough, or the underlying source code cannot work > without cups. > I believe there is a number of cases where CUPS has no reason to be > present: servers, printerless computers. > Other Java implementations don?t require it either. > > Cheers, > Victor > From volker.simonis at gmail.com Tue May 21 08:38:53 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 May 2013 10:38:53 +0200 Subject: Windows configure "issues" In-Reply-To: References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> Message-ID: As you noticed, Visual Studio Express only contains the 32-bit Compiler. You have to download and install the "Windows SDK for Windows 7 and .NET Framework 4" from http://www.microsoft.com/download/en/details.aspx?id=8279to get the 64-bit compiler (this will also install the IA64 cross compiler just in case your keen on a real adventure:) Regards, Volker On Mon, May 20, 2013 at 3:04 PM, David Chase wrote: > In addition, the instructions must note that if the Express compiler is > used, the 64-bit compiler is (apparently, according to configure) not > provided, and hence --with-target-bits=32 is required. > > David > > From Alan.Bateman at oracle.com Tue May 21 08:47:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2013 09:47:31 +0100 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B23F3.1090700@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> Message-ID: <519B34A3.4030805@oracle.com> On 21/05/2013 08:36, David Holmes wrote: > > While that is probably true, it seems to me that the cause of the > problem here is that the javac source path includes > /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc - > and that seems wrong to me. It comes from CompileJavaClasses.gmk: > > $(eval $(call SetupJavaCompilation,BUILD_JOBJC,\ > SETUP:=GENERATE_15BYTECODE,\ > DISABLE_SJAVAC:=true,\ > > SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ > > $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ > $(JDK_OUTPUTDIR)/gensrc, \ > INCLUDES := com/apple/jobjc,\ > EXCLUDES := tests/java/com/apple/jobjc,\ > BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ > JAR:=$(JDK_OUTPUTDIR)/lib/JObjC.jar, \ > JARINDEX := true)) > > > No idea why JObjC.jar has to be built as 1.5. But in that case it > should be able to compile against the boot JDK and not put gensrc on > the sourcepath. (Maybe it was meant to be gensrc_jobjc/src ?) It seems to include gensrc because that is where com.apple.jobjc.** is generated. I also do not know why this is built as 1.5. I think we need someone familiar with jobjc to provide an overview on its usage. -Alan From erik.joelsson at oracle.com Tue May 21 09:18:03 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2013 11:18:03 +0200 Subject: MacOS build tool selections for JDK8 In-Reply-To: <51945E20.2000600@oracle.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> <519426C6.5030702@oracle.com> <51945E20.2000600@oracle.com> Message-ID: <519B3BCB.5040203@oracle.com> On 2013-05-16 06:18, David Holmes wrote: > On 16/05/2013 10:22 AM, David Katleman wrote: >> >> On 5/13/2013 8:59 AM, David DeHaven wrote: >>> If it were my choice, Mac OS X 10.8 would be the base OS with Xcode >>> 4.6.1 (current) with clang as the officially supported compiler and >>> with an option to use gcc. I don't see why that would't last at least >>> the public lifecycle of JDK8. What I would be more concerned with is >>> the apparent drift from what we know as Mac OS X towards something >>> more iOS-like, that could mean libraries and frameworks we depend on >>> no longer being available, but at that point it wouldn't be the same >>> OS and we'd have to re-evaluate anyways. Sort of like what's happening >>> with Windows 8 right now. >> >> Sorry for what may be considered muddying the waters, since this is a >> JDK8 discussion. >> >> What about JDK7 update builds? We currently use the same set of macosx >> hardware for both 7u & 8. Does JPRT / others do so as well, or do >> they maintain separate systems for 7u. > > JPRT as far as I know only uses 10.7 systems for builds. The 10.8 > systems can only be used for testing. Since we have added the compiler and link args described earlier in this thread to jdk8 makefiles, I believe we have enabled 10.8 for building jdk8 too now. At least we intend to. /Erik > > David > >> Dave >> From erik.joelsson at oracle.com Tue May 21 09:44:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2013 11:44:54 +0200 Subject: Windows configure "issues" In-Reply-To: References: Message-ID: <519B4216.4080307@oracle.com> On 2013-05-19 22:58, David Chase wrote: > This is for Windows 7, following instructions, mostly vanilla. > I restarted after all the various installations. > I'm "following" the instructions at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html > > The non-vanilla step, inspired by the cautionary warnings about paths with spaces in them and cygwin, was to install Java and VS10 express in C:\PFx86, not C:\Program Files. > > > #1, after setting the path explicitly, it was ignored and "not found". > > $ bash configure --with-boot-jdk=$J --with-tools-dir="C:\\PFx86\\MVS10.0\\VC\\bin" > > configure: Found Visual Studio installation at /cygdrive/c/PFx86/MVS10.0/ using VS100COMNTOOLS variable > configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring > configure: Found Visual Studio installation at /cygdrive/c/Program Files/Microsoft Visual Studio 10.0 using well-known name > configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring > configure: Cannot locate a valid Visual Studio installation, checking current environment > checking for Visual Studio variables... not found > configure: Cannot locate a valid Visual Studio or Windows SDK installation on disk, > configure: nor is this script run from a Visual Studio command prompt. > configure: Try setting --with-tools-dir to the VC/bin directory within the VS installation > configure: or run "bash.exe -l" from a VS command prompt and then run configure from there. > configure: error: Cannot continue > configure exiting with result code 1 > > My understanding of what happened is that it found, both from the tools dir and from the environment variable, an Express install, but because it was an Express install it kept looking, and was misled by something dribbled in Program Files by my non-standard-installation-location install, and did not then backtrack to the perfectly good Express install that I instructed it to use. > > I told it exactly what to do, in exactly the way that I was instructed, and it ignored my good advice. If the answer is "fails if not installed in the default location, even if you direct it to the non-default location" (i.e., ProgramSPACEFiles, despite our worrying language about the dangers of SPACEs in paths), then we should be sure to say so. > Configure looks for visual studio (and windows SDK) installs and tries to run the vcvars*.bat to get the environment necessary to build. In this case it couldn't find the bat file where it was expected to be. Probably because it looked for the 64bit version of the file when there was only a 32bit install of visual studio. If that's the case, we should add a better fail message since 64bit build is normally the default. As noted by Volker, this can be solved by installing the correct windows SDK which will provide the 64bit compiler. > #2, if you fire up a Visual Studio command prompt and say "bash.exe -l", it will not find it and will not run it. > If you naively attempt to reverse engineer the "which base" from your Cygwin window, you will be lead astray and go looking for C:\cygwin\usr\bin\bash.exe", which does not exist. > What does exist, what you should tell people to type, and what works, is: C:\cygwin\bin\bash.exe . > So the instructions should say that, instead. > > However, once reverse-engineered, it did seem work (if this is working): > > configure: Found Visual Studio installation at /cygdrive/c/PFx86/MVS10.0/ using VS100COMNTOOLS variable > configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring > configure: Found Visual Studio installation at /cygdrive/c/Program Files/Microsoft Visual Studio 10.0 using well-known name > configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably Visual Studio Express. Ignoring > configure: Cannot locate a valid Visual Studio installation, checking current environment > checking for Visual Studio variables... ok > checking for msvcr100.dll... configure: Warning: msvcr100.dll not found in VCINSTALLDIR: C:\PFx86\MVS10.0\VC\ > configure: msvcr100.dll found in C:\windows/system32 > C:\windows/system32/msvcr100.dll > configure: Rewriting MSVCR_DLL to "/cygdrive/c/windows/system32/msvcr100.dll" > This is a possible workaround. Where did you read the "bash.exe -l" instruction? > #3, the DirectX 9.0 link is not maybe dead, it is dead. > The search for "DirectX 9.0 SDK Update Summer 2004" is also dead; nothing is found. > Searches for "DirectX 9" yield downloads that are not SDKs, searches for "DirectX 9 SDK" and "DirectX 9.0 SDK" leads to SDKs that are not version 9. > > Does it still work with somewhat newer (e.g., April 2006, version "DX")? > http://www.microsoft.com/en-us/download/details.aspx?id=24982 > If it does, we should say so, because currently the instructions lead to dead ends. > Unfortunately Microsoft is no longer distributing this version of the directx SDK and unfortunately it's still the officially supported SDK by OpenJDK. It will still build with newer versions (Technically it will still build with the directx sdk bundled with VS2010, but configure won't let you do that anymore without being tricked), but there will be the potential for bugs. The choice of supported directx sdk dependencies should be discussed with the engineering team using it. /Erik > David > From erik.joelsson at oracle.com Tue May 21 09:47:33 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2013 11:47:33 +0200 Subject: Windows configure "issues" In-Reply-To: <519B4216.4080307@oracle.com> References: <519B4216.4080307@oracle.com> Message-ID: <519B42B5.8000606@oracle.com> On 2013-05-21 11:44, Erik Joelsson wrote: > > > On 2013-05-19 22:58, David Chase wrote: >> This is for Windows 7, following instructions, mostly vanilla. >> I restarted after all the various installations. >> I'm "following" the instructions at >> http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html >> >> The non-vanilla step, inspired by the cautionary warnings about paths >> with spaces in them and cygwin, was to install Java and VS10 express >> in C:\PFx86, not C:\Program Files. >> >> >> #1, after setting the path explicitly, it was ignored and "not found". >> >> $ bash configure --with-boot-jdk=$J >> --with-tools-dir="C:\\PFx86\\MVS10.0\\VC\\bin" >> >> configure: Found Visual Studio installation at >> /cygdrive/c/PFx86/MVS10.0/ using VS100COMNTOOLS variable >> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is >> probably Visual Studio Express. Ignoring >> configure: Found Visual Studio installation at /cygdrive/c/Program >> Files/Microsoft Visual Studio 10.0 using well-known name >> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is >> probably Visual Studio Express. Ignoring >> configure: Cannot locate a valid Visual Studio installation, checking >> current environment >> checking for Visual Studio variables... not found >> configure: Cannot locate a valid Visual Studio or Windows SDK >> installation on disk, >> configure: nor is this script run from a Visual Studio command prompt. >> configure: Try setting --with-tools-dir to the VC/bin directory >> within the VS installation >> configure: or run "bash.exe -l" from a VS command prompt and then run >> configure from there. >> configure: error: Cannot continue >> configure exiting with result code 1 >> >> My understanding of what happened is that it found, both from the >> tools dir and from the environment variable, an Express install, but >> because it was an Express install it kept looking, and was misled by >> something dribbled in Program Files by my >> non-standard-installation-location install, and did not then >> backtrack to the perfectly good Express install that I instructed it >> to use. >> >> I told it exactly what to do, in exactly the way that I was >> instructed, and it ignored my good advice. If the answer is "fails >> if not installed in the default location, even if you direct it to >> the non-default location" (i.e., ProgramSPACEFiles, despite our >> worrying language about the dangers of SPACEs in paths), then we >> should be sure to say so. >> > Configure looks for visual studio (and windows SDK) installs and tries > to run the vcvars*.bat to get the environment necessary to build. In > this case it couldn't find the bat file where it was expected to be. > Probably because it looked for the 64bit version of the file when > there was only a 32bit install of visual studio. If that's the case, > we should add a better fail message since 64bit build is normally the > default. As noted by Volker, this can be solved by installing the > correct windows SDK which will provide the 64bit compiler. >> #2, if you fire up a Visual Studio command prompt and say "bash.exe >> -l", it will not find it and will not run it. >> If you naively attempt to reverse engineer the "which base" from your >> Cygwin window, you will be lead astray and go looking for >> C:\cygwin\usr\bin\bash.exe", which does not exist. >> What does exist, what you should tell people to type, and what works, >> is: C:\cygwin\bin\bash.exe . >> So the instructions should say that, instead. >> >> However, once reverse-engineered, it did seem work (if this is working): >> >> configure: Found Visual Studio installation at >> /cygdrive/c/PFx86/MVS10.0/ using VS100COMNTOOLS variable >> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is >> probably Visual Studio Express. Ignoring >> configure: Found Visual Studio installation at /cygdrive/c/Program >> Files/Microsoft Visual Studio 10.0 using well-known name >> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is >> probably Visual Studio Express. Ignoring >> configure: Cannot locate a valid Visual Studio installation, checking >> current environment >> checking for Visual Studio variables... ok >> checking for msvcr100.dll... configure: Warning: msvcr100.dll not >> found in VCINSTALLDIR: C:\PFx86\MVS10.0\VC\ >> configure: msvcr100.dll found in C:\windows/system32 >> C:\windows/system32/msvcr100.dll >> configure: Rewriting MSVCR_DLL to >> "/cygdrive/c/windows/system32/msvcr100.dll" >> > This is a possible workaround. Where did you read the "bash.exe -l" > instruction? >> #3, the DirectX 9.0 link is not maybe dead, it is dead. >> The search for "DirectX 9.0 SDK Update Summer 2004" is also dead; >> nothing is found. >> Searches for "DirectX 9" yield downloads that are not SDKs, searches >> for "DirectX 9 SDK" and "DirectX 9.0 SDK" leads to SDKs that are not >> version 9. >> >> Does it still work with somewhat newer (e.g., April 2006, version "DX")? >> http://www.microsoft.com/en-us/download/details.aspx?id=24982 >> If it does, we should say so, because currently the instructions lead >> to dead ends. >> > Unfortunately Microsoft is no longer distributing this version of the > directx SDK and unfortunately it's still the officially supported SDK > by OpenJDK. It will still build with newer versions (Technically it > will still build with the directx sdk bundled with VS2010, but > configure won't let you do that anymore without being tricked), but > there will be the potential for bugs. The choice of supported directx > sdk dependencies should be discussed with the engineering team using it. Note that the installer for this sdk can be found on /java/devtools if you are on Oracles network. /Erik > > /Erik >> David >> From erik.joelsson at oracle.com Tue May 21 09:53:23 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2013 11:53:23 +0200 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B34A3.4030805@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> Message-ID: <519B4413.7000000@oracle.com> In the old build, JObjC.jar was built completely differently from all other java classes, by an ant script. We kept the source/target 1.5 when converting to the new build to keep the builds equal. I very much doubt there is a reason for it now though. It looks like left over legacy to me. The simplest fix for you would be to change the outputdir of the generated sources for jobjc to something like gensrc_jobjc. I would really like to see the whole special handling of jobjc compilation removed. /Erik On 2013-05-21 10:47, Alan Bateman wrote: > On 21/05/2013 08:36, David Holmes wrote: >> >> While that is probably true, it seems to me that the cause of the >> problem here is that the javac source path includes >> /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc >> - and that seems wrong to me. It comes from CompileJavaClasses.gmk: >> >> $(eval $(call SetupJavaCompilation,BUILD_JOBJC,\ >> SETUP:=GENERATE_15BYTECODE,\ >> DISABLE_SJAVAC:=true,\ >> >> SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ >> >> $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ >> $(JDK_OUTPUTDIR)/gensrc, \ >> INCLUDES := com/apple/jobjc,\ >> EXCLUDES := tests/java/com/apple/jobjc,\ >> BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ >> JAR:=$(JDK_OUTPUTDIR)/lib/JObjC.jar, \ >> JARINDEX := true)) >> >> >> No idea why JObjC.jar has to be built as 1.5. But in that case it >> should be able to compile against the boot JDK and not put gensrc on >> the sourcepath. (Maybe it was meant to be gensrc_jobjc/src ?) > It seems to include gensrc because that is where com.apple.jobjc.** is > generated. I also do not know why this is built as 1.5. I think we > need someone familiar with jobjc to provide an overview on its usage. > > -Alan From david.r.chase at oracle.com Tue May 21 10:43:28 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 21 May 2013 06:43:28 -0400 Subject: Windows configure "issues" In-Reply-To: References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> Message-ID: <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> I saw that and tried that, but it declared that "you must be Administrator to install this". I thought I was, I as installing all sorts of other software, but no go. I found your instructions, but they weren't Oracle-sourced instructions, so it seemed like it was not my problem. This is not just a matter of "I'm blocked, please help me", this is also "anyone out there trying to follow these instructions will fail, we must fix this". On 2013-05-21, at 4:38 AM, Volker Simonis wrote: > As you noticed, Visual Studio Express only contains the 32-bit Compiler. You have to download and install the "Windows SDK for Windows 7 and .NET Framework 4" from http://www.microsoft.com/download/en/details.aspx?id=8279 to get the 64-bit compiler (this will also install the IA64 cross compiler just in case your keen on a real adventure:) > > Regards, > Volker > > > > On Mon, May 20, 2013 at 3:04 PM, David Chase wrote: > In addition, the instructions must note that if the Express compiler is used, the 64-bit compiler is (apparently, according to configure) not provided, and hence --with-target-bits=32 is required. > > David > > From david.holmes at oracle.com Tue May 21 10:50:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2013 20:50:27 +1000 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B4413.7000000@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> <519B4413.7000000@oracle.com> Message-ID: <519B5173.4010805@oracle.com> On 21/05/2013 7:53 PM, Erik Joelsson wrote: > In the old build, JObjC.jar was built completely differently from all > other java classes, by an ant script. We kept the source/target 1.5 when > converting to the new build to keep the builds equal. I very much doubt > there is a reason for it now though. It looks like left over legacy to me. > > The simplest fix for you would be to change the outputdir of the > generated sources for jobjc to something like gensrc_jobjc. From what I can see though the output directory is intended to be gensrc_jobc, but somehow the com/java/jobc classes get generated into gensrc - though I can't see where. David ----- > I would really like to see the whole special handling of jobjc > compilation removed. > > /Erik > > On 2013-05-21 10:47, Alan Bateman wrote: >> On 21/05/2013 08:36, David Holmes wrote: >>> >>> While that is probably true, it seems to me that the cause of the >>> problem here is that the javac source path includes >>> /u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc - >>> and that seems wrong to me. It comes from CompileJavaClasses.gmk: >>> >>> $(eval $(call SetupJavaCompilation,BUILD_JOBJC,\ >>> SETUP:=GENERATE_15BYTECODE,\ >>> DISABLE_SJAVAC:=true,\ >>> SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ >>> >>> $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ >>> $(JDK_OUTPUTDIR)/gensrc, \ >>> INCLUDES := com/apple/jobjc,\ >>> EXCLUDES := tests/java/com/apple/jobjc,\ >>> BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ >>> JAR:=$(JDK_OUTPUTDIR)/lib/JObjC.jar, \ >>> JARINDEX := true)) >>> >>> >>> No idea why JObjC.jar has to be built as 1.5. But in that case it >>> should be able to compile against the boot JDK and not put gensrc on >>> the sourcepath. (Maybe it was meant to be gensrc_jobjc/src ?) >> It seems to include gensrc because that is where com.apple.jobjc.** is >> generated. I also do not know why this is built as 1.5. I think we >> need someone familiar with jobjc to provide an overview on its usage. >> >> -Alan From Alan.Bateman at oracle.com Tue May 21 11:30:33 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2013 12:30:33 +0100 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B4413.7000000@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> <519B4413.7000000@oracle.com> Message-ID: <519B5AD9.8040506@oracle.com> On 21/05/2013 10:53, Erik Joelsson wrote: > In the old build, JObjC.jar was built completely differently from all > other java classes, by an ant script. We kept the source/target 1.5 > when converting to the new build to keep the builds equal. I very much > doubt there is a reason for it now though. It looks like left over > legacy to me. > > The simplest fix for you would be to change the outputdir of the > generated sources for jobjc to something like gensrc_jobjc. > > I would really like to see the whole special handling of jobjc > compilation removed. > > /Erik It would be good to get this cleaned up or removed. For now I'm using the attached patch to ensure that the classes are generated to gensrc_jobjc. -Alan. diff -r b9b26b424bfc makefiles/CompileJavaClasses.gmk --- a/makefiles/CompileJavaClasses.gmk Sat May 18 18:55:56 2013 -0700 +++ b/makefiles/CompileJavaClasses.gmk Tue May 21 12:05:43 2013 +0100 @@ -342,7 +342,7 @@ DISABLE_SJAVAC:=true,\ SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ - $(JDK_OUTPUTDIR)/gensrc, \ + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ INCLUDES := com/apple/jobjc,\ EXCLUDES := tests/java/com/apple/jobjc,\ BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ @@ -355,7 +355,7 @@ SETUP:=GENERATE_JDKBYTECODE,\ SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ - $(JDK_OUTPUTDIR)/gensrc, \ + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ INCLUDES := com/apple/jobjc,\ EXCLUDES := tests/java/com/apple/jobjc,\ BIN:=$(JDK_OUTPUTDIR)/jobjc_classes_headers,\ dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff GensrcJ GensrcJDWP.gmk GensrcJObjC.gmk dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff GensrcJObjC.gmk diff -r b9b26b424bfc makefiles/GensrcJObjC.gmk --- a/makefiles/GensrcJObjC.gmk Sat May 18 18:55:56 2013 -0700 +++ b/makefiles/GensrcJObjC.gmk Tue May 21 12:05:52 2013 +0100 @@ -104,9 +104,9 @@ # The generator delets all files in the target dir so it has to work in its # own dir and have the files copied over to gensrc aftewards. -$(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files : $(JOBJC_TMP)/_the.generator +$(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files : $(JOBJC_TMP)/_the.generator $(MKDIR) -p $(@D) $(CP) -rp $(JOBJC_DST)/* $(@D) $(TOUCH) $@ -GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files +GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files From erik.joelsson at oracle.com Tue May 21 11:50:18 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2013 13:50:18 +0200 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B5AD9.8040506@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> <519B4413.7000000@oracle.com> <519B5AD9.8040506@oracle.com> Message-ID: <519B5F7A.3020802@oracle.com> Looks good to me. /Erik On 2013-05-21 13:30, Alan Bateman wrote: > On 21/05/2013 10:53, Erik Joelsson wrote: >> In the old build, JObjC.jar was built completely differently from all >> other java classes, by an ant script. We kept the source/target 1.5 >> when converting to the new build to keep the builds equal. I very >> much doubt there is a reason for it now though. It looks like left >> over legacy to me. >> >> The simplest fix for you would be to change the outputdir of the >> generated sources for jobjc to something like gensrc_jobjc. >> >> I would really like to see the whole special handling of jobjc >> compilation removed. >> >> /Erik > It would be good to get this cleaned up or removed. > > For now I'm using the attached patch to ensure that the classes are > generated to gensrc_jobjc. > > -Alan. > > > diff -r b9b26b424bfc makefiles/CompileJavaClasses.gmk > --- a/makefiles/CompileJavaClasses.gmk Sat May 18 18:55:56 2013 -0700 > +++ b/makefiles/CompileJavaClasses.gmk Tue May 21 12:05:43 2013 +0100 > @@ -342,7 +342,7 @@ > DISABLE_SJAVAC:=true,\ > SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ > > $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ > - $(JDK_OUTPUTDIR)/gensrc, \ > + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ > INCLUDES := com/apple/jobjc,\ > EXCLUDES := tests/java/com/apple/jobjc,\ > BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ > @@ -355,7 +355,7 @@ > SETUP:=GENERATE_JDKBYTECODE,\ > SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ > > $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ > - $(JDK_OUTPUTDIR)/gensrc, \ > + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ > INCLUDES := com/apple/jobjc,\ > EXCLUDES := tests/java/com/apple/jobjc,\ > BIN:=$(JDK_OUTPUTDIR)/jobjc_classes_headers,\ > dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ > dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ > dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff GensrcJ > GensrcJDWP.gmk GensrcJObjC.gmk > dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff > GensrcJObjC.gmk > diff -r b9b26b424bfc makefiles/GensrcJObjC.gmk > --- a/makefiles/GensrcJObjC.gmk Sat May 18 18:55:56 2013 -0700 > +++ b/makefiles/GensrcJObjC.gmk Tue May 21 12:05:52 2013 +0100 > @@ -104,9 +104,9 @@ > > # The generator delets all files in the target dir so it has to work > in its > # own dir and have the files copied over to gensrc aftewards. > -$(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files : $(JOBJC_TMP)/_the.generator > +$(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files : > $(JOBJC_TMP)/_the.generator > $(MKDIR) -p $(@D) > $(CP) -rp $(JOBJC_DST)/* $(@D) > $(TOUCH) $@ > > -GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files > +GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files From erik.joelsson at oracle.com Tue May 21 14:22:58 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 May 2013 16:22:58 +0200 Subject: RFR: 8014970: Use open man pages when DISABLE_COMMERCIAL_FEATURES=true Message-ID: <519B8342.1060000@oracle.com> Open part of this review. Moving logic for choosing open or oracle man pages to closed makefile. http://cr.openjdk.java.net/~erikj/8014970/webrev.jdk.01/ /Erik From volker.simonis at gmail.com Tue May 21 15:55:05 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 May 2013 17:55:05 +0200 Subject: Windows configure "issues" In-Reply-To: <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> Message-ID: On Tue, May 21, 2013 at 12:43 PM, David Chase wrote: > I saw that and tried that, but it declared that "you must be Administrator > to install this". I thought I was, I as installing all sorts of other > software, but no go. I found your instructions, but they weren't > Oracle-sourced instructions, so it seemed like it was not my problem. Sometimes "Oracle-sourced instructions" simply aren't the "silver bullet" :) This will hopefully change now that we have a usable Wiki. I always felt that having the build instructions checked in into the repository is somewhat to heavyweight. It should only contain a general build overview and link into the OpenJDK Wiki which can be updated more easily and more frequently and it can contain all the different peculiarities of each build platform (i.e. not only the few "official" Oracle ones). > This is not just a matter of "I'm blocked, please help me", this is also > "anyone out there trying to follow these instructions will fail, we must > fix this". > > On 2013-05-21, at 4:38 AM, Volker Simonis > wrote: > > > As you noticed, Visual Studio Express only contains the 32-bit Compiler. > You have to download and install the "Windows SDK for Windows 7 and .NET > Framework 4" from > http://www.microsoft.com/download/en/details.aspx?id=8279 to get the > 64-bit compiler (this will also install the IA64 cross compiler just in > case your keen on a real adventure:) > > > > Regards, > > Volker > > > > > > > > On Mon, May 20, 2013 at 3:04 PM, David Chase > wrote: > > In addition, the instructions must note that if the Express compiler is > used, the 64-bit compiler is (apparently, according to configure) not > provided, and hence --with-target-bits=32 is required. > > > > David > > > > > > From omajid at redhat.com Tue May 21 15:30:20 2013 From: omajid at redhat.com (Omair Majid) Date: Tue, 21 May 2013 11:30:20 -0400 Subject: RFR: 8014970: Use open man pages when DISABLE_COMMERCIAL_FEATURES=true In-Reply-To: <519B8342.1060000@oracle.com> References: <519B8342.1060000@oracle.com> Message-ID: <519B930C.4000508@redhat.com> On 05/21/2013 10:22 AM, Erik Joelsson wrote: > Open part of this review. Moving logic for choosing open or oracle man > pages to closed makefile. > > http://cr.openjdk.java.net/~erikj/8014970/webrev.jdk.01/ Looks okay to me. Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kellyohair at gmail.com Tue May 21 16:25:37 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Tue, 21 May 2013 09:25:37 -0700 Subject: Windows configure "issues" In-Reply-To: References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> Message-ID: <9FED93F9-6CF9-4758-8E30-D9CCFC45599F@gmail.com> A voice from the past rings out through the forests of repositories, squirting ancient wisdom into the clouds... ;^) Yes, yes, I have indeed gone insane. ;^) ---- The intent with the README-build.html document was as a purely "OpenJDK" document, there should be no "Oracle specific" instructions in it, that is the wrong place for it. Inside Oracle, there is another README-builds.html file that will refer to the OpenJDK one and provide additional Oracle specific information. The Oracle build people know where that is. Historically, I have tried in the past to only contain the kind of information that would help any user needing to build the OpenJDK. It might be that a wiki would be a better place, but at the time I created this file, keeping it in the repository made the most sense. So I tried to isolate all the information in this document (we had no wiki at that time). Anyone changing this document needs to be very careful, and know what they are doing, and being in a repository, requiring a bug id, and a reviewer, seemed to be the right level of control. My suggestion at this time, now that there is a wiki, would be to get this document down to the bare bones (so to speak), and have the wiki page provide details, e.g. "You need Visual Studio 2010, see wiki for details." So that changes to the wiki can be made quickly and as needed, but someone still needs to make sure the basic information is correct in this README-builds.html file, or get rid of it completely. Having the same detailed information in two places seems like a bad idea to me. --- I'll crawl back under my new job rock now, hope this provided some insight. -kto On May 21, 2013, at 8:55 AM, Volker Simonis wrote: > On Tue, May 21, 2013 at 12:43 PM, David Chase wrote: > >> I saw that and tried that, but it declared that "you must be Administrator >> to install this". I thought I was, I as installing all sorts of other >> software, but no go. I found your instructions, but they weren't >> Oracle-sourced instructions, so it seemed like it was not my problem. > > > Sometimes "Oracle-sourced instructions" simply aren't the "silver bullet" :) > > This will hopefully change now that we have a usable Wiki. I always felt > that having the build instructions checked in into the repository is > somewhat to heavyweight. It should only contain a general build overview > and link into the OpenJDK Wiki which can be updated more easily and more > frequently and it can contain all the different peculiarities of each build > platform (i.e. not only the few "official" Oracle ones). > > >> This is not just a matter of "I'm blocked, please help me", this is also >> "anyone out there trying to follow these instructions will fail, we must >> fix this". >> >> On 2013-05-21, at 4:38 AM, Volker Simonis >> wrote: >> >>> As you noticed, Visual Studio Express only contains the 32-bit Compiler. >> You have to download and install the "Windows SDK for Windows 7 and .NET >> Framework 4" from >> http://www.microsoft.com/download/en/details.aspx?id=8279 to get the >> 64-bit compiler (this will also install the IA64 cross compiler just in >> case your keen on a real adventure:) >>> >>> Regards, >>> Volker >>> >>> >>> >>> On Mon, May 20, 2013 at 3:04 PM, David Chase >> wrote: >>> In addition, the instructions must note that if the Express compiler is >> used, the 64-bit compiler is (apparently, according to configure) not >> provided, and hence --with-target-bits=32 is required. >>> >>> David >>> >>> >> >> From tim.bell at oracle.com Tue May 21 17:35:01 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 21 May 2013 10:35:01 -0700 Subject: RFR: 8014970: Use open man pages when DISABLE_COMMERCIAL_FEATURES=true In-Reply-To: <519B930C.4000508@redhat.com> References: <519B8342.1060000@oracle.com> <519B930C.4000508@redhat.com> Message-ID: <519BB045.5010203@oracle.com> On 05/21/13 08:30 AM, Omair Majid wrote: > On 05/21/2013 10:22 AM, Erik Joelsson wrote: >> Open part of this review. Moving logic for choosing open or oracle man >> pages to closed makefile. >> >> http://cr.openjdk.java.net/~erikj/8014970/webrev.jdk.01/ > Looks okay to me. > > Cheers, > Omair Looks good to me as well. Tim From erik.joelsson at oracle.com Tue May 21 18:14:13 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 21 May 2013 18:14:13 +0000 Subject: hg: jdk8/build: 8014508: Fix log levels in make Message-ID: <20130521181414.1249048C06@hg.openjdk.java.net> Changeset: eea249c1ecee Author: erikj Date: 2013-05-21 13:18 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/eea249c1ecee 8014508: Fix log levels in make Reviewed-by: tbell ! NewMakefile.gmk ! common/autoconf/spec.gmk.in From erik.joelsson at oracle.com Tue May 21 18:14:27 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 21 May 2013 18:14:27 +0000 Subject: hg: jdk8/build/jdk: 8011346: build-infra: While Constructing Javadoc information, JSpinner.java error: package sun.util.locale.provider does not exist Message-ID: <20130521181450.24C6F48C07@hg.openjdk.java.net> Changeset: 2868607646a0 Author: erikj Date: 2013-05-21 17:02 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2868607646a0 8011346: build-infra: While Constructing Javadoc information, JSpinner.java error: package sun.util.locale.provider does not exist Reviewed-by: dholmes, tbell, naoto ! makefiles/GensrcSwing.gmk From kellyohair at gmail.com Tue May 21 18:48:59 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Tue, 21 May 2013 11:48:59 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <519B3BCB.5040203@oracle.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> <519426C6.5030702@oracle.com> <51945E20.2000600@oracle.com> <519B3BCB.5040203@oracle.com> Message-ID: <3C365036-CE8C-46AE-9049-EEC17B119BE6@gmail.com> On May 21, 2013, at 2:18 AM, Erik Joelsson wrote: >> JPRT as far as I know only uses 10.7 systems for builds. The 10.8 systems can only be used for testing. > Since we have added the compiler and link args described earlier in this thread to jdk8 makefiles, I believe we have enabled 10.8 for building jdk8 too now. At least we intend to. Careful with this. The jdk7u builds/makefiles probably still need a 10.7 system. With no access to JPRT sources anymore, I can't remember all details, but just declaring 10.8 systems able to build 10.7 might not work for jdk7u jobs. Can't remember if I had a solution for this, kind of expected the jdk7u makefiles to get changed, but I kind of doubt that happened. :^( -kto From aph at redhat.com Tue May 21 19:00:09 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 May 2013 20:00:09 +0100 Subject: Windows configure "issues" In-Reply-To: References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> Message-ID: <519BC439.3050201@redhat.com> On 05/21/2013 04:55 PM, Volker Simonis wrote: > I always felt that having the build instructions checked in into the > repository is somewhat to heavyweight. There are two good reasons to do this. Firstly, it's a free software tradition: I expect to find a README with build instructions in the repo. Secondly, the build instructions will change over time, so of they're on a Wiki there will have to be multiple versions. Andrew. From gnu.andrew at redhat.com Tue May 21 18:31:56 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 May 2013 14:31:56 -0400 (EDT) Subject: [PATCH] Provide debugging information for programs In-Reply-To: <145725342.5458499.1369157837984.JavaMail.root@redhat.com> Message-ID: <434361871.5475325.1369161116141.JavaMail.root@redhat.com> Hi all, The following webrevs: Root: http://cr.openjdk.java.net/~andrew/build/debugging/webrev.02/ JDK: http://cr.openjdk.java.net/~andrew/build/debugging/webrev.03/ 1. Enable debugging on programs for OpenJDK builds (unclear why this is disabled; the comment says "Programs don't get the debug symbols added in the old build. It's not clear if this is intentional" but all our builds of 6 & 7 have debug info, making this a regression) 2. Turn on debugging symbols for unpack200 and jexec which seem to have been missed. Ok? If so, can I have a bug ID for this, please? Thanks, -- 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 david.dehaven at oracle.com Tue May 21 19:03:52 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 21 May 2013 12:03:52 -0700 Subject: MacOS build tool selections for JDK8 In-Reply-To: <3C365036-CE8C-46AE-9049-EEC17B119BE6@gmail.com> References: <518D71D1.3080706@oracle.com> <34717EF6-69E0-4547-B53C-CACBF24FBCAE@oracle.com> <8D7B4B14-AA37-42BF-B8B7-F8AED8C0FCEB@oracle.com> <519426C6.5030702@oracle.com> <51945E20.2000600@oracle.com> <519B3BCB.5040203@oracle.com> <3C365036-CE8C-46AE-9049-EEC17B119BE6@gmail.com> Message-ID: <99ADDF5E-EAFF-42AC-B844-7E7D0918A6B9@oracle.com> >>> JPRT as far as I know only uses 10.7 systems for builds. The 10.8 systems can only be used for testing. >> Since we have added the compiler and link args described earlier in this thread to jdk8 makefiles, I believe we have enabled 10.8 for building jdk8 too now. At least we intend to. > > Careful with this. The jdk7u builds/makefiles probably still need a 10.7 system. > With no access to JPRT sources anymore, I can't remember all details, but just declaring 10.8 systems > able to build 10.7 might not work for jdk7u jobs. Can't remember if I had a solution for this, > kind of expected the jdk7u makefiles to get changed, but I kind of doubt that happened. :^( No, 7u has not been changed. At least, whenever I need to have someone test a fix, they have to test on 10.8 :) -DrD- From volker.simonis at gmail.com Tue May 21 19:17:35 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 May 2013 21:17:35 +0200 Subject: Windows configure "issues" In-Reply-To: <519BC439.3050201@redhat.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> Message-ID: On Tue, May 21, 2013 at 9:00 PM, Andrew Haley wrote: > On 05/21/2013 04:55 PM, Volker Simonis wrote: > > > I always felt that having the build instructions checked in into the > > repository is somewhat to heavyweight. > > There are two good reasons to do this. > > Firstly, it's a free software tradition: I expect to find a README with > build instructions in the repo. Secondly, the build instructions will > change over time, so of they're on a Wiki there will have to be > multiple versions. > > You're right, but the problem is that the process of updating the instructions is much too heavyweight (getting a BugID, getting reviews, getting a sponsor who will push the changes,..). The other problem is that there exist so many different OS releases/distributions and compiler versions which people may use for building that I'm afraid the "official" README in the repo will never cover them all. So I'd rather take a pragmatic approach of having more build documentation in a central place in the Wiki than having a super-accurate documentation in the repository for a system nobody can even set up today (e.g. because the software mentioned there isn't available anymore). I therefore like Kelly's suggestion of having a "bare bones" version in the repository and more details and updates in the Wiki. > Andrew. > > > > From david.katleman at oracle.com Tue May 21 20:05:16 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:05:16 +0000 Subject: hg: jdk8/build: 5 new changesets Message-ID: <20130521200517.304A348C0F@hg.openjdk.java.net> Changeset: 83b519cafa68 Author: katleman Date: 2013-05-16 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/83b519cafa68 Added tag jdk8-b90 for changeset 69b773a221b9 ! .hgtags Changeset: e2eb6bc06621 Author: mduigou Date: 2013-05-08 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/e2eb6bc06621 8014269: Add missing .PHONY targets to Main.gmk Reviewed-by: mchung, tbell ! common/makefiles/Main.gmk Changeset: 49ea9293fa49 Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/49ea9293fa49 Merge Changeset: 40bba0507f76 Author: lana Date: 2013-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/40bba0507f76 Merge Changeset: e83abb0a04ab Author: katleman Date: 2013-05-21 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/e83abb0a04ab Merge From david.katleman at oracle.com Tue May 21 20:05:23 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:05:23 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b90 for changeset c8286839d0df Message-ID: <20130521200525.7BA0848C10@hg.openjdk.java.net> Changeset: 8f7ffb296385 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/8f7ffb296385 Added tag jdk8-b90 for changeset c8286839d0df ! .hgtags From david.katleman at oracle.com Tue May 21 20:06:03 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:06:03 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b90 for changeset 1ae0472ff3a0 Message-ID: <20130521200608.673CE48C11@hg.openjdk.java.net> Changeset: 1cdbd42c3e49 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1cdbd42c3e49 Added tag jdk8-b90 for changeset 1ae0472ff3a0 ! .hgtags From david.katleman at oracle.com Tue May 21 20:07:59 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:07:59 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b90 for changeset 3e5b9ea5ac35 Message-ID: <20130521200803.A248848C13@hg.openjdk.java.net> Changeset: 0bb1a9fa56b0 Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/0bb1a9fa56b0 Added tag jdk8-b90 for changeset 3e5b9ea5ac35 ! .hgtags From david.katleman at oracle.com Tue May 21 20:07:33 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:07:33 +0000 Subject: hg: jdk8/build/jaxp: 8 new changesets Message-ID: <20130521200753.B199148C12@hg.openjdk.java.net> Changeset: f39d61028d2f Author: katleman Date: 2013-05-16 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/f39d61028d2f Added tag jdk8-b90 for changeset 668acc0e1034 ! .hgtags Changeset: 452e1a182907 Author: dfuchs Date: 2013-05-06 18:50 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/452e1a182907 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Summary: Encodings.java sometimes creates EncodingInfo objects whose java names are not recognized by the Charset API. This patch fixes that issue. Reviewed-by: joehw, alanb ! src/com/sun/org/apache/xml/internal/serializer/Encodings.java Changeset: 1e8d98012ab8 Author: joehw Date: 2013-05-08 23:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/1e8d98012ab8 8011653: Upgrade JDK8 to JAXP 1.5 Reviewed-by: alanb, dfuchs ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XSDDescription.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XSGrammarPoolContainer.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java ! src/com/sun/xml/internal/stream/StaxXMLInputSource.java ! src/javax/xml/XMLConstants.java ! src/javax/xml/parsers/DocumentBuilderFactory.java ! src/javax/xml/parsers/SAXParser.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/transform/TransformerFactory.java ! src/javax/xml/validation/SchemaFactory.java ! src/javax/xml/validation/Validator.java Changeset: 6976616f5753 Author: lana Date: 2013-05-08 22:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/6976616f5753 Merge Changeset: 9e4dfe933ba9 Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/9e4dfe933ba9 Merge Changeset: a229726149b4 Author: joehw Date: 2013-05-10 09:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/a229726149b4 8014333: javadoc error in JAXP 1.5 patch Reviewed-by: lancea ! src/javax/xml/stream/XMLInputFactory.java Changeset: 6443f5627744 Author: dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/6443f5627744 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This patch adds hashCode() methods that are consistent with equals(). Reviewed-by: chegar, joehw ! src/com/sun/org/apache/bcel/internal/generic/BasicType.java ! src/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java ! src/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java ! src/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java ! src/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java ! src/com/sun/org/apache/bcel/internal/generic/ReturnaddressType.java ! src/com/sun/org/apache/bcel/internal/generic/Select.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRefBase.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/DecimalDV.java ! src/com/sun/org/apache/xerces/internal/impl/dv/xs/PrecisionDecimalDV.java ! src/com/sun/org/apache/xerces/internal/util/URI.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java ! src/com/sun/org/apache/xml/internal/serializer/utils/URI.java ! src/com/sun/org/apache/xml/internal/utils/URI.java ! src/com/sun/org/apache/xpath/internal/Arg.java Changeset: e3065fb07877 Author: lana Date: 2013-05-17 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/e3065fb07877 Merge From david.katleman at oracle.com Tue May 21 20:12:07 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:12:07 +0000 Subject: hg: jdk8/build/jdk: 102 new changesets Message-ID: <20130521203304.EDD8148C15@hg.openjdk.java.net> Changeset: 08c28cdacd7b Author: katleman Date: 2013-05-16 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/08c28cdacd7b Added tag jdk8-b90 for changeset c63eda8f6300 ! .hgtags Changeset: 4dd6f7bb8bbd Author: simonis Date: 2013-05-06 12:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4dd6f7bb8bbd 7191872: Xrender: No text displayed using 64 bit JDK on solaris11-sparc Reviewed-by: prr, ceisserer ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/GlyphList.java ! src/solaris/classes/sun/font/XRGlyphCacheEntry.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 23f7ff502a89 Author: jgodinez Date: 2013-05-07 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/23f7ff502a89 8011069: Printing: NullPointerException since jdk8 b82 showing native Page Setup Dialog. Reviewed-by: bae, prr ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 8a995d335d59 Author: lana Date: 2013-05-09 19:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8a995d335d59 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: 103f492d8ce7 Author: vadim Date: 2013-05-17 17:19 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/103f492d8ce7 4892259: GIF ImageReader does not call passComplete in IIOReadUpdateListener Reviewed-by: prr, bae ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java + test/javax/imageio/plugins/gif/GIFPassListenerTest.java Changeset: 4ee85e865a83 Author: vadim Date: 2013-05-17 14:18 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4ee85e865a83 8000936: Enable Java2D D3D pipeline on newer Intel chipsets : Intel HD and later Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 51f5e544c88b Author: lana Date: 2013-05-17 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/51f5e544c88b Merge Changeset: 90b67c9a7eb2 Author: serb Date: 2013-05-06 16:23 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/90b67c9a7eb2 7161575: [macosx] On MacOSX port java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWToolkit.java Changeset: 7982299cd11c Author: serb Date: 2013-05-08 15:58 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7982299cd11c 8013841: [macosx] Animations not disabled for CALayers used via JAWT Reviewed-by: anthony, alexsch ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 5fe0a4da863d Author: lana Date: 2013-05-09 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5fe0a4da863d Merge - test/java/io/Serializable/accessConstants/AccessConstants.java - test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: a466a4192fea Author: pchelko Date: 2013-05-14 16:39 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a466a4192fea 8002045: Auto failed and threw exception:java.lang.UnsatisfiedLinkError: Reviewed-by: serb, anthony ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mapfile-vers-linux ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux Changeset: b1a7cc79f13d Author: serb Date: 2013-05-14 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b1a7cc79f13d 8014423: [macosx] The scrollbar's block increment performs incorrectly Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java Changeset: 722ee3129ce0 Author: ant Date: 2013-05-15 16:49 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/722ee3129ce0 8014227: JLightweightFrame needs another synchronization policy Reviewed-by: art ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 7a8a8e31a126 Author: pchelko Date: 2013-05-17 11:02 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7a8a8e31a126 7079254: Toolkit eventListener leaks memory Reviewed-by: serb, art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java + test/java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Changeset: e944b78812a8 Author: kshefov Date: 2013-05-17 14:08 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e944b78812a8 8014721: TEST_BUG: java/awt/TrayIcon/DragEventSource/DragEventSource.java fails with java.lang.UnsupportedOperationException Reviewed-by: anthony, serb ! test/java/awt/TrayIcon/DragEventSource/DragEventSource.java Changeset: 281add053efe Author: kshefov Date: 2013-05-17 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/281add053efe 8013426: TEST_BUG: java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java fails with "RuntimeException: The data should be available" on Linux Reviewed-by: anthony, serb ! test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java Changeset: 49871f1581b8 Author: lana Date: 2013-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/49871f1581b8 Merge Changeset: 167d2dcaeeee Author: ksrini Date: 2013-05-01 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/167d2dcaeeee 8013225: Refresh jdk's private ASM to the latest. Reviewed-by: mduigou, sundar ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java ! src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Context.java ! src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handler.java ! src/share/classes/jdk/internal/org/objectweb/asm/Item.java ! src/share/classes/jdk/internal/org/objectweb/asm/Label.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/TypePath.java + src/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ParameterNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/version.txt Changeset: 5045eb04a579 Author: mduigou Date: 2013-05-02 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5045eb04a579 8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile Reviewed-by: mduigou, henryjen, alanb, martin, psandoz Contributed-by: akhil.arora at oracle.com, brian.goetz at oracle.com ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/BitSet/BitSetStreamTest.java + test/java/util/Random/RandomStreamTest.java + test/java/util/zip/ZipFile/StreamZipEntriesTest.java Changeset: a6ff4a823164 Author: kizune Date: 2013-05-02 21:23 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a6ff4a823164 8013155: [pack200] improve performance of pack200 Reviewed-by: ksrini, jrose ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Changeset: 3062bf908281 Author: khazra Date: 2013-05-02 14:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3062bf908281 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name Summary: Remove buffer overruns in native code Reviewed-by: alanb, chegar ! src/solaris/native/java/net/NetworkInterface.c Changeset: 81be41c7323f Author: weijun Date: 2013-05-03 10:43 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/81be41c7323f 8013855: DigestMD5Client has not checked RealmChoiceCallback value Reviewed-by: xuelei, mullan ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java + test/com/sun/security/sasl/digest/AuthRealmChoices.java Changeset: 470f19b6bfdd Author: jbachorik Date: 2013-05-02 13:21 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/470f19b6bfdd 7199324: Connection ID for IPv6 addresses is not generated accordingly to the specification Summary: RemoteServer.getClientHost is returning a String with an IPv6 literal address and we need to enclose it in [] when building the connection id Reviewed-by: alanb, sjiang ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! test/javax/management/remote/mandatory/connection/ConnectionTest.java Changeset: fc156b925259 Author: mduigou Date: 2013-05-03 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fc156b925259 8013528: Provide SharedSecrets access to String(char[], boolean) constructor Reviewed-by: martin, alanb, chegar, plevart ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/sun/misc/JavaLangAccess/NewUnsafeString.java Changeset: d7f3d5659c46 Author: juh Date: 2013-05-03 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d7f3d5659c46 8005922: TEST_BUG: There is no /tmp directory for windows system. Reviewed-by: weijun ! test/sun/security/tools/policytool/ChangeUI.html ! test/sun/security/tools/policytool/UpdatePermissions.html ! test/sun/security/tools/policytool/i18n.html Changeset: d8f01bfb1da4 Author: dwanvik Date: 2013-05-06 05:51 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d8f01bfb1da4 8013403: Update JDK8 with Java DB 10.10.1.1. Summary: Drop Java DB 10.10.1.1 bits into JDK 8 and update image builds Reviewed-by: tbell ! make/common/Release.gmk ! makefiles/CompileDemos.gmk ! makefiles/Images.gmk Changeset: 398fe07f530f Author: dwanvik Date: 2013-05-06 06:05 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/398fe07f530f Merge - test/sun/reflect/CallerSensitive/MethodFinder.java Changeset: bd118033e44c Author: dxu Date: 2013-05-06 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bd118033e44c 8003992: File and other classes in java.io do not handle embedded nulls properly Summary: Have every file operation done with File, FileInputStream, FileOutputStream, or RandomAccessFile that involves a file path containing NUL fail. Also reviewed by fweimer at redhat.com Reviewed-by: alanb, sherman, ahgross, mduigou, dholmes, aph, plevart, martin ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/File/NulFile.java Changeset: e13cf31e5a96 Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e13cf31e5a96 8013712: Add Objects.nonNull and Objects.isNull Reviewed-by: mchung, darcy ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 3cbb65d9af9e Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3cbb65d9af9e 8013150: Iterator.remove and forEachRemaining relationship not specified Reviewed-by: mduigou Contributed-by: Akhil Arora ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Vector.java + test/java/util/Iterator/IteratorDefaults.java Changeset: 8221c421490f Author: mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8221c421490f 8003258: BufferedReader.lines() Reviewed-by: alanb, mduigou, psandoz Contributed-by: Brian Goetz , Henry Jen ! src/share/classes/java/io/BufferedReader.java + src/share/classes/java/io/UncheckedIOException.java + test/java/io/BufferedReader/Lines.java Changeset: b4a013f4eff4 Author: sherman Date: 2013-05-06 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b4a013f4eff4 8013252: Regex Matcher .start and .end should be accessible by group name 8013254: Constructor \w need update to add the support of \p{Join_Control} Summary: added the requested methods and updated the \w constructor Reviewed-by: mchung, alanb ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/regex/UnicodeProp.java ! test/java/util/regex/POSIX_Unicode.java ! test/java/util/regex/RegExTest.java Changeset: 814dcc08df52 Author: weijun Date: 2013-05-07 12:30 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/814dcc08df52 8010192: Enable native JGSS provider on Mac Reviewed-by: valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/native/sun/security/jgss/wrapper/gssapi.h ! test/sun/security/krb5/runNameEquals.sh Changeset: 9c9b2385c1b0 Author: jfranck Date: 2013-05-07 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9c9b2385c1b0 8013541: Revise javadoc for Executable.getAnnotatedReturnType() Reviewed-by: abuckley, darcy ! src/share/classes/java/lang/reflect/Executable.java Changeset: 2602eab5f086 Author: dfuchs Date: 2013-05-07 11:35 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2602eab5f086 8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently Summary: Encodings.java sometimes creates EncodingInfo objects whose java names are not recognized by the Charset API. This patch fixes that issue. Reviewed-by: joehw, alanb + test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java Changeset: 7b40394ad944 Author: sla Date: 2013-05-07 19:57 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7b40394ad944 6980985: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage is not robust when getMax() returns -1 7181907: TEST_BUG: j/l/management/MemoryMXBean/ResetPeakMemoryUsage fails with NegativeArraySizeException 7148492: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java failing since update to hs23-b15 or b16 Reviewed-by: mchung, brutisso ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java Changeset: 100027950b05 Author: sla Date: 2013-05-07 20:00 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/100027950b05 8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true Reviewed-by: alanb, dsamersoff ! test/sun/tools/jinfo/Basic.sh Changeset: e30396e22c6f Author: naoto Date: 2013-05-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e30396e22c6f 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: fe4e9bc2186f Author: mduigou Date: 2013-05-07 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fe4e9bc2186f 4802647: Throw required NPEs from removeAll()/retainAll() Reviewed-by: mduigou, chegar, dholmes Contributed-by: Brandon Passanisi ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! test/java/util/Collection/MOAT.java Changeset: 6feee75b0a8b Author: briangoetz Date: 2013-05-06 11:43 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6feee75b0a8b 8012664: Add tests for java.util.stream and lambda translation Reviewed-by: mduigou, briangoetz Contributed-by: Brian Goetz , Paul Sandoz , Mike Duigou , Robert Field , Jim Gish ! test/Makefile + test/java/util/concurrent/atomic/AtomicReferenceTest.java + test/java/util/stream/bootlib/TEST.properties + test/java/util/stream/bootlib/java/util/stream/CollectorOps.java + test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java + test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java + test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/OpTestCase.java + test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java + test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java + test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java + test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java + test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java + test/java/util/stream/bootlib/java/util/stream/TestData.java + test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java + test/java/util/stream/boottest/TEST.properties + test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java + test/java/util/stream/boottest/java/util/stream/FlagOpTest.java + test/java/util/stream/boottest/java/util/stream/IntNodeTest.java + test/java/util/stream/boottest/java/util/stream/LongNodeTest.java + test/java/util/stream/boottest/java/util/stream/NodeBuilderTest.java + test/java/util/stream/boottest/java/util/stream/NodeTest.java + test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java + test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java + test/java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java + test/java/util/stream/boottest/java/util/stream/StreamReuseTest.java + test/java/util/stream/boottest/java/util/stream/UnorderedTest.java + test/java/util/stream/test/TEST.properties + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java + test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/NullArgsTestCase.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FilterOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindAnyOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntReduceTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveAverageOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamParSeqTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/TeeOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java + test/jdk/lambda/ArrayCtorRefTest.java + test/jdk/lambda/FDTest.java + test/jdk/lambda/LambdaTranslationCompoundSamTest.java + test/jdk/lambda/LambdaTranslationInInterface.java + test/jdk/lambda/LambdaTranslationInnerConstructor.java + test/jdk/lambda/LambdaTranslationTest1.java + test/jdk/lambda/LambdaTranslationTest2.java + test/jdk/lambda/MethodReferenceTestFDCCE.java + test/jdk/lambda/MethodReferenceTestInnerDefault.java + test/jdk/lambda/MethodReferenceTestInnerInstance.java + test/jdk/lambda/MethodReferenceTestInnerVarArgsThis.java + test/jdk/lambda/MethodReferenceTestInstance.java + test/jdk/lambda/MethodReferenceTestInstanceMethod.java + test/jdk/lambda/MethodReferenceTestKinds.java + test/jdk/lambda/MethodReferenceTestNew.java + test/jdk/lambda/MethodReferenceTestNewInner.java + test/jdk/lambda/MethodReferenceTestSueCase1.java + test/jdk/lambda/MethodReferenceTestSueCase2.java + test/jdk/lambda/MethodReferenceTestSueCase4.java + test/jdk/lambda/MethodReferenceTestSuper.java + test/jdk/lambda/MethodReferenceTestSuperDefault.java + test/jdk/lambda/MethodReferenceTestTypeConversion.java + test/jdk/lambda/MethodReferenceTestVarArgs.java + test/jdk/lambda/MethodReferenceTestVarArgsExt.java + test/jdk/lambda/MethodReferenceTestVarArgsSuper.java + test/jdk/lambda/MethodReferenceTestVarArgsSuperDefault.java + test/jdk/lambda/MethodReferenceTestVarArgsThis.java + test/jdk/lambda/TEST.properties + test/jdk/lambda/TestInnerCtorRef.java + test/jdk/lambda/TestPrivateCtorRef.java + test/jdk/lambda/separate/AttributeInjector.java + test/jdk/lambda/separate/ClassFile.java + test/jdk/lambda/separate/ClassFilePreprocessor.java + test/jdk/lambda/separate/ClassToInterfaceConverter.java + test/jdk/lambda/separate/Compiler.java + test/jdk/lambda/separate/DirectedClassLoader.java + test/jdk/lambda/separate/SourceModel.java + test/jdk/lambda/separate/TestHarness.java + test/jdk/lambda/shapegen/ClassCase.java + test/jdk/lambda/shapegen/Hierarchy.java + test/jdk/lambda/shapegen/HierarchyGenerator.java + test/jdk/lambda/shapegen/Rule.java + test/jdk/lambda/shapegen/RuleGroup.java + test/jdk/lambda/shapegen/TTNode.java + test/jdk/lambda/shapegen/TTParser.java + test/jdk/lambda/shapegen/TTShape.java + test/jdk/lambda/vm/DefaultMethodRegressionTests.java + test/jdk/lambda/vm/DefaultMethodsTest.java + test/jdk/lambda/vm/InterfaceAccessFlagsTest.java + test/jdk/lambda/vm/StrictfpDefault.java Changeset: 7d89b0dd973c Author: weijun Date: 2013-05-08 08:25 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7d89b0dd973c 8012679: Let allow_weak_crypto default to false Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/etype/WeakCrypto.java Changeset: c8f47674d105 Author: alanb Date: 2013-05-08 18:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c8f47674d105 8013652: (profiles) Add javax.script to compact1 Reviewed-by: mchung, dholmes ! makefiles/profile-rtjar-includes.txt Changeset: 3fd83f282c61 Author: ksrini Date: 2013-05-07 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3fd83f282c61 8013736: [launcher] cleanup code for correctness 8005735: [parfait] False positive integer overflow in jdk/src/solaris/bin/jexec.c 8009873: [parfait] Memory leak at jdk/src/share/bin/wildcard.c 8005807: [parfait] Undefined return value at jdk/src/share/bin/java.c Reviewed-by: alanb, martin ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/wildcard.c ! src/solaris/bin/jexec.c Changeset: bb9cdfac1a7d Author: juh Date: 2013-05-09 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bb9cdfac1a7d 8007699: Move some tests from test/sun/security/provider/certpath/X509CertPath to closed repo Reviewed-by: mullan - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 498ea4c3a4c6 Author: psandoz Date: 2013-05-01 18:40 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/498ea4c3a4c6 8012646: Pattern.splitAsStream Reviewed-by: forax, plevart, alanb Contributed-by: Ben Evans , Paul Sandoz ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 573a593379cb Author: lana Date: 2013-05-08 23:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/573a593379cb Merge ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 2023e3d573eb Author: lana Date: 2013-05-09 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2023e3d573eb Merge - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: ba74cd79e4f6 Author: jfranck Date: 2013-05-10 10:20 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ba74cd79e4f6 8007073: Implement Core Reflection for Type Annotations on parameters Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/TypeAnnotation.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! test/java/lang/annotation/TypeAnnotationReflection.java Changeset: 09a3b08c986f Author: alanb Date: 2013-05-10 14:53 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/09a3b08c986f 8011128: (fs) Files.createDirectory fails if the resolved path is exactly 248 characters long Reviewed-by: khazra, chegar ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsPath.java + test/java/nio/file/Files/NameLimits.java Changeset: ece61e21782d Author: darcy Date: 2013-05-10 08:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ece61e21782d 8014249: Add Modifer.parameterModifiers() Reviewed-by: mduigou, mchung ! src/share/classes/java/lang/reflect/Modifier.java Changeset: c26e0d29249a Author: rriggs Date: 2013-05-10 09:06 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c26e0d29249a 8014296: DivModTests should not compare pointers Reviewed-by: darcy ! test/java/lang/Math/DivModTests.java Changeset: 2490769abdfa Author: mduigou Date: 2013-05-10 09:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2490769abdfa 8014316: Use Method Refs in j.u.stream.MatchOps Reviewed-by: dholmes ! src/share/classes/java/util/stream/MatchOps.java Changeset: 9891e4d7d5b3 Author: mduigou Date: 2013-05-10 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9891e4d7d5b3 Merge - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: f84b5498b2bb Author: darcy Date: 2013-05-10 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f84b5498b2bb 8014357: Minor refactorings to sun.reflect.generics.reflectiveObjects.* Reviewed-by: mchung ! src/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java Changeset: 90f715cceaae Author: dmeetry Date: 2013-05-10 23:56 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/90f715cceaae 7021870: GzipInputStream closes underlying stream during reading Reviewed-by: mduigou Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/java/util/zip/GZIPInputStream.java + test/java/util/zip/GZIP/GZIPInZip.java Changeset: 76998d11a643 Author: xuelei Date: 2013-05-13 05:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/76998d11a643 8005535: SSLSessionImpl should have protected finalize() Reviewed-by: weijun, wetmore ! src/share/classes/sun/security/ssl/SSLSessionImpl.java Changeset: 46db0e633240 Author: xuelei Date: 2013-05-13 06:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/46db0e633240 8005598: (reopened) Need to clone array of input/output parameters Reviewed-by: weijun ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: 536678dffa97 Author: sundar Date: 2013-05-13 22:23 +0530 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/536678dffa97 8012975: Remove rhino from jdk8 Reviewed-by: alanb, tbell ! make/com/sun/Makefile - make/com/sun/script/Makefile ! make/sun/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile ! make/tools/src/build/tools/deps/refs.allowed ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/profile-rtjar-includes.txt - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java Changeset: 6175fe5b07aa Author: bharadwaj Date: 2013-05-13 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6175fe5b07aa 8008687: MethodHandle code: allow static and invokespecial calls to interface methods Summary: Changes to support invocation of lambda methods compiled either as static interface methods and or private instance methods. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: f7fcfb204a69 Author: mduigou Date: 2013-05-13 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f7fcfb204a69 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java Changeset: 86c1e8c799f5 Author: khazra Date: 2013-05-13 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/86c1e8c799f5 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive Summary: Rearrange event-handling code to remove bottle-neck. Also reviewed by mhall at mhcomputing.net. Reviewed-by: chegar, alanb ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: ae35fdbab949 Author: sherman Date: 2013-05-13 20:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ae35fdbab949 8013386: (tz) Support tzdata2013c Summary: updated tz data to version 2013c Reviewed-by: peytoia, okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/Rule.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: a50bad038f31 Author: darcy Date: 2013-05-13 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a50bad038f31 8014365: Restore Objects.requireNonNull(T, Supplier) Reviewed-by: mduigou ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: b315cb9a7544 Author: alanb Date: 2013-05-14 14:32 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b315cb9a7544 8014500: bootcycle-images fails after upgrade to JAXP 1.5 Reviewed-by: lancea ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java Changeset: 5ea5f5dfb96a Author: uta Date: 2013-05-14 20:16 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5ea5f5dfb96a 8012453: (process) Runtime.exec(String) fails if command contains spaces [win] Reviewed-by: alanb ! src/share/classes/java/lang/ProcessBuilder.java ! src/windows/classes/java/lang/ProcessImpl.java + test/java/lang/Runtime/exec/ExecCommand.java Changeset: e0135f1a8627 Author: sundar Date: 2013-05-14 22:36 +0530 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e0135f1a8627 8014519: scriptpad sample does not work with nashorn Reviewed-by: attila, jlaskey Contributed-by: rieberandreas at gmail.com ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.sh ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js Changeset: 790d292ee761 Author: khazra Date: 2013-05-14 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/790d292ee761 6328537: Improve javadocs for Socket class by adding references to SocketOptions Summary: Insert references to SocketOptions.java where applicable Reviewed-by: alanb, chegar ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java Changeset: 08ef70f60e0d Author: sherman Date: 2013-05-14 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/08ef70f60e0d 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Summary: removed the race condition risk from ExtendedCahrset access code Reviewed-by: mchung, alanb ! make/sun/nio/cs/Makefile ! makefiles/CreateJars.gmk ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java Changeset: c70fff3db913 Author: sherman Date: 2013-05-14 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c70fff3db913 8014217: Base64.getXDecoder().wrap(...).read() doesn't throw exception for an incorrect number of padding chars in the final unit Summary: to throw IOE for malformed final unit in base64 stream Reviewed-by: chegar, alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: a3d79a4c2a24 Author: dholmes Date: 2013-05-15 00:36 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a3d79a4c2a24 8013395: StringBuffer.toString performance regression impacting embedded benchmarks Summary: cache a copy of the char[] to use with toString() and clear it when ever the sb content is modified Reviewed-by: alanb, plevart, mduigou, forax ! src/share/classes/java/lang/StringBuffer.java + test/java/lang/StringBuffer/ToStringCache.java Changeset: 93a268759ec3 Author: michaelm Date: 2013-05-15 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/93a268759ec3 8010464: Evolve java networking same origin policy Reviewed-by: alanb, chegar, dsamersoff, weijun ! src/share/classes/java/net/HttpURLConnection.java + src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLPermission/HttpURLPermissionTest.java + test/java/net/HttpURLPermission/URLTest.java + test/java/net/HttpURLPermission/policy.1 + test/java/net/HttpURLPermission/policy.2 + test/java/net/HttpURLPermission/policy.3 Changeset: ef04044f77d2 Author: sherman Date: 2013-05-15 07:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ef04044f77d2 8013730: JSR 310 DateTime API Updates III Summary: Integration of JSR310 Date/Time API update III Reviewed-by: naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DateTimeException.java ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Ser.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/HijrahEra.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimeParseException.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/DecimalStyle.java ! src/share/classes/java/time/format/FormatStyle.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/format/ResolverStyle.java ! src/share/classes/java/time/format/SignStyle.java ! src/share/classes/java/time/format/TextStyle.java ! src/share/classes/java/time/format/package-info.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesException.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java + test/java/time/tck/java/time/format/TCKDecimalStyle.java + test/java/time/tck/java/time/format/TCKInstantPrinterParser.java ! test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java ! test/java/time/test/java/time/chrono/TestChronologyPerf.java ! test/java/time/test/java/time/chrono/TestExampleCode.java + test/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/java/time/test/java/time/format/AbstractTestPrinterParser.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java + test/java/time/test/java/time/format/TestDecimalStyle.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java Changeset: bad8f5237f10 Author: darcy Date: 2013-05-15 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bad8f5237f10 8014677: Correct docs warning for Objects.requireNonNull(T, Supplier) Reviewed-by: alanb ! src/share/classes/java/util/Objects.java Changeset: 3d9f25dc630c Author: naoto Date: 2013-05-15 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3d9f25dc630c 8013233: java/util/Locale/LocaleProviders.sh fails Reviewed-by: okutsu ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: 2ec31660cc0e Author: valeriep Date: 2013-05-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2ec31660cc0e 8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps should be protected Summary: Change the finalize method of PKCS11 class to be protected. Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java Changeset: 991420add35d Author: valeriep Date: 2013-05-07 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/991420add35d 7196009: SunPkcs11 provider fails to parse config path containing parenthesis Summary: Enhanced to allow quoted string as library path values. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java ! test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/cspQuotedPath.cfg Changeset: 804da1e9bd04 Author: ascarpino Date: 2013-05-07 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/804da1e9bd04 8001284: Buffer problems with SunPKCS11-Solaris and CKM_AES_CTR Summary: Changed output length calculation to include incomplete blocks for CTR mode. Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: fc70416beef3 Author: valeriep Date: 2013-05-13 16:52 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fc70416beef3 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 59357ea7f131 Author: valeriep Date: 2013-05-15 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/59357ea7f131 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java Changeset: bb01cc14223c Author: ewang Date: 2013-05-16 10:59 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bb01cc14223c 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up Reviewed-by: alanb, dholmes, chegar ! test/java/lang/Thread/GenerifyStackTraces.java - test/java/lang/Thread/StackTraces.java Changeset: b198389f9da4 Author: xuelei Date: 2013-05-16 04:30 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b198389f9da4 8010814: More buffers are stored or returned without cloning Reviewed-by: lancea ! src/share/classes/com/sun/jndi/ldap/BerDecoder.java ! src/share/classes/com/sun/jndi/ldap/BerEncoder.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java Changeset: 81c449fd18fe Author: dmeetry Date: 2013-05-16 19:28 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/81c449fd18fe 8014676: Java debugger may fail to run Summary: The problem is observed when the binaries for windows are placed under a path which contains a space Reviewed-by: sla, alanb Contributed-by: ivan.gerasimov at oracle.com ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java Changeset: 74f91b7f4b66 Author: michaelm Date: 2013-05-16 17:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/74f91b7f4b66 8012625: Incorrect handling of HTTP/1.1 " Expect: 100-continue " in HttpURLConnection Reviewed-by: alanb, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/B8012625.java Changeset: d02d1b18d828 Author: michaelm Date: 2013-05-16 17:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d02d1b18d828 Merge Changeset: da203779cb33 Author: jgish Date: 2013-05-16 11:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/da203779cb33 8013380: Removal of stack walk to find resource bundle breaks Glassfish startup Summary: Use caller's classloader to load resource as an alternative to thread context classloader and system classloader Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/bundlesearch/IndirectlyLoadABundle.java - test/java/util/logging/bundlesearch/LoadItUp.java + test/java/util/logging/bundlesearch/LoadItUp1.java + test/java/util/logging/bundlesearch/LoadItUp2.java + test/java/util/logging/bundlesearch/LoadItUp2Invoker.java ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java + test/java/util/logging/bundlesearch/TwiceIndirectlyLoadABundle.java + test/java/util/logging/bundlesearch/resources/CallerSearchableResource_en.properties Changeset: df133f9cc4c9 Author: dfuchs Date: 2013-05-16 18:40 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/df133f9cc4c9 Merge Changeset: a8be9405bb4b Author: khazra Date: 2013-05-16 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a8be9405bb4b 7150552: network test hangs [macosx] Summary: Remove usage of test/sun/net/www/httptest Reviewed-by: chegar ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieManagerTest.java ! test/sun/net/www/protocol/http/B6299712.java Changeset: a13de892cefd Author: ksrini Date: 2013-05-15 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a13de892cefd 8001163: [pack200] should support attributes introduced by JSR-308 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java + test/tools/pack200/BandIntegrity.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java + test/tools/pack200/typeannos/Lambda.java + test/tools/pack200/typeannos/Readme.txt + test/tools/pack200/typeannos/TargetTypes.java + test/tools/pack200/typeannos/TestTypeAnnotations.java + test/tools/pack200/typeannos/TypeUseTarget.java Changeset: 9abf5dc83823 Author: vinnie Date: 2013-05-14 18:08 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9abf5dc83823 7194075: Various classes of sunec.jar are duplicated in rt.jar Reviewed-by: mullan, vinnie Contributed-by: Stephen Flores ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! makefiles/CreateJars.gmk + src/share/classes/sun/security/ec/CurveDB.java ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/NamedCurve.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/ssl/JsseJce.java + src/share/classes/sun/security/util/ECKeySizeParameterSpec.java + src/share/classes/sun/security/util/ECUtil.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/ec/TestECDH2.java ! test/sun/security/pkcs11/ec/TestECDSA2.java Changeset: fdf082cddb69 Author: vinnie Date: 2013-05-14 18:11 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fdf082cddb69 Merge Changeset: a399b8be56ae Author: vinnie Date: 2013-05-15 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a399b8be56ae Merge ! makefiles/CreateJars.gmk - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider Changeset: 5153f5154162 Author: vinnie Date: 2013-05-15 15:39 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5153f5154162 Merge Changeset: 0465f27f19f5 Author: vinnie Date: 2013-05-16 02:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0465f27f19f5 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java Changeset: 9783f07d43e6 Author: vinnie Date: 2013-05-16 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9783f07d43e6 Merge - test/java/lang/Thread/StackTraces.java - test/java/util/logging/bundlesearch/LoadItUp.java Changeset: 5e8959ab64af Author: mchung Date: 2013-05-16 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e8959ab64af 4487672: (proxy) Proxy constructor should check for null argument Reviewed-by: alanb, lancea ! src/share/classes/java/lang/reflect/Proxy.java ! test/java/lang/reflect/Proxy/Basic1.java Changeset: 68209420aac2 Author: dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/68209420aac2 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This patch adds hashCode() methods that are consistent with equals(). Reviewed-by: chegar, joehw + test/javax/xml/jaxp/PrecisionDecimalDV/XPrecisionDecimalToString.java Changeset: 3981ad7ec458 Author: chegar Date: 2013-05-17 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3981ad7ec458 8014791: More ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: fab0e4b682e8 Author: chegar Date: 2013-05-17 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fab0e4b682e8 Merge ! test/ProblemList.txt - test/java/util/logging/bundlesearch/LoadItUp.java Changeset: 222da3d4692a Author: chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/222da3d4692a 8014783: java/net/HttpURLPermission/HttpURLPermissionTest.java leaves files open Reviewed-by: michaelm ! test/java/net/HttpURLPermission/HttpURLPermissionTest.java Changeset: fed779a87670 Author: chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fed779a87670 Merge - test/java/util/logging/bundlesearch/LoadItUp.java Changeset: 30101f69e66f Author: lana Date: 2013-05-17 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/30101f69e66f Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Base64.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: b61632814be2 Author: katleman Date: 2013-05-21 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b61632814be2 Merge From david.katleman at oracle.com Tue May 21 20:38:48 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:38:48 +0000 Subject: hg: jdk8/build/langtools: 45 new changesets Message-ID: <20130521204054.10AFA48C16@hg.openjdk.java.net> Changeset: 9717b9523d46 Author: katleman Date: 2013-05-16 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/9717b9523d46 Added tag jdk8-b90 for changeset e19283cd30a4 ! .hgtags Changeset: abd153854f16 Author: jjg Date: 2013-05-03 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/abd153854f16 8012728: Normalize @ignore comments on langtools tests Reviewed-by: vromero, mcimadamore ! test/com/sun/javadoc/_template/Template.java ! test/com/sun/javadoc/_template/TemplateComplete.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511b.java ! test/tools/javac/generics/OverrideBridge.java ! test/tools/javac/lambda/TargetType36.java ! test/tools/javac/lambda/TargetType53.java ! test/tools/javac/lambda/TargetType54.java ! test/tools/javac/lambda/TargetType58.java ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java ! test/tools/javap/output/RepeatingTypeAnnotations.java ! test/tools/javap/output/Tester.java Changeset: 38c4bade0ec1 Author: jjg Date: 2013-05-03 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/38c4bade0ec1 8002387: Improve rendered HTML formatting for {@code} Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javadoc/Comment.java + test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java + test/com/sun/javadoc/testLiteralCodeInPre/pkg/Test.java Changeset: a2889739cf21 Author: jjg Date: 2013-05-03 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a2889739cf21 8000407: remove @GenerateNativeHeader Reviewed-by: vromero, darcy ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java Changeset: d918b63a5509 Author: jjg Date: 2013-05-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d918b63a5509 8008768: Using {@inheritDoc} in simple tag defined via -tag fails Reviewed-by: jjg, mduigou Contributed-by: jonathan.gibbons at oracle.com, mike.duigou at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java + test/com/sun/javadoc/InheritDocForUserTags/DocTest.java + test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java + test/com/sun/javadoc/testSimpleTagInherit/p/BaseClass.java + test/com/sun/javadoc/testSimpleTagInherit/p/TestClass.java Changeset: e8987ce7fb4b Author: darcy Date: 2013-05-05 21:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e8987ce7fb4b 8013909: Fix doclint issues in javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/SupportedAnnotationTypes.java ! src/share/classes/javax/annotation/processing/SupportedOptions.java ! src/share/classes/javax/annotation/processing/SupportedSourceVersion.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/element/NestingKind.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: a7ff36d06fa2 Author: jlahoda Date: 2013-05-06 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a7ff36d06fa2 8009724: Enhance the DocTree API with DocTreePath Summary: Adding DocTreePath and DocTreePathScanner similar to TreePath and TreePathScanner, respectively Reviewed-by: jjg Contributed-by: Ralph Benjamin Ruijs , Jan Lahoda + src/share/classes/com/sun/source/util/DocTreePath.java + src/share/classes/com/sun/source/util/DocTreePathScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/doctree/DocTreePathScannerTest.java ! test/tools/javac/doctree/ReferenceTest.java Changeset: 68142e69cafb Author: rfield Date: 2013-05-07 06:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/68142e69cafb 8014023: When a method reference to a local class constructor is contained in a method whose number of parameters matches the number of constructor parameters compilation fails Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/methodReference/TreeMakerParamsIsGoofy.java Changeset: 43c2f7cb9c76 Author: jjg Date: 2013-05-07 14:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/43c2f7cb9c76 8004082: test/tools/javac/plugin/showtype/Test.java fails on windows: jtreg can't delete plugin.jar Reviewed-by: vromero, mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + src/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! test/tools/javac/plugin/showtype/Test.java Changeset: 780014a234fa Author: jfranck Date: 2013-05-08 14:10 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/780014a234fa 8013485: javac can't handle annotations with a from a previous compilation unit Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/clinit/AnnoWithClinit1.java + test/tools/javac/annotations/clinit/AnnoWithClinitFail.java + test/tools/javac/annotations/clinit/AnnoWithClinitFail.out Changeset: c68834236058 Author: lana Date: 2013-05-08 23:54 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c68834236058 Merge Changeset: ce7e1674eb73 Author: alanb Date: 2013-05-10 16:10 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ce7e1674eb73 8014318: tools/javac/profiles/ProfileOptionTest.java needs modifying now that javax.script is in compact1 Reviewed-by: mchung ! test/tools/javac/profiles/ProfileOptionTest.java Changeset: 1c43236f6d69 Author: darcy Date: 2013-05-10 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/1c43236f6d69 8014365: Restore Objects.requireNonNull(T, Supplier) Reviewed-by: jjg ! makefiles/BuildLangtools.gmk Changeset: e39669aea0bd Author: jjg Date: 2013-05-12 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e39669aea0bd 8014363: javac test class ToolTester handles classpath incorrectly Reviewed-by: ksrini ! test/tools/javac/api/6406133/T6406133.java ! test/tools/javac/api/6410643/T6410643.java ! test/tools/javac/api/6411310/T6411310.java ! test/tools/javac/api/6411333/T6411333.java ! test/tools/javac/api/6412656/T6412656.java ! test/tools/javac/api/6415780/T6415780.java ! test/tools/javac/api/6418694/T6418694.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6421756/T6421756.java ! test/tools/javac/api/6422215/T6422215.java ! test/tools/javac/api/6422327/T6422327.java ! test/tools/javac/api/6423003/T6423003.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/6437349/T6437349.java ! test/tools/javac/api/6437999/T6437999.java ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/6440528/T6440528.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/6733837/T6733837.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/api/guide/Test.java ! test/tools/javac/api/lib/ToolTester.java Changeset: 8dd528992c15 Author: jlahoda Date: 2013-05-10 15:15 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8dd528992c15 8012929: Trees.getElement should work not only for declaration trees, but also for use-trees Reviewed-by: jjg Contributed-by: Dusan Balek , Jan Lahoda ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/api/TestGetElementReference.java + test/tools/javac/api/TestGetElementReferenceData.java Changeset: 8ea30d59ac41 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8ea30d59ac41 8010440: Replace int constants in LinkInfoImpl with enum Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java Changeset: 74cd21f2c2fe Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/74cd21f2c2fe 8011642: Remove LinkOutput in favor of direct use of Content Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java Changeset: 7a9ef837e57f Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/7a9ef837e57f 8011650: reduce use of RawHtml nodes in doclet Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java Changeset: 6ea964c78845 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6ea964c78845 8011651: simplify LinkInfoImpl API Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java Changeset: e6c5b5ee9fac Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/e6c5b5ee9fac 8011662: Remove single instance of resource with HTML from doclet resource bundle Reviewed-by: bpatel, darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: ce4f0769b4b2 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ce4f0769b4b2 8011668: Allow HTMLWriter.getResource to take Content args Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: 4c43e51433ba Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/4c43e51433ba 8011288: Erratic/inconsistent indentation of signatures Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java + test/com/sun/javadoc/testIndentation/TestIndentation.java + test/com/sun/javadoc/testIndentation/p/Indent.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java Changeset: 7af0fa419a2b Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/7af0fa419a2b 8012174: {@literal} and {@code} should use \"new\" Taglet, not old. Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java Changeset: 6a5288a298fd Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6a5288a298fd 8012175: Convert TagletOutputImpl to use ContentBuilder instead of StringBuilder Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java Changeset: 76a691e3e961 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/76a691e3e961 8012176: reduce use of TagletOutputImpl.toString Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java Changeset: 937aa020c667 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/937aa020c667 8012177: HTMLDocletWriter methods should generate Content, not Strings Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java Changeset: bd51ca92c013 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bd51ca92c013 8012178: Cleanup use of Util.escapeHtmlChars Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: df4f44800923 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/df4f44800923 8012183: replace some uses of Configuration.getText with Configuration.getResource Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java Changeset: 051b728cfe90 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/051b728cfe90 8012180: Speed up removeNonInlineHtmlTags Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 25c89a492f14 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/25c89a492f14 8012295: Cleanup JavaFX features in standard doclet Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: 081d7c72ee92 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/081d7c72ee92 8012311: Cleanup names and duplicatre code in TagletManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: ca8808c88f94 Author: jjg Date: 2013-05-14 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ca8808c88f94 8012308: Remove TagletOutput in favor of direct use of Content Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/Taglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/BoldTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/GreenTaglet.java ! test/com/sun/javadoc/testNestedInlineTag/testtaglets/UnderlineTaglet.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java Changeset: c09b7234cded Author: rfield Date: 2013-05-14 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c09b7234cded 8012556: Implement lambda methods on interfaces as static 8006140: Javac NPE compiling Lambda expression on initialization expression of static field in interface Summary: Lambdas occurring in static contexts or those not needing instance information should be generated into static methods. This has long been the case for classes. However, as a work-around to the lack of support for statics on interfaces, interface lambda methods have been generated into default methods. For lambdas in interface static contexts (fields and static methods) this causes an NPE in javac because there is no 'this'. MethodHandles now support static methods on interfaces. This changeset allows lambda methods to be generated as static interface methods. An existing bug in Hotspot (8013875) is exposed in a test when the "-esa" flag is used. This test and another test that already exposed this bug have been marked with @ignore. Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaInterfaceStaticField.java ! test/tools/javac/lambda/MethodReference66.java ! test/tools/javac/lambda/bytecode/TestLambdaBytecode.java ! test/tools/javac/lambda/lambdaExecution/InInterface.java Changeset: 46b9c25f7024 Author: jjg Date: 2013-05-14 12:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/46b9c25f7024 8014461: genstubs creates default native methods Reviewed-by: alanb ! make/tools/genstubs/GenStubs.java Changeset: 0384683c64be Author: jjg Date: 2013-05-14 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/0384683c64be 8014557: Mutable static field in HtmlDocletWriter Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java Changeset: ddb4a2bfcd82 Author: jjg Date: 2013-05-14 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ddb4a2bfcd82 8013852: update reference impl for type-annotations Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com, joel.franck at oracle.com, alex.buckley at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest3.java ! test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java + test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java + test/tools/javac/annotations/typeAnnotations/classfile/T8008769.java + test/tools/javac/annotations/typeAnnotations/classfile/T8010015.java + test/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java + test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out + test/tools/javac/annotations/typeAnnotations/failures/T8008751.java + test/tools/javac/annotations/typeAnnotations/failures/T8009360.java + test/tools/javac/annotations/typeAnnotations/failures/T8011722.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DeclarationAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DeclarationAnnotation.out + test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Initializers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Test.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/diags/examples/ArrayAndReceiver.java + test/tools/javac/diags/examples/IncorrectConstructorReceiverName.java + test/tools/javac/diags/examples/IncorrectConstructorReceiverType.java + test/tools/javac/diags/examples/IncorrectReceiverName.java + test/tools/javac/diags/examples/ReceiverParameterNotApplicableConstructor.java + test/tools/javac/diags/examples/VarargsAndReceiver.java ! test/tools/javac/lib/DPrinter.java + test/tools/javac/processing/model/type/BasicAnnoTests.java ! test/tools/javac/tree/SourceTreeScannerTest.java ! test/tools/javap/output/RepeatingTypeAnnotations.java ! test/tools/javap/typeAnnotations/NewArray.java ! test/tools/javap/typeAnnotations/Presence.java ! test/tools/javap/typeAnnotations/TypeCasts.java Changeset: 53b389eb39c1 Author: sogoel Date: 2013-05-14 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/53b389eb39c1 8013163: Convert 4 tools multicatch tests to jtreg format Reviewed-by: jjg + test/tools/javac/multicatch/Pos11.java + test/tools/javac/multicatch/Pos12.java Changeset: 529fb3ed5d2a Author: jjg Date: 2013-05-14 21:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/529fb3ed5d2a 8014323: Add VariableTree.getNameExpression Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! test/tools/javac/tree/SourceTreeScannerTest.java Changeset: bcd927639039 Author: darcy Date: 2013-05-15 00:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bcd927639039 8004133: Provide javax.lang.model.* implementation backed by core reflection Summary: Joint work by darcy and jfranck to provide sample code for JEP 119. Reviewed-by: jjg Contributed-by: joe.darcy at oracle.com, joel.franck at oracle.com + src/share/sample/language/model/CoreReflectionFactory.java Changeset: 05ec778794d0 Author: mcimadamore Date: 2013-05-15 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/05ec778794d0 8012003: Method diagnostics resolution need to be simplified in some cases Summary: Unfold method resolution diagnostics when they mention errors in poly expressions Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/Diagnostics/compressed/T8012003a.java + test/tools/javac/Diagnostics/compressed/T8012003a.out + test/tools/javac/Diagnostics/compressed/T8012003b.java + test/tools/javac/Diagnostics/compressed/T8012003b.out + test/tools/javac/Diagnostics/compressed/T8012003c.java + test/tools/javac/Diagnostics/compressed/T8012003c.out ! test/tools/javac/diags/examples/BadArgTypesInLambda.java + test/tools/javac/diags/examples/CompressedDiags.java ! test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/ProbFoundReqFragment.java ! test/tools/javac/lambda/TargetType66.out Changeset: 33d1937af1a3 Author: mcimadamore Date: 2013-05-15 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/33d1937af1a3 8012685: Spurious raw types warning when using unbound method references Summary: Spurious raw type warning when unbound method reference qualifier parameter types are inferred from target Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/MethodReference67.java + test/tools/javac/lambda/MethodReference67.out Changeset: 78717f2d00e8 Author: mcimadamore Date: 2013-05-15 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/78717f2d00e8 8013222: Javac issues spurious raw type warnings when lambda has implicit parameter types Summary: Bad warnings and position for lambda inferred parameter types Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/NoWarnOnImplicitParams.java + test/tools/javac/lambda/NoWarnOnImplicitParams.out Changeset: 31ef33db5e0e Author: rfield Date: 2013-05-15 06:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/31ef33db5e0e 8010006: NPE in javac with interface super in lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaWithInterfaceSuper.java Changeset: 445b8b5ae9f4 Author: jjg Date: 2013-05-15 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/445b8b5ae9f4 8006879: Detection of windows in sjavac fails. Reviewed-by: jjg Contributed-by: erik.joelsson at oracle.com ! src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java Changeset: 997c0fae2b12 Author: lana Date: 2013-05-17 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/997c0fae2b12 Merge - src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java - src/share/classes/javax/tools/annotation/GenerateNativeHeader.java - test/tools/javac/nativeHeaders/javahComparison/TestClass2.java - test/tools/javac/nativeHeaders/javahComparison/TestClass3.java From david.katleman at oracle.com Tue May 21 20:41:04 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 20:41:04 +0000 Subject: hg: jdk8/build/nashorn: 19 new changesets Message-ID: <20130521204119.4924F48C17@hg.openjdk.java.net> Changeset: 4ce88eec5078 Author: katleman Date: 2013-05-16 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/4ce88eec5078 Added tag jdk8-b90 for changeset 67ca019e3713 ! .hgtags Changeset: b754fb89367d Author: jlaskey Date: 2013-04-30 10:05 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b754fb89367d 8006220: Simplify PropertyMaps Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java Changeset: 80cb02dedc83 Author: hannesw Date: 2013-05-02 09:19 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/80cb02dedc83 8013729: SwitchPoint invalidation not working over prototype chain Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8013729.js + test/script/basic/JDK-8013729.js.EXPECTED Changeset: 7563c56ca565 Author: jlaskey Date: 2013-05-02 13:22 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/7563c56ca565 8013794: JDK-8006220 caused an octane performance regression. Reviewed-by: lagergren, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ObjectCreator.java Changeset: 9c2376a250b6 Author: jlaskey Date: 2013-05-02 13:23 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9c2376a250b6 Merge Changeset: c8023561505b Author: jlaskey Date: 2013-05-02 15:01 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c8023561505b 8013796: load("fx:base.js") should not be in fx:bootstrap.js Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/bootstrap.js Changeset: 5a3f7867e19c Author: lagergren Date: 2013-05-03 15:33 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5a3f7867e19c 8013477: Node.setSymbol needs to be copy on write - enable IR snapshots for recompilation based on callsite type specialization. [not enabled by default, hidden by a flag for now] Reviewed-by: jlaskey, hannesw ! bin/jjs ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/tools/Shell.java + test/script/basic/paramspec.js + test/script/basic/paramspec.js.EXPECTED ! test/script/basic/runsunspider.js + test/script/currently-failing/logcoverage.js - test/script/trusted/logcoverage.js Changeset: 829b06307fb2 Author: lagergren Date: 2013-05-03 16:01 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/829b06307fb2 8013871: mem usage histograms enabled with compiler logging level set to more specific than or equals to info when --print-mem-usage flag is used Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/ir/debug/ClassHistogramElement.java + src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/tools/Shell.java Changeset: c0f0033d7b08 Author: hannesw Date: 2013-05-03 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c0f0033d7b08 8013878: ClassCastException in Regex Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8013878.js + test/script/basic/JDK-8013878.js.EXPECTED Changeset: f98d22fa3cbc Author: hannesw Date: 2013-05-03 22:48 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f98d22fa3cbc 8013873: Regexp regression for escaped dash in character class Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8013873.js + test/script/basic/JDK-8013873.js.EXPECTED Changeset: f3dcb12c8439 Author: hannesw Date: 2013-05-03 22:50 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f3dcb12c8439 8013874: Function argument's prototype seem cached and wrongly reused Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/PropertyMap.java + test/script/basic/JDK-8013874.js + test/script/basic/JDK-8013874.js.EXPECTED Changeset: 544e17632e96 Author: lagergren Date: 2013-05-07 14:36 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/544e17632e96 8013913: Removed Source field from all nodes except FunctionNode in order to save footprint Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java - src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java Changeset: fb1d7ea3e1b6 Author: lagergren Date: 2013-05-07 14:43 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/fb1d7ea3e1b6 8013914: Removed explicit LineNumberNodes that were too brittle when code moves around, and also introduced unnecessary footprint. Introduced the Statement node and fixed dead code elimination issues that were discovered by the absense of labels for LineNumberNodes. Reviewed-by: jlaskey, attila ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java - src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java + src/jdk/nashorn/internal/ir/Statement.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/no_line_numbers.js + test/script/basic/no_line_numbers.js.EXPECTED Changeset: d28180d97c61 Author: attila Date: 2013-05-08 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d28180d97c61 8013912: Nashorn needs to reuse temporary symbols Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java + src/jdk/nashorn/internal/ir/TemporarySymbols.java ! src/jdk/nashorn/internal/ir/TypeOverride.java Changeset: 18ce1cd3026c Author: attila Date: 2013-05-08 16:48 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/18ce1cd3026c 8014225: Rerun only failed 262 tests Reviewed-by: jlaskey, lagergren ! make/project.properties ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java Changeset: 9073bcc4307b Author: lagergren Date: 2013-05-10 13:16 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9073bcc4307b 8014329: Slim down the label stack structure in CodeGenerator Reviewed-by: attila, jlaskey ! .hgignore ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java Changeset: 098a4cedcaf2 Author: attila Date: 2013-05-14 12:39 +0200 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/098a4cedcaf2 8014492: Make NashornLinker public Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java Changeset: 264bb0af9e4e Author: jlaskey Date: 2013-05-14 09:05 -0300 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/264bb0af9e4e Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - src/jdk/nashorn/internal/runtime/SpillProperty.java - test/script/trusted/logcoverage.js Changeset: 6b9f41203800 Author: lana Date: 2013-05-17 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/6b9f41203800 Merge - src/jdk/nashorn/internal/ir/LineNumberNode.java - src/jdk/nashorn/internal/ir/Location.java - src/jdk/nashorn/internal/runtime/SpillProperty.java - test/script/trusted/logcoverage.js From gnu.andrew at redhat.com Tue May 21 20:47:49 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 May 2013 16:47:49 -0400 (EDT) Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <5194B3BB.7070002@oracle.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> <51904E2B.2050505@oracle.com> <610430170.2257586.1368631903161.JavaMail.root@redhat.com> <5194B3BB.7070002@oracle.com> Message-ID: <1865898459.5517231.1369169269743.JavaMail.root@redhat.com> ----- Original Message ----- > On 16/05/2013 1:31 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 11/05/2013 2:53 AM, Andrew Hughes wrote: > >> > >>> I have offered a very simple solution to that problem to which no-one has > >>> yet > >>> given any reason as to why we should not implemented it; simply add a > >>> HotSpot tree > >>> where pushes can be made prior to JPRT runs, then perform the JPRT runs > >>> on > >>> the commits > >>> in that tree before merging to the main HotSpot tree. Problem solved. > >> > >> You need one of these repos for each of the hotspot group repos, > >> otherwise the changesets won't be correct. > > > > I'm not sure I follow this. I envision this repository as being equivalent > > to e.g. hotspot-gc and merged into the main HotSpot tree in the same way. > > The group repos, like hotspot-gc, only accept changes that pass JPRT and > only sync up to hotspot-main after successful bouts of nightly testing. > Your proposed repo would need an equivalent level of testing before > changes could go straight to hotspot-main, so I can only see it working > if it is treated as a child of one of the existing group repos and so we > have: > > external repo -> jprt -> group repo [testing] -> jprt -> hotspot-main > Why do they need to be run through jprt twice? external repo -> jprt -> hotspot-main seems sufficient to me. > But as we have multiple group repos you then need an external repo per > group - which in turn will require a "gatekeeper" from each group to > manage the logistics of the actual jprt submissions and keeping things > in sync. > > David > ----- > > >> You also need an Oracle > >> employee to then push the change through JPRT - and that would be a lot > >> more effort than the existing processes as "we" would need to clone the > >> external repo first, re-parent the clone to the group repo, re-sync from > >> parent if needed, then do JPRT submit. Plus you need someone to update > >> these repos each time the "parent" gets updated. > >> > > > > I'm not saying it's an ideal solution; the ideal would be to allow everyone > > to submit their own JPRT runs. But, in six years, there seems to be have > > been no progress on this from an external standpoint. > > > >> So a simple enough idea, but the logistics are more complex. > >> > >> David > >> > > > -- 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 gnu.andrew at redhat.com Tue May 21 20:49:42 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 May 2013 16:49:42 -0400 (EDT) Subject: Disable overrides during jdk build In-Reply-To: <5190FB86.3050402@oracle.com> References: <5190F060.8090604@oracle.com> <5190F7A3.9060201@oracle.com> <5190FB86.3050402@oracle.com> Message-ID: <952269397.5517725.1369169382225.JavaMail.root@redhat.com> ----- Original Message ----- > On 13/05/2013 15:24, Maurizio Cimadamore wrote: > > I think it makes sense, esp. if the messages appear to be redundant. The > > compiler logic is very strict and there are cases where it comes down to > > guessing user intent and compilers are notoriously bad at doing that. In > > the long term, I'd like to see @SuppressWarnings("overrides") applied in > > those cases where the impl knows what it's doing. > > Agreed. Tackling warnings, on a per area basis, is something that we > need to spend more time on. > > I have not taken a look at the reason for the specific overrides > warnings. It is just that it appears the intent of the new build was to > suppress as many warnings as necessary, to make the output reasonable. > Since this warning was not in existence at the time, I could not be > suppressed. > > @SuppressWarnings("overrides") can be added, where appropriate, during > future warning cleanup events. > Is there an option in the new build to turn on all warnings, as there was in the old (JAVAC_MAX_WARNINGS if I recall correctly)? > -Chris. > > > > > Maurizio > > > > On 13/05/13 14:53, Chris Hegarty wrote: > >> Please hold your fire! This is not a suggestion to about general > >> handling of warnings during the build, just a specific gripe I have > >> when trying to find genuine build failures among the noise. > >> > >> Would there be any objection to adding '-overrides' to the jdk build? > >> > >> This lint warning was added after the new build was introduced. I > >> suspect it would have been suppressed originally if it was supported > >> at the time. > >> > >> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk > >> --- a/makefiles/Setup.gmk > >> +++ b/makefiles/Setup.gmk > >> @@ -23,7 +23,7 @@ > >> # questions. > >> # > >> > >> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > >> > >> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides > >> > >> > >> # The generate old bytecode javac setup uses the new compiler to > >> compile for the > >> # boot jdk to generate tools that need to be run with the boot jdk. > >> > >> -Chris. > >> > >> P.S. how to handle warnings generally will have to be addressed at > >> some point, but I am not making any proposal at this time. > > > -- 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 gnu.andrew at redhat.com Tue May 21 20:54:16 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 May 2013 16:54:16 -0400 (EDT) Subject: Windows configure "issues" In-Reply-To: <519BC439.3050201@redhat.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> Message-ID: <712962147.5518935.1369169656380.JavaMail.root@redhat.com> ----- Original Message ----- > On 05/21/2013 04:55 PM, Volker Simonis wrote: > > > I always felt that having the build instructions checked in into the > > repository is somewhat to heavyweight. > > There are two good reasons to do this. > > Firstly, it's a free software tradition: I expect to find a README with > build instructions in the repo. Secondly, the build instructions will > change over time, so of they're on a Wiki there will have to be > multiple versions. > > Andrew. > Another reason is it makes the software self-contained; I don't need Internet access and a web browser to be able to build it. -- 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 dalibor.topic at oracle.com Tue May 21 21:06:09 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 21 May 2013 23:06:09 +0200 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <1865898459.5517231.1369169269743.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> <51904E2B.2050505@oracle.com> <610430170.2257586.1368631903161.JavaMail.root@redhat.com> <5194B3BB.7070002@oracle.com> <1865898459.5517231.1369169269743.JavaMail.root@redhat.com> Message-ID: <519BE1C1.1030402@oracle.com> On 5/21/13 10:47 PM, Andrew Hughes wrote: > Why do they need to be run through jprt twice? > > external repo -> jprt -> hotspot-main > > seems sufficient to me. For the same reason jdk8-external wouldn't work. That's not how the flow of changes is set up to go - it's from the lowest rung upwards to the highest (and back), not sideways across. ;) cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From david.katleman at oracle.com Tue May 21 21:51:04 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 21 May 2013 21:51:04 +0000 Subject: hg: jdk8/build/hotspot: 46 new changesets Message-ID: <20130521215241.53E9B48C1D@hg.openjdk.java.net> Changeset: 6114c49b31b5 Author: amurillo Date: 2013-05-10 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6114c49b31b5 8014279: new hotspot build - hs25-b33 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 712a1e9c91f3 Author: coleenp Date: 2013-05-07 09:46 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/712a1e9c91f3 8013063: nsk/jvmti/RetransformClasses/retransform001 failed debug version on os::free Summary: Clear out class_file_bytes so they aren't deallocated twice Reviewed-by: dcubed, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4674e409a9e6 Author: coleenp Date: 2013-05-07 18:51 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4674e409a9e6 8014024: NPG: keep compiled ic methods from being deallocated in redefine classes Summary: Walk the compiledIC relocation records to keep Method* from being deallocated. Reviewed-by: dlong, kvn ! src/share/vm/code/nmethod.cpp Changeset: a1cc1d1e7ce5 Author: coleenp Date: 2013-05-07 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a1cc1d1e7ce5 Merge Changeset: 28ae1d38d296 Author: coleenp Date: 2013-05-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/28ae1d38d296 Merge Changeset: 64340da5b68c Author: hseigel Date: 2013-05-08 08:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/64340da5b68c 8007018: RFE: -XX:+UseLargePages does not work with CDS Summary: Remove command line restriction. It should just work. Reviewed-by: ctornqvi, coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: cbfe859bd244 Author: sla Date: 2013-05-08 15:37 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cbfe859bd244 8013591: compiler/ciReplay/TestSA.sh fails in nightly Reviewed-by: coleenp, rbackman, dholmes ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java Changeset: 0dc028fd5101 Author: sla Date: 2013-05-08 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0dc028fd5101 Merge Changeset: 39ead0411f07 Author: bharadwaj Date: 2013-05-08 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/39ead0411f07 8013875: Incorrect vtable index being set during methodHandle creation for static Summary: Set vtable index as appropriate for static interface methods and for interface methods invoked via invokespecial. To be improved in a later enhancement to CallInfo. Reviewed-by: jrose, twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 711016f146fd Author: dholmes Date: 2013-05-08 19:28 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/711016f146fd 8006997: ContendedPaddingWidth should be range-checked Summary: Constrain between zero and 8K Reviewed-by: dholmes, rbackman Contributed-by: Aleksey Shipilev ! src/share/vm/runtime/arguments.cpp Changeset: 9b77ca4ce35e Author: dholmes Date: 2013-05-08 19:38 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9b77ca4ce35e Merge ! src/share/vm/runtime/arguments.cpp Changeset: c272092594bd Author: dholmes Date: 2013-05-08 21:06 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c272092594bd Merge Changeset: 0b7f78069732 Author: rbackman Date: 2013-05-08 11:21 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0b7f78069732 8008255: jvmtiExport.cpp::post_to_env() does not check malloc() return Reviewed-by: coleenp, dholmes, sla ! src/share/vm/prims/jvmtiExport.cpp Changeset: 735c995bf1a1 Author: rbackman Date: 2013-05-13 07:53 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/735c995bf1a1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 92ef81e2f571 Author: minqi Date: 2013-05-10 08:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/92ef81e2f571 8003557: NPG: Klass* const k should be const Klass* k. Summary: With NPG, const KlassOop klass which is in fact a definition converted to Klass* const, which is not the original intention. The right usage is converting them to const Klass*. Reviewed-by: coleenp, kvn Contributed-by: yumin.qi at oracle.com ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 1fcfc045b229 Author: minqi Date: 2013-05-10 19:30 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1fcfc045b229 Merge Changeset: 8b40495b9381 Author: minqi Date: 2013-05-13 18:08 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8b40495b9381 Merge ! src/share/vm/oops/method.hpp Changeset: 43083e670adf Author: coleenp Date: 2013-05-13 15:37 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/43083e670adf 8005056: NPG: Crash after redefining java.lang.Object Summary: Need to walk array class vtables replacing old methods too if j.l.o redefined Reviewed-by: sspitsyn, dcubed, ctornqvi ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp + test/runtime/RedefineObject/Agent.java + test/runtime/RedefineObject/TestRedefineObject.java ! test/testlibrary/ClassFileInstaller.java Changeset: a9270d9ecb13 Author: shade Date: 2013-05-14 11:34 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a9270d9ecb13 8014448: Purge PrintCompactFieldsSavings Summary: Remove obsolete debugging code. Reviewed-by: dholmes, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: f944ba972151 Author: hseigel Date: 2013-05-14 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f944ba972151 8014138: Add VM option to facilitate the writing of CDS tests Summary: Added the -XX:SharedArchiveFile option. Reviewed-by: coleenp, ccheung, acorn, dcubed, zgu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp + test/runtime/SharedArchiveFile/SharedArchiveFile.java Changeset: f9be75d21404 Author: minqi Date: 2013-05-14 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f9be75d21404 8012902: remove use of global operator new - take 2 Summary: The fix of 8010992, disable use of global operator new and new[] which caused failure on some tests. This takes two of the bugs also add ALLOW_OPERATOR_NEW_USAGE to prevent crash for third party code calling operator new of jvm on certain platforms. Reviewed-by: coleenp, dholmes, zgu Contributed-by: yumin.qi at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/vm.make ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 513a5298c1dd Author: minqi Date: 2013-05-14 17:33 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/513a5298c1dd Merge Changeset: d15464bfd4d0 Author: roland Date: 2013-05-03 09:32 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d15464bfd4d0 8012037: Test8009761.java "Failed: init recursive calls: 7224. After deopt 58824" Summary: test shouldn't be run with a modified CompileThreshold Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: e76dd894b984 Author: roland Date: 2013-04-24 14:26 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e76dd894b984 8012292: optimized build with GCC broken Summary: Some #ifndef PRODUCT should be #ifdef ASSERT Reviewed-by: kvn, twisti Contributed-by: gdub ! make/jprt.properties ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: d73c88e524ff Author: kvn Date: 2013-05-03 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d73c88e524ff Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: f0bc60565ba8 Author: twisti Date: 2013-05-06 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f0bc60565ba8 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact Reviewed-by: jrose, kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: aabf54ccedb1 Author: twisti Date: 2013-05-06 19:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aabf54ccedb1 8008772: remove gamma launcher Reviewed-by: kvn, neliasso, ctornqvi ! make/Makefile ! make/bsd/makefiles/buildtree.make - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make + make/hotspot.script ! make/linux/makefiles/buildtree.make - make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make - make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make - make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/projectfiles/common/Makefile - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h Changeset: 6f3fd5150b67 Author: kvn Date: 2013-05-08 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6f3fd5150b67 6934604: enable parts of EliminateAutoBox by default Summary: Resurrected autobox elimination code and enabled part of it by default. Reviewed-by: roland, twisti ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/6934604/TestByteBoxing.java + test/compiler/6934604/TestDoubleBoxing.java + test/compiler/6934604/TestFloatBoxing.java + test/compiler/6934604/TestIntBoxing.java + test/compiler/6934604/TestLongBoxing.java + test/compiler/6934604/TestShortBoxing.java Changeset: 70120f47d403 Author: kvn Date: 2013-05-09 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/70120f47d403 8014189: JVM crash with SEGV in ConnectionGraph::record_for_escape_analysis() Summary: Add NULL checks and asserts for Type::make_ptr() returned value. Reviewed-by: twisti ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/subnode.cpp Changeset: 8bcfd9ce2c6b Author: twisti Date: 2013-05-13 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8bcfd9ce2c6b Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 1da5d70655e9 Author: kvn Date: 2013-05-13 14:36 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1da5d70655e9 8014286: failed java/lang/Math/DivModTests.java after 6934604 changes Summary: Corrected escape state for the result of boxing method. Added force inlining executed boxing methods. Reviewed-by: twisti ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/escape.cpp Changeset: cd6f6fccd287 Author: iignatyev Date: 2013-05-15 22:44 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cd6f6fccd287 8014068: TEST_BUG: compiler/ciReplay/TestSA.sh fails on Windows: core wasn't generated Reviewed-by: kvn ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/common.sh Changeset: e484fe2abebd Author: twisti Date: 2013-05-16 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e484fe2abebd Merge - make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/quickSort.cpp Changeset: 7a95933197d0 Author: tschatzl Date: 2013-05-13 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7a95933197d0 8014058: Regression tests for 8006088 Summary: The patch for 8006088 misses regression tests after a merge error, this CR provides them. Reviewed-by: jwilhelm, tamao, jmasa ! src/share/vm/memory/collectorPolicy.cpp + test/gc/arguments/TestCMSHeapSizeFlags.java + test/gc/arguments/TestG1HeapSizeFlags.java + test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMinInitialErgonomics.java + test/gc/arguments/TestParallelHeapSizeFlags.java + test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 4868caa99ecf Author: brutisso Date: 2013-05-13 14:09 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4868caa99ecf 8014339: Improve assert and remove some dead code from parMarkBitMap.hpp/cpp Reviewed-by: stefank, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 0a2986f36965 Author: tschatzl Date: 2013-05-14 17:08 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0a2986f36965 8014489: tests/gc/arguments/Test(Serial|CMS|Parallel|G1)HeapSizeFlags jtreg tests invoke wrong class Summary: Some jtreg tests reference unknown classes in the @run and @build lines. This change fixes them. Reviewed-by: stefank, ehelin ! test/gc/arguments/TestCMSHeapSizeFlags.java ! test/gc/arguments/TestG1HeapSizeFlags.java ! test/gc/arguments/TestParallelHeapSizeFlags.java ! test/gc/arguments/TestSerialHeapSizeFlags.java Changeset: 12f651e29f6b Author: tschatzl Date: 2013-05-15 11:05 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/12f651e29f6b 6843347: Boundary values in some public GC options cause crashes Summary: Setting some public integer options to specific values causes crashes or undefined GC behavior. This patchset adds the necessary argument checking for these options. Reviewed-by: jmasa, brutisso ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eba99d16dc6f Author: tamao Date: 2013-05-15 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/eba99d16dc6f 8007763: Refactoring: split up compute_generation_free_space() into two functions for class PSAdaptiveSizePolicy Summary: split up compute_generation_free_space() into two functions: compute_eden_space_size() + compute_old_gen_free_space(), each of which (if needed) can be reused without executing an overhead of the other. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: bed55d125e37 Author: johnc Date: 2013-05-15 22:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bed55d125e37 8014408: G1: crashes with assert assert(prev_committed_card_num == _committed_max_card_num) failed Summary: Mismatch in the card number calculation between next and previous committed sizes of the card counts table. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CardCounts.hpp Changeset: 05a17f270c7e Author: tschatzl Date: 2013-05-16 13:02 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/05a17f270c7e 8014240: G1: Add remembered set size information to output of G1PrintRegionLivenessInfo Summary: Improve the output of G1PrintRegionLivenessInfo by adding a per-region remembered set size information column Reviewed-by: jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 48391ab0687e Author: johnc Date: 2013-05-16 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/48391ab0687e 8010738: G1: Output for full GCs with +PrintGCDetails should contain perm gen size/meta data change info Summary: Include metaspace information (used, allocated, reserved) in the PrintGCDetails output for full GCs. Reviewed-by: poonam, jmasa, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + test/gc/g1/TestPrintGCDetails.java Changeset: acac2b03a07f Author: tschatzl Date: 2013-05-16 23:51 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/acac2b03a07f 8014765: VM exits if MaxTenuringThreshold is set below the default InitialTenuringThreshold, and InitialTenuringThreshold is not set Summary: The VM exits when the condition in the subject line applies. The fix sets InitialTenuringThreshold to MaxTenuringThreshold if it is larger than MaxTenuringThreshold and InitialTenuringThreshold has not been set (is default). Reviewed-by: jwilhelm, jmasa, brutisso, johnc ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestInitialTenuringThreshold.java Changeset: 2958af1d8c5a Author: jwilhelm Date: 2013-05-17 06:01 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2958af1d8c5a Merge ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2f9ac66165e6 Author: jwilhelm Date: 2013-05-17 08:00 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2f9ac66165e6 Merge - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: b19517cecc2e Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b19517cecc2e Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: 7cbdf0e3725c Author: amurillo Date: 2013-05-17 08:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7cbdf0e3725c Added tag hs25-b33 for changeset b19517cecc2e ! .hgtags From gnu.andrew at redhat.com Tue May 21 21:11:19 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 May 2013 17:11:19 -0400 (EDT) Subject: Windows configure "issues" In-Reply-To: References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> Message-ID: <1065491952.5523027.1369170679839.JavaMail.root@redhat.com> ----- Original Message ----- > On Tue, May 21, 2013 at 9:00 PM, Andrew Haley wrote: > > > On 05/21/2013 04:55 PM, Volker Simonis wrote: > > > > > I always felt that having the build instructions checked in into the > > > repository is somewhat to heavyweight. > > > > There are two good reasons to do this. > > > > Firstly, it's a free software tradition: I expect to find a README with > > build instructions in the repo. Secondly, the build instructions will > > change over time, so of they're on a Wiki there will have to be > > multiple versions. > > > > > You're right, but the problem is that the process of updating the > instructions is much too heavyweight (getting a BugID, getting reviews, > getting a sponsor who will push the changes,..). True. But it's the process that needs to be changed in that case, because it also applies to other patches. Working around it doesn't help. A sponsor is only needed for those without commit access. It's pretty easy to get a review. Are we any further to being able to get access to the bug system, which is long overdue? Thanks, -- 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 mark.reinhold at oracle.com Tue May 21 22:25:58 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 21 May 2013 15:25:58 -0700 Subject: Windows configure "issues" In-Reply-To: <712962147.5518935.1369169656380.JavaMail.root@redhat.com> References: , <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com>, , , <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com>, , <519BC439.3050201@redhat.com>, <712962147.5518935.1369169656380.JavaMail.root@redhat.com> Message-ID: <20130521152558.514226@eggemoggin.niobe.net> 2013/5/21 6:54 -0700, gnu.andrew at redhat.com: >> On 05/21/2013 04:55 PM, Volker Simonis wrote: >>> I always felt that having the build instructions checked in into the >>> repository is somewhat to heavyweight. >> >> There are two good reasons to do this. >> >> Firstly, it's a free software tradition: I expect to find a README with >> build instructions in the repo. Secondly, the build instructions will >> change over time, so of they're on a Wiki there will have to be >> multiple versions. >> >> Andrew. > > Another reason is it makes the software self-contained; I don't need Internet > access and a web browser to be able to build it. I agree, on all three counts. How-to-build documents, just like unit tests, belong with the code to which they apply. Posting them on a wiki just increases inconvenience and invites confusion. - Mark From neugens.limasoftware at gmail.com Tue May 21 23:02:10 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 22 May 2013 01:02:10 +0200 Subject: Windows configure "issues" In-Reply-To: <20130521152558.514226@eggemoggin.niobe.net> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> <712962147.5518935.1369169656380.JavaMail.root@redhat.com> <20130521152558.514226@eggemoggin.niobe.net> Message-ID: I fully agree with this point of view. I don't think that this conflict with the idea of a wiki companion, this can be done and surely would be of help, but copy-paste instructions should be with the code. I also think that since we need to keep in sync the readme with the wiki, the problem with the overhead of the process doesn't really change (with the risk of then having an outdated readme). Cheers, Mario Il giorno 22/mag/2013 00:26, ha scritto: > 2013/5/21 6:54 -0700, gnu.andrew at redhat.com: > >> On 05/21/2013 04:55 PM, Volker Simonis wrote: > >>> I always felt that having the build instructions checked in into the > >>> repository is somewhat to heavyweight. > >> > >> There are two good reasons to do this. > >> > >> Firstly, it's a free software tradition: I expect to find a README with > >> build instructions in the repo. Secondly, the build instructions will > >> change over time, so of they're on a Wiki there will have to be > >> multiple versions. > >> > >> Andrew. > > > > Another reason is it makes the software self-contained; I don't need > Internet > > access and a web browser to be able to build it. > > I agree, on all three counts. How-to-build documents, just like unit > tests, belong with the code to which they apply. Posting them on a > wiki just increases inconvenience and invites confusion. > > - Mark > From david.holmes at oracle.com Wed May 22 04:20:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2013 14:20:45 +1000 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519B5F7A.3020802@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> <519B4413.7000000@oracle.com> <519B5AD9.8040506@oracle.com> <519B5F7A.3020802@oracle.com> Message-ID: <519C479D.6090200@oracle.com> On 21/05/2013 9:50 PM, Erik Joelsson wrote: > Looks good to me. So has a bug been filed yet? :) I think some further investigation is still needed because gensrc_jobjc is being used in some places and not others and I'd want to verify they are all supposed to be the same thing. David > /Erik > > On 2013-05-21 13:30, Alan Bateman wrote: >> On 21/05/2013 10:53, Erik Joelsson wrote: >>> In the old build, JObjC.jar was built completely differently from all >>> other java classes, by an ant script. We kept the source/target 1.5 >>> when converting to the new build to keep the builds equal. I very >>> much doubt there is a reason for it now though. It looks like left >>> over legacy to me. >>> >>> The simplest fix for you would be to change the outputdir of the >>> generated sources for jobjc to something like gensrc_jobjc. >>> >>> I would really like to see the whole special handling of jobjc >>> compilation removed. >>> >>> /Erik >> It would be good to get this cleaned up or removed. >> >> For now I'm using the attached patch to ensure that the classes are >> generated to gensrc_jobjc. >> >> -Alan. >> >> >> diff -r b9b26b424bfc makefiles/CompileJavaClasses.gmk >> --- a/makefiles/CompileJavaClasses.gmk Sat May 18 18:55:56 2013 -0700 >> +++ b/makefiles/CompileJavaClasses.gmk Tue May 21 12:05:43 2013 +0100 >> @@ -342,7 +342,7 @@ >> DISABLE_SJAVAC:=true,\ >> SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ >> $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ >> - $(JDK_OUTPUTDIR)/gensrc, \ >> + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ >> INCLUDES := com/apple/jobjc,\ >> EXCLUDES := tests/java/com/apple/jobjc,\ >> BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ >> @@ -355,7 +355,7 @@ >> SETUP:=GENERATE_JDKBYTECODE,\ >> SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ >> $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ >> - $(JDK_OUTPUTDIR)/gensrc, \ >> + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ >> INCLUDES := com/apple/jobjc,\ >> EXCLUDES := tests/java/com/apple/jobjc,\ >> BIN:=$(JDK_OUTPUTDIR)/jobjc_classes_headers,\ >> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ >> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ >> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff GensrcJ >> GensrcJDWP.gmk GensrcJObjC.gmk >> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff >> GensrcJObjC.gmk >> diff -r b9b26b424bfc makefiles/GensrcJObjC.gmk >> --- a/makefiles/GensrcJObjC.gmk Sat May 18 18:55:56 2013 -0700 >> +++ b/makefiles/GensrcJObjC.gmk Tue May 21 12:05:52 2013 +0100 >> @@ -104,9 +104,9 @@ >> >> # The generator delets all files in the target dir so it has to work >> in its >> # own dir and have the files copied over to gensrc aftewards. >> -$(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files : $(JOBJC_TMP)/_the.generator >> +$(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files : >> $(JOBJC_TMP)/_the.generator >> $(MKDIR) -p $(@D) >> $(CP) -rp $(JOBJC_DST)/* $(@D) >> $(TOUCH) $@ >> >> -GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files >> +GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files From david.holmes at oracle.com Wed May 22 04:40:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2013 14:40:40 +1000 Subject: Preserving changeset authorship (was Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds) In-Reply-To: <1865898459.5517231.1369169269743.JavaMail.root@redhat.com> References: <1296964538.372074.1364921773405.JavaMail.root@redhat.com> <630646019.8220662.1367935070589.JavaMail.root@redhat.com> <1203652896.9438216.1368115806661.JavaMail.root@redhat.com> <20130509144741.733107@eggemoggin.niobe.net> <1682802011.10040559.1368204820543.JavaMail.root@redhat.com> <51904E2B.2050505@oracle.com> <610430170.2257586.1368631903161.JavaMail.root@redhat.com> <5194B3BB.7070002@oracle.com> <1865898459.5517231.1369169269743.JavaMail.root@redhat.com> Message-ID: <519C4C48.1050600@oracle.com> On 22/05/2013 6:47 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 16/05/2013 1:31 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> On 11/05/2013 2:53 AM, Andrew Hughes wrote: >>>> >>>>> I have offered a very simple solution to that problem to which no-one has >>>>> yet >>>>> given any reason as to why we should not implemented it; simply add a >>>>> HotSpot tree >>>>> where pushes can be made prior to JPRT runs, then perform the JPRT runs >>>>> on >>>>> the commits >>>>> in that tree before merging to the main HotSpot tree. Problem solved. >>>> >>>> You need one of these repos for each of the hotspot group repos, >>>> otherwise the changesets won't be correct. >>> >>> I'm not sure I follow this. I envision this repository as being equivalent >>> to e.g. hotspot-gc and merged into the main HotSpot tree in the same way. >> >> The group repos, like hotspot-gc, only accept changes that pass JPRT and >> only sync up to hotspot-main after successful bouts of nightly testing. >> Your proposed repo would need an equivalent level of testing before >> changes could go straight to hotspot-main, so I can only see it working >> if it is treated as a child of one of the existing group repos and so we >> have: >> >> external repo -> jprt -> group repo [testing] -> jprt -> hotspot-main >> > > Why do they need to be run through jprt twice? Before the push up there is a sync down and we need to be sure that the new combination is still working. > external repo -> jprt -> hotspot-main > > seems sufficient to me. No, as I already said there is a heap of testing that happens to a group repo before it can be pushed to main. So the only way to avoid going through a group repo is to have the same testing applied as a group repo. David ----- > >> But as we have multiple group repos you then need an external repo per >> group - which in turn will require a "gatekeeper" from each group to >> manage the logistics of the actual jprt submissions and keeping things >> in sync. >> >> David >> ----- >> >>>> You also need an Oracle >>>> employee to then push the change through JPRT - and that would be a lot >>>> more effort than the existing processes as "we" would need to clone the >>>> external repo first, re-parent the clone to the group repo, re-sync from >>>> parent if needed, then do JPRT submit. Plus you need someone to update >>>> these repos each time the "parent" gets updated. >>>> >>> >>> I'm not saying it's an ideal solution; the ideal would be to allow everyone >>> to submit their own JPRT runs. But, in six years, there seems to be have >>> been no progress on this from an external standpoint. >>> >>>> So a simple enough idea, but the logistics are more complex. >>>> >>>> David >>>> >>> >> > From erik.joelsson at oracle.com Wed May 22 07:45:33 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 May 2013 09:45:33 +0200 Subject: [PATCH] Provide debugging information for programs In-Reply-To: <434361871.5475325.1369161116141.JavaMail.root@redhat.com> References: <434361871.5475325.1369161116141.JavaMail.root@redhat.com> Message-ID: <519C779D.2030605@oracle.com> This looks good to me. 8015087: Provide debugging information for programs /Erik On 2013-05-21 20:31, Andrew Hughes wrote: > Hi all, > > The following webrevs: > > Root: http://cr.openjdk.java.net/~andrew/build/debugging/webrev.02/ > JDK: http://cr.openjdk.java.net/~andrew/build/debugging/webrev.03/ > > 1. Enable debugging on programs for OpenJDK builds > (unclear why this is disabled; the comment says "Programs don't get the debug symbols added in the old build. It's not clear if this is intentional" but all our builds of 6& 7 have debug info, making this a regression) > 2. Turn on debugging symbols for unpack200 and jexec which seem to have been missed. > > Ok? If so, can I have a bug ID for this, please? > > Thanks, From erik.joelsson at oracle.com Wed May 22 07:48:31 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 May 2013 09:48:31 +0200 Subject: Disable overrides during jdk build In-Reply-To: <952269397.5517725.1369169382225.JavaMail.root@redhat.com> References: <5190F060.8090604@oracle.com> <5190F7A3.9060201@oracle.com> <5190FB86.3050402@oracle.com> <952269397.5517725.1369169382225.JavaMail.root@redhat.com> Message-ID: <519C784F.7040204@oracle.com> On 2013-05-21 22:49, Andrew Hughes wrote: > ----- Original Message ----- >> On 13/05/2013 15:24, Maurizio Cimadamore wrote: >>> I think it makes sense, esp. if the messages appear to be redundant. The >>> compiler logic is very strict and there are cases where it comes down to >>> guessing user intent and compilers are notoriously bad at doing that. In >>> the long term, I'd like to see @SuppressWarnings("overrides") applied in >>> those cases where the impl knows what it's doing. >> Agreed. Tackling warnings, on a per area basis, is something that we >> need to spend more time on. >> >> I have not taken a look at the reason for the specific overrides >> warnings. It is just that it appears the intent of the new build was to >> suppress as many warnings as necessary, to make the output reasonable. >> Since this warning was not in existence at the time, I could not be >> suppressed. >> >> @SuppressWarnings("overrides") can be added, where appropriate, during >> future warning cleanup events. >> > Is there an option in the new build to turn on all warnings, as there > was in the old (JAVAC_MAX_WARNINGS if I recall correctly)? > No, this is currently missing. /Erik >> -Chris. >> >>> Maurizio >>> >>> On 13/05/13 14:53, Chris Hegarty wrote: >>>> Please hold your fire! This is not a suggestion to about general >>>> handling of warnings during the build, just a specific gripe I have >>>> when trying to find genuine build failures among the noise. >>>> >>>> Would there be any objection to adding '-overrides' to the jdk build? >>>> >>>> This lint warning was added after the new build was introduced. I >>>> suspect it would have been suppressed originally if it was supported >>>> at the time. >>>> >>>> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk >>>> --- a/makefiles/Setup.gmk >>>> +++ b/makefiles/Setup.gmk >>>> @@ -23,7 +23,7 @@ >>>> # questions. >>>> # >>>> >>>> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >>>> >>>> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides >>>> >>>> >>>> # The generate old bytecode javac setup uses the new compiler to >>>> compile for the >>>> # boot jdk to generate tools that need to be run with the boot jdk. >>>> >>>> -Chris. >>>> >>>> P.S. how to handle warnings generally will have to be addressed at >>>> some point, but I am not making any proposal at this time. From Alan.Bateman at oracle.com Wed May 22 08:04:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 May 2013 09:04:45 +0100 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519C479D.6090200@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> <519B4413.7000000@oracle.com> <519B5AD9.8040506@oracle.com> <519B5F7A.3020802@oracle.com> <519C479D.6090200@oracle.com> Message-ID: <519C7C1D.6090404@oracle.com> On 22/05/2013 05:20, David Holmes wrote: > On 21/05/2013 9:50 PM, Erik Joelsson wrote: >> Looks good to me. > > So has a bug been filed yet? :) > > I think some further investigation is still needed because > gensrc_jobjc is being used in some places and not others and I'd want > to verify they are all supposed to be the same thing. > > David I don't think there is a bug a this, I only ran into it because of a patch-in-the-works that changes code generated to gensrc. I can include the change in my patch or I can create a separate bug. I do agree that further investigation is required, if nothing else, this part of the build needs clean-up. -Alan From erik.joelsson at oracle.com Wed May 22 08:05:17 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 May 2013 10:05:17 +0200 Subject: BUILD_JOBJC woes on Mac In-Reply-To: <519C479D.6090200@oracle.com> References: <5198E277.9090202@oracle.com> <519AFF85.9030602@oracle.com> <519B1F10.6090400@oracle.com> <519B23F3.1090700@oracle.com> <519B34A3.4030805@oracle.com> <519B4413.7000000@oracle.com> <519B5AD9.8040506@oracle.com> <519B5F7A.3020802@oracle.com> <519C479D.6090200@oracle.com> Message-ID: <519C7C3D.5060700@oracle.com> On 2013-05-22 06:20, David Holmes wrote: > On 21/05/2013 9:50 PM, Erik Joelsson wrote: >> Looks good to me. > > So has a bug been filed yet? :) > > I think some further investigation is still needed because > gensrc_jobjc is being used in some places and not others and I'd want > to verify they are all supposed to be the same thing. > I was too fast looking at this. After more careful investigation, this is what happens. The source generator for jobjc classes is directed to generate the sources to a separate directory (gensrc_jobjc/src) and the files are then copied into the general gensrc directory. The reason for this is that the generator does a full delete of all files in the target directory before generating sources. If you point the SetupJavaCompilation macro to gensrc_jobjc/src and skip the other changes, it will all work out fine. The copy of the generated sources will not be needed but I would rather keep it for now until we clear up the whole mess. /Erik > David > >> /Erik >> >> On 2013-05-21 13:30, Alan Bateman wrote: >>> On 21/05/2013 10:53, Erik Joelsson wrote: >>>> In the old build, JObjC.jar was built completely differently from all >>>> other java classes, by an ant script. We kept the source/target 1.5 >>>> when converting to the new build to keep the builds equal. I very >>>> much doubt there is a reason for it now though. It looks like left >>>> over legacy to me. >>>> >>>> The simplest fix for you would be to change the outputdir of the >>>> generated sources for jobjc to something like gensrc_jobjc. >>>> >>>> I would really like to see the whole special handling of jobjc >>>> compilation removed. >>>> >>>> /Erik >>> It would be good to get this cleaned up or removed. >>> >>> For now I'm using the attached patch to ensure that the classes are >>> generated to gensrc_jobjc. >>> >>> -Alan. >>> >>> >>> diff -r b9b26b424bfc makefiles/CompileJavaClasses.gmk >>> --- a/makefiles/CompileJavaClasses.gmk Sat May 18 18:55:56 2013 >>> -0700 >>> +++ b/makefiles/CompileJavaClasses.gmk Tue May 21 12:05:43 2013 >>> +0100 >>> @@ -342,7 +342,7 @@ >>> DISABLE_SJAVAC:=true,\ >>> SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ >>> $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ >>> - $(JDK_OUTPUTDIR)/gensrc, \ >>> + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ >>> INCLUDES := com/apple/jobjc,\ >>> EXCLUDES := tests/java/com/apple/jobjc,\ >>> BIN:=$(JDK_OUTPUTDIR)/jobjc_classes,\ >>> @@ -355,7 +355,7 @@ >>> SETUP:=GENERATE_JDKBYTECODE,\ >>> SRC:=$(JDK_TOPDIR)/src/macosx/native/jobjc/src/core/java \ >>> $(JDK_TOPDIR)/src/macosx/native/jobjc/src/runtime-additions/java \ >>> - $(JDK_OUTPUTDIR)/gensrc, \ >>> + $(JDK_OUTPUTDIR)/gensrc_jobjc, \ >>> INCLUDES := com/apple/jobjc,\ >>> EXCLUDES := tests/java/com/apple/jobjc,\ >>> BIN:=$(JDK_OUTPUTDIR)/jobjc_classes_headers,\ >>> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ >>> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ >>> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff >>> GensrcJ >>> GensrcJDWP.gmk GensrcJObjC.gmk >>> dhcp-uk-twvpn-2-vpnpool-10-175-60-135:makefiles ab23780$ hg diff >>> GensrcJObjC.gmk >>> diff -r b9b26b424bfc makefiles/GensrcJObjC.gmk >>> --- a/makefiles/GensrcJObjC.gmk Sat May 18 18:55:56 2013 -0700 >>> +++ b/makefiles/GensrcJObjC.gmk Tue May 21 12:05:52 2013 +0100 >>> @@ -104,9 +104,9 @@ >>> >>> # The generator delets all files in the target dir so it has to work >>> in its >>> # own dir and have the files copied over to gensrc aftewards. >>> -$(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files : $(JOBJC_TMP)/_the.generator >>> +$(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files : >>> $(JOBJC_TMP)/_the.generator >>> $(MKDIR) -p $(@D) >>> $(CP) -rp $(JOBJC_DST)/* $(@D) >>> $(TOUCH) $@ >>> >>> -GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc/_the.jobjc.files >>> +GENSRC_JOBJC += $(JDK_OUTPUTDIR)/gensrc_jobjc/_the.jobjc.files From ahughes at redhat.com Wed May 22 12:49:21 2013 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 22 May 2013 12:49:21 +0000 Subject: hg: jdk8/build: 8015087: Provide debugging information for programs Message-ID: <20130522124921.28A0848C38@hg.openjdk.java.net> Changeset: cb51fb4789ac Author: andrew Date: 2013-05-22 13:49 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/cb51fb4789ac 8015087: Provide debugging information for programs Summary: Enable debugging info on programs in OpenJDK builds Reviewed-by: erikj ! common/makefiles/NativeCompilation.gmk From gnu.andrew at redhat.com Wed May 22 12:50:31 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 22 May 2013 08:50:31 -0400 (EDT) Subject: [PATCH] Provide debugging information for programs In-Reply-To: <519C779D.2030605@oracle.com> References: <434361871.5475325.1369161116141.JavaMail.root@redhat.com> <519C779D.2030605@oracle.com> Message-ID: <824778674.5926862.1369227031369.JavaMail.root@redhat.com> ----- Original Message ----- > This looks good to me. > > 8015087: Provide debugging information for programs > > /Erik > Thanks. Pushed: http://hg.openjdk.java.net/jdk8/build/rev/cb51fb4789ac http://hg.openjdk.java.net/jdk8/build/jdk/rev/f559fadbf491 > On 2013-05-21 20:31, Andrew Hughes wrote: > > Hi all, > > > > The following webrevs: > > > > Root: http://cr.openjdk.java.net/~andrew/build/debugging/webrev.02/ > > JDK: http://cr.openjdk.java.net/~andrew/build/debugging/webrev.03/ > > > > 1. Enable debugging on programs for OpenJDK builds > > (unclear why this is disabled; the comment says "Programs don't get the > > debug symbols added in the old build. It's not clear if this is > > intentional" but all our builds of 6& 7 have debug info, making this a > > regression) > > 2. Turn on debugging symbols for unpack200 and jexec which seem to have > > been missed. > > > > Ok? If so, can I have a bug ID for this, please? > > > > Thanks, > -- 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 ahughes at redhat.com Wed May 22 12:48:20 2013 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 22 May 2013 12:48:20 +0000 Subject: hg: jdk8/build/jdk: 8015087: Provide debugging information for programs Message-ID: <20130522124842.1393C48C37@hg.openjdk.java.net> Changeset: f559fadbf491 Author: andrew Date: 2013-05-22 13:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f559fadbf491 8015087: Provide debugging information for programs Summary: Add missing debug info to unpack200 and jexec Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk From erik.joelsson at oracle.com Wed May 22 15:11:39 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 22 May 2013 15:11:39 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130522151215.092ED48C3F@hg.openjdk.java.net> Changeset: 88d6a20672ac Author: erikj Date: 2013-05-22 10:31 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/88d6a20672ac 8014970: Use open man pages for non commercial builds Reviewed-by: omajid, tbell ! makefiles/Images.gmk Changeset: 169451cf0cc5 Author: erikj Date: 2013-05-22 15:00 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/169451cf0cc5 Merge From david.r.chase at oracle.com Wed May 22 21:12:38 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 22 May 2013 17:12:38 -0400 Subject: Somewhat wonkier Windows problem Message-ID: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> I am persisting in my attempt to compile OpenJDK 8 on Windows 7, using the tools likely to be handy for someone outside Oracle attempting to do this, because our existing directions are borken and need to be fixed, if possible. I'm using VS2012, because that's what someone would normally do in 2013, and I've worked through a couple of issues with that. I'm currently lying about the version number (claiming VS2010) and tinkering with a few header files by-hand to get to the end. I get near the end (linking jvm.dll) and hit: LNK2011 - If you use precompiled headers, LINK requires that all of the object files created with precompiled headers must be linked in. If you have a source file that you use to generate a precompiled header for use with other source files, you now must include the object file created along with the precompiled header. http://msdn.microsoft.com/en-us/library/3ay26wa2(v=vs.110).aspx The cause of this is that (I think) we used precompiled headers for some or all of the adlc tool for the hotspot compiler, and now the linker wants to put them into jvm.dll, just in case, because (apparently) all the precompiled header information lands in one big confusing blob. I'm a little puzzled that this has not occurred before (the error message dates back to VS 2003) but I see no mention of LNK2011 in the bug database, or anything that looks right using various combinations of keywords. David From kellyohair at gmail.com Wed May 22 22:53:07 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Wed, 22 May 2013 15:53:07 -0700 Subject: Somewhat wonkier Windows problem In-Reply-To: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> Message-ID: <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. DLLs created by a newer VS will not like the older VS runtime DLLs. To make a long story short, changing VS compilers is a royal pain, and not trivial. This is why we only recommend VS2010. I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( -kto On May 22, 2013, at 2:12 PM, David Chase wrote: > I am persisting in my attempt to compile OpenJDK 8 on Windows 7, using the tools likely to be handy for someone outside Oracle attempting to do this, because our existing directions are borken and need to be fixed, if possible. > > I'm using VS2012, because that's what someone would normally do in 2013, and I've worked through a couple of issues with that. > I'm currently lying about the version number (claiming VS2010) and tinkering with a few header files by-hand to get to the end. > > I get near the end (linking jvm.dll) and hit: > > LNK2011 - If you use precompiled headers, LINK requires that all of the object files created with precompiled headers must be linked in. If you have a source file that you use to generate a precompiled header for use with other source files, you now must include the object file created along with the precompiled header. > > http://msdn.microsoft.com/en-us/library/3ay26wa2(v=vs.110).aspx > > The cause of this is that (I think) we used precompiled headers for some or all of the adlc tool for the hotspot compiler, and now the linker wants to put them into jvm.dll, just in case, because (apparently) all the precompiled header information lands in one big confusing blob. > > I'm a little puzzled that this has not occurred before (the error message dates back to VS 2003) but I see no mention of LNK2011 in the bug database, or anything that looks right using various combinations of keywords. > > David > From david.r.chase at oracle.com Wed May 22 23:27:08 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 22 May 2013 19:27:08 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> Message-ID: I hope I'm trying to solve a simpler problem, which is just a build, as if I were someone outside Oracle playing with Openjdk. I assume my problems are a subset of the release problem. David On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote: > Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. > > DLLs created by a newer VS will not like the older VS runtime DLLs. > > To make a long story short, changing VS compilers is a royal pain, and not trivial. > This is why we only recommend VS2010. > > I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( > > -kto From kellyohair at gmail.com Wed May 22 23:54:01 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Wed, 22 May 2013 16:54:01 -0700 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> Message-ID: If you accept the fact that the build may complete but not work, then fine. But if you want the JDK you built to actually run, you will probably need to get the new msvcr*dll files placed in the jdk image area (in the bin dirs), manually or via the makefiles. I also vaguely recall some silly thing with VS2012 that it was for Windows 8 only and you needed VS2012sp1 to be able to build for Windows releases before Windows 8? I'm not sure I remember that right. :^( -kto On May 22, 2013, at 4:27 PM, David Chase wrote: > I hope I'm trying to solve a simpler problem, which is just a build, as if I were someone outside Oracle playing with Openjdk. I assume my problems are a subset of the release problem. > > David > > On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote: > >> Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. >> >> DLLs created by a newer VS will not like the older VS runtime DLLs. >> >> To make a long story short, changing VS compilers is a royal pain, and not trivial. >> This is why we only recommend VS2010. >> >> I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( >> >> -kto > From david.r.chase at oracle.com Thu May 23 00:09:37 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 22 May 2013 20:09:37 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> Message-ID: <2923F28C-40A1-4908-A84A-558FBD452405@oracle.com> VS2012, at least the one I downloaded recently, pretends to compile, and since ADLC ran, I think it produces images that run, too, so there is some hope. It darn sure won't run if I don't get the build to complete. Getting the DLLs right, I assume I'll drive off that bridge when I come to it. That's all this is anyhow -- drive into a ditch, get out of the ditch, drive to the next ditch, lather, rinse, repeat. We can't put this off forever, and speaking as someone who's used other open source stuff, it's really annoying when something I want to use declares that I need to install some 2-year-old down-rev stuff to make it work -- especially if I already have the new stuff installed and then get them confused -- for instance, accidentally picking up gcc 4.8 to build, instead of 4.2. David On 2013-05-22, at 7:54 PM, Kelly O'Hair wrote: > If you accept the fact that the build may complete but not work, then fine. > But if you want the JDK you built to actually run, you will probably need to get the new msvcr*dll files placed in the jdk image area (in the bin dirs), manually or via the makefiles. > > I also vaguely recall some silly thing with VS2012 that it was for Windows 8 only and you needed VS2012sp1 to be able to build for Windows releases before Windows 8? I'm not sure I remember that right. :^( > > -kto > > On May 22, 2013, at 4:27 PM, David Chase wrote: > >> I hope I'm trying to solve a simpler problem, which is just a build, as if I were someone outside Oracle playing with Openjdk. I assume my problems are a subset of the release problem. >> >> David >> >> On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote: >> >>> Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. >>> >>> DLLs created by a newer VS will not like the older VS runtime DLLs. >>> >>> To make a long story short, changing VS compilers is a royal pain, and not trivial. >>> This is why we only recommend VS2010. >>> >>> I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( >>> >>> -kto >> > From tim.bell at oracle.com Thu May 23 00:44:25 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 22 May 2013 17:44:25 -0700 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> Message-ID: <519D6669.7090100@oracle.com> We are in the process of evaluating build tool selections for JDK8. For Windows, Anthony Petrov started the work and supplied a patch [1], plus more changes for hotspot. I have successfully completed OpenJDK builds of the JDK8 build forest using Visual Studio 2012. The runtime .dll selection that Kelly is referring to takes place in toolchain_windows.m4. The binaries produced by my builds passed a few basic checks like 'java -version' and ran the JVM98 benchmark for a few minutes. Much more testing remains to be done. Here is a pointer to the source changes I needed to make, so far: http://cr.openjdk.java.net/~tbell/VS2012/webrev.00/ You will need to run 'bash common/autoconf/autoconf.sh' after applying the patch from the webrev. It has also been reported that the free VS2012 'Express' edition does not include the 64-bit compiler, so you will be able to build 32-bit only. I have not verified that. Tim [1] http://hg.openjdk.java.net/jdk8/awt/rev/dd1a80efa7cf On 05/22/13 04:27 PM, David Chase wrote: > I hope I'm trying to solve a simpler problem, which is just a build, as if I were someone outside Oracle playing with Openjdk. I assume my problems are a subset of the release problem. > > David > > On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote: > >> Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. >> >> DLLs created by a newer VS will not like the older VS runtime DLLs. >> >> To make a long story short, changing VS compilers is a royal pain, and not trivial. >> This is why we only recommend VS2010. >> >> I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( >> >> -kto From david.r.chase at oracle.com Thu May 23 03:13:18 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 22 May 2013 23:13:18 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <519D6669.7090100@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> Message-ID: <0EE20F25-CA92-4650-A9FE-E8EBF165531E@oracle.com> I think that there is a 64-bit compiler in there, though it seems to not be the default. I saw three different command-line choices, and one is 64-bit, which I am using. The available copies of the DirectX SDK (later than 2004) were not recognized as 32-bit by configure -- doesn't mean that they're not, it just decided that they were 64-bit given its current state, so I had to see if I could find a 64-bit compiler. I can supply more details tomorrow, and check a little harder to ensure it really is 64-bit. David On 2013-05-22, at 8:44 PM, Tim Bell wrote: > > It has also been reported that the free VS2012 'Express' edition does not include the 64-bit compiler, so you will be able to build 32-bit only. I have not verified that. > From erik.joelsson at oracle.com Thu May 23 09:47:13 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2013 11:47:13 +0200 Subject: RFR: 8014970: Use open man pages for non commercial builds Message-ID: <519DE5A1.2020706@oracle.com> Please review open part of these changes in jdk7u-dev. Moving logic for choosing open or oracle man pages to closed makefile. http://cr.openjdk.java.net/~erikj/8014969/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Thu May 23 09:59:11 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2013 11:59:11 +0200 Subject: RFR: 8014969: Use open man pages for non commercial builds In-Reply-To: <519DE5A1.2020706@oracle.com> References: <519DE5A1.2020706@oracle.com> Message-ID: <519DE86F.8060704@oracle.com> Oops, wrong bug number. 8014969 is the jdk7 version of this issue. /Erik On 2013-05-23 11:47, Erik Joelsson wrote: > Please review open part of these changes in jdk7u-dev. Moving logic > for choosing open or oracle man pages to closed makefile. > > http://cr.openjdk.java.net/~erikj/8014969/webrev.jdk.01/ > > /Erik From erik.joelsson at oracle.com Thu May 23 11:52:59 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 23 May 2013 11:52:59 +0000 Subject: hg: jdk8/build: 8014514: Fix jvm args for sjavac Message-ID: <20130523115259.AEAD448C97@hg.openjdk.java.net> Changeset: e247ee3924d5 Author: erikj Date: 2013-05-22 17:26 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/e247ee3924d5 8014514: Fix jvm args for sjavac Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh From anthony.petrov at oracle.com Thu May 23 12:08:35 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 May 2013 16:08:35 +0400 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> Message-ID: <519E06C3.7090401@oracle.com> Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to make them compatible with XP. Yes, we don't officially support JDK8 on Windows XP. However, there's a difference between _not supported_ and _just won't run_. Hence, if we ever decide to switch to VS2012, we'll most likely want to use VS2012sp1+. -- best regards, Anthony On 05/23/13 03:54, Kelly O'Hair wrote: > If you accept the fact that the build may complete but not work, then fine. > But if you want the JDK you built to actually run, you will probably need to get the new msvcr*dll files placed in the jdk image area (in the bin dirs), manually or via the makefiles. > > I also vaguely recall some silly thing with VS2012 that it was for Windows 8 only and you needed VS2012sp1 to be able to build for Windows releases before Windows 8? I'm not sure I remember that right. :^( > > -kto > > On May 22, 2013, at 4:27 PM, David Chase wrote: > >> I hope I'm trying to solve a simpler problem, which is just a build, as if I were someone outside Oracle playing with Openjdk. I assume my problems are a subset of the release problem. >> >> David >> >> On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote: >> >>> Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. >>> >>> DLLs created by a newer VS will not like the older VS runtime DLLs. >>> >>> To make a long story short, changing VS compilers is a royal pain, and not trivial. >>> This is why we only recommend VS2010. >>> >>> I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( >>> >>> -kto >> > From anthony.petrov at oracle.com Thu May 23 12:12:33 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 May 2013 16:12:33 +0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <0EE20F25-CA92-4650-A9FE-E8EBF165531E@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> <0EE20F25-CA92-4650-A9FE-E8EBF165531E@oracle.com> Message-ID: <519E07B1.7060306@oracle.com> David, I have worked around the compatibility of latest DirectX SDK and 32-bit JDK builds by copying the contents of the \Program Files\Microsoft DirectX SDK\Lib\x86\* to the Lib\ directory itself. Works like a charm. -- best regards, Anthony On 05/23/13 07:13, David Chase wrote: > I think that there is a 64-bit compiler in there, though it seems to not be the default. > I saw three different command-line choices, and one is 64-bit, which I am using. > > The available copies of the DirectX SDK (later than 2004) were not recognized as 32-bit > by configure -- doesn't mean that they're not, it just decided that they were 64-bit given > its current state, so I had to see if I could find a 64-bit compiler. > > I can supply more details tomorrow, and check a little harder to ensure it really is 64-bit. > > David > > On 2013-05-22, at 8:44 PM, Tim Bell wrote: >> >> It has also been reported that the free VS2012 'Express' edition does not include the 64-bit compiler, so you will be able to build 32-bit only. I have not verified that. >> > From david.r.chase at oracle.com Thu May 23 12:47:40 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 23 May 2013 08:47:40 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <519E06C3.7090401@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519E06C3.7090401@oracle.com> Message-ID: <7793E0A7-EFB9-4B9B-B0CB-43C0B3CFD26D@oracle.com> I think you need to understand the problem I'm after -- currently, our public instructions for third-party OpenJDK (8) builds don't work. They don't build at all, so porting is completely out of the question. I'm trying to come up with instructions that will at least build something that will run on the machine where it is built. Regarding the DirectX compatibility, that sounds like something we should be repairing in the builds, so that we can cut our dependence on a 9-year-old release of the DirectX SDK. Note also that some of these newer DirectX SDKs (certainly April 2006) will mess up your %PATH% by inserting elements on it that include quoted strings, and those you will need to remove manually. I will do the experiment to see if the 2010 release does not do this, since "repair your path after installing required software" is a good step not to have in any build process. On 2013-05-23, at 8:08 AM, Anthony Petrov wrote: > Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to make them compatible with XP. > > Yes, we don't officially support JDK8 on Windows XP. However, there's a difference between _not supported_ and _just won't run_. > > Hence, if we ever decide to switch to VS2012, we'll most likely want to use VS2012sp1+. > From anthony.petrov at oracle.com Thu May 23 13:09:12 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 May 2013 17:09:12 +0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <7793E0A7-EFB9-4B9B-B0CB-43C0B3CFD26D@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519E06C3.7090401@oracle.com> <7793E0A7-EFB9-4B9B-B0CB-43C0B3CFD26D@oracle.com> Message-ID: <519E14F8.6090706@oracle.com> David, I pretty much understand the problem you're trying to solve. I recall myself in 2006-2007 when I was eagerly wanting to build (then) JDK 6 with VS2005 while we officially used VS2003. It was fun. :) Later on we ended up switching to VS2010 for JDK7, however some results of my work still were useful and relevant, and they made their way to the JDK repo (some make files changes, command-line options for the compiler, minor code changes, etc.) So if you come up with some useful fixes for our new build system and/or sources to provide better support for newer compilers/libraries - it's great! FWIW, I did build JDK8 with VS2012 back in Oct/Nov last year. I've run a few GUI demo apps (SwingSet2 and friends) and they all worked just fine. Only some make files needed some minor updates in order to learn to use the new compilers. Overall, switching from VS2010 to VS2012 shouldn't be hard. -- best regards, Anthony On 05/23/13 16:47, David Chase wrote: > I think you need to understand the problem I'm after -- currently, our public instructions for third-party OpenJDK (8) builds don't work. > They don't build at all, so porting is completely out of the question. I'm trying to come up with instructions that will at least build something that will run on the machine where it is built. > > Regarding the DirectX compatibility, that sounds like something we should be repairing in the builds, so that we can cut our dependence on a 9-year-old release of the DirectX SDK. > > Note also that some of these newer DirectX SDKs (certainly April 2006) will mess up your %PATH% by inserting elements on it that include quoted strings, and those you will need to remove manually. I will do the experiment to see if the 2010 release does not do this, since "repair your path after installing required software" is a good step not to have in any build process. > > On 2013-05-23, at 8:08 AM, Anthony Petrov wrote: > >> Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to make them compatible with XP. >> >> Yes, we don't officially support JDK8 on Windows XP. However, there's a difference between _not supported_ and _just won't run_. >> >> Hence, if we ever decide to switch to VS2012, we'll most likely want to use VS2012sp1+. >> > From volker.simonis at gmail.com Thu May 23 14:00:33 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 May 2013 16:00:33 +0200 Subject: Somewhat wonkier Windows problem In-Reply-To: <519E14F8.6090706@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519E06C3.7090401@oracle.com> <7793E0A7-EFB9-4B9B-B0CB-43C0B3CFD26D@oracle.com> <519E14F8.6090706@oracle.com> Message-ID: Hi Anthony, I think what David is really objecting here is that the current build requirements for building OpenJDK 8 on Windows as described in the official build documentation can not be easily fulfilled by anybody outside Oracle (because of age-old dependencies which simply aren't publicly available anymore and which can not be easily provided by the OpenJDK project itself because of licensing issues - e.g. "DirectX 9.0 SDK Update Summer 2004", Cygwin 1.7.16, etc...). Of course it is possible to finally build with almost any combination of tools and libraries given that you invest enough time and resources and of course after you succeed in doing so you got wiser a little bit. But that's not the point! Ideally, everybody should be able to get the required build dependencies as easy as the JDK sources and after installing them as described in the build documentation he should be able to build. That's currently not the case - at least not on Windows! The problem is that Oracle nails down the build requirements years before a Java version is released and these requirements are carved into stone in the official build documentation. That's perfectly fine for a commercially released product which has to run on a variety of different platforms and which has to be supported for a long period of time - but not for an OpenSource project! I've been criticized for my suggestion to put (at least a part of) the build documentation into a Wiki in order to get a chance to update it more dynamically. From a software engineering standpoint that criticism was perfectly valid. From a pragmatic point of view perhaps not. Anyway - if we want to keep the build instructions in the repository in a central document (which is good!), than this document should really reflect the current situation and not the the instructions how Oracle once decided to build its derived, commercial product. I understand that Oracle may not want to be responsible to provide such a kind of document and that's perfectly fine. After all this is an open source project so the community may have to be involved here - we just have to make this fact clear to anybody. Currently, unfortunately, all these notable Windows build adventures more than often lead to a dead-end (just browse the mailing lists!) or at best in a blog entry which describes a special, working setup (been there several time myself:) Nevertheless David, you have my full moral support! Regards, Volker On Thu, May 23, 2013 at 3:09 PM, Anthony Petrov wrote: > David, > > I pretty much understand the problem you're trying to solve. I recall > myself in 2006-2007 when I was eagerly wanting to build (then) JDK 6 with > VS2005 while we officially used VS2003. It was fun. :) Later on we ended up > switching to VS2010 for JDK7, however some results of my work still were > useful and relevant, and they made their way to the JDK repo (some make > files changes, command-line options for the compiler, minor code changes, > etc.) > > So if you come up with some useful fixes for our new build system and/or > sources to provide better support for newer compilers/libraries - it's > great! > > FWIW, I did build JDK8 with VS2012 back in Oct/Nov last year. I've run a > few GUI demo apps (SwingSet2 and friends) and they all worked just fine. > Only some make files needed some minor updates in order to learn to use the > new compilers. Overall, switching from VS2010 to VS2012 shouldn't be hard. > > -- > best regards, > Anthony > > > On 05/23/13 16:47, David Chase wrote: > >> I think you need to understand the problem I'm after -- currently, our >> public instructions for third-party OpenJDK (8) builds don't work. >> They don't build at all, so porting is completely out of the question. >> I'm trying to come up with instructions that will at least build something >> that will run on the machine where it is built. >> >> Regarding the DirectX compatibility, that sounds like something we should >> be repairing in the builds, so that we can cut our dependence on a >> 9-year-old release of the DirectX SDK. >> >> Note also that some of these newer DirectX SDKs (certainly April 2006) >> will mess up your %PATH% by inserting elements on it that include quoted >> strings, and those you will need to remove manually. I will do the >> experiment to see if the 2010 release does not do this, since "repair your >> path after installing required software" is a good step not to have in any >> build process. >> >> On 2013-05-23, at 8:08 AM, Anthony Petrov> >> wrote: >> >> Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to >>> make them compatible with XP. >>> >>> Yes, we don't officially support JDK8 on Windows XP. However, there's a >>> difference between _not supported_ and _just won't run_. >>> >>> Hence, if we ever decide to switch to VS2012, we'll most likely want to >>> use VS2012sp1+. >>> >>> >> From anthony.petrov at oracle.com Thu May 23 14:12:57 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 May 2013 18:12:57 +0400 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519E06C3.7090401@oracle.com> <7793E0A7-EFB9-4B9B-B0CB-43C0B3CFD26D@oracle.com> <519E14F8.6090706@oracle.com> Message-ID: <519E23E9.2020606@oracle.com> Hi Volker, I agree completely. As I wrote in my reply to David - fixes in this area are very much welcome. Adding additional and/or alternative instructions and tips to the BUILD-README file is also a fix, btw. -- best regards, Anthony On 05/23/13 18:00, Volker Simonis wrote: > Hi Anthony, > > I think what David is really objecting here is that the current build > requirements for building OpenJDK 8 on Windows as described in the > official build documentation can not be easily fulfilled by anybody > outside Oracle (because of age-old dependencies which simply aren't > publicly available anymore and which can not be easily provided by the > OpenJDK project itself because of licensing issues - e.g. "DirectX 9.0 > SDK Update Summer 2004", Cygwin 1.7.16, etc...). > > Of course it is possible to finally build with almost any combination of > tools and libraries given that you invest enough time and resources and > of course after you succeed in doing so you got wiser a little bit. But > that's not the point! Ideally, everybody should be able to get the > required build dependencies as easy as the JDK sources and after > installing them as described in the build documentation he should be > able to build. That's currently not the case - at least not on Windows! > > The problem is that Oracle nails down the build requirements years > before a Java version is released and these requirements are carved into > stone in the official build documentation. That's perfectly fine for a > commercially released product which has to run on a variety of different > platforms and which has to be supported for a long period of time - but > not for an OpenSource project! > > I've been criticized for my suggestion to put (at least a part of) the > build documentation into a Wiki in order to get a chance to update it > more dynamically. From a software engineering standpoint that criticism > was perfectly valid. From a pragmatic point of view perhaps not. Anyway > - if we want to keep the build instructions in the repository in a > central document (which is good!), than this document should really > reflect the current situation and not the the instructions how Oracle > once decided to build its derived, commercial product. I understand that > Oracle may not want to be responsible to provide such a kind of document > and that's perfectly fine. After all this is an open source project so > the community may have to be involved here - we just have to make this > fact clear to anybody. > > Currently, unfortunately, all these notable Windows build adventures > more than often lead to a dead-end (just browse the mailing lists!) or > at best in a blog entry which describes a special, working setup (been > there several time myself:) > > Nevertheless David, you have my full moral support! > > Regards, > Volker > > > > On Thu, May 23, 2013 at 3:09 PM, Anthony Petrov > > wrote: > > David, > > I pretty much understand the problem you're trying to solve. I > recall myself in 2006-2007 when I was eagerly wanting to build > (then) JDK 6 with VS2005 while we officially used VS2003. It was > fun. :) Later on we ended up switching to VS2010 for JDK7, however > some results of my work still were useful and relevant, and they > made their way to the JDK repo (some make files changes, > command-line options for the compiler, minor code changes, etc.) > > So if you come up with some useful fixes for our new build system > and/or sources to provide better support for newer > compilers/libraries - it's great! > > FWIW, I did build JDK8 with VS2012 back in Oct/Nov last year. I've > run a few GUI demo apps (SwingSet2 and friends) and they all worked > just fine. Only some make files needed some minor updates in order > to learn to use the new compilers. Overall, switching from VS2010 to > VS2012 shouldn't be hard. > > -- > best regards, > Anthony > > > On 05/23/13 16:47, David Chase wrote: > > I think you need to understand the problem I'm after -- > currently, our public instructions for third-party OpenJDK (8) > builds don't work. > They don't build at all, so porting is completely out of the > question. I'm trying to come up with instructions that will at > least build something that will run on the machine where it is > built. > > Regarding the DirectX compatibility, that sounds like something > we should be repairing in the builds, so that we can cut our > dependence on a 9-year-old release of the DirectX SDK. > > Note also that some of these newer DirectX SDKs (certainly April > 2006) will mess up your %PATH% by inserting elements on it that > include quoted strings, and those you will need to remove > manually. I will do the experiment to see if the 2010 release > does not do this, since "repair your path after installing > required software" is a good step not to have in any build process. > > On 2013-05-23, at 8:08 AM, Anthony > Petrov > wrote: > > Binaries built with VS2012 won't run on WinXP. You need > VS2012sp1 to make them compatible with XP. > > Yes, we don't officially support JDK8 on Windows XP. > However, there's a difference between _not supported_ and > _just won't run_. > > Hence, if we ever decide to switch to VS2012, we'll most > likely want to use VS2012sp1+. > > > From david.r.chase at oracle.com Thu May 23 15:57:32 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 23 May 2013 11:57:32 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <519D6669.7090100@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> Message-ID: Those changes look quite familiar, but more comprehensive. Thanks. I will give them a try in a minute, after I see how far I get with the 2010 DirectX SDK. That one has the desirable property of not messing up %PATH%. I suspect, based on others' experience, that we'll want need to adjust how we deal with DirectX if we want to use the not-2004 version (I didn't seen any occurrence of "directx" in your patch). David On 2013-05-22, at 8:44 PM, Tim Bell wrote: > We are in the process of evaluating build tool selections for JDK8. > > For Windows, Anthony Petrov started the work and supplied a patch [1], plus more changes for hotspot. > > I have successfully completed OpenJDK builds of the JDK8 build forest using Visual Studio 2012. The runtime .dll selection that Kelly is referring to takes place in toolchain_windows.m4. > > The binaries produced by my builds passed a few basic checks like 'java -version' and ran the JVM98 benchmark for a few minutes. Much more testing remains to be done. > > Here is a pointer to the source changes I needed to make, so far: > > http://cr.openjdk.java.net/~tbell/VS2012/webrev.00/ > > You will need to run 'bash common/autoconf/autoconf.sh' after applying the patch from the webrev. > > It has also been reported that the free VS2012 'Express' edition does not include the 64-bit compiler, so you will be able to build 32-bit only. I have not verified that. > > Tim > > [1] http://hg.openjdk.java.net/jdk8/awt/rev/dd1a80efa7cf > > > On 05/22/13 04:27 PM, David Chase wrote: >> I hope I'm trying to solve a simpler problem, which is just a build, as if I were someone outside Oracle playing with Openjdk. I assume my problems are a subset of the release problem. >> >> David >> >> On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote: >> >>> Windows VS compilers are a pain. Each release has it's own unique runtime DLLs, which we must deliver with the JDK, so the build process has to know what that DLL is named, where it is located, and copy it into various places. >>> >>> DLLs created by a newer VS will not like the older VS runtime DLLs. >>> >>> To make a long story short, changing VS compilers is a royal pain, and not trivial. >>> This is why we only recommend VS2010. >>> >>> I'm not saying it cannot be done, I'm just saying you should have plenty of liquor available when you do it. :^( >>> >>> -kto From david.r.chase at oracle.com Thu May 23 17:12:19 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 23 May 2013 13:12:19 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <519D6669.7090100@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> Message-ID: On 2013-05-22, at 8:44 PM, Tim Bell wrote: > Here is a pointer to the source changes I needed to make, so far: > > http://cr.openjdk.java.net/~tbell/VS2012/webrev.00/ > > You will need to run 'bash common/autoconf/autoconf.sh' after applying the patch from the webrev. > > It has also been reported that the free VS2012 'Express' edition does not include the 64-bit compiler, so you will be able to build 32-bit only. I have not verified that. A report back on your patch, with minor testing: This worked: jdk8tl + closed + your patch Windows 7 VS 2012 Express, x64 Command Prompt DirectX SDK 2010 REBASE=/usr/bin/rebase bash configure --with-boot-jdk=...1.7.0_21 The java -showversion happily declared that it was 64-bit, and I ran some of the applet demos, and they all seemed to work. Things that fail, so far (each line describes a different failure): DirectX SDK 2006 (because it makes a mess of the path) VS 2012 Express, 32-bit Command Prompt (because it fails to find x86 direct X, though it is there) Are there more experiments that you think I should try? I am most interested in working around the 32-bit problem in configure, then in testing if it still works properly with VS2010, 32 and 64, then in testing if it works with the closed bits missing. As near as I can tell, the combinations to consider for "the future" are at minimum { VS2010, VS2012, VS2012sp1} x {express, professional} x {32, 64} x {open, closed} Everything there has to should build and pass a bunch of tests once. I'd love to stick with a single modern version of DXSDK. David From david.r.chase at oracle.com Thu May 23 18:10:49 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 23 May 2013 14:10:49 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> Message-ID: One change to add (a by-hand "diff") to common/autoconf/toolchain_windows.m4 : AC_MSG_CHECKING([for DirectX SDK lib dir]) if test "x$with_dxsdk_lib" != x; then DXSDK_LIB_PATH="$with_dxsdk_lib" elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then DXSDK_LIB_PATH="$dxsdk_path/Lib/x64" + elif test -d "$dxsdk_path/Lib/x86"; then + DXSDK_LIB_PATH="$dxsdk_path/Lib/x86" else DXSDK_LIB_PATH="$dxsdk_path/Lib" fi This allows 32-bit configure with DirectX SDK 2010. This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't seen it yet. It built, I ran an applet demo, so some minor success there, too. I'm keeping notes on what works. More later. David From erik.joelsson at oracle.com Fri May 24 07:23:32 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2013 09:23:32 +0200 Subject: Somewhat wonkier Windows problem In-Reply-To: References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> Message-ID: <519F1574.5040105@oracle.com> On 2013-05-23 20:10, David Chase wrote: > One change to add (a by-hand "diff") to common/autoconf/toolchain_windows.m4 : > > AC_MSG_CHECKING([for DirectX SDK lib dir]) > if test "x$with_dxsdk_lib" != x; then > DXSDK_LIB_PATH="$with_dxsdk_lib" > elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then > DXSDK_LIB_PATH="$dxsdk_path/Lib/x64" > + elif test -d "$dxsdk_path/Lib/x86"; then > + DXSDK_LIB_PATH="$dxsdk_path/Lib/x86" > else > DXSDK_LIB_PATH="$dxsdk_path/Lib" > fi > > This allows 32-bit configure with DirectX SDK 2010. > This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't seen it yet. > Yes, newer directx sdks have that subdir while the only one we support doesn't. That's why I didn't add that check. The 2d team is quite adamant about that being the only working directx sdk and any talk about changing it should be with them, not the build team. If we want to change directx sdk, we should first consider removing the dependency completely since technically, everything that's needed is installed with visual studio and/or the normal windows sdk. /Erik > It built, I ran an applet demo, so some minor success there, too. > > I'm keeping notes on what works. > > More later. > > David > > > From anthony.petrov at oracle.com Fri May 24 09:41:29 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 May 2013 13:41:29 +0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <519F1574.5040105@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> <519F1574.5040105@oracle.com> Message-ID: <519F35C9.1040001@oracle.com> [ adding 2d-dev@ ] On 05/24/2013 11:23 AM, Erik Joelsson wrote: > On 2013-05-23 20:10, David Chase wrote: >> One change to add (a by-hand "diff") to >> common/autoconf/toolchain_windows.m4 : >> >> AC_MSG_CHECKING([for DirectX SDK lib dir]) >> if test "x$with_dxsdk_lib" != x; then >> DXSDK_LIB_PATH="$with_dxsdk_lib" >> elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then >> DXSDK_LIB_PATH="$dxsdk_path/Lib/x64" >> + elif test -d "$dxsdk_path/Lib/x86"; then >> + DXSDK_LIB_PATH="$dxsdk_path/Lib/x86" >> else >> DXSDK_LIB_PATH="$dxsdk_path/Lib" >> fi >> >> This allows 32-bit configure with DirectX SDK 2010. >> This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't >> seen it yet. >> > Yes, newer directx sdks have that subdir while the only one we support > doesn't. That's why I didn't add that check. The 2d team is quite > adamant about that being the only working directx sdk and any talk about > changing it should be with them, not the build team. We build OracleJDK using DXSDK 2004. Building with a newer DXSDK may (in theory) cause some differences in rendering graphics. Note that in practice I don't recall if anyone has ever seen any actual differences. However, when fixing e.g. 2D bugs, it is important that developers use the proper version of DXSDK for their developer builds to make sure they reproduce the actual issue. In all other cases the version of DXSDK doesn't really matter. I don't see how this translates to DXSDK 2004 "being the only working directx sdk". I believe that the changes proposed by David are reasonable and should be implemented to allow the OpenJDK community build with any version of DXSDK. > If we want to change directx sdk, we should first consider removing the > dependency completely since technically, everything that's needed is > installed with visual studio and/or the normal windows sdk. I agree, this is a good idea. And this is exactly something that the 2D team should decide. However, I believe that the above patch could be applied to OpenJDK as an interim solution before the decision is made. -- best regards, Anthony > > /Erik >> It built, I ran an applet demo, so some minor success there, too. >> >> I'm keeping notes on what works. >> >> More later. >> >> David >> >> >> From erik.joelsson at oracle.com Fri May 24 10:06:02 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2013 12:06:02 +0200 Subject: Somewhat wonkier Windows problem In-Reply-To: <519F35C9.1040001@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> <519F1574.5040105@oracle.com> <519F35C9.1040001@oracle.com> Message-ID: <519F3B8A.4070205@oracle.com> On 2013-05-24 11:41, Anthony Petrov wrote: > [ adding 2d-dev@ ] > > On 05/24/2013 11:23 AM, Erik Joelsson wrote: >> On 2013-05-23 20:10, David Chase wrote: >>> One change to add (a by-hand "diff") to >>> common/autoconf/toolchain_windows.m4 : >>> >>> AC_MSG_CHECKING([for DirectX SDK lib dir]) >>> if test "x$with_dxsdk_lib" != x; then >>> DXSDK_LIB_PATH="$with_dxsdk_lib" >>> elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then >>> DXSDK_LIB_PATH="$dxsdk_path/Lib/x64" >>> + elif test -d "$dxsdk_path/Lib/x86"; then >>> + DXSDK_LIB_PATH="$dxsdk_path/Lib/x86" >>> else >>> DXSDK_LIB_PATH="$dxsdk_path/Lib" >>> fi >>> >>> This allows 32-bit configure with DirectX SDK 2010. >>> This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't >>> seen it yet. >>> >> Yes, newer directx sdks have that subdir while the only one we support >> doesn't. That's why I didn't add that check. The 2d team is quite >> adamant about that being the only working directx sdk and any talk about >> changing it should be with them, not the build team. > > We build OracleJDK using DXSDK 2004. Building with a newer DXSDK may > (in theory) cause some differences in rendering graphics. Note that > in practice I don't recall if anyone has ever seen any actual > differences. However, when fixing e.g. 2D bugs, it is important that > developers use the proper version of DXSDK for their developer builds > to make sure they reproduce the actual issue. In all other cases the > version of DXSDK doesn't really matter. > > I don't see how this translates to DXSDK 2004 "being the only working > directx sdk". I believe that the changes proposed by David are > reasonable and should be implemented to allow the OpenJDK community > build with any version of DXSDK. > > >> If we want to change directx sdk, we should first consider removing the >> dependency completely since technically, everything that's needed is >> installed with visual studio and/or the normal windows sdk. > > I agree, this is a good idea. And this is exactly something that the > 2D team should decide. However, I believe that the above patch could > be applied to OpenJDK as an interim solution before the decision is made. >> I agree with the patch too. Just gave the history to why it wasn't added already. /Erik From david.r.chase at oracle.com Fri May 24 12:07:43 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 24 May 2013 08:07:43 -0400 Subject: Somewhat wonkier Windows problem In-Reply-To: <519F3B8A.4070205@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> <519F1574.5040105@oracle.com> <519F35C9.1040001@oracle.com> <519F3B8A.4070205@oracle.com> Message-ID: <4274E826-E9BB-4594-89CB-6263418E9B40@oracle.com> Note that my little patch is in addition to everything that Tim Bell has in his patch to allow building with VS2012 Express, and I haven't tested this yet with VS2010 Express, but I will shortly. And the point is exactly to allow someone outside Oracle to download OpenJDK and to build on Windows. David On 2013-05-24, at 6:06 AM, Erik Joelsson wrote: > On 2013-05-24 11:41, Anthony Petrov wrote: >> [ adding 2d-dev@ ] >> >> On 05/24/2013 11:23 AM, Erik Joelsson wrote: >>> On 2013-05-23 20:10, David Chase wrote: >>>> One change to add (a by-hand "diff") to >>>> common/autoconf/toolchain_windows.m4 : >>>> >>>> AC_MSG_CHECKING([for DirectX SDK lib dir]) >>>> if test "x$with_dxsdk_lib" != x; then >>>> DXSDK_LIB_PATH="$with_dxsdk_lib" >>>> elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then >>>> DXSDK_LIB_PATH="$dxsdk_path/Lib/x64" >>>> + elif test -d "$dxsdk_path/Lib/x86"; then >>>> + DXSDK_LIB_PATH="$dxsdk_path/Lib/x86" >>>> else >>>> DXSDK_LIB_PATH="$dxsdk_path/Lib" >>>> fi >>>> >>>> This allows 32-bit configure with DirectX SDK 2010. >>>> This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't >>>> seen it yet. >>>> >>> Yes, newer directx sdks have that subdir while the only one we support >>> doesn't. That's why I didn't add that check. The 2d team is quite >>> adamant about that being the only working directx sdk and any talk about >>> changing it should be with them, not the build team. >> >> We build OracleJDK using DXSDK 2004. Building with a newer DXSDK may (in theory) cause some differences in rendering graphics. Note that in practice I don't recall if anyone has ever seen any actual differences. However, when fixing e.g. 2D bugs, it is important that developers use the proper version of DXSDK for their developer builds to make sure they reproduce the actual issue. In all other cases the version of DXSDK doesn't really matter. >> >> I don't see how this translates to DXSDK 2004 "being the only working directx sdk". I believe that the changes proposed by David are reasonable and should be implemented to allow the OpenJDK community build with any version of DXSDK. >> >> >>> If we want to change directx sdk, we should first consider removing the >>> dependency completely since technically, everything that's needed is >>> installed with visual studio and/or the normal windows sdk. >> >> I agree, this is a good idea. And this is exactly something that the 2D team should decide. However, I believe that the above patch could be applied to OpenJDK as an interim solution before the decision is made. >>> > I agree with the patch too. Just gave the history to why it wasn't added already. > > /Erik From erik.joelsson at oracle.com Fri May 24 12:40:55 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2013 14:40:55 +0200 Subject: RFR: 8015377: Support using compiler devkits on Linux Message-ID: <519F5FD7.2020505@oracle.com> Official compiler and OS versions for building OracleJDK are being evaluated. A wanted feature is to be able to separate compiler version from OS version for the linux build, as is already the case for all other platforms. This could be achieved by creating portable self contained compiler bundles. Support for such devkits already exist in the OpenJDK configure scripts, but since it's rarely used, there are a couple of issues with it that needs to be fixed. This patch fixes those issues and also provides makefiles that can be used to replicate the devkits being evaluated. More information on how to build them can be found in the comments in common/makefiles/devkit/Makefile. I don't expect many will try this, but the information should be open. These makefiles could be left for later. The configure changes are what we need now. A devkit like this solves several problems: 1. We need to build on an older OS to create binaries compatible with both old and new versions of OSes, but we also want to use modern compilers not likely to be available on an older OS. 2. For developers it's easier to get a working build environment on a new system since most dependencies will be in the devkit. It also makes it easier to use the official compiler and libraries for developer builds. 3. Support for cross compilation is included. The x86_64 package supports the -m32 flag and will function correctly when the jdk configure script is fed with --with-target-bits=32. The i686 package contains a full x86_64 cross toolchain. http://cr.openjdk.java.net/~erikj/8015377/webrev.root.01/ Binary bundles will be made available internally soon. /Erik From erik.joelsson at oracle.com Fri May 24 13:22:02 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2013 15:22:02 +0200 Subject: RFR: 8014074: Building hotspot with ccache in new build is very slow with empty cache. Message-ID: <519F697A.4070106@oracle.com> This patch to configure disables precompiled headers in hotspot when ccache is in use. Background is in this mail (and the bug report): http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008772.html In short, build time is shortened considerably both with an empty and a perfect cache when ccache is in use. Note that this only affects full builds from the root repo and not hotspot only builds. http://cr.openjdk.java.net/~erikj/8014074/webrev.root.01/ /Erik From vadim.pakhnushev at oracle.com Fri May 24 13:20:09 2013 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 24 May 2013 17:20:09 +0400 Subject: [OpenJDK 2D-Dev] Somewhat wonkier Windows problem In-Reply-To: <519F35C9.1040001@oracle.com> References: <2A6D948F-B2A1-458C-A087-1548B7FAE896@oracle.com> <976E0C55-40FF-4533-A085-E883649E47AF@gmail.com> <519D6669.7090100@oracle.com> <519F1574.5040105@oracle.com> <519F35C9.1040001@oracle.com> Message-ID: <519F6909.4030706@oracle.com> Hi, There is a bug filed for exactly this reason: http://bugs.sun.com/view_bug.do?bug_id=8008022 I was building JDK 7 and 8 with DXSDK 2010 for almost a year without any problems, and I don't see why there should be any, the core DXSDK API hasn't changed. The change proposed by David is almost exactly what I was thinking to implement. In addition, I think we should make this change in the old build system as well? BTW, 2D code is not using DXSDK_LIB_PATH at all, it loads the d3d9.dll via LoadLibrary. The only usage of the lib path I've found is javax.sound jsoundds.dll which links dsound.dll. And I've checked that we can remove DXSDK dependency at all since all necessary headers are included in Windows SDK (although officially only in SDK 8). But for conservative approach I would use David's change with addition for old build system. I hope Phil can add something to this discussion. Thanks, Vadim On 24.05.2013 13:41, Anthony Petrov wrote: > [ adding 2d-dev@ ] > > On 05/24/2013 11:23 AM, Erik Joelsson wrote: >> On 2013-05-23 20:10, David Chase wrote: >>> One change to add (a by-hand "diff") to >>> common/autoconf/toolchain_windows.m4 : >>> >>> AC_MSG_CHECKING([for DirectX SDK lib dir]) >>> if test "x$with_dxsdk_lib" != x; then >>> DXSDK_LIB_PATH="$with_dxsdk_lib" >>> elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then >>> DXSDK_LIB_PATH="$dxsdk_path/Lib/x64" >>> + elif test -d "$dxsdk_path/Lib/x86"; then >>> + DXSDK_LIB_PATH="$dxsdk_path/Lib/x86" >>> else >>> DXSDK_LIB_PATH="$dxsdk_path/Lib" >>> fi >>> >>> This allows 32-bit configure with DirectX SDK 2010. >>> This assumes that DXSDK 2004 lacks any subdirectory Lib/x86; I haven't >>> seen it yet. >>> >> Yes, newer directx sdks have that subdir while the only one we support >> doesn't. That's why I didn't add that check. The 2d team is quite >> adamant about that being the only working directx sdk and any talk about >> changing it should be with them, not the build team. > > We build OracleJDK using DXSDK 2004. Building with a newer DXSDK may > (in theory) cause some differences in rendering graphics. Note that > in practice I don't recall if anyone has ever seen any actual > differences. However, when fixing e.g. 2D bugs, it is important that > developers use the proper version of DXSDK for their developer builds > to make sure they reproduce the actual issue. In all other cases the > version of DXSDK doesn't really matter. > > I don't see how this translates to DXSDK 2004 "being the only working > directx sdk". I believe that the changes proposed by David are > reasonable and should be implemented to allow the OpenJDK community > build with any version of DXSDK. > > >> If we want to change directx sdk, we should first consider removing the >> dependency completely since technically, everything that's needed is >> installed with visual studio and/or the normal windows sdk. > > I agree, this is a good idea. And this is exactly something that the > 2D team should decide. However, I believe that the above patch could > be applied to OpenJDK as an interim solution before the decision is made. > > -- > best regards, > Anthony > >> >> /Erik >>> It built, I ran an applet demo, so some minor success there, too. >>> >>> I'm keeping notes on what works. >>> >>> More later. >>> >>> David >>> >>> >>> From david.r.chase at oracle.com Fri May 24 21:41:28 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 24 May 2013 17:41:28 -0400 Subject: Windows configure "issues" In-Reply-To: References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> <712962147.5518935.1369169656380.JavaMail.root@redhat.com> <20130521152558.514226@eggemoggin.niobe.net> Message-ID: <1206BB08-E3D0-4B9D-9735-62C1510A83C8@oracle.com> FYI, progress report. No additional changes to the build, but the instructions may require tweaking. Did manage successful builds without closed subdirectories, using VS2012 and DirectX 2010. Required installation+build of Freetype using instructions from Volker's blog, adapted slightly for updated activex and new build directory expectations. Not sure what is the best plan here; the fix is all of mkdir ../../../lib cp * ../../../lib Compared to the additional steps needed to get it built, this is not a big deal, so I am not sure it justifies whacking on the build scripts. VS2012, the studio, does not come with 64-bit support, even though the compilers are there, so this is a glitch. So, from the list to consider: { VS2010, VS2012, VS2012sp1} x {express, professional} x {32, 64} x {open, closed} the results thus far are: VS2012 x express x {32, 64} x closed = builds, runs VS2012 x express x 32 x open = builds, runs (release and slowdebug) VS2012 x express x 64 x open = blocked by initial inability to build 64-bit freetype next step is to try VS2010 express to see if it still works. David From david.holmes at oracle.com Mon May 27 03:11:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 13:11:42 +1000 Subject: RFR: 8014074: Building hotspot with ccache in new build is very slow with empty cache. In-Reply-To: <519F697A.4070106@oracle.com> References: <519F697A.4070106@oracle.com> Message-ID: <51A2CEEE.3080402@oracle.com> Hi Erik, I have mixed feelings on this one. On the one hand I don't like the idea that using/not-using an optimization like ccache, changes the way the build of hotspot is carried out. On the other hand, if this means we will do more builds without precompiled headers then it should help trap errors when there are missing #includes. Does this have any impact on our actual RE builds? Thanks, David On 24/05/2013 11:22 PM, Erik Joelsson wrote: > This patch to configure disables precompiled headers in hotspot when > ccache is in use. > > Background is in this mail (and the bug report): > http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008772.html > > In short, build time is shortened considerably both with an empty and a > perfect cache when ccache is in use. > > Note that this only affects full builds from the root repo and not > hotspot only builds. > > http://cr.openjdk.java.net/~erikj/8014074/webrev.root.01/ > > /Erik From david.holmes at oracle.com Mon May 27 03:22:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2013 13:22:26 +1000 Subject: RFR: 8015377: Support using compiler devkits on Linux In-Reply-To: <519F5FD7.2020505@oracle.com> References: <519F5FD7.2020505@oracle.com> Message-ID: <51A2D172.6060805@oracle.com> Hi Erik, Not a full review by any means. Looking at libraries.m4, there is some later code: 156 # Some of the old makefiles require a setting of OPENWIN_HOME 157 # Since the X11R6 directory has disappeared on later Linuxes, 158 # we need to probe for it. 159 if test "x$OPENJDK_TARGET_OS" = xlinux; then 160 if test -d "$SYS_ROOT/usr/X11R6"; then 161 OPENWIN_HOME="$SYS_ROOT/usr/X11R6" 162 fi 163 if test -d "$SYS_ROOT/usr/include/X11"; then 164 OPENWIN_HOME="$SYS_ROOT/usr" 165 fi 166 fi that looks like it should an if/else similar to the code you modified. (Bob Vandette flagged this to me a while ago) Otherwise the existing configure changes look okay. Can't comment on the devkit package stuff. Thanks, David On 24/05/2013 10:40 PM, Erik Joelsson wrote: > Official compiler and OS versions for building OracleJDK are being > evaluated. A wanted feature is to be able to separate compiler version > from OS version for the linux build, as is already the case for all > other platforms. This could be achieved by creating portable self > contained compiler bundles. Support for such devkits already exist in > the OpenJDK configure scripts, but since it's rarely used, there are a > couple of issues with it that needs to be fixed. > > This patch fixes those issues and also provides makefiles that can be > used to replicate the devkits being evaluated. More information on how > to build them can be found in the comments in > common/makefiles/devkit/Makefile. I don't expect many will try this, but > the information should be open. These makefiles could be left for later. > The configure changes are what we need now. > > A devkit like this solves several problems: > 1. We need to build on an older OS to create binaries compatible with > both old and new versions of OSes, but we also want to use modern > compilers not likely to be available on an older OS. > 2. For developers it's easier to get a working build environment on a > new system since most dependencies will be in the devkit. It also makes > it easier to use the official compiler and libraries for developer builds. > 3. Support for cross compilation is included. The x86_64 package > supports the -m32 flag and will function correctly when the jdk > configure script is fed with --with-target-bits=32. The i686 package > contains a full x86_64 cross toolchain. > > http://cr.openjdk.java.net/~erikj/8015377/webrev.root.01/ > > Binary bundles will be made available internally soon. > > /Erik From erik.joelsson at oracle.com Mon May 27 08:08:36 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 May 2013 10:08:36 +0200 Subject: RFR: 8014074: Building hotspot with ccache in new build is very slow with empty cache. In-Reply-To: <51A2CEEE.3080402@oracle.com> References: <519F697A.4070106@oracle.com> <51A2CEEE.3080402@oracle.com> Message-ID: <51A31484.2000200@oracle.com> On 2013-05-27 05:11, David Holmes wrote: > Hi Erik, > > I have mixed feelings on this one. On the one hand I don't like the > idea that using/not-using an optimization like ccache, changes the way > the build of hotspot is carried out. On the other hand, if this means > we will do more builds without precompiled headers then it should help > trap errors when there are missing #includes. I agree, and it feels weird to me too. Precompiled header is also a kind of build optimization, though more intrusive than ccache. I was even more annoyed at the long build times when the cache didn't give any hits though. > > Does this have any impact on our actual RE builds? I do not know if they have ccache installed and available on their machines. My guess is that if it is, it's by accident. We could instruct them to add --disable-ccache to make sure they don't accidentally pick it up. I could also readd and fix the support for precompiled header together with ccache and add another option for it. /Erik > > Thanks, > David > > On 24/05/2013 11:22 PM, Erik Joelsson wrote: >> This patch to configure disables precompiled headers in hotspot when >> ccache is in use. >> >> Background is in this mail (and the bug report): >> http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008772.html >> >> In short, build time is shortened considerably both with an empty and a >> perfect cache when ccache is in use. >> >> Note that this only affects full builds from the root repo and not >> hotspot only builds. >> >> http://cr.openjdk.java.net/~erikj/8014074/webrev.root.01/ >> >> /Erik From erik.joelsson at oracle.com Mon May 27 08:45:50 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 May 2013 10:45:50 +0200 Subject: RFR: 8015377: Support using compiler devkits on Linux In-Reply-To: <51A2D172.6060805@oracle.com> References: <519F5FD7.2020505@oracle.com> <51A2D172.6060805@oracle.com> Message-ID: <51A31D3E.3010406@oracle.com> On 2013-05-27 05:22, David Holmes wrote: > Hi Erik, > > Not a full review by any means. > > Looking at libraries.m4, there is some later code: > > 156 # Some of the old makefiles require a setting of OPENWIN_HOME > 157 # Since the X11R6 directory has disappeared on later Linuxes, > 158 # we need to probe for it. > 159 if test "x$OPENJDK_TARGET_OS" = xlinux; then > 160 if test -d "$SYS_ROOT/usr/X11R6"; then > 161 OPENWIN_HOME="$SYS_ROOT/usr/X11R6" > 162 fi > 163 if test -d "$SYS_ROOT/usr/include/X11"; then > 164 OPENWIN_HOME="$SYS_ROOT/usr" > 165 fi > 166 fi > > that looks like it should an if/else similar to the code you modified. > (Bob Vandette flagged this to me a while ago) > That should be using the same logic as above yes. Fixed. http://cr.openjdk.java.net/~erikj/8015377/webrev.root.02/ > Otherwise the existing configure changes look okay. Can't comment on > the devkit package stuff. > Thanks! Not sure about committing the devikt creator scripts, but think they should be open in some way. They are quite messy, even if I've tried cleaning them up. /Erik > Thanks, > David > > On 24/05/2013 10:40 PM, Erik Joelsson wrote: >> Official compiler and OS versions for building OracleJDK are being >> evaluated. A wanted feature is to be able to separate compiler version >> from OS version for the linux build, as is already the case for all >> other platforms. This could be achieved by creating portable self >> contained compiler bundles. Support for such devkits already exist in >> the OpenJDK configure scripts, but since it's rarely used, there are a >> couple of issues with it that needs to be fixed. >> >> This patch fixes those issues and also provides makefiles that can be >> used to replicate the devkits being evaluated. More information on how >> to build them can be found in the comments in >> common/makefiles/devkit/Makefile. I don't expect many will try this, but >> the information should be open. These makefiles could be left for later. >> The configure changes are what we need now. >> >> A devkit like this solves several problems: >> 1. We need to build on an older OS to create binaries compatible with >> both old and new versions of OSes, but we also want to use modern >> compilers not likely to be available on an older OS. >> 2. For developers it's easier to get a working build environment on a >> new system since most dependencies will be in the devkit. It also makes >> it easier to use the official compiler and libraries for developer >> builds. >> 3. Support for cross compilation is included. The x86_64 package >> supports the -m32 flag and will function correctly when the jdk >> configure script is fed with --with-target-bits=32. The i686 package >> contains a full x86_64 cross toolchain. >> >> http://cr.openjdk.java.net/~erikj/8015377/webrev.root.01/ >> >> Binary bundles will be made available internally soon. >> >> /Erik From erik.joelsson at oracle.com Mon May 27 12:05:10 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 May 2013 14:05:10 +0200 Subject: RFR: 8007129: build-infra Add configure --with-jtreg option for location of JTREG Message-ID: <51A34BF6.1060207@oracle.com> This patch adds a configure option --with-jtreg=/path/to/jtreg. It also changes how BASIC_FIXUP_PATH works on unix platforms, making it behave more like it's documented and like on windows. Relative paths are made absolute and special variables like ~ are expanded. This macro didn't have a lot of uses that weren't windows specific so I doubt it will affect anything in a bad way. http://cr.openjdk.java.net/~erikj/8007129/webrev.root.01/ /Erik From erik.joelsson at oracle.com Mon May 27 13:59:38 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 May 2013 15:59:38 +0200 Subject: RFR: 8012566: Replace find, rm, printf and similar with their proper variables Message-ID: <51A366CA.2070904@oracle.com> A bit of cleanup work in langtools/makefiles/BuildLangtools.gmk, this patch replaces all occurrences of rm, mv, mkdir, printf, find and echo with their respective make variables as defined by configure. http://cr.openjdk.java.net/~erikj/8012566/webrev.langtools.01/ /Erik From tim.bell at oracle.com Mon May 27 19:07:01 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 May 2013 12:07:01 -0700 Subject: RFR: 8007129: build-infra Add configure --with-jtreg option for location of JTREG In-Reply-To: <51A34BF6.1060207@oracle.com> References: <51A34BF6.1060207@oracle.com> Message-ID: <51A3AED5.4040701@oracle.com> Erik: > This patch adds a configure option --with-jtreg=/path/to/jtreg. > > It also changes how BASIC_FIXUP_PATH works on unix platforms, making > it behave more like it's documented and like on windows. Relative > paths are made absolute and special variables like ~ are expanded. > This macro didn't have a lot of uses that weren't windows specific so > I doubt it will affect anything in a bad way. > > http://cr.openjdk.java.net/~erikj/8007129/webrev.root.01 Looks good to me. Tim From tim.bell at oracle.com Mon May 27 19:13:56 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 May 2013 12:13:56 -0700 Subject: RFR: 8012566: Replace find, rm, printf and similar with their proper variables In-Reply-To: <51A366CA.2070904@oracle.com> References: <51A366CA.2070904@oracle.com> Message-ID: <51A3B074.2000504@oracle.com> Erik: > A bit of cleanup work in langtools/makefiles/BuildLangtools.gmk, this > patch replaces all occurrences of rm, mv, mkdir, printf, find and echo > with their respective make variables as defined by configure. > > http://cr.openjdk.java.net/~erikj/8012566/webrev.langtools.01 Looks good to me. Tim From erik.joelsson at oracle.com Tue May 28 11:15:35 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2013 13:15:35 +0200 Subject: RFR: 8013489: New build system does not run codesign on SA-related launchers on OS X Message-ID: <51A491D7.7090305@oracle.com> This patch readds the missing functionality of running codesign on certain launchers on macosx. In the old build, it was always run, but failing if the openjdk_codesign certificate wasn't present on the system. Make ignored this failure. In this patch, configure tests that the certificate is there and disables running codesign if it isn't, reducing pointless error messages in the build log. http://cr.openjdk.java.net/~erikj/8013489/webrev.01/ /Erik From staffan.larsen at oracle.com Tue May 28 11:19:05 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 May 2013 13:19:05 +0200 Subject: RFR: 8013489: New build system does not run codesign on SA-related launchers on OS X In-Reply-To: <51A491D7.7090305@oracle.com> References: <51A491D7.7090305@oracle.com> Message-ID: <92F826B0-1ED3-4E77-A8A0-B02602D2E59A@oracle.com> Looks good. I have verified that this patch signs the binaries as expected. Thanks, /Staffan On 28 maj 2013, at 13:15, Erik Joelsson wrote: > This patch readds the missing functionality of running codesign on certain launchers on macosx. In the old build, it was always run, but failing if the openjdk_codesign certificate wasn't present on the system. Make ignored this failure. In this patch, configure tests that the certificate is there and disables running codesign if it isn't, reducing pointless error messages in the build log. > > http://cr.openjdk.java.net/~erikj/8013489/webrev.01/ > > /Erik From maurizio.cimadamore at oracle.com Tue May 28 11:36:40 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 May 2013 12:36:40 +0100 Subject: new build system configure step - a small suggestion Message-ID: <51A496C8.4030504@oracle.com> Hi, as I recently went through the process of reinstalling my OS, I had to get the JDK build up and running again (with Ubuntu). As expected, configure kept failing because of missing libraries; I counted 4 failures: *) build-essential missing (gcc, etc.) *) X headers missing *) cups headers missing *) alsa headers missing Since the output of the configure tool is already very good (i.e. it gives you the apt command needed to fetch missing stuff), wouldn't it be possible to somehow go through an entire scan of the system, and then report back a unique list of missing stuff instead of forcing users to do this trial and error approach? Of course this is a very minor adjustment to an overall very user-friendly process; I only wanted to share my experience. Thanks Maurizio From erik.joelsson at oracle.com Tue May 28 11:47:05 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2013 13:47:05 +0200 Subject: new build system configure step - a small suggestion In-Reply-To: <51A496C8.4030504@oracle.com> References: <51A496C8.4030504@oracle.com> Message-ID: <51A49939.8010408@oracle.com> This has been brought up before and is a good idea. At least the headers could be checked for in one go. The compiler is needed to check for headers, so that would need to be a separate run. Creating bug JDK-8015483 to track the suggestion. /Erik On 2013-05-28 13:36, Maurizio Cimadamore wrote: > Hi, > as I recently went through the process of reinstalling my OS, I had to > get the JDK build up and running again (with Ubuntu). As expected, > configure kept failing because of missing libraries; I counted 4 > failures: > > *) build-essential missing (gcc, etc.) > *) X headers missing > *) cups headers missing > *) alsa headers missing > > Since the output of the configure tool is already very good (i.e. it > gives you the apt command needed to fetch missing stuff), wouldn't it > be possible to somehow go through an entire scan of the system, and > then report back a unique list of missing stuff instead of forcing > users to do this trial and error approach? > > Of course this is a very minor adjustment to an overall very > user-friendly process; I only wanted to share my experience. > > Thanks > Maurizio From maurizio.cimadamore at oracle.com Tue May 28 11:50:59 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 May 2013 12:50:59 +0100 Subject: new build system configure step - a small suggestion In-Reply-To: <51A49939.8010408@oracle.com> References: <51A496C8.4030504@oracle.com> <51A49939.8010408@oracle.com> Message-ID: <51A49A23.1060301@oracle.com> On 28/05/13 12:47, Erik Joelsson wrote: > This has been brought up before and is a good idea. At least the > headers could be checked for in one go. The compiler is needed to > check for headers, so that would need to be a separate run. Makes sense. Thanks! Maurizio > > Creating bug JDK-8015483 to track the suggestion. > > /Erik > > On 2013-05-28 13:36, Maurizio Cimadamore wrote: >> Hi, >> as I recently went through the process of reinstalling my OS, I had >> to get the JDK build up and running again (with Ubuntu). As expected, >> configure kept failing because of missing libraries; I counted 4 >> failures: >> >> *) build-essential missing (gcc, etc.) >> *) X headers missing >> *) cups headers missing >> *) alsa headers missing >> >> Since the output of the configure tool is already very good (i.e. it >> gives you the apt command needed to fetch missing stuff), wouldn't it >> be possible to somehow go through an entire scan of the system, and >> then report back a unique list of missing stuff instead of forcing >> users to do this trial and error approach? >> >> Of course this is a very minor adjustment to an overall very >> user-friendly process; I only wanted to share my experience. >> >> Thanks >> Maurizio From erik.joelsson at oracle.com Tue May 28 12:32:59 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2013 14:32:59 +0200 Subject: RFR: 8013920: Configure sets JOBS to 0 if memory is too low. Message-ID: <51A4A3FB.10800@oracle.com> Simple patch making sure that JOBS is never set to 0. http://cr.openjdk.java.net/~erikj/8013920/webrev.root.01/ /Erik From erik.joelsson at oracle.com Tue May 28 14:34:51 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 May 2013 16:34:51 +0200 Subject: RFR: 8014003: New build does not handle symlinks in workspace path Message-ID: <51A4C08B.2020707@oracle.com> Due to a difference in the default output of the pwd command on mac vs linux and solaris, configure wouldn't allow the source root to be a symlink on mac. This patch fixes this by adding -L to the pwd command, forcing it to show the logical directory rather than the symlink free one. http://cr.openjdk.java.net/~erikj/8014003/webrev.root.01/ /Erik From tim.bell at oracle.com Tue May 28 15:05:05 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 28 May 2013 08:05:05 -0700 Subject: RFR: 8013920: Configure sets JOBS to 0 if memory is too low. In-Reply-To: <51A4A3FB.10800@oracle.com> References: <51A4A3FB.10800@oracle.com> Message-ID: <51A4C7A1.2040505@oracle.com> Erik: > Simple patch making sure that JOBS is never set to 0. > > http://cr.openjdk.java.net/~erikj/8013920/webrev.root.01/ Looks good to me. Tim From mike.duigou at oracle.com Tue May 28 15:54:27 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 May 2013 08:54:27 -0700 Subject: RFR: 8013920: Configure sets JOBS to 0 if memory is too low. In-Reply-To: <51A4A3FB.10800@oracle.com> References: <51A4A3FB.10800@oracle.com> Message-ID: <4BD858EB-6D13-41FB-8169-8656017BB778@oracle.com> If memory is so low will the build actually succeed? Perhaps it might be better to error out if memory is below some threshold. Mike On May 28 2013, at 05:32 , Erik Joelsson wrote: > Simple patch making sure that JOBS is never set to 0. > > http://cr.openjdk.java.net/~erikj/8013920/webrev.root.01/ > > /Erik From erik.joelsson at oracle.com Tue May 28 16:46:10 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 28 May 2013 16:46:10 +0000 Subject: hg: jdk8/build: 8007129: build-infra Add configure --with-jtreg option for location of JTREG Message-ID: <20130528164610.A628F48D97@hg.openjdk.java.net> Changeset: e7c09a983c3c Author: erikj Date: 2013-05-28 08:50 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/e7c09a983c3c 8007129: build-infra Add configure --with-jtreg option for location of JTREG Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 From erik.joelsson at oracle.com Tue May 28 16:47:33 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 28 May 2013 16:47:33 +0000 Subject: hg: jdk8/build/langtools: 8012566: Replace find, rm, printf and similar with their proper variables Message-ID: <20130528164744.4977948D98@hg.openjdk.java.net> Changeset: 58eace4d997f Author: erikj Date: 2013-05-28 08:49 +0200 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/58eace4d997f 8012566: Replace find, rm, printf and similar with their proper variables Reviewed-by: tbell ! makefiles/BuildLangtools.gmk From david.r.chase at oracle.com Tue May 28 17:04:33 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 28 May 2013 13:04:33 -0400 Subject: Windows configure "issues" In-Reply-To: <1206BB08-E3D0-4B9D-9735-62C1510A83C8@oracle.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> <712962147.5518935.1369169656380.JavaMail.root@redhat.com> <20130521152558.514226@eggemoggin.niobe.net> <1206BB08-E3D0-4B9D-9735-62C1510A83C8@oracle.com> Message-ID: <254B8F5E-4721-4C67-BFDA-64779B8281CE@oracle.com> Non-progress report with VS2010 - Tim Bell's patches, and perhaps the residual cruft from the "uninstalled" VS2012, don't seem to be compatible with VS2010. These look like patch problems, not faulty uninstall problems, but I did need to do a by-hand removal of environment variables referencing VS2012 (machine reboot was not sufficient). The three problems encountered thus far: 1) patched system looks for msvcr110.dll, but (in system32 on Windows 7) only msvcr100.dll is available. 2) patched system expects that compiler will generate (in 32-bit mode) for "x86", not "80x86" I tweaked my built to handle those two cases. The latest failure I have not yet worked around: 3) Link complains about an extra argument _build_pch_file.obj when linking adlc . Any hints as to how to deal with this last error are welcome. David On 2013-05-24, at 5:41 PM, David Chase wrote: > FYI, progress report. > > No additional changes to the build, but the instructions may require tweaking. > > Did manage successful builds without closed subdirectories, using VS2012 and DirectX 2010. > > Required installation+build of Freetype using instructions from Volker's blog, adapted slightly > for updated activex and new build directory expectations. Not sure what is the best plan here; > the fix is all of > > mkdir ../../../lib > cp * ../../../lib > > Compared to the additional steps needed to get it built, this is not a big deal, so I am not sure it > justifies whacking on the build scripts. > > VS2012, the studio, does not come with 64-bit support, even though the compilers are there, > so this is a glitch. > > So, from the list to consider: > > { VS2010, VS2012, VS2012sp1} x {express, professional} x {32, 64} x {open, closed} > > the results thus far are: > > VS2012 x express x {32, 64} x closed = builds, runs > > VS2012 x express x 32 x open = builds, runs (release and slowdebug) > > VS2012 x express x 64 x open = blocked by initial inability to build 64-bit freetype > > next step is to try VS2010 express to see if it still works. > > David > From Mike.Duigou at oracle.COM Tue May 28 22:30:30 2013 From: Mike.Duigou at oracle.COM (Mike Duigou) Date: Tue, 28 May 2013 15:30:30 -0700 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile Message-ID: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> Hello all; As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. Thanks, Mike From tim.bell at oracle.com Wed May 29 00:44:33 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 28 May 2013 17:44:33 -0700 Subject: RFR: 8013489: New build system does not run codesign on SA-related launchers on OS X In-Reply-To: <92F826B0-1ED3-4E77-A8A0-B02602D2E59A@oracle.com> References: <51A491D7.7090305@oracle.com> <92F826B0-1ED3-4E77-A8A0-B02602D2E59A@oracle.com> Message-ID: <51A54F71.9050301@oracle.com> Looks good to me as well, but sadly I have not had a chance to test it. Tim On 05/28/13 04:19 AM, Staffan Larsen wrote: > Looks good. I have verified that this patch signs the binaries as expected. > > Thanks, > /Staffan > > On 28 maj 2013, at 13:15, Erik Joelsson wrote: > >> This patch readds the missing functionality of running codesign on certain launchers on macosx. In the old build, it was always run, but failing if the openjdk_codesign certificate wasn't present on the system. Make ignored this failure. In this patch, configure tests that the certificate is there and disables running codesign if it isn't, reducing pointless error messages in the build log. >> >> http://cr.openjdk.java.net/~erikj/8013489/webrev.01/ >> >> /Erik From david.katleman at oracle.com Wed May 29 01:00:35 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:00:35 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130529010035.B80F748DB0@hg.openjdk.java.net> Changeset: f089df41bff5 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/f089df41bff5 Added tag jdk8-b91 for changeset cb51fb4789ac ! .hgtags Changeset: 3a36c926a7aa Author: katleman Date: 2013-05-28 17:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/3a36c926a7aa Merge From david.katleman at oracle.com Wed May 29 01:00:39 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:00:39 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b91 for changeset 8f7ffb296385 Message-ID: <20130529010041.33C5148DB1@hg.openjdk.java.net> Changeset: 717aa26f8e0a Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/717aa26f8e0a Added tag jdk8-b91 for changeset 8f7ffb296385 ! .hgtags From david.katleman at oracle.com Wed May 29 01:02:01 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:02:01 +0000 Subject: hg: jdk8/build/hotspot: 41 new changesets Message-ID: <20130529010339.A5F2448DB2@hg.openjdk.java.net> Changeset: ad47de214f0c Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ad47de214f0c Added tag jdk8-b91 for changeset 7cbdf0e3725c ! .hgtags Changeset: 7ec426e29e4c Author: amurillo Date: 2013-05-17 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7ec426e29e4c 8014760: new hotspot build - hs25-b34 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f49e0508a38a Author: rbackman Date: 2013-05-15 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f49e0508a38a 4965252: JvmtiExport::post_raw_field_modification jni ref handling is odd Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiExport.cpp Changeset: 243469d929e6 Author: ctornqvi Date: 2013-05-16 15:31 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/243469d929e6 8008169: test/runtime/7158804/Test7158804.sh has bad copyright header Summary: Re-wrote test in Java in addition to fixing the Copyright notice. Also reviewed by leonid.mesnik at oracle.com Reviewed-by: coleenp, ctornqvi Contributed-by: Mikhailo Seledtsov - test/runtime/7158804/Test7158804.sh + test/runtime/CommandLine/ConfigFileParsing.java Changeset: 17db82f22f1e Author: ctornqvi Date: 2013-05-16 17:54 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/17db82f22f1e 8014511: runtime/RedefineObject/TestRedefineObject.java has incorrect classname in @run tag Summary: Corrected the class name Reviewed-by: coleenp, ctornqvi, hseigel Contributed-by: Mikhailo Seledtsov ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: 78332b46e604 Author: kevinw Date: 2013-05-16 12:40 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/78332b46e604 6313816: SA: jstack -m fails on Win32 : UnalignedAddressException Reviewed-by: sla, poonam - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! make/sa.files Changeset: 205dd30230e1 Author: shade Date: 2013-05-17 01:43 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/205dd30230e1 8012939: @Contended doesn't work correctly with inheritance Summary: Fix instance_size miscalculation. Reviewed-by: jrose, kvn ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/Inheritance1.java Changeset: b334821dad92 Author: dholmes Date: 2013-05-16 21:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b334821dad92 Merge Changeset: 50e9396d5257 Author: shade Date: 2013-05-17 01:58 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/50e9396d5257 8014509: @Contended: explicit default value behaves differently from the implicit value Summary: Treat the empty string as the default value tag Reviewed-by: kvn, twisti ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/DefaultValue.java Changeset: 074ba6269cf4 Author: dholmes Date: 2013-05-16 22:11 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/074ba6269cf4 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java Changeset: 1ba508fcd3e2 Author: dholmes Date: 2013-05-16 23:40 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1ba508fcd3e2 Merge Changeset: 6ce351ac7339 Author: rdurbin Date: 2013-05-17 08:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6ce351ac7339 7145527: sscanf must use a length in the format string Summary: Remove dead code containing last call to scanf with no string length specifier Reviewed-by: dcubed, coleenp ! src/share/vm/utilities/debug.cpp Changeset: a250c89cf9e3 Author: dcubed Date: 2013-05-17 08:56 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a250c89cf9e3 Merge Changeset: b5be63340698 Author: dcubed Date: 2013-05-17 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5be63340698 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! src/share/vm/classfile/classFileParser.cpp - test/runtime/7158804/Test7158804.sh Changeset: 386b77bf6427 Author: dcubed Date: 2013-05-17 17:52 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/386b77bf6427 Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: a5d6f0c3585f Author: iklam Date: 2013-05-18 20:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a5d6f0c3585f 8014262: PrintStringTableStatistics should include more footprint info Summary: Added info for the string/symbol objects and the hash entries Reviewed-by: coleenp, rbackman ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 5e3573e08a83 Author: shade Date: 2013-05-20 15:43 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5e3573e08a83 8014871: Move @Contended regression tests to the same place Summary: Move the missing test to appropriate location. Reviewed-by: dholmes, sla - test/runtime/8003985/Test8003985.java + test/runtime/contended/Basic.java Changeset: bbddfb08190f Author: shade Date: 2013-05-20 23:41 +0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bbddfb08190f 8014878: Clean up class field layout code Summary: rename/remove local variables, re-arrange instance_size calculation, more comments. Reviewed-by: kvn, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: 293b99787401 Author: dholmes Date: 2013-05-14 07:24 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/293b99787401 8014460: Need to check for non-empty EXT_LIBS_PATH before using it Reviewed-by: tbell, collins, sla, coleenp ! make/bsd/makefiles/arm.make ! make/linux/makefiles/arm.make Changeset: 26579ac80ce9 Author: bpittore Date: 2013-05-15 23:06 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/26579ac80ce9 8014669: arch specific flags not passed to some link commands Summary: EXTRA_CFLAGS does not propagate to saproc and jsig makefiles Reviewed-by: dholmes, tbell, collins ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: f8c833eb2a5f Author: jiangli Date: 2013-05-20 13:13 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f8c833eb2a5f Merge Changeset: c838b672691c Author: jiangli Date: 2013-05-23 13:40 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c838b672691c Merge Changeset: 91eba9f82325 Author: anoll Date: 2013-05-16 15:46 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/91eba9f82325 8012371: Adjust Tiered compile threshold according to available space in code cache Summary: Added command line parameter to define a threshold at which C1 compilation threshold for is increased. Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ec922e5c545a Author: anoll Date: 2013-05-22 10:28 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ec922e5c545a 8012312: hsdis fails to compile with binutils-2.23.2 Summary: added to header file to make hsdis compile with binutils 2.23.* Reviewed-by: kvn, twisti ! src/share/tools/hsdis/hsdis.c Changeset: b4907b24ed48 Author: twisti Date: 2013-05-22 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b4907b24ed48 Merge Changeset: 1682bec79205 Author: kvn Date: 2013-05-22 09:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1682bec79205 8014811: loopTransform.cpp assert(cmp_end->in(2) == limit) failed Summary: Stop current iteration of loop opts if partial_peel() failed and it created node clones outside processed loop. Reviewed-by: roland ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 71a2d06b9c2b Author: kvn Date: 2013-05-22 17:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/71a2d06b9c2b Merge Changeset: 3f281b313240 Author: kvn Date: 2013-05-22 18:25 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3f281b313240 8010927: Kitchensink crashed with SIGSEGV, Problematic frame: v ~StubRoutines::checkcast_arraycopy Summary: Changed gen_write_ref_array_post_barrier() code on x64 to pass start address and number of copied oop elements. In generate_checkcast_copy() skip post barrier code if no elements are copied. Reviewed-by: roland ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + test/compiler/8010927/Test8010927.java Changeset: 01e51113b4f5 Author: anoll Date: 2013-05-23 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/01e51113b4f5 8014430: JRE crashes instead of stop compilation on full Code Cache. Internal Error (c1_Compiler.cpp:87) Summary: Disable client compiler and switch to interpreter if there is not enough free space in the code cache. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp Changeset: 59e18b573605 Author: twisti Date: 2013-05-23 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/59e18b573605 Merge Changeset: 001ec9515f84 Author: ehelin Date: 2013-05-17 11:57 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/001ec9515f84 8014277: Remove ObjectClosure as base class for BoolObjectClosure Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! 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/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 2138a2c14831 Author: jwilhelm Date: 2013-05-19 20:31 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2138a2c14831 Merge ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 10f759898d40 Author: tamao Date: 2013-05-20 10:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/10f759898d40 7186737: Unable to allocate bit maps or card tables for parallel gc for the requested heap Summary: Print helpful error message when VM aborts due to inability of allocating bit maps or card tables Reviewed-by: jmasa, stefank Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 2b1a9d972fc2 Author: jmasa Date: 2013-05-20 22:34 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2b1a9d972fc2 8014862: Add fast Metasapce capacity and used per MetadataType Reviewed-by: ehelin, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 28e53b8db94f Author: brutisso Date: 2013-05-21 08:50 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/28e53b8db94f 7066063: CMS: "Conservation Principle" assert failed Summary: Add call to coalBirth() in CompactibleFreeListSpace::reset() Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 5ed122fbd0ef Author: brutisso Date: 2013-05-21 10:39 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5ed122fbd0ef Merge Changeset: 6702da6b6082 Author: tschatzl Date: 2013-05-21 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6702da6b6082 8014405: G1: PerRegionTable::fl_mem_size() calculates size of the free list using wrong element sizes Summary: Instead of using a simple sizeof(), ask the PerRegionTable class about its size when iterating over the free list. Reviewed-by: jwilhelm, brutisso ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/prims/jni.cpp Changeset: 7c5a1b62f53d Author: brutisso Date: 2013-05-22 08:04 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7c5a1b62f53d 8014971: Minor code cleanup of the freelist management Reviewed-by: jwilhelm, jmasa, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp Changeset: 62890ed7e2a8 Author: jwilhelm Date: 2013-05-24 09:29 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/62890ed7e2a8 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 38da9f4f6709 Author: amurillo Date: 2013-05-24 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/38da9f4f6709 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 092018493d3b Author: amurillo Date: 2013-05-24 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/092018493d3b Added tag hs25-b34 for changeset 38da9f4f6709 ! .hgtags From david.katleman at oracle.com Wed May 29 01:04:35 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:04:35 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b91 for changeset e3065fb07877 Message-ID: <20130529010440.8F5AD48DB3@hg.openjdk.java.net> Changeset: 827b59af45f3 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/827b59af45f3 Added tag jdk8-b91 for changeset e3065fb07877 ! .hgtags From david.katleman at oracle.com Wed May 29 01:04:45 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:04:45 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b91 for changeset 0bb1a9fa56b0 Message-ID: <20130529010451.798C348DB4@hg.openjdk.java.net> Changeset: a0f604766ca1 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/a0f604766ca1 Added tag jdk8-b91 for changeset 0bb1a9fa56b0 ! .hgtags From david.katleman at oracle.com Wed May 29 01:05:02 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:05:02 +0000 Subject: hg: jdk8/build/jdk: Added tag jdk8-b91 for changeset 169451cf0cc5 Message-ID: <20130529010538.D1B9848DB5@hg.openjdk.java.net> Changeset: fbd926b20201 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fbd926b20201 Added tag jdk8-b91 for changeset 169451cf0cc5 ! .hgtags From david.katleman at oracle.com Wed May 29 01:06:36 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:06:36 +0000 Subject: hg: jdk8/build/langtools: 2 new changesets Message-ID: <20130529010646.445EA48DB6@hg.openjdk.java.net> Changeset: 4830d661c4f9 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/4830d661c4f9 Added tag jdk8-b91 for changeset 997c0fae2b12 ! .hgtags Changeset: 3597773628a4 Author: katleman Date: 2013-05-28 17:58 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3597773628a4 Merge From david.katleman at oracle.com Wed May 29 01:06:50 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 01:06:50 +0000 Subject: hg: jdk8/build/nashorn: Added tag jdk8-b91 for changeset 6b9f41203800 Message-ID: <20130529010652.DF73B48DB7@hg.openjdk.java.net> Changeset: dee23cce5235 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/dee23cce5235 Added tag jdk8-b91 for changeset 6b9f41203800 ! .hgtags From tim.bell at oracle.com Wed May 29 02:40:04 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 28 May 2013 19:40:04 -0700 Subject: RFR: 8014003: New build does not handle symlinks in workspace path In-Reply-To: <51A4C08B.2020707@oracle.com> References: <51A4C08B.2020707@oracle.com> Message-ID: <51A56A84.3010009@oracle.com> Erik: > Due to a difference in the default output of the pwd command on mac vs > linux and solaris, configure wouldn't allow the source root to be a > symlink on mac. This patch fixes this by adding -L to the pwd command, > forcing it to show the logical directory rather than the symlink free > one. > > http://cr.openjdk.java.net/~erikj/8014003/webrev.root.01/ Looks good to me. I checked pwd on Solaris, Linux, Cygwin on Windows, and Mac. They all show -L as an option. Unfortunately, I don't have the means at this time to check other platforms such as (non-Mac) BSD, AIX, HP-UX, Unicos, etc. Tim From david.holmes at oracle.com Wed May 29 02:56:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2013 12:56:11 +1000 Subject: Windows configure "issues" In-Reply-To: <254B8F5E-4721-4C67-BFDA-64779B8281CE@oracle.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> <712962147.5518935.1369169656380.JavaMail.root@redhat.com> <20130521152558.514226@eggemoggin.niobe.net> <1206BB08-E3D0-4B9D-9735-62C1510A83C8@oracle.com> <254B8F5E-4721-4C67-BFDA-64779B8281CE@oracle.com> Message-ID: <51A56E4B.8080205@oracle.com> On 29/05/2013 3:04 AM, David Chase wrote: > Non-progress report with VS2010 - > > Tim Bell's patches, and perhaps the residual cruft from the "uninstalled" VS2012, > don't seem to be compatible with VS2010. These look like patch problems, not > faulty uninstall problems, but I did need to do a by-hand removal of environment > variables referencing VS2012 (machine reboot was not sufficient). > > The three problems encountered thus far: > > 1) patched system looks for msvcr110.dll, but (in system32 on Windows 7) > only msvcr100.dll is available. > > 2) patched system expects that compiler will generate (in 32-bit mode) for "x86", not "80x86" > > I tweaked my built to handle those two cases. The latest failure I have not yet worked around: > > 3) Link complains about an extra argument _build_pch_file.obj when linking adlc . > > Any hints as to how to deal with this last error are welcome. Disable pre-compiled headers ? David > David > > On 2013-05-24, at 5:41 PM, David Chase wrote: > >> FYI, progress report. >> >> No additional changes to the build, but the instructions may require tweaking. >> >> Did manage successful builds without closed subdirectories, using VS2012 and DirectX 2010. >> >> Required installation+build of Freetype using instructions from Volker's blog, adapted slightly >> for updated activex and new build directory expectations. Not sure what is the best plan here; >> the fix is all of >> >> mkdir ../../../lib >> cp * ../../../lib >> >> Compared to the additional steps needed to get it built, this is not a big deal, so I am not sure it >> justifies whacking on the build scripts. >> >> VS2012, the studio, does not come with 64-bit support, even though the compilers are there, >> so this is a glitch. >> >> So, from the list to consider: >> >> { VS2010, VS2012, VS2012sp1} x {express, professional} x {32, 64} x {open, closed} >> >> the results thus far are: >> >> VS2012 x express x {32, 64} x closed = builds, runs >> >> VS2012 x express x 32 x open = builds, runs (release and slowdebug) >> >> VS2012 x express x 64 x open = blocked by initial inability to build 64-bit freetype >> >> next step is to try VS2010 express to see if it still works. >> >> David >> > From tim.bell at oracle.com Wed May 29 03:27:59 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 28 May 2013 20:27:59 -0700 Subject: Windows configure "issues" In-Reply-To: <51A56E4B.8080205@oracle.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> <712962147.5518935.1369169656380.JavaMail.root@redhat.com> <20130521152558.514226@eggemoggin.niobe.net> <1206BB08-E3D0-4B9D-9735-62C1510A83C8@oracle.com> <254B8F5E-4721-4C67-BFDA-64779B8281CE@oracle.com> <51A56E4B.8080205@oracle.com> Message-ID: <51A575BF.90101@oracle.com> On 05/28/13 07:56 PM, David Holmes wrote: > On 29/05/2013 3:04 AM, David Chase wrote: >> Non-progress report with VS2010 - >> >> Tim Bell's patches, and perhaps the residual cruft from the >> "uninstalled" VS2012, >> don't seem to be compatible with VS2010. These look like patch >> problems, not >> faulty uninstall problems, but I did need to do a by-hand removal of >> environment >> variables referencing VS2012 (machine reboot was not sufficient). >> >> The three problems encountered thus far: >> >> 1) patched system looks for msvcr110.dll, but (in system32 on Windows 7) >> only msvcr100.dll is available. >> >> 2) patched system expects that compiler will generate (in 32-bit >> mode) for "x86", not "80x86" >> >> I tweaked my built to handle those two cases. The latest failure I >> have not yet worked around: >> >> 3) Link complains about an extra argument _build_pch_file.obj when >> linking adlc . >> >> Any hints as to how to deal with this last error are welcome. > > Disable pre-compiled headers ? > > David Possibly - but I tried for several days to come up with a build configuration that worked for both VS 2010 and 2012. I ran out of time for that experiment. Nice to have, but if we do not move to VS2012 with JDK8, we will have to wait until JDK9, so upgrading is where my focus must remain. Keep in mind that changing compilers on Windows[tm] also dictates a change in runtime (see above, msvcr110.dll versus msvcr100.dll). Such a change also affects JNI libraries built by any organization using that JDK. Nothing good will happen if two runtime libraries exist in the same address space. It may actually work for a while, but all bets are off. Tim > > >> David >> >> On 2013-05-24, at 5:41 PM, David Chase wrote: >> >>> FYI, progress report. >>> >>> No additional changes to the build, but the instructions may require >>> tweaking. >>> >>> Did manage successful builds without closed subdirectories, using >>> VS2012 and DirectX 2010. >>> >>> Required installation+build of Freetype using instructions from >>> Volker's blog, adapted slightly >>> for updated activex and new build directory expectations. Not sure >>> what is the best plan here; >>> the fix is all of >>> >>> mkdir ../../../lib >>> cp * ../../../lib >>> >>> Compared to the additional steps needed to get it built, this is not >>> a big deal, so I am not sure it >>> justifies whacking on the build scripts. >>> >>> VS2012, the studio, does not come with 64-bit support, even though >>> the compilers are there, >>> so this is a glitch. >>> >>> So, from the list to consider: >>> >>> { VS2010, VS2012, VS2012sp1} x {express, professional} x {32, 64} x >>> {open, closed} >>> >>> the results thus far are: >>> >>> VS2012 x express x {32, 64} x closed = builds, runs >>> >>> VS2012 x express x 32 x open = builds, runs (release and slowdebug) >>> >>> VS2012 x express x 64 x open = blocked by initial inability to build >>> 64-bit freetype >>> >>> next step is to try VS2010 express to see if it still works. >>> >>> David >>> >> From mike.duigou at oracle.com Wed May 29 03:38:34 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 28 May 2013 20:38:34 -0700 Subject: RFR: 8014003: New build does not handle symlinks in workspace path In-Reply-To: <51A56A84.3010009@oracle.com> References: <51A4C08B.2020707@oracle.com> <51A56A84.3010009@oracle.com> Message-ID: http://pubs.opengroup.org/onlinepubs/009695399/utilities/pwd.html Yep, -L is part of IEEE Std 1003.1-2001 standard which basically everything in use today supports. If only the same could be said about C99. Mike On May 28 2013, at 19:40 , Tim Bell wrote: > Erik: > >> Due to a difference in the default output of the pwd command on mac vs linux and solaris, configure wouldn't allow the source root to be a symlink on mac. This patch fixes this by adding -L to the pwd command, forcing it to show the logical directory rather than the symlink free one. >> >> http://cr.openjdk.java.net/~erikj/8014003/webrev.root.01/ > > Looks good to me. > > I checked pwd on Solaris, Linux, Cygwin on Windows, and Mac. They all show -L as an option. Unfortunately, I don't have the means at this time to check other platforms such as (non-Mac) BSD, AIX, HP-UX, Unicos, etc. > > > Tim > > From erik.joelsson at oracle.com Wed May 29 07:46:41 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 May 2013 09:46:41 +0200 Subject: RFR: 8013920: Configure sets JOBS to 0 if memory is too low. In-Reply-To: <4BD858EB-6D13-41FB-8169-8656017BB778@oracle.com> References: <51A4A3FB.10800@oracle.com> <4BD858EB-6D13-41FB-8169-8656017BB778@oracle.com> Message-ID: <51A5B261.7000906@oracle.com> The problem was reported on this list a while back, running on a virtual linux with 1GB of ram. Working around the JOBS=0 issue, the build still succeeded. Perhaps having a low limit on memory would be good idea, but to determine it, we would need to test it. /Erik On 2013-05-28 17:54, Mike Duigou wrote: > If memory is so low will the build actually succeed? Perhaps it might be better to error out if memory is below some threshold. > > Mike > > On May 28 2013, at 05:32 , Erik Joelsson wrote: > >> Simple patch making sure that JOBS is never set to 0. >> >> http://cr.openjdk.java.net/~erikj/8013920/webrev.root.01/ >> >> /Erik From erik.joelsson at oracle.com Wed May 29 08:06:17 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 May 2013 10:06:17 +0200 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile In-Reply-To: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> References: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> Message-ID: <51A5B6F9.8020404@oracle.com> On 2013-05-29 00:30, Mike Duigou wrote: > Hello all; > > As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. > > Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. > > http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ When trying to find a program on the path, please use the builtin AC_PATH_PROG or similar macro. Using "which" is bad as it works differently on all platforms and we have worked hard to remove its use in configure. It looks like at that point, JTREGEXE is required to be found, then you can use BASIC_REQUIRE_PROG which also fails with a suitable error message. There is no need to repeat AC_SUBST calls and making them conditionals has no effect to my knowledge. I would move them out of the if statements and put them at the end of the block. If JT_HOME is set in the environment, it is just accepted and not validated. Should it be? > If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. > If you want to have it undefined, you can achieve it with the following pattern (look at OPENJDK for an example): In .m4: SET_JT_HOME="JT_HOME=$JT_HOME" In spec.gmk.in: @SET_JT_HOME@ Keeping it undefined when not set would let the makefiles pick it up from the environment, a pattern the new build is trying to break. /Erik > Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. > > Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. > > Thanks, > > Mike From erik.joelsson at oracle.com Wed May 29 11:44:34 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 May 2013 13:44:34 +0200 Subject: RFR: 8014003: New build does not handle symlinks in workspace path In-Reply-To: References: <51A4C08B.2020707@oracle.com> <51A56A84.3010009@oracle.com> Message-ID: <51A5EA22.8060509@oracle.com> Unfortunately the /bin/pwd on fedora 9 doesn't follow this. I will try to figure out something else. /Erik On 2013-05-29 05:38, Mike Duigou wrote: > http://pubs.opengroup.org/onlinepubs/009695399/utilities/pwd.html > > Yep, -L is part of IEEE Std 1003.1-2001 standard which basically everything in use today supports. If only the same could be said about C99. > > Mike > > > On May 28 2013, at 19:40 , Tim Bell wrote: > >> Erik: >> >>> Due to a difference in the default output of the pwd command on mac vs linux and solaris, configure wouldn't allow the source root to be a symlink on mac. This patch fixes this by adding -L to the pwd command, forcing it to show the logical directory rather than the symlink free one. >>> >>> http://cr.openjdk.java.net/~erikj/8014003/webrev.root.01/ >> Looks good to me. >> >> I checked pwd on Solaris, Linux, Cygwin on Windows, and Mac. They all show -L as an option. Unfortunately, I don't have the means at this time to check other platforms such as (non-Mac) BSD, AIX, HP-UX, Unicos, etc. >> >> >> Tim >> >> From david.r.chase at oracle.com Wed May 29 14:24:50 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 29 May 2013 10:24:50 -0400 Subject: Windows configure "issues" In-Reply-To: <51A575BF.90101@oracle.com> References: <9EE05E43-798C-4671-9869-F42DF2CA0692@oracle.com> <21AA852D-666A-498C-9B63-D397A628E27E@oracle.com> <519BC439.3050201@redhat.com> <712962147.5518935.1369169656380.JavaMail.root@redhat.com> <20130521152558.514226@eggemoggin.niobe.net> <1206BB08-E3D0-4B9D-9735-62C1510A83C8@oracle.com> <254B8F5E-4721-4C67-BFDA-64779B8281CE@oracle.com> <51A56E4B.8080205@oracle.com> <51A575BF.90101@oracle.com> Message-ID: On 2013-05-28, at 11:27 PM, Tim Bell wrote: > > Possibly - but I tried for several days to come up with a build configuration that worked for both VS 2010 and 2012. > > I ran out of time for that experiment. Nice to have, but if we do not move to VS2012 with JDK8, we will have to wait until JDK9, so upgrading is where my focus must remain. > > Keep in mind that changing compilers on Windows[tm] also dictates a change in runtime (see above, msvcr110.dll versus msvcr100.dll). Such a change also affects JNI libraries built by any organization using that JDK. Nothing good will happen if two runtime libraries exist in the same address space. It may actually work for a while, but all bets are off. > > Tim I think upgrading would be lovely. Is there anything (testing, taking notes on build steps) that I can do to help? Right now I am working with an Oracle-issue Windows 7 laptop, still running the "Express" editions, so I can do a plausible job of pretending to be an open, non-Oracle build. David From david.katleman at oracle.com Wed May 29 17:17:15 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 17:17:15 +0000 Subject: hg: jdk8/build/jaxp: 8015525: JDK8 b91 source with GPL header errors Message-ID: <20130529171721.3DC8048DF3@hg.openjdk.java.net> Changeset: 1ab5d8d6eab8 Author: katleman Date: 2013-05-29 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/1ab5d8d6eab8 8015525: JDK8 b91 source with GPL header errors Reviewed-by: dholmes, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java From david.katleman at oracle.com Wed May 29 17:16:48 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 17:16:48 +0000 Subject: hg: jdk8/build/langtools: 8015525: JDK8 b91 source with GPL header errors Message-ID: <20130529171654.B69E248DF2@hg.openjdk.java.net> Changeset: 149890642a0e Author: katleman Date: 2013-05-29 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/149890642a0e 8015525: JDK8 b91 source with GPL header errors Reviewed-by: dholmes, lancea ! test/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java From david.katleman at oracle.com Wed May 29 17:17:37 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 29 May 2013 17:17:37 +0000 Subject: hg: jdk8/build/jdk: 8015525: JDK8 b91 source with GPL header errors Message-ID: <20130529171813.619F248DF4@hg.openjdk.java.net> Changeset: a2a2a91075ad Author: katleman Date: 2013-05-29 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a2a2a91075ad 8015525: JDK8 b91 source with GPL header errors Reviewed-by: dholmes, lancea ! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java ! test/jdk/lambda/MethodReferenceTestInstanceMethod.java ! test/jdk/lambda/MethodReferenceTestKinds.java ! test/jdk/lambda/MethodReferenceTestSueCase1.java ! test/jdk/lambda/MethodReferenceTestSueCase2.java ! test/jdk/lambda/MethodReferenceTestSueCase4.java ! test/jdk/lambda/separate/AttributeInjector.java ! test/jdk/lambda/separate/ClassFile.java ! test/jdk/lambda/separate/ClassFilePreprocessor.java ! test/jdk/lambda/separate/ClassToInterfaceConverter.java ! test/jdk/lambda/separate/Compiler.java ! test/jdk/lambda/separate/DirectedClassLoader.java ! test/jdk/lambda/separate/SourceModel.java ! test/jdk/lambda/separate/TestHarness.java ! test/jdk/lambda/vm/DefaultMethodRegressionTests.java ! test/jdk/lambda/vm/DefaultMethodsTest.java ! test/jdk/lambda/vm/InterfaceAccessFlagsTest.java From erik.joelsson at oracle.com Thu May 30 08:03:49 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 30 May 2013 08:03:49 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130530080349.672F248E1E@hg.openjdk.java.net> Changeset: 33b6df33a2b7 Author: erikj Date: 2013-05-29 13:58 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/33b6df33a2b7 8013920: Configure sets JOBS to 0 if memory is too low. Reviewed-by: tbell ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh Changeset: 03e60e87d92a Author: erikj Date: 2013-05-29 14:01 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/03e60e87d92a 8013489: New build system does not run codesign on SA-related launchers on OS X Reviewed-by: sla, tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk ! common/makefiles/NativeCompilation.gmk From erik.joelsson at oracle.com Thu May 30 08:04:02 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 30 May 2013 08:04:02 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130530080445.1461E48E1F@hg.openjdk.java.net> Changeset: 583e6dec1ed7 Author: erikj Date: 2013-05-29 14:01 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/583e6dec1ed7 8013489: New build system does not run codesign on SA-related launchers on OS X Reviewed-by: sla, tbell ! makefiles/CompileLaunchers.gmk Changeset: d8c97d6772cd Author: erikj Date: 2013-05-30 09:29 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d8c97d6772cd Merge From erik.joelsson at oracle.com Thu May 30 09:22:49 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2013 11:22:49 +0200 Subject: RFR: 8014003: New build does not handle symlinks in workspace path In-Reply-To: <51A5EA22.8060509@oracle.com> References: <51A4C08B.2020707@oracle.com> <51A56A84.3010009@oracle.com> <51A5EA22.8060509@oracle.com> Message-ID: <51A71A69.3050706@oracle.com> The bash builtin version of pwd seems to behave more uniformly. Changed to use this version of pwd and also explicitly added either -L or -P to all invocations of it to make sure the expected result was generated. http://cr.openjdk.java.net/~erikj/8014003/webrev.root.02/ /Erik On 2013-05-29 13:44, Erik Joelsson wrote: > Unfortunately the /bin/pwd on fedora 9 doesn't follow this. I will try > to figure out something else. > > /Erik > > On 2013-05-29 05:38, Mike Duigou wrote: >> http://pubs.opengroup.org/onlinepubs/009695399/utilities/pwd.html >> >> Yep, -L is part of IEEE Std 1003.1-2001 standard which basically >> everything in use today supports. If only the same could be said >> about C99. >> >> Mike >> >> >> On May 28 2013, at 19:40 , Tim Bell wrote: >> >>> Erik: >>> >>>> Due to a difference in the default output of the pwd command on mac >>>> vs linux and solaris, configure wouldn't allow the source root to >>>> be a symlink on mac. This patch fixes this by adding -L to the pwd >>>> command, forcing it to show the logical directory rather than the >>>> symlink free one. >>>> >>>> http://cr.openjdk.java.net/~erikj/8014003/webrev.root.01/ >>> Looks good to me. >>> >>> I checked pwd on Solaris, Linux, Cygwin on Windows, and Mac. They >>> all show -L as an option. Unfortunately, I don't have the means at >>> this time to check other platforms such as (non-Mac) BSD, AIX, >>> HP-UX, Unicos, etc. >>> >>> >>> Tim >>> >>> From erik.joelsson at oracle.com Thu May 30 12:45:16 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 May 2013 14:45:16 +0200 Subject: RFR: 7195481: FDS: debuginfo file for libjdwp.so is missed Message-ID: <51A749DC.9030408@oracle.com> Simple fix enabling FDS for libjdwp.so, which was mistakenly missed in the FDS project. http://cr.openjdk.java.net/~erikj/7195481/webrev.jdk.01/ /Erik From tim.bell at oracle.com Thu May 30 15:10:37 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 30 May 2013 08:10:37 -0700 Subject: RFR: 7195481: FDS: debuginfo file for libjdwp.so is missed In-Reply-To: <51A749DC.9030408@oracle.com> References: <51A749DC.9030408@oracle.com> Message-ID: <51A76BED.4000309@oracle.com> Erik: > Simple fix enabling FDS for libjdwp.so, which was mistakenly missed in > the FDS project. > > http://cr.openjdk.java.net/~erikj/7195481/webrev.jdk.01 Looks good to me. Tim From tim.bell at oracle.com Thu May 30 16:05:57 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 30 May 2013 09:05:57 -0700 Subject: RFR: 8014003: New build does not handle symlinks in workspace path In-Reply-To: <51A71A69.3050706@oracle.com> References: <51A4C08B.2020707@oracle.com> <51A56A84.3010009@oracle.com> <51A5EA22.8060509@oracle.com> <51A71A69.3050706@oracle.com> Message-ID: <51A778E5.7000307@oracle.com> Erik: OK - looks good to me. Tim On 05/30/13 02:22 AM, Erik Joelsson wrote: > The bash builtin version of pwd seems to behave more uniformly. > Changed to use this version of pwd and also explicitly added either -L > or -P to all invocations of it to make sure the expected result was > generated. > > http://cr.openjdk.java.net/~erikj/8014003/webrev.root.02/ > > /Erik > > On 2013-05-29 13:44, Erik Joelsson wrote: >> Unfortunately the /bin/pwd on fedora 9 doesn't follow this. I will >> try to figure out something else. >> >> /Erik >> >> On 2013-05-29 05:38, Mike Duigou wrote: >>> http://pubs.opengroup.org/onlinepubs/009695399/utilities/pwd.html >>> >>> Yep, -L is part of IEEE Std 1003.1-2001 standard which basically >>> everything in use today supports. If only the same could be said >>> about C99. >>> >>> Mike >>> >>> >>> On May 28 2013, at 19:40 , Tim Bell wrote: >>> >>>> Erik: >>>> >>>>> Due to a difference in the default output of the pwd command on >>>>> mac vs linux and solaris, configure wouldn't allow the source root >>>>> to be a symlink on mac. This patch fixes this by adding -L to the >>>>> pwd command, forcing it to show the logical directory rather than >>>>> the symlink free one. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/8014003/webrev.root.01/ >>>> Looks good to me. >>>> >>>> I checked pwd on Solaris, Linux, Cygwin on Windows, and Mac. They >>>> all show -L as an option. Unfortunately, I don't have the means at >>>> this time to check other platforms such as (non-Mac) BSD, AIX, >>>> HP-UX, Unicos, etc. >>>> >>>> >>>> Tim >>>> >>>> From Mike.Duigou at oracle.com Thu May 30 18:05:33 2013 From: Mike.Duigou at oracle.com (Mike Duigou) Date: Thu, 30 May 2013 11:05:33 -0700 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile In-Reply-To: <51A5B6F9.8020404@oracle.com> References: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> <51A5B6F9.8020404@oracle.com> Message-ID: <42E3F1C6-884D-4820-A010-F2605A25A8BB@oracle.com> Thank you for the feedback. I have updated the webrev : http://cr.openjdk.java.net/~mduigou/JDK-8015510/1/webrev/ It's a lot simpler now. The one part I couldn't make perfect was the check if test ! -f "$JTREGEXE"; then AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) fi which only checks for whether the executable exists and not whether it is executable. I understand the "-x" text condition can't be used because it doesn't work on windows. Alternatives? Mike On May 29 2013, at 01:06 , Erik Joelsson wrote: > > > On 2013-05-29 00:30, Mike Duigou wrote: >> Hello all; >> >> As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. >> >> Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ > When trying to find a program on the path, please use the builtin AC_PATH_PROG or similar macro. Using "which" is bad as it works differently on all platforms and we have worked hard to remove its use in configure. It looks like at that point, JTREGEXE is required to be found, then you can use BASIC_REQUIRE_PROG which also fails with a suitable error message. > > There is no need to repeat AC_SUBST calls and making them conditionals has no effect to my knowledge. I would move them out of the if statements and put them at the end of the block. > > If JT_HOME is set in the environment, it is just accepted and not validated. Should it be? >> If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. >> > If you want to have it undefined, you can achieve it with the following pattern (look at OPENJDK for an example): > In .m4: SET_JT_HOME="JT_HOME=$JT_HOME" > In spec.gmk.in: @SET_JT_HOME@ > > Keeping it undefined when not set would let the makefiles pick it up from the environment, a pattern the new build is trying to break. > > /Erik >> Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. >> >> Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. >> >> Thanks, >> >> Mike From erik.joelsson at oracle.com Fri May 31 08:06:53 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2013 10:06:53 +0200 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile In-Reply-To: <42E3F1C6-884D-4820-A010-F2605A25A8BB@oracle.com> References: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> <51A5B6F9.8020404@oracle.com> <42E3F1C6-884D-4820-A010-F2605A25A8BB@oracle.com> Message-ID: <51A85A1D.1040705@oracle.com> On 2013-05-30 20:05, Mike Duigou wrote: > Thank you for the feedback. I have updated the webrev : > > http://cr.openjdk.java.net/~mduigou/JDK-8015510/1/webrev/ > > It's a lot simpler now. Now my concern is that configure will fail without either specifying --without-jtreg or having it available. I doubt RE has it available on their build machines and it's not a requirement to just build. It would be better if it was optional by default and only required if you specified --with-jtreg. > The one part I couldn't make perfect was the check > > if test ! -f "$JTREGEXE"; then > AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) > fi > > which only checks for whether the executable exists and not whether it is executable. I understand the "-x" text condition can't be used because it doesn't work on windows. Alternatives? You could try executing it with a known parameter that returns 0 and outputs something known (-version or similar), and see that it gives the expected result, but I wouldn't go that far. /Erik > Mike > > On May 29 2013, at 01:06 , Erik Joelsson wrote: > >> >> On 2013-05-29 00:30, Mike Duigou wrote: >>> Hello all; >>> >>> As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. >>> >>> Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ >> When trying to find a program on the path, please use the builtin AC_PATH_PROG or similar macro. Using "which" is bad as it works differently on all platforms and we have worked hard to remove its use in configure. It looks like at that point, JTREGEXE is required to be found, then you can use BASIC_REQUIRE_PROG which also fails with a suitable error message. >> >> There is no need to repeat AC_SUBST calls and making them conditionals has no effect to my knowledge. I would move them out of the if statements and put them at the end of the block. >> >> If JT_HOME is set in the environment, it is just accepted and not validated. Should it be? >>> If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. >>> >> If you want to have it undefined, you can achieve it with the following pattern (look at OPENJDK for an example): >> In .m4: SET_JT_HOME="JT_HOME=$JT_HOME" >> In spec.gmk.in: @SET_JT_HOME@ >> >> Keeping it undefined when not set would let the makefiles pick it up from the environment, a pattern the new build is trying to break. >> >> /Erik >>> Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. >>> >>> Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. >>> >>> Thanks, >>> >>> Mike From erik.joelsson at oracle.com Fri May 31 10:14:00 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2013 12:14:00 +0200 Subject: RFR: 8010785: JDK 8 build on Linux fails with new build mechanism In-Reply-To: <5166961E.3090607@oracle.com> References: <5166961E.3090607@oracle.com> Message-ID: <51A877E8.1090105@oracle.com> Finally getting back to this. Updated webrevs: http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.02/ http://cr.openjdk.java.net/~erikj/8010785/webrev.root.02/ The javascript part is no longer needed since it has been removed. /Erik On 2013-04-11 12:53, Erik Joelsson wrote: > Open part of this review. > > The licensee bundles aren't buildable with the new build for several > reasons. I've tried to fix all the issues that I've found and have now > successfully built them on linux, windows and solaris. Here is a list > of the changes that I had to do to OpenJDK: > > * Filter out javascript src when the rhino source isn't available. > Also do not copy rhino resource files when not available. This is > controlled by a new variable, INCLUDE_JAVASCRIPT, which we control > from closed configure and shouldn't affect the OpenJDK build. I also > moved the copying of the resources to the correct makefile, > CopyIntoClasses.gmk. > > * If javax/crypto isn't available, jce.jar needs to be added to the > bootclasspath of the main java compilation. Also, a number of security > jar files shouldn't be built at all. (Normally these are built just to > exercise the logic, but not used.) The kerberos library is also > excluded by this. Introduced the variable BUILD_CRYPTO, also set by > closed configure to control this. I used the logic ifneq > ($(BUILD_CRYPTO),no) to not change the behavior if the variable isn't > set, which it won't be in the open case. > > * I removed the logic for setting the closed cacerts file in the open > configure script. > > * Also fixing JDK-8005655 by adding logic for unzipping sec-bin (and > friends) if available. > > http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.01/ > http://cr.openjdk.java.net/~erikj/8010785/webrev.root.01/ > > /Erik From Mike.Duigou at oracle.com Fri May 31 13:47:52 2013 From: Mike.Duigou at oracle.com (Mike Duigou) Date: Fri, 31 May 2013 06:47:52 -0700 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile In-Reply-To: <51A85A1D.1040705@oracle.com> References: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> <51A5B6F9.8020404@oracle.com> <42E3F1C6-884D-4820-A010-F2605A25A8BB@oracle.com> <51A85A1D.1040705@oracle.com> Message-ID: <4B4CDC88-85B7-4E38-99A1-27C0A57F8274@oracle.com> On May 31 2013, at 01:06 , Erik Joelsson wrote: > > > On 2013-05-30 20:05, Mike Duigou wrote: >> Thank you for the feedback. I have updated the webrev : >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015510/1/webrev/ >> >> It's a lot simpler now. > Now my concern is that configure will fail without either specifying --without-jtreg or having it available. I doubt RE has it available on their build machines and it's not a requirement to just build. It would be better if it was optional by default and only required if you specified --with-jtreg. It is optional. Not specifying anything is the same as specifying "--without-jtreg". --without-jtreg disables --with-jtreg=no disables (nothing) disables --with-jtreg=path uses path $JT_HOME --with-jtreg uses $JT_HOME location (on PATH) --with-jtreg uses PATH location >> The one part I couldn't make perfect was the check >> >> if test ! -f "$JTREGEXE"; then >> AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) >> fi >> >> which only checks for whether the executable exists and not whether it is executable. I understand the "-x" text condition can't be used because it doesn't work on windows. Alternatives? > You could try executing it with a known parameter that returns 0 and outputs something known (-version or similar), and see that it gives the expected result, but I wouldn't go that far. OK, I will leave it as is then I think this patch is complete then. > > /Erik >> Mike >> >> On May 29 2013, at 01:06 , Erik Joelsson wrote: >> >>> >>> On 2013-05-29 00:30, Mike Duigou wrote: >>>> Hello all; >>>> >>>> As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. >>>> >>>> Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ >>> When trying to find a program on the path, please use the builtin AC_PATH_PROG or similar macro. Using "which" is bad as it works differently on all platforms and we have worked hard to remove its use in configure. It looks like at that point, JTREGEXE is required to be found, then you can use BASIC_REQUIRE_PROG which also fails with a suitable error message. >>> >>> There is no need to repeat AC_SUBST calls and making them conditionals has no effect to my knowledge. I would move them out of the if statements and put them at the end of the block. >>> >>> If JT_HOME is set in the environment, it is just accepted and not validated. Should it be? >>>> If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. >>>> >>> If you want to have it undefined, you can achieve it with the following pattern (look at OPENJDK for an example): >>> In .m4: SET_JT_HOME="JT_HOME=$JT_HOME" >>> In spec.gmk.in: @SET_JT_HOME@ >>> >>> Keeping it undefined when not set would let the makefiles pick it up from the environment, a pattern the new build is trying to break. >>> >>> /Erik >>>> Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. >>>> >>>> Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. >>>> >>>> Thanks, >>>> >>>> Mike From erik.joelsson at oracle.com Fri May 31 14:14:50 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 31 May 2013 16:14:50 +0200 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile In-Reply-To: <4B4CDC88-85B7-4E38-99A1-27C0A57F8274@oracle.com> References: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> <51A5B6F9.8020404@oracle.com> <42E3F1C6-884D-4820-A010-F2605A25A8BB@oracle.com> <51A85A1D.1040705@oracle.com> <4B4CDC88-85B7-4E38-99A1-27C0A57F8274@oracle.com> Message-ID: <51A8B05A.3090609@oracle.com> On 2013-05-31 15:47, Mike Duigou wrote: > On May 31 2013, at 01:06 , Erik Joelsson wrote: > >> >> On 2013-05-30 20:05, Mike Duigou wrote: >>> Thank you for the feedback. I have updated the webrev : >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8015510/1/webrev/ >>> >>> It's a lot simpler now. >> Now my concern is that configure will fail without either specifying --without-jtreg or having it available. I doubt RE has it available on their build machines and it's not a requirement to just build. It would be better if it was optional by default and only required if you specified --with-jtreg. > It is optional. Not specifying anything is the same as specifying "--without-jtreg". > > --without-jtreg disables > --with-jtreg=no disables > (nothing) disables > --with-jtreg=path uses path > $JT_HOME --with-jtreg uses $JT_HOME location > (on PATH) --with-jtreg uses PATH location > I tried applying your patch and ran just "bash configure" and it failed on missing jtreg, so i think you might have missed something in the logic for the default case. /Erik >>> The one part I couldn't make perfect was the check >>> >>> if test ! -f "$JTREGEXE"; then >>> AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) >>> fi >>> >>> which only checks for whether the executable exists and not whether it is executable. I understand the "-x" text condition can't be used because it doesn't work on windows. Alternatives? >> You could try executing it with a known parameter that returns 0 and outputs something known (-version or similar), and see that it gives the expected result, but I wouldn't go that far. > OK, I will leave it as is then I think this patch is complete then. > >> /Erik >>> Mike >>> >>> On May 29 2013, at 01:06 , Erik Joelsson wrote: >>> >>>> On 2013-05-29 00:30, Mike Duigou wrote: >>>>> Hello all; >>>>> >>>>> As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. >>>>> >>>>> Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ >>>> When trying to find a program on the path, please use the builtin AC_PATH_PROG or similar macro. Using "which" is bad as it works differently on all platforms and we have worked hard to remove its use in configure. It looks like at that point, JTREGEXE is required to be found, then you can use BASIC_REQUIRE_PROG which also fails with a suitable error message. >>>> >>>> There is no need to repeat AC_SUBST calls and making them conditionals has no effect to my knowledge. I would move them out of the if statements and put them at the end of the block. >>>> >>>> If JT_HOME is set in the environment, it is just accepted and not validated. Should it be? >>>>> If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. >>>>> >>>> If you want to have it undefined, you can achieve it with the following pattern (look at OPENJDK for an example): >>>> In .m4: SET_JT_HOME="JT_HOME=$JT_HOME" >>>> In spec.gmk.in: @SET_JT_HOME@ >>>> >>>> Keeping it undefined when not set would let the makefiles pick it up from the environment, a pattern the new build is trying to break. >>>> >>>> /Erik >>>>> Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. >>>>> >>>>> Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. >>>>> >>>>> Thanks, >>>>> >>>>> Mike From Mike.Duigou at oracle.com Fri May 31 18:28:03 2013 From: Mike.Duigou at oracle.com (Mike Duigou) Date: Fri, 31 May 2013 11:28:03 -0700 Subject: RFR : 8015510 : (s) Improve JTReg location detection and provide location to test/Makefile In-Reply-To: <51A8B05A.3090609@oracle.com> References: <52633801-432F-4E1C-A8A2-27156C7BB83A@oracle.COM> <51A5B6F9.8020404@oracle.com> <42E3F1C6-884D-4820-A010-F2605A25A8BB@oracle.com> <51A85A1D.1040705@oracle.com> <4B4CDC88-85B7-4E38-99A1-27C0A57F8274@oracle.com> <51A8B05A.3090609@oracle.com> Message-ID: On May 31 2013, at 07:14 , Erik Joelsson wrote: > > > On 2013-05-31 15:47, Mike Duigou wrote: >> On May 31 2013, at 01:06 , Erik Joelsson wrote: >> >>> >>> On 2013-05-30 20:05, Mike Duigou wrote: >>>> Thank you for the feedback. I have updated the webrev : >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8015510/1/webrev/ >>>> >>>> It's a lot simpler now. >>> Now my concern is that configure will fail without either specifying --without-jtreg or having it available. I doubt RE has it available on their build machines and it's not a requirement to just build. It would be better if it was optional by default and only required if you specified --with-jtreg. >> It is optional. Not specifying anything is the same as specifying "--without-jtreg". >> >> --without-jtreg disables >> --with-jtreg=no disables >> (nothing) disables >> --with-jtreg=path uses path >> $JT_HOME --with-jtreg uses $JT_HOME location >> (on PATH) --with-jtreg uses PATH location >> > I tried applying your patch and ran just "bash configure" and it failed on missing jtreg, so i think you might have missed something in the logic for the default case. One more try then... http://cr.openjdk.java.net/~mduigou/JDK-8015510/2/webrev/ I added a default for absent in the AC_ARG_WITH Thanks, Mike > /Erik >>>> The one part I couldn't make perfect was the check >>>> >>>> if test ! -f "$JTREGEXE"; then >>>> AC_MSG_ERROR([JTReg executable does not exist: $JTREGEXE]) >>>> fi >>>> >>>> which only checks for whether the executable exists and not whether it is executable. I understand the "-x" text condition can't be used because it doesn't work on windows. Alternatives? >>> You could try executing it with a known parameter that returns 0 and outputs something known (-version or similar), and see that it gives the expected result, but I wouldn't go that far. >> OK, I will leave it as is then I think this patch is complete then. >> >>> /Erik >>>> Mike >>>> >>>> On May 29 2013, at 01:06 , Erik Joelsson wrote: >>>> >>>>> On 2013-05-29 00:30, Mike Duigou wrote: >>>>>> Hello all; >>>>>> >>>>>> As a follow on to JDK-8007129 recently pushed to the jdk8/build repo I've improved the detection logic for finding jtreg. In addition to using the provided path it will also try the location specified by JT_HOME and in the command path. >>>>>> >>>>>> Attention people who just let magic happen and don't pay attention until something breaks: Currently if no location is defined for JT_HOME a default location of $(SLASH_JAVA)/re/jtreg/4.1/promoted/latest/binaries/jtreg is used. SLASH_JAVA is either /java on posix platforms or J:\\ on windows. This default location still works for now, but future changes will almost certainly remove it. You can avoid this pain by adding an appropriate --with-jtreg to your configure command today. >>>>>> >>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8015510/0/webrev/ >>>>> When trying to find a program on the path, please use the builtin AC_PATH_PROG or similar macro. Using "which" is bad as it works differently on all platforms and we have worked hard to remove its use in configure. It looks like at that point, JTREGEXE is required to be found, then you can use BASIC_REQUIRE_PROG which also fails with a suitable error message. >>>>> >>>>> There is no need to repeat AC_SUBST calls and making them conditionals has no effect to my knowledge. I would move them out of the if statements and put them at the end of the block. >>>>> >>>>> If JT_HOME is set in the environment, it is just accepted and not validated. Should it be? >>>>>> If "--without-jtreg", "--with-jtreg=no" or no jtreg directive is used on the command line the spec.gmk vars JT_HOME and JTREGEXE will still present but will be empty. I am not sure if it's better (or possible) to avoid defining them in this case. >>>>>> >>>>> If you want to have it undefined, you can achieve it with the following pattern (look at OPENJDK for an example): >>>>> In .m4: SET_JT_HOME="JT_HOME=$JT_HOME" >>>>> In spec.gmk.in: @SET_JT_HOME@ >>>>> >>>>> Keeping it undefined when not set would let the makefiles pick it up from the environment, a pattern the new build is trying to break. >>>>> >>>>> /Erik >>>>>> Also, since test/Makefile doesn't yet read spec.gmk it is necessary to provide it the JT_HOME location via an environment var in Main.gmk. This will eventually be fixed. >>>>>> >>>>>> Rather than wait for 8007129 to propagate to TL I would like someone to sponsor this change into build repo. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Mike