Explanation on the anatomy of a JNI call and return

[perry wang]

Hi,
I try to answer your question according to my understanding with JVM
specification 7.
JVM keep a java stack for every java thread.This stack just a logic stack,
a stack data structure defined by JVM implementation in memory. It has
nothing with conventional runtime stack and heap.
For native call, according to specification, you can directly use
conventional stack that means you need not keep a stack structure in memory
just like you call a general C method. Or you also can keep a logic stack
data structure like for java method call for native method. This is depends
JVM implementation.
If I am wrong please other guys point out.

Best Regards
Peng


On Fri, Jan 25, 2013 at 2:01 AM, Fiterau Paul <fiteraup at yahoo.com> wrote:

> Hello guys. Sorry for the intrusion. Looked everywhere for this
> information, no luck. Browsed the code, very difficult to get an idea from
> it. 20 hours of search with no result. Also posted on StackOverflow,
> http://stackoverflow.com/questions/14497754/the-jni-call-its-effect-on-the-two-stacks,
> got no response. If someone could explain to me the evolution of the native
> and the java stack during a JNI call invocation, I'd be very appreciative.
>
> What I could find over the internet is this:
> http://weblogs.java.net/blog/mlam/archive/2006/12/a_tale_of_two_s.html .
> But this is not Hotspot. Plus, I'm doubtful on whether the information is
> accurate, since, in a native to native call, you'd get a recurse in
> executeJava, the interpreter (like shown bellow) and I suspect the
> interpreter does not have the lightest of stack frames.
>         * native stack: executeJava -> mNa -> executeJava -> mNb
>
>         * Java stack:  mNa -> mNb
> My question is, what's the anatomy of a java to native, native to native
> call and native to java in terms of stack frames. The purpose is, for a
> School project I have involving static analysis, where I should infer a
> very conservative upper bound for both the Java stack and the native stack.
> Right now there's a tool inferring the upper bound for the Java stack, but
> it doesn't take into account that some methods might already be compiled. I
> can use that measure in my inference.
>
> I'm especially interested in what would be the worst case with regards to
> stack consumption in a call chain. Let's say A calls B which calls C which
> calls D.
> Would it be more stack consuming if  B, C and D were all native or it's
> more consuming if they are interleaved (one native one not).
> From what tests I made, it seems that having all of them native does seem
> to yield the highest consumption. On the Native stack and on the java stack.
>
> Thanks for any input! And sorry for the not really dev oriented post.
> Paul.
>