subject:"Re\: \[9\] RFR$M$ 8166416\: \[AOT\] Integrate JDK build changes and launcher 'jaotc' for AOT compiler"

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, check for linux-x64 presence of jdk.aot and jdk.vm.compiler directories. Set ENABLE_AOT=true if all are present. Throw config errors if --enable-aot is specified but sources are missing or on
different platforms.

Second, in lib-elf.m4, when ENABLE_AOT==true check if libelf.h is present and
usable.
Throw config errors if --enable-aot is specified but libelf.h is missing.
Otherwise warnings and set ENABLE_AOT==false.

Third, check ENABLE_AOT in HOTSPOT_SETUP_JVM_FEATURES to set JVM_FEATURES.

Thanks,
Vladimir

On 10/28/16 3:27 AM, Erik Joelsson wrote:

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.

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 by ENABLE_AOT as Volker suggested.

I did not figure out how switch off ENABLE_AOT if libelf not found. So I
changed warning to configuration error:

error: libelf not found, cannot build AOT. Disable AOT build:
--enable-aot=no. You might be able to fix this by running 'sudo yum install
elfutils-libelf-devel'.

Which is not correct since AOT build is enabled by default on linux-x64.
Need help with this.

I think it should be fine moving HOTSPOT_SETUP_JVM_FEATURES to after
LIB_SETUP_LIBRARIES in configure.ac. (Note that many of these calls are just
ordered as they happened to be, though some really need to be before or
after others. I cannot find a reason for these two.) Then you can
enable/disable AOT after looking for libelf. It depends on what kind of
behavior you want.

If libelf isn't commonly installed, then having configure use it, and enable
AOT if it is, and semi silently just disabling AOT if it's not is fine. We
can define our Oracle builds to explicitly set --enable-aot to get an early
fail on a missing dependency. That's inline with current configure behavior
so I like that.

I'm fine with that. But then we shouldn't warn if we don't find
libelf. We should only warn, if '--enable-aot' was explicitly
requested by the user and if this request can't be fulfilled because
of the missing libelf dependency.

--enable-aot and not finding libelf should result in an error. If on linux-x64
where aot is default enabled, there should be a warning that it was disabled
because libelf is missing. This warning
would now need to be in the ENABLE_AOT logic.

/Erik

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Mandy Chung


> 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 is "a reader”?
>> 
>> A person reading the code.
> 
> I don't think it will help "reader" to have 174 lines which are hard to read 
> in module-info.java:
> 
> provides com.oracle.graal.nodes.graphbuilderconf.NodeIntrinsicPluginFactory 
> with com.oracle.graal.hotspot.nodes.PluginFactory_AcquiredCASLockNode;
> 
> I would agree if it was only 20-30 dependencies but not so many.

Can you send module-info.java.extra and module-info.java generated in your 
build?

Mandy

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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 hard to read in 
module-info.java:

provides com.oracle.graal.nodes.graphbuilderconf.NodeIntrinsicPluginFactory 
with com.oracle.graal.hotspot.nodes.PluginFactory_AcquiredCASLockNode;

I would agree if it was only 20-30 dependencies but not so many.

Regards,
Vladimir

On 10/28/16 2:23 PM, 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  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`.  module-info.java.extra is 
expected to be checked in the source.

   Do you expect the list of `uses` and `provides` are often changed?


Yes, Graal code changes frequently and  we need to run annotation processor to 
generate these dependencies for each jdk.vm.compiler (Graal) module build.



When the OptionDescriptors list is changed, we can run the tool (you can add a 
make target if it helps) to generate the list of `uses` and `provides`.  Then 
update module-info.java in the source together with the changes.  That would 
work too, right?


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.  A test to detect if the module-info.java is out-of-sync 
with the annotated options.  In addition a make target to generate the list of 
`use` and `provides` can be used to generate module-info.java to be included in 
any change in the annotated options list.


What is "a reader”?


A person reading the code.


And how to check "out-of-sync" without running 'processor’?


I meant a regression test that will run the annotation processor and compare 
with module-info.class in the image (using java.lang.module.ModuleDescriptor 
API)

Mandy


Sorry, I am not familiar with all this modules build process.

Thanks,
Vladimir



Mandy

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Christian Thalinger


> 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  
 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`. module-info.java.extra is 
>>> expected to be checked in the source.
>>> 
>>>  Do you expect the list of `uses` and `provides` are often changed?
>> 
>> Yes, Graal code changes frequently and  we need to run annotation processor 
>> to generate these dependencies for each jdk.vm.compiler (Graal) module build.
>> 
> 
> When the OptionDescriptors list is changed, we can run the tool (you can add 
> a make target if it helps) to generate the list of `uses` and `provides`.  
> Then update module-info.java in the source together with the changes.  That 
> would work too, right?

Why can’t we have it generated?  It’s much more convenient and less maintenance 
overhead.  There needs to be a good reason to give this up.

> 
>>> 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.  A test to detect if the module-info.java is 
>>> out-of-sync with the annotated options.  In addition a make target to 
>>> generate the list of `use` and `provides` can be used to generate 
>>> module-info.java to be included in any change in the annotated options list.
>> 
>> What is "a reader”?
> 
> A person reading the code.
> 
>> And how to check "out-of-sync" without running 'processor’?
> 
> I meant a regression test that will run the annotation processor and compare 
> with module-info.class in the image (using java.lang.module.ModuleDescriptor 
> API)
> 
> Mandy
> 
>> Sorry, I am not familiar with all this modules build process.
>> 
>> Thanks,
>> Vladimir
>> 
>>> 
>>> Mandy

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Mandy Chung


