RFR: 8245832 - JDK build make-static-libs should build all JDK libraries

Please review this change that alters the make target “make-static-libs” to produce static libraries for ALL native libraries in the JDK. Prior to this fix we only built a small select list. Note: I had to change the functions JAWT_GetAWT for all platforms to match the prototype which used

Re: cross-compile JDK 14 with arm-linux-gnueabihf target

Is the ARM compiler on your path? I use the —with-devkit configure option to point to the compiler. Bob. > On Apr 20, 2020, at 5:04 PM, Choe, Jiwon wrote: > > Hello all, > > I'm trying to cross-compile OpenJDK 14 to target arm-linux-gnueabihf, and > the build is failing for me with these

Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

> On Feb 27, 2020, at 9:59 AM, Magnus Ihse Bursie > wrote: > > On 2020-02-27 15:52, Bob Vandette wrote: >> >>> On Feb 27, 2020, at 7:15 AM, Magnus Ihse Bursie >>> >>> wrote: >>> >>> On 2020-02-26 22:01, Bob Vand

Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

> On Feb 27, 2020, at 7:15 AM, Magnus Ihse Bursie > wrote: > > On 2020-02-26 22:01, Bob Vandette wrote: >> Here’s an updated webrev that implementes the suggestion that allows >> JNIEXPORT in jni.h to be overridden >> and the build limits v

Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

.01 <http://cr.openjdk.java.net/~bobv/8239563/webrev.01> Bob. > On Feb 26, 2020, at 10:35 AM, Magnus Ihse Bursie > wrote: > > On 2020-02-26 15:56, Bob Vandette wrote: >> >>> On Feb 26, 2020, at 9:17 AM, Magnus Ihse Bursie >>> wrote: >&g

Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

> On Feb 26, 2020, at 9:17 AM, Magnus Ihse Bursie > wrote: > > On 2020-02-26 14:31, Bob Vandette wrote: >> >>> On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie >>> wrote: >>> >>> On 2020-02-26 08:41, David Holmes wrote: >>>

Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

> On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie > wrote: > > On 2020-02-26 08:41, David Holmes wrote: >> Hi Bob, >> >> Adding build-dev. > Thanks for noticing that we were missing, David! Sorry, I should have included you folks. > >> &g

Re: Is anyone still building multiple JVMs?

Keep in mind that any change here will have an impact on the jlink option that allows for the selection of JVM. Jlink Plugin Name: vm Option: --vm= Description: Select the HotSpot VM in the output image. Default is all Bob. > On Feb 20, 2020, at 10:04 AM, Magnus Ihse Bursie > wrote: > >

Re: RFR: 8236921: Add build target to produce a JDK image suitable for a Graal/SVM build

> On Jan 13, 2020, at 3:42 AM, Severin Gehwolf wrote: > > On Fri, 2020-01-10 at 13:19 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> Looks good. > > Thanks for the review, Erik! > >> /Erik >> >> On 2020-01-10 09:28, Bob Vandette

Re: RFR: 8236921: Add build target to produce a JDK image suitable for a Graal/SVM build

I like it! I have to manually copy the libs each time. BTW: I have a PR in our internal queue to update the graal repo so it can build with the latest JDK 14. Bob. > On Jan 10, 2020, at 10:45 AM, Severin Gehwolf wrote: > > Hi, > > Currently there is no easy way to produce an OpenJDK

Re: native debug symbols support on Windows

enerate-debug-info?view=vs-2019 > [1] > https://docs.microsoft.com/en-us/cpp/build/reference/pdb-use-program-database?view=vs-2019 > >> -Original Message- >> From: Erik Joelsson >> Sent: Mittwoch, 4. Dezember 2019 15:46 >> To: Bob Vandette >> Cc: Lang

Re: native debug symbols support on Windows

There seems to be an option that will include debug information in generated .obj files. Assuming this option is supported in the versions of Visual Studio we use, it could be used to implement “internal” native debug symbols. /Z7 The /Z7 option produces object files that also contain full

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

> On Oct 23, 2019, at 3:07 PM, mark.reinh...@oracle.com wrote: > > 2019/10/22 15:36:28 -0700, mark.reinh...@oracle.com: >> 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: 2019/10/22 10:31:55 -0700,

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

Hotspot changes look good to me. Bob. > On Oct 22, 2019, at 6:36 PM, mark.reinh...@oracle.com wrote: > > 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: In

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: > > 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: >> In arguments.cpp, could you use a new JVMFlag to declare options that came >> from this resource as RESOURCE? >> >> - jint result =

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

In arguments.cpp, could you use a new JVMFlag to declare options that came from this resource as RESOURCE? - jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, JVMFlag::INTERNAL); + jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, JVMFlag::RESOURCE); This

Re: [PATCH] Windows 32-bit DLL name decoration

Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad functions. Perhaps you should just follow the same procedure for the debug library. #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad@8", "JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload@8", "JNI_OnUnload"}

RFR: 8209093 - JEP 340: One AArch64 Port, Not Two

