On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and
On Mon, 15 Jul 2024 16:40:06 GMT, Maurizio Cimadamore
wrote:
> > So +1 to merge this and hopefully backport it at least to 21?
>
> Backport to 21 is difficult, given the handshake code there is different
> (and, FFM is preview there). But, might be more possible for 22. I have
> notified
On Mon, 15 Jul 2024 16:30:11 GMT, Maurizio Cimadamore
wrote:
>>> > > Even with `arrayElementVarHandle` it's about the same
>>> >
>>> >
>>> > This is very odd, and I don't have a good explanation as to why that is
>>> > the case. What does the baseline (confined arena) look like for
>>> >
On Mon, 15 Jul 2024 15:18:20 GMT, Jorn Vernee wrote:
> > > This is what I was thinking of as well. close() on a shared arena can be
> > > called by any thread, so it would be possible to have an executor service
> > > with 1-n threads that is dedicated to closing memory.
> >
> >
> > This
On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and
On Mon, 15 Jul 2024 09:17:31 GMT, Maurizio Cimadamore
wrote:
>>> One only closing arenas, another set that consumes scoped memory and a
>>> third group doing totally unrelated stuff.
>>
>> Exactly. My general feeling is that the cost of handshaking a thread
>> dominates everything else, so
On Mon, 15 Jul 2024 08:54:11 GMT, Maurizio Cimadamore
wrote:
> > I have one problem with the benchmark: I think it is not measuring the
> > whole setup in a way that is our workload: The basic problem is that we
> > don't want to deoptimize threads which are not related to MemorySegments.
>
On Mon, 15 Jul 2024 08:57:08 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> track has_scoped_access for compiled methods
>
>
On Mon, 15 Jul 2024 08:41:01 GMT, Alan Bateman wrote:
>> This is the whole magic around the shared arena. It is not public API and
>> internal to Hotspot/VM:
>> -
>>
On Mon, 15 Jul 2024 08:28:16 GMT, Doug Simon wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> track has_scoped_access for compiled methods
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 179:
>
>> 177:
On Sat, 13 Jul 2024 16:43:16 GMT, Rémi Forax wrote:
> Knowing that all the segments are freed during close() is something you may
> want. But having the execution time of close() be linear with the number of
> threads is also problematic. Maybe, it means that we need another kind of
> Arena
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and
On Fri, 24 Nov 2023 18:30:17 GMT, Erik Österlund wrote:
>> The current logic for closing memory in panama today is susceptible to live
>> lock if we have a closing thread that wants to close the memory in a loop
>> that keeps failing, and a bunch of accessing threads that want to perform
>>
On Mon, 23 Oct 2023 22:15:48 GMT, Uwe Schindler wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove 2 extraneous files from commit
>
> Marked as reviewed by uschindler (A
On Mon, 23 Oct 2023 18:26:51 GMT, Raffaello Giulietti
wrote:
>> Please review this simple fix to restore the original exception message that
>> existed before [16050](https://github.com/openjdk/jdk/pull/16050).
>
> Raffaello Giulietti has updated the pull request incrementally with one
>
On Mon, 23 Oct 2023 08:17:43 GMT, Uwe Schindler wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Using compareUnsigned() rather than open logic.
>
> This caused issue s
On Fri, 6 Oct 2023 16:26:42 GMT, Raffaello Giulietti
wrote:
>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the
>> details.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Using
On Fri, 11 Aug 2023 12:37:59 GMT, Jorn Vernee wrote:
>> This patch contains the implementation of the foreign linker & memory API
>> JEP for Java 22. The initial patch is composed of commits brought over
>> directly from the [panama-foreign
>> repo](https://github.com/openjdk/panama-foreign).
On Fri, 21 Jul 2023 15:14:23 GMT, Maurizio Cimadamore
wrote:
>> So have you thought of making this low-level classes public so we outside
>> users no longer need to deal with VarHandles?
> I believe this is beyond the scope of this PR.
Sure, I brought this up here but yes, it is not really
On Thu, 20 Jul 2023 21:43:49 GMT, Maurizio Cimadamore
wrote:
>>> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the
>>> performance of ByteBuffer was also poor:
>>
>> I finally see it.
>>
>>
>> Benchmark (polluteProfile) Mode Cnt Score
On Wed, 12 Jul 2023 14:31:53 GMT, Glavo wrote:
>> src/java.base/share/classes/java/io/StreamTokenizer.java line 632:
>>
>>> 630: sval = String.copyValueOf(buf, 0, i);
>>> 631: if (forceLower)
>>> 632: sval = sval.toLowerCase(Locale.ROOT);
>>
>> I suspect
On Thu, 29 Jun 2023 07:59:42 GMT, Glavo wrote:
> I understand the original reason for retaining it before, but this discussion
> is outdated for this PR.
>
> `Unsafe` does not provide `getFloatUnaligned`/`getDoubleUnaligned` and
> `putFloatUnaligned`/`putDoubleUnaligned`, so we must convert
>
> The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and
> was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.
>
> Thanks!
Marked as reviewed by uschindler (Author).
-
PR Review: https://git.openjdk.org/jdk21/pull/3#pullrequestreview-1473013982
On Fri, 9 Jun 2023 13:18:07 GMT, Chris Hegarty wrote:
>> A trivial use of the Vector API when run with the security manager and a
>> domain that does not grant permissions fails with
>> java.security.AccessControlException: access denied
>> ("java.util.PropertyPermission"
>>
On Fri, 9 Jun 2023 13:07:27 GMT, Chris Hegarty wrote:
>> A trivial use of the Vector API when run with the security manager and a
>> domain that does not grant permissions fails with
>> java.security.AccessControlException: access denied
>> ("java.util.PropertyPermission"
>>
On Fri, 9 Jun 2023 13:18:07 GMT, Chris Hegarty wrote:
>> A trivial use of the Vector API when run with the security manager and a
>> domain that does not grant permissions fails with
>> java.security.AccessControlException: access denied
>> ("java.util.PropertyPermission"
>>
n types;
>>> m(factories);
>>> ^
>>> required: List>>
>>> found: List>>
>>> reason: argument mismatch; List>>
>>> cannot be conve
Other times it is less practical to do so, as for FFM
API, and patterns in switch + record patterns.
Maurizio
Chen Liang
On Tue, May 16, 2023 at 12:28 PM Remi Forax wrote:
- Original Message -
From: "Uwe Schindler"
To: "core-libs-dev"
Sent: Tuesday, May 16
APIs. There should be no risk in running the compiler output of
preview switch or instanceof statements without preview features enabled.
Uwe
--
Uwe Schindler
uschind...@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
Hi Alan,
Am 16.05.2023 um 18:07 schrieb Alan Bateman:
On 16/05/2023 16:38, Uwe Schindler wrote:
:
Is it really needed to have a next round of preview API? Why not have
Java 21 with Foreign API finalized in the same way like virtual
threads? To me it is strange that an API like virtual
lang.foreign! Please, please, please!
Uwe
P.S.: Vector API is still in incubation, when will it go to preview?
--
Uwe Schindler
uschind...@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
On Fri, 25 Nov 2022 14:38:55 GMT, Adam Sotona wrote:
> 8294962: java.base jdk.internal.module package uses ASM to modify and write
> module-info.class.
> This patch converts it to use Classfile API.
>
> Please review.
> Thanks,
> Adam
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>>
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>>
On Mon, 9 Jan 2023 10:33:44 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove faulty test tag, improve other test tag, fix comments
>
> src/java.base/share/classes/java/io/Bits.java
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Thu, 5 Jan 2023 12:50:25 GMT, Raffaello Giulietti
wrote:
> One reason is that if the `byte[]` contains a non-canonical NaN then `get()`
> would return it. The original code first reads an integer value and then
> converts it to a floating-point value, so for backward compatibility the same
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
modes will work
also for long and double.
So I think this should be labeled as "getAndSet" or at least
"get-and-set" access mode. Currently it's very confusing.
--
Uwe Schindler
uschind...@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 12:20:28 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 12:20:28 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 10:49:24 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 10:49:24 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Wed, 4 Jan 2023 09:01:06 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard
On Mon, 11 Jul 2022 09:46:11 GMT, Maurizio Cimadamore
wrote:
> Some of the accessors in `MemorySegment` and `MemoryAddress` (esp. setters)
> have typos - e.g. they use `from` instead of `into`.
>
> I've tried to simplify the text and made it more regular.
Marked as reviewed by uschindler
48 matches
Mail list logo