> 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:
>>> 
>>> 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`.  module-info.java.extra is 
>> expected to be checked in the source.
>> 
>>   Do you expect the list of `uses` and `provides` are often changed?
> 
> Yes, Graal code changes frequently and  we need to run annotation processor 
> to generate these dependencies for each jdk.vm.compiler (Graal) module build.
> 

When the OptionDescriptors list is changed, we can run the tool (you can add a 
make target if it helps) to generate the list of `uses` and `provides`.  Then 
update module-info.java in the source together with the changes.  That would 
work too, right?

>> 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.  A test to detect if the module-info.java is 
>> out-of-sync with the annotated options.  In addition a make target to 
>> generate the list of `use` and `provides` can be used to generate 
>> module-info.java to be included in any change in the annotated options list.
> 
> What is "a reader”?

A person reading the code.

> And how to check "out-of-sync" without running 'processor’?

I meant a regression test that will run the annotation processor and compare 
with module-info.class in the image (using java.lang.module.ModuleDescriptor 
API)

Mandy

> Sorry, I am not familiar with all this modules build process.
> 
> Thanks,
> Vladimir
> 
>> 
>> Mandy
>>

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Mandy Chung

> 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`.  module-info.java.extra is 
expected to be checked in the source.

  Do you expect the list of `uses` and `provides` are often changed? 

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.  A test to detect if the module-info.java is out-of-sync 
with the annotated options.  In addition a make target to generate the list of 
`use` and `provides` can be used to generate module-info.java to be included in 
any change in the annotated options list.

Mandy

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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

product build, AOT modules with -g
  208913 Oct 28 09:31 build/product/images/jmods/jdk.aot.jmod
 5465020 Oct 28 09:32 build/product/images/jmods/jdk.vm.compiler.jmod
  387958 Oct 28 09:32 build/product/images/jmods/jdk.vm.ci.jmod

Vladimir

On 10/28/16 1:43 AM, Alan Bateman wrote:

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 the debug information when generating the JRE 
image to see that it comes out at around the
same size as the current build.

-Alan.

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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 Hotspot repo):

http://cr.openjdk.java.net/~kvn/aot/jaotc.webrev/

Thanks,
Vladimir

On 10/28/16 4:04 AM, Andrew Dinn wrote:

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/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/


I have applied these 3 change sets to the latest hs on AArch64 and it
build and runs ok (perhaps not much of a surprise).

However, I'm not sure exactly what this proves -- or, rather, whether
that is all that you want proved in order to proceed with 8166416.

1) Do I need to use any specific configure options to exercise these
specific changes satisfactorily on AArch64?

2) Do I need to include any further changes in order to test more fully?

regards,


Andrew Dinn
---

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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
 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.

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 by ENABLE_AOT as Volker suggested.

I did not figure out how switch off ENABLE_AOT if libelf not found. So I
changed warning to configuration error:

error: libelf not found, cannot build AOT. Disable AOT build:
--enable-aot=no. You might be able to fix this by running 'sudo yum install
elfutils-libelf-devel'.

Which is not correct since AOT build is enabled by default on linux-x64.
Need help with this.


I think it should be fine moving HOTSPOT_SETUP_JVM_FEATURES to after
LIB_SETUP_LIBRARIES in configure.ac. (Note that many of these calls are just
ordered as they happened to be, though some really need to be before or
after others. I cannot find a reason for these two.) Then you can
enable/disable AOT after looking for libelf. It depends on what kind of
behavior you want.

If libelf isn't commonly installed, then having configure use it, and enable
AOT if it is, and semi silently just disabling AOT if it's not is fine. We
can define our Oracle builds to explicitly set --enable-aot to get an early
fail on a missing dependency. That's inline with current configure behavior
so I like that.


I'm fine with that. But then we shouldn't warn if we don't find
libelf. We should only warn, if '--enable-aot' was explicitly
requested by the user and if this request can't be fulfilled because
of the missing libelf dependency.

I also noticed that currently the configuration for AOT bails out
early, because it can not find the "aot src":

+  AC_MSG_CHECKING([if aot src is present])
+  if test -d "$HOTSPOT_TOPDIR/src/jdk.aot"; then
+AC_MSG_RESULT([yes])

But I couldn't find the patch which provides
"$HOTSPOT_TOPDIR/src/jdk.aot". Should this read
"$HOTSPOT_TOPDIR/src/jdk.vm.compiler" which is the location where the
graal sources will be copied to (see RFR for "8166417: Graal-core into
JDK for AOT compiler")? Or is there yet another patch to come which
will provide "$HOTSPOT_TOPDIR/src/jdk.aot"?



Another note. We usually use the style --disable- rather than
--enable-=no when referring to configure options.

/Erik


AOT modules dependencies moved to new module-info.java.extra.

And other changes suggested by Erik.

Thanks,
Vladimir

On 10/27/16 11:41 AM, Vladimir Kozlov wrote:


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: Comment is misleading. Should just be removed.



Removed.


CompileJavaModules.gmk: Use of -g flag for java compilation is
controlled globally. Please remove.



See Chris comment on this. We want to have JAOTC java debug information
for debugging in product builds.


Main.gmk: buildtools-hotspot should be declared inside the
CREATING_BUILDJDK conditional like all other buildtools targets.



Done.




http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/


The extra exports from java.base needs to go in a new
jdk/src/java.base/share/classes/module-info.java.extra since the module
jdk.vm.compiler is optional.



Done.


http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/


Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB)
to LIBS since that will provide -lc on Solaris automatically.



