date:20161027



On 10/27/16 6:31 PM, Pete Brunet wrote:
> On 10/27/16 1:30 PM, Mandy Chung wrote:
>>> On Oct 27, 2016, at 10:44 AM, Phil Race  wrote:
>>>
>>> No, we are definitely shipping those.
>>> Unless of course you think we should stop shipping JNI headers too …
>>>
>> No.  I tried to understand what is external interface.  I took it that these 
>> header files are external interfaces.
>>
>> I reviewed:
>>   http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.05/index.html
>>
>> Please move AccessBridgeCalls.c to  
>> src/jdk.accessibility/windows/native/bridge directory.
> I moved the source to
> src/jdk.accessibility/windows/native/bridge/src
> and the includes to
> src/jdk.accessibility/windows/native/bridge/include
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.06/
I forgot to update the link in readme.html, i.e. include/bridge is now
bridge/include.  See
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.07/
>> Right now, the header files to be packaged in the JMOD file and linked into 
>> the image is white-listed in the makefile.
>>
>> Ultimately, we want the entire directory to contain only header files for 
>> external interfaces and then the build can simply take all files under 
>> src/${MODULE}/share,${OS}/native/include and get rid of the hardcoded list 
>> in the makefile.  We are not there yet - one open issue is related to the 
>> duplicated header files in VM and JDK and some are private and some are 
>> external.  But we should prepare for that.
>>
>> Mandy
>>
>>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory


On 10/27/16 1:30 PM, Mandy Chung wrote:
>> On Oct 27, 2016, at 10:44 AM, Phil Race  wrote:
>>
>> No, we are definitely shipping those.
>> Unless of course you think we should stop shipping JNI headers too …
>>
> No.  I tried to understand what is external interface.  I took it that these 
> header files are external interfaces.
>
> I reviewed:
>   http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.05/index.html
>
> Please move AccessBridgeCalls.c to  
> src/jdk.accessibility/windows/native/bridge directory.
I moved the source to
src/jdk.accessibility/windows/native/bridge/src
and the includes to
src/jdk.accessibility/windows/native/bridge/include

http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.06/
>
> Right now, the header files to be packaged in the JMOD file and linked into 
> the image is white-listed in the makefile.
>
> Ultimately, we want the entire directory to contain only header files for 
> external interfaces and then the build can simply take all files under 
> src/${MODULE}/share,${OS}/native/include and get rid of the hardcoded list in 
> the makefile.  We are not there yet - one open issue is related to the 
> duplicated header files in VM and JDK and some are private and some are 
> external.  But we should prepare for that.
>
> Mandy
>
>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory


On 10/27/2016 11:52 AM, Pete Brunet wrote:


On 10/27/16 1:47 PM, Pete Brunet wrote:

On 10/27/16 1:34 PM, Phil Race wrote:

In which case be careful it is not built by the JDK build ..

Build team, Is there anything I need to handle here to make sure it isn't?

Actually, let me give it a try.  I should be able to resolve any
issues.  If not I'll ask again.


The makefiles have lists of files to be excluded from the build.
Look at make/lib/Awt2dLibraries.gmk for lines like
LIBFOO_EXCLUDE_FILES += ...

In theory this should work the same way for AccessBridge.

-phil.

unless that is actually required .. which I didn't think it was.

-phil.

On 10/27/2016 11:30 AM, Mandy Chung wrote:

Please move AccessBridgeCalls.c to
src/jdk.accessibility/windows/native/bridge directory.

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory



On 10/27/16 1:47 PM, Pete Brunet wrote:
>
> On 10/27/16 1:34 PM, Phil Race wrote:
>> In which case be careful it is not built by the JDK build ..
> Build team, Is there anything I need to handle here to make sure it isn't?
Actually, let me give it a try.  I should be able to resolve any
issues.  If not I'll ask again.
>> unless that is actually required .. which I didn't think it was.
>>
>> -phil.
>>
>> On 10/27/2016 11:30 AM, Mandy Chung wrote:
>>> Please move AccessBridgeCalls.c to 
>>> src/jdk.accessibility/windows/native/bridge directory.

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory



On 10/27/16 1:34 PM, Phil Race wrote:
> In which case be careful it is not built by the JDK build ..
Build team, Is there anything I need to handle here to make sure it isn't?
> unless that is actually required .. which I didn't think it was.
>
> -phil.
>
> On 10/27/2016 11:30 AM, Mandy Chung wrote:
>> Please move AccessBridgeCalls.c to 
>> src/jdk.accessibility/windows/native/bridge directory.
>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory



On 10/27/16 1:34 PM, Phil Race wrote:
> In which case be careful it is not built by the JDK build ..
> unless that is actually required .. which I didn't think it was.
It isn't.
>
> -phil.
>
> On 10/27/2016 11:30 AM, Mandy Chung wrote:
>> Please move AccessBridgeCalls.c to 
>> src/jdk.accessibility/windows/native/bridge directory.
>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory


In which case be careful it is not built by the JDK build ..
unless that is actually required .. which I didn't think it was.

-phil.

On 10/27/2016 11:30 AM, Mandy Chung wrote:

Please move AccessBridgeCalls.c to  src/jdk.accessibility/windows/native/bridge 
directory.

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: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

2016-10-27 Thread Mandy Chung

> On Oct 27, 2016, at 10:44 AM, Phil Race  wrote:
> 
> No, we are definitely shipping those.
> Unless of course you think we should stop shipping JNI headers too …
> 

No.  I tried to understand what is external interface.  I took it that these 
header files are external interfaces.

I reviewed:
  http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.05/index.html

Please move AccessBridgeCalls.c to  src/jdk.accessibility/windows/native/bridge 
directory.

Right now, the header files to be packaged in the JMOD file and linked into the 
image is white-listed in the makefile.

Ultimately, we want the entire directory to contain only header files for 
external interfaces and then the build can simply take all files under 
src/${MODULE}/share,${OS}/native/include and get rid of the hardcoded list in 
the makefile.  We are not there yet - one open issue is related to the 
duplicated header files in VM and JDK and some are private and some are 
external.  But we should prepare for that.

Mandy

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: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory


No, we are definitely shipping those.
Unless of course you think we should stop shipping JNI headers too ...

-phil

On 10/27/2016 10:37 AM, Mandy Chung wrote:

Should they be kept just in the source and not to be included in the 
image/include directory?

It’s not clear to me if anyone needs these header files from the JDK image as 
AccessBridgeCalls.c is obtained from the source.

Mandy


On Oct 27, 2016, at 6:48 AM, Pete Brunet  wrote:

The .h files are unlicensed in the bundle/install so no need?

On 10/26/16 11:52 PM, Mandy Chung wrote:

Should the same change be applied to the .h files as well?

Mandy


On Oct 26, 2016, at 7:24 PM, Pete Brunet  wrote:

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/

The change is to AccessBridgeCalls.c.  The license has been changed from
GPL2 to BSD.  This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is linked to by
vendors creating proprietary code.  Vendors will be instructed to
download AccessBridgeCalls.c from the OpenJDK repository.  Also the
include/use of AccessBridgeDebug.h/cpp has been removed.

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:

The fix looks good to me.

Thanks,
Alexandr.

On 10/24/2016 1:18 PM, Erik Joelsson wrote:

The last change looks good and simple to me.

/Erik


On 2016-10-21 06:55, Pete Brunet wrote:

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/

The fix now is to simply remove the copy of the AccessBridgeCalls.c
file
into the JDK.

AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that hides the
complications related to interfacing to JAB's WindowsAccessBridge*.dll.
In the past users of the API would compile and link to
AccessBridgeCalls.c/obj.

