I've just integrated this - thanks to all the contributors and reviewers
for the help!
Cheers
Maurizio
On 20/05/2020 15:01, Maurizio Cimadamore wrote:
Another very small iteration which fixes a gap in the javadoc
specification for MemorySegment::toArray (thanks Chris!)
Webrev:
> On 20 May 2020, at 15:01, Maurizio Cimadamore
> wrote:
>
> Another very small iteration which fixes a gap in the javadoc specification
> for MemorySegment::toArray (thanks Chris!)
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev
>
> Delta webrev:
>
>
+1
Paul.
> On May 20, 2020, at 7:01 AM, Maurizio Cimadamore
> wrote:
>
> Another very small iteration which fixes a gap in the javadoc specification
> for MemorySegment::toArray (thanks Chris!)
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev
>
> Delta webrev:
>
>
Another very small iteration which fixes a gap in the javadoc
specification for MemorySegment::toArray (thanks Chris!)
Webrev:
http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev
Delta webrev:
http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev_delta/
Cheers
Maurizio
On
> On 13 May 2020, at 13:12, Maurizio Cimadamore
> wrote:
>
> Another iteration which addresses the latest CSR comments (the CSR has now
> been approved):
>
> * make MemorySegment::withAccessModes/hasAccessMode throw
> IllegalArgumentException in cases where the provided mask is invalid
Another iteration which addresses the latest CSR comments (the CSR has
now been approved):
* make MemorySegment::withAccessModes/hasAccessMode throw
IllegalArgumentException in cases where the provided mask is invalid
(this required a test tweak)
* sprinkled a couple of references to the JLS
Hi Maurizio,
On 5/5/20 4:12 PM, Maurizio Cimadamore wrote:
On 02/05/2020 09:45, Peter Levart wrote:
Thread 1 does:
a) increments 'acquires'
b) reads OPEN from 'state'
Thread 2 does:
c) writes CLOSING to 'state'
d) sums 'acquires'
'a' happens before 'b' happens before 'c' happens
On 02/05/2020 09:45, Peter Levart wrote:
Thread 1 does:
a) increments 'acquires'
b) reads OPEN from 'state'
Thread 2 does:
c) writes CLOSING to 'state'
d) sums 'acquires'
'a' happens before 'b' happens before 'c' happens before 'd' => 'a'
happens before 'd'
Where did you get the
On 5/1/20 4:36 PM, Maurizio Cimadamore wrote:
Now there's dup(). I think implementing dup() on a root scope is not
too hard - for the child you probably need some trick, but probably
not too bad - in the sense that in a Child scope, the cleanup action
is really the increment of the root
Hi Maurizio,
On 5/1/20 4:36 PM, Maurizio Cimadamore wrote:
Hi Peter,
this does look better yes.
I suspect this doesn't affect performance negatively right? (in most
cases, when acquiring, state will be OPEN).
Now there's dup(). I think implementing dup() on a root scope is not
too hard -
On 01/05/2020 15:36, Maurizio Cimadamore wrote:
in which case close() will fail and acquire() will fail.
I meant close() will fail and segment will be acquired
On 01/05/2020 15:31, Peter Levart wrote:
So WDYT? Is it ok to propose this for panama? How do I proceed?
You can do a pull request against this branch:
https://github.com/openjdk/panama-foreign/tree/foreign-memaccess
Cheers
Maurizio
Hi Peter,
this does look better yes.
I suspect this doesn't affect performance negatively right? (in most
cases, when acquiring, state will be OPEN).
Now there's dup(). I think implementing dup() on a root scope is not too
hard - for the child you probably need some trick, but probably not
Hi Maurizio,
On 5/1/20 3:00 PM, Peter Levart wrote:
Luckily, I think I have fixed this shortcoming in the alternative
MemoryScope:
http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java
I added support for dup() (modified above file in-place) and also
On 4/30/20 8:10 PM, Maurizio Cimadamore wrote:
On 30/04/2020 01:06, Peter Levart wrote:
Think differently: what if the client succeeded in closing the
segment, just because it did it in a time window when no thread in
the thread pool held an open scope (this is entirely possible with
Latest iteration - the follow issues were addressed:
* fix a bug with alignment of native segments triggering spurious
failures (contributed by Jorn)
* fix javadoc and tests for access modes (contributed by Chris)
* added benchmarks for Stream::findAny using segment spliterator
(contributed
quot; ,
"core-libs-dev"
*Envoyé: *Jeudi 30 Avril 2020 01:05:46
*Objet: *Re: RFR 8243491: Implementation of Foreign-Memory Access
API (Second Incubator)
On 4/29/20 2:30 PM, fo...@univ-mlv.fr wrote:
I think the problem with perf might be caused by the fact t
On 30/04/2020 01:06, Peter Levart wrote:
Think differently: what if the client succeeded in closing the
segment, just because it did it in a time window when no thread in the
thread pool held an open scope (this is entirely possible with
parallel stream for example since threads periodically
t;Jorn Vernee"
> Cc: "Maurizio Cimadamore" , "core-libs-dev"
>
> Envoyé: Jeudi 30 Avril 2020 01:05:46
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
> Incubator)
> On 4/29/20 2:30 PM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.
Thanks Chris,
I'll make sure this is included in the next iteration!
Cheers
Maurizio
On 30/04/2020 16:07, Chris Hegarty wrote:
Maurizio,
On 30 Apr 2020, at 15:35, Maurizio Cimadamore
wrote:
Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with "will feature",
and also
Maurizio,
> On 30 Apr 2020, at 15:35, Maurizio Cimadamore
> wrote:
>
> Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with "will
> feature", and also add a link between "access modes" to the access mode
> section of the javadoc, to make it more navigable.
Done.
Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with
"will feature", and also add a link between "access modes" to the access
mode section of the javadoc, to make it more navigable.
Maurizio
On 30/04/2020 14:33, Chris Hegarty wrote:
Maurizio,
On 23 Apr 2020, at 21:33,
Maurizio,
> On 23 Apr 2020, at 21:33, Maurizio Cimadamore
> wrote:
>
>
> Javadoc:
>
> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc
>
I’m still working my way through this update ( BTW it’s looking very good ),
but an initial comment on the API.
The access modes of
On 4/29/20 10:23 PM, Maurizio Cimadamore wrote:
Many thanks Peter,
my preference would be for adding the benchmark now, and come back to
fix this post integration. The MemoryScope code is finicky and getting
confidence that the code is race-free takes time and I'd prefer not to
change that
On 4/29/20 11:16 PM, Maurizio Cimadamore wrote:
On 29/04/2020 21:40, Maurizio Cimadamore wrote:
On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a
revised version (posted below). The spurious ISE may happen but only
when close is called
On 4/29/20 2:30 PM, fo...@univ-mlv.fr wrote:
I think the problem with perf might be caused by the fact that while the
array is now a constant, the elements are not (the array is mutable
after all). For fields you can fix this by using @Stable, but not for CP
entries :)
I think you're right,
- Mail original -
> De: "Jorn Vernee"
> À: "Maurizio Cimadamore" , "mandy chung"
> , "Remi Forax"
>
> Cc: "core-libs-dev"
> Envoyé: Mercredi 29 Avril 2020 22:09:47
> Objet: Re: RFR 8243491: Implementation of Foreign
- Mail original -
> De: "Maurizio Cimadamore"
> À: "mandy chung" , "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 29 Avril 2020 03:13:35
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
&
On 29/04/2020 21:40, Maurizio Cimadamore wrote:
On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a revised
version (posted below). The spurious ISE may happen but only when
close is called prematurely relative to all child scope close(s)
On 29/04/2020 08:10, Peter Levart wrote:
Right, as you saw in a private Email, I did exactly that in a revised
version (posted below). The spurious ISE may happen but only when
close is called prematurely relative to all child scope close(s) that
were or are still active. So we could say the
Many thanks Peter,
my preference would be for adding the benchmark now, and come back to
fix this post integration. The MemoryScope code is finicky and getting
confidence that the code is race-free takes time and I'd prefer not to
change that during the course of this RFR.
Your approach
Hi,
I think the problem with perf might be caused by the fact that while the
array is now a constant, the elements are not (the array is mutable
after all). For fields you can fix this by using @Stable, but not for CP
entries :)
I think what could work is; rather than ldc'ing the array, and
Hi Maurizio,
On 4/29/20 2:41 AM, Maurizio Cimadamore wrote:
The current implementation has performances that are on par with the
previous acquire-based implementation, and also on par with what can
be achieved with Unsafe. We do have a micro benchmark in the patch
(see ParallelSum (**)) which
> De: "mandy chung"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" , "core-libs-dev"
>
> Envoyé: Mardi 28 Avril 2020 20:09:07
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
> Incubator)
> On 4/28/20
On 4/29/20 2:41 AM, Maurizio Cimadamore wrote:
On 28/04/2020 21:27, Peter Levart wrote:
Hi,
The problem with current implementation of MemoryScope is that if a
child scope is frequently acquired and closed (which increments and
then decrements the parent scope counter atomically using
On 28/04/2020 21:44, Maurizio Cimadamore wrote:
On 28/04/2020 19:09, Mandy Chung wrote:
On 4/28/20 12:58 AM, fo...@univ-mlv.fr wrote:
I don't think you need to store all the values into static
fields, you can directly do a ldc + aaload with the right index
right where you need
On 28/04/2020 21:27, Peter Levart wrote:
Hi,
The problem with current implementation of MemoryScope is that if a
child scope is frequently acquired and closed (which increments and
then decrements the parent scope counter atomically using CAS), and
that is performed from multiple
On 28/04/2020 23:08, Peter Levart wrote:
On 4/28/20 10:49 PM, Maurizio Cimadamore wrote:
On 28/04/2020 17:12, Peter Levart wrote:
Hi Maurizio,
I'm checking out the thread-confinement in the parallel stream case.
I see the Spliterator.trySplit() is calling
AbstractMemorySegmentImpl's:
On 4/28/20 10:49 PM, Maurizio Cimadamore wrote:
On 28/04/2020 17:12, Peter Levart wrote:
Hi Maurizio,
I'm checking out the thread-confinement in the parallel stream case.
I see the Spliterator.trySplit() is calling AbstractMemorySegmentImpl's:
102 private AbstractMemorySegmentImpl
On 28/04/2020 17:12, Peter Levart wrote:
Hi Maurizio,
I'm checking out the thread-confinement in the parallel stream case. I
see the Spliterator.trySplit() is calling AbstractMemorySegmentImpl's:
102 private AbstractMemorySegmentImpl asSliceNoCheck(long offset,
long newSize) {
103
On 28/04/2020 19:09, Mandy Chung wrote:
On 4/28/20 12:58 AM, fo...@univ-mlv.fr wrote:
I don't think you need to store all the values into static fields, you
can directly do a ldc + aaload with the right index right where you need it,
I think this is what you are thinking as
Hi,
The problem with current implementation of MemoryScope is that if a
child scope is frequently acquired and closed (which increments and then
decrements the parent scope counter atomically using CAS), and that is
performed from multiple concurrent threads, contention might become
On 4/28/20 12:58 AM, fo...@univ-mlv.fr wrote:
I don't think you need to store all the values into static fields, you
can directly do a ldc + aaload with the right index right where you need it,
I think this is what you are thinking as reported in JDK-8243492:
Hi Maurizio,
I'm checking out the thread-confinement in the parallel stream case. I
see the Spliterator.trySplit() is calling AbstractMemorySegmentImpl's:
102 private AbstractMemorySegmentImpl asSliceNoCheck(long offset,
long newSize) {
103 return dup(offset, newSize, mask,
> De: "mandy chung"
> À: "Remi Forax" , "Maurizio Cimadamore"
>
> Cc: "core-libs-dev"
> Envoyé: Mardi 28 Avril 2020 01:17:05
> Objet: Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second
> Incubator)
&
will be available to the other ldcs)
and the JIT will fold the access to the array given the array is a constant.
regards,
Rémi
- Mail original -
De: "Maurizio Cimadamore"
À: "core-libs-dev"
Envoyé: Lundi 27 Avril 2020 14:13:55
Objet: Re: RFR 8243491: Implementation of F
will be available to the other ldcs)
and the JIT will fold the access to the array given the array is a constant.
regards,
Rémi
- Mail original -
> De: "Maurizio Cimadamore"
> À: "core-libs-dev"
> Envoyé: Lundi 27 Avril 2020 14:13:55
> Objet: Re: RFR 8243491: Impleme
Another iteration, which addresses the following issues:
* wrong copyright headers in certain tests
* issue with TestNative when running in debug mode caused by mismatched
malloc/os::free (contributed by Jorn)
* clarify javadoc of MemoryHandles::withStride
* improved implementation of
On 24/04/2020 17:38, Paul Sandoz wrote:
On Apr 23, 2020, at 5:45 PM, Maurizio Cimadamore
wrote:
On 24/04/2020 01:35, Paul Sandoz wrote:
Hi,
Looks good. I have seen almost all of this in reviews on panama-dev hence the
lack of substantial comments here.
I suspect we are not gonna need
> On Apr 23, 2020, at 5:45 PM, Maurizio Cimadamore
> wrote:
>
>
> On 24/04/2020 01:35, Paul Sandoz wrote:
>> Hi,
>>
>> Looks good. I have seen almost all of this in reviews on panama-dev hence
>> the lack of substantial comments here.
>>
>> I suspect we are not gonna need the drop
On 24/04/2020 01:35, Paul Sandoz wrote:
Hi,
Looks good. I have seen almost all of this in reviews on panama-dev hence the
lack of substantial comments here.
I suspect we are not gonna need the drop argument VH combinator, dropping
coordinates feels a little suspicious to me, but I can see
Hi,
Looks good. I have seen almost all of this in reviews on panama-dev hence the
lack of substantial comments here.
I suspect we are not gonna need the drop argument VH combinator, dropping
coordinates feels a little suspicious to me, but I can see why it's there for
completeness.
Paul.
>
Hi,
time has come for another round of foreign memory access API incubation
(see JEP 383 [3]). This iteration aims at polishing some of the rough
edges of the API, and adds some of the functionalities that developers
have been asking for during this first round of incubation. The revised
API
53 matches
Mail list logo