Like this?:

LDFLAGS := $(LDFLAGS_JDKLIB), \
LIBS := $(ELF_LIBS) $(LIBS_JDKLIB), \


No need to set DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be
correct and controlled globally.



Done.

Thanks,
Vladimir



/Erik



Please, review build changes for AOT.  Only Linux/x64 platform is
supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build
jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native
part of 'jaotc'. It is used to generated AOT shared libraries (.so) as
result of AOT compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT
changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Andrew Dinn

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/
> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

I have applied these 3 change sets to the latest hs on AArch64 and it
build and runs ok (perhaps not much of a surprise).

However, I'm not sure exactly what this proves -- or, rather, whether
that is all that you want proved in order to proceed with 8166416.

1) Do I need to use any specific configure options to exercise these
specific changes satisfactorily on AArch64?

2) Do I need to include any further changes in order to test more fully?

regards,

Andrew Dinn
---

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Erik Joelsson




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.

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 by ENABLE_AOT as Volker suggested.

I did not figure out how switch off ENABLE_AOT if libelf not found. So I
changed warning to configuration error:

error: libelf not found, cannot build AOT. Disable AOT build:
--enable-aot=no. You might be able to fix this by running 'sudo yum install
elfutils-libelf-devel'.

Which is not correct since AOT build is enabled by default on linux-x64.
Need help with this.


I think it should be fine moving HOTSPOT_SETUP_JVM_FEATURES to after
LIB_SETUP_LIBRARIES in configure.ac. (Note that many of these calls are just
ordered as they happened to be, though some really need to be before or
after others. I cannot find a reason for these two.) Then you can
enable/disable AOT after looking for libelf. It depends on what kind of
behavior you want.

If libelf isn't commonly installed, then having configure use it, and enable
AOT if it is, and semi silently just disabling AOT if it's not is fine. We
can define our Oracle builds to explicitly set --enable-aot to get an early
fail on a missing dependency. That's inline with current configure behavior
so I like that.

I'm fine with that. But then we shouldn't warn if we don't find
libelf. We should only warn, if '--enable-aot' was explicitly
requested by the user and if this request can't be fulfilled because
of the missing libelf dependency.
--enable-aot and not finding libelf should result in an error. If on 
linux-x64 where aot is default enabled, there should be a warning that 
it was disabled because libelf is missing. This warning would now need 
to be in the ENABLE_AOT logic.


/Erik

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Volker Simonis

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.
>>
>> 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 by ENABLE_AOT as Volker suggested.
>>
>> I did not figure out how switch off ENABLE_AOT if libelf not found. So I
>> changed warning to configuration error:
>>
>> error: libelf not found, cannot build AOT. Disable AOT build:
>> --enable-aot=no. You might be able to fix this by running 'sudo yum install
>> elfutils-libelf-devel'.
>>
>> Which is not correct since AOT build is enabled by default on linux-x64.
>> Need help with this.
>>
> I think it should be fine moving HOTSPOT_SETUP_JVM_FEATURES to after
> LIB_SETUP_LIBRARIES in configure.ac. (Note that many of these calls are just
> ordered as they happened to be, though some really need to be before or
> after others. I cannot find a reason for these two.) Then you can
> enable/disable AOT after looking for libelf. It depends on what kind of
> behavior you want.
>
> If libelf isn't commonly installed, then having configure use it, and enable
> AOT if it is, and semi silently just disabling AOT if it's not is fine. We
> can define our Oracle builds to explicitly set --enable-aot to get an early
> fail on a missing dependency. That's inline with current configure behavior
> so I like that.

I'm fine with that. But then we shouldn't warn if we don't find
libelf. We should only warn, if '--enable-aot' was explicitly
requested by the user and if this request can't be fulfilled because
of the missing libelf dependency.

I also noticed that currently the configuration for AOT bails out
early, because it can not find the "aot src":

+  AC_MSG_CHECKING([if aot src is present])
+  if test -d "$HOTSPOT_TOPDIR/src/jdk.aot"; then
+AC_MSG_RESULT([yes])

