On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK
>
> The [Zlib Data Compression Library](https://github.com/madler/zlib ) has
> released Zlib 1.3 on August 18, 2023.
>
> There are a [small number of
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
>>> Something fishy here, is this working around a bug in GraaVM native image
>>> or why does this change need to be in JDK?
>>
>> I've now realized that the bug had an incorrect statement in the
>>
On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko wrote:
>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko 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
This looks fun! It's probably best to bring this to loom-dev. In its
archives you'll find several discussions about generators as several
people have been interested in that topic. Even when thread confined,
the main concern has been that exotic control flow yields leads to
surprising
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
>
Vote: yes
Vote: yes
Vote: yes
On Thu, 24 Aug 2023 14:39:18 GMT, Severin Gehwolf wrote:
> I've now realized that the bug had an incorrect statement in the description.
> The cycle happens due to the `Runtime.getRuntime().maxMemory()`
> implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code
> relies on
On Fri, 25 Aug 2023 09:37:47 GMT, Masanori Yano wrote:
> I want to add a log output similar to JDK-8301627 to Runtime.halt().
> To avoid double logging of Runtime.exit(), add a flag to indicate whether
> logging was done, and fix it so that logging is done only once.
> Could someone please
On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman wrote:
> If yielding fails due to the pinning then VirtualThread.parkNanos parks on
> the carrier thread with the remaining time. The calculation of the remaining
> time needs to be replaced so that it obviously uses the differenc
On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf wrote:
> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part
> of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use
> the
> JDK's version of `Metrics` in GraalVM. See the bug for
On Thu, 24 Aug 2023 11:55:20 GMT, Daniel Fuchs wrote:
> Although... what happens if parkOnCarrierThread is called with a negative
> value (as that could happen here)?
Not an issue, nothing has changed there.
-
PR Comment:
If yielding fails due to the pinning then VirtualThread.parkNanos parks on the
carrier thread with the remaining time. The calculation of the remaining time
needs to be replaced so that it obviously uses the difference between the start
and end time in the calculation. The current code isn't
On Thu, 24 Aug 2023 04:24:21 GMT, Vyom Tewari wrote:
> I am unable to understand how proposed change breaks longstanding
> behavior(what behavior). With current implementation if the underline stream
> is closed ‘BufferedOutputStream.write’ will throw IOException when the
> internal buffer is
On Wed, 23 Aug 2023 13:02:37 GMT, Matthias Baesken wrote:
> This might be the case, but it is a separate issue. This issue is about
> improving the BackingStoreException . Normally I would not even touch the
> prefs C code, but converting the errno int into something more 'nice' has to
> be
On Tue, 22 Aug 2023 07:48:46 GMT, Matthias Baesken wrote:
> Hi Alan, should we maybe add this ? If so in this change on in another one ?
I don't have a strong opinion on this, I was just surprised to see these tests
run concurrently given the history of issues.
-
PR Comment:
On Wed, 23 Aug 2023 12:46:28 GMT, Matthias Baesken wrote:
> Hi Alan, should this be done similar to what is done here , using strerror +
> strdup and throwing an exception with the generated error message ?
>
On Mon, 21 Aug 2023 15:05:29 GMT, Alan Bateman wrote:
> I thought of this ,but i was not 100% sure. I will create CSR first.
It's probably a bit premature to create the CSR as there is no agreement here
on the API change. I think it would be better to drop this part and focus on
the behav
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 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 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, 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, 21 Aug 2023 15:00:59 GMT, Chen Liang wrote:
>> I thought of this ,but i was not 100% sure. I will create CSR first.
>
> You can convert this method, or the `closed` field, to be package-private
> (default access) instead.
> I thought of this ,but i was not 100% sure. I will create CSR
On Mon, 21 Aug 2023 14:26:39 GMT, Vyom Tewari wrote:
> With the current implementation of BufferedOutputStream if you close the
> stream and try to write to the closed stream BufferedOutputStream does not
> throw an IOException until the internal buffer is full. To fix this issue i
> added a
On Mon, 21 Aug 2023 06:48:18 GMT, David Holmes wrote:
> How long is the file-lock typically held? How many such tests can run
> concurrently? And how long do we retry for?
It's typically the sync method when writing back the cached changes. I suspect
the Unix implementation could be easily
On Fri, 28 Jul 2023 20:33:01 GMT, Alan Bateman wrote:
> This is a small issue with StructuredTaskScope. If the owner attempts to fork
> a subtask and the task scope is shutdown then the implementation doesn't
> currently force the owner to join when it's the first fork in a
On Fri, 18 Aug 2023 17:25:10 GMT, Ben Taylor wrote:
> Backport is clean, all tests in test/jdk/java/util/zip pass.
JDK 21 is at RC, only P1 issues with approval. There is already a fix request
for jdk21u. The 21.0.1 release is only a few weeks after JDK 21.
-
PR Comment:
On Fri, 18 Aug 2023 12:02:05 GMT, Matthias Baesken wrote:
> I checked the usage of sun/nio/fs/UnixConstants.java and seems we would need
> to make the class public and an additional export for this like
>
> ```
> exports sun.nio.fs to
> +java.prefs,
> jdk.net;
> ```
>
>
On Wed, 16 Aug 2023 16:16:12 GMT, Paul Sandoz wrote:
> Very minor suggestion, up to you. We could change the exception message
> thrown by `SubtaskImpl::get` to:
>
> > Subtask result is unavailable or did not complete successfully
>
> (Similar change for `SubtaskImpl::exception`.) That leans
ling Subtask::get throws ISE with
> the wrong exception message.
>
> The existing test for this API is updated to remove a duplicate test and also
> fix two tasks that didn't call join.
Alan Bateman has updated the pull request with a new target base due to a merge
or a rebase. The inc
On Wed, 16 Aug 2023 18:42:00 GMT, Mandy Chung wrote:
> Clarify the spec of `ModuleDescriptor::mainClass`, `ModuleDescriptor::uses`,
> `ModuleDescriptor.Provides::service` and
> `ModuleDescriptor.Provides::providers` to return a binary name.
>
> This PR also fixes JDK-8314449 to update the
On Thu, 17 Aug 2023 04:52:59 GMT, Joe Darcy wrote:
> Use of javadoc search index feature; I'll re-flow paragraphs before pushing
> once the wording is agreed to.
This looks okay to me. You might want to move the "For a" on L58 to the next
line to avoid L58 stick out too much, up to you.
On Tue, 15 Aug 2023 16:21:55 GMT, Alan Bateman wrote:
> This is a docs only change. The specification for
> StructuredTaskScope.shutdown should make it clear that the state of subtasks
> that are completing (with a result or exception) at around the time of
> shutdown is
On Wed, 16 Aug 2023 14:45:25 GMT, Sergey Bylokhov wrote:
> I disagree for a few reasons, using that property will completely disable the
> appropriate patch for a fix in the CPU, and it will be possible to
> have/accept some malicious zip files which may trigger some unfortunate
> behavior.
On Wed, 16 Aug 2023 14:44:23 GMT, Matthias Baesken wrote:
> Hi Alan, I am not sure what 'interesting file path' you are referring to. I
> only added an integer (errno/errcode) and at one place fix strings
> shared/nonshared to the exception message.
Oh I see, I thought you wanted to include
On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken wrote:
> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
>
> [JShell] Exception in thread "main" java.lang.IllegalStateException:
> java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at
>
On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov wrote:
> Made a few fields `final` in java.util.Scanner.
> Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.`
Marked as reviewed by alanb (Reviewer).
-
PR Review:
On Wed, 16 Aug 2023 08:07:05 GMT, Raffaello Giulietti
wrote:
> Please review this trivial typo.
> TIA
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/15303#pullrequestreview-1580051924
On Tue, 15 Aug 2023 23:13:00 GMT, Volker Simonis wrote:
> That file is accepted by zip, by the latest JDK8u382, by the JDK20 GA, and
> rejected by the 20.0.2. That is a regression in the latest update of JDK11+
> which we trying to solve here.
Have you tested your ZIP file with
On Tue, 15 Aug 2023 20:13:18 GMT, Andrey Turbanov wrote:
> A field `char mAttrIdx` in the `jdk.internal.util.xml.impl.Attrs` class is
> unused and can be removed.
Marked as reviewed by alanb (Reviewer).
-
PR Review:
On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen wrote:
>> This PR updates the extra field validation added as part of
>> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
>> issues seen with 3rd party tools/libraries where a ZipException may be
>> encountered when
This is a small issue with StructuredTaskScope. If the owner attempts to fork a
subtask and the task scope is shutdown then the implementation doesn't
currently force the owner to join when it's the first fork in a new round of
forking. The result is that broken code calling Subtask::get throws
This is a docs only change. The specification for StructuredTaskScope.shutdown
should make it clear that the state of subtasks that are completing (with a
result or exception) at around the time of shutdown is not defined. The state
of a completing subtask may transition to a terminal state, it
On Tue, 15 Aug 2023 16:41:35 GMT, Lance Andersen wrote:
>> This PR updates the extra field validation added as part of
>> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
>> issues seen with 3rd party tools/libraries where a ZipException may be
>> encountered when
On Tue, 15 Aug 2023 16:36:34 GMT, Lance Andersen wrote:
> Reworked similar to above.
Thanks. Related is that there aren't tests in this PR that run with
-Djdk.util.zip.disableZip64ExtraFieldValidation and
-D"jdk.util.zip.disableZip64ExtraFieldValidation=true to check that zip
implementations
On Tue, 15 Aug 2023 00:07:01 GMT, Sergey Bylokhov wrote:
> try this example, zip -T passed, unzip works fine, but openjdk rejects it.
Are you arguing to drop all checking of the extra fields? It's not clear to me
that this PR should be do that as it has a lot of implications.
-
On Mon, 14 Aug 2023 21:21:30 GMT, Lance Andersen wrote:
>> This PR updates the extra field validation added as part of
>> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
>> issues seen with 3rd party tools/libraries where a ZipException may be
>> encountered when
On Mon, 14 Aug 2023 21:38:02 GMT, Volker Simonis wrote:
>> Hi Volker,
>>
>> I understand your point and I had done that previously but decided I did
>> not like the flow of the code that way which is why I moved the check. I
>> prefer to leave it as is.
>
> I don't think this is a
On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs wrote:
> The same copyright updates are needed in JDK21.
JDK 21 is in the RC phase so I assume this should re-targeted to jdk21u.
-
PR Comment: https://git.openjdk.org/jdk21/pull/166#issuecomment-1678567910
On Wed, 12 Jul 2023 15:06:36 GMT, Glavo wrote:
>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Revert StreamTokenizer.java
Now that the incompatible change to
On Mon, 14 Aug 2023 14:52:00 GMT, Lance Andersen wrote:
> This PR updates the extra field validation added as part of
> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
> issues seen with 3rd party tools/libraries where a ZipException may be
> encountered when opening
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
>
On Fri, 11 Aug 2023 15:32:58 GMT, Aleksey Shipilev wrote:
>> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127),
>> I realized there are no targeted tests for `FileDescriptor.sync` that can be
>> used to qualify the changes in that area.
>>
>> Additionally, we use
On Thu, 10 Aug 2023 15:45:12 GMT, Aleksey Shipilev wrote:
> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127),
> I realized there are no targeted tests for `FileDescriptor.sync` that can be
> used to qualify the changes in that area.
>
> Additionally, we use
On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao wrote:
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
> the is an IOException generation when the output stream was flushing the
> buffer.
>
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
On Mon, 31 Jul 2023 18:38:30 GMT, Raffaello Giulietti
wrote:
>> Fixes a bug showing up after
>> [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are
>> capturing groups outside the match.
>
> Raffaello Giulietti has updated the pull request with a new target base due
>
On Wed, 2 Aug 2023 18:19:27 GMT, Tim Prinzing wrote:
> I believe this has all requested changes or has separate bug reports to
> address changes yet needing to be made.
> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
> https://bugs.openjdk.org/browse/JDK-8310978 -
On Fri, 28 Jul 2023 15:44:54 GMT, Alan Bateman wrote:
> This is a test only change to a test that exercises core reflection from
> virtual threads. One of the tests (testNewInstance6) uses a custom scheduler
> in setup to check that calling a constructor reflectively, where the
>
On Tue, 1 Aug 2023 09:01:49 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the build
> failure noted in https://bugs.openjdk.org/browse/JDK-8313274?
>
> The build failure is consistently reproducible with `--with-jobs=1`. Martin,
> in that JBS
On Thu, 27 Jul 2023 19:09:00 GMT, Matias Saavedra Silva
wrote:
>> Currently we exit the VM after static dumping with
>> `MetaspaceShared::exit_after_static_dump()`.
>>
>>
>> // We have finished dumping the static archive. At this point, there may be
>> pending VM
>> // operations. We
On Fri, 28 Jul 2023 19:59:15 GMT, Brian Burkhalter wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> Brian Burkhalter has updated the pull request incrementally with
On Sun, 30 Jul 2023 04:54:32 GMT, Vyom Tewari wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 6478546: Move buffer clamping up to Java layer; correct read behavior to
>> match legacy
>
>
This is a test only change to a test that exercises core reflection from
virtual threads. One of the its tests (testNewInstance6) uses a custom
scheduler in setup to check that calling a constructor reflectively, where the
constructor parks, doesn't pin the underlying carrier. The test
Vote: yes
Vote: yes
On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov wrote:
> This patch adds the java/lang/ScopedValue/StressStackOverflow.java to the
> problem list for linux-x86 where it intermittently fails on a GA, ex:
> https://github.com/openjdk/jdk21/pull/148
>
> This is only for JDK 21, test passes on
On Thu, 27 Jul 2023 06:07:42 GMT, David Holmes wrote:
>> Yes, if you change it CHECK_EXCEPTION_LEAVE(1)then any pending exception
>> will be printed and it will exit with 1; if there is no pending exception
>> then it exit with the value of `ret` as the exit status, which will be 0
>> here.
>
On Thu, 27 Jul 2023 01:30:01 GMT, Serguei Spitsyn wrote:
> Nit: normal indent for native code is 2.
The .c files I sampled in test/hotspot/jtreg/serviceability/jvmti/** used 4,
either is okay as this is just two tiny JNI functions.
-
PR Review Comment:
On Wed, 26 Jul 2023 21:52:04 GMT, Matias Saavedra Silva
wrote:
>> src/java.base/share/native/libjli/java.c line 464:
>>
>>> 462: if (dumpSharedSpaces) {
>>> 463: CHECK_EXCEPTION_LEAVE(0);
>>> 464: LEAVE();
>>
>> What is exit status ($?) when -Xshare:dump fails. It looks like
On Wed, 26 Jul 2023 19:22:08 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on
> select platforms.
JSR166TestCase.java runs >4000 tests so excluding this discussion is not good.
Maybe JDK-8312980 needs to be bumped to a P1/P2 or a
On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> java/util/concurrent/SynchronousQueue/Fairness.java on X64.
Are all the sightings -XX:+UseZGC -Xcomp? Only asking in case you meant to add
it to ProblemList-zgc.txt.
-
PR Comment:
On Tue, 25 Jul 2023 18:48:58 GMT, Matias Saavedra Silva
wrote:
>> Currently we exit the VM after static dumping with
>> `MetaspaceShared::exit_after_static_dump()`.
>>
>>
>> // We have finished dumping the static archive. At this point, there may be
>> pending VM
>> // operations. We
On Wed, 26 Jul 2023 12:20:49 GMT, David Holmes wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java
>> line 133:
>>
>>> 131: } finally {
>>> 132: thread.join();
>>> 133: Reference.reachabilityFence(lock);
>>
>> It
On Tue, 25 Jul 2023 07:09:55 GMT, airsquared wrote:
> I see. I'll create a PR there. Thanks.
Thanks, I assume this PR can be closed.
-
PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1651454738
On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> Brian Burkhalter has updated the pull request incrementally with
On Wed, 26 Jul 2023 00:00:33 GMT, Brian Burkhalter wrote:
> There was no dropping of the file system cache. I would think this would have
> more of an effect on measuring the throughput of writing than reading.
In that case, I assume the benchmarks are just reading from the file system
cache
On Wed, 26 Jul 2023 06:17:13 GMT, Vyom Tewari wrote:
> If i am reading code correctly then with the new implementation, until client
> issue the next "FIS.read" he may or may not know if there was exception
> pending in previous 'read' call ?.
> I am not sure in case of partial read we have
On Tue, 25 Jul 2023 06:56:26 GMT, airsquared wrote:
> How likely is it that this can get approved in RDP 2? This is only a tiny
> change that fixes a minor bug in jpackage.
Unlikely as this is a P4 and not a regression in JDK 21. I think you should be
aiming for jdk21u with this backport.
On Tue, 25 Jul 2023 02:09:29 GMT, Brian Burkhalter wrote:
> It's based on micro-benchmarks. Having the loops in Java reduces throughput
> but allocating memory using `malloc(len)` also reduces throughput as `len`
> gets larger and this threshold appears to balance the two.
Are these micro
On Tue, 25 Jul 2023 05:21:45 GMT, David Holmes wrote:
> Why handle TIMED this way instead of just making TIMED_PARKED/PARKING states?
Been there but it is 3 additional states and a lot simpler to just use the
additional state bits, like we do with SUSPENDED. We might use another one for
Thread::getState is an API for monitoring and management purposes to report the
thread state. If a virtual thread is parked with LockSupport.parkNanos, its
state is reported as WAITING when it should be TIMED_WAITING. JVM TI
GetThreadState has the same issue in that it returns
On Mon, 24 Jul 2023 16:00:52 GMT, Sean Coffey wrote:
> Modify the -XshowSettings launcher option to print non-verbose settings
> details of all components by default. Verbose settings details will be
> printed via the -XshowSettings:all option. Modify the -XshowSettings option
> to reject bad
On Mon, 24 Jul 2023 09:16:23 GMT, Vyom Tewari wrote:
>> Limit native memory allocation and move write loop from the native layer
>> into Java. This change should make the OOME reported in the issue much less
>> likely.
>
> src/java.base/share/native/libjava/io_util.c line 99:
>
>> 97:
On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter wrote:
> Limit native memory allocation and move write loop from the native layer into
> Java. This change should make the OOME reported in the issue much less likely.
src/java.base/share/classes/java/io/FileOutputStream.java line 366:
> 364:
On Thu, 20 Jul 2023 02:34:05 GMT, airsquared wrote:
> 8309032: jpackage does not work for module projects unless --module-path is
> specified
JDK 21 is in rampdown phase two so only P1/P2 bugs (with approval) at this
time, maybe this is one for JDK 21u instead.
-
PR Comment:
On Thu, 20 Jul 2023 10:29:25 GMT, Chen Liang wrote:
> The Unsafe-based writing will be used by `Integer.toString` and
> `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper
> be overkill?
Integer/Long are very core classes so I assume they can use Unsafe if needed,
On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov wrote:
> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14926#pullrequestreview-1538485598
On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov wrote:
> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.
src/java.base/share/classes/java/util/ServiceLoader.java line 426:
> 424:
> 425: private static final JavaLangAccess LANG_ACCESS =
> 426:
On Wed, 19 Jul 2023 07:05:45 GMT, Jaikiran Pai wrote:
> I had initially considered that but had noticed that there's a small
> difference between the generic warning message "Warning: %s option is
> deprecated and may be removed in a future release." printed by the launcher
> and the one
On Wed, 19 Jul 2023 07:05:51 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal the `-Xdebug` option and `-debug` option of the `java` command?
>> This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>>
>> As noted in the
On Wed, 19 Jul 2023 07:07:40 GMT, Jaikiran Pai wrote:
> I would like inputs on the
> test/hotspot/jtreg/runtime/6294277/SourceDebugExtension.java test. That test
> launches java passing it the -Xdebug option and was introduced as part of
> https://bugs.openjdk.org/browse/JDK-6294277. -Xdebug
On Mon, 17 Jul 2023 20:46:32 GMT, Naoto Sato wrote:
>> This is to bring the JLine-based Console implementation as the default,
>> which was the initial intention in
>> [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding
>> CSR has also been drafted.
>
> Naoto Sato has
On Tue, 18 Jul 2023 07:58:58 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal the `-Xdebug` option and `-debug` option of the `java` command?
>> This addresses https://bugs.openjdk.org/browse/JDK-8227229.
>>
>> As noted in the
On Tue, 18 Jul 2023 06:59:52 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal the `-Xdebug` option of the `java` command? This addresses
> https://bugs.openjdk.org/browse/JDK-8312151?
>
> As noted in the JBS issue this option is
On Sat, 15 Jul 2023 13:54:46 GMT, Alan Bateman wrote:
> If FileDescriptor::sync is invoked by a virtual thread then it doesn't
> release its carrier to do other work while modifications are written to the
> file system. For cases like this, parallelism should be temporarily
If FileDescriptor::sync is invoked by a virtual thread then it doesn't release
its carrier to do other work while modifications are written to the file
system. For cases like this, parallelism should be temporarily increased for
the duration of the operation. This one is somewhat legacy as it's
On Thu, 1 Jun 2023 18:53:21 GMT, Naoto Sato wrote:
> This is to bring the JLine-based Console implementation as the default, which
> was the initial intention in
> [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding
> CSR has also been drafted.
This looks quite good.
701 - 800 of 1993 matches
Mail list logo
