Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-29 Thread Erik Österlund
On Tue, 29 Sep 2020 14:39:23 GMT, Zhengyu Gu wrote: >>> Hi Erik, >>> >>> I have been playing with this patch for past a few days. Great work! >>> >>> I found that this patch seems to break an early assumption. >>> We have a comment in JavaThread::exit() says: >>> >>> // We need to cache the

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-29 Thread Zhengyu Gu
On Tue, 29 Sep 2020 14:12:26 GMT, Erik Österlund wrote: > > Hi Erik, > > I have been playing with this patch for past a few days. Great work! > > I found that this patch seems to break an early assumption. > > We have a comment in JavaThread::exit() says: > > // We need to cache the thread name

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-29 Thread Erik Österlund
On Tue, 29 Sep 2020 13:13:55 GMT, Zhengyu Gu wrote: >> I see; thank you for the explanation. > > Hi Erik, > > I have been playing with this patch for past a few days. Great work! > > I found that this patch seems to break an early assumption. > We have a comment in JavaThread::exit() says: >

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-29 Thread Zhengyu Gu
On Mon, 28 Sep 2020 12:00:40 GMT, Albert Mingkun Yang wrote: >>> Thank you for the comments and diagrams; they make the code much more >>> digestible. From that diagram, I get the >>> impression that the watermark is associated with stack pointer, so it >>> should be 1:1 relation, but `class

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-28 Thread Albert Mingkun Yang
On Mon, 28 Sep 2020 11:54:17 GMT, Erik Österlund wrote: >> Thank you for the comments and diagrams; they make the code much more >> digestible. From that diagram, I get the >> impression that the watermark is associated with stack pointer, so it should >> be 1:1 relation, but `class Thread` >>

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-28 Thread Erik Österlund
On Thu, 24 Sep 2020 21:20:19 GMT, Albert Mingkun Yang wrote: > Thank you for the comments and diagrams; they make the code much more > digestible. From that diagram, I get the > impression that the watermark is associated with stack pointer, so it should > be 1:1 relation, but `class Thread` >

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-24 Thread Albert Mingkun Yang
On Thu, 24 Sep 2020 15:49:36 GMT, Erik Österlund wrote: >> To be clear, my comments about boolean parameters to vframeStream/RegMap can >> be addressed in a follow up RFE. That >> would be better. > >> To be clear, my comments about boolean parameters to vframeStream/RegMap can >> be

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-24 Thread Erik Österlund
On Thu, 24 Sep 2020 14:28:44 GMT, Coleen Phillimore wrote: > To be clear, my comments about boolean parameters to vframeStream/RegMap can > be addressed in a follow up RFE. That > would be better. Thanks for reviewing Coleen! - PR: https://git.openjdk.java.net/jdk/pull/296

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-24 Thread Coleen Phillimore
On Thu, 24 Sep 2020 14:25:15 GMT, Erik Österlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack >> Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a >> frame (supporting

Re: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6]

2020-09-24 Thread Erik Österlund
> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack > Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a > frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the