Thread: [Aegisvm-devel] patch to jni.c
Status: Pre-Alpha
Brought to you by:
pwlfong
Menu
▾
▴
aegisvm-devel
|
From: Gildas B. <gb...@al...> - 2002-07-23 21:33:40
Attachments:
jni.diff
|
Hi, As I told you in my last mail (which btw is still waiting for moderator approval due to my silly mistake of using a different mail account) I did quite a few modifications to the JNI code in AegisVM. The first part of the changes consist of code factorisation which does reduce the size of jni.c by a fair amount. For instance all the ae_jni_Call*Method() functions are quite similar and thus it is possible to generate them all from a single macro, a new ae_jni_CallMethodA() also regroups all the common code for all the ae_jni_Call* variants (including static and virtual). The second part of the changes is an attempt to implement more of the JNI functions. These changes need to be reviewed carefully as I'm not entirely sure I understood all the subtilities involved, even though they all seem to work correctly. List of implemented functions: - all the ae_jni_Call##JType##Method*() - ae_jni_GetFieldID() - all the ae_jni_Get/Set##JType##Field() - ae_jni_GetStringUTFLength() - ae_jni_GetStringUTFChars() - ae_jni_ReleaseStringUTFChars() - ae_jni_GetArrayLength() If you have some criticism about this patch or needs me to rework some of it, do not hesitate to tell me. Regards, -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-07-24 23:54:56
|
Hi, On Tue, 23 Jul 2002, Gildas Bazin wrote: > As I told you in my last mail (which btw is still waiting for moderator > approval due to my silly mistake of using a different mail account) I did > quite a few modifications to the JNI code in AegisVM. No, the fault is mine. I was busy working on something else last week and didn't reply your mail promptly. > The first part of the changes consist of code factorisation which does > reduce the size of jni.c by a fair amount. For instance all the > ae_jni_Call*Method() functions are quite similar and thus it is possible to > generate them all from a single macro, a new ae_jni_CallMethodA() also > regroups all the common code for all the ae_jni_Call* variants (including > static and virtual). Hmm, I am usually not very fond of such use of macros. But I see your point though. The various method invocation routines definitely need a lot of factoring. I am still thinking about how to do this the right way. My experience is that most of the nasty bugs I have seen have to do with either the garbage collector or one of the method invocation routines. These functions are extremely delicate, and break very easily. My fear is that using macro-based templates might make the code even more cryptic. However, I welcome any thoughts you might have on this matter. > The second part of the changes is an attempt to implement more of the JNI > functions. These changes need to be reviewed carefully as I'm not entirely > sure I understood all the subtilities involved, even though they all seem > to work correctly. > List of implemented functions: > - all the ae_jni_Call##JType##Method*() > - ae_jni_GetFieldID() > - all the ae_jni_Get/Set##JType##Field() > - ae_jni_GetStringUTFLength() > - ae_jni_GetStringUTFChars() > - ae_jni_ReleaseStringUTFChars() > - ae_jni_GetArrayLength() This is perfect! As I mentioned before, we could probably discuss a bit more before we give a good shot at the ae_jni_Call##JType##Method*() functions, but it would be extremely nice if you would be able to help out with implementing the rest. Thanks in advance. > If you have some criticism about this patch or needs me to rework some of > it, do not hesitate to tell me. BTW, which release (or cvs tag) was your previous patch made out of? Again, thanks. Philip -- Philip W. L. Fong pw...@us... The Aegis VM Project http://aegisvm.sourceforge.net The Aegis VM Project is an on-going effort to implement a lightweight, secure JVM. It will eventually feature a modular architecture, Proof Linking, that supports pluggable verification modules. |
|
From: Gildas B. <gb...@al...> - 2002-07-25 10:19:37
|
On Thursday 25 July 2002 01:54, Philip Fong wrote: > Hi, > > Hmm, I am usually not very fond of such use of macros. But I see your > point though. The various method invocation routines definitely need > a lot of factoring. I am still thinking about how to do this the > right way. My experience is that most of the nasty bugs I have seen have > to do with either the garbage collector or one of the method invocation > routines. These functions are extremely delicate, and break very > easily. My fear is that using macro-based templates might make the > code even more cryptic. However, I welcome any thoughts you might > have on this matter. > I am not found of them either ;-) The main motivation for using such macros is to replace the multitude of small wrapper functions that jni.c is using. All the Call##JType##Method*() functions are in fact wrappers around ae_jni_CallMethodA() where the bulk of the work is done anyway. ae_jni_CallMethodA() is the important function where all the improvements are likely to be done in the future, the wrappers themselves shouldn't have to change much. But I guess this is also a matter of taste ;-) > > The second part of the changes is an attempt to implement more of the JNI > > functions. These changes need to be reviewed carefully as I'm not entirely > > sure I understood all the subtilities involved, even though they all seem > > to work correctly. > > List of implemented functions: > > - all the ae_jni_Call##JType##Method*() > > - ae_jni_GetFieldID() > > - all the ae_jni_Get/Set##JType##Field() > > - ae_jni_GetStringUTFLength() > > - ae_jni_GetStringUTFChars() > > - ae_jni_ReleaseStringUTFChars() > > - ae_jni_GetArrayLength() > > This is perfect! As I mentioned before, we could probably discuss a bit > more before we give a good shot at the ae_jni_Call##JType##Method*() > functions, but it would be extremely nice if you would be able to help > out with implementing the rest. Thanks in advance. > If you want me to send you a patch without the macros I can do it (not that I will like to do it, but I can ;-). One of the reasons why I started implementing these JNI functions is that I'm trying to run the mauve java testsuite (http://sources.redhat.com/mauve/) on AegisVM but the testsuite doesn't even bootstrap with the current AegisVM cvs because of missing JNI functions and a few other things. It's almost working though and I will send you the remaining patches when it is. > > BTW, which release (or cvs tag) was your previous patch made out of? > Current cvs :) Regards, -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-07-26 19:44:28
|
Hi,
On Thu, 25 Jul 2002, Gildas Bazin wrote:
> I am not found of them either ;-)
> The main motivation for using such macros is to replace the multitude of
> small wrapper functions that jni.c is using. All the Call##JType##Method*()
> functions are in fact wrappers around ae_jni_CallMethodA() where the bulk
> of the work is done anyway. ae_jni_CallMethodA() is the important function
> where all the improvements are likely to be done in the future, the
> wrappers themselves shouldn't have to change much.
> But I guess this is also a matter of taste ;-)
I understand your concern, which is 100% valid. Maintaining these various
versions of method invocation functions has become a nightmare. There
are a number of issues that I am struggling with:
(1) Native method invocation is a very frequent event in the Java class
library, yet unfortunately it is extremely inefficient because of
the use of libffi and the need for marshalling/unmarshalling data.
We need extremely efficient implementation for it.
(2) The JNI virtual method invocation function can be used to invoke
interface methods. This complicates a lot of stuffs.
As a result of the above concerns, I am still in need of a good design.
I do need some more time to decide. Anyway, I'll place this in a
very high priority, and will let you know as soon as I have resolved them.
> If you want me to send you a patch without the macros I can do it (not that
> I will like to do it, but I can ;-).
Hee hee... if it is not too much trouble for you, would you mind sending
the patch without the parts related to the *Call*Method* functions?
I'd really appreciate it.
> One of the reasons why I started implementing these JNI functions is that
> I'm trying to run the mauve java testsuite
> (http://sources.redhat.com/mauve/) on AegisVM but the testsuite doesn't
> even bootstrap with the current AegisVM cvs because of missing JNI
> functions and a few other things. It's almost working though and I will
> send you the remaining patches when it is.
That is fantastic. I think this is the way to go. However, the VM is
functionally very incomplete: it does not have multithreading, class
finalization and weak reference, and reflection support is still
rather incomplete. Hope this does not hinder your work too much.
Philip
--
Philip W. L. Fong pw...@us...
The Aegis VM Project http://aegisvm.sourceforge.net
The Aegis VM Project is an on-going effort to implement a lightweight,
secure JVM. It will eventually feature a modular architecture, Proof
Linking, that supports pluggable verification modules.
|
|
From: Gildas B. <gb...@al...> - 2002-07-31 17:48:12
|
Hi Philip, On Friday 26 July 2002 21:36, Philip Fong wrote: > > On Thu, 25 Jul 2002, Gildas Bazin wrote: > > > If you want me to send you a patch without the macros I can do it (not that > > I will like to do it, but I can ;-). > > Hee hee... if it is not too much trouble for you, would you mind sending > the patch without the parts related to the *Call*Method* functions? > I'd really appreciate it. > Ok, I'll send it ASAP then. > > That is fantastic. I think this is the way to go. However, the VM is > functionally very incomplete: it does not have multithreading, class > finalization and weak reference, and reflection support is still > rather incomplete. Hope this does not hinder your work too much. > Don't worry, I already knew that aegisvm was missing quite a few features, but being able to run mauve to attest that what has already been implemented works correctly is a big plus IMHO. Thurthermore mauve provides a nice stress test :). -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-07-31 22:11:20
|
Hi On Wed, 31 Jul 2002, Gildas Bazin wrote: > Ok, I'll send it ASAP then. Thank you so much. > Don't worry, I already knew that aegisvm was missing quite a few features, > but being able to run mauve to attest that what has already been > implemented works correctly is a big plus IMHO. Thurthermore mauve provides > a nice stress test :). That is cool. What you are doing will make me sleep tighter at night. :-) Philip -- Philip W. L. Fong pw...@us... The Aegis VM Project http://aegisvm.sourceforge.net The Aegis VM Project is an on-going effort to implement a lightweight, secure JVM. It will eventually feature a modular architecture, Proof Linking, that supports pluggable verification modules. |
|
From: Philip F. <pw...@us...> - 2002-08-04 21:17:57
|
Hi Gildas, On Wed, 31 Jul 2002, Gildas Bazin wrote: > > Hee hee... if it is not too much trouble for you, would you mind sending > > the patch without the parts related to the *Call*Method* functions? > > I'd really appreciate it. > > > > Ok, I'll send it ASAP then. While I am implementing the enforcement of loading constraints, I need java.net.URLClassLoader for testing. I figure out that there are some jni functions that I need in order to make URLClassLoader flies. Guess what, some of them are exactly the ones you implemented. I think I'll just extract from your previous patch all the new features and bug fixes, and leave the restructuring code for later considerations. So, please hold off the reworking of the patch. I apologize for creating all these confusions and duplicated work. Thanks again for your excellent work. BTW, I'll try to finish the loading constraints stuff next week and then cut out release 0.1.1. After that I can really start the moduler verification stuff. :-) Philip -- Philip W. L. Fong pw...@us... The Aegis VM Project http://aegisvm.sourceforge.net The Aegis VM Project is an on-going effort to implement a lightweight, secure JVM. It will eventually feature a modular architecture, Proof Linking, that supports pluggable verification modules. |
|
From: Philip F. <pw...@us...> - 2002-08-06 23:28:43
Attachments:
patch
|
Hi I just committed the attached patch into the cvs repository, with the following log: New feature & bug fix: Implementation for GetStringUTFLength, GetStringUTFChars, and GetArrayLength. Also fixed the typedef for CallNonvirtualByteMethodA and the missing assertion in ReleaseStringChars. Patch contributed by Gildas Bazin <gb...@al...>. Also, I'll process the rest of your patch to jni.c asap. Philip Philip W. L. Fong pw...@us... The Aegis VM Project http://aegisvm.sourceforge.net The Aegis VM Project is an on-going effort to implement a lightweight, secure JVM. It will eventually feature a modular architecture, Proof Linking, that supports pluggable verification modules. |
|
From: Philip F. <pw...@us...> - 2002-08-21 19:51:20
Attachments:
patch
|
Hi Gildas,
I have just processed the part of your JNI patch that has to do with
getting and setting of static and instance fields. As I mentioned before,
there are enough complexities in the code that I don't feel very
comfortable maintaining macro-based code template. So, what I did was
the following:
- Functions ae_jni_[Get|Set]Static[Float|Double]Field are basically manual
expansion of your macros, with the incorrect references of i8 changed
back to f8.
- Functions ae_jni_[Get|Set]<Type>Field are basically manual expansion of
your macros, with the following exceptions:
- In [Get|Set]DoubleField, the incorrect references of i8 is changed
back to f8.
- GetObjectField should wrap the returned value by a local reference.
Attached is that actual patch that I committed, with the following
log:
New feature: Implementation of [Get|Set]Static[Float|Double]Field and
[Get|Set]<Type>Field. Based on a patch contributed by Gildas Bazin
<gb...@al...>.
I'll work on the last part of your jni patch (i.e. the method invocation
part) now, and when this last bit of your patch is processed, I'll
cut out another new release. :-)
Thank you for your contribution.
Philip
--
Philip W. L. Fong pw...@us...
The Aegis VM Project http://aegisvm.sourceforge.net
The Aegis VM Project is an on-going effort to implement a lightweight,
secure JVM. It will eventually feature a modular architecture, Proof
Linking, that supports pluggable verification modules.
|
|
From: Philip F. <pw...@us...> - 2002-08-22 10:11:37
|
Hi Gildas,
I have just finished the implementation of the jni functions for method
calling. I ended up doing things differently than what you suggested
in your patch:
1/ The non-virtual method invocation functions you suggested is
simply a macro-based factoring of the stub code. I filled in
the actual implementation and didn't use macros.
2/ The virtual method invocation functions are actually much more
subtle than your implementation. It involves instance/interface
method dispatching logic. So I ended up doing things my own way.
3/ I really appreciate your factoring of common code in CallMethodA
and CallMethodV. You basically did two things:
a/ You introduced an extra argument obj to reuse the static method
invocation code for instance method invocation. I adopted the
idea in my code.
b/ You make CallMethodV delegate its method invocation task to
CallMethodA. You achieve this by converting the input va_list
into an array of jvalue. This is real nice, with only one
catch. Since you allocate the array from the stack frame of
the caller, if the caller perform multiple jni calls, then
all these intermediate arrays will be accumulated in the
caller's frame without deallocation. One apparent fix would
be to use the arena check-pointing mechanism to deallocate the
intermediate array when the invocation returns. However, the
catch is, in the mean time, JNI may have already allocated
some local references from the caller frame, and simple
rewinding based on check-pointing will corrupt the local
reference registry. The cleanest way to implement this
is to allocate the intermediate arrays in the callee's stack
frame. I am too eager to release soon, and so I'll leave the
code unfactored for now, and will return to this issue later.
If you have a good way of fixing it, please do let me know.
Again, thanks for your contribution. :-)
Philip
--
Philip W. L. Fong pw...@us...
The Aegis VM Project http://aegisvm.sourceforge.net
The Aegis VM Project is an on-going effort to implement a lightweight,
secure JVM. It will eventually feature a modular architecture, Proof
Linking, that supports pluggable verification modules.
|
Thanks for helping keep SourceForge clean.
X