Re: Review Request 8074432: Move jdeps to jdk.compiler module
On 27/05/2015 07:00, Mandy Chung wrote: We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. Revised webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ The internal classfile API, javap and jdeps in the jdk.jdeps module looks good to me. -Alan.
Re: Review Request 8074432: Move jdeps to jdk.compiler module
Looks good to me.
/Erik
On 2015-05-27 15:40, Mandy Chung wrote:
It’s in my repo but missing from the webrev.
diff --git a/make/launcher/Launcher-jdk.jdeps.gmk
b/make/launcher/Launcher-jdk.jdeps.gmk
new file mode 100644
--- /dev/null
+++ b/make/launcher/Launcher-jdk.jdeps.gmk
@@ -0,0 +1,36 @@
+#
+# Copyright (c) 2015, 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
+# under the terms of the GNU General Public License version 2 only, as
+# published by the Free Software Foundation. Oracle designates this
+# particular file as subject to the "Classpath" exception as provided
+# by Oracle in the LICENSE file that accompanied this code.
+#
+# This code is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+# version 2 for more details (a copy is included in the LICENSE file that
+# accompanied this code).
+#
+# You should have received a copy of the GNU General Public License version
+# 2 along with this work; if not, write to the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+# or visit www.oracle.com if you need additional information or have any
+# questions.
+#
+
+include LauncherCommon.gmk
+
+$(eval $(call SetupLauncher,javap, \
+-DEXPAND_CLASSPATH_WILDCARDS \
+-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \
+-DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.javap.Main"$(COMMA) }'))
+
+$(eval $(call SetupLauncher,jdeps, \
+-DEXPAND_CLASSPATH_WILDCARDS \
+-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \
+-DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.jdeps.Main"$(COMMA) }'))
On May 27, 2015, at 12:48 AM, Erik Joelsson wrote:
Hello Mandy,
I don't see a Launcher-jdk.jdeps.gmk. Should there be one?
/Erik
On 2015-05-27 08:00, Mandy Chung wrote:
We discussed this offline and revised the proposal to group javap and classfile
library together with jdeps in jdk.jdeps module for static analysis tools to
live. The jdk.compiler module will contain the compiler and a couple of small
tools. Moving out javap and classfile library save about 1.2M uncompressed
from jdk.compiler (~11%).
The module is named after the primary tool, jdeps in this case. Tools are in
JAVA_HOME/bin directory of idk image and so which module jdeps and javap are
transparent in the idk image.
Revised webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/
This touches many langtools tests to update @modules but should be easy to
review.
$ du -s -h jdk.jdeps/com/sun/tools/*
816Kjdk.jdeps/com/sun/tools/classfile
468Kjdk.jdeps/com/sun/tools/javap
400Kjdk.jdeps/com/sun/tools/jdeps
$ du -s -h jdk.compiler/
9.1Mjdk.compiler/
Mandy
Re: Review Request 8074432: Move jdeps to jdk.compiler module
It’s in my repo but missing from the webrev.
diff --git a/make/launcher/Launcher-jdk.jdeps.gmk
b/make/launcher/Launcher-jdk.jdeps.gmk
new file mode 100644
--- /dev/null
+++ b/make/launcher/Launcher-jdk.jdeps.gmk
@@ -0,0 +1,36 @@
+#
+# Copyright (c) 2015, 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
+# under the terms of the GNU General Public License version 2 only, as
+# published by the Free Software Foundation. Oracle designates this
+# particular file as subject to the "Classpath" exception as provided
+# by Oracle in the LICENSE file that accompanied this code.
+#
+# This code is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+# version 2 for more details (a copy is included in the LICENSE file that
+# accompanied this code).
+#
+# You should have received a copy of the GNU General Public License version
+# 2 along with this work; if not, write to the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+# or visit www.oracle.com if you need additional information or have any
+# questions.
+#
+
+include LauncherCommon.gmk
+
+$(eval $(call SetupLauncher,javap, \
+-DEXPAND_CLASSPATH_WILDCARDS \
+-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \
+-DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.javap.Main"$(COMMA) }'))
+
+$(eval $(call SetupLauncher,jdeps, \
+-DEXPAND_CLASSPATH_WILDCARDS \
+-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \
+-DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.jdeps.Main"$(COMMA) }'))
> On May 27, 2015, at 12:48 AM, Erik Joelsson wrote:
>
> Hello Mandy,
>
> I don't see a Launcher-jdk.jdeps.gmk. Should there be one?
>
> /Erik
>
> On 2015-05-27 08:00, Mandy Chung wrote:
>> We discussed this offline and revised the proposal to group javap and
>> classfile library together with jdeps in jdk.jdeps module for static
>> analysis tools to live. The jdk.compiler module will contain the compiler
>> and a couple of small tools. Moving out javap and classfile library save
>> about 1.2M uncompressed from jdk.compiler (~11%).
>>
>> The module is named after the primary tool, jdeps in this case. Tools are
>> in JAVA_HOME/bin directory of idk image and so which module jdeps and javap
>> are transparent in the idk image.
>>
>> Revised webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/
>>
>> This touches many langtools tests to update @modules but should be easy to
>> review.
>>
>> $ du -s -h jdk.jdeps/com/sun/tools/*
>> 816K jdk.jdeps/com/sun/tools/classfile
>> 468K jdk.jdeps/com/sun/tools/javap
>> 400K jdk.jdeps/com/sun/tools/jdeps
>> $ du -s -h jdk.compiler/
>> 9.1M jdk.compiler/
>>
>> Mandy
>
Re: RFR: Proposed jimage refresh for JDK9
[Have been OOTO] I have a cunning plan. However, getting this jimage refresh in play has me really bogged down (there is always one more thing -- curse you Jobs.) I do plan on moving the bulk of the jimage JVM_ calls to the JDK. The callbacks into the VM will be reduced to a few calls (open, close, read, read_compressed) and will be VM style correct. Cheers, — Jim > On May 26, 2015, at 2:03 PM, Coleen Phillimore > wrote: > > > > On 5/26/15 10:25 AM, Alan Bateman wrote: >> >> On 26/05/2015 15:18, Coleen Phillimore wrote: >>> : >>> In any case, I don't think the JVM functions are a supported interface so we shouldn't need a CCC. >>> >>> We need CCC to remove the JVM functions so I assume we need one to add them. >> Okay although JVM_* functions have never been a supported interface (to my >> knowledge anyway). >> > These are the current rules, which assume that even though unsupported, these > interfaces are known to our customers and licensees. >> Also I think we need to see where this is going longer term, my preference would be to move these JVM_* functions out of the VM and put the jimage support in its own libjimage.so. I realize this requires mmap and other support that might be tied a bit to VM options but I think we should at least explore it. >>> >>> I think this functionality should be in Java. >> We might be talking different issues here, I assume you need a minimal >> native implementation to startup. > > Yes. It seems wasteful to have the JDK code call back to the JVM for this, > and then we have new JVM functions to support (and have to file CCC requests > if we remove them). > > Thanks, > Coleen > >> >> -Alan >
Re: Review Request 8074432: Move jdeps to jdk.compiler module
Hello Mandy, I don't see a Launcher-jdk.jdeps.gmk. Should there be one? /Erik On 2015-05-27 08:00, Mandy Chung wrote: We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. Revised webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ This touches many langtools tests to update @modules but should be easy to review. $ du -s -h jdk.jdeps/com/sun/tools/* 816Kjdk.jdeps/com/sun/tools/classfile 468Kjdk.jdeps/com/sun/tools/javap 400Kjdk.jdeps/com/sun/tools/jdeps $ du -s -h jdk.compiler/ 9.1Mjdk.compiler/ Mandy
