On 11/06/2024 18:19, David Lloyd wrote:
:
I thought that might be where Alan was headed with this. I would
support this solution; it would solve the problem for conformant
serialization libraries. If a class has a `readObject`/etc. then we
use it - we wouldn't care if it was "natural" or
On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls wrote:
> Sure, happy to not add annotations in sun.jvmstat.monitor.remote
> (RemoteHost.java, RemoteVm.java).
Right, you can drop it from all the source files except for module-info.java.
-
PR Comment:
On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls wrote:
> Sure, happy to not add annotations in sun.jvmstat.monitor.remote
> (RemoteHost.java, RemoteVm.java).
Right, you can drop it from all the source files except for module-info.java.
-
PR Comment:
On 11/06/2024 17:27, David Lloyd wrote:
:
Yes, all of the method-access methods on ReflectionFactory are used,
not just for readObject/writeObject but also readObjectNoData,
readResolve, and writeReplace, the constructor accessors, and the
factory methods for OptionalDataException. We
On 06/06/2024 18:37, David Lloyd wrote:
Just bumping this one more time. I intend to start by opening a JIRA
to add the two proposed methods to `ReflectionFactory`, and go from
there. I guess that we might need a JEP for the proposed serialization
restrictions, which is going to be
On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls wrote:
> jstatd is an RMI server application which monitors HotSpot VMs, and provides
> an interface to the monitoring tool jstat, for use across a remote RMI
> connection.
>
> RMI is not how modern applications communicate. It is an old transport
On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls wrote:
> jstatd is an RMI server application which monitors HotSpot VMs, and provides
> an interface to the monitoring tool jstat, for use across a remote RMI
> connection.
>
> RMI is not how modern applications communicate. It is an old transport
On Mon, 10 Jun 2024 07:36:50 GMT, Inigo Mediavilla Saiz
wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request with a new target base due
> to a merge or a rebase. The incremental webrev excludes
On Tue, 4 Jun 2024 08:06:28 GMT, Alan Bateman wrote:
>> Inigo Mediavilla Saiz has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Cleanup test
>>
>>- Stop virtualthread
>>- Remo
On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote:
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
>
On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote:
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
>
On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote:
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
>
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
It's hard for me to determine this for customers who may already have
installed Apache NiFi and just drop my NAR in or count on my Docker
container. I'd like a clearer idea of who or what is responsible for that.
On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti
wrote:
> A documentation-only change to match the original intent and the implemented
> behavior.
Yes, this one needs a CSR.
-
Marked as reviewed by alanb (Reviewer).
PR Review:
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 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 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 Wed, 5 Jun 2024 15:58:28 GMT, Thomas Stuefe wrote:
>> Thanks !
>>
>> Your PR looks very promising @tstuefe, I would indeed prefer to wait for
>> your changes as a way to add additional indentation to the stack of the
>> virtual thread.
>>
>> What do you think if I leave the current PR
On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang wrote:
> Primarily offering this PR for discussion, as Throwables throwing exceptions
> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
> unreasonable thing to do.
>
> Nevertheless, there is some things we can do, as
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 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 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 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 Wed, 5 Jun 2024 12:14:07 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which updates the API specification
>> of `java.util.zip.InflaterInputStream.skip()` method to match its current
>> implementation?
>>
>> `InflaterInputStream.skip()`, just like
On Fri, 31 May 2024 13:18:33 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On 05/06/2024 07:45, Iñigo Mediavilla wrote:
Thanks, Alan. Sorry, I wasn't clear in my message. I wasn't thinking
about including unmounted threads in the output of `Thread.print`, I
agree with you that besides the formatting things that still need to
be fixed there's no need to add more
On Wed, 5 Jun 2024 04:41:48 GMT, David Alayachew wrote:
> Hey, I'm just curious -- why was the solution to remove an entire module? I
> understand the point of moving the relevant code over to `java.base`, but I
> don't understand why removing the random module made sense.
With the
On 04/06/2024 21:52, Iñigo Mediavilla wrote:
Hello,
While there's ongoing work on:
https://github.com/openjdk/jdk/pull/19482
to add the stack trace of mounted virtual threads to the `jcmd
Thread.print` command, I'm starting to think about how I could do to
print the stack trace for virtual
On Wed, 5 Jun 2024 01:21:36 GMT, Nizar Benalla wrote:
>> This is a simple noreg cleanup. The motivation was that I noticed javac
>> doesn't recognise package.html files well.
>>
>> Some of the contents of the `package.html` files (and code in the package)
>> may be outdated, but I think it is
On Mon, 27 May 2024 09:01:48 GMT, Nizar Benalla wrote:
>> This is a simple noreg cleanup. The motivation was that I noticed javac
>> doesn't recognise package.html files well.
>>
>> Some of the contents of the `package.html` files (and code in the package)
>> may be outdated, but I think it
On Tue, 4 Jun 2024 13:17:11 GMT, Thomas Stuefe wrote:
> Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3
> you want to have tested?
I think just prudent to run more tests when touching the launcher as it has
options that aren't tested much in tier1. Shouldn't be an
On Tue, 4 Jun 2024 12:59:54 GMT, Jaikiran Pai wrote:
> I'll file follow up issue(s) and also trigger CI testing of this PR.
Thanks, the regressions fixed here are important to fix. It's unfortunate there
the original changes weren't changes weren't caught by tests. There is a good
test
On Tue, 4 Jun 2024 12:49:18 GMT, Alexey Semenyuk wrote:
> We already have [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466) to
> find the original crash.
Thanks, just making sure the issue that there is an issue tracking it as it's a
bit unsettling that a re-run may be hiding
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> I think there's some consensus that we need some follow up cleanup issues for
> the JNI spec, renaming constants, fixing return codes, etc.
>
> Seeing how that grows the scope of the issue quite a bit, I'd like to
On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Cleanup
On Tue, 4 Jun 2024 06:38:36 GMT, Serguei Spitsyn wrote:
>> The intent is to provide a definition of what a null pointer is, for both C
>> and C++ programs. Is there a better place to do that so that elsewhere the
>> spec can simply to refer to "a null pointer" or "null"?
>
> Thanks, David. I
On Mon, 3 Jun 2024 14:38:03 GMT, Alexey Semenyuk wrote:
>> I am yet to see anything that actually explains the cause of the `dlerror`
>> crash here ???
>
> @dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR.
> The PR fixes jpackage tests to rerun a launcher if it
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 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 Mon, 3 Jun 2024 11:26:27 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add
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 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 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 Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote:
>> Hi all,
>> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
>> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
>> There are two changes in this PR:
>> 1. In
On Fri, 31 May 2024 02:07:25 GMT, David Holmes wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> I'd probably give preference to the stack of the virtual thread, as the stack
> of the carrier when a vthread is mounted is generally quite
On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz
wrote:
> Print the stack traces of mounted virtual threads when calling `jcmd
> Thread.print`.
Thanks for take this one. Here's the result with the changes in 1a75277e.
"ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31
On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> 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
&g
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base
On Thu, 30 May 2024 06:51:54 GMT, David Holmes wrote:
>> Hopefully the ports will catch up someday and the alternative implementation
>> can be removed.
>>
>> We decided not to rename java.lang.VirtualThread when introducing the
>> alternative implementation as it's just too disruptive. The
On Thu, 30 May 2024 06:14:21 GMT, David Holmes wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> change from java_lang_VirtualThread::is_instance(thread_oop) to
>> hread_oop->is_a(vmClasses::BaseVirtualThread_klass())
On Wed, 29 May 2024 20:17:30 GMT, Chris Plummer wrote:
> Fixed broken javadoc link. I confirmed that it currently is broken as can be
> seen in the JDK 22 javadocs:
>
> https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/jdk.jdi/com/sun/jdi/VirtualMachine.html#allThreads()
>
>
nding method on
> Carrier) are no longer needed. The functional interface is not proposed for
> j.u.function at this time.
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 merg
On Wed, 29 May 2024 06:25:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which marks 2 constructors on
>> `java.net.Socket` as deprecated for removal?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
>> constructors, which allow for
On Wed, 29 May 2024 05:48:44 GMT, Jaikiran Pai wrote:
> Hello Alan, I've updated the PR to include a note on
> `SocketImpl.create(...)`. Does the wording look correct? I'll update the CSR
> too once we finalize on the text.
SocketImpl is for implementors (it's not a user facing API) so
On Wed, 29 May 2024 00:59:10 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which marks 2 constructors on
> `java.net.Socket` as deprecated for removal?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
> constructors, which allow for
On Tue, 28 May 2024 20:22:24 GMT, Jonathan Gibbons wrote:
> What about changing `///` to `//---` to give slightly more prominence to
> these comments, over plain old `//` comments. The dashes give a small sense
> of a horizontal rule, to delimit sections of code.
>
> (FWIW, I have locally
On Tue, 28 May 2024 20:22:24 GMT, Jonathan Gibbons wrote:
> What about changing `///` to `//---` to give slightly more prominence to
> these comments, over plain old `//` comments. The dashes give a small sense
> of a horizontal rule, to delimit sections of code.
>
> (FWIW, I have locally
On Tue, 28 May 2024 18:57:07 GMT, Jonathan Gibbons wrote:
> OK. I was just trying to honor the apparent intent to make the comment stand
> out more than just a plain `//` comment, but I have no strong feelings
> against reducing `///` to `//`
In this case I would reduce it to '//' but others
On Tue, 28 May 2024 18:57:07 GMT, Jonathan Gibbons wrote:
> OK. I was just trying to honor the apparent intent to make the comment stand
> out more than just a plain `//` comment, but I have no strong feelings
> against reducing `///` to `//`
In this case I would reduce it to '//' but others
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> 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 remove
On Tue, 28 May 2024 12:27: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 Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
This pull request has now been integrated.
Changeset: e708d135
Author: Alan Batema
I don't know if Alex Menkov is subscribed here, better to ask on
serviceability-dev.
-Alan
On 28/05/2024 11:03, Iñigo Mediavilla wrote:
On Tue, May 28, 2024 at 11:28 AM Iñigo Mediavilla
wrote:
Hello,
I've been looking at possible tickets that I could work on under
the
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
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
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 b
On Sun, 26 May 2024 14:24:27 GMT, SendaoYan wrote:
> > That would mean it's not tested. I suspect the
> > java_lang_VirtualThread::is_instance checks will need to be changed to test
> > with is_a(vmClasses::BaseVirtualThread_klass()) to allow for the
> > alternative implementation.
>
> Do
On Sun, 26 May 2024 09:27:00 GMT, SendaoYan wrote:
> Hi all,
> ObjectMonitorUsage.java failed with `unexpected waiter_count` after
> [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32.
> It should be predicated with `@requires vm.continuations` to be skipped.
>
>
On Sun, 26 May 2024 08:22:44 GMT, Lei Zhu wrote:
> Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and
> MulticastSocket.send(DatagramPacket, byte)
These methods are proposed to be deprecated for removal in JDK 23, it will be
JDK 25, maybe later, before they can be
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 18:11:18 GMT, Nizar Benalla wrote:
> This is a simple noreg cleanup. The motivation was that I noticed javac
> doesn't recognise package.html files well.
>
> Some of the contents of the `package.html` files (and code in the package)
> may be outdated, but I think it is out
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 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 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, 15 May 2024 20:29:17 GMT, Serguei Spitsyn wrote:
>> The fix is to degrade virtual threads support in the JVM TI
>> `GetObjectMonitorUsage` function so that it is specified to only return an
>> owner when the owner is a platform thread. Also, virtual threads are not
>> listed in the
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 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.
-
1 - 100 of 18235 matches
Mail list logo
