On Tue, 11 Jun 2024 19:02:29 GMT, Alexandre Iline
wrote:
> Update JCov for class file version 68
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19665#pullrequestreview-2111285609
On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix default description of keep-packaged-modules
>
> I've read through all src chan
On Thu, 6 Jun 2024 09:47:30 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 4 Jun 2024 14:39:23 GMT, Severin Gehwolf wrote:
> I've added a couple of `@requires jlink.packagedModules` (new with this
> patch) so that jlink tests don't start to fail with it.
Good, the `@requires jlink.packagedModules` make sense.
-
PR Comment:
On Tue, 4 Jun 2024 16:23:19 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Mon, 3 Jun 2024 15:40:10 GMT, Severin Gehwolf wrote:
> Does that proposal sound good?
That table is useful, I think it's right. No change to default behavior. If
someone configures with --enable-runtime-image then they get a JDK run-time
image that supports jlink (with some limitations)
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 110 commits:
>>
>> - Merge branch 'master' into jdk-8311302-jmodless
On Wed, 22 May 2024 13:23:25 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 24 May 2024 05:26:40 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 23 May 2024 16:42:39 GMT, Severin Gehwolf wrote:
> Do you think you'll be able to review this next week?
Yes, I want to help you get this one over the line.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2127828050
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Mon, 20 May 2024 12:48:01 GMT, Sean Mullan wrote:
>> Joe Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> withdraw changes to jaxp.properties. The configuration process has not
>> changed, changing the default configuration
On Sun, 19 May 2024 05:01:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 12:23:44 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
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from
On Thu, 16 May 2024 12:23:44 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
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review
On Wed, 15 May 2024 10:40:34 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
On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore
wrote:
> I don't fully agree that this option is not module related (which is why I
> gave it that name). The very definition of illegal native access is related
> to native access occurring from a module that is outside a specific set. So
On Wed, 15 May 2024 00:54:43 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/arguments.cpp line 2271:
>>
>>> 2269: } else if (match_option(option, "--illegal-native-access=",
>>> )) {
>>> 2270: if (!create_module_property("jdk.module.illegal.native.access",
>>> tail,
On Mon, 13 May 2024 11:47:38 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
On Tue, 16 Apr 2024 11:59:12 GMT, Severin Gehwolf wrote:
> If I understand you correctly, this would be no longer a build-time only
> approach to produce the "linkable runtime"? It would be some-kind of
> jlink-option driven approach (as it would run some code that should only run
> when
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtime link supporting classes in package
>>
On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski wrote:
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
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
>>
On Wed, 6 Mar 2024 12:14:10 GMT, Magnus Ihse Bursie wrote:
> * `test/jdk/java/lang/Thread/jni/AttachCurrentThread/libImplicitAttach.c` was
> missing an export. This had not been discovered before since that file was
> not compiled on Windows.
It's a Linux/macOS specific test so it wasn't
On Fri, 8 Mar 2024 16:47:33 GMT, Magnus Ihse Bursie wrote:
> What is the rationale for introducing a special configure flag for this
> functionality? I've tried to look though all comments in this PR, and read
> the JBS issue and CSR, but I have not found any motivation for this. I'm
> sorry
On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda wrote:
>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line
>> 812:
>>
>>> 810: }
>>> 811:
>>> 812: private static void addEnableNativeAccess(ModuleLayer layer,
>>> Set moduleNames, boolean shouldWarn) {
>>
>> The
On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung wrote:
> Native access is needed for modules which calls restricted methods [1].
In time, we'll need it for modules using JNI too. We can do this trimming in
another PR to avoid Jan getting pulled into deeply.
-
PR Review Comment:
On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung wrote:
> Many of these modules do not need native access in the current implementation.
In addition this will eventually need jlink support. I view the change to
ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as
very
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai wrote:
> to make the intention clear as well as reduce the chances of missing some
> boot or platform module in this NATIVE_ACCESS_MODULES?
The list to be be granted native access is a subset, it shouldn't be granted
all modules mapped to the boot
On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote:
> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
> `COMPAT` locale data was introduced for applications' migratory purposes
> transitioning to `CLDR`. It is becoming a technical debt and now is the time
> to
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with
On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon wrote:
> You're right. I had forgotten the intricacies of class loader delegation. The
> only hard constraint on loading a class in multiple loaders is that `java.*`
> classes [must (only) be loaded by the boot
>
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
>>
On Sat, 20 Jan 2024 07:34:34 GMT, Alan Bateman wrote:
>> Sam James has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven
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
>
> The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023
> and was reviewed by Leonid Mesnik and Alan Bateman.
>
> Thanks!
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/23#pullrequestreview-1812613022
On Fri, 8 Dec 2023 22:42:42 GMT, Alexandre Iline wrote:
> JCov support for byte code version 67.
Happy to see this being changed soon after the fork.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17041#pullrequestreview-1773616082
On Fri, 8 Dec 2023 11:54:40 GMT, Serguei Spitsyn wrote:
>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
>> time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical
>> sections with the `interruptLock` (in methods: `unpark()`,
On Sun, 3 Dec 2023 16:31:13 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> please help review this enhancement to add a JFR event to report runtime
>> invocations of methods that have been declared deprecated in the JDK.
>>
>> Testing: jdk_jfr, CI 1-6, stress testing
>>
>> Thanks
>> Markus
On Sat, 2 Dec 2023 17:20:58 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> please help review this enhancement to add a JFR event to report runtime
>> invocations of methods that have been declared deprecated in the JDK.
>>
>> Testing: jdk_jfr, CI 1-6, stress testing
>>
>> Thanks
>> Markus
On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy wrote:
>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update symbol files to JDK 22 b26.
Good good. I assume you'll bump the
On Fri, 24 Nov 2023 12:04:01 GMT, Daniel Jeliński wrote:
> Yes, with `/mA` the command exits as soon as the dump is completed. I
> couldn't find a way to make `cdb` not enter interactive mode on unrecognized
> parameter, so I left that part as is.
Okay, maybe it can be figured out another
On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeliński wrote:
>> The recent cdb versions do not support `.dump /f`:
>>
>> *
>> * .dump /f is not supported on a user mode process. *
>> *
On Fri, 24 Nov 2023 11:33:57 GMT, Daniel Jeliński wrote:
> It's ignoring the rest of the command line after `/f`, which means it ignores
> the `;qd` (quit and detach) part and enters the interactive mode.
Wonderful :-)Does switching to `/mA` change that?
-
PR Review Comment:
On Fri, 24 Nov 2023 09:40:16 GMT, Daniel Jeliński wrote:
>>> Notice the absence of "params" part in that key. I wonder if that is
>>> playing a role here and whether we should fix this key.
>>
>> Actually ignore that part. I had a look at the internal logs that you
>> referenced. It appears
On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeliński wrote:
> The recent cdb versions do not support `.dump /f`:
>
> *
> * .dump /f is not supported on a user mode process. *
> *
On Mon, 20 Nov 2023 17:46:53 GMT, Joe Wang wrote:
>> Implement the built-in Catalog.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add a note; fix alignment
I'm happy with the addition of the JDK built-in catalog, the
On Fri, 17 Nov 2023 20:22:40 GMT, Joe Wang wrote:
> Implement the built-in Catalog.
src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/JDKCatalog.xml line 34:
> 32:
> 33: http://java.sun.com/dtd/preferences.dtd;
> uri="J2SE/preferences.dtd"/>
> 34:
On Sun, 19 Nov 2023 08:44:01 GMT, Alan Bateman wrote:
>> Implement the built-in Catalog.
>
> src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/JDKCatalog.xml line 34:
>
>> 32:
>> 33: http://java.sun.com/dtd/preferences.dtd;
>> uri="J2SE/
On Fri, 10 Nov 2023 16:30:35 GMT, suchismith1993 wrote:
> There is not generic way of generating this. It needs a manual intervention
> and symbols are to be added on a need basis in future. Looks like a list to
> be maintained. I had tried adding comments to explain the list, but that
>
On Wed, 20 Apr 2022 14:30:21 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Could I get the following PR review please? It adds a new JDK specific
>> extended socket option
>> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
>> and IPv6
>> UDP sockets (NIO
On Tue, 31 Oct 2023 16:11:47 GMT, Joe Darcy wrote:
>> Clarify the intention of tier 1 tests. I'll reflow the paragraph and
>> regenerate the HTML file once the wording is agreed upon.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
On Thu, 2 Nov 2023 16:19:35 GMT, Mandy Chung wrote:
>> Tool modules can be created via `jmod --main-class` option such that
>> `ModuleMainClass` attribute will be added in `module-info.class` and the
>> module's main class can be launched via `java -m ` without
>> specifying the name of the
On Wed, 1 Nov 2023 19:58:07 GMT, Mandy Chung wrote:
> Tool modules can be created via `jmod --main-class` option such that
> `ModuleMainClass` attribute will be added in `module-info.class` and the
> module's main class can be launched via `java -m ` without
> specifying the name of the main
On Tue, 31 Oct 2023 00:23:44 GMT, Joe Darcy wrote:
>> Clarify the intention of tier 1 tests. I'll reflow the paragraph and
>> regenerate the HTML file once the wording is agreed upon.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
On Sat, 28 Oct 2023 21:03:50 GMT, Joe Darcy wrote:
> So in terms of a sentence or two of guidance, I think "aim for 10 seconds or
> less almost all of the time for a tier 1 test" is reasonable in this context.
Yes, I think making it an aspiration would be better.
In passing, you have
On Thu, 26 Oct 2023 19:38:55 GMT, Joe Darcy wrote:
>> Clarify the intention of tier 1 tests. I'll reflow the paragraph and
>> regenerate the HTML file once the wording is agreed upon.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to the way Java modules work,
On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to the way Java modules work,
On Wed, 27 Sep 2023 16:50:33 GMT, Jorn Vernee wrote:
>> This patch contains the implementation of the foreign linker & memory API
>> JEP for Java 22. The initial patch is composed of commits brought over
>> directly from the [panama-foreign
>> repo](https://github.com/openjdk/panama-foreign).
On Wed, 27 Sep 2023 16:12:46 GMT, Jorn Vernee wrote:
> Side note: I don't believe I have to add all the different error message
> translations right? Only the English version?
That's right, the translations will be updated towards the end of the release.
-
PR Review Comment:
On Wed, 27 Sep 2023 00:53:25 GMT, Jorn Vernee wrote:
>> This patch contains the implementation of the foreign linker & memory API
>> JEP for Java 22. The initial patch is composed of commits brought over
>> directly from the [panama-foreign
>> repo](https://github.com/openjdk/panama-foreign).
On Wed, 27 Sep 2023 00:53:25 GMT, Jorn Vernee wrote:
>> This patch contains the implementation of the foreign linker & memory API
>> JEP for Java 22. The initial patch is composed of commits brought over
>> directly from the [panama-foreign
>> repo](https://github.com/openjdk/panama-foreign).
On Tue, 5 Sep 2023 07:53:36 GMT, Afshin Zafari wrote:
> A new benchmark for measuring the NMT overhead in `summary` and `detail`
> modes.
> The tests are run using:
>
> make CONF=debug test TEST="micro:java.util.NMTBenchmark"
> MICRO="RESULTS_FORMAT=json"
>
> The results are written to a
On Wed, 20 Sep 2023 11:21:51 GMT, Daniel Fuchs wrote:
> Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?
I don't think so as these tests are just used to check that changes haven't
broken anything.
-
PR Comment:
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
>>> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
>>> https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event
>>> generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking,
>>> event
On Mon, 18 Sep 2023 17:30:25 GMT, Daniel Jeliński wrote:
> WinHTTP functions are only used when an application:
> - uses DefaultProxySelector to resolve proxies, and
> - is run with -Djava.net.useSystemProxies=true
>
> In all other cases, loading winhttp.dll is a waste of resources.
>
>
On Thu, 31 Aug 2023 21:31:40 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX512 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
> I think it's useful if trying to trace the calls (i.e. set to 0ms).
> Apparently the security manager was being used for that by some.
The SM isn't called once connected so I don't think anyone could have every
done that. Yes, you could
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote:
> One has to wonder about the `**/*_OLD.java` files, but that would be a
> different cleanup
The IBM double byte charsets were re-implemented in JDK 7. I think the old
implementations moved to the test tree so it could be used to test
On Wed, 30 Aug 2023 00:37:26 GMT, Srinivas Vamsi Parasa
wrote:
> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is
> triggering the intrinsic without additional flags
Just to add that Sorting.java has short and long run modes. The default when
running with jtreg
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal is to develop faster sort routines for x86_64 CPUs by taking
>> advantage of AVX512 instructions. This enhancement provides an order of
>> magnitude speedup for Arrays.sort() using int, long, float and double arrays.
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote:
> yes this is of course AIX specific. However I found something that might be
> similar on Windows, there we have in case of successful LoadLibrary in
> os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not
>
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote:
>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>>
>>> 406: @Override
>>> 407: public int read(ByteBuffer buf) throws IOException {
>>> 408: if (!SocketReadEvent.enabled()) {
>>
>> The read/write
On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - remove unused SOCKET_READ and SOCKET_WRITE configurations.
&g
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote:
> An exception event will be emitted. The event is disabled by default, but
> there is ongoing work on a throttling mechanism, so it can be always-on.
Good, I think the exception cases are probably the most interesting for this
area when it
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman wrote:
> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
> https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event
> generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocki
On Mon, 14 Aug 2023 22:18:56 GMT, Erik Joelsson wrote:
> This is a redo of [pull/14561](https://git.openjdk.org/jdk/pull/14561). The
> change relaxes the prerequisites for the top level java.base-jmod target to
> not include targets for jmods of upgradable modules.
>
> The problem with the
1 - 100 of 212 matches
Mail list logo