But I couldn't find the patch which provides
"$HOTSPOT_TOPDIR/src/jdk.aot". Should this read
"$HOTSPOT_TOPDIR/src/jdk.vm.compiler" which is the location where the
graal sources will be copied to (see RFR for "8166417: Graal-core into
JDK for AOT compiler")? Or is there yet another patch to come which
will provide "$HOTSPOT_TOPDIR/src/jdk.aot"?

>
> Another note. We usually use the style --disable- rather than
> --enable-=no when referring to configure options.
>
> /Erik
>
>> AOT modules dependencies moved to new module-info.java.extra.
>>
>> And other changes suggested by Erik.
>>
>> Thanks,
>> Vladimir
>>
>> On 10/27/16 11:41 AM, Vladimir Kozlov wrote:
>>>
>>> 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: Comment is misleading. Should just be removed.
>>>
>>>
>>> Removed.
>>>
 CompileJavaModules.gmk: Use of -g flag for java compilation is
 controlled globally. Please remove.
>>>
>>>
>>> See Chris comment on this. We want to have JAOTC java debug information
>>> for debugging in product builds.
>>>
 Main.gmk: buildtools-hotspot should be declared inside the
 CREATING_BUILDJDK conditional like all other buildtools targets.
>>>
>>>
>>> Done.
>>>

> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/

 The extra exports from java.base needs to go in a new
 jdk/src/java.base/share/classes/module-info.java.extra since the module
 jdk.vm.compiler is optional.
>>>
>>>
>>> Done.
>>>
> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

 Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB)
 to LIBS since that will provide -lc on Solaris automatically.
>>>
>>>
>>> Like this?:
>>>
>>>LDFLAGS := $(LDFLAGS_JDKLIB), \
>>>LIBS := $(ELF_LIBS) $(LIBS_JDKLIB), \
>>>
 No need to set DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be
 correct and controlled globally.
>>>
>>>
>>> Done.
>>>
>>> Thanks,
>>> Vladimir
>>>

 /Erik
>
>
> Please, review build changes for AOT.  Only Linux/x64 platform is
> supported. 'jaotc' and AOT part of Hotspot will be build only on 
> Linux/x64.
>
> Changes include new 'jaotc' launcher, makefile changes to build
> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
> hotspot/src/jdk.vm.compiler.
> 'jaotc' requires installed libelf package on a system to build native
> part of 'jaotc'. It is used to generated AOT shared libraries (.so) as
> result of AOT compilation.
>
> Hotspot makefile changes will

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Erik Joelsson


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/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

libelfshim generation is guarded by ENABLE_AOT as Volker suggested.

I did not figure out how switch off ENABLE_AOT if libelf not found. So 
I changed warning to configuration error:


error: libelf not found, cannot build AOT. Disable AOT build: 
--enable-aot=no. You might be able to fix this by running 'sudo yum 
install elfutils-libelf-devel'.


Which is not correct since AOT build is enabled by default on 
linux-x64. Need help with this.


I think it should be fine moving HOTSPOT_SETUP_JVM_FEATURES to after 
LIB_SETUP_LIBRARIES in configure.ac. (Note that many of these calls are 
just ordered as they happened to be, though some really need to be 
before or after others. I cannot find a reason for these two.) Then you 
can enable/disable AOT after looking for libelf. It depends on what kind 
of behavior you want.


If libelf isn't commonly installed, then having configure use it, and 
enable AOT if it is, and semi silently just disabling AOT if it's not is 
fine. We can define our Oracle builds to explicitly set --enable-aot to 
get an early fail on a missing dependency. That's inline with current 
configure behavior so I like that.


Another note. We usually use the style --disable- rather than 
--enable-=no when referring to configure options.


/Erik

AOT modules dependencies moved to new module-info.java.extra.

And other changes suggested by Erik.

Thanks,
Vladimir

On 10/27/16 11:41 AM, Vladimir Kozlov wrote:

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: Comment is misleading. Should just be removed.


Removed.

CompileJavaModules.gmk: Use of -g flag for java compilation is 
controlled globally. Please remove.


See Chris comment on this. We want to have JAOTC java debug 
information for debugging in product builds.


Main.gmk: buildtools-hotspot should be declared inside the 
CREATING_BUILDJDK conditional like all other buildtools targets.


Done.




http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
The extra exports from java.base needs to go in a new 
jdk/src/java.base/share/classes/module-info.java.extra since the 
module jdk.vm.compiler is optional.


Done.


http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add 
$(LIBS_JDKLIB) to LIBS since that will provide -lc on Solaris 
automatically.


Like this?:

   LDFLAGS := $(LDFLAGS_JDKLIB), \
   LIBS := $(ELF_LIBS) $(LIBS_JDKLIB), \

No need to set DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should 
be correct and controlled globally.


Done.

Thanks,
Vladimir



/Erik


Please, review build changes for AOT.  Only Linux/x64 platform is 
supported. 'jaotc' and AOT part of Hotspot will be build only on 
Linux/x64.


Changes include new 'jaotc' launcher, makefile changes to build 
jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot 
and hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build 
native part of 'jaotc'. It is used to generated AOT shared 
libraries (.so) as result of AOT compilation.


Hotspot makefile changes will be pushed together with Hotspot AOT 
changes.


Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Alan Bateman


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 the debug information when 
generating the JRE image to see that it comes out at around the same 
size as the current build.


-Alan.

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-28 Thread Erik Joelsson

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:

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.

CompileJavaModules.gmk: Use of -g flag for java compilation is controlled
globally. Please remove.

There is a reason for that. Some debugging related Graal code makes use of
classfile information to provide better information. Since this is Java and
not C++ it *is* possible to have pleasant debugging experience even in product
builds. I want this to be there.

Chris, do we need -g for JVMCI module too for that?

I’m assuming Chris is referring to the use of debug info for snippet parameter
names:

https://github.com/graalvm/graal-core/blob/7c94891d06f08a635367df6078696b9388332f3b/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java#L191

