RFR(s): 8065895: Synchronous signals during error reporting may terminate or hang VM process
david.holmes at oracle.com
Tue Dec 2 09:50:34 UTC 2014
On 1/12/2014 11:30 PM, Thomas Stüfe wrote:
> Hi all,
> lets not get this patch bogged down on ARM opcode discussions.
> For me, it is just a question of style and which one would be most
> acceptable to the OpenJDK.
> As I see it, here are my options:
> 1 leave the code as it is and whoever does ARM porting at Oracle will
> provide the SIGILL opcodes inside debug.cpp
> 2 like (1), but provide a fallback for CPUs where we do not know the
> SIGILL opcodes right now, by doing a raise(SIGILL). This would work but
> make the test a tiny bit less valuable on those platforms.
> 3 Move the CPU-dependend parts (the big #ifdef) away from debug.cpp
> into debug_<cpu>.cpp. Would mean a bit code duplication because for 3
> out of 5 cpus the SIGILL-generating opcode is 0. This basically would be
> the same as my second webrev
> 4 like (3), but with additional introduction of a debug_<cpu>.hpp, and
> adding a "ZERO_WILL_GENERATE_SIGILL" or somesuch macro to provide a
> common fallback for cpus where 0 generates SIGILL.
> I am leaning toward (2) or (3) but I am okay with any of the four.
I'm really undecided here. #1 makes me cringe because of the cpu ifdefs
in shared code (including those for non-OpenJDK platforms). #3 and #4
make me cringe because it is a lot of overhead to introduce the
debug_<cpu>.hpp files on all platforms.
That leaves #2 though I'm unclear how we will identify the platforms
that don't have defined bad opcodes. If that's still just a variant of
the ifdefs in #1 then I'm still cringing. :)
Would appreciate someone else from runtime jumping in with an opinion
(PS. I'm on vacation tomorrow so apologies for delayed responses.)
> Kind Regards,
> Thomas Stuefe
> On Thu, Nov 27, 2014 at 12:04 PM, Andrew Haley <aph at redhat.com
> <mailto:aph at redhat.com>> wrote:
> On 11/27/2014 11:00 AM, David Holmes wrote:
> > On 27/11/2014 8:55 PM, Andrew Haley wrote:
> >> On 11/27/2014 10:38 AM, Thomas Stüfe wrote:
> >>> Hi Andrew, thank you! Does endianess matter ?
> >> Yes. I'd do it symbolically rather than mess with endian defines:
> >> #ifdef AARCH64
> >> unsigned insn;
> >> asm("b 1f; 0: dcps1; 1: ldr %0, 0b" : "=r"(insn));
> >> #endif
> > Does that work for ARMv7?
> Sorry, I don't know what a good choice there would be. And I must
> warn you: DCPS1 isn't necessarily guaranteed to do this forever, but
> it works on the kernels I've tried.
More information about the hotspot-runtime-dev