[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[Jochen Theodorou]

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