RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

[Jean Christophe Beyler]

Thanks all, I pushed it like this then because it seems more "incremental",
Jc

On Thu, May 16, 2019 at 7:08 AM Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Jc,
>
> from the perspective of the ppc64 and s390 port it is OK to exclude
> the two platforms from the test. When we will fix AGCT on the two
> platforms we will update the tests.
>
> Thanks,
> Volker
>
> On Thu, May 16, 2019 at 4:57 AM Jean Christophe Beyler
> <jcbeyler at google.com> wrote:
> >
> > Hi both,
> >
> > For the linux question, I was doing that less for the AGCT code itself
> but more for the dlsym I was doing in the test; I was not really wanting to
> support the various ways of getting the function pointer in the first
> iteration of the test. If we wanted to add it, I would prefer to do a
> separate bug/webrev to add it in a second step (For example, my theory is
> that dlsym works on mac but I'm not sure of the support there either).
> >
> > I like the idea of trying to only know what architectures are supported.
> From what I can tell, if I restrain my inspection to linux:
> >
> > For the linux ports and pd_get_top_frame_for_signal_handler:
> >   - aarch64, arm, ppc, sparc, x86 seem to have an implementation (or it
> calls the for_profiling_one)
> >   - zero, s390 do not
> >
> > On the AsyncGetCallTrace itself, it seems like the #ifndef around the
> call that removes ppc64/ia64 is what is blocking it for ppc at least.
> >
> > Which means that on linux, we should remove zero, s390, ia64, and ppc64;
> or as you are suggesting allow aarch64, arm, sparc, and x86.
> >
> > I offer thus:
> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.01/
> > Bug:  https://bugs.openjdk.java.net/browse/JDK-8224020
> >
> > Thanks for the reviews!
> > Jc
> >
> >
> >
> > From: serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
> > Date: Wed, May 15, 2019 at 7:44 PM
> > To: Chris Plummer, Jean Christophe Beyler, OpenJDK Serviceability
> >
> >> Hi Jc,
> >>
> >> I'm Okay with this fix in general modulo some suggestion from Chris
> below.
> >>
> >>
> >> On 5/15/19 18:49, Chris Plummer wrote:
> >>
> >> Hi JC,
> >>
> >> Looks like s390 is also not supported. Do we know for usre if it is
> implemented on other architectures, like aarch64? I wouldn't necessarily
> rely on the lack of a negative comment in
> JavaThread::pd_get_top_frame_for_signal_handler() to determine support.
> Maybe the test should list supported platforms rather than unsupported ones.
> >>
> >>
> >> I like the suggestion above.
> >> It is better to list what is supported now.
> >>
> >> Also, why does the test currently require linux?
> >>
> >>
> >> My guess is that Jc does not have other platforms to check it on.
> >> Probably, it is Okay for now to keep it this way.
> >> Then we could file an RFE, check if ASGCT tests work Okay on other
> OS'es and relax this limitation.
> >>
> >> Thanks,
> >> Serguei
> >>
> >>
> >> Chris
> >>
> >> On 5/15/19 6:01 PM, Jean Christophe Beyler wrote:
> >>
> >> Hi all,
> >>
> >> Could I get a review that restricts the test to not run on PPC64/IA64
> please?
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224020
> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.00/
> >>
> >> I also moved NULL -> RTLD_DEFAULT as the man page on linux does not
> specify the behavior of passing NULL.
> >>
> >> Thanks,
> >> Jc
> >>
> >>
> >>
> >
> >
> > --
> >
> > Thanks,
> > Jc
>


-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190516/d8e6d556/attachment-0001.html>