Am 20.09.2013 17:45, schrieb Peter Levart: [...]
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.
StackFrameInfo is already a conversion for me. I see some value in the additional ability to impose security checks, but nothing for ease of use. I somehow cannot believe that StackFrameInfo is a structure the VM uses internally to manage stack frames
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?
You won't need a GrowableArray if you know the stack length. Then you can just create the target StackFrameInfo[]
bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org
