Debugging segmentation faults in the JVM on linux-powerpc

Thomas Stüfe thomas.stuefe at
Mon Jun 12 13:15:44 UTC 2017

On Mon, Jun 12, 2017 at 2:22 PM, Andrew Haley <aph at> wrote:

> On 12/06/17 13:08, Thomas Stüfe wrote:
> > I agree with Severin. It makes sense to rule out a compiler failure
> before
> > spending more work on it. The coding in question is completely
> architecture
> > independent, and the fact that it only happens on one platform, and that
> > the error vanishes in slowdebug, is suspicious.
> Not necessarily.  The problem seems to be that we get a failure when
> allocating a direct byte bufer, in Bits.reserveMemory().  The limit is
> controlled by -XX:MaxDirectMemorySize.
> It might well be a bug in the Zero interpreter.  I'd start by adding a
> couple of lines in Bits.tryReserveMemory() to print out the
> totalCapacity when allocation fails.
I think there are several problems. The original problem, the bytebuffer
OOM, happens in his release build. He then did a debug build. Slowdebug
worked (?) but fastdebug crashed very early in SafeFetch initialization in
tests which are omitted in release build.

So, multiple problems in optimized code.


> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-dev mailing list