Since the interface implementation of AccessBridgeCalls.c will no
longer
be provided the JAB API documentation will be updated to instruct a
user
how to create an equivalent of AccessBridgeCalls.c.  The documentation
will also contain a reference to the JAB 2.0.2 download
http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html

which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:

I've updated the webrev.  Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/

Rather than removing the files needed by Assistive Technology
developers
we have to provide them in JDK.  However since there is a .c file
in the
group of files the files were moved from the include directory to a
new
javaaccessbridge directory.

On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:

On 2016-10-14 17:51, Pete Brunet wrote:

Please review the following.

The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from
the built
JRE/JDK images.  They are not used much and they can be obtained
online
via the OpenJDK web site.  The pubs will be updated to mention the
location of the files.

Since there is a .c file in this group of files the directory
structure
has been changed slightly to remove the include directory.

There was one file missing from the group of files needed by
developers
and that was moved from the common to the bridge directory.

The make was updated in response to the above.

Bug: https://bugs.openjdk.java.net/browse/JDK-8167213

Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/

Build changes looks good to me.

/Magnus

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

2016-10-27 Thread Mandy Chung

Should they be kept just in the source and not to be included in the 
image/include directory?

It’s not clear to me if anyone needs these header files from the JDK image as 
AccessBridgeCalls.c is obtained from the source.

Mandy

> On Oct 27, 2016, at 6:48 AM, Pete Brunet  wrote:
> 
> The .h files are unlicensed in the bundle/install so no need?
> 
> On 10/26/16 11:52 PM, Mandy Chung wrote:
>> Should the same change be applied to the .h files as well?
>> 
>> Mandy
>> 
>>> On Oct 26, 2016, at 7:24 PM, Pete Brunet  wrote:
>>> 
>>> Please review the latest update at
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>>> 
>>> The change is to AccessBridgeCalls.c.  The license has been changed from
>>> GPL2 to BSD.  This is because the file was originally unlicensed prior
>>> to being bundled into the JDK and the compiled .obj is linked to by
>>> vendors creating proprietary code.  Vendors will be instructed to
>>> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
>>> include/use of AccessBridgeDebug.h/cpp has been removed.
>>> 
>>> Please also review readme.html which has been added to
>>> .../jdk/include/win32/bridge.
>>> 
>>> Pete
>>> 
>>> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
 The fix looks good to me.
 
 Thanks,
 Alexandr.
 
 On 10/24/2016 1:18 PM, Erik Joelsson wrote:
> The last change looks good and simple to me.
> 
> /Erik
> 
> 
> On 2016-10-21 06:55, Pete Brunet wrote:
>> Please see the latest update
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>> 
>> The fix now is to simply remove the copy of the AccessBridgeCalls.c
>> file
>> into the JDK.
>> 
>> AccessBridgeCalls.c is the implementation of the documented Java Access
>> Bridge API and is a set of wrapper functions that hides the
>> complications related to interfacing to JAB's WindowsAccessBridge*.dll.
>> In the past users of the API would compile and link to
>> AccessBridgeCalls.c/obj.
>> 
>> Since the interface implementation of AccessBridgeCalls.c will no
>> longer
>> be provided the JAB API documentation will be updated to instruct a
>> user
>> how to create an equivalent of AccessBridgeCalls.c.  The documentation
>> will also contain a reference to the JAB 2.0.2 download
>> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>> 
>> which does contain AccessBridgeCalls.c and which is compatible with the
>> current API and related calls into WindowsAccessBridge*.dll.
>> 
>> Pete
>> 
>> On 10/18/16 12:28 PM, Pete Brunet wrote:
>>> I've updated the webrev.  Please see
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>>> 
>>> Rather than removing the files needed by Assistive Technology
>>> developers
>>> we have to provide them in JDK.  However since there is a .c file
>>> in the
>>> group of files the files were moved from the include directory to a
>>> new
>>> javaaccessbridge directory.
>>> 
>>> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
 On 2016-10-14 17:51, Pete Brunet wrote:
