On Tue, 7 Jun 2022 12:42:26 GMT, Severin Gehwolf wrote:
>> Please review this cleanup change in the cgroup subsystem which used to use
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream`
>> instead which doesn't have the issue
>> of hard-codin
On Wed, 8 Jun 2022 07:13:30 GMT, Ioi Lam wrote:
>> Severin Gehwolf 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 six additional
>> commits sin
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin
wrote:
> Hi!
>
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea
> of the fix is to re-use value of --with-hotspot-build-time option to generate
> deterministic timestamp exactly like it's done to hotspot componen
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin
wrote:
> Hi!
>
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea
> of the fix is to re-use value of --with-hotspot-build-time option to generate
> deterministic timestamp exactly like it's done to hotspot componen
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin
wrote:
> Hi!
>
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea
> of the fix is to re-use value of --with-hotspot-build-time option to generate
> deterministic timestamp exactly like it's done to hotspot componen
> Please review this cleanup change in the cgroup subsystem which used to use
> hard-coded stack allocated
> buffers for concatenating strings in memory. We can use `stringStream`
> instead which doesn't have the issue
> of hard-coding maximum lengths (and related checks) and makes the code, thus
On Wed, 8 Jun 2022 08:25:21 GMT, Severin Gehwolf wrote:
>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54:
>>
>>> 52: } else {
>>> 53: char *p = strstr(cgroup_path, _root);
>>> 54: if (p != NULL && p == cgroup_path) {
>>
>> I think this change should be done in a
On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote:
> A trivial fix that deletes an errant `debugee.resume()` call that causes a
> race
> between the debugger and debuggee. I've also corrected incorrect line number
> values mentioned in comments.
>
> This fix has been tested with the up
On Thu, 28 Apr 2022 16:33:48 GMT, XenoAmess wrote:
>> I'm getting a bit tired of seeing these JDK wide changes with lots of files
>> touched.
>> Delete all changes in desktop from this PR and re-submit them as a separate
>> PR.
>>
>> Also do not change J2DBench. We deliberately avoid using new
On Sat, 4 Jun 2022 17:28:33 GMT, Andrey Turbanov wrote:
> No need to separately perform HashMap.containsKey before HashMap.remove call.
> If key is present - it will be removed anyway. If it's not present, nothing
> will be deleted.
> https://github.com/openjdk/jdk/blob/a6fc485a22484b70daf170e9
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Sat, 4 Jun 2022 17:28:33 GMT, Andrey Turbanov wrote:
> No need to separately perform HashMap.containsKey before HashMap.remove call.
> If key is present - it will be removed anyway. If it's not present, nothing
> will be deleted.
> https://github.com/openjdk/jdk/blob/a6fc485a22484b70daf170e9
12 matches
Mail list logo