This JEP is now targeted to JDK 12. I’ve merged up to the latest sources and will be integrating these changes in the next day or two. Here’s the latest webrev post merge in the event anyone spots any last minute issues. http://cr.openjdk.java.net/~bobv/8209093/webrev.02

Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two

these other configurations. The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Bob. > On Sep 17, 2018, at 10:53 PM, David Holmes wrote: > > Hi Bob, > > On 18/09/2018 2:20 AM, Bob Vandette wrote: >> Please review the changes rel

Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two

Thanks for the detailed review Aleksey. I took care of these. Bob. > On Sep 17, 2018, at 1:49 PM, Aleksey Shipilev wrote: > > On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >> On 9/17/18 9:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340

Re: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two

> On Aug 27, 2018, at 2:30 AM, Magnus Ihse Bursie > wrote: > > On 2018-08-23 17:13, Bob Vandette wrote: >> As a follow-on to the previous thread "ARM port consolidation” [1], >> please review and comment on this newly filed JEP that removes >> one of

Re: RFR: JDK-8200132: Remove jre images and bundles

> On Jun 4, 2018, at 4:32 PM, Jonathan Gibbons > wrote: > > > > On 06/02/2018 12:20 AM, Alan Bateman wrote: >> On 02/06/2018 08:05, Aleksey Shipilev wrote: >>> : >>> Unfortunately, in the age of containers, distribution size matters. It >>> makes the whole sense to ship >>> JRE in Docker

Re: RFR: JDK-8200132: Remove jre images and bundles

If we do this, shouldn’t we provide an aggregator module to allow developers to easily create a Java runtime with the same list of modules? AFAIK, this doesn’t exists. The java.se module is not the same. It’s missing many modules. Bob. > On Jun 2, 2018, at 1:01 PM, Alan

Re: Execution problems with Atomic Operations on OpenJDK10 for ARM5 Soft Float

I believe the problem is that the VM is now using more atomic load/store of java longs and we don’t support these operations on multi-processing ARMv5 systems due to the lack of low level atomic instructions. On non MP ARMv5 systems, we use load/store multiple instructions. If you can

Re: Building OpenJDK9 on MSYS2

tear-down > [==] 346 tests from 54 test cases ran. (3859 ms total) > [ PASSED ] 346 tests. > > What is the best way to test the current build more thoroughly? > > P. > > From: Bob Vandette <mailto:bob.vande...@oracle.com> > Sent: Tuesday, Octobe

Re: Building OpenJDK9 on MSYS2

coming later in the VM_Version::get_processor_features() > function > > Peter > > From: Bob Vandette <mailto:bob.vande...@oracle.com> > Sent: Tuesday, October 24, 2017 6:28 PM > To: Peter Budai <mailto:peterbu...@hotmail.com> > Cc: David Holmes <mailto:david.hol...@or

Re: Building OpenJDK9 on MSYS2

Was this a SEGV while you were running the debugger? There is an intentional SEGV generated. This is used to determine if we can use some of newer CPU features. Try to allow the SEGV to continue to see if you run normally. Bob. > On Oct 24, 2017, at 11:37 AM, Peter Budai

Re: RFR: JDK-8186115 - libelf still referenced after 8172670

classes. We need to have > dependency on it in suite.py. > > Thanks, > Vladimir > > On 8/15/17 12:10 PM, Vladimir Kozlov wrote: >> On 8/15/17 11:55 AM, Bob Vandette wrote: >>> Please review these changes for JDK 10 that remove all dependencies on >>> libelf from the

RFR: JDK-8186115 - libelf still referenced after 8172670

Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK build system. Bug: https://bugs.openjdk.java.net/browse/JDK-8186115 Webrev: http://cr.openjdk.java.net/~bobv/8186115/ Compiler team: Please check

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

> On Apr 4, 2017, at 12:35 PM, mark.reinh...@oracle.com wrote: > > 2017/4/4 8:22:50 -0700, a...@redhat.com: >> On 04/04/17 16:12, mark.reinh...@oracle.com wrote: >>> The trouble here is that "arm64" and "aarch64" are effectively synonyms >>> for the ISA, but in the JDK we've wound up using them

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

> On Apr 4, 2017, at 11:12 AM, mark.reinh...@oracle.com wrote: > > 2017/4/4 1:04:22 -0700, magnus.ihse.bur...@oracle.com: >> On 2017-04-03 23:50, Mandy Chung wrote: >>> ... >>> >>> JDK 8 JDK 9 >>> - - >>> OS_NAMELinux

Re: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so

I just cloned the latest http://hg.openjdk.java.net/jdk9/dev and was able to successfully build OpenJDK with the minimalvm. Here’s my configure script. /export/users/bobv/jdk9devopenonly/configure --enable-option-checking=fatal --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabihf

FR: 8174203: Enable AOT Jtreg tests on Windows x86_64