> Please review the following.
> 
> The .h files and .c file provided to allow Assistive Technology to
> interface to the Java Access Bridge API are being removed from
> the built
> JRE/JDK images.  They are not used much and they can be obtained
> online
> via the OpenJDK web site.  The pubs will be updated to mention the
> location of the files.
> 
> Since there is a .c file in this group of files the directory
> structure
> has been changed slightly to remove the include directory.
> 
> There was one file missing from the group of files needed by
> developers
> and that was moved from the common to the bridge directory.
> 
> The make was updated in response to the above.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167213
> 
> Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
 Build changes looks good to me.
 
 /Magnus
>

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

This all seems fine.

Do other accessbridge files still have the remnants of SCCS ? :-
That was purged from all the other JDK files when we moved to mercurial.

33 /*
34 * @(#)AccessBridgeCalls.c 1.25 05/08/22
35 */

If "yes", then I suggest to file a clean-up bug to clean up all of these
separately.

if "no", then I suggest to fix this one file here and now ..

-phil.

On 10/27/2016 07:41 AM, Pete Brunet wrote:

Thanks for noticing that Phil. Updated at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.05/

On 10/27/16 9:20 AM, Philip Race wrote:

But it still needs to say "jdk9/jdk9" not jdk9/client or jdk9/dev.

-phil.

On 10/26/16, 9:27 PM, Anirvan Sarkar wrote:

Hi,

If you replace the hex number with 'tip' then it will always point
to the latest version.

Something like
http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

Regards,
Anirvan Sarkar

On Thursday 27 October 2016, Pete Brunet > wrote:

On 10/26/16 10:44 PM, Philip Race wrote:

>
15 http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c;

>
That URL is definitely not authoritative.

I think you need to give a pointer to something more like

http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

Looks like that hex number in there is the Mercurial long
revision number of the tip so that's going to keep changing.
I'm not aware of a "latest" link. Maybe some other reader will

know.

But I am not sure about that either .. it may need to be split between the
main URL and the location in the repo.

-phil
On 10/26/16, 7:24 PM, Pete Brunet wrote:

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/

The change is to AccessBridgeCalls.c. The license has been changed from
GPL2 to BSD. This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is linked to by
vendors creating proprietary code. Vendors will be instructed to
download AccessBridgeCalls.c from the OpenJDK repository. Also the
include/use of AccessBridgeDebug.h/cpp has been removed.

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:

The fix looks good to me.

Thanks,
Alexandr.

On 10/24/2016 1:18 PM, Erik Joelsson wrote:

The last change looks good and simple to me.

/Erik

On 2016-10-21 06:55, Pete Brunet wrote:

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/

The fix now is to simply remove the copy of the AccessBridgeCalls.c
file
into the JDK.

AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that hides the
complications related to interfacing to JAB's WindowsAccessBridge*.dll.
In the past users of the API would compile and link to
AccessBridgeCalls.c/obj.

Since the interface implementation of AccessBridgeCalls.c will no
longer
be provided the JAB API documentation will be updated to instruct a
user
how to create an equivalent of AccessBridgeCalls.c. The documentation
will also contain a reference to the JAB 2.0.2 download

http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html

which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:

I've updated the webrev. Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/

Rather than removing the files needed by Assistive Technology
developers
we have to provide them in JDK. However since there is a .c file
in the
group of files the files were moved from the include directory to a
new
javaaccessbridge directory.

On 10/17/16

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: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

Thanks for noticing that Phil.  Updated at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.05/


