On Wed, 21 Oct 2020 04:35:14 GMT, Yasumasa Suenaga wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make DumpPerfMapAtExit a diagnostic option
>
> Changes requested by ysuenaga (Reviewer).
> @YaSuenag could you
On Wed, 21 Oct 2020 04:35:14 GMT, Yasumasa Suenaga wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make DumpPerfMapAtExit a diagnostic option
>
> Changes requested by ysuenaga (Reviewer).
@YaSuenag could you
On Thu, 29 Oct 2020 21:23:12 GMT, Coleen Phillimore wrote:
>> The imasm::remove_activation() call does not deal with safepoints very well.
>> However, when the MethodExit JVMTI event is being called, we call into the
>> runtime in the middle of remove_activation(). If the value being returned
On Thu, 29 Oct 2020 12:44:58 GMT, Erik Österlund wrote:
> The imasm::remove_activation() call does not deal with safepoints very well.
> However, when the MethodExit JVMTI event is being called, we call into the
> runtime in the middle of remove_activation(). If the value being returned is
>
On Thu, 29 Oct 2020 14:23:04 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
>>
On Thu, 29 Oct 2020 14:53:54 GMT, Richard Reingruber wrote:
>> The following test cases try to provoke VMOutOfMemoryException during object
>> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>>
>> EAPopFrameNotInlinedReallocFailure
>>
> The following test cases try to provoke VMOutOfMemoryException during object
> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>
> EAPopFrameNotInlinedReallocFailure
> EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure
>
On Wed, 28 Oct 2020 20:13:15 GMT, Vladimir Kozlov wrote:
>
>
> Please change @requires for testing with Graal to `vm.graal.enabled` instead
> of `vm.jvmci`
Sure. I've done that now.
-
PR: https://git.openjdk.java.net/jdk/pull/775
> 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,
On Fri, 23 Oct 2020 10:25:43 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
>
On Thu, 29 Oct 2020 08:56:13 GMT, Lin Zang 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
>> compile
> 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,
The imasm::remove_activation() call does not deal with safepoints very well.
However, when the MethodExit JVMTI event is being called, we call into the
runtime in the middle of remove_activation(). If the value being returned is an
object type, then the top-of-stack contains the oop. However,
On Tue, 27 Oct 2020 14:00:34 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
> compile
14 matches
Mail list logo