On Tue, 27 Oct 2020 04:17:34 GMT, Nick Gasson wrote:
>> Hi Nick,
>>
>> This looks good.
>> Thank you for the update.
>>
>> Thanks,
>> Serguei
>
>> I don't see any reason for this to be a product flag, rather than diagnostic.
>
> OK sure, I've made it a diagnostic flag.
> @nick-arm only [Revie
On Tue, 27 Oct 2020 14:56:33 GMT, Claes Redestad wrote:
>> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
>> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
>> initialization into a constexpr, we can precalculate the helper table at
>> comp
On Thu, 22 Oct 2020 00:00:17 GMT, Alex Menkov wrote:
> Please review the fix for BadHandshakeTest.
> Summary:
> The test verifies that bad (testcase1) or incomplete (testcase2) handshake
> does not cause debuggee termination.
> To check this it tries to attach to the debuggee again (connect in t
On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf wrote:
> Test only change. With
> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
> been added on the hotspot side, but nothing for the Java Metrics code. Same
> for [JDK-8252359](https://bugs.openjdk.java.net/browse/
On Tue, 27 Oct 2020 17:08:18 GMT, Xin Liu wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update for review comments
>
> src/hotspot/share/code/codeCache.cpp line 1566:
>
>> 1564:
>> 1565: char fname[32];
>> 156
On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote:
>> When using the Linux "perf" tool to do system profiling, symbol names of
>> running Java methods cannot be decoded, resulting in unhelpful output
>> such as:
>>
>> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
>>
>> Perf can read a simp
> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
> initialization into a constexpr, we can precalculate the helper table at
> compile time, which trades a runtime overhead for a small, 8kb, st
On Tue, 27 Oct 2020 13:28:53 GMT, Erik Österlund wrote:
>> It does sound good indeed to me if you don't mind doing that. Thanks!
>> I have run the tests dedicated to EscapeBarriers with ZGC enabled and also
>> the DeoptimizeObjectsALot stress testing. I will run some more
>> serviceability test
On Tue, 27 Oct 2020 13:31:36 GMT, Erik Österlund wrote:
>> The escape barrier reallocates scalarized objects potentially deep into the
>> stack of a remote thread. Each allocation can safepoint, causing referenced
>> frames to be invalid. Some sprinklings were added that deal with that, but I
> The escape barrier reallocates scalarized objects potentially deep into the
> stack of a remote thread. Each allocation can safepoint, causing referenced
> frames to be invalid. Some sprinklings were added that deal with that, but I
> believe it was subsequently broken with the integration of
On Mon, 26 Oct 2020 15:19:51 GMT, Richard Reingruber wrote:
>>> Hi Erik, the last commit in
>>> https://github.com/reinrich/jdk/commits/pr-832-with-better-encapsulation
>>> would be the refactoring I would like to do. It removes the code not
>>> compliant with concurrent thread stack processin
> The following test cases try to provoke VMOutOfMemoryException during object
> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>
> EAPopFrameNotInlinedReallocFailure
> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure
> EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjec
On Tue, 27 Oct 2020 00:52:20 GMT, Serguei Spitsyn wrote:
>> Richard Reingruber 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 four
>> additiona
13 matches
Mail list logo
