harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: Using APR for Harmony's native link to the OS?
Date Tue, 21 Feb 2006 12:47:18 GMT
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



Mime
View raw message