Re: fn:stack-trace

My knowledge on Java optimizations is very limited (I hope others can
tell more). As far as I know, the stack trace call always returns
information that’s stored in the compiled class code. Function
inlining is only performed at runtime by JIT (at runtime), and it’s
postponed and only triggered if a function has already been called
numerous times (possibly also to preserve debugging information, but
that’s just a guess).

Dimitre can possibly tell us more about .NET. I remember there was an
option to suppress inlining (MethodImplOptions.NoInlining), maybe for
this reason? Other languages have similar pragmas/annotations.

Apart from this, I believe there will always be solutions to preserve
required information for debugging purposes if it’s important enough.
I was mostly wondering if we expect XQuery implementations to do this
by adding an official function that promises this information. If yes,
we should possibly add some more details on the expected result. If
not (and if they function may some more information that’s helpful for
debugging purposes), a more generic name may be less misleading.

What do other implementors think?
____________________________________

On Wed, Dec 2, 2020 at 12:07 PM Michael Kay <mike@saxonica.com> wrote:
>
> I wonder how Java and other languages handle this? Does the fact that the program can call for a stack-trace inhibit any optimizations like tail-call optimization or function inlining? My assumption was that stack-trace() would just do the best it could to present any information that's available at run-time and hasn't been optimized away (and it might give you more information if optimizations have been disabled).
>
> Michael Kay
> Saxonica
>
> On 2 Dec 2020, at 10:53, Christian Grün <cg@basex.org> wrote:
>
> The description for fn:stack-trace is fairly general and vague [1]. I
> think that’s just fine, as the specs do not prescribe how to implement
> function invocations.
>
> “Stack trace” implies to me that the function will return the call
> stack (i.e., the stack of invoked functions). As this may only be
> fully possible if functions are not inlined at compile time, code
> might need to be compiled differently whenever a stack trace request
> is found… and so forth. The name also implies to me that the function
> should return nothing else. However, it could be helpful to get a list
> of bound variables with their values at runtime.
>
> Maybe we can find a more general name, such as fn:debug or fn:runtime-trace?
>
> Cheers,
> Christian
>
> [1] Returns implementation-dependent information about the current
> state of execution.
>
>

Received on Wednesday, 2 December 2020 11:55:58 UTC