On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Tue, 8 Oct 2024 13:35:27 GMT, Magnus Ihse Bursie wrote:
>> Personally I think it is foolish to trust this compiler and rather than
>> dropping the optimisation level for the one file we've been lucky enough to
>> know has been compiled incorrectly, we should issue a fatal error if this
>> c
On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan wrote:
> While making `LogManager.checkAccess` be a no-op might be more convenient, it
> could unconditionally permit operations that formerly required a permission
> check: clearly a bad idea. Always throwing a `SecurityException` is the
> safest
On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs wrote:
>> This is a bit of forced move. Same thing with Thread.checkAccess and
>> ThreadGroup.checkAccess that also have to be re-specified to throw
>> unconditionally. They are called out in the CSR.
>
> OK
While I disagree with this change on th
On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote:
> Trivial change to drop the optimization level (for both fastdebug and
> release) of stackMapTable.cpp to O1 on MacOS with Xcode 16.
>
> This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which
> prevents building on Ma
On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote:
> Hi all,
> This PR delete tedious bool type define in
> `src/java.base/unix/native/libjsig/jsig.c` and
> `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP
> 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we
>
On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote:
> Hi all,
> This PR delete tedious bool type define in
> `src/java.base/unix/native/libjsig/jsig.c` and
> `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP
> 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we
>
On Tue, 3 Sep 2024 05:52:31 GMT, Magnus Ihse Bursie wrote:
>> This code is devoid of pretty much all error handling and logging, but I
>> agree that a simple fprintf on error would be useful.
>> Also doesn't a call like this trigger the warning about ignoring a function
>> result, or have we di
On Mon, 2 Sep 2024 22:32:34 GMT, Magnus Ihse Bursie wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744:
On Sun, 1 Sep 2024 16:30:33 GMT, Julian Waters wrote:
> This does make me wonder: What if the new method for checking if the VM was
> statically linked was inlined? Then the problem comes back yet again as the
> object files need to be recompiled once more. This is possible if Link Time
> Opti
On Fri, 30 Aug 2024 10:51:30 GMT, Magnus Ihse Bursie wrote:
>> I understand the cost overhead experienced by any individual Java run may be
>> lost in the noise, but it still impacts every single Java run just to save
>> some time/resources for the handful of builders of statically linked VMs.
On Mon, 12 Aug 2024 05:25:49 GMT, Kim Barrett wrote:
> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> produced by the gtest framework when such warnings are enabled.
>
> Warnings from the 3rd party GoogleTest are suppressed by disabling that
> warning when compili
On Mon, 5 Aug 2024 18:34:01 GMT, Leonid Mesnik wrote:
>> There jtreg tests have several additional problemlists
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it
>> makes sense to treat
On Mon, 5 Aug 2024 18:34:01 GMT, Leonid Mesnik wrote:
>> There jtreg tests have several additional problemlists
>> ProblemList-Xcomp.txt
>> ProblemList-generational-zgc.txt
>> ProblemList-zgc.txt
>> Each of them is bound to corresponding execution mode (Xcomp/ZGC) and it
>> makes sense to treat
immediately on startup? Otherwise there should be a
hs_err.log file created.
David
-
Thanks
X X64 (64-bit) Mac OS X 10.7 "Lion" XCode 4.5.2 or newer
There is also info here, but again likely out-of-date:
https://wiki.openjdk.org/display/Build/Supported+Build+Platforms
The folks on jdk8u-dev are the best source of current info.
David
-
Even less information was on Mac O
On Tue, 6 Aug 2024 22:02:33 GMT, Daniel D. Daugherty wrote:
> A trivial fix to remove EA from the JDK 23 version string with first RC
> promotion.
Good
-
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20481#pullrequestreview-314019
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were li
On Tue, 30 Jul 2024 08:36:25 GMT, Viktor Klang wrote:
>> WaitOnAddress is reported to spin before yielding. It might be related.
>
> @djelinski @dholmes-ora Couldn't it be that the producer thread is already
> scheduled, so it can reacquire the monitor whereas if the consumer was parked
> then
On Mon, 29 Jul 2024 06:04:52 GMT, Daniel Jeliński wrote:
> With the original code, the publisher thread was getting the monitor ~100x
> more often than the subscriber thread; with the new code, the publisher
> thread gets the monitor 2x more often than the subscriber thread.
Okay but still, b
On Tue, 16 Jul 2024 14:29:25 GMT, Nizar Benalla wrote:
> Can I please have a review for this bug fix? This regex to avoid duplicate
> "style" tags in our generated HTML, It can now match it even if the text
> contains a newline character.
>
> Thanks in advance!
Not a regex expert but this se
On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote:
> Can I please have a review for this bug fix to make file used to generate the
> OpenJDK documentation. It adds the missing `` tag after `OTHER
> SPECIFICATIONS`, this should help remove some HTML warnings in out generated
> docs.
>
> Th
On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote:
> Citing David Holmes from bug report:
> "We provided the ability to leave out certain VM services (JVMTI, GC's other
> than serial, ...) as part of the design of the MinimalVM to support Java SE
> Embedded,
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were li
On Wed, 26 Jun 2024 07:48:54 GMT, Daniel Jeliński wrote:
> the waiting thread wakes up, but still needs to compete with the notifying
> thread for the monitor.
No, a notified thread is moved from the wait-queue to the monitor-entry queue.
It is only unparked once the notifier thread releases
On Tue, 25 Jun 2024 18:23:18 GMT, Daniel Jeliński wrote:
> With the new implementation, it wakes up much more frequently,
Why? The number of unparks is unchanged. Are we seeing spurious unparks that
are consuming too much CPU?
-
PR Comment: https://git.openjdk.org/jdk/pull/19778
On Mon, 24 Jun 2024 14:34:37 GMT, Jan Kratochvil
wrote:
>> fastdebug:
>>
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>> pid=878152, tid=878158
>> # assert
On Mon, 24 Jun 2024 21:22:48 GMT, Ioi Lam wrote:
> More filtering is needed when building the default archive in the JDK:
> constant pool resolution when running the
> `build.tools.classlist.HelloClasslist` program is not deterministic (due to
> concurrency in core library classes). This could
On Mon, 24 Jun 2024 08:24:56 GMT, Jan Kratochvil
wrote:
> That's all.
That's somewhat of an understatement. :)
I'm still unclear how anything ASAN does gets examined by our assertion, but it
sounds to me like ASAN is just broken in this area. So I support Kim's
conclusion - lets just turn th
On Sun, 23 Jun 2024 09:35:07 GMT, Daniel Jeliński wrote:
> the GHA failure looks related, but I can't reproduce it locally. Will dig...
The failure in jdk/jshell/ToolTabSnippetTest.java? That test is somewhat flakey
- search JBS.
-
PR Comment: https://git.openjdk.org/jdk/pull/1977
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were li
On Sun, 23 Jun 2024 13:18:19 GMT, Jan Kratochvil
wrote:
>> fastdebug:
>>
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>> pid=878152, tid=878158
>> # assert
On Thu, 20 Jun 2024 05:58:16 GMT, Thomas Stuefe wrote:
>> Oh. That's interesting. 😞
>
> Of course pre-existing, but the typical pattern we use with RAII objects that
> may or may not do something is to give it a constructor argument, e.g. `bool
> activate`, that controls if it is activated.
On Sun, 23 Jun 2024 09:35:07 GMT, Daniel Jeliński wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update comment
>
> the GHA failure looks related, but I can't reproduce it locally. Will dig...
@djelinski why d
l flags so that
-XX:+UseSerialGC does not cause an error and the default GC would be
used instead.
Though as I put in the bug report I found a different error building the
tests when I tried to build without SerialGC.
David
-
best regards,
Julian
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live a
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live a
7 instead of jdk-16 as in the
instructions above.
If you are building mainline JDK then at this stage you need a JDK 22
boot JDK.
HTH.
David
thanks,
Anil
On Thu, 23 May 2024 16:33:14 GMT, Magnus Ihse Bursie wrote:
>> As seen in [JDK-8331541](https://bugs.openjdk.org/browse/JDK-8331541), if we
>> are not consistently setting all assembler directives correctly, we can get
>> errors that are not detected by the linker.
>>
>> We should stop duplica
DK-8180450: secondary_super_cache does not scale
well back on April 16. It should be in
#ifdef COMPILER2
as per ./hotspot/cpu/x86/stubGenerator_x86_64.cpp
Cheers,
David
Thanks,
- Johan
[1]
https://github.com/openjdk/jdk/commit/47377a2ad398eadd7acb8cccf1e95703c76
On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Fix another typo
>> - Fix typo
>> - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line 227
On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
library itself?
David
Best Regards,
Vladimir.
[1] https://github.com/vpa1977/linksample
On Tue, May 7, 2024 at 10:36 PM Magnus Ihse Bursie
wrote:
Undefined symbols in libjvm.so is no good, and it should not be allowed.
However, I am unsure about your analysis. This flag only affect linking
On Wed, 1 May 2024 14:46:14 GMT, SendaoYan wrote:
>> Hi,
>>
>> In doc/testing.md file, it says:
>>
>> As an example, :tier1 will expand to
>> jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1
>> jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1
>>
On Mon, 29 Apr 2024 16:14:45 GMT, SendaoYan wrote:
> Hi,
>
> In doc/testing.md file, it says:
>
> As an example, :tier1 will expand to jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1
> jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1
> jtreg:$(TOPDIR)/test/nashorn:tier1 jtreg:$(TO
On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy wrote:
>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Correct release date as observed in review feedback.
> - Improve javadoc of class file update.
LGTM
On Wed, 20 Mar 2024 16:17:36 GMT, Robbin Ehn wrote:
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY", so I removed it.
>
> Thanks, Robbi
On Tue, 12 Mar 2024 13:55:11 GMT, Magnus Ihse Bursie wrote:
>> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24:
>>
>>> 22: */
>>> 23:
>>> 24: #include
>>
>> Seems unneeded.
>
> So what I did here was change:
>
> #include "jni.h"
> #include
>
>
> into
>
> #include
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>> [JDK-8327045](https://bugs.openjdk
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
> https://github.com/openjdk/jdk/
On Tue, 5 Mar 2024 14:19:14 GMT, Erik Joelsson wrote:
> Does the release note also looks ok?
Yes.
> Is there any process to formally review release notes?
No. Typically just add a comment to the RN sub-task indicating it is okay. My
comment, that I had made some minor changes was meant as an
On Tue, 5 Mar 2024 07:12:09 GMT, Kim Barrett wrote:
>> Please review this change to update the HotSpot Style Guide's discussion of
>> nullptr and its use.
>>
>> I suggest this is an editorial rather than substantive change to the style
>> guide. As such, the normal HotSpot PR process can be use
On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson wrote:
>> Executables and dynamic libraries on Linux can encode a search path that the
>> dynamic linker will use when looking up library dependencies, generally
>> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature
>> to s
On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson wrote:
>> Executables and dynamic libraries on Linux can encode a search path that the
>> dynamic linker will use when looking up library dependencies, generally
>> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature
>> to s
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote:
> Executables and dynamic libraries on Linux can encode a search path that the
> dynamic linker will use when looking up library dependencies, generally
> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to
> set
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote:
> There is no supported usecase that I can think of for injecting other
> versions of such libraries in a JDK distribution.
I can imagine it could be used to allow "hot patching" of the installed
JDK/JRE. Whether anyone has ever needed to
On Wed, 28 Feb 2024 17:06:17 GMT, Magnus Ihse Bursie wrote:
>> We have seen a build failure along the lines of:
>>
>> /usr/bin/mv: cannot move
>> '.../build/windows-x64-open-debug/hotspot/variant-server/libjvm/win-exports.def.tmp'
>> to
>> '.../build/windows-x64-open-debug/hotspot/variant-se
On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie wrote:
>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
>> integrated, it is possible to do some cleanup. The goal of
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
>> any behavior,
On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie wrote:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, eve
On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie wrote:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, eve
On Thu, 22 Feb 2024 09:26:23 GMT, Magnus Ihse Bursie wrote:
> I tried to be clear, but apparently I failed: There is no change to these
> symbols in the patch! So everything should work just as before!
Yes but "should work" and "does work" may not be the same unless you have
actually verified
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
On Wed, 21 Feb 2024 23:32:58 GMT, Magnus Ihse Bursie wrote:
> it turned out that there were several symbols declared JNIEXPORT that were
> not included in the symbol list,
There appear to be two main categories of functions here:
1. Those intended for use from a debugger
Have you verified th
On Wed, 21 Feb 2024 00:59:18 GMT, David Holmes wrote:
> Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
>
> This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code
> signing failures on macOS.
>
> Thanks
This pull req
On Wed, 21 Feb 2024 01:12:40 GMT, Mikael Vidstedt wrote:
>> Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
>>
>> This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code
>> signing failures on macOS.
>>
>> Thanks
>
> Marked as reviewed by mikael (R
Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
This reverts commit 1bd91cdebee1e9ec78ecf185529923eef40ff89c due to code
signing failures on macOS.
Thanks
-
Commit messages:
- Revert "8325963: Clean up NativeCompilation.gmk and its newly created parts"
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#impo
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote:
> I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and
the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are
to provide consistent output across platforms. "%p" provides implementation
defined out
On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett wrote:
> I consider the "format '%p' expects argument of type 'void*" warnings to be
> not at all helpful. Fortunately we don't use '%p' in HotSpot,
We do use it in hotspot. Not a huge amount as we have the legacy format
specifiers for PTR_FORMAT et
On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon wrote:
> You need to check if class is already loaded by trying findLoadedClass first.
Thanks @xxDark . I knew it should work. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908961416
On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon wrote:
> As far as I understand, even a non-delegating classloader cannot redefine a
> class loaded by the boot loader. I modified the test to show this and get:
>
> ```
> java.lang.LinkageError: loader LoadAlternativeJVMCI$1 @4a1f4d08 attempted
> d
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Wed, 24 Jan 2024 08:46:08 GMT, Doug Simon wrote:
>> test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 54:
>>
>>> 52:
>>> 53: ClassLoader pcl = ClassLoader.getPlatformClassLoader();
>>> 54: URLClassLoader ucl = new URLClassLoader(cp, null);
>>
>> I am missing s
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote:
>> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform
>> class loader instead of the boot class loader. This allows Native Image to
>> load a version of JVMCI different than the version on top of which Native
>> Image
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Fri, 19 Jan 2024 06:08:21 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Sat, 16 Dec 2023 06:38:38 GMT, Sam James wrote:
> My preference for moving forward is:
>
> 1. I add some static_assert for off_t to the modified JVM bits to be safe
> (that's what I tested with);
> 2. We keep this PR for the build-only fixes which are semantically identical
> to the previo
On Wed, 10 Jan 2024 01:58:33 GMT, Kim Barrett wrote:
> Please review this change to enable -Wparentheses when building HotSpot. That
> warning is enabled by -Wall (which we use). That was overridden by explicitly
> disabling it, because there were a number of places in HotSpot code that
> trigger
On Mon, 8 Jan 2024 20:16:47 GMT, Mikael Vidstedt wrote:
> We run dsymutils on the libraries (e.g. `libjvm.dylib`) to extract the debug
> symbols.
So how does it know about empty files??? Does an empty src file create an empty
object file which in turns creates an empty section in the library?
On Fri, 5 Jan 2024 21:05:49 GMT, Mikael Vidstedt wrote:
> When building on macOS, dsymutil generates a warning for some files:
>
> `warning: no debug symbols in executable (-arch x86_64)`
>
> It turns out that the files in question have one thing in common: they're
> empty. Specifically, the s
On Fri, 5 Jan 2024 21:05:49 GMT, Mikael Vidstedt wrote:
> When building on macOS, dsymutil generates a warning for some files:
>
> `warning: no debug symbols in executable (-arch x86_64)`
>
> It turns out that the files in question have one thing in common: they're
> empty. Specifically, the s
On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt wrote:
> The libinstrument library is linked against libjava and libjvm, twice. This
> is mostly harmless but Xcode 15.x generates a warning:
>
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12
> file(s)
> ld: warning:
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> counterparts and de
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> counterparts and de
On Wed, 29 Nov 2023 13:26:58 GMT, serge-sans-paille wrote:
>> I take it he is not an Intel employee, in which case he has to be an OpenJDK
>> contributor himself for code for which he holds a copyright to be
>> contributed to OpenJDK. @robilad please correct me if I am wrong here.
>
> hey o/ No
On Tue, 21 Nov 2023 15:14:28 GMT, Dalibor Topic wrote:
>> src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved.
>>> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved.
>>
>> Is th
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Hotspot change is trivially fine, but too insignificant to hit the Approve
button.
Thanks
-
PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1752152672
On Mon, 27 Nov 2023 23:44:25 GMT, Sandhya Viswanathan
wrote:
>> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors
>
> Yes, Vamsi is part of Intel Java team. He also has the author status
> (https://openjdk.org/census#sparasa).
@sviswa7 I am asking about the copyright holder
On Wed, 22 Nov 2023 15:00:29 GMT, Stefan Karlsson wrote:
> In the rewrites made for:
> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>
> I removed the filtering of *owned ObjectMonitors with dead objects*
On Wed, 22 Nov 2023 15:00:29 GMT, Stefan Karlsson wrote:
> Previously, the locked monitors never got unlocked because the ObjectMonitor
> iterator never exposed these monitors to the JNI detach code
I had not realized that. It explains some confusion in a separate issue I had
been looking in
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 7 Nov 2023 00:12:41 GMT, Srinivas Vamsi Parasa wrote:
> The goal is to develop faster sort routines for x86_64 CPUs by taking
> advantage of AVX2 instructions. This enhancement provides an order of
> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>
> For
On Wed, 15 Nov 2023 22:05:47 GMT, Srinivas Vamsi Parasa
wrote:
>> make/modules/java.base/Lib.gmk line 245:
>>
>>> 243: TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
>>> 244: OPTIMIZATION := HIGH, \
>>> 245: CFLAGS := $(CFLAGS_JDKLIB) -std=c++17, \
>>
>> This makes me uneasy. We do not i
On Wed, 15 Nov 2023 01:32:00 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X
On Wed, 15 Nov 2023 01:32:00 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X
On Mon, 13 Nov 2023 07:46:37 GMT, Jorn Vernee wrote:
>>> For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()`
>>> returns a `SymbolLookup` that can be used to find symbols from the standard
>>> library.
>>>
>>> We use a shim library that re-exports symbols from the stand
On Mon, 13 Nov 2023 17:55:12 GMT, Mikael Vidstedt wrote:
>> Oracle is updating the version of GCC for building the JDK on Linux to
>> 13.2.0.
>>
>> Apart from the "obvious" changes, I'll add some color to the CompileJvm.gmk
>> changes. In particular, I ran into two different types of new warni
an this up
> further if desired.
>
> Testing:
> - All Oracle tiers 1-5 builds (which includes an ARMv7 build)
> - GHA builds/tests
> - Oracle tiers 1-3 sanity testing
>
> Zero changes coming in via
> [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) wi
1 - 100 of 409 matches
Mail list logo
