On Thu, 25 Aug 2022 19:10:19 GMT, Сергей Цыпанов wrote:
>> Maybe you can modify the `read0` method to receive a width parameter
>> additionally. Or we can wait for Panama and use `mmap` for this instead of
>> JNI? Thanks.
>
>> Maybe you can modify the read0 method to receive a width parameter
On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti wrote:
>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8065554: MatchResult should provide values
On Wed, 24 Aug 2022 18:22:42 GMT, Raffaello Giulietti wrote:
>> In principle, yes. In practice, I see that `namedGroups` doesn't have an
>> `@throws UnsupportedOperationException` but has an `@implSpec` that says
>> that the default implementation throws `UnsupportedOperationException`. This
On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti wrote:
>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8065554: MatchResult should provide values
On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti wrote:
>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8065554: MatchResult should provide values
On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti wrote:
>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8065554: MatchResult should provide values
On Thu, 25 Aug 2022 09:24:20 GMT, Raffaello Giulietti wrote:
>> Add support for named groups to java.util.regex.MatchResult
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8065554: MatchResult should provide values
On Thu, 25 Aug 2022 16:58:29 GMT, Mahendra Chhipa wrote:
>> Added tests for namespace Axis. Tests incluse namspace expressions,
>> namespace node counts and namespace node scope.
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last
On Wed, 27 Jul 2022 10:47:44 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The superclass `java.io.InputStream`
On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato wrote:
> This is to enhance the character break analysis in `java.text.BreakIterator`
> to conform to the extended grapheme cluster boundaries defined in
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
> corresponding CSR has
On Thu, 25 Aug 2022 03:52:48 GMT, Stuart Marks wrote:
>> This is to enhance the character break analysis in `java.text.BreakIterator`
>> to conform to the extended grapheme cluster boundaries defined in
>> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
>> corresponding
On Thu, 25 Aug 2022 17:58:05 GMT, Quan Anh Mai wrote:
> Maybe you can modify the read0 method to receive a width parameter
> additionally.
@merykitty sorry, I don't get it. We already have `readBytes0()` returning
array. Why do we need to add a new param to `read0`?
-
PR:
On Thu, 25 Aug 2022 17:31:05 GMT, Brian Burkhalter wrote:
>> Currently some operations of RandomAccessFile are implemented with multiple
>> read() invocations:
>>
>> public final int readInt() throws IOException {
>> int ch1 = this.read();
>> int ch2 = this.read();
>> int ch3 =
On Thu, 25 Aug 2022 16:33:57 GMT, Severin Gehwolf wrote:
>> I've pushed a small excerpt of the changes from #9880 in
>> 1bf3aa341fd93079289f11e620938e6bed40b382 to this PR in order to add the log
>> lines that the tests depend on.
>
> We cannot have this in both PRs, though.
Indeed: even
On Thu, 25 Aug 2022 17:14:20 GMT, Сергей Цыпанов wrote:
> Currently some operations of RandomAccessFile are implemented with multiple
> read() invocations:
>
> public final int readInt() throws IOException {
> int ch1 = this.read();
> int ch2 = this.read();
> int ch3 = this.read();
On Thu, 25 Aug 2022 17:14:20 GMT, Сергей Цыпанов wrote:
> Currently some operations of RandomAccessFile are implemented with multiple
> read() invocations:
>
> public final int readInt() throws IOException {
> int ch1 = this.read();
> int ch2 = this.read();
> int ch3 = this.read();
Currently some operations of RandomAccessFile are implemented with multiple
read() invocations:
public final int readInt() throws IOException {
int ch1 = this.read();
int ch2 = this.read();
int ch3 = this.read();
int ch4 = this.read();
if ((ch1 | ch2 | ch3 | ch4) < 0)
> We have a few reports that existing Weak* VarHandle tests are still flaky,
> for example on large AArch64 machines or small RISC-V machines.
>
> The flakiness is intrinsic to the nature of Weak* operations under tests,
> that can spuriously fail. The last attempt to fix these was
>
> Added tests for namespace Axis. Tests incluse namspace expressions, namespace
> node counts and namespace node scope.
Mahendra Chhipa has updated the pull request incrementally with one additional
commit since the last revision:
Implemented the review comments.
-
Changes:
-
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
> They use
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
> They use
On Thu, 25 Aug 2022 16:12:23 GMT, Jonathan Dowland wrote:
>> Yes. There is a feature to use dependent PRs, which could be used here. Just
>> target `pr/9880` instead of `master`.
>
> I've pushed a small excerpt of the changes from #9880 in
> 1bf3aa341fd93079289f11e620938e6bed40b382 to this PR
On Thu, 25 Aug 2022 15:32:08 GMT, Jonathan Dowland wrote:
>> Jonathan Dowland has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address nit
>>
>> Thanks Thomas Stuefe
>
> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
On Thu, 25 Aug 2022 16:09:01 GMT, Severin Gehwolf wrote:
>> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java line 53:
>>
>>> 51: DockerRunOptions opts = Common.newOpts(imageName);
>>> 52: String goodMem = Common.run(opts).firstMatch("total physical
>>> memory:
On Thu, 25 Aug 2022 16:08:11 GMT, Jonathan Dowland wrote:
>> When the container memory exceeds the physical host's memory, the Java
>> metrics reporting is wrong.
>>
>> https://bugs.openjdk.org/browse/JDK-8292541
>>
>> This is the equivalent core-libs fix for Hotspot's
>>
> When the container memory exceeds the physical host's memory, the Java
> metrics reporting is wrong.
>
> https://bugs.openjdk.org/browse/JDK-8292541
>
> This is the equivalent core-libs fix for Hotspot's
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>
On Thu, 25 Aug 2022 14:00:36 GMT, Severin Gehwolf wrote:
>> Jonathan Dowland has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address nit
>>
>> Thanks Thomas Stuefe
>
>
> When the container memory exceeds the physical host's memory, the Java
> metrics reporting is wrong.
>
> https://bugs.openjdk.org/browse/JDK-8292541
>
> This is the equivalent core-libs fix for Hotspot's
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>
On Thu, 25 Aug 2022 12:35:13 GMT, Jonathan Dowland wrote:
>> When the container memory exceeds the physical host's memory, the Java
>> metrics reporting is wrong.
>>
>> https://bugs.openjdk.org/browse/JDK-8292541
>>
>> This is the equivalent core-libs fix for Hotspot's
>>
On Thu, 25 Aug 2022 12:35:13 GMT, Jonathan Dowland wrote:
>> When the container memory exceeds the physical host's memory, the Java
>> metrics reporting is wrong.
>>
>> https://bugs.openjdk.org/browse/JDK-8292541
>>
>> This is the equivalent core-libs fix for Hotspot's
>>
On Thu, 25 Aug 2022 12:41:31 GMT, Jonathan Dowland wrote:
>> src/java.base/linux/native/libjava/CgroupMetrics.c line 41:
>>
>>> 39: Java_jdk_internal_platform_CgroupMetrics_getTotalMemorySize0
>>> 40: (JNIEnv *env, jclass ignored)
>>> 41: {
>>
>> Why not do it the same way hotspot does?
>>
On Thu, 25 Aug 2022 10:09:32 GMT, Thomas Stuefe wrote:
>> Jonathan Dowland has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> avoid calling subsystem.getMemoryLimit twice
>
> src/java.base/linux/native/libjava/CgroupMetrics.c line 41:
>
> When the container memory exceeds the physical host's memory, the Java
> metrics reporting is wrong.
>
> https://bugs.openjdk.org/browse/JDK-8292541
>
> This is the equivalent core-libs fix for Hotspot's
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>
On Thu, 25 Aug 2022 10:02:22 GMT, Thomas Stuefe wrote:
>> Jonathan Dowland has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address nit
>>
>> Thanks Thomas Stuefe
>
>
On Thu, 25 Aug 2022 10:07:15 GMT, Jonathan Dowland wrote:
>> When the container memory exceeds the physical host's memory, the Java
>> metrics reporting is wrong.
>>
>> https://bugs.openjdk.org/browse/JDK-8292541
>>
>> This is the equivalent core-libs fix for Hotspot's
>>
> When the container memory exceeds the physical host's memory, the Java
> metrics reporting is wrong.
>
> https://bugs.openjdk.org/browse/JDK-8292541
>
> This is the equivalent core-libs fix for Hotspot's
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>
When the container memory exceeds the physical host's memory, the Java metrics
reporting is wrong.
https://bugs.openjdk.org/browse/JDK-8292541
This is the equivalent core-libs fix for Hotspot's
[JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
On Thu, 25 Aug 2022 07:46:13 GMT, Сергей Цыпанов wrote:
> What is wrong with the change?
You'll need parentheses to make that work, changing it to use '|' would work
too.
-
PR: https://git.openjdk.org/jdk/pull/9956
> Add support for named groups to java.util.regex.MatchResult
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
8065554: MatchResult should provide values of named-capturing groups
-
Changes:
- all:
On Wed, 24 Aug 2022 15:48:38 GMT, Raffaello Giulietti wrote:
> Add support for named groups to java.util.regex.MatchResult
Addressed concerns about undocumented `UnsuportedOperationException`.
-
PR: https://git.openjdk.org/jdk/pull/1
On Sun, 21 Aug 2022 20:07:10 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
> They use
42 matches
Mail list logo
