exception from javaCall but no StackTraceElements

[Deneau, Tom]

Christian --

Yes, you were correct.  I turned off OmitStackTraceInFastThrow and
I don't see this issue occurring anymore.

I assume from looking at the hotspot code that this optimization kicks in
during C2 compilation so the reason we weren't seeing it all the time
is that it depended on the hotness of the method being called thru javaCall.

Now asking for some advice---
In those of our junit tests that we expect to throw a single exception,
we had it set up to catch exceptions in the framework outside the kernel,
and then capture the exception class and the first stack trace element
expecting them to be the same between the pure java run and the hsail kernel run.

But it sounds like we can't count on the stack trace being recorded.
And my understanding is we can't turn off Hotspot options from the junit framework.
Is there any good way to test that not just the exception class matched
but also the point at which the exception occurred?

-- Tom

> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> Sent: Wednesday, May 14, 2014 6:32 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: exception from javaCall but no StackTraceElements
> 
> 
> On May 14, 2014, at 3:57 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 
> > We are seeing an occasional failure on one of our hsail junit tests, I
> will describe here...
> >
> > There is a flag, UseHSAILSafepoints and one effect of that is that if
> a kernel is executing and sees that the VM is desiring a safepoint, then
> new workitems will not get started.  This occurs even if the hsail code
> in the kernel itself has no "compiler safepoints".
> >
> > The workitems that do not start as mentioned above are marked as
> never-rans and are then after all the workitems finish each never-ran is
> run as a javaCall to the underlying java method.  All of this is done in
> "thread-in-VM" mode.
> >
> > This particular test is set up to have 589824 workitems and the very
> last workitem is designed to cause an ArrayOutOfBoundsException.  A try
> block surrounding the kernel call and we catch any exceptions and
> compare the first frame of the stack trace of the exception with the
> first frame that occurred when the kernel was run in pure java mode.
> >
> > We always get an exception thrown from the last javaCall but
> occasionally the exception has no stackTraceElements so our comparison
> fails in that case.
> >
> > I assume an exception in a javaCall is recorded in the thread and then
> when the thread returns from VM mode to Java mode.
> >
> > Does anyone know why the exception would sometimes have no
> stackTraceElements?
> 
> Not sure if I'm following correctly but the "empty" exception is coming
> from running Java code on the CPU, correct?  It might be related to
> OmitStackTraceInFastThrow.  Try to turn it off.
> 
> >
> > -- Tom
> >
> >