New Native Code interface

In the design of the native code interface in the Microsoft VM, this article has addressed many of the implications of prior interfaces as discussed previously. Internally, object references are pointers directly to the object. The following diagram describes the internal storage details of objects within the Microsoft native code model.

A pointer to this object is a pointer directly to the method table pointer in the object that is located just under the Data. The data is directly above the method table (which is a different data structure than current implementations support). When the Microsoft VM calls native code, it calls the target function directly without going through stubs located in the DLL library. There are stubs, but they are optimized, CPU-specific code generated by the VM.

For source code compatibility and header compatibility, this native code model supports the unhand macro. All the unhand does is cast the handle to a pointer (and add 4 to its address). In the future, Microsoft will have another version of unhand that won't do any arithmetic (but should still be used). There will also be another header file generator that detects this extra method table element at the base and creates appropriate C structures representing this. This will ensure that everything is fully accessible.

Since the Microsoft VM does not conservatively garbage collect native stacks, if any native code has outstanding pointer references during a garbage collection, the same problems that exist with the current native code model could be encountered. To remedy this, while still providing maximum speed with minimum overhead, Microsoft has defined conventions to ensure a deterministic, low overhead solution with respect to outstanding native code pointers. These conventions rely on the fact that native code is responsible for enabling/disabling garbage collection as necessary, and informing the VM of locations in memory where object pointers exist.

Implications for Existing Code

This new native code interface is not binary compatible with the current interface. Existing Java applications that use the native keyword will need to consider the use they make of native code and how long they will be in native code functions. If you are calling native code and returning, it's all right to leave source code as it was with the previous model. If you are going to block or take an undetermined amount of time to perform some task before returning to the VM, you need to ensure that you allow garbage collection. By default, garbage collection is turned off when you enter native code.

Implications and Benefits

• No extra level of indirection. Objects that are accessed don't require extra code to indirect through handles.

Benefit : performance improvement

• No explicit stubs

The target method is called directly from the VM. On the fly, the VM creates an assembler stub, which sets up a frame appropriate for the calling convention of the current machine architecture. The process is as follows (the pushes are needed to transpose calling conventions).

setup native frame

push

push

push

call native method

In a way, this is similar to what happens in the existing native code interface, but it's carried out in a highly-optimized form within the VM. This allows the VM to share stubs among similar methods and reduce working set, or optimize absolutely for speed. In either case, the native code libraries themselves can be smaller because they don't contain additional code for parameter unwrapping.

Benefit :  VM chooses optimizations, performance improvement.

• Using passed parameters is faster

Benefit : performance improvement

• JIT code is internally more optimized

Benefit : performance improvement

C code is just as portable as before. For the existing native code interface, there is less computer-specific code within the VM to support the model, but there is always porting work required. Stubs are duplicated in every library (DLL or equivalent).