On Wed, 31 Jul 2024 18:52:12 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>>
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the
Hi Anthony,
>The use case is a time series, which has methods to return a Stream of data
>points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are
>several Gatherer factory methods, one of which is `GathererDataPoint> withInterpolationAt(NavigableSet instants)`. If
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to
On Sat, 27 Jul 2024 15:01:30 GMT, fabioromano1 wrote:
>> On my M1 Pro/32 GiB
>>
>> Current
>>
>> Benchmark Mode CntScore
>> Error Units
>> BigIntegerSquareRoot.testBigSqrtAndRemainderavgt 15 45.655 ?
>> 0.273 ns/op
>>
On Tue, 30 Jul 2024 19:00:13 GMT, Archie Cobbs wrote:
> Another (more conservative) possibility is to preserve both 1 ("Trailing
> garbage is ignored") and 3 ("Concatenated streams are automatically decoded")
> in the default configuration.
>
> Then basically all we would be changing is no
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to
This test spawns 2 forked processes, which then try to trigger a code cache OOM
in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow,
which increases dramatically with `-Xcomp`, since startup Java code has to be
compiled 3 times, once for the main test process, and then 2
On Sun, 28 Jul 2024 15:59:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the
> First pass at adding some quality of implementation discussions around the
> overridable methods of Object.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull
On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
On Tue, 30 Jul 2024 17:35:33 GMT, Lance Andersen wrote:
> Based on the above, I am reluctant to change the current behavior given it
> appears to have been modeled after gzip/gunzip as well as WinZip.
That's a reasonable conclusion... and I have no problem with preserving the
existing
On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote:
> Removes 6 `AccessFlags` factories that do not take class-file versions as its
> arguments.
>
> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in
> ClassFile API. It additionally supports advanced validation
On Mon, 29 Jul 2024 19:36:31 GMT, Chen Liang wrote:
> In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of
> mutable and immutable lists.
>
> Though the mutability of the list returned by `verify` has no particular
> importance, as the mutable list is constructed on
On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
July 29, 2024 at 8:08 PM, "Viktor Klang" wrote:
>
> Hi Anthony,
Hi Viktor
> Thank you for your patience, and for providing feedback, it is always much
> appreciated.
>
> >When writing factory methods for Gatherers, there's sometimes a
> degenerate case that requires returning a no-op
On Wed, 24 Jul 2024 12:20:05 GMT, Vanitha B P wrote:
> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently,
> fixed the issue and changes are tested.
This pull request has now been integrated.
Changeset: 2c9fd901
Author:Vanitha B P
Committer: Alexey Semenyuk
URL:
On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang wrote:
> Removes some of the old wording around the algorithmic complexity of
> ConcurrentSkipListSet::size() while still retaining the warning around the
> accuracy of the returned result.
Yes, thanks for fixing wording that should have been
On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang wrote:
> Removes some of the old wording around the algorithmic complexity of
> ConcurrentSkipListSet::size() while still retaining the warning around the
> accuracy of the returned result.
@DougLea Please let me know what you think about this
Removes some of the old wording around the algorithmic complexity of
ConcurrentSkipListSet::size() while still retaining the warning around the
accuracy of the returned result.
-
Commit messages:
- Improving the JavaDoc of ConcurrentSkipListSet::size() to reflect current
reality
On Mon, 29 Jul 2024 23:30:48 GMT, Chen Liang wrote:
>> Removes 6 `AccessFlags` factories that do not take class-file versions as
>> its arguments.
>>
>> `AccessFlags` is a wrapper around a bit mask to support modifier streaming
>> in ClassFile API. It additionally supports advanced validation
On Mon, 29 Jul 2024 19:36:31 GMT, Chen Liang wrote:
> In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of
> mutable and immutable lists.
>
> Though the mutability of the list returned by `verify` has no particular
> importance, as the mutable list is constructed on
On Mon, 29 Jul 2024 05:03:22 GMT, Jan Kratochvil
wrote:
>> src/hotspot/os/linux/cgroupUtil_linux.cpp line 64:
>>
>>> 62: return cpu->adjust_controller(cpu_total);
>>> 63: }
>>> 64: return cpu;
>>
>> I guess an alternative - and maybe more readable solution - would be to
>> inline
> The testcase requires root permissions.
>
> Fix by Severin Gehwolf.
> Testcase by Jan Kratochvil.
Jan Kratochvil has updated the pull request incrementally with two additional
commits since the last revision:
- Inline adjust_controller() twice
- Revert "Unify 4 copies of
> The testcase requires root permissions.
>
> Fix by Severin Gehwolf.
> Testcase by Jan Kratochvil.
Jan Kratochvil has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commits:
- Implement vm.cgroup.tools
- Use
On Wed, 24 Jul 2024 16:42:52 GMT, Alexey Semenyuk wrote:
>> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently,
>> fixed the issue and changes are tested.
>
> @sashamatveev please review
@alexeysemenyukoracle @sashamatveev Can you please sponsor?
-
PR
On Tue, 30 Jul 2024 05:59:44 GMT, Vanitha B P wrote:
>> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently,
>> fixed the issue and changes are tested.
>
> Vanitha B P has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
> tools/jpackage/windows/WinChildProcessTest.java was failing intermittently,
> fixed the issue and changes are tested.
Vanitha B P has updated the pull request incrementally with one additional
commit since the last revision:
Vanitha B P
-
Changes:
- all:
On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote:
> Removes 6 `AccessFlags` factories that do not take class-file versions as its
> arguments.
>
> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in
> ClassFile API. It additionally supports advanced validation
> Removes 6 `AccessFlags` factories that do not take class-file versions as its
> arguments.
>
> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in
> ClassFile API. It additionally supports advanced validation based on location.
>
> However, as class file versions
On Mon, 1 Jul 2024 19:20:48 GMT, Chen Liang wrote:
> Clarify that only `Class` is returned for core reflection implementation, and
> the return type is `Type` to support other implementations, such as ones
> modeling unloaded or remote types.
Keep-alive.
-
PR Comment:
On Mon, 1 Jul 2024 18:22:48 GMT, Chen Liang wrote:
> Clarify that `ParameterizedType.getOwnerType()` always return `null` in a few
> scenarios.
Keep-alive.
-
PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2257160095
On Mon, 29 Jul 2024 20:51:39 GMT, Raffaello Giulietti
wrote:
>>> The following variant should be preferred, as it has a readable figure on
>>> p. 21, whereas the same figure in the variant linked in the PR seems broken
>>> for some reason. https://inria.hal.science/inria-00072113/document
>>
Hi Bernd,
The issue with the infinite directory tree you observe looks like a
duplicate of [1].
You can add "--verbose" option to jpackage command line to get more
details on what is going on with jpackage.
There is no way to configure the list of directories where native
launcher is
On Thu, 25 Jul 2024 22:41:08 GMT, Chen Liang wrote:
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus,
On Mon, 29 Jul 2024 12:32:10 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
On Mon, 29 Jul 2024 18:25:54 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 550:
>>
>>> 548: */
>>> 549: void safeRightShift(int n) {
>>> 550: if (n >= bitLength()) {
>>
>> The commit message for this reads `More accurate
Hello,
I noticed some jpackage pecularities:
1 - if you use "-i ." (and no target) it will not ignore its target
directory and recursively copy itself generating a massive deep directory
tree hard to remove.
Sample command:
jpackage --type app-image -n MyApp --main-class myapp.Main
In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of
mutable and immutable lists.
Though the mutability of the list returned by `verify` has no particular
importance, as the mutable list is constructed on every call and does not
mutate the models, there are a few
On Fri, 26 Jul 2024 19:17:34 GMT, Justin Lu wrote:
> Please review this PR which is a simple doc only change to
> java.text.DecimalFormat.
>
> Mainly, the DecimalFormat constructors have wording that recommends using the
> NumberFormat factory methods for a standard formatting. This would be
On Mon, 29 Jul 2024 16:48:32 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> If the input is a square, then s0 == 0, so testing for non-zero remainder
>> is redundant
>
>
On Mon, 29 Jul 2024 16:50:32 GMT, Raffaello Giulietti
wrote:
> Also, I wonder if it wouldn't be simpler for `len` to represent the `int`
> length of the square root rather than the `int` length of the argument. It
> would be more consistent with the Bertot, Magaud, Zimmermann paper and might
Hi Anthony,
Thank you for your patience, and for providing feedback, it is always much
appreciated.
>When writing factory methods for Gatherers, there's sometimes a
degenerate case that requires returning a no-op Gatherer. So I'd like a
way to mark a no-op Gatherer as such, allowing the Stream
On Mon, 29 Jul 2024 16:50:10 GMT, Raffaello Giulietti
wrote:
> The following variant should be preferred, as it has a readable figure on p.
> 21, whereas the same figure in the variant linked in the PR seems broken for
> some reason. https://inria.hal.science/inria-00072113/document
What is
On Mon, 29 Jul 2024 17:00:09 GMT, Raffaello Giulietti
wrote:
> Sorry, not `<<` but `*`
or `(x.intLen & 1) << 5`
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695649080
On Mon, 29 Jul 2024 14:27:28 GMT, Lance Andersen wrote:
> ... we really need more datapoint to better understand the risks/benefits in
> order to make an informed decision.
Agreed.
Here's some what I've come up with after a little bit of research:
First, we shouldn't confuse GZIP with ZIP
On Mon, 29 Jul 2024 16:49:04 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> If the input is a square, then s0 == 0, so testing for non-zero remainder
>> is redundant
>
>
On Mon, 29 Jul 2024 13:18:16 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>>
On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote:
> This fix is to address the tier_1 test run on Windows taking much longer time
> than before. The test case creates child processes that remain behind after
> the test run has completed, which is problematic on Windows as the make
> command
On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote:
> This fix is to address the tier_1 test run on Windows taking much longer time
> than before. The test case creates child processes that remain behind after
> the test run has completed, which is problematic on Windows as the make
> command
On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote:
> This fix is to address the tier_1 test run on Windows taking much longer time
> than before. The test case creates child processes that remain behind after
> the test run has completed, which is problematic on Windows as the make
> command
On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote:
> This fix is to address the tier_1 test run on Windows taking much longer time
> than before. The test case creates child processes that remain behind after
> the test run has completed, which is problematic on Windows as the make
> command
On Mon, 29 Jul 2024 15:49:10 GMT, Naoto Sato wrote:
> This fix is to address the tier_1 test run on Windows taking much longer time
> than before. The test case creates child processes that remain behind after
> the test run has completed, which is problematic on Windows as the make
> command
This fix is to address the tier_1 test run on Windows taking much longer time
than before. The test case creates child processes that remain behind after the
test run has completed, which is problematic on Windows as the make command
waits for the process to terminate. Confirmed tier_1/part_1
On Mon, 29 Jul 2024 13:52:57 GMT, Archie Cobbs wrote:
> > So where does that leave us:
> > Keep the code as is and document the current behavior
> > Continue to add additional test coverage for the current API
> > We probably do not need a new constructor given it probably adds no new
> >
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
> For example, on cg v2, the memory limit interface file is `memory.max`.
>
On Mon, 22 Jul 2024 13:48:29 GMT, Severin Gehwolf wrote:
>> Jan Kratochvil has refreshed the contents of this pull request, and previous
>> commits have been removed. Incremental views are not available.
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 193:
>
>> 191: }
> The testcase requires root permissions.
>
> Fix by Severin Gehwolf.
> Testcase by Jan Kratochvil.
Jan Kratochvil has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 260 commits:
- Implement vm.cgroup.tools
- Use
On Mon, 29 Jul 2024 13:06:24 GMT, Lance Andersen wrote:
> So where does that leave us:
>
>Keep the code as is and document the current behavior
>Continue to add additional test coverage for the current API
>We probably do not need a new constructor given it probably adds no new
>
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the
On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
On Mon, 29 Jul 2024 07:36:15 GMT, Jaikiran Pai wrote:
>> So how should we proceed this? This problem is critical for some modularized
>> applications as I said before.
>>
>> I agree that we need to consider the approach for this, but it is worth to
>> provide the fix even if it is short-term,
On Mon, 29 Jul 2024 12:32:10 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus, the proposed solution is to move these APIs to be
>
On Mon, 29 Jul 2024 02:22:11 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
On Mon, 29 Jul 2024 02:22:11 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
On Sun, 28 Jul 2024 06:24:38 GMT, Yasumasa Suenaga wrote:
>> We cannot pass GNU style options like `--enable-preview` to `jlink
>> --add-option`. It is hard to use for complex application.
>>
>> We have workaround for this issue (see JBS), but I think it is better to fix
>> on JDK side.
>
>
On Fri, 19 Jul 2024 15:36:10 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>>
On Mon, 22 Jul 2024 09:07:31 GMT, Severin Gehwolf wrote:
>> Jan Kratochvil has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Unify 4 copies of adjust_controller()
>
> src/hotspot/os/linux/cgroupUtil_linux.cpp line 64:
>
>> 62: return
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus, the proposed solution is to move these APIs to be
>
On Mon, 29 Jul 2024 00:37:21 GMT, ExE Boss wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits
On Sun, 28 Jul 2024 02:39:23 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations.
On Sun, 28 Jul 2024 15:52:03 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
1. fix handle
On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the
On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Fri, 26 Jul 2024 15:32:18 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3818:
>>
>>> 3816: }
>>> 3817: // add fraction
>>> 3818: if (fractionalDigits > 0) {
>>
>> This breaks the logic.
On Fri, 26 Jul 2024 15:44:59 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one
On Thu, 25 Jul 2024 23:36:02 GMT, Shaojin Wen wrote:
>> test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47:
>>
>>> 45: @Measurement(iterations = 5, time = 1000, timeUnit =
>>> TimeUnit.MILLISECONDS)
>>> 46: @Fork(value = 3, jvmArgsAppend =
>>>
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Sat, 27 Jul 2024 23:08:36 GMT, Shaojin Wen wrote:
> Should mixer and prepend add the two types of Integer and Long? Now we need
> to do integer.toString and then concatenate, which leads to performance
> degradation.
I think the generic problem with specializing on types is that this leads
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Thu, 25 Jul 2024 14:52:11 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the
On 27/07/2024 21:24, Сергей Цыпанов wrote:
Hello,
I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads.
Can you bring it to loom-dev as this looks like another case where all
carriers are pinned, there is a mix of object monitors and
On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote:
> We cannot pass GNU style options like `--enable-preview` to `jlink
> --add-option`. It is hard to use for complex application.
>
> We have workaround for this issue (see JBS), but I think it is better to fix
> on JDK side.
So how
On Fri, 26 Jul 2024 13:17:11 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
>> line 67:
>>
>>> 65: this.maxLocals = Util.maxLocals(methodInfo.methodFlags(),
>>> methodInfo.methodTypeSymbol());
>>> 66: if (original !=
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus, the proposed solution is to move these APIs to be
>
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
This pull request has now been integrated.
Changeset: 2fbdbaca
Author:Shaojin Wen
Committer: Claes Redestad
URL:
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20344#pullrequestreview-2203242433
On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote:
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
>
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
@wenshao
Your change (at version d453e6c2837cf7d8802f7fea624324361e085edf) is now ready
to be sponsored by a Committer.
-
PR Comment:
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the
On Sat, 27 Jul 2024 14:44:15 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>>
Hello,
I've run into a concurrency issue manifested in application becoming frozen due
to pinned virtual threads.
Here I've described the reproduction steps in details:
https://stackoverflow.com/questions/78790376/spring-boot-application-gets-stuck-when-virtual-threads-are-used-on-java-21
Hello, I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads. Here I've described the reproduction steps in details: https://stackoverflow.com/questions/78790376/spring-boot-application-gets-stuck-when-virtual-threads-are-used-on-java-21 The
1 - 100 of 35382 matches
Mail list logo
