On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
This pull request has now been integrated.
Changeset: 5cf7947c
> Please review this PR which implements toString() for the `Format`
> subclasses. Corresponding CSR:
> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>
> The general specification follows a template that provides the locale (if the
> class is localized) and any relevant patterns.
On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu wrote:
>> Please review this PR which implements toString() for the `Format`
>> subclasses. Corresponding CSR:
>> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>>
>> The general specification follows a template that provides the locale
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
On Wed, 10 Jan 2024 06:00:18 GMT, Joe Darcy wrote:
> Add a few apiNote concerning source-level modifiers that are not represented
> in java.lang.reflect.Modifier.
This pull request has now been integrated.
Changeset: 9e9c05f0
Author:Joe Darcy
URL:
On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu wrote:
>> Please review this PR which implements toString() for the `Format`
>> subclasses. Corresponding CSR:
>> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>>
>> The general specification follows a template that provides the locale
On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu wrote:
> Please review this PR which is a backport of commit
> [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The original commit was a
On Wed, 10 Jan 2024 18:56:45 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Small space optimization.
Thanks for the updates.
> Please review this PR which implements toString() for the `Format`
> subclasses. Corresponding CSR:
> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>
> The general specification follows a template that provides the locale (if the
> class is localized) and any relevant patterns.
On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu wrote:
> Please review this PR which is a backport of commit
> [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The original commit was a
On Fri, 12 Jan 2024 18:27:55 GMT, Justin Lu wrote:
>> Please review this PR which implements toString() for the `Format`
>> subclasses. Corresponding CSR:
>> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>>
>> The general specification follows a template that provides the locale
I generated runtime images using `jlink --compress 2 --add-modules
java.se,jdk.unsupported,jdk.management` and then ran the following JMH
benchmark:
@Warmup(iterations = 10, time = 2)
@Measurement(iterations = 5, time = 3)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g",
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Fri, 12 Jan 2024 18:17:23 GMT, Mandy Chung wrote:
> The plan [1] is to remove the old compression values `0`, `1`, `2` in the
> future and only support the zip compression `--compress zip-[0-9]`, i.e. the
> string sharing plugin will be removed as there isn't any known customer usage
> of
On Thu, 11 Jan 2024 19:42:42 GMT, Naoto Sato wrote:
> I think test cases for these new overridden `toString()` methods would be
> helpful.
Added test cases for the new methods. Additionally, in the most recent commit,
I swapped the placement of `compact patterns` with `decimal pattern`. As
Please review this PR which is a backport of commit
[4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The original commit was a test-only change which optimized and split up the
> Please review this PR which implements toString() for the `Format`
> subclasses. Corresponding CSR:
> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>
> The general specification follows a template that provides the locale (if the
> class is localized) and any relevant patterns.
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
> Add a few apiNote concerning source-level modifiers that are not represented
> in java.lang.reflect.Modifier.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Reflow paragraph.
-
Changes:
- all:
On Fri, 5 Jan 2024 09:07:57 GMT, Stefan Karlsson wrote:
>> Tests using ProcessTools.executeProcess gets the following output written to
>> stdout:
>> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
>> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process
On Fri, 12 Jan 2024 07:38:12 GMT, Joe Darcy wrote:
>> Add a few apiNote concerning source-level modifiers that are not represented
>> in java.lang.reflect.Modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refine
On Fri, 12 Jan 2024 15:17:42 GMT, Per Minborg wrote:
> This PR proposes to remove the snippet files in
> `java/lang/foreign/snippet-files` from the build.
make/modules/java.base/Java.gmk line 41:
> 39: java/lang/classfile/snippet-files \
> 40:
On Thu, 28 Dec 2023 15:19:23 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>
> Jan Kratochvil has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix gtest testcases compilation errors
It looks like this patch needs a
On Fri, 8 Dec 2023 22:38:56 GMT, Claes Redestad wrote:
>> Does anyone want to take a look at this PR?
>
>> Does anyone want to take a look at this PR?
>
> RFE: https://bugs.openjdk.org/browse/JDK-8321620 - update the bug ID and this
> should PR should reach a wider audience. I'll have some
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan wrote:
> Reviewed-by: Yi Yang
The test case before this PR has a maximum heap of 64MB and applies for 8M of
memory each time in the for loop. When applying for memory for the sixth time,
it was killed by the docker container because of OOM,
This PR proposes to remove the snippet files in
`java/lang/foreign/snippet-files` from the build.
-
Commit messages:
- Exclude snipet files
Changes: https://git.openjdk.org/jdk/pull/17403/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17403=00
Issue:
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
timed offer
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17393/files
- new:
On Fri, 12 Jan 2024 15:02:59 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional
> commit since the last revision:
>
> timed offer
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
add test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17393/files
- new:
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
Marked as reviewed by dfuchs (Reviewer).
-
PR Review:
On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg wrote:
> 8321786: SegmentAllocator:allocateFrom(ValueLayout,
> MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
This pull request has now been integrated.
Changeset: 3909d74a
Author:Per Minborg
URL:
On Wed, 10 Jan 2024 15:23:01 GMT, Maurizio Cimadamore
wrote:
>> test/jdk/java/foreign/TestSegmentAllocators.java line 234:
>>
>>> 232: // WrongThreadException if this method is called from a
>>> thread {@code T},
>>> 233: // such that {@code source.isAccessibleBy(T) ==
> This PR proposes to add a clarification that an `Arena` always returns
> zeroed-out segments for `Arena::allocate` methods.
>
> Note that other overloaded methods refer to the abstract `Arena::allocate`
> method via implementation notes.
Per Minborg has updated the pull request incrementally
On Mon, 4 Dec 2023 13:56:55 GMT, Doug Lea wrote:
>> This update cascades timeouts to trim subsequent workers after the first
>> keepAlive inactive period.
>
> Doug Lea has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the
> This PR proposes to add a clarification that an `Arena` always returns
> zeroed-out segments for `Arena::allocate` methods.
>
> Note that other overloaded methods refer to the abstract `Arena::allocate`
> method via implementation notes.
Per Minborg has updated the pull request incrementally
On Fri, 12 Jan 2024 13:06:39 GMT, Per Minborg wrote:
>> This PR proposes to add a clarification that an `Arena` always returns
>> zeroed-out segments for `Arena::allocate` methods.
>>
>> Note that other overloaded methods refer to the abstract `Arena::allocate`
>> method via implementation
On Fri, 12 Jan 2024 13:06:39 GMT, Per Minborg wrote:
>> This PR proposes to add a clarification that an `Arena` always returns
>> zeroed-out segments for `Arena::allocate` methods.
>>
>> Note that other overloaded methods refer to the abstract `Arena::allocate`
>> method via implementation
> This PR proposes to add a clarification that an `Arena` always returns
> zeroed-out segments for `Arena::allocate` methods.
>
> Note that other overloaded methods refer to the abstract `Arena::allocate`
> method via implementation notes.
Per Minborg has updated the pull request incrementally
On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty wrote:
> Update LinkedTransferQueue add and put methods to not call overridable.
FTR - I agree that it's kinda annoying to be proposing this change and it is
true that the consuming user code is making an assumption, but the impact of
this is
On Fri, 12 Jan 2024 11:54:06 GMT, Alan Bateman wrote:
> I think this one will require digging into whether the no-arg read is used in
> the authentication or not. It might not be, in which case it's not testable
> with something that emulates LDAPv3. However if it is used then we should
>
On Fri, 12 Jan 2024 11:54:06 GMT, Alan Bateman wrote:
> I think this one will require digging into whether the no-arg read is used in
> the authentication or not.
Digging into this, it seems this was looked at last year and the conclusion was
this code is not used, but for some reason there
On Fri, 12 Jan 2024 12:10:46 GMT, Chris Hegarty wrote:
>>> this PR is against mainline, but the issue's Fix Version/s is 22.
>>
>> I updated the fix version in JIRA, and followed the process as outlined in
>> https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html
>
>>
On Fri, 12 Jan 2024 11:22:13 GMT, Chris Hegarty wrote:
>>> A process-related comment: this PR is against mainline, but the issue's Fix
>>> Version/s is 22. This will create a bit of a mess if integrated.
>>
>> Thanks for the reminder Pavel. If accepted, then the change will be
>> applicable
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
On Fri, 12 Jan 2024 11:43:23 GMT, Aleksey Shipilev wrote:
> No need, that one is an easy target for static analyzers. This bug was found
> by one :)
I think this one will require digging into whether the no-arg read is used in
the authentication or not. It might not be, in which case it's not
On Fri, 12 Jan 2024 11:22:13 GMT, Chris Hegarty wrote:
>>> A process-related comment: this PR is against mainline, but the issue's Fix
>>> Version/s is 22. This will create a bit of a mess if integrated.
>>
>> Thanks for the reminder Pavel. If accepted, then the change will be
>> applicable
On Fri, 12 Jan 2024 07:33:07 GMT, Sergey Bylokhov wrote:
> Just curious if this was found by inspection or when debugging some issue
> with LDAP authentication? Asking on whether it is feasible or not to have
> more tests in this area.
No need, that one is an easy target for static analyzers.
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
Looks fine. I think the common style is to use capitalized `0xFF`, but
On Fri, 12 Jan 2024 11:11:51 GMT, Chris Hegarty wrote:
> this PR is against mainline, but the issue's Fix Version/s is 22.
I updated the fix version in JIRA, and followed the process as outlined in
https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html
-
PR Comment:
On Thu, 11 Jan 2024 07:59:37 GMT, Per Minborg wrote:
>> This PR proposes to add a clarification that an `Arena` always returns
>> zeroed-out segments for `Arena::allocate` methods.
>>
>> Note that other overloaded methods refer to the abstract `Arena::allocate`
>> method via implementation
On Fri, 12 Jan 2024 11:07:17 GMT, Pavel Rappo wrote:
> A process-related comment: this PR is against mainline, but the issue's Fix
> Version/s is 22. This will create a bit of a mess if integrated.
Thanks for the reminder Pavel. If accepted, then the change will be applicable
to 23, 22, and
On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty wrote:
> Update LinkedTransferQueue add and put methods to not call overridable.
A process-related comment: this PR is against mainline, but the issue's Fix
Version/s is 22. This will create a bit of a mess if integrated.
-
PR
On Fri, 12 Jan 2024 11:03:02 GMT, Alan Bateman wrote:
> This feels more like a hazard when extending to override behavior.
Yeah, this is certainly a potential issue with any subclass-able class. I
remember seeing similar before in other areas too.
> I think it would be useful to provide a
On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty wrote:
> Update LinkedTransferQueue add and put methods to not call overridable.
This feels more like a hazard when extending to override behavior. I think it
would be useful to provide a summary on what the override wants to do, maybe
there are
Update LinkedTransferQueue add and put methods to not call overridable.
-
Commit messages:
- Update LinkedTransferQueue add and put methods to not call overridable offer
Changes: https://git.openjdk.org/jdk/pull/17393/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17393=00
On Thu, 11 Jan 2024 17:49:42 GMT, Erik Joelsson wrote:
> Fair enough. This isn't worse than the current CWD. The test image dir and
> the support output dir have no guaranteed relationship relative to each
> other, so we can't rely any relative path between them.
Thanks! Perhaps we can
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar
On Fri, 12 Jan 2024 01:10:49 GMT, Leonid Mesnik wrote:
> Needed to update copyrights now.
Even when the code was written in 2023?
-
PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1888699636
On Thu, 11 Jan 2024 19:21:00 GMT, Joshua Cao wrote:
>>> We don't need to compute max() here.
>>> [tryPresize()](https://github.com/openjdk/jdk/blob/8a4dc79e1a40e7115e2971af81623b6b0368f41c/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2397)
>>> does that already.
>>
On Wed, 10 Jan 2024 20:25:21 GMT, Alan Bateman wrote:
> This test was recently dialled down via JDK-8323002 but it still makes slow
> progress on some test machines, esp. macox-x64-debug builds. The issue is
> that the sampling of the target thread is skewed towards the unmounted case
> so
62 matches
Mail list logo
