Re: RFR: 8254723: add diagnostic command to write Linux perf map file [v5]

2020-10-29 Thread Yasumasa Suenaga
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

Re: RFR: 8254723: add diagnostic command to write Linux perf map file [v5]

2020-10-29 Thread Nick Gasson
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

Re: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop

2020-10-29 Thread Erik Österlund
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

Re: RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop

2020-10-29 Thread Coleen Phillimore
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 >

Re: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v6]

2020-10-29 Thread Ioi Lam
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 >>

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5]

2020-10-29 Thread Vladimir Kozlov
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 >>

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5]

2020-10-29 Thread Richard Reingruber
> The following test cases try to provoke VMOutOfMemoryException during object > reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure >

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4]

2020-10-29 Thread Richard Reingruber
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

Re: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v6]

2020-10-29 Thread Claes Redestad
> 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,

Integrated: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing

2020-10-29 Thread Erik Österlund
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 >

Re: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr

2020-10-29 Thread Claes Redestad
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

Re: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v5]

2020-10-29 Thread Claes Redestad
> 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,

RFR: 8255452: Doing GC during JVMTI MethodExit event posting breaks return oop

2020-10-29 Thread Erik Österlund
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,

Re: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr

2020-10-29 Thread Lin Zang
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