Re: Review request: 8055230: Rename attach provider implementation class
On 26/08/2014 05:29, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ This patch renames the class name of attach provider implementation class to be the same for all platforms. This simplifies the build logic and removes the need for generating the service config file at build time. This looks good, nice to see the benefits of the new layout. -Alan.
Re: Review request: 8055230: Rename attach provider implementation class
On 26 Aug 2014, at 08:26, Alan Bateman alan.bate...@oracle.com wrote: On 26/08/2014 05:29, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ This patch renames the class name of attach provider implementation class to be the same for all platforms. This simplifies the build logic and removes the need for generating the service config file at build time. This looks good, nice to see the benefits of the new layout. +1. Wow this is nice, and the knock on simplification in the build logic is a bonus. -Chris. -Alan.
Re: Review request: 8055230: Rename attach provider implementation class
Nice!
/Erik
On 2014-08-26 06:29, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service config file at build time.
The files renamed are
unix/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
unix/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
and also corresponding native files.
Mandy
Re: RFR: JDK-8055922: Work around sjavac limitation with public api tracking cross modules
Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/ Some of the demos failed to compile because the javac_state file did not contain any public api and this caused grep to exit with code 1, which failed the build. I made exit code 1 for this grep line not fail the build. /Erik On 2014-08-25 16:50, Erik Joelsson wrote: Hello, Please review this little workaround for a current shortcoming in Sjavac. See bug for more details. With this change, Sjavac will start acting correctly again and not miss any files that need to be recompiled. The approximation is course however, we should still fix https://bugs.openjdk.java.net/browse/JDK-8054717 to properly only recompile what is really necessary. Still, this workaround does add value compared to running without sjavac. With this change and JDK-8014510 (also on review) I'm starting to feel confident enough to make sjavac default for building jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8055922 Webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.01/ /Erik
Re: RFR: JDK-8055922: Work around sjavac limitation with public api tracking cross modules
On 2014-08-26 11:58, Erik Joelsson wrote: Updated webrev: http://cr.openjdk.java.net/~erikj/8055922/webrev.root.02/ Some of the demos failed to compile because the javac_state file did not contain any public api and this caused grep to exit with code 1, which failed the build. I made exit code 1 for this grep line not fail the build. Looks good to me. /Magnus
Re: Review request: 8055230: Rename attach provider implementation class
Hi Mandy,
I'm seeing some small differences in the various VirtualMachineImpl.java
files, but if I'm not mistaken, all the new AttachProviderImpl.java look
all the same. I wonder if the patch could be further simplified by
moving AttachProviderImpl.java to jdk.attach/share/classes (unless
there's a reason to keep all the different copies)...
best regards,
-- daniel
On 8/26/14 6:29 AM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service config file at build time.
The files renamed are
unix/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
unix/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
and also corresponding native files.
Mandy
RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
Hello, Please review this proposed fix for the Hotspot build. In the new jdk9 build, we utilize the gnu make job server, which automatically makes sure the -j flag gets propagated and shared between all recursive make calls. In the hotspot build, this gets overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number of parallel make jobs into the JOBS variable, which gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in the new build, the hotspot build is happening concurrently with other parts of the build and the consequence is that the hotspot build gets JOBS number of jobs and the rest of the build also gets JOBS number of jobs, all of which are used at the same time. We would like the whole build to share in the same job pool. To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made conditional and we need to add .NOTPARALLEL: to a number of makefiles in hotspot that currently can't handle being executed in parallel. Lastly, the + sign must be added first to recipe lines that call make recursively but are not explicitly using the MAKE variable directly. The result will be that the active -j flag in the root makefiles will just automatically propagate down to the hotspot makefiles. Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ /Erik
Re: Review request: 8055230: Rename attach provider implementation class
There are some differences in the AttachProvideImpl files. Most notably the
windows version is very different. Linux, Bsd and Aix are the same. The Solaris
version has a minor difference in the “public String type()” implementation.
The Linux, Bsd, Aix and Solaris versions could probably be unified.
/Staffan
On 26 aug 2014, at 12:40, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi Mandy,
I'm seeing some small differences in the various VirtualMachineImpl.java
files, but if I'm not mistaken, all the new AttachProviderImpl.java look
all the same. I wonder if the patch could be further simplified by
moving AttachProviderImpl.java to jdk.attach/share/classes (unless
there's a reason to keep all the different copies)...
best regards,
-- daniel
On 8/26/14 6:29 AM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service config file at build time.
The files renamed are
unix/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
unix/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
and also corresponding native files.
Mandy
Re: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20
Hi David, The change was pushed on Friday so it included the change in the Makefile. I filed JDK-8056056 to remove it. Thanks! /Jesper David Holmes skrev 25/8/14 02:50: Sorry I'm late but had a long weekend and was off last Friday. On 22/08/2014 3:04 AM, Jesper Wilhelmsson wrote: Thank you for the quick reply Dan! A new webrev with your suggested change is available here: http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ The change in make/solaris/Makefile isn't necessary. buildtree.make already includes defs.make which defines HS_ALT_MAKE. If this is already pushed please follow up with a correction. But don't push this part of 8u. Thanks, David /Jesper Daniel D. Daugherty skrev 21/8/14 18:42: On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: Hi, On Solaris the HS_ALT_MAKE variable was not passed to vm.make when creating the mapfiles which lead to mapfile-ext not being found and later a linker error due to symbols declared in the extra mapfile not being found. The hotspot makefiles are .. interesting .. yes. The proposed solution is to include defs.make where HS_ALT_MAKE is set up into vm.make on Solaris. Webrev: http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ Unfortunately, including defs.make in make/solaris/makefiles/vm.make isn't the right way to get a top-level variable down into the HotSpot build system. I cannot remember what breaks when you do that, but it doesn't work right in all the ways that we build HotSpot. For the HotSpot build system, you'll want to: - update make/solaris/Makefile and add HS_ALT_MAKE to the BUILDTREE_VARS list: BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) - update make/solaris/makefiles/buildtree.make and add HS_ALT_MAKE to the rule that creates flags.make: [ -n $(HS_ALT_MAKE) ] \ echo echo HS_ALT_MAKE = $(HS_ALT_MAKE); \ The way I usually find all the right spots is I look for where ZIPEXE is added to the above files and follow those examples. Dan Bug: https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 This is a P1 so if you feel comfortable with the hotspot makefiles, please have a look. Thanks! /Jesper
Re: Review request: 8055230: Rename attach provider implementation class
On 8/26/14 12:59 PM, Staffan Larsen wrote:
There are some differences in the AttachProvideImpl files. Most notably the
windows version is very different. Linux, Bsd and Aix are the same. The Solaris
version has a minor difference in the “public String type()” implementation.
The Linux, Bsd, Aix and Solaris versions could probably be unified.
Ah - right - I missed those. Forget my comment then!
Thanks Staffan!
-- daniel
/Staffan
On 26 aug 2014, at 12:40, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi Mandy,
I'm seeing some small differences in the various VirtualMachineImpl.java
files, but if I'm not mistaken, all the new AttachProviderImpl.java look
all the same. I wonder if the patch could be further simplified by
moving AttachProviderImpl.java to jdk.attach/share/classes (unless
there's a reason to keep all the different copies)...
best regards,
-- daniel
On 8/26/14 6:29 AM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service config file at build time.
The files renamed are
unix/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
unix/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
- ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
and also corresponding native files.
Mandy
Re: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
Hi Erik, On 26/08/2014 8:53 PM, Erik Joelsson wrote: Hello, Please review this proposed fix for the Hotspot build. In the new jdk9 build, we utilize the gnu make job server, which automatically makes sure the -j flag gets propagated and shared between all recursive make calls. In the hotspot build, this gets overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number of parallel make jobs into the JOBS variable, which gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in the new build, the hotspot build is happening concurrently with other parts of the build and the consequence is that the hotspot build gets JOBS number of jobs and the rest of the build also gets JOBS number of jobs, all of which are used at the same time. We would like the whole build to share in the same job pool. To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made conditional and we need to add .NOTPARALLEL: to a number of makefiles in hotspot that currently can't handle being executed in parallel. Lastly, the + sign must be added first to recipe lines that call make recursively but are not explicitly using the MAKE variable directly. The result will be that the active -j flag in the root makefiles will just automatically propagate down to the hotspot makefiles. I don't know how make handles -j propagation but from your description it sounds like we will still generate too much concurrency as the submakes will be run with the same -j value as the top-level. ?? I'm also unclear how we used to pass HOTSPOT_BUILD_JOBS and didn't need .NOTPARALLEL, but now we pass -j from the top we do need .NOTPARALLEL ?? Thanks, David Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ /Erik
Re: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
Hello David, I realize my description was not very clear and will try to make a better one. It used to be (before make 3.78), that recursive make calls and the -j flag were tricky to use together. The Hotspot makefiles solved this by asking people not to use -j, and instead set the variable HOTSPOT_BUILD_JOBS. The calls to the leaf make invocations would then set -j$(HOTSPOT_BUILD_JOBS) so that the bulk of the work would be run in parallel, but one makefile at a time. Modern versions of gnu make has a solution to this problem called the Job Server. (Read more about it here: http://mad-scientist.net/make/jobserver.html) In short it enables multiple make processes to share a single pool of job tokens through a pipe, making sure that concurrency is kept within the limitations set by -j to the root process. Note that make never sends the -j flag on to sub invocations, but instead does a secret transfer of the Job Server pipe. In the new jdk9 build, I introduced using the Job Server across the whole build. Unfortunately, this didn't work well for Hotspot because as soon as one sub make gets an explicit -j flag, or is invoked from a recipe line without either a + sign or explicit use of the $(MAKE) variable, that subtree is outside the job server sharing pool and will govern its own concurrency. The result of this is that while the rest of the build is sharing JOBS number of parallel jobs, vm.make will execute HOTSPOT_BUILD_NUMBER number of parallel jobs on its own. The reason .NOTPARALLEL wasn't need before is that until this patch, HotspotWrapper.gmk and the user building Hotspot alone has always run make with -j1. In this patch, I removed that -j1 from HotspotWrapper.gmk so that the Job Server would get propagated into the Hotspot build. To protect the makefiles that aren't able to run in parallel, I had to add .NOTPARALLEL: in a couple of places. /Erik On 2014-08-26 14:09, David Holmes wrote: Hi Erik, On 26/08/2014 8:53 PM, Erik Joelsson wrote: Hello, Please review this proposed fix for the Hotspot build. In the new jdk9 build, we utilize the gnu make job server, which automatically makes sure the -j flag gets propagated and shared between all recursive make calls. In the hotspot build, this gets overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number of parallel make jobs into the JOBS variable, which gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in the new build, the hotspot build is happening concurrently with other parts of the build and the consequence is that the hotspot build gets JOBS number of jobs and the rest of the build also gets JOBS number of jobs, all of which are used at the same time. We would like the whole build to share in the same job pool. To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made conditional and we need to add .NOTPARALLEL: to a number of makefiles in hotspot that currently can't handle being executed in parallel. Lastly, the + sign must be added first to recipe lines that call make recursively but are not explicitly using the MAKE variable directly. The result will be that the active -j flag in the root makefiles will just automatically propagate down to the hotspot makefiles. I don't know how make handles -j propagation but from your description it sounds like we will still generate too much concurrency as the submakes will be run with the same -j value as the top-level. ?? I'm also unclear how we used to pass HOTSPOT_BUILD_JOBS and didn't need .NOTPARALLEL, but now we pass -j from the top we do need .NOTPARALLEL ?? Thanks, David Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ /Erik
RFR: JDK-8056062: Additional minor cleanups from source restructure build changes
Hello, Please review this small patch fixing a couple of issues that have been raised on this list following the source code restructure. * Fix spelling error in make help (build-built) * Readd the jdk target as an alias for exploded-image as people are used to the target and the error message when it's missing is confusing. * Print a warning when clean targets and other targets are mixed on the command line as this won't work well. Also add a note about this in the help target. Bug: https://bugs.openjdk.java.net/browse/JDK-8056062 Webrev: http://cr.openjdk.java.net/~erikj/8056062/webrev.root.01/ /Erik
RFR: JDK-8056064: Fix corba locale build problem on windows
Thanks for pointing this out. That is indeed a better and more portable solution. I took the liberty of creating a new bug and creating a patch reverting my earlier change and using this instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8056064 Webrev: http://cr.openjdk.java.net/~erikj/8056064/webrev.01/ /Erik On 2014-08-23 17:32, Ludovic HOCHET wrote: Hello Erik, This does not fix the issue for me on a Win 8.1 fr_FR. I still have creation dates in French. eg.: Compiling 1478 files for java.corba c:\dev\dev\build\windows-x86_64-normal-server-release\corba\gensrc\java.corba\com\sun\corba\se\spi\activation\Activator.java:8: error: unmappable character for encoding ascii * samedi 23 ao?t 2014 16 h 50 CEST Forcing the en locale on the Java run of IDLJ fixes the issue for me: diff -r 4d704afddadd make/GensrcCorba.gmk --- a/make/GensrcCorba.gmkMon Aug 18 10:07:13 2014 +0100 +++ b/make/GensrcCorba.gmkSat Aug 23 15:41:15 2014 +0100 @@ -51,7 +51,7 @@ EXCLUDE_FILES := ResourceBundleUtil.java)) TOOL_IDLJ_CMD := $(JAVA) -cp $(CORBA_OUTPUTDIR)/idlj_classes \ -com.sun.tools.corba.se.idl.toJavaPortable.Compile +-Duser.language=en com.sun.tools.corba.se.idl.toJavaPortable.Compile Rgds, On Wed, Aug 20, 2014 at 10:55 AM, Erik Joelsson erik.joels...@oracle.com wrote: Hello, Please review this minor patch which makes the build work on a ja_JP locale. Bug: https://bugs.openjdk.java.net/browse/JDK-8055405 diff -r c72d6edec4cf make/common/IdlCompilation.gmk --- a/make/common/IdlCompilation.gmk +++ b/make/common/IdlCompilation.gmk @@ -60,7 +60,7 @@ $(RM) -rf $3/$$($4_TMPDIR) $(MKDIR) -p $(dir $5) $(ECHO) $(LOG_INFO) Compiling IDL $(patsubst $2/%,%,$4) -$8 -td $3/$$($4_TMPDIR) \ +LC_ALL=C $8 -td $3/$$($4_TMPDIR) \ -i $2/org/omg/CORBA \ -i $2/org/omg/PortableInterceptor \ -i $2/org/omg/PortableServer \ /Erik
Re: RFR: JDK-8056062: Additional minor cleanups from source restructure build changes
On 26/08/2014 13:46, Erik Joelsson wrote: Hello, Please review this small patch fixing a couple of issues that have been raised on this list following the source code restructure. * Fix spelling error in make help (build-built) * Readd the jdk target as an alias for exploded-image as people are used to the target and the error message when it's missing is confusing. * Print a warning when clean targets and other targets are mixed on the command line as this won't work well. Also add a note about this in the help target. Bug: https://bugs.openjdk.java.net/browse/JDK-8056062 Webrev: http://cr.openjdk.java.net/~erikj/8056062/webrev.root.01/ This looks okay to me, I'm just wondering whether an attempt to mix clean with other targets should be an error rather than a warning. -Alan.
Re: RFR: JDK-8056064: Fix corba locale build problem on windows
On 26/08/2014 14:02, Erik Joelsson wrote: Thanks for pointing this out. That is indeed a better and more portable solution. I took the liberty of creating a new bug and creating a patch reverting my earlier change and using this instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8056064 Webrev: http://cr.openjdk.java.net/~erikj/8056064/webrev.01/ This looks okay to me, I just wonder if there are any other cases where we might also need to set user.language. -Alan.
Re: RFR: JDK-8056062: Additional minor cleanups from source restructure build changes
Erik: Please review this small patch fixing a couple of issues that have been raised on this list following the source code restructure. * Fix spelling error in make help (build-built) * Readd the jdk target as an alias for exploded-image as people are used to the target and the error message when it's missing is confusing. * Print a warning when clean targets and other targets are mixed on the command line as this won't work well. Also add a note about this in the help target. Bug: https://bugs.openjdk.java.net/browse/JDK-8056062 Webrev: http://cr.openjdk.java.net/~erikj/8056062/webrev.root.01 Looks good to me. Approved. Tim
Re: RFR: JDK-8056064: Fix corba locale build problem on windows
Hi Erik On 08/26/14 07:30, Alan Bateman wrote: On 26/08/2014 14:02, Erik Joelsson wrote: Thanks for pointing this out. That is indeed a better and more portable solution. I took the liberty of creating a new bug and creating a patch reverting my earlier change and using this instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8056064 Webrev: http://cr.openjdk.java.net/~erikj/8056064/webrev.01/ This looks okay to me, I just wonder if there are any other cases where we might also need to set user.language. -Alan. Looks good to me as well. Tim
How to influence File Permission Mode
Hi I am seeing some files with permission 0600 (-rw --- --- ) in my build. Is there a way to influence the generated files' permission from the configure or do I need to run a chmod(1) on them myself. Note that I have selected owner=root , group=root, so the net effect is that those files with 0600 only works for root. I need it to be readable by all. Unless there is some specific reason why these JARs are 0600. mmontaseri@griffin:~/work/bug-91383/depot9 ls -1 bin/ jvm/ openjdk-1.8.0-jdk-20140822.debian.tgz openjdk-1.8.0-jre-20140822.debian.tgz mmontaseri@griffin:~/work/bug-91383/depot9 bin/javac -version javac 1.8.0-20140822 mmontaseri@griffin:~/work/bug-91383/depot9/jvm/openjdk-1.8.0-20140822 find . -perm 600 ./demo/scripting/jconsole-plugin/jconsole-plugin.jar ./demo/jfc/Metalworks/Metalworks.jar ./demo/jfc/FileChooserDemo/FileChooserDemo.jar ./demo/jfc/SwingApplet/SwingApplet.jar ./demo/jfc/Notepad/Notepad.jar ./demo/jfc/TransparentRuler/TransparentRuler.jar ./demo/jfc/TableExample/TableExample.jar ./demo/jfc/SampleTree/SampleTree.jar ./demo/jfc/Font2DTest/Font2DTest.jar ./demo/jfc/CodePointIM/CodePointIM.jar ./demo/jpda/examples.jar ./demo/management/MemoryMonitor/MemoryMonitor.jar ./demo/management/FullThreadDump/FullThreadDump.jar ./demo/management/VerboseGC/VerboseGC.jar ./demo/management/JTop/JTop.jar ./demo/nio/zipfs/zipfs.jar ./demo/applets/WireFrame/WireFrame.jar ./demo/applets/MoleculeViewer/MoleculeViewer.jar ./demo/jvmti/mtrace/mtrace.jar ./demo/jvmti/heapTracker/heapTracker.jar ./demo/jvmti/minst/minst.jar ./lib/ct.sym ./lib/tools.jar ./lib/sa-jdi.jar ./lib/jconsole.jar ./lib/dt.jar ./jre/lib/jsse.jar ./jre/lib/ext/sunjce_provider.jar ./jre/lib/ext/dnsns.jar ./jre/lib/ext/zipfs.jar ./jre/lib/ext/nashorn.jar ./jre/lib/ext/sunec.jar ./jre/lib/ext/sunpkcs11.jar ./jre/lib/ext/cldrdata.jar ./jre/lib/ext/localedata.jar ./jre/lib/security/US_export_policy.jar ./jre/lib/security/local_policy.jar ./jre/lib/jce.jar ./jre/lib/charsets.jar mmontaseri@griffin:~/work/bug-91383/depot9/jvm/openjdk-1.8.0-20140822/jre/lib find . -perm 600 -ls 67241378 608 -rw--- 1 mmontaseri software 617946 Aug 22 11:38 ./jsse.jar 67297842 260 -rw--- 1 mmontaseri software 259148 Aug 22 11:38 ./ext/sunjce_provider.jar 67297843 12 -rw--- 1 mmontaseri software 8286 Aug 22 11:38 ./ext/dnsns.jar 67297844 72 -rw--- 1 mmontaseri software68844 Aug 22 11:38 ./ext/zipfs.jar 67297845 1560 -rw--- 1 mmontaseri software 1589693 Aug 22 11:38 ./ext/nashorn.jar 67297846 36 -rw--- 1 mmontaseri software35899 Aug 22 11:38 ./ext/sunec.jar 67297848 236 -rw--- 1 mmontaseri software 235457 Aug 22 11:38 ./ext/sunpkcs11.jar 67297849 3776 -rw--- 1 mmontaseri software 3860522 Aug 22 11:38 ./ext/cldrdata.jar 67297850 1156 -rw--- 1 mmontaseri software 1178765 Aug 22 11:38 ./ext/localedata.jar 673464434 -rw--- 1 mmontaseri software 620 Aug 22 11:38 ./security/US_export_policy.jar 673464444 -rw--- 1 mmontaseri software 1040 Aug 22 11:38 ./security/local_policy.jar 67241387 96 -rw--- 1 mmontaseri software93130 Aug 22 11:38 ./jce.jar 67241393 3064 -rw--- 1 mmontaseri software 3131343 Aug 22 11:38 ./charsets.jar Here is another way of showing thislets say I have my JRE packaged up in a tar file tar -zvtf openjdk-1.8.0-jre-20140822.debian.tgz | grep '^-rw---' -rw--- root/root617946 2014-08-22 11:38 ./lib/jsse.jar -rw--- root/root259148 2014-08-22 11:38 ./lib/ext/sunjce_provider.jar -rw--- root/root 8286 2014-08-22 11:38 ./lib/ext/dnsns.jar -rw--- root/root 68844 2014-08-22 11:38 ./lib/ext/zipfs.jar -rw--- root/root 1589693 2014-08-22 11:38 ./lib/ext/nashorn.jar -rw--- root/root 35899 2014-08-22 11:38 ./lib/ext/sunec.jar -rw--- root/root235457 2014-08-22 11:38 ./lib/ext/sunpkcs11.jar -rw--- root/root 3860522 2014-08-22 11:38 ./lib/ext/cldrdata.jar -rw--- root/root 1178765 2014-08-22 11:38 ./lib/ext/localedata.jar -rw--- root/root 620 2014-08-22 11:38 ./lib/security/US_export_policy.jar -rw--- root/root 1040 2014-08-22 11:38 ./lib/security/local_policy.jar -rw--- root/root 93130 2014-08-22 11:38 ./lib/jce.jar -rw--- root/root 3131343 2014-08-22 11:38 ./lib/charsets.jar
Re: RFR 8054717: SJavac should track changes in the public apis of classpath classes!
It seems like the development speed for sjavac needs to be increased significantly, one JIRA bug, one 2 week review cycle, leads to one commit is much too slow. I belive it would be good to have a separate repository to do quicker development of sjavac, and test out all sorts of interesting stuff, after which a larger more polished review can be published here. I have now created such a high speed development repository and published my changes that I made over two late night hacks: https://bitbucket.org/jabberbeak/sjavac I believe that now when the OpenJDK sources are modularized, we should move sjavac to its own module perhaps jdk.sjavac. I also published a blog post on the contents of the high speed development repository, called The Smart Javac Wrapper JDK8 Backport with Extras and it can be found here: http://fredrikohrstrom.blogspot.se/ On Fri, Aug 22, 2014 at 8:42 PM, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: I think the path to a thin Java client is relatively quick and easy. Once you have located the server, you just have to change the protocol to send argv over the connection and accept stream output coming back. The bulk of the code that currently lives in the fat client can equally well exist and be executed in the server. The bug that Eric described in his message of 08/21/2014 01:42 AM sounds as much like a bug in the build as in sjavac. If a file in a module is modified, in the worst case, all dependent modules should be recompiled. Yes, that is suboptimal, but at least it would give correct class files. sjavac may provide the means to reduce the set of modules that need to be recompiled, but the build should be capable of behaving reasonably even without sjavac. -- Jon On 08/22/2014 08:02 AM, Fredrik Öhrström wrote: The path to a super thin client is quite long with a lot of interesting technical problems (I suppose that is why the royal we has not authorized RFR:8044131 since that does not reach the thin client in one go, but is a mere first step) however classpath dependency tracking is needed now. 2014-08-22 0:05 GMT+02:00 Jonathan Gibbons jonathan.gibb...@oracle.com: Fredrik, Can you please explain the following some more: It is important that this public api scanning does not require a javac server started though. This is /not/ the direction we want to take sjavac. We want to change sjavac from its current client/server split to a (very) thin client, with most of the work happening in the server. In some version of an ideal world, the client would be so simple it could be written in C and not invoke a JVM at all. The client should just locate the server (starting it if necessary) and then dispatch its command line args to be processed in the server. Doing more and more work in a cold unshared JVM to avoid doing work in a hot shared JVM seems like a bad way to go. -- Jon On 08/21/2014 01:42 AM, Erik Joelsson wrote: I can't comment on the code quality of this patch, but I do think this feature is important. I can't recommend people to try sjavac with a straight face at the moment as it will no longer guarantee a correct incremental build. The current behavior when I add a public field to java/lang/Object is that all of java.base is recompiled, then the rest of the modules are sent to sjavac (as make thinks they need to be recompiled) and sjavac does nothing with them. /Erik On 2014-08-09 00:22, Fredrik Öhrström wrote: Here is very useful feature addition to sjavac, in fact it is required for a modularized OpenJDK build (Jigsawified), where not all sources are sent to sjavac at the same time. sjavac should track the public apis of the classes in the classpath, that the previous compile has linked to. If the public api of the linked to classes has changed, then this should trigger a recompile of the appropriate sources. This is a very useful feature. Currently sjavac must be fed all sources that belong to the product in a single huge compile. The OpenJDK is already at the limit of what fits in a reasonable (of today) sized Java heap. Other products are significantly larger and therefore cannot make use of the incremental compile in sjavac. With this feature, it is possible to compile the product as separate jar files, as long as the build dependencies for the jar files are a directed acyclic graph, then each succesive compile will detect if there were any changes in the public apis of the dependency jar files. If the public apis of the dependencies were not changed, and there were no other source changes for that jar, it will not be recompiled! But if there were changes in the public apis of the dependencies, then only the appropriate parts of the jar will be recompiled! This is the first draft of this large patch. In particular the new file Compile.java is a misnamer, it does NOT compile, it is used to extract the public apis of the classes on the classpath. Somehowe
