On Tue, 7 Jun 2022 04:17:44 GMT, Ioi Lam wrote:
> > We should try to consolidate these test cases to improve maintainability.
>
> I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185)
Agreed. Thanks for the review @iklam
-
PR:
On Wed, 1 Jun 2022 09:18:38 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-coding
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote:
> This adds a regression test for a recent fix (JDK-8287073). I've restructured
> the linux specific JDK code to call a separate static function to enable this
> test. It'll help future tests too.
>
> Testing:
> - [x] Container tests
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled
On Mon, 6 Jun 2022 07:15:45 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call Handshake::execute
>> - Switch
> Please review this PR for fixing JDK-8287281.
>
> If a thread is handshake safe we immediately execute the closure, instead of
> going through the regular Handshake process.
>
> Finally: Should `VirtualThreadGetThreadClosure` and its `do_thread()` body
> be inlined instead? We can do this
On Tue, 7 Jun 2022 09:58:11 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and
On Tue, 7 Jun 2022 12:42:05 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and
> 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,
> Please review this PR for fixing JDK-8287281.
>
> If a thread is handshake safe we immediately execute the closure, instead of
> going through the regular Handshake process.
>
> Finally: Should `VirtualThreadGetThreadClosure` and its `do_thread()` body
> be inlined instead? We can do this
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
Thumbs up. This is a trivial change.
-
Marked as reviewed by dcubed (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/9050
On Mon, 6 Jun 2022 16:36:01 GMT, Daniel D. Daugherty wrote:
>> We also no longer need L358 as `current` is now unused.
>
> JavaThread *target = state->get_thread();
> Thread *current = Thread::current();
>
> assert(state != NULL, "sanity check");
>
> The `assert()` on L360 is in the wrong
> Please review following fix which exclude failing test.
Leonid Mesnik has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Merge branch 'master' of https://github.com/openjdk/jdk into 8287877
- Merge branch 'master'
On Tue, 31 May 2022 18:14:51 GMT, Chris Plummer wrote:
>> As part of the loom integration, jdb added `-trackvthreads` and the debug
>> agent added `enumeratevthreads`. These options are being renamed to
>> `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads`
>> should not
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
Marked as reviewed by sspitsyn (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/9050
> Please review following fix which exclude failing test.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
fixed merge
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/9050/files
- new:
On Thu, 19 May 2022 00:10:15 GMT, Chris Plummer wrote:
> As part of the loom integration, jdb added `-trackvthreads` and the debug
> agent added `enumeratevthreads`. These options are being renamed to
> `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads`
> should not have
On Mon, 9 May 2022 21:26:50 GMT, Alex Menkov wrote:
> isThreadExpected function checks only some known JFR/Graal threads.
> This approach requires to keep this function up to date (add other internal
> threads like usage tracker, loom, etc).
>
> To avoid this updated all tests which use it,
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
This pull request has now been integrated.
Changeset: 8e10c2bf
Author:Leonid Mesnik
URL:
https://git.openjdk.java.net/jdk/commit/8e10c2bfc73a25d93187b62f5aa8e6210d6fe98b
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.
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 component.
Verification (Windows-10/MSVS-2019): ```bash ./configure
22 matches
Mail list logo
