RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms

Severin Gehwolf sgehwolf at redhat.com
Thu Jun 11 08:05:47 UTC 2015

Hi David,

On Thu, 2015-06-11 at 15:45 +1000, David Holmes wrote:
> On 10/06/2015 11:49 PM, Severin Gehwolf wrote:
> > Hi,
> >
> > Could somebody please review this Zero only change? I'd also need a
> > sponsor who can push the change for me once reviewed.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/
> >
> > The issue is that Zero relies on undefined behaviour for getting the
> > current stack pointer by allocating a variable on the stack and
> > returning its address. With GCC 5 returning an address of a local
> > variable will always be 0, thus causing the issue. It worked fine with
> > older GCC versions, because they returned the actual address of the
> > variable.
> >
> > The fix is to use GCC's built-in function "__builtin_frame_address".
> > This also works on GCC 5. It's GCC specific, though. On the other hand,
> > I don't know if anybody builds Zero without GCC. An alternative would be
> > to use alloca, but that has strange semantics if the stack pointer
> > cannot be extended. Thoughts?
> The Zero folk will need to confirm if this gcc dependency is ok or 
> whether it requires an ifdef - and they can also push directly to one of 
> the hotspot repos.

Speaking as the Zero maintainer, the GCC dependency is OK. I'd rather
avoid the ifdef. Unfortunately, I am not a committer so cannot push it
myself. I can ask Andrew Haley to push the fix for me once you're OK
with it.

> Is the built-in available across gcc 4.x releases?

Looking at the oldest GCC manual I've found for the 4.x series it
appears it's available since 4.0.4. A couple of examples:


More information about the hotspot-dev mailing list