On Fri, 5 Jan 2024 09:07:57 GMT, Stefan Karlsson wrote:
>> Tests using ProcessTools.executeProcess gets the following output written to
>> stdout:
>> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
>> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process
On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang wrote:
> While this might not fix 8314515, it should at least make it more exact.
test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 27:
> 25: * @test
> 26: * @modules java.base/java.util.concurrent:open
> 27: * @bug 4992438
On Thu, 21 Dec 2023 01:33:29 GMT, Adam Sotona wrote:
> Profiling of the benchmarks revealed several slowdowns:
>
> * many expensive conversions from `Class` to `ClassDesc` to
> `ClassEntry`, or even more expensive `MethodTypeDesc`
>
> * building proxy class from scratch from symbols
On Fri, 5 Jan 2024 22:58:36 GMT, Chen Liang wrote:
>> Discovered while writing a test for #16513 that
>> `ClassSignature.superclassSignature()` does not return a `ClassTypeSig`, yet
>> [JVM
>> Spec](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.9.1-4100)
>>
> Discovered while writing a test for #16513 that
> `ClassSignature.superclassSignature()` does not return a `ClassTypeSig`, yet
> [JVM
> Spec](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.9.1-4100)
> requires it to be one. This patch adds such a requirement to the
> Discovered while writing a test for #16513 that
> `ClassSignature.superclassSignature()` does not return a `ClassTypeSig`, yet
> [JVM
> Spec](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.9.1-4100)
> requires it to be one. This patch adds such a requirement to the
On Wed, 3 Jan 2024 12:36:26 GMT, Adam Sotona wrote:
>> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy
>> classes.
>>
>> This patch converts it to use Classfile API.
>>
>> It is continuation of https://github.com/openjdk/jdk/pull/10991
>>
>> Any comments and suggestions
On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg wrote:
>> This PR outlines a solution for making immutable maps `@ValueBased` by
>> removing cacheing of certain values in `AbstractMap`.
>>
>> By removing these caching fields in `AbstractMap`, we can make the immutable
>> maps `@ValueBased` and
On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote:
> In preparation for when virtual threads can unmount while holding a monitor
> or unmount when blocking on monitorenter, the implementation of
> VirtualThread's interrupt method is refactored to avoid parking/blocking
> while holding the
On Fri, 5 Jan 2024 17:35:01 GMT, Jaikiran Pai wrote:
>> In preparation for when virtual threads can unmount while holding a monitor
>> or unmount when blocking on monitorenter, the implementation of
>> VirtualThread's interrupt method is refactored to avoid parking/blocking
>> while holding
On Fri, 5 Jan 2024 17:42:42 GMT, Alan Bateman wrote:
> Serguei is working to change notifyJvmtiDisableSuspend to be a static method
> (JDK-8322744) to make it clearer that it disable suspend of the current
> virtual thread rather than the receiver.
That explains it then. Before commenting, I
Clean backport tzdata 2023d.
`make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test
test/jdk/sun/util/resources test/jdk/sun/text/resources
test/jdk/sun/util/calendar"` is all passing
-
Commit messages:
- Backport 2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc
Changes:
On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote:
> In preparation for when virtual threads can unmount while holding a monitor
> or unmount when blocking on monitorenter, the implementation of
> VirtualThread's interrupt method is refactored to avoid parking/blocking
> while holding the
On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote:
> In preparation for when virtual threads can unmount while holding a monitor
> or unmount when blocking on monitorenter, the implementation of
> VirtualThread's interrupt method is refactored to avoid parking/blocking
> while holding the
On Fri, 5 Jan 2024 17:27:30 GMT, Jaikiran Pai wrote:
>> In preparation for when virtual threads can unmount while holding a monitor
>> or unmount when blocking on monitorenter, the implementation of
>> VirtualThread's interrupt method is refactored to avoid parking/blocking
>> while holding
On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote:
> In preparation for when virtual threads can unmount while holding a monitor
> or unmount when blocking on monitorenter, the implementation of
> VirtualThread's interrupt method is refactored to avoid parking/blocking
> while holding the
On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote:
> In preparation for when virtual threads can unmount while holding a monitor
> or unmount when blocking on monitorenter, the implementation of
> VirtualThread's interrupt method is refactored to avoid parking/blocking
> while holding the
On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote:
> In preparation for when virtual threads can unmount while holding a monitor
> or unmount when blocking on monitorenter, the implementation of
> VirtualThread's interrupt method is refactored to avoid parking/blocking
> while holding the
On Fri, 5 Jan 2024 16:51:40 GMT, Jaikiran Pai wrote:
>> In preparation for when virtual threads can unmount while holding a monitor
>> or unmount when blocking on monitorenter, the implementation of
>> VirtualThread's interrupt method is refactored to avoid parking/blocking
>> while holding
>
> As for Panama, note that the SymbolLookup API allows a better way to
> load system libraries, with its SymbolLookup::libraryLookup factory:
>
>
>
On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang wrote:
> While this might not fix 8314515, it should at least make it more exact.
@AlanBateman I think this change is worth making to see if that makes a
difference.
-
PR Comment:
Hi Glavo,
parsing ld.conf is something that some frameworks do (e.g. JNR). Last
time I checked there was some concerns in having hotspot bootstrap code
depending on the results of an external tool, whose output could change
over time. Currently, IIRC the list of path is just a compiler
On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang wrote:
> While this might not fix 8314515, it should at least make it more exact.
Yes, it is a bit more fragile (looking for particular methods) but similar to
other test improvements (like FJP close tests) that make them more reliable and
While this might not fix 8314515, it should at least make it more exact.
-
Commit messages:
- Improving SynchronousQueue Fairness test to only proceed once observing that
the previous thread is enqueued as a producer
Changes: https://git.openjdk.org/jdk/pull/17082/files
Webrev:
On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang wrote:
> While this might not fix 8314515, it should at least make it more exact.
@Martin-Buchholz @DougLea while this might not fix
https://bugs.openjdk.org/browse/JDK-8314515 it should be more correct than
waiting for the thread state to
On Thu, 7 Sep 2023 11:13:44 GMT, Per Minborg wrote:
> This PR outlines a solution for making immutable maps `@ValueBased` by
> removing cacheing of certain values in `AbstractMap`.
>
> By removing these caching fields in `AbstractMap`, we can make the immutable
> maps `@ValueBased` and at the
On Sun, 24 Sep 2023 13:17:05 GMT, Chen Liang wrote:
> 1. Primitive array VHs are now singletons and no longer need to record their
> array base and offset in their object themselves.
> 2. Moved Unsafe offset calculation to a utility method, like `index` in
> VarHandleByteArrayView.
This pull
On Fri, 5 Jan 2024 07:08:35 GMT, Jatin Bhateja wrote:
>> Hi,
>>
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2
>> only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2
>> instruction set.
>> These are very frequently used APIs in
On Fri, 5 Jan 2024 07:05:51 GMT, Jatin Bhateja wrote:
>> We do have extensive functional tests for compress/expand APIs in
>> [test/jdk/jdk/incubator/vector](https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/incubator/vector)
>
>> Could there be equivalent `expand` tests?
>
> Here are
On Fri, 5 Jan 2024 09:37:55 GMT, Emanuel Peter wrote:
>> This computes the byte offset from start of the table, both integer and long
>> permute table have same row sizes, 8 int elements vs 4 long elements.
>
> Ah, I understand now. Maybe leave a comment for that?
I would say something like
On Thu, 4 Jan 2024 13:40:19 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updating copyright year of modified files.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 957:
>
>> 955: __
On Fri, 5 Jan 2024 09:31:50 GMT, Emanuel Peter wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 957:
>>
>>> 955: __ align(CodeEntryAlignment);
>>> 956: StubCodeMark mark(this, "StubRoutines", stub_name);
>>> 957: address start = __ pc();
>>
>> Could you please add some
On Fri, 5 Jan 2024 07:03:34 GMT, Jatin Bhateja wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5307:
>>
>>> 5305: assert(bt == T_LONG || bt == T_DOUBLE, "");
>>> 5306: vmovmskpd(rtmp, mask, vec_enc);
>>> 5307: shlq(rtmp, 5);
>>
>> Might this need to be 6? If I
On Fri, 5 Jan 2024 08:22:41 GMT, Stefan Karlsson wrote:
>> Most functions in ProcessTools are declared to throw Exceptions, or one of
>> its subclasses. However, there are a small number of functions that are
>> unnecessarily declared to throw Throwable instead of Exception. I propose
>> that
On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson wrote:
> Most functions in ProcessTools are declared to throw Exceptions, or one of
> its subclasses. However, there are a small number of functions that are
> unnecessarily declared to throw Throwable instead of Exception. I propose
> that we
> Tests using ProcessTools.executeProcess gets the following output written to
> stdout:
> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
> [2023-11-24T09:58:23.071045055Z] Waiting for completion
> This PR proposes to change the specification for some methods that take
> `long` offsets so that they will throw an `IllegalArgumentException` rather
> than an `IndexOutOfBoundsException` for negative values.
>
> The PR also proposes to fix a bug where the allocation size would overflow
>
> This PR proposes to change the specification for some methods that take
> `long` offsets so that they will throw an `IllegalArgumentException` rather
> than an `IndexOutOfBoundsException` for negative values.
>
> The PR also proposes to fix a bug where the allocation size would overflow
>
> Most functions in ProcessTools are declared to throw Exceptions, or one of
> its subclasses. However, there are a small number of functions that are
> unnecessarily declared to throw Throwable instead of Exception. I propose
> that we change them to also be declared to throw Exception.
>
>
> This PR proposes to change the specification for some methods that take
> `long` offsets so that they will throw an `IllegalArgumentException` rather
> than an `IndexOutOfBoundsException` for negative values.
>
> The PR also proposes to fix a bug where the allocation size would overflow
>
On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose wrote:
> tzdata2023d changes
This pull request has now been integrated.
Changeset: 2a9c3589
Author:Johny Jose
Committer: Sean Coffey
URL:
https://git.openjdk.org/jdk/commit/2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc
Stats: 140 lines in
41 matches
Mail list logo
