RE: 8202794: Native Unix code should use readdir rather than readdir_r
Hey, all; did this get resolved? I'm still getting this error in
pulled-yesterday clones of jdk8u and jdk9 and jdk10. I would prefer not to
make local changes (mostly I want to build debug builds so I can spelunk the
JVM bits), but if this isn't going to roll out fairly shortly I'll disable
warnings-as-errors and carry on.
Ted Neward
Technologist and Leader
T: @tedneward | M: (425) 647-4526
http://www.newardassociates.com
-Original Message-
From: build-dev On Behalf Of Pengfei Li
Sent: Thursday, June 28, 2018 3:01 AM
To: kim.barr...@oracle.com; bsr...@gmail.com
Cc: build-dev@openjdk.java.net; nd ;
core-libs-...@openjdk.java.net
Subject: RFR: 8202794: Native Unix code should use readdir rather than
readdir_r
Hi
Last month, Bernard proposed a patch to fix the OpenJDK build issue with
recent versions of glibc.
See
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html
But this fix requires to be tested on all POSIX systems before getting
integrated.
As recently, more and more guys are complaining about the OpenJDK build
failure issue, shall we just add the following workaround to upstream before
Bernard's real fix eventually merged?
diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c
b/src/java.base/unix/native/libjava/TimeZone_md.c
index f0bb362afc..e156381acd 100644
--- a/src/java.base/unix/native/libjava/TimeZone_md.c
+++ b/src/java.base/unix/native/libjava/TimeZone_md.c
@@ -146,7 +146,7 @@ findZoneinfoFile(char *buf, size_t size, const char
*dir)
(void) closedir(dirp);
return NULL;
}
-
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
while (readdir64_r(dirp, entry, ) == 0 && dp != NULL) {
/*
* Skip '.' and '..' (and possibly other .* files) diff --git
a/src/java.base/unix/native/libjava/UnixFileSystem_md.c
b/src/java.base/unix/native/libjava/UnixFileSystem_md.c
index 315aa92b64..5b9554dd47 100644
--- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c
+++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c
@@ -339,6 +339,7 @@ Java_java_io_UnixFileSystem_list(JNIEnv *env, jobject
this,
if (rv == NULL) goto error;
/* Scan the directory */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
while ((readdir64_r(dir, ptr, ) == 0) && (result != NULL)) {
jstring name;
if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) diff
--git a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
index 53bb1c1009..72c38eb9a6 100644
--- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
+++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
@@ -731,6 +731,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv*
env, jclass this, jlong val
/* EINTR not listed as a possible error */
/* TDB: reentrant version probably not required here */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
res = readdir64_r(dirp, ptr, );
#ifdef _AIX
diff --git
a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
index 1adeaf7bb5..080cf2a89b 100644
--- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c
+++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemIm
+++ pl.c
@@ -80,6 +80,7 @@ static struct dirent* read_dir(DIR* dirp, struct dirent*
entry) {
return dbuf;
#else /* __linux__ || _ALLBSD_SOURCE */
struct dirent* p;
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
if (readdir_r(dirp, entry, ) == 0) {
return p;
} else {
--
Thanks,
Pengfei
Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds
Looks good to me. /Magnus > 3 aug. 2018 kl. 00:21 skrev David Holmes : > >> On 3/08/2018 4:59 PM, Baesken, Matthias wrote: >> Thank you David , can the change be pushed , or do I need a second >> review for an XS change ? >> (any way a second review would be good ) > > Need a review from official build team member :) > > Cheers, > David > >> Best regards, Matthias >>> -Original Message- >>> From: David Holmes >>> Sent: Freitag, 3. August 2018 08:18 >>> To: Baesken, Matthias ; Magnus Ihse Bursie >>> >>> Cc: build-dev@openjdk.java.net >>> Subject: Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for >>> JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs >>> builds >>> >>> Looks fine to me. >>> >>> Thanks, >>> David >>> On 3/08/2018 4:13 PM, Baesken, Matthias wrote: Hello, I can confirm what David said . Additionally I grepped through /usr/include on my Linux machine and did >>> not find any USE_MMAP occurences. I created this webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8208744/ https://bugs.openjdk.java.net/browse/JDK-8208744 Please review ! Thanks, Matthias > -Original Message- > From: David Holmes > Sent: Freitag, 3. August 2018 02:56 > To: Magnus Ihse Bursie ; Baesken, > Matthias > Cc: build-dev@openjdk.java.net > Subject: Re: unneeded -DUSE_MMAP in JDK native libs builds > >> On 3/08/2018 3:44 AM, Magnus Ihse Bursie wrote: >> >>> 2 aug. 2018 kl. 05:33 skrev Baesken, Matthias > : >>> >>> Hello I noticed that -DUSE_MMAP is set for these JDK native libs, >>> but >>> I > cannot find it in the code (for libzip it is different there the flag > shows up >>> in > the code too ) : >> >> I've always assumed that this was used to control the behavior in some > imported header files. Have you verified that this is not the case? > > It is only used in > > ./java.base/share/native/libzip/zip_util.c > ./java.base/share/native/libzip/zip_util.h > > and the header itself is only included in the .c file. So unless this > source file is used for the other libraries (which I don't see) then we > don't need -DUSE_MMAP when building them. > > AFAIKS the use of this for BUILD_LIBDT_SOCKET and >>> BUILD_LIBDT_SHMEM > dates back to the build-infra changes in JDK 8. > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9d3d01aca52c > > But I can't see why it was introduced there. > > In JDK 7 it's only applied to the zip library. > > Cheers, > David > - > >> >> /Magnus >> >>> >>> Lib-jdk.jdi.gmk : >>> >>> 32 $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SHMEM, \ >>> .. >>> 35 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP, \ >>> >>> >>> Lib-jdk.jdwp.agent.gmk : >>> >>> 30 $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>> .. >>> 33 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ >>> >>> >>> Any objections to remove those 2-DUSE_MMAPsettings ? >>> If it is fine to remove I would prepare a webrev . >>> >>> Thanks, Matthias >>
How to build hotspot jtreg test JNI with specific CFLAGS?
Hi, I'm trying to get a JNI library used for testing to be compiled with certain CFLAGS. In particular, I'm trying to get it compiled on a GCC platform with '-fomit-frame-pointer' and/or '-fomit-frame-pointer -O3'. The patch currently looks like this: diff --git a/make/test/JtregNativeHotspot.gmk b/make/test/JtregNativeHotspot.gmk --- a/make/test/JtregNativeHotspot.gmk +++ b/make/test/JtregNativeHotspot.gmk @@ -139,6 +139,13 @@ -I$(VM_TESTBASE_DIR)/nsk/share/native \ -I$(VM_TESTBASE_DIR)/nsk/share/jni +NO_FRAMEPOINTER_CFLAGS := +ifeq ($(OPENJDK_TARGET_OS),linux) + NO_FRAMEPOINTER_CFLAGS := -O3 -fomit-frame-pointer +endif + +BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libNoFramePointer := $(NO_FRAMEPOINTER_CFLAGS) + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libProcessUtils := $(VM_SHARE_INCLUDES) BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libThreadController := $(NSK_MONITORING_INCLUDES) When I look at the compile command line this produces with 'make run-test', I see this: $ cat ./build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.o.cmdline /usr/bin/gcc -I/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/modules_include/java.base -I/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/modules_include/java.base/linux -I/disk/openjdk/upstream-sources/openjdk-head/src/java.base/share/native/libjava -I/disk/openjdk/upstream-sources/openjdk-head/src/java.base/unix/native/libjava -I/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/share/include -I/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/os/posix/include -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DLINUX -DNDEBUG -Wall -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 -fno-strict-aliasing -m64 -D_LITTLE_ENDIAN -DARCH='"amd64"' -Damd64 -D_LP64=1 -fno-omit-frame-pointer -fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC -O3 -fomit-frame-pointer -g -O2 -DTHIS_FILE='""' -c -MMD -MF /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.d -o /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.o /disk/openjdk/upstream-sources/openjdk-head/test/hotspot/jtreg/serviceability/sa/libNoFramePointer.c The command line has '-O3 -fomit-frame-pointer -g -O2' in that order. This screws things up since -O2 seems to override -fomit-frame-pointer. My guess is that -O2 is from OPTIMIZATION == LOW, but not sure. How can I get this -O2 flag removed which apparently gets added later? Thanks, Severin
Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds
Looks good to me. On Fri, Aug 3, 2018 at 5:58 AM, Alan Bateman wrote: > > > On 03/08/2018 00:21, David Holmes wrote: > >> On 3/08/2018 4:59 PM, Baesken, Matthias wrote: >> >>> Thank you David , can the change be pushed , or do I need a second >>> review for an XS change ? >>> (any way a second review would be good ) >>> >> >> Need a review from official build team member :) >> > I'm not in the build group but just to confirm that USE_MMAP is specific > to libzip and dates back to when the entire zip file (not just the CEN) was > memory mapped. I don't know how it got into make file to build libjdwp or > libdt_socket. So the change looks right to me too. > > -Alan. >
Re: JNI Native - System (java.lang.System)
Yeah OK. SETEC ASTRONOMY.
From: David Holmes
Sent: Friday, August 3, 2018 9:03 AM
To: mr rupplin; build-dev@openjdk.java.net
Subject: Re: JNI Native - System (java.lang.System)
On 3/08/2018 10:49 PM, mr rupplin wrote:
> How would I subscribe to core-libs-dev?
The same way you subscribed to build-dev. ???
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
David
> Ok.
>
> *From:* David Holmes
> *Sent:* Thursday, August 2, 2018 11:55 PM
> *To:* mr rupplin; build-dev@openjdk.java.net
> *Subject:* Re: JNI Native - System (java.lang.System)
> Hi Max,
>
> The build-dev list is for discussing the OpenJDK build system. You
> appear to running into issues customizing parts of OpenJDK for your own
> use. It would be more appropriate to ask on core-libs-dev how to extend
> the System class - though examination of the existing native methods in
> System.java and System.c should show how it is done. There is not enough
> information in your post to see where you may have a made an error or
> omission.
>
> Cheers,
> David
>
> On 3/08/2018 12:53 PM, mr rupplin wrote:
>> Hello.
>>
>> Trying to run a simple JNI call and I keep getting the following:
>>
>> SecureJVM : GNU Public License 2.0
>> Program Name >> java
>> Launcher Name >> openjdk
>> Windows >> off
>> Version >> 9-internal+0-adhoc.mearvk.jdk9
>>
>> A new instance of Hope is born.
>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>> java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
>> at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
>> at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
>> at Hope.(Hope.java:19)
>>
>>
>> The source looks like:
>>
>> public static void setMemoryAllocationListener(MemoryAllocationListener
>> memoryAllocationListener) {
>> checkMalloc();
>> setMemoryAllocationListener0(memoryAllocationListener);
>> }
>>
>>
>> The C source looks like:
>>
>>
>> JNIEXPORT void JNICALL
>> Java_java_lang_System_setMemoryAllocationListener0(JNIEnv *env, jclass cla,
>> jobject listener)
>> {
>> printf("setMemoryAllocationListener called:\n");
>>
>> jfieldID fid =
>>
>> (*env)->GetStaticFieldID(env,cla,"memoryAllocationListener","Ljava/lang/memory/MemoryAllocationListener;");
>>
>> printf("\t >> Lookup of MemoryAllocationListener completed");
>>
>> if (fid == 0)
>> return;
>>
>>
>> (*env)->SetStaticObjectField(env,cla,fid,listener);
>>
>> printf("\t >> SetStaticObjectField completed");
>> }
>>
>>
>> I am unable to discern the problem. The make runs clean as does a
>> non-native call that instantiates a MemoryAllocationListener object.
>>
>> Can you guys spot the issue?
>>
>> Thanks,
>>
>> Max R.
>>
>> Sr. Software Tech
>>
Re: JNI Native - System (java.lang.System)
On 3/08/2018 10:49 PM, mr rupplin wrote:
How would I subscribe to core-libs-dev?
The same way you subscribed to build-dev. ???
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
David
Ok.
*From:* David Holmes
*Sent:* Thursday, August 2, 2018 11:55 PM
*To:* mr rupplin; build-dev@openjdk.java.net
*Subject:* Re: JNI Native - System (java.lang.System)
Hi Max,
The build-dev list is for discussing the OpenJDK build system. You
appear to running into issues customizing parts of OpenJDK for your own
use. It would be more appropriate to ask on core-libs-dev how to extend
the System class - though examination of the existing native methods in
System.java and System.c should show how it is done. There is not enough
information in your post to see where you may have a made an error or
omission.
Cheers,
David
On 3/08/2018 12:53 PM, mr rupplin wrote:
Hello.
Trying to run a simple JNI call and I keep getting the following:
SecureJVM : GNU Public License 2.0
Program Name >> java
Launcher Name >> openjdk
Windows >> off
Version >> 9-internal+0-adhoc.mearvk.jdk9
A new instance of Hope is born.
Exception in thread "main" java.lang.UnsatisfiedLinkError:
java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
at Hope.(Hope.java:19)
The source looks like:
public static void setMemoryAllocationListener(MemoryAllocationListener
memoryAllocationListener) {
checkMalloc();
setMemoryAllocationListener0(memoryAllocationListener);
}
The C source looks like:
JNIEXPORT void JNICALL
Java_java_lang_System_setMemoryAllocationListener0(JNIEnv *env, jclass cla,
jobject listener)
{
printf("setMemoryAllocationListener called:\n");
jfieldID fid =
(*env)->GetStaticFieldID(env,cla,"memoryAllocationListener","Ljava/lang/memory/MemoryAllocationListener;");
printf("\t >> Lookup of MemoryAllocationListener completed");
if (fid == 0)
return;
(*env)->SetStaticObjectField(env,cla,fid,listener);
printf("\t >> SetStaticObjectField completed");
}
I am unable to discern the problem. The make runs clean as does a non-native
call that instantiates a MemoryAllocationListener object.
Can you guys spot the issue?
Thanks,
Max R.
Sr. Software Tech
Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds
On 03/08/2018 00:21, David Holmes wrote: On 3/08/2018 4:59 PM, Baesken, Matthias wrote: Thank you David , can the change be pushed , or do I need a second review for an XS change ? (any way a second review would be good ) Need a review from official build team member :) I'm not in the build group but just to confirm that USE_MMAP is specific to libzip and dates back to when the entire zip file (not just the CEN) was memory mapped. I don't know how it got into make file to build libjdwp or libdt_socket. So the change looks right to me too. -Alan.
Re: JNI Native - System (java.lang.System)
How would I subscribe to core-libs-dev?
Ok.
From: David Holmes
Sent: Thursday, August 2, 2018 11:55 PM
To: mr rupplin; build-dev@openjdk.java.net
Subject: Re: JNI Native - System (java.lang.System)
Hi Max,
The build-dev list is for discussing the OpenJDK build system. You
appear to running into issues customizing parts of OpenJDK for your own
use. It would be more appropriate to ask on core-libs-dev how to extend
the System class - though examination of the existing native methods in
System.java and System.c should show how it is done. There is not enough
information in your post to see where you may have a made an error or
omission.
Cheers,
David
On 3/08/2018 12:53 PM, mr rupplin wrote:
> Hello.
>
> Trying to run a simple JNI call and I keep getting the following:
>
> SecureJVM : GNU Public License 2.0
> Program Name >> java
> Launcher Name >> openjdk
> Windows >> off
> Version >> 9-internal+0-adhoc.mearvk.jdk9
>
> A new instance of Hope is born.
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V
> at java.base/java.lang.System.setMemoryAllocationListener0(Native Method)
> at java.base/java.lang.System.setMemoryAllocationListener(System.java:261)
> at Hope.(Hope.java:19)
>
>
> The source looks like:
>
> public static void setMemoryAllocationListener(MemoryAllocationListener
> memoryAllocationListener) {
> checkMalloc();
> setMemoryAllocationListener0(memoryAllocationListener);
> }
>
>
> The C source looks like:
>
>
> JNIEXPORT void JNICALL
> Java_java_lang_System_setMemoryAllocationListener0(JNIEnv *env, jclass cla,
> jobject listener)
> {
> printf("setMemoryAllocationListener called:\n");
>
> jfieldID fid =
>
> (*env)->GetStaticFieldID(env,cla,"memoryAllocationListener","Ljava/lang/memory/MemoryAllocationListener;");
>
> printf("\t >> Lookup of MemoryAllocationListener completed");
>
> if (fid == 0)
> return;
>
>
> (*env)->SetStaticObjectField(env,cla,fid,listener);
>
> printf("\t >> SetStaticObjectField completed");
> }
>
>
> I am unable to discern the problem. The make runs clean as does a non-native
> call that instantiates a MemoryAllocationListener object.
>
> Can you guys spot the issue?
>
> Thanks,
>
> Max R.
>
> Sr. Software Tech
>
Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds
On 3/08/2018 4:59 PM, Baesken, Matthias wrote: Thank you David , can the change be pushed , or do I need a second review for an XS change ? (any way a second review would be good ) Need a review from official build team member :) Cheers, David Best regards, Matthias -Original Message- From: David Holmes Sent: Freitag, 3. August 2018 08:18 To: Baesken, Matthias ; Magnus Ihse Bursie Cc: build-dev@openjdk.java.net Subject: Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds Looks fine to me. Thanks, David On 3/08/2018 4:13 PM, Baesken, Matthias wrote: Hello, I can confirm what David said . Additionally I grepped through /usr/include on my Linux machine and did not find any USE_MMAP occurences. I created this webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8208744/ https://bugs.openjdk.java.net/browse/JDK-8208744 Please review ! Thanks, Matthias -Original Message- From: David Holmes Sent: Freitag, 3. August 2018 02:56 To: Magnus Ihse Bursie ; Baesken, Matthias Cc: build-dev@openjdk.java.net Subject: Re: unneeded -DUSE_MMAP in JDK native libs builds On 3/08/2018 3:44 AM, Magnus Ihse Bursie wrote: 2 aug. 2018 kl. 05:33 skrev Baesken, Matthias : Hello I noticed that -DUSE_MMAP is set for these JDK native libs, but I cannot find it in the code (for libzip it is different there the flag shows up in the code too ) : I've always assumed that this was used to control the behavior in some imported header files. Have you verified that this is not the case? It is only used in ./java.base/share/native/libzip/zip_util.c ./java.base/share/native/libzip/zip_util.h and the header itself is only included in the .c file. So unless this source file is used for the other libraries (which I don't see) then we don't need -DUSE_MMAP when building them. AFAIKS the use of this for BUILD_LIBDT_SOCKET and BUILD_LIBDT_SHMEM dates back to the build-infra changes in JDK 8. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9d3d01aca52c But I can't see why it was introduced there. In JDK 7 it's only applied to the zip library. Cheers, David - /Magnus Lib-jdk.jdi.gmk : 32 $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SHMEM, \ .. 35 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP, \ Lib-jdk.jdwp.agent.gmk : 30 $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ .. 33 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ Any objections to remove those 2-DUSE_MMAPsettings ? If it is fine to remove I would prepare a webrev . Thanks, Matthias
RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds
Hello, I can confirm what David said . Additionally I grepped through /usr/include on my Linux machine and did not find any USE_MMAP occurences. I created this webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8208744/ https://bugs.openjdk.java.net/browse/JDK-8208744 Please review ! Thanks, Matthias > -Original Message- > From: David Holmes > Sent: Freitag, 3. August 2018 02:56 > To: Magnus Ihse Bursie ; Baesken, > Matthias > Cc: build-dev@openjdk.java.net > Subject: Re: unneeded -DUSE_MMAP in JDK native libs builds > > On 3/08/2018 3:44 AM, Magnus Ihse Bursie wrote: > > > >> 2 aug. 2018 kl. 05:33 skrev Baesken, Matthias > : > >> > >> Hello I noticed that -DUSE_MMAP is set for these JDK native libs, but I > cannot find it in the code (for libzip it is different there the flag shows > up in > the code too ) : > > > > I've always assumed that this was used to control the behavior in some > imported header files. Have you verified that this is not the case? > > It is only used in > > ./java.base/share/native/libzip/zip_util.c > ./java.base/share/native/libzip/zip_util.h > > and the header itself is only included in the .c file. So unless this > source file is used for the other libraries (which I don't see) then we > don't need -DUSE_MMAP when building them. > > AFAIKS the use of this for BUILD_LIBDT_SOCKET and BUILD_LIBDT_SHMEM > dates back to the build-infra changes in JDK 8. > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9d3d01aca52c > > But I can't see why it was introduced there. > > In JDK 7 it's only applied to the zip library. > > Cheers, > David > - > > > > > /Magnus > > > >> > >> Lib-jdk.jdi.gmk : > >> > >> 32 $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SHMEM, \ > >> .. > >> 35 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP, \ > >> > >> > >> Lib-jdk.jdwp.agent.gmk : > >> > >> 30 $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ > >> .. > >> 33 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \ > >> > >> > >> Any objections to remove those 2-DUSE_MMAPsettings ? > >> If it is fine to remove I would prepare a webrev . > >> > >> Thanks, Matthias > >
