Thank you, Andrew
I fixed compiledCI_aarch64.cpp and updated webrev in place.
Thanks,
Vladimir
On 10/31/16 8:35 AM, Andrew Dinn wrote:
Hi Vladimir,
On 31/10/16 11:38, Andrew Dinn wrote:
On 28/10/16 16:52, Vladimir Kozlov wrote:
Thank you, Andrew, for verifying that build changes do not
Thank you, Erik
On 10/31/16 3:11 AM, Erik Joelsson wrote:
Hello Vladimir,
The new organization of the checks looks good. Just found one minor nit,
in lib-elf.m4, no need to AC_SUBST(ENABLE_AOT) again.
Removed.
Thanks,
Vladimir
/Erik
On 2016-10-29 04:23, Vladimir Kozlov wrote:
Updated
Hi Vladimir,
On 31/10/16 11:38, Andrew Dinn wrote:
> On 28/10/16 16:52, Vladimir Kozlov wrote:
>> Thank you, Andrew, for verifying that build changes do not break AArch64.
>> But it would be nice if you can also apply Hotspot changes (revert
>> hs.make.webrev changes before that since hs.webrev
Hi Vladimir,
On 28/10/16 16:52, Vladimir Kozlov wrote:
> Thank you, Andrew, for verifying that build changes do not break AArch64.
> But it would be nice if you can also apply Hotspot changes (revert
> hs.make.webrev changes before that since hs.webrev have them):
>
>
Hello Vladimir,
The new organization of the checks looks good. Just found one minor nit,
in lib-elf.m4, no need to AC_SUBST(ENABLE_AOT) again.
/Erik
On 2016-10-29 04:23, Vladimir Kozlov wrote:
Updated build webrevs (webrev.2)
http://cr.openjdk.java.net/~kvn/aot/top.webrev.2/
Updated build webrevs (webrev.2)
http://cr.openjdk.java.net/~kvn/aot/top.webrev.2/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev.2/
Use one ENABLE_AOT variable in all config and make files (removed
NEEDS_LIB_JELFSHIM).
Moved HOTSPOT_SETUP_JVM_FEATURES after LIB_SETUP_LIBRARIES.
First,
> On Oct 28, 2016, at 3:19 PM, Vladimir Kozlov
> wrote:
>
The alternative is to declare `uses` and `provides` in module-info.java in
the source repo
so that a reader can see the module descriptor content without needing to
do a build.
>>> What
The alternative is to declare `uses` and `provides` in module-info.java in the
source repo
so that a reader can see the module descriptor content without needing to do a
build.
What is "a reader”?
A person reading the code.
I don't think it will help "reader" to have 174 lines which are
> On Oct 28, 2016, at 11:23 AM, Mandy Chung wrote:
>
>>
>> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov
>> wrote:
>>
>> Thank you, Mandy
>>
>> On 10/28/16 1:31 PM, Mandy Chung wrote:
>>>
On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov
> On Oct 28, 2016, at 1:52 PM, Vladimir Kozlov
> wrote:
>
> Thank you, Mandy
>
> On 10/28/16 1:31 PM, Mandy Chung wrote:
>>
>>> On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov
>>> wrote:
>>>
>>>
> On Oct 26, 2016, at 5:45 PM, Vladimir Kozlov
> wrote:
>
> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
make/gensrc/Gensrc-jdk.vm.compiler.gmk
This generates module-info.java.extra at build time to augment
module-info.java with `uses` and `provides`.
I got some data. It is about 10% increase size with -g:
product build, no -g for AOT modules
191173 Oct 28 09:15 build/product/images/jmods/jdk.aot.jmod
4893583 Oct 28 09:16 build/product/images/jmods/jdk.vm.compiler.jmod
352073 Oct 28 09:15 build/product/images/jmods/jdk.vm.ci.jmod
Thank you, Andrew, for verifying that build changes do not break AArch64.
But it would be nice if you can also apply Hotspot changes (revert
hs.make.webrev changes before that since hs.webrev have them):
http://cr.openjdk.java.net/~kvn/aot/hs.webrev/
and jaotc sources (which are located in
Volker,
Patch for aot sources is tracked by:
8166415: Integrate AOT tool JAOTC
http://cr.openjdk.java.net/~kvn/aot/jaotc.webrev/
JAOTC code is in Hotspot, not in JDK, repo.
Vladimir
On 10/28/16 2:09 AM, Volker Simonis wrote:
On Fri, Oct 28, 2016 at 10:57 AM, Erik Joelsson
On 28/10/16 08:56, Vladimir Kozlov wrote:
> Webrevs updated in place (please, reload webpage to get new version).
> generated-configure.sh changes are included.
>
> http://cr.openjdk.java.net/~kvn/aot/top.webrev/
> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>
On 2016-10-28 11:09, Volker Simonis wrote:
On Fri, Oct 28, 2016 at 10:57 AM, Erik Joelsson
wrote:
Hello,
On 2016-10-28 09:56, Vladimir Kozlov wrote:
Webrevs updated in place (please, reload webpage to get new version).
generated-configure.sh changes are included.
On Fri, Oct 28, 2016 at 10:57 AM, Erik Joelsson
wrote:
> Hello,
>
>
> On 2016-10-28 09:56, Vladimir Kozlov wrote:
>>
>> Webrevs updated in place (please, reload webpage to get new version).
>> generated-configure.sh changes are included.
>>
>>
Hello,
On 2016-10-28 09:56, Vladimir Kozlov wrote:
Webrevs updated in place (please, reload webpage to get new version).
generated-configure.sh changes are included.
http://cr.openjdk.java.net/~kvn/aot/top.webrev/
http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
On 28/10/2016 09:34, Erik Joelsson wrote:
but maybe jlink is able to strip the debug info from java classes now?
In that case we could consider globally enabling -g for product builds.
Yes, it can, `jlink --strip-debug` (or `-G`). A good test would be to
build with `javac -g` and then strip
On 2016-10-27 20:18, Doug Simon wrote:
On 27 Oct 2016, at 20:12, Vladimir Kozlov wrote:
On 10/27/16 10:55 AM, Christian Thalinger wrote:
On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote:
On 2016-10-27 02:45, Vladimir Kozlov wrote:
Webrevs updated in place (please, reload webpage to get new version).
generated-configure.sh changes are included.
http://cr.openjdk.java.net/~kvn/aot/top.webrev/
http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
libelfshim generation is guarded
Thank you, Erik
On 10/27/16 5:40 AM, Erik Joelsson wrote:
On 2016-10-27 02:45, Vladimir Kozlov wrote:
AOT JEP:
https://bugs.openjdk.java.net/browse/JDK-8166089
Subtask:
https://bugs.openjdk.java.net/browse/JDK-8166416
Webrev:
http://cr.openjdk.java.net/~kvn/aot/top.webrev/
hotspot.m4: 296:
> On Oct 27, 2016, at 8:12 AM, Vladimir Kozlov
> wrote:
>
> On 10/27/16 10:55 AM, Christian Thalinger wrote:
>>
>>> On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote:
>>>
>>>
>>>
>>> On 2016-10-27 02:45, Vladimir Kozlov wrote:
AOT
> On 27 Oct 2016, at 20:12, Vladimir Kozlov wrote:
>
> On 10/27/16 10:55 AM, Christian Thalinger wrote:
>>
>>> On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote:
>>>
>>>
>>>
>>> On 2016-10-27 02:45, Vladimir Kozlov wrote:
AOT JEP:
On 10/27/16 10:55 AM, Christian Thalinger wrote:
On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote:
On 2016-10-27 02:45, Vladimir Kozlov wrote:
AOT JEP:
https://bugs.openjdk.java.net/browse/JDK-8166089
Subtask:
https://bugs.openjdk.java.net/browse/JDK-8166416
Done as you suggested. I will update webrevs later.
One problem left. How to switch off ENABLE_AOT if we can't build libjelfshim.so
(libelf not found or wrong version)?
ENABLE_AOT and JVM_FEATURES_server are defined before LIBJELFSHIM_ENABLED is
defined.
Can I reset ENABLE_AOT (based on
> On Oct 27, 2016, at 2:40 AM, Erik Joelsson wrote:
>
>
>
> On 2016-10-27 02:45, Vladimir Kozlov wrote:
>> AOT JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8166089
>> Subtask:
>> https://bugs.openjdk.java.net/browse/JDK-8166416
>> Webrev:
>>
OK, thanks. I'll do that tomorrow.
For now I did built 'hotspot-only' and sent out a webrev with the
requiredppc/s390 changes for hotspot to the corresponding review
thread. Would be nice if you could integrate them into your patch
right away.
Thanks,
Volker
On Thu, Oct 27, 2016 at 6:24 PM,
Yes, you need to integrate graal-core into hotspot for that.
I just send final RFR which explains what to do:
8166417: Graal-core into JDK for AOT compiler
Regards,
Vladimir
On 10/27/16 8:45 AM, Volker Simonis wrote:
I can't even compile this on Linux/x86_64. I get the following error:
I can't even compile this on Linux/x86_64. I get the following error:
/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:159:
error: module not found: jdk.vm.compiler
jdk.vm.compiler;
^
On Thu, Oct 27, 2016 at 2:22 PM, Volker Simonis
wrote:
> Hi,
>
> currently libelf support is checked on every 64-bit Linux and Solaris
> platform (see lib-elf.m4):
>
> if ((test "x$OPENJDK_TARGET_OS" = "xlinux" \
>|| test "x$OPENJDK_TARGET_OS" = "xsolaris") &&
I see. I specifically removed generated-configure.sh from webrev since it has
to be generated.
I will add version of webrev with it.
Regards,
Vladimir
On 10/27/16 3:14 AM, Volker Simonis wrote:
Hi Vladimir,
I'm trying to build and test these changes on our platforms and I've
just realized
On 2016-10-27 02:45, Vladimir Kozlov wrote:
AOT JEP:
https://bugs.openjdk.java.net/browse/JDK-8166089
Subtask:
https://bugs.openjdk.java.net/browse/JDK-8166416
Webrev:
http://cr.openjdk.java.net/~kvn/aot/top.webrev/
hotspot.m4: 296: Comment is misleading. Should just be removed.
Hi,
currently libelf support is checked on every 64-bit Linux and Solaris
platform (see lib-elf.m4):
if ((test "x$OPENJDK_TARGET_OS" = "xlinux" \
|| test "x$OPENJDK_TARGET_OS" = "xsolaris") && \
(test "x$OPENJDK_TARGET_CPU_BITS" = "x64")); then
LIBJELFSHIM_ENABLED="true"
Hi Vladimir,
I'm trying to build and test these changes on our platforms and I've
just realized that the top-level changes do not contained the
generated-configure.sh script. I for myself have generated it for me,
but I think it would be useful to always include that into a webrev
for convenience
AOT JEP:
https://bugs.openjdk.java.net/browse/JDK-8166089
Subtask:
https://bugs.openjdk.java.net/browse/JDK-8166416
Webrev:
http://cr.openjdk.java.net/~kvn/aot/top.webrev/
http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
Please, review build
36 matches
Mail list logo