Another advantages of portlib is that its function implementation can be
easily replaced without recompiling the entire JVM, copied its document
from [1] below:
<quote>
The port library is implemented as a table of function pointers. One
advantage of a function pointer based table is the ability to replace
any functionality without recompiling the entire Java virtual machine.
For example if an application is experiencing a memory leak, the memory
management functions of the port library can be replaced to help
determine the root cause of this leak. Alternatively applications
wishing to control all memory allocation can provide their own routines
to override the platform specific allocation and deallocation of memory.
Various implementations of the port library may choose not to implement
all functionality contained in the port library table. If a platform
does not support sockets, and thus the Java virtual machine does not
utilize sockets, the port library does not need to provide a valid
socket behavior. The port library contains version control information
that enables applications to determine if required functionality is
supported. In addition the version control information allows
applications to determine if the port library provided is compatible
with the one which they were compiled against.
</quote>
Tim Ellison wrote:
As I wrote earlier, I agree. Implementing the Harmony portability layer
to run on APR is a good idea (volunteers?).
The Harmony portlib [1] itself has some interesting characteristics that
I would not want to loose by programming Java natives straight to APR.
The portlib is a table of function pointers that is linked to a
particular VM instance. Each function in turn has a parameter that is
the function table it should use; and all this is wrapped up in some
syntactic sugar to make palatable to the programmer.
This means that an application that creates multiple VM's in the same
process (i.e. repeated calls to JNI_CreateJavaVM) has the option to keep
the resource management separated. It can ensure that one VM does not
grab the entire OS heap, or that the resources are allocated a given
security sandbox, or (heaven-forbid) if the VM abends it can clean-up
just that VM's resources. It also makes things like tracing much
easier, since you can augment a function at any given point by replacing
it in the function table, and have that augmented function used by all
downstream callers. This scenario will be familiar to the app server
crowd, who want to run multiple VMs inside a webserver for example.
Here's how it looks from a JNI programmer's pov [2]:
================================================
void JNICALL
Java_java_net_Socket_socketCloseImpl (JNIEnv * env,
jclass thisClz,
jobject fileDescriptor)
{
PORT_ACCESS_FROM_ENV (env);
hysocket_t socketP;
socketP = getJavaIoFileDescriptorContentsAsPointer (env,
fileDescriptor);
if (hysock_socketIsValid (socketP))
{
/* Set the file descriptor before closing so the select
polling loop will terminate. */
/* Some platforms wait in the socket close. */
setJavaIoFileDescriptorContentsAsPointer (env, fileDescriptor,
(void *) -1);
hysock_close (&socketP);
}
}
================================================
The "PORT_ACCESS_FROM_ENV(env)" is a macro that reaches into the JNIEnv
and gets the table of function pointers[3].
#define PORT_ACCESS_FROM_ENV(jniEnv) \
VMInterface *portPrivateVMI = VMI_GetVMIFromJNIEnv(jniEnv); \
HyPortLibrary *privatePortLibrary = \
(*portPrivateVMI)->GetPortLibrary(portPrivateVMI)
After that you could tweak it if you choose, but this function doesn't.
Then calls to 'functions' like "hysock_socketIsValid" and
"hysock_close" are actually macros that expand out into offsets into the
function table, and passing the function table down;
i.e.
hysock_socketIsValid (socketP)
expands as follows [3]
#define hysock_socketIsValid(param1) \
privatePortLibrary->sock_socketIsValid(privatePortLibrary,param1)
You can see where this is going. The implementation of
sock_socketIsValid inherits the caller's view of the portlib, and so on.
The on-line doc describes it here [1]. While we would normally also
use the portlayer as the OS porting layer, implementing this on APR
would be a GoodThing too.
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
[2] taken from
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/socket.c?view=markup
[3] look in
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/include/hyport.h?view=markup
Regards,
Tim
Alexey Petrenko wrote:
What do you think?
I think that's using Apache Portable Runtime in Apache Harmony is
natural and good idea.
However we should understand that APR does not have ALL the needed
functionality. For example APR does not have graphical and window
management functions. So at least awt will need to use OS dependent
native code.
--
Alexey A. Petrenko
Intel Middleware Products Division
--
Paulex Yang
China Software Development Lab
IBM
