On Sun, 26 May 2024 06:06:50 GMT, Daniel Jeliński wrote:
> SkippedException works with jtreg tests only. For jUnit you need to use
> [Assumptions.abort](https://junit.org/junit5/docs/5.9.1/api/org.junit.jupiter.api/org/junit/jupiter/api/Assumptions.html#abort(java.lang.String))
Yes, the
On Fri, 24 May 2024 23:15:26 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
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 23:24:16 GMT, Chen Liang wrote:
> Hmm, actually, looking at the specs of the method again, does it imply that
> Proxy classes are never unloaded once defined in a ClassLoader, as seen in
> `Proxy::getProxyClass`:
It's not specified, Proxy pre-dates hidden classes although
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 Thu, 23 May 2024 13:28:16 GMT, Chen Liang wrote:
> I have updated the compatibility risk description of the CSR.
>
> My CSR proposes to allow dynamic unloading of the proxy implementation
> classes, but currently it's not implemented as they are strongly referenced
> in the
On Thu, 23 May 2024 11:25:00 GMT, Chen Liang wrote:
> A CSR targeting 24 describing the compatibility concerns and behavioral
> differences is here, somehow not linked by skara:
> https://bugs.openjdk.org/browse/JDK-8332770 The incompatibilities were much
> greater in the previous iterations
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 Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote:
> Please review this change that convert dynamic proxies implementations to
> hidden classes, intended to target JDK 24.
>
> Summary:
> 1. Adds new implementation while preserving the old implementation behind
>
On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote:
> A long vertical series of lines beginning /// is replaced by lines beginning
> //|.
This one looks unusual when it's just one line, I could imagine deleting the
"|" in these cases.
-
PR Comment:
On Tue, 21 May 2024 16:59:38 GMT, Brent Christian wrote:
> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer
> ✔️s.
I can do that. One other thing to do is to rebase the changes, it looks like
this branch is 6 months behind main line.
-
PR Comment:
On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change for addressing
> https://bugs.openjdk.org/browse/JDK-8332490?
>
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but
> then doesn't close the stream. This can
JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
change. The type of the operation parameter of the callWhere method is changed
to a new functional interface to avoid having the API throw Exception. With
that change, the getWhere (and the corresponding method on Carrier)
l sample of methods to
> ensure the changes doesn't cause any perf regressions ([sample
> results](https://cr.openjdk.org/~alanb/8331670-results.txt)).
>
> For now, the changes include the update to the man page for the "java"
> command. It might be that this has to be se
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 15:23:36 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem. Regression test added for JDK20+
>
> Viktor Klang has updated the pull request incrementally with one additional
>
On Fri, 17 May 2024 13:19:19 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem. Regression test added for JDK20+
>
> Viktor Klang has updated the pull request incrementally with one additional
>
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 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
1 - 100 of 1927 matches
Mail list logo
