On Tue, 12 Sep 2023 19:20:16 GMT, Aleksey Shipilev wrote:
> Similar to [JDK-8315437](https://bugs.openjdk.org/browse/JDK-8315437),
> current vmTestbase/nsk/monitoring/stress/lowmem tests contains 36 tests, each
> running exclusively. This drags the tier4 test times up. There seem to be no
> re
Similar to [JDK-8315437](https://bugs.openjdk.org/browse/JDK-8315437), current
vmTestbase/nsk/monitoring/stress/lowmem tests contains 36 tests, each running
exclusively. This drags the tier4 test times up. There seem to be no reason to
run these tests exclusively, though: they complete in reason
On Tue, 12 Sep 2023 23:23:39 GMT, Chris Plummer wrote:
> [JDK-8248675](https://bugs.openjdk.org/browse/JDK-8248675) no longer seems to
> be reproducing, even before
> [JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed.
> I'm not sure what may have fixed it, but even if
On Wed, 13 Sep 2023 01:03:49 GMT, David Holmes wrote:
>> This PR includes a couple of clarifications of the JDWP and JDI invoke
>> method support. The first is that deadlocks can occur due to a needed
>> "resource" being held. The spec previously just mentioned monitors being
>> held, but this
On Tue, 12 Sep 2023 22:24:18 GMT, Chris Plummer wrote:
> This PR includes a couple of clarifications of the JDWP and JDI invoke method
> support. The first is that deadlocks can occur due to a needed "resource"
> being held. The spec previously just mentioned monitors being held, but this
> is
This PR includes a couple of clarifications of the JDWP and JDI invoke method
support. The first is that deadlocks can occur due to a needed "resource" being
held. The spec previously just mentioned monitors being held, but this is too
specific. The second is to clarify that an invoke on a virtu
[JDK-8276210](https://bugs.openjdk.org/browse/JDK-8276210) no longer seems to
be reproducing, even before
[JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed. I'm
not sure what may have fixed it, but even if the bug was potentially still
there, it has likely been fixed by
[JDK-8248675](https://bugs.openjdk.org/browse/JDK-8248675) no longer seems to
be reproducing, even before
[JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed. I'm
not sure what may have fixed it, but even if the bug was potentially still
there, it has likely been fixed by
On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu wrote:
> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It
> would improve readability to see the native characters instead of escape
> sequences (especially for the L10n process). The majority of files changed
> are local
JDK .properties files still use ISO-8859-1 encoding with escape sequences. It
would improve readability to see the native characters instead of escape
sequences (especially for the L10n process). The majority of files changed are
localized resource files.
This change converts the Unicode escape
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using a
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using a
On Wed, 9 Aug 2023 07:46:58 GMT, Sergey Bylokhov wrote:
> The test uses this code to create a list of valid addresses for the localhost:
>
> String hostname = "localhost";
> List validAddresses = new LinkedList<>();
> validAddresses.add(hostname);
> Arrays.stream(
On Thu, 7 Sep 2023 16:58:38 GMT, Andrew Haley wrote:
> This PR fixes a specific problem caused by using r29/rfp to unwind Java code.
> For some time we have treated r29 as a callee-saved scratch register, and it
> is freely used by C2-generated code. Therefore, any code in SA that uses
> getFP
> This PR fixes a specific problem caused by using r29/rfp to unwind Java code.
> For some time we have treated r29 as a callee-saved scratch register, and it
> is freely used by C2-generated code. Therefore, any code in SA that uses
> getFP() in a compiled frame is very likely to come to grief.
On Tue, 12 Sep 2023 05:58:28 GMT, Fei Yang wrote:
> Neither can I reproduce this issue on linux-riscv64 platform with jdk/jdk
> tip. But it has the same settings for the x8/fp register and context, I guess
> it also bears the same problem.
Yes, I'm sure it does.
-
PR Comment: htt
> 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
> JVMTI_
On Tue, 12 Sep 2023 08:26:59 GMT, Matthias Baesken wrote:
> So could we remove the existing PrivilegedAction in getCompilerName ?
Wouldn't that break ManagementFactory.getCompilationMXBean?
-
PR Comment: https://git.openjdk.org/jdk/pull/15629#issuecomment-1715570499
On Tue, 29 Aug 2023 23:37:06 GMT, Jiangli Zhou wrote:
> Please review this simple change from @cjmoon1 for resolving static linking
> issue caused by multiple definition of 'normalize'. @cjmoon1's branch can be
> found at:
> https://github.com/openjdk/jdk/compare/master...cjmoon1:jdk:fix_norma
On Fri, 1 Sep 2023 21:11:03 GMT, Jiangli Zhou wrote:
>> Please review this simple change from @cjmoon1 for resolving static linking
>> issue caused by multiple definition of 'normalize'. @cjmoon1's branch can be
>> found at:
>> https://github.com/openjdk/jdk/compare/master...cjmoon1:jdk:fix_no
On Fri, 8 Sep 2023 13:02:07 GMT, Alan Bateman wrote:
> > So probably we could avoid changing VMManagementImpl.java because it is not
> > needed any more at least in jdk-head .
>
> It's a JDK internal class so should never have been used directly. I can't
> imagine what might be using a JDK int
On Fri, 8 Sep 2023 14:01:24 GMT, Alexey Ivanov wrote:
> > So what about FontConfiguration? Is that something using the class directly
> > too?
>
> I think this is not needed either. As far as I can see, the instance of
> `FontConfiguration` is created from `doPrivileged`, therefore these two
22 matches
Mail list logo
