1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)"
to correctly handle IdentitityHashMap.values()? The instanceof List seems like
safe choice but it is too bad we can still fool that check by wrapping List as
an unmodifiableCollection. If splitIterator().characteris
On 5/1/20 5:55 PM, Viswanathan, Sandhya wrote:
Hi Vladimir,
Thanks a lot for the feedback.
We used an old existing separate branch to share the code for review and to
track changes.
We didn’t know how to change the name of the branch from vector-unstable to
vector-stable.
Good to know that
Hi Vladimir,
Thanks a lot for the feedback.
We used an old existing separate branch to share the code for review and to
track changes.
We didn’t know how to change the name of the branch from vector-unstable to
vector-stable.
Best Regards,
Sandhya
-Original Message-
From: Vladimir Koz
Changes seems fine. Nice work.
Why it is called "vector-unstable branch"?
Thanks,
Vladimir K
On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote:
Hi,
Following up on review requests of API [0], Java implementation [1] and
General Hotspot changes[3] for Vector API, here's a request for review
of
OK. Approved.
-phil.
On 5/1/20, 4:18 PM, Alexey Semenyuk wrote:
Evaluation:
Code snippet at memory(1871):
---
~unique_ptr() noexcept {
if (_Mypair._Myval2) {
_Mypair._Get_first()(_Mypair._Myval2);
}
}
---
Where '_Myval2' is of type jni::JniObjWithEnv define
Evaluation:
Code snippet at memory(1871):
---
~unique_ptr() noexcept {
if (_Mypair._Myval2) {
_Mypair._Get_first()(_Mypair._Myval2);
}
}
---
Where '_Myval2' is of type jni::JniObjWithEnv defined in JniUtils.h.
JniObjWithEnv is a struct wrapping two pointers:
On 5/1/20 2:02 AM, dmytro sheyko wrote:
The checked, synchronized and unmodifiable wrappers in some cases store backing
collection in more than one fields.
Thus `UnmodifiableList` has
1. its own field `List list` and
2. `Collection c`, which it inherits from
`UnmodifiableCollection`.
Also `Un
It may be self-evident but I really like to see a RFR include an evaluation
and explanation of the fix and the same in the bug report.
Please do both.
-phil.
On 5/1/20, 1:00 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Fix vs2019 compliation error.
- Alexey
[1] htt
I’ll push it for you,
Paul.
> On May 1, 2020, at 2:13 PM, Jorn Vernee wrote:
>
> The CSR for this patch is now Approved, so it looks like this patch is ready
> to be sponsored.
>
> Here are the relevant links again.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
> CSR: https://bugs
Hi Alexey,
Looks fine.
Thanks,
Alexander
On 5/1/20 1:00 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Fix vs2019 compliation error.
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8244220
[2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
The CSR for this patch is now Approved, so it looks like this patch is
ready to be sponsored.
Here are the relevant links again.
Bug: https://bugs.openjdk.java.net/browse/JDK-8241100
CSR: https://bugs.openjdk.java.net/browse/JDK-8241667
Patch: http://cr.openjdk.java.net/~jvernee/8241100/webrev.
Thanks Roger.
I figure I could have gotten away without an additional reviewer. :-) However, I
asked for a review because I wanted someone to cross-check my decision not to
file a CSR for this, despite most specification changes requiring a CSR. I also
wanted to model behavior for new communit
Hi Remi,
Thanks for the feedback. I am gonna need to go over this with John. Some
comments inline.
> On Apr 20, 2020, at 6:31 AM, Remi Forax wrote:
>
> Hi Paul,
> about the API part (not the implementation),
> there are location where the same concept is described with a different names
> wh
Hi all,
I'm taking another swing at this one. I've taken a minimal approach compared to
my previous proposals.
Briefly, AbstractSet.removeAll switches from iterating this collection and
calling contains() on its argument, to iterating the argument and calling
this.contains(), if the argument
Please review fix [2] for jpackage bug [1].
Fix vs2019 compliation error.
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8244220
[2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
Redirecting to core-libs-dev (with a Bcc to code-tools-dev)
Code signing for macOS, along with the addition of notarization, has
been improved for JDK 15. You might want to try the EA builds of JDK 15,
which are available here:
https://jdk.java.net/15/
-- Kevin
On 5/1/2020 8:13 AM, Adam Ca
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
+1,
BTW, Stuart you are a Reviewer, no need for a 2nd.
Roger
On 5/1/20 12:02 AM, Stuart Marks wrote:
Hi Jay,
OK, welcome! I'll sponsor this changeset for you. It's pretty simple,
so I'll just paste the exported changeset below. (For complicated
changesets, you'll have to ask a sponsor to h
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 to
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 th
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
parall
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 by
Thank you, I got it. I have one more a bit unrelated question.
The checked, synchronized and unmodifiable wrappers in some cases store
backing collection in more than one fields.
Thus `UnmodifiableList` has
1. its own field `List list` and
2. `Collection c`, which it inherits from
`UnmodifiableCo
24 matches
Mail list logo
