On 09/20/2013 10:45 AM, Peter Levart wrote:
On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
List<StackFrameInfo> frames = new ArrayList<>();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole
stack or not. Your code implies it does. If It does, I don't see the
advantage of suing a Stream here.... or does the predicate version not?
Right.
I think the reasoning behind call-back API is that it moves the logic to
construct a suitable data structure to the Java side, skipping
intermediary representations and conversions. I don't know what the
overhead of call-backs from native code to Java is though. For
constructing and returning an array of StackFrameInfo objects, the
native code has to collect the objects into a GrowableArray (a native
equivalent of ArrayList). Before returning, it has to copy elements into
the Java array. And this Java array is usually later used just to
iterate it's elements... Imagine a situation where GrowableArray and
Java array could be skipped and StackFrameInfo objects directly
formatted into a StringBuilder, creating the final logger message. This
assumes that call-backs from native code are cheap. Are they? Can native
method be intrinsified together with call-back invocations?
To support this call-back API in a JDK6 compatible way, but optimally, I
would create a similar API to the one in JDK8 in the form of interfaces
and then provide two implementations:
- the JDK8 implementation: a thin wrapper over JDK8 API
- the JDK6/7 implementation: an emulation adapter using JDK6/7 provided
APIs
Regards, Peter
From my testing (in JDK 6), I found that calling back from JNI was not
very cheap, but perhaps rather than making this call be a JNI
call+callback it can simply be an intrinsic operation to begin with? I
like the idea of using a JDK8-style lambda to process frames.
--
- DML