[aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options

[Kavitha Natarajan]

I have been trying to resolve a SEGV issue after using zero_words.

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x0000007f70b22a50, pid=12602, tid=12633

#

# JRE version: OpenJDK Runtime Environment (9.0) (build
9-internal+0-2016-11-16-004839.dinesh.openjdk9hs)

# Java VM: OpenJDK 64-Bit Server VM
(9-internal+0-2016-11-16-004839.dinesh.openjdk9hs,
mixed mode, tiered, parallel gc, linux-aarch64)

# Problematic frame:

# v  ~RuntimeStub::fast_new_instance Runtime1 stub

#

# Core dump will be written. Default location: Core dumps may be processed
with "/usr/share/apport/apport %p %s %c %P" (or dumping to
/user/dinesh/temp/JTwork/scratch/core.12602)



The pc address maps to instructions in eden_allocate(). Looks like large
memory is not being handled properly by eden_allocate(). Or if block_zero()
is polluting the memory. This is the code that I am concerned on:


hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:

3999     // if end < obj then we wrapped around high memory

4000     cmp(end, obj);

4001     br(Assembler::LO, slow_case);

4002

4003     cmp(end, heap_end);

4004     br(Assembler::HI, slow_case);

4005

4006     // If heap_top hasn't been changed by some other thread, update it.

4007     stlxr(rscratch2, end, rscratch1);

4008     cbnzw(rscratch2, retry);


I haven't got a solution yet. Wondering if I can get any help from this
forum.


Regards,

Kavitha

On 16 November 2016 at 23:22, Andrew Haley <aph at redhat.com> wrote:

> On 16/11/16 17:08, White, Derek wrote:
>
> > But I still suggest calling zero_words in
> > MacroAssembler::tlab_refill().
> >
> > The whole point of the ZeroTLAB flag is if bulk clearing the TLAB is
> > faster than piecemeal clearing as needed. Doing a simpler
> > zero_memory just has the potential to pollute the cache
> > unnecessarily.  The extra size of calling zero_words here only comes
> > into play if ZeroTLAB flag is on, and the macro should only be
> > expanded once in any case.
>
> Sounds reasonable.  This will need to be submitted to hotspot-dev for
> formal approval.
>
> Andrew.
>