Browse Prior Art Database

Method to control Java Native Interface (JNI) Offloading in a Java Virtual Machine (JVM)

IP.com Disclosure Number: IPCOM000202425D
Publication Date: 2010-Dec-15
Document File: 5 page(s) / 120K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a novel technique of choosing between remote and/or local execution of native methods using annotations and JVM support.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 01 of 5

Method to control Java Native Interface (JNI) Offloading in a Java Virtual Machine (JVM)

Java* Virtual Machine (JVM) implementations support the Java Native Interface (JNI) as a mechanism which allows Java code to call methods written in C and C++ (native code) and vice versa. Traditionally both the code written in Java and the native code is executed in the same process and by the same thread as execution transitions between the two.

It is possible, however, to construct a JVM such that the native code is run in one or more Remote Execution Containers which may be hosted in separate processes on the same or different machines from where the Java code is executed such that the native code is unaware that it is executing separately from the JVM (as shown in the Fig.1). This separation prevents misbehaved native code from destabilizing the JVM and enables running the native code in a different environment than the main JVM.

(This page contains 00 pictures or other non-text object)

Figure1

In such a system where natives execute remotely from JVM, each JNI call results in every native running in the Remote Execution Container. This requires an expensive round trip between the Java Process and the Remote Execution Container.

For some types of natives, the end result of running the native will be identical, regardless of which process it runs in. For other types of natives, the end result may not be identical but running the native in the Java process instead of the Remote Execution Container is much more efficient and the difference in behavior acceptable. For example, natives for file access, when the file being accessed is on a shared file system.

For these types of natives it is advantageous to be able to run the native either in the Java Process (locally) or in the Remote Execution Container (remotely) based on the context in which the native is being run. This context is often tied to the instance of the

1


Page 02 of 5

object on which the native is operating. The decision to execute a particular native method remotely or locally needs to be made based on:
(a) the characteristics of associated Java Object (Java Object is local and all the required information is present in the Front End VM)
(b) the native method characteristics itself (for example: all the data required by the native method is available locally, so executing the native method locally is better than executing it remotely).

In addition to the types of natives discussed above, there is a class of natives (typically for initialization and life-cycle) which needs to be run both locally and remotely so that the other natives can be run either locally or remote as needed.

To enable choosing between remote and local execution of any native method, certain basic control features are provided as described below:

Offload Library List: List of libraries from which all the calls will be run remotely on an Offloaded JVM.

Exclude Method List: List of native methods (belonging to...