Please review this change for JDK 10, that enables jtreg testing of Hotspot AOT support on Windows. This change also includes some fixes that allow JPRT to be able to run these tests. Thanks to Erik Joelsson for providing the JPRT support. CR: https://bugs.openjdk.java.net/browse/JDK-8174203

Fwd: libjvm.so, jmods and --with-native-debug-symbols=internal

My assumption is that this was intentional. Forwarding to the jigsaw team for clarification. The native libraries associated with java.base are needed in the jmod file in order to allow developers to run jlink to produce custom Java runtimes. So, independent of having debug information,

RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too)

SUMMARY: Please review the following set of changes that adds Ahead-of-time compilation support for Mac OSX and Windows x64 in JDK 10. Linux and Solaris x64 AOT support has also been updated to be consistent with the new 100% Java based binary container support included in this changeset.

JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master

I am please to announce that the source changes for JEP 297: Unified arm32/arm64 Port have now been integrated into the JDK 9 Master forest (http://hg.openjdk.java.net/jdk9/jdk9). JEP URL:http://openjdk.java.net/jeps/297 This means that we made feature complete cutoff and JDK 9 will now

Re: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port

Thanks Magnus, see comments below .. > On Dec 7, 2016, at 3:44 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > On 2016-12-05 16:23, Bob Vandette wrote: >>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov <vladimir.koz...@oracle.com> >&

Re: RFR: 8168503 JEP 297: Unified arm32/arm64 Port

sters derived from the structure in user.h. Bob. > > I saw Hotspot changes before and I think they are fine (did not dive deep). > > Thanks, > Vladimir > > On 12/2/16 12:28 PM, Bob Vandette wrote: >> Please review the proposed changes to be integrated under JEP 297

Re: RFR: JDK-8164120: The minimal VM should be stripped using --strip-unneeded

The change looks good to me. Bob. > On Oct 3, 2016, at 9:52 AM, Erik Joelsson wrote: > > Hello, > > Please review this small change, which adds --strip-unneeded when stripping > the minimal VM on Linux, which reduces size on x86 builds with around 1.2MB. > > Bug:

Re: RFR: 8148302: Initial Bringup of Android in mobile/dev

> On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > On 2016-01-26 20:50, Bob Vandette wrote: >> Please review the changes for two improvements for the Mobile Dev Forest. >> >> With these changes, the mobile/d

Re: RFR: 8148302: Initial Bringup of Android in mobile/dev

to be fully controlled by —disable-headful. This shouldn’t impact our ARMv8 build since we set both —disable-headful and BUILD_HEADLESS_ONLY. Thanks, Bob. > On Jan 27, 2016, at 4:56 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@oracle.com> wrote: > > On 2016-01-26 20:50,

RFR: 8148302: Initial Bringup of Android in mobile/dev

Please review the changes for two improvements for the Mobile Dev Forest. With these changes, the mobile/dev forest can successfully build x86 and ARM Android JDK 9 binaries. The ARM binaries use the Zero ARM interpreter while the x86 implementation uses standard x86 Hotspot VMs. The webrev

RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE

the entire MacOSXFileSystemProvider set of classes. Currently the default provider for iOS is Bsd. Bob Vandette

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

at this may be interesting to hotspot-runtime, because the > changes to the OS layer are somewhat extensive, so I'll take the freedom and > put them on the recipient list. > > Kind regards, Thomas > > On Dec 18, 2015 22:16, "Bob Vandette" <bob.vande...@oracle.com &g

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

I caught that and gave Gary an updated set of os_linux* files that hopefully corrected this. Here’s the updated changes that Gary just pushed today. http://hg.openjdk.java.net/mobile/dev/hotspot/rev/f1acc8fa34b8 Bob. > On Dec 18, 2015, at 4:11 PM, Thomas Stüfe

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

1. In make/bsd/makefiles/vm.make You commented out the libffi logic that we’ll need to Zero iOS ARM. I guess we could uncomment this with the push to add this support. 2. hotspot/src/share/vm/runtime/java.cpp You shouldn’t need this change. dll_lookup does the right thing for static builds

RFR: 8140396 - BUILD_LIBJIMAGE missing as a dependency to JAVA_BASE_EXPORT_SYMBOLS_SRC

Please review this 1 line change to add a missing library dependency from the recent addition of static build support. The new libjimage support was brought into my forest during the merge before I pushed this feature and I missed this dependency. Thanks to Magnus for catching this.

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

> On Oct 16, 2015, at 1:01 PM, Naoto Sato <naoto.s...@oracle.com> wrote: > > Hi Bob, Alan, > > On 10/16/15 8:11 AM, Bob Vandette wrote: >>> I've skimmed through the patches and the DEF_* macros look okay. The only >>> one that doesn't look right

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

> On Oct 16, 2015, at 2:28 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 15/10/2015 19:07, Bob Vandette wrote: >> Please review this JDK 9 enhancement which allows a completely static build >> of the JDK for MacOSX x64 platforms. >> >> h

RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

Resending after joining mailing list … Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. https://bugs.openjdk.java.net/browse/JDK-8136556 The change involves: 1. Producing “.a”