On Tue, 9 Apr 2024 21:36:46 GMT, Vladimir Yaroslavskiy wrote:
>>> Hi Vamsi (@vamsi-parasa), few questions on your test environment:
>>>
>>> * what are the hardware specs of your server ?
>>> * bare-metal or virtual ?
>>> * are other services or big processes running ?
>>> * os tuning ? CPU HT:
On Sat, Apr 20, 2024 at 8:29 PM ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com> wrote:
> Gatherers could be effectively terminal, but I don't think Gatherer API
> designers intended it to be. In related JEP, gatherers are described as a
> way to declare custom intermediate operations, and
Gatherers could be effectively terminal, but I don't think Gatherer API
designers intended it to be. In related JEP, gatherers are described as a
way to declare custom intermediate operations, and introducing "terminal"
gatherers would be misleading.
Talking about performance, not even
On Sat, Apr 20, 2024 at 7:44 PM ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com> wrote:
> Also enumerated stream should also support index-aware terminal
> operations, which getherers are incapable of, so it will also require to
> create index-aware collectors. I am not aware if this is even
Also enumerated stream should also support index-aware terminal operations,
which getherers are incapable of, so it will also require to create
index-aware collectors. I am not aware if this is even possible, but this
looks like another separate functionality in different place, and some
>
> 1. Batch tasks processing, especially in concurrent environments, when
> tasks could have different priorities. Sometimes tasks that are stored in a
> queue are processed in batches. Using today's stdlib of Java,
> acquiring such a batch of tasks from collection would be a O(n * log n)
>
Yes, I think every possible intermediate operation could be made index
aware using gatherers. The point is: should it be turned?
As a developers of jdk itself, we are not limited in a ways we could
provide tools for Java users, especially when it comes to adding completely
new features and not
My point is that we can create Gatherers that gather indexed elements
(indexed gatherer), and another factory wraps the Gatherer so the index
boxing and automatically performed before sending to the indexed gatherer.
All other stream operations, like indexed filter, indexed collect, etc. can
all
I am sorry, but I feel like I am missing the point of your response and how
is it related to what I have said.
Regarding wrapping and unwrapping indexed pairs, one of advantages of the
approach I have suggested is that EnumeratedStream is still a stream and
all index-unaware ops could still be
We must convert index-processing operations to a `gather(Gatherers.scan(/*
index gathering */))` immediate before the operation that uses the index,
and immediately unwrap the indices afterwards.
Syntactically writing such 3 lines for every index-aware operation would be
weird; I actually wonder
I would like to correct myself a bit: indexes should be assigned at the
moment an element is received from upstream, not when it is passed to
processing. Not sure if it will effectively change order of execution in
actual implementation, but to put it this way would be more precise
вс, 21 апр.
Hello again.
I have imagined implementation of enumerated streams in a slightly
different way. I think enumerated streams should be a separate kind of
stream like parallel, sequential or some primitive stream. This way
enumeration could be deferred to the time that index is being consumed,
This
Hello!
The example you have provided is indeed a workaround. Such a setup indeed
covers most of the problems, nothing I could get from the top of my head
that can't be accomplished using this.
However, there are a few downsides:
1. Obvious performance and memory overhead. I think no elaboration
Hi Oleksandr,
I fear that enumeration might not be applicable to all streams, especially
parallel ones. If we have a parallel stream, we might not always process
all elements in order, and even index generation can be unreliable. In
addition, stream merging will become a headache. I think
Hi IP-24 Oleksandr Rotan',
You can use a Map>. This map stores T as the object
equivalence key, and each Collection in this map stores the values known
to be equal to the key. Since map compares keys by equals, any key in the
collection can be used to find the collection in the Map>.
If you want
On Sat, 20 Apr 2024 19:09:43 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
> this change.
>
> Overall, making this an intrinsic improves overall performance of
> `Unsafe::setMemory` by up to 4x for all buffer sizes.
Also, after some research, I found that HashMultisets also have some area
of application in image detection and event simulations
вс, 21 апр. 2024 г. в 01:19, ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com>:
> Sorry for duplicate, I accidentally sent last message only to you
>
> вс, 21 апр.
Firstly, about queues. As far as I know, priority queue is implemented as
heap, not tree, so things like subQueue doesn't make much sense in this
context.
About popularity: this is indeed not very popular, might even be negligible
outside of sorted multiset (lets adopt java naming conventions for
Yes, your point about enumeration is the best way to do it, i guess, I am
also voting for this. This makes the most sense considering the way that
method invocation chains should be handled
вс, 21 апр. 2024 г. в 00:55, David Alayachew :
> I am in full support of this idea. I do also appreciate
Biggest use case is definitely when creating different histograms from the
same dataset. Our friends in sci-py land spend A LOT of time doing this.
Our R friends also use this frequently.
I can imagine this bag implementation would not just be good for
Collections, but would play well with the
I am in full support of this idea. I do also appreciate the functionality
of using a BiFunction on the map method instead of a normal
Function, R>.
As for the actual enumeration logic, my vote is that it should simply
enumerate as it arrives, with no context or care given to what came before
it.
Let me prefix this by saying that I'm a mathematician, so maybe the lingo I
use is a bit different. A multi set has no structure apart from "counting
duplication", just like a set has no structure at all, ordered set **is not
a set** and ordered multi set **is not a multi set**.
With the
My proposal regarding findIndex brought up a topic that, as I see, has been
brought up here multiple times.
My idea is to extend the existing stream interface in the new
EnumeratedStream interface. Such an approach has a number of advantages.
1. Some methods will be able to explicitly specify
I won't stop you, but remember, you are not the one maintaining the large
number of collection implementations in the JDK. The ones who are may feel
differently. This FAQ gives a good hint of their opinion, even to your
retorts.
On Sat, Apr 20, 2024, 4:44 PM ІП-24 Олександр Ротань <
Concurrent Bag is something like CopyOnWriteArrayList or Vector, don't we
have it already? (I know vectors aren't optimized). THe whole point of the
bag is to store duplicate elements without preserving order, which allows
things like ordered collections. There could be mutable collections for
By "ordered collection" you mean "unordered collection"?
How common is it to actually use a multiset in general? Of course there are
use cases, and there are areas in which it is used a lot, but I don't
believe it is common enough to be part of the std with the one exception of
concurrent bag.
On Sat, 20 Apr 2024 19:09:43 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
I agree with the point made in the FAQ about the popularity of such
problems. That said, I don't think that it is that unpopular to be ignored.
Regarding Map.values(), this is the case, but, In my experience, one of the
main advantages of using TreeMultiset was O(long n) modification
complexity.
Your Bag suggestion has been asked so frequently that there is an FAQ entry
in the official Java Docs.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
On Sat, Apr 20, 2024 at 4:25 PM ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com> wrote:
In this letter I would like to express some of my thoughts regarding the
potential Multiset interface.
I, personally, have encountered a few situations where such an interface
could come in handy, mostly when I needed an ordered collection that
permits duplicates. That time I used guava`s
On Sat, 20 Apr 2024 04:28:43 GMT, Vladimir Kozlov wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Long to short jmp; other cleanup
>
> `runtime/Unsafe/InternalErrorTest.java` test SIGBUS when run with `-Xcomp`
>
On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
On Sat, 20 Apr 2024 14:14:59 GMT, Jatin Bhateja wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Long to short jmp; other cleanup
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2530:
>
>> 2528:
> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
> this change.
>
> Overall, making this an intrinsic improves overall performance of
> `Unsafe::setMemory` by up to 4x for all buffer sizes.
On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
Regarding what Holo said, I think enumerated() would be a more suitable
name.
I have few ideas about implementation of such things, like separate
EnumeratedStream interface, which extends stream and provides methods like
forEach(BiConsumer), etc. This would eliminate unnecessary
object
Fix the description of java.io.Serializable.
-
Commit messages:
- Inconsistent use of semicolon in the code snippet of java.io.Serializable
javadoc
Changes: https://git.openjdk.org/jdk/pull/18874/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18874=00
Issue:
Hello,
I want to challenge the idea that every stream may be indexed for 3 reasons:
Any sensible type to use for an index (int/long) will be bounded, but
streams need not, e.g.
new Random().ints().withIndex().forEach(v -> ...);
May result (after a very long time) non sensical values. Using
Fix typos within the `DatabaseMetaData.java`.
-
Commit messages:
- Merge branch 'master' of github.com:onacit/jdk
- Merge branch 'master' of github.com:onacit/jdk
- Fix more typos
- Fix typo
- Fix wrongly typed constant name
- Fix more typos
- Fix typo
- Fix wrongly typed
On Fri, 19 Apr 2024 11:36:48 GMT, Jin Kwon wrote:
>> Fix typos within the `DatabaseMetaData.java`.
>
> @openjdk with issue from where?
Hello @onacit, it appears a JBS issue has been filed for this
https://bugs.openjdk.org/browse/JDK-8330686. Please change the title of this PR
to `8330686: Fix
On Fri, 19 Apr 2024 11:33:48 GMT, Jin Kwon wrote:
> Fix typos within the `DatabaseMetaData.java`.
@openjdk with issue from where?
-
PR Comment: https://git.openjdk.org/jdk/pull/18860#issuecomment-2066389888
On Fri, 5 Apr 2024 23:13:39 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Sat, 20 Apr 2024 00:00:54 GMT, ExE Boss wrote:
>> We can reduce overhead of first use of a switch bootstrap by moving
>> `typePairToName` into `TypePairs` and by explicitly overriding `hashCode`
>> and `equals`. The first change avoids loading and initializing the
>> `TypePairs` class in
Hi Rotan',
Interface methods are both exposed to callers and to implementations. Is
there any scenario where the implementation can be more efficient than the
stream/gatherer scanning approach?
indexOf or lastIndexOf may be faster if a list has some tricks like a
hashmap to quickly look up the
45 matches
Mail list logo