On 10/27/16 9:20 AM, Philip Race wrote:
> But it still needs to say "jdk9/jdk9" not jdk9/client or jdk9/dev.
>
> -phil.
>
> On 10/26/16, 9:27 PM, Anirvan Sarkar wrote:
>> Hi,
>>
>> If you replace the hex number with 'tip' then it will always point to
>> the latest version. 
>>
>> Something
>> like 
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
>> 
>>
>> Regards,
>> Anirvan Sarkar
>>
>> On Thursday 27 October 2016, Pete Brunet > > wrote:
>>
>>
>>
>> On 10/26/16 10:44 PM, Philip Race wrote:
>>> >
>>>   15 >> href="http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c;
>>> 
>>> >
>>> That URL is definitely not authoritative.
>>>
>>> I think you need to give a pointer to something more like
>>> 
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
>>> 
>>> 
>> Looks like that hex number in there is the Mercurial long
>> revision number of the tip so that's going to keep changing.  I'm
>> not aware of a "latest" link.  Maybe some other reader will know.
>>> But I am not sure about that either .. it may need to be split between 
>>> the main URL and the location in the repo.
>>>
>>> -phil 
>>> On 10/26/16, 7:24 PM, Pete Brunet wrote:
 Please review the latest update at
 http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
 

 The change is to AccessBridgeCalls.c.  The license has been changed 
 from
 GPL2 to BSD.  This is because the file was originally unlicensed prior
 to being bundled into the JDK and the compiled .obj is linked to by
 vendors creating proprietary code.  Vendors will be instructed to
 download AccessBridgeCalls.c from the OpenJDK repository.  Also the
 include/use of AccessBridgeDebug.h/cpp has been removed.

 Please also review readme.html which has been added to
 .../jdk/include/win32/bridge.

 Pete

 On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
> The fix looks good to me.
>
> Thanks,
> Alexandr.
>
> On 10/24/2016 1:18 PM, Erik Joelsson wrote:
>> The last change looks good and simple to me.
>>
>> /Erik
>>
>>
>> On 2016-10-21 06:55, Pete Brunet wrote:
>>> Please see the latest update
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>>> 
>>>
>>> The fix now is to simply remove the copy of the AccessBridgeCalls.c
>>> file
>>> into the JDK.
>>>
>>> AccessBridgeCalls.c is the implementation of the documented Java 
>>> Access
>>> Bridge API and is a set of wrapper functions that hides the
>>> complications related to interfacing to JAB's 
>>> WindowsAccessBridge*.dll.
>>> In the past users of the API would compile and link to
>>> AccessBridgeCalls.c/obj.
>>>
>>> Since the interface implementation of AccessBridgeCalls.c will no
>>> longer
>>> be provided the JAB API documentation will be updated to instruct a
>>> user
>>> how to create an equivalent of AccessBridgeCalls.c.  The 
>>> documentation
>>> will also contain a reference to the JAB 2.0.2 download
>>> 
>>> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>>> 
>>> 
>>>
>>> which does contain AccessBridgeCalls.c and which is compatible with 
>>> the
>>> current API and related calls into WindowsAccessBridge*.dll.
>>>
>>> Pete
>>>
>>> On 10/18/16 12:28 PM, Pete Brunet wrote:
 I've updated the webrev.  Please see
 http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
 

 Rather than removing the files needed by Assistive Technology
 developers
 we have to provide them

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: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

2016-10-27 Thread Philip Race

But it still needs to say "jdk9/jdk9" not jdk9/client or jdk9/dev.

-phil.

On 10/26/16, 9:27 PM, Anirvan Sarkar wrote:

Hi,

If you replace the hex number with 'tip' then it will always point to
the latest version.

Something like
http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

Regards,
Anirvan Sarkar

On Thursday 27 October 2016, Pete Brunet > wrote:

On 10/26/16 10:44 PM, Philip Race wrote:

>
15http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c;

>
That URL is definitely not authoritative.

I think you need to give a pointer to something more like

http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

Looks like that hex number in there is the Mercurial long revision
number of the tip so that's going to keep changing. I'm not aware
of a "latest" link. Maybe some other reader will know.

But I am not sure about that either .. it may need to be split between the
main URL and the location in the repo.

-phil

On 10/26/16, 7:24 PM, Pete Brunet wrote:

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:

The fix looks good to me.

Thanks,
Alexandr.

On 10/24/2016 1:18 PM, Erik Joelsson wrote:

The last change looks good and simple to me.

/Erik

On 2016-10-21 06:55, Pete Brunet wrote:

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/

The fix now is to simply remove the copy of the AccessBridgeCalls.c
file
into the JDK.

http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html

which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:

I've updated the webrev. Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/

On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:

On 2016-10-14 17:51, Pete Brunet wrote:

Please review the following.

The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from
the built
JRE/JDK images. They are not used much and they can be obtained
online
via the OpenJDK web site. The pubs will be updated to mention the
location of the files.

Since there is a .c file in this group of files the directory
structure
has been changed slightly to remove the include directory.

There was

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

The .h files are unlicensed in the bundle/install so no need?

On 10/26/16 11:52 PM, Mandy Chung wrote:
> Should the same change be applied to the .h files as well?
>
> Mandy
>
>> On Oct 26, 2016, at 7:24 PM, Pete Brunet  wrote:
>>
>> Please review the latest update at
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/
>>
>> The change is to AccessBridgeCalls.c.  The license has been changed from
>> GPL2 to BSD.  This is because the file was originally unlicensed prior
>> to being bundled into the JDK and the compiled .obj is linked to by
>> vendors creating proprietary code.  Vendors will be instructed to
>> download AccessBridgeCalls.c from the OpenJDK repository.  Also the
>> include/use of AccessBridgeDebug.h/cpp has been removed.
>>
>> Please also review readme.html which has been added to
>> .../jdk/include/win32/bridge.
>>
>> Pete
>>
>> On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:
>>> The fix looks good to me.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 10/24/2016 1:18 PM, Erik Joelsson wrote:
 The last change looks good and simple to me.

 /Erik


 On 2016-10-21 06:55, Pete Brunet wrote:
> Please see the latest update
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/
>
> The fix now is to simply remove the copy of the AccessBridgeCalls.c
> file
> into the JDK.
>
> AccessBridgeCalls.c is the implementation of the documented Java Access
> Bridge API and is a set of wrapper functions that hides the
> complications related to interfacing to JAB's WindowsAccessBridge*.dll.
> In the past users of the API would compile and link to
> AccessBridgeCalls.c/obj.
>
> Since the interface implementation of AccessBridgeCalls.c will no
> longer
> be provided the JAB API documentation will be updated to instruct a
> user
> how to create an equivalent of AccessBridgeCalls.c.  The documentation
> will also contain a reference to the JAB 2.0.2 download
> http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
>
> which does contain AccessBridgeCalls.c and which is compatible with the
> current API and related calls into WindowsAccessBridge*.dll.
>
> Pete
>
> On 10/18/16 12:28 PM, Pete Brunet wrote:
>> I've updated the webrev.  Please see
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>>
>> Rather than removing the files needed by Assistive Technology
>> developers
>> we have to provide them in JDK.  However since there is a .c file
>> in the
>> group of files the files were moved from the include directory to a
>> new
>> javaaccessbridge directory.
>>
>> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
>>> On 2016-10-14 17:51, Pete Brunet wrote:
 Please review the following.

 The .h files and .c file provided to allow Assistive Technology to
 interface to the Java Access Bridge API are being removed from
 the built
 JRE/JDK images.  They are not used much and they can be obtained
 online
 via the OpenJDK web site.  The pubs will be updated to mention the
 location of the files.

 Since there is a .c file in this group of files the directory
 structure
 has been changed slightly to remove the include directory.

 There was one file missing from the group of files needed by
 developers
 and that was moved from the common to the bridge directory.

 The make was updated in response to the above.

 Bug: https://bugs.openjdk.java.net/browse/JDK-8167213

 Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
>>> Build changes looks good to me.
>>>
>>> /Magnus

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