For that use case, -g is not necessary for JVMCI. That said, I think it’s
always useful for Java code to be compiled with -g ;-)
I'm sure most people do. To my knowledge, -g is disabled by default for
footprint reasons in the JRE. This has been up for discussion before and
I think the conclusion was that ideally we want -g in the JDK image but
not in the JRE image. That has not been possible before (without
compiling everything twice), 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.

For now if you have a special case for needing -g on specific modules,
at the very least provide a comment explaining why. Otherwise it will
just be cleaned away in the future.

/Erik

-Doug

Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK
conditional like all other buildtools targets.

http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/

The extra exports from java.base needs to go in a new
jdk/src/java.base/share/classes/module-info.java.extra since the module
jdk.vm.compiler is optional.

http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to LIBS
since that will provide -lc on Solaris automatically. No need to set
DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and controlled
globally.

/Erik

Please, review build changes for AOT. Only Linux/x64 platform is supported.
'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build jdk.vm.compiler
(Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part of
'jaotc'. It is used to generated AOT shared libraries (.so) as result of AOT
compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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 by ENABLE_AOT as Volker suggested.

I did not figure out how switch off ENABLE_AOT if libelf not found. So I 
changed warning to configuration error:

error: libelf not found, cannot build AOT. Disable AOT build: --enable-aot=no. 
You might be able to fix this by running 'sudo yum install 
elfutils-libelf-devel'.

Which is not correct since AOT build is enabled by default on linux-x64. Need 
help with this.

AOT modules dependencies moved to new module-info.java.extra.

And other changes suggested by Erik.

Thanks,
Vladimir

On 10/27/16 11:41 AM, Vladimir Kozlov wrote:

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: Comment is misleading. Should just be removed.


Removed.


CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
globally. Please remove.


See Chris comment on this. We want to have JAOTC java debug information for 
debugging in product builds.


Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK 
conditional like all other buildtools targets.


Done.




http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/

The extra exports from java.base needs to go in a new 
jdk/src/java.base/share/classes/module-info.java.extra since the module 
jdk.vm.compiler is optional.


Done.


http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to LIBS 
since that will provide -lc on Solaris automatically.


Like this?:

   LDFLAGS := $(LDFLAGS_JDKLIB), \
   LIBS := $(ELF_LIBS) $(LIBS_JDKLIB), \


No need to set DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct 
and controlled globally.


Done.

Thanks,
Vladimir



/Erik


Please, review build changes for AOT.  Only Linux/x64 platform is supported. 
'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build jdk.vm.compiler 
(Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part of 
'jaotc'. It is used to generated AOT shared libraries (.so) as result of AOT 
compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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: Comment is misleading. Should just be removed.


Removed.


CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
globally. Please remove.


See Chris comment on this. We want to have JAOTC java debug information for 
debugging in product builds.


Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK 
conditional like all other buildtools targets.


Done.




http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/

The extra exports from java.base needs to go in a new 
jdk/src/java.base/share/classes/module-info.java.extra since the module 
jdk.vm.compiler is optional.


Done.


http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to LIBS 
since that will provide -lc on Solaris automatically.


Like this?:

  LDFLAGS := $(LDFLAGS_JDKLIB), \
  LIBS := $(ELF_LIBS) $(LIBS_JDKLIB), \


No need to set DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct 
and controlled globally.


Done.

Thanks,
Vladimir



/Erik


Please, review build changes for AOT.  Only Linux/x64 platform is supported. 
'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build jdk.vm.compiler 
(Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part of 
'jaotc'. It is used to generated AOT shared libraries (.so) as result of AOT 
compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-27 Thread Christian Thalinger


> 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 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.
>>> 
>>> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
>>> globally. Please remove.
>> 
>> There is a reason for that.  Some debugging related Graal code makes use of 
>> classfile information to provide better information.  Since this is Java and 
>> not C++ it *is* possible to have pleasant debugging experience even in 
>> product builds.  I want this to be there.
> 
> Chris, do we need -g for JVMCI module too for that?

Yes.

> 
> And do we need -Xlint:-exports for jdk.vm.compiler (Graal)? FOR JVMCI it was 
> added by:
> 
> http://hg.openjdk.java.net/jdk9/hs/rev/81435a812f59 
> 

I can’t remember what the reason for -Xlint was but… wait.  That was added 3 
weeks ago.  No clue then.

> 
> Thanks,
> Vladimir
> 
>> 
>>> 
>>> Main.gmk: buildtools-hotspot should be declared inside the 
>>> CREATING_BUILDJDK conditional like all other buildtools targets.
>>> 
 http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>>> The extra exports from java.base needs to go in a new 
>>> jdk/src/java.base/share/classes/module-info.java.extra since the module 
>>> jdk.vm.compiler is optional.
 http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>>> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to 
>>> LIBS since that will provide -lc on Solaris automatically. No need to set 
>>> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and 
>>> controlled globally.
>>> 
>>> /Erik
 
 Please, review build changes for AOT.  Only Linux/x64 platform is 
 supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
 
 Changes include new 'jaotc' launcher, makefile changes to build 
 jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
 Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
 hotspot/src/jdk.vm.compiler.
 'jaotc' requires installed libelf package on a system to build native part 
 of 'jaotc'. It is used to generated AOT shared libraries (.so) as result 
 of AOT compilation.
 
 Hotspot makefile changes will be pushed together with Hotspot AOT changes.
 
 Thanks,
 Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-27 Thread Doug Simon

> 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:
 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.
>>> 
>>> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
>>> globally. Please remove.
>> 
>> There is a reason for that.  Some debugging related Graal code makes use of 
>> classfile information to provide better information.  Since this is Java and 
>> not C++ it *is* possible to have pleasant debugging experience even in 
>> product builds.  I want this to be there.
> 
> Chris, do we need -g for JVMCI module too for that?

I’m assuming Chris is referring to the use of debug info for snippet parameter 
names:

https://github.com/graalvm/graal-core/blob/7c94891d06f08a635367df6078696b9388332f3b/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java#L191

For that use case, -g is not necessary for JVMCI. That said, I think it’s 
always useful for Java code to be compiled with -g ;-)

-Doug

>> 
>>> 
>>> Main.gmk: buildtools-hotspot should be declared inside the 
>>> CREATING_BUILDJDK conditional like all other buildtools targets.
>>> 
 http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>>> The extra exports from java.base needs to go in a new 
>>> jdk/src/java.base/share/classes/module-info.java.extra since the module 
>>> jdk.vm.compiler is optional.
 http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>>> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to 
>>> LIBS since that will provide -lc on Solaris automatically. No need to set 
>>> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and 
>>> controlled globally.
>>> 
>>> /Erik

 Please, review build changes for AOT.  Only Linux/x64 platform is 
 supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

 Changes include new 'jaotc' launcher, makefile changes to build 
 jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
 Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
 hotspot/src/jdk.vm.compiler.
 'jaotc' requires installed libelf package on a system to build native part 
 of 'jaotc'. It is used to generated AOT shared libraries (.so) as result 
 of AOT compilation.

 Hotspot makefile changes will be pushed together with Hotspot AOT changes.

 Thanks,
 Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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
Webrev:
http://cr.openjdk.java.net/~kvn/aot/top.webrev/

hotspot.m4: 296: Comment is misleading. Should just be removed.

CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
globally. Please remove.


There is a reason for that.  Some debugging related Graal code makes use of 
classfile information to provide better information.  Since this is Java and 
not C++ it *is* possible to have pleasant debugging experience even in product 
builds.  I want this to be there.


Chris, do we need -g for JVMCI module too for that?

And do we need -Xlint:-exports for jdk.vm.compiler (Graal)? FOR JVMCI it was 
added by:

http://hg.openjdk.java.net/jdk9/hs/rev/81435a812f59

Thanks,
Vladimir





Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK 
conditional like all other buildtools targets.


http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/

The extra exports from java.base needs to go in a new 
jdk/src/java.base/share/classes/module-info.java.extra since the module 
jdk.vm.compiler is optional.

http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to LIBS 
since that will provide -lc on Solaris automatically. No need to set 
DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and controlled 
globally.

/Erik


Please, review build changes for AOT.  Only Linux/x64 platform is supported. 
'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build jdk.vm.compiler 
(Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part of 
'jaotc'. It is used to generated AOT shared libraries (.so) as result of AOT 
compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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 LIBJELFSHIM_ENABLED) in 
make/common/Modules.gmk (where AOT modules filtered out)?

http://cr.openjdk.java.net/~kvn/aot/top.webrev/make/common/Modules.gmk.udiff.html

Thanks,
Vladimir

On 10/27/16 8:45 AM, Volker Simonis wrote:

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") && \
   (test "x$OPENJDK_TARGET_CPU_BITS" = "x64")); then
 LIBJELFSHIM_ENABLED="true"
   else
 LIBJELFSHIM_ENABLED="false"
   fi

As far as I understand, this is only required for AOT and should
therefore only be checked for if AOT is enabled. We could do something
similar like for FFI (see libraries.m4):

   # Check if ffi is needed
   if HOTSPOT_CHECK_JVM_VARIANT(zero) ||
HOTSPOT_CHECK_JVM_VARIANT(zeroshark); then
 NEEDS_LIB_FFI=true
   else
 NEEDS_LIB_FFI=false
   fi

And then test for "NEEDS_LIB_JELFSHIM" in lib-elf.m4 instead of
testing for a specific platform.

Otherwise we get ugly warning like:

WARNING: Could not find libelf!  Not building libjelfshim.so



And I think in the case where we compile for AOT, we should print the
usual, platform-dependent hints like for example:

libelf.so not found: try  to run 'sudo apt-get install libelf-dev'


during configuration if we are running on platforms without AOT
support or if AOT support is switched of.

Regards,
Volker



On Thu, Oct 27, 2016 at 2:45 AM, 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/
http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

Please, review build changes for AOT.  Only Linux/x64 platform is supported.
'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build
jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part
of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of
AOT compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-27 Thread Christian Thalinger


> 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:
>> http://cr.openjdk.java.net/~kvn/aot/top.webrev/
> hotspot.m4: 296: Comment is misleading. Should just be removed.
> 
> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled 
> globally. Please remove.

There is a reason for that.  Some debugging related Graal code makes use of 
classfile information to provide better information.  Since this is Java and 
not C++ it *is* possible to have pleasant debugging experience even in product 
builds.  I want this to be there.

> 
> Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK 
> conditional like all other buildtools targets.
> 
>> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
> The extra exports from java.base needs to go in a new 
> jdk/src/java.base/share/classes/module-info.java.extra since the module 
> jdk.vm.compiler is optional.
>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to 
> LIBS since that will provide -lc on Solaris automatically. No need to set 
> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and 
> controlled globally.
> 
> /Erik
>> 
>> Please, review build changes for AOT.  Only Linux/x64 platform is supported. 
>> 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>> 
>> Changes include new 'jaotc' launcher, makefile changes to build 
>> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
>> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
>> hotspot/src/jdk.vm.compiler.
>> 'jaotc' requires installed libelf package on a system to build native part 
>> of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of 
>> AOT compilation.
>> 
>> Hotspot makefile changes will be pushed together with Hotspot AOT changes.
>> 
>> Thanks,
>> Vladimir
>

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

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, Vladimir Kozlov
 wrote:
> 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:
>>
>>
>> /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;
>>^
>>
>> /usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:180:
>> error: module not found: jdk.vm.compiler
>>  jdk.vm.compiler,
>>^
>>
>> /usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:309:
>> error: module not found: jdk.vm.compiler
>>  jdk.vm.compiler;
>>
>> I have integrated this two webrevs and the hotspot webrev from
>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/
>>
>> What do I have to do, to get it at least compiled?
>>
>> Regards,
>> Volker
>>
>> On Thu, Oct 27, 2016 at 2:40 PM, 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: Comment is misleading. Should just be removed.
>>>
>>> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled
>>> globally. Please remove.
>>>
>>> Main.gmk: buildtools-hotspot should be declared inside the
>>> CREATING_BUILDJDK
>>> conditional like all other buildtools targets.
>>>
 http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>>>
>>>
>>> The extra exports from java.base needs to go in a new
>>> jdk/src/java.base/share/classes/module-info.java.extra since the module
>>> jdk.vm.compiler is optional.


 http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>>>
>>>
>>> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to
>>> LIBS since that will provide -lc on Solaris automatically. No need to set
>>> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and
>>> controlled globally.
>>>
>>> /Erik
>>>

 Please, review build changes for AOT.  Only Linux/x64 platform is
 supported. 'jaotc' and AOT part of Hotspot will be build only on
 Linux/x64.

 Changes include new 'jaotc' launcher, makefile changes to build
 jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
 Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
 hotspot/src/jdk.vm.compiler.
 'jaotc' requires installed libelf package on a system to build native
 part
 of 'jaotc'. It is used to generated AOT shared libraries (.so) as result
 of
 AOT compilation.

 Hotspot makefile changes will be pushed together with Hotspot AOT
 changes.

 Thanks,
 Vladimir
>>>
>>>
>>>
>

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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:

/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;
   ^
/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:180:
error: module not found: jdk.vm.compiler
 jdk.vm.compiler,
   ^
/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:309:
error: module not found: jdk.vm.compiler
 jdk.vm.compiler;

I have integrated this two webrevs and the hotspot webrev from
http://cr.openjdk.java.net/~kvn/aot/hs.webrev/

What do I have to do, to get it at least compiled?

Regards,
Volker

On Thu, Oct 27, 2016 at 2:40 PM, 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: Comment is misleading. Should just be removed.

CompileJavaModules.gmk: Use of -g flag for java compilation is controlled
globally. Please remove.

Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK
conditional like all other buildtools targets.


http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/


The extra exports from java.base needs to go in a new
jdk/src/java.base/share/classes/module-info.java.extra since the module
jdk.vm.compiler is optional.


http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/


Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to
LIBS since that will provide -lc on Solaris automatically. No need to set
DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and
controlled globally.

/Erik



Please, review build changes for AOT.  Only Linux/x64 platform is
supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build
jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part
of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of
AOT compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

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;
  ^
/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:180:
error: module not found: jdk.vm.compiler
jdk.vm.compiler,
  ^
/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:309:
error: module not found: jdk.vm.compiler
jdk.vm.compiler;

I have integrated this two webrevs and the hotspot webrev from
http://cr.openjdk.java.net/~kvn/aot/hs.webrev/

What do I have to do, to get it at least compiled?

Regards,
Volker

On Thu, Oct 27, 2016 at 2:40 PM, 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: Comment is misleading. Should just be removed.
>
> CompileJavaModules.gmk: Use of -g flag for java compilation is controlled
> globally. Please remove.
>
> Main.gmk: buildtools-hotspot should be declared inside the CREATING_BUILDJDK
> conditional like all other buildtools targets.
>
>> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>
> The extra exports from java.base needs to go in a new
> jdk/src/java.base/share/classes/module-info.java.extra since the module
> jdk.vm.compiler is optional.
>>
>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>
> Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) to
> LIBS since that will provide -lc on Solaris automatically. No need to set
> DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and
> controlled globally.
>
> /Erik
>
>>
>> Please, review build changes for AOT.  Only Linux/x64 platform is
>> supported. 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>>
>> Changes include new 'jaotc' launcher, makefile changes to build
>> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
>> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
>> hotspot/src/jdk.vm.compiler.
>> 'jaotc' requires installed libelf package on a system to build native part
>> of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of
>> AOT compilation.
>>
>> Hotspot makefile changes will be pushed together with Hotspot AOT changes.
>>
>> Thanks,
>> Vladimir
>
>

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT 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") && \
>   (test "x$OPENJDK_TARGET_CPU_BITS" = "x64")); then
> LIBJELFSHIM_ENABLED="true"
>   else
> LIBJELFSHIM_ENABLED="false"
>   fi
>
> As far as I understand, this is only required for AOT and should
> therefore only be checked for if AOT is enabled. We could do something
> similar like for FFI (see libraries.m4):
>
>   # Check if ffi is needed
>   if HOTSPOT_CHECK_JVM_VARIANT(zero) ||
> HOTSPOT_CHECK_JVM_VARIANT(zeroshark); then
> NEEDS_LIB_FFI=true
>   else
> NEEDS_LIB_FFI=false
>   fi
>
> And then test for "NEEDS_LIB_JELFSHIM" in lib-elf.m4 instead of
> testing for a specific platform.
>
> Otherwise we get ugly warning like:
>
> WARNING: Could not find libelf!  Not building libjelfshim.so
>

And I think in the case where we compile for AOT, we should print the
usual, platform-dependent hints like for example:

libelf.so not found: try  to run 'sudo apt-get install libelf-dev'

> during configuration if we are running on platforms without AOT
> support or if AOT support is switched of.
>
> Regards,
> Volker
>
>
>
> On Thu, Oct 27, 2016 at 2:45 AM, 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/
>> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
>> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>>
>> Please, review build changes for AOT.  Only Linux/x64 platform is supported.
>> 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>>
>> Changes include new 'jaotc' launcher, makefile changes to build
>> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
>> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
>> hotspot/src/jdk.vm.compiler.
>> 'jaotc' requires installed libelf package on a system to build native part
>> of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of
>> AOT compilation.
>>
>> Hotspot makefile changes will be pushed together with Hotspot AOT changes.
>>
>> Thanks,
>> Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler


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 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 because not everybody may have the right version of
autoconf at hand.

Thanks,
Volker


On Thu, Oct 27, 2016 at 2:45 AM, 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/
http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/

Please, review build changes for AOT.  Only Linux/x64 platform is supported.
'jaotc' and AOT part of Hotspot will be build only on Linux/x64.

Changes include new 'jaotc' launcher, makefile changes to build
jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native part
of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of
AOT compilation.

Hotspot makefile changes will be pushed together with Hotspot AOT changes.

Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

2016-10-27 Thread Erik Joelsson




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.

CompileJavaModules.gmk: Use of -g flag for java compilation is 
controlled globally. Please remove.


Main.gmk: buildtools-hotspot should be declared inside the 
CREATING_BUILDJDK conditional like all other buildtools targets.



http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
The extra exports from java.base needs to go in a new 
jdk/src/java.base/share/classes/module-info.java.extra since the module 
jdk.vm.compiler is optional.

http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
Lib-jdk.aot.gmk: Please inline LDFLAGS and LIBS and add $(LIBS_JDKLIB) 
to LIBS since that will provide -lc on Solaris automatically. No need to 
set DEBUG_SYMBOLS or STRIP_SYMBOLS as the defaults should be correct and 
controlled globally.


/Erik


Please, review build changes for AOT.  Only Linux/x64 platform is 
supported. 'jaotc' and AOT part of Hotspot will be build only on 
Linux/x64.


Changes include new 'jaotc' launcher, makefile changes to build 
jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
Both modules sources are located in Hotspot: hotspot/src/jdk.aot and 
hotspot/src/jdk.vm.compiler.
'jaotc' requires installed libelf package on a system to build native 
part of 'jaotc'. It is used to generated AOT shared libraries (.so) as 
result of AOT compilation.


Hotspot makefile changes will be pushed together with Hotspot AOT 
changes.


Thanks,
Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

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"
  else
LIBJELFSHIM_ENABLED="false"
  fi

As far as I understand, this is only required for AOT and should
therefore only be checked for if AOT is enabled. We could do something
similar like for FFI (see libraries.m4):

  # Check if ffi is needed
  if HOTSPOT_CHECK_JVM_VARIANT(zero) ||
HOTSPOT_CHECK_JVM_VARIANT(zeroshark); then
NEEDS_LIB_FFI=true
  else
NEEDS_LIB_FFI=false
  fi

And then test for "NEEDS_LIB_JELFSHIM" in lib-elf.m4 instead of
testing for a specific platform.

Otherwise we get ugly warning like:

WARNING: Could not find libelf!  Not building libjelfshim.so

during configuration if we are running on platforms without AOT
support or if AOT support is switched of.

Regards,
Volker



On Thu, Oct 27, 2016 at 2:45 AM, 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/
> http://cr.openjdk.java.net/~kvn/aot/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/aot/hs.make.webrev/
>
> Please, review build changes for AOT.  Only Linux/x64 platform is supported.
> 'jaotc' and AOT part of Hotspot will be build only on Linux/x64.
>
> Changes include new 'jaotc' launcher, makefile changes to build
> jdk.vm.compiler (Graal) and jdk.aot modules used by 'jaotc'.
> Both modules sources are located in Hotspot: hotspot/src/jdk.aot and
> hotspot/src/jdk.vm.compiler.
> 'jaotc' requires installed libelf package on a system to build native part
> of 'jaotc'. It is used to generated AOT shared libraries (.so) as result of
> AOT compilation.
>
> Hotspot makefile changes will be pushed together with Hotspot AOT changes.
>
> Thanks,
> Vladimir

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler