Hi Zhengyu,
On 2/02/2019 11:38 pm, z...@redhat.com wrote:
On Sat, 2019-02-02 at 11:01 +1000, David Holmes wrote:
On 2/02/2019 4:27 am, z...@redhat.com wrote:
After FastTLABRefill was removed, let's cleanup related perf
counters.
I removed perf counters for fast refill, and renamed perf counter
Hi Jini,
On 02/02/2019 02:16, Jini George wrote:
> Do we reach here after AARCH64CurrentFrameGuess.run() fails to get the
> PC ?
Yes, that's right. It's the else branch (not interpreter and not
compiler) that sets this.pc to null.
> If so, was wondering if it would make more sense to scan fro
On Sat, 2019-02-02 at 08:38 -0500, z...@redhat.com wrote:
> On Sat, 2019-02-02 at 11:01 +1000, David Holmes wrote:
> > On 2/02/2019 4:27 am, z...@redhat.com wrote:
> > > After FastTLABRefill was removed, let's cleanup related perf
> > > counters.
> > > I removed perf counters for fast refill, and r
On Sat, 2019-02-02 at 11:01 +1000, David Holmes wrote:
> On 2/02/2019 4:27 am, z...@redhat.com wrote:
> > After FastTLABRefill was removed, let's cleanup related perf
> > counters.
> > I removed perf counters for fast refill, and renamed perf counters
> > for
> > slow refill.
> >
> > I am not all
Hi Jini, for that particular case, it just provides a simple way to
reproduce more general problems in SA: first I run a program under gdb
and with the option "-XX:CompileCommand=print,...", then I put a
breakpoint at a particular place that I suspect the stack walker code
has problems with. When t
