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 Mon, 13 May 2024 21:00:10 GMT, Stuart Marks wrote:
>>> If an event class is loaded before JFR is started, the event class needs to
>>> be retransformed, but if it is loaded later, we can add instrumentation on
>>> class load and avoid the retransformation. More happens when an event class
On Thu, 16 May 2024 12:10:46 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of a change that moves the jdk.FileRead and
>> jdk.FileWrite events to java.base to remove the use of the ASM
>> instrumentation.
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>
> Erik Gahlin has
On Sun, 12 May 2024 13:35:42 GMT, Erik Gahlin wrote:
> I guess it's not 100% safe if the JIT decides to store the read value
> elsewhere over several event checks, but it seems unlikely. Event settings
> checks (i.e., Event::isEnabled()) have always used plain reads, so it is not
> more
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:21:14 GMT, Maurizio Cimadamore
wrote:
> I believe we already disable a bunch of warnings from the command line when
> compiling these benchmarks. Perhaps we can just tweak the build script in a
> similar way and avoid the changes to the sources? E.g.
>
> ```
>
l sample of methods to
> ensure the changes doesn't cause any perf regressions.
>
> For now, the changes include the update to the man page for the "java"
> command. It might be that this has to be separated out so that it goes with
> other updates in the releas
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:18:11 GMT, Maurizio Cimadamore
wrote:
> The FFM code throws if an unknown value is passed. Here we log. Should we try
> to be more consistent?
I don't have a strong opinion on this. The value of --illegal-native-access is
examined during startup so startup can fail if
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 08:49:46 GMT, ExE Boss wrote:
> Maybe export this interface to `jdk.unsupported`?
I don't we should do that. In general, we need jdk.unsupported to go away in
the long term. Also integrity of the platform depends on java.base being very
stingy and not exporting internal
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 Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the
On Tue, 14 May 2024 07:14:09 GMT, Thomas Stuefe wrote:
> but it does not state explicitly that an exception is thrown on every error,
> or whether there are cases where the API can return NULL but not throw an
> exception, or vice versa.
>
> So, I'd check for both. Or, if we think that both
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 Mon, 13 May 2024 10:30:43 GMT, Per Minborg wrote:
> Some of the deprecated methods are very likely to be run in hot loops (e.g.
> read/store operations). Unless we set
> `--sun-misc-unsafe-memory-access=allow`, what would be the performance impact
> on various platforms for these
On Thu, 9 May 2024 18:44:10 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
The OpenJDK net-dev mailing list is the best place to bring this. There
was discussion about SOCKS when the HTTP client was developed, I thought
JEP 321 had a summary on this but it seems not. I'm sure others on
net-dev can say more on this.
-Alan
On 12/05/2024 22:58, Alessandro Autiero
On Mon, 13 May 2024 06:58:42 GMT, Per Minborg wrote:
> Would it make sense to add some verbiage in the JavaDocs for
> `sun.misc.Unsafe` that indicates the planned direction for said class and the
> use of the new command line options?
There is an API note to say that the class predates
On Sun, 12 May 2024 21:44:56 GMT, Alan Snyder wrote:
> I was not using the Zip file system. I was processing a Zip file.
They are equivalent, the suggestion to look at the sym link support in the zip
file system provider is that it's a much better fit for this extension. It
already has
This is the implementation changes for JEP 471.
The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
for removal. This means a removal warning at compile time. No methods have been
removed. A deprecated message is added to each of the methods but unlikely to
be seen as
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
On Sun, 12 May 2024 09:48:42 GMT, xiaotaonan wrote:
> This issue was reported by a person named Alan Snyder, I don't have his or
> her contact information, how to create a CSR in this situation.
He came to core-libs-dev in Dec 2023 [1] to discuss this. The context at the
time was symbolic
On Sat, 11 May 2024 19:31:34 GMT, Erik Gahlin wrote:
> If an event class is loaded before JFR is started, the event class needs to
> be retransformed, but if it is loaded later, we can add instrumentation on
> class load and avoid the retransformation. More happens when an event class
> is
On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote:
> Add API to access ZipEntry.extraAttributes
I think this will require discussion on core libs before proposing APIs in this
area. I think a starting point would be explain how you might use this, esp.
with file permissions and sym links.
On Thu, 9 May 2024 16:02:02 GMT, Erik Gahlin wrote:
>> The field is only used once and a VarHandle implementation loads three
>> additional classes during startup and in my measurements add about 0.6 ms to
>> startup.
>
> A compromise between performance and readability is:
>
> if
On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang wrote:
>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
>
On Thu, 9 May 2024 11:19:14 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of a change that moves the jdk.FileRead and
>> jdk.FileWrite events to java.base to remove the use of the ASM
>> instrumentation.
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>
> Erik Gahlin has
On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote:
> In preparation for JEP 471 and JEP 472, provide access to the initial value
> of System.err from JavaLangAccess. The initial value of System.in is already
> exposed to code in java.base with this shared secret.
This pull reques
In preparation for JEP 471 and JEP 472, provide access to the initial value of
System.err from JavaLangAccess. The initial value of System.in is already
exposed to code in java.base with this shared secret.
-
Commit messages:
- Initial commit
Changes:
There are any API or implementations changes in third preview but the JEP
number/title needs to be bumped for the javadoc page.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/19175/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19175=00
On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles
wrote:
>> Pre-existing: Man, I cannot grok the complex return code handling, tbh.
>>
>> We have the local `ret` variable holding a return code. We also hand codes
>> to CHECK_EXCEPTION_LEAVE as macro argument. But we don't hand codes to
On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
On Wed, 8 May 2024 17:30:22 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 17:01:05 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna
wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> further tweaks to reachability
>
> src/java.base/share/classes/java/lang/ref/package-info.java line
On Mon, 29 Apr 2024 21:17:24 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Fri, 23 Feb 2024 06:06:21 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Wed, 1 May 2024 22:33:29 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 any
On Wed, 8 May 2024 05:29:03 GMT, Jaikiran Pai wrote:
> Hello Raffaello, the proposed changes look OK to me. Do you think we should
> add a jtreg test for this?
>
> In general, the test coverage for these APIs appears to be missing. I think
> that can be addressed separately in some of the
On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang wrote:
> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19123#pullrequestreview-2043916265
On Sun, 5 May 2024 12:05:48 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 147:
>>
>>> 145:
>>> FactoryMapHolder.class.getModule().addUses(RandomGenerator.class);
>>> 146: return ServiceLoader
>>>
On Sat, 4 May 2024 18:29:25 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Fri, 3 May 2024 08:15:32 GMT, Matthias Baesken wrote:
> The naming GetApplicationHomeFromLD_LIBRARY_PATH looks a bit unconventional ;
> maybe adjust this ? Regarding if the code should be added for all platforms
> or just AIX, let's hear what Alan and others have to say.
I was busy with
On Thu, 2 May 2024 17:17:54 GMT, Liam Miller-Cushon wrote:
> Please keep this open, assistance on progressing this pull request is welcome
ACK. There was a lengthy bug tail when zip64 support was added. We've got away
without needing this for executable JAR files for a long time so it's great
On Tue, 30 Apr 2024 10:21:49 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Mon, 29 Apr 2024 21:53:02 GMT, Tim Prinzing wrote:
> Should I set the default to be fairly high (like maybe 1600ms)? I think to be
> useful people will have to set the threshold to something that fits their
> needs anyway.
I wonder about the usefulness of this event if the default
On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang wrote:
> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and
> status for Stream Gatherers.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19003#pullrequestreview-2030820148
On Mon, 29 Apr 2024 16:42:59 GMT, Viktor Klang wrote:
> @AlanBateman Let me know if I should create a new JBS issue for this change,
> or if it is fine to target the JEP JBS issue. 樂
The bot has spotted this already (see "Integration Blocker" in the updated
description). You'll need to create
On Mon, 29 Apr 2024 14:45:07 GMT, Joachim Kern wrote:
> Since ~ end of March, after
> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>
> stdout: [];
> stderr: [Error: could not find libjava.so
> Error: Could not
On Fri, 26 Apr 2024 09:41:21 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang wrote:
> This PR adds the exception documentation as per the ExecutorService API
> contract. I also took the liberty of adding @Override-annotations to be clear
> about intent.
Marked as reviewed by alanb (Reviewer).
I think this is okay. The
On Thu, 25 Apr 2024 13:17:51 GMT, Matthias Baesken wrote:
> I removed the mentioned 'private JRE' check and also the related size check.
Good, I'll look at it as soon as I can. I suspect we'll need some follow on
issues as there are several issues here.
-
PR Comment:
On Tue, 23 Apr 2024 14:29:05 GMT, Matthias Baesken wrote:
>
> `/* Does the app ship a private JRE in /jre directory? */`
>
> part meant? This looks indeed obsolete .
Yes, this is code that doesn't make sense since JDK 9 and should be
removed/cleanup at some point. I suspect we had to leave
On Wed, 24 Apr 2024 15:27:23 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Thu, 25 Apr 2024 07:56:59 GMT, Adam Sotona wrote:
> Pr/18914 broke tests build.
> This patch fixes
> `test/micro/org/openjdk/bench/jdk/classfile/CodeAttributeTools`
>
> Please review.
>
> Thanks,
> Adam
Marked as reviewed by alanb (Reviewer).
-
PR Review:
On 25/04/2024 05:29, Iñigo Mediavilla wrote:
Hello,
For my first contribution to OpenJDK, I've started looking into
JDK-8313674, an issue that falls into core-libs. According to the
OpenJDK Developers’ Guide I'd need a sponsor to help me through the
contribution process, would anyone be
On Wed, 24 Apr 2024 15:45:58 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request with a new target base due to a
> merge or a
On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti
wrote:
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
What is the footprint implications for this? I'm trying
On Tue, 23 Apr 2024 18:08:34 GMT, Brian Burkhalter wrote:
>> I was thinking more of a subclass that counted invocations to public methods
>> or metering which would cause subclass to double the counts when calling via
>> virtual thread.
>
> So do we think it better not to invoke `toByteArray`
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to
On Tue, 23 Apr 2024 11:16:01 GMT, Jason Mehrens wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correct ID in test @bug tag
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>
>>
On Mon, 22 Apr 2024 11:57:19 GMT, Alan Bateman wrote:
>> Hi, any additional comments / reviews ?
>> Thanks Matthias
>
>> Hi, any additional comments / reviews ? Thanks Matthias
>
> It still looks like left over trace messages from a debugging session, need
> to
On Tue, 23 Apr 2024 08:04:54 GMT, Viktor Klang wrote:
>> Alan Bateman 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 contai
On Tue, 23 Apr 2024 07:11:34 GMT, Viktor Klang wrote:
> Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been
> explored/benchmarked?
Yes, decided not to do because it's just guarding access to a byte[] and any
changes can influence the inlining. Plus, it would need to
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
direct
> buffer in some I/O operations). This part is a pre-requisite to the changes
> to better support object monitor there are more places where preemption is
> possible and this quickly leads to unbalanced begin/end.
>
> The changes have been baking in loom repo for some time.
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
>
On Mon, 22 Apr 2024 11:30:41 GMT, Matthias Baesken wrote:
> Hi, any additional comments / reviews ? Thanks Matthias
It still looks like left over trace messages from a debugging session, need to
think about about what tracing make sense here.
-
PR Comment:
On Fri, 19 Apr 2024 11:33:59 GMT, Evemose wrote:
> but i cant manage to find where exactly and how I can file CSR review
> request. Could you help me out?
I think you can ignore CSR for now, the first step when proposing an API in
this area is to start a discussion on core-libs-dev to make
On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
On Wed, 17 Apr 2024 23:24:06 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 any more
On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken wrote:
>> src/java.base/windows/native/libjli/java_md.c line 326:
>>
>>> 324: }
>>> 325:
>>> 326: JLI_TraceLauncher("GetJREPath - attempt to get JRE location from
>>> shared lib of the image\n");
>>
>> Maybe add a trace also in the
On Wed, 17 Apr 2024 19:33:09 GMT, Jan Lahoda wrote:
>> This is an implementation of JEP JDK-8315129: Module Import Declarations
>> (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>>
>> It is mostly straightforward - the module imports are parsed, and
On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken wrote:
> I am not sure if this even works any more. Maybe Alan could comment on this ?
The GetPublicJREHome function was removed at some point, I think JDK 9, as it
didn't make sense to have in the OpenJDK project. However, Oracle installer
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, 16 Apr 2024 08:25:01 GMT, Thomas Stuefe wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 912:
>>
>>> 910: private static final int MAIN_WITHOUT_ARGS = 1;
>>> 911: private static final int MAIN_NONSTATIC = 2;
>>> 912: private static int mainType =
On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken wrote:
> We have already good JLI tracing capabilities. But GetApplicationHome and
> GetApplicationHomeFromDll lack some tracing and should be enhanced.
I think this is way too ad hoc and looks like lefts over from a debugging
session. So I
On Mon, 26 Feb 2024 14:17:09 GMT, Daniel Fuchs wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:
>>
>>> 42: @Label("SelectionKey Count")
>>> 43: @Description("Number of channels ready for I/O or added to ready
>>> set")
>>> 44: public int
On Mon, 15 Apr 2024 20:39:26 GMT, Tim Prinzing wrote:
>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:
>>
>>> 62:
>>> 63: data.flip();
>>> 64: ch.write(data, 0);
>>
>> This just initiates the write operation, it doesn't wait until it
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue
On Mon, 15 Apr 2024 07:36:05 GMT, Jan Lahoda wrote:
>> Consider code like:
>>
>> public class MainClass {
>> public MainClass() {
>> System.out.println("Constructor called!");
>> }
>> public static void main() {
>> System.out.println("main called!");
>> }
>> }
>>
On Fri, 12 Apr 2024 10:16:36 GMT, Jan Lahoda wrote:
> Consider code like:
>
> public class MainClass {
> public MainClass() {
> System.out.println("Constructor called!");
> }
> public static void main() {
> System.out.println("main called!");
> }
> }
>
> and
On Thu, 11 Apr 2024 09:12:30 GMT, Daniel Fuchs wrote:
>>> Maybe that's OK - and maybe in that case the onus is on the user to set a
>>> threshold greater than 1500ms?
>>
>> The threshold is 20ms so these timed-select ops in the HTTP client will
>> record an event when they timeout.
>
> We
On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing wrote:
>> Added mirror event with static methods: jdk.internal.event.SelectionEvent
>> that provides the duration of select calls and the count of how many keys
>> are available.
>>
>> Emit the event from SelectorImpl::lockAndDoSelect
>>
>> Test
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to
1 - 100 of 1907 matches
Mail list logo
