aegisvm-devel Mailing List for The Aegis VM Project (Page 2)
Status: Pre-Alpha
Brought to you by:
pwlfong
Menu
▾
▴
aegisvm-devel — Developers list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
(4) |
May
(15) |
Jun
(2) |
Jul
(19) |
Aug
(8) |
Sep
(8) |
Oct
(14) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gildas B. <gb...@al...> - 2002-09-21 23:38:34
|
Hi Philip, Here are the patches for the Win32 port of JPR (minus the bits I already sent in my last mail). 1) jpr_win32.diff: the win32 port itself. It has been tested with both the MinGW and the MSVC (microsoft visual c++ compiler) compilers. 2) jpr_correctness.diff: various syntax fixes that MSVC needs in order to get rid of annoying warnings. 3) jpr_fp.diff: MSVC yells at this special case handling because there are divisions by 0, so I just conditionally disabled the offending code. 3) README.win32: file explaining how to compile JPR for win32 4) libffi.win32.patch: patch to make libffi compile under MSVC and a couple of fixes to have it compile under MinGW. (This patch hasn't been sent yet to the libffi maintainers but it will shortly). I also have patches pending for AegisVM but I need some sleep now so they will wait until tomorrow :) I hope you enjoy it :) -- Gildas |
|
From: Gildas B. <gb...@al...> - 2002-09-21 17:30:56
|
Hi Philip,
I've got a few more patches to propose you :)
Recently I've been working on a Win32 port of AegisVM. In the process, I had
to make one change to the API of JPR which does break compatibility with
older versions.
I introduced a new JFile structure:
struct JFile {
void *data; /* pointer to the mmap area */
size_t size; /* size of mmap data */
#ifdef WIN32
HANDLE hmmap; /* handle of file mapping object */
HANDLE hfile; /* handle of file */
#endif
};
This change is needed on Win32 because we need to know "hmmap", "hfile" and
"data" when freeing a mmapped file.
I think hidding the platform specific details in a structure like this does
make aegisvm more platform independant.
So here is the patch for JPR and AegisVM. The patch for JPR also includes
some Win32 specific bits which touched the io.[hc] files, but I'll send you
the rest of the win32 port in a separate patch.
Regards,
--
Gildas |
|
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.
|
|
From: Philip F. <pw...@us...> - 2002-08-21 19:51:20
|
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-06 23:28:43
|
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-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-03 22:21:19
|
Hi Because the GNU ftp server alpha.gnu.org has recently been cracked, all the files were wiped out. This renders our build env setup scripts useless for a while. After reporting this to the classpath team, they have now restored the classpath 0.04 package on the alpha ftp server. I have taken this opportunity to update the setup scripts so that it installs more up-to-date versions of the build tools, and also to verify that aegisvm interoperates properly with classpath 0.04. These setup scripts download, compile and install all the tools necessary for developing aegisvm and libjpr. They have been tested on the x86 Debian machines from the SF compile farm and also on my Mandrake Linux 8.2 box. To save time and to stay current, please try out these scripts. To get the scripts, check out the following cvs module: Tools/Build Please read the README file in the module. 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-03 08:23:03
|
Hi Gildas, On Wed, 31 Jul 2002, Gildas Bazin wrote: > yes, if I use aegisvm foo.bar I will have the following error: > resolve.c:303: failed assertion: thread != 0 && classname != 0 && > j_utf8_is_class_name(classname) > because j_utf8_scan_qualified_name() doesn't deal with J_ASCII_period. > > The fix to j_utf8_scan_java_simple_class_name() is also needed if you want > to pass test names to mauve as foo/bar/foobar instead of foo.bar.foobar. The functions in utf8.h/c have precise meaning, and I don't think they are the cause of the problem. In theory, we should be able to say: aegisvm foo.bar to invoke the main method in class bar of package foo. We should also be able to say: aegisvm foo\$bar to invoke the main method of foo's inner class bar. The first, as you have pointed out, is broken, while the second seems to work okay. I looked again, and find that in aegisvm.c I have actually forgotten to convert the command line Java class name into its internal form. Also, in the native implementation of Class.define() I have used the wrong predicate to test the validity of the classname argument. Attached is the fix I just committed. Thanks for pointing out the problem. 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-03 01:04:01
|
Hi On Fri, 2 Aug 2002, Philip Fong wrote: > I committed the attached patch to the cvs repository (it is basically > your correction and your test files), with the following log entry: Yes, I forgot a backslash in the previous commit. The fault in mine, and it is fixed now. 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-03 00:48:31
|
Hi On Wed, 31 Jul 2002, Gildas Bazin wrote: > > (1) I am not sure what the patch on interpret.c (invokeinterface code) > > is for. Would you mind to explain a bit more? As I understand > > from the JVM spec the narg operand only counts the arguments > > but not the objectref. Am I missing something? > > I think the JVM spec is not clear there. This is also what I understood at > first, but I have a testcase that proves the objectref is in fact included > in the count. Have a look at the attached java files and try them with and > without the patch, you'll see :) > (I myself used AE_DEBUG_INSTR to find out what was really going on.) Silly me. I checked the JVM spec again, and figured from Section 4.8.1 that your interpretation definitely right. In fact, when I check the cvs snapshot for release 0.1.0, this is exactly what I did. I then did some crazy restructuring, and finally lost track of my sense of reality.... I committed the attached patch to the cvs repository (it is basically your correction and your test files), with the following log entry: Bug fix: Incorrectly interpreted the counts operand of invokeinterface as the number of words for the arguments only (excluding the objectref). Fix and test cases contributed by Gildas Bazin <gb...@al...>. 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-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: 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: Gildas B. <gb...@al...> - 2002-07-31 17:38:13
|
Hi Philip, On Friday 26 July 2002 21:43, Philip Fong wrote: > > One thing that I found out from rereading the relevant part of the JVM > spec is that there might be multiple line number table attributes > for a single method (if I am interpreting properly). I think most > sane compilers will generate a single such attribute for each method, > but still the spec allows it. I would propose to ignore the problem > for now, add an entry to the BUGS file, and move on to something > more productive. > Oh yeah I think you're right. I missed that one. Thanks for applying the patch. -- Gildas |
|
From: Gildas B. <gb...@al...> - 2002-07-31 17:36:27
|
On Saturday 27 July 2002 01:14, Philip Fong wrote: > > I have just committed the following: ... > > What is remaining are two particular patches: > (1) I am not sure what the patch on interpret.c (invokeinterface code) > is for. Would you mind to explain a bit more? As I understand > from the JVM spec the narg operand only counts the arguments > but not the objectref. Am I missing something? I think the JVM spec is not clear there. This is also what I understood at first, but I have a testcase that proves the objectref is in fact included in the count. Have a look at the attached java files and try them with and without the patch, you'll see :) (I myself used AE_DEBUG_INSTR to find out what was really going on.) > (2) Concerning the following patch: > > > - jpr.diff (patch to j_utf8_scan_qualified_name() and > > j_utf8_scan_java_simple_class_name(). I'm not sure these are the right > > fixes for the problem but I know there definitely is a problem with name > > recognition as mauve and several other programs expect JVMs to accept in > > there command line names like foo.bar as a java program to execute) > > Do you mean that, say the main() method of a Java program resides > in class foo.bar, typing "aegisvm foo.bar" does not properly > start the program? > yes, if I use aegisvm foo.bar I will have the following error: resolve.c:303: failed assertion: thread != 0 && classname != 0 && j_utf8_is_class_name(classname) because j_utf8_scan_qualified_name() doesn't deal with J_ASCII_period. The fix to j_utf8_scan_java_simple_class_name() is also needed if you want to pass test names to mauve as foo/bar/foobar instead of foo.bar.foobar. Regards, -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-07-26 23:14:42
|
Hi,
I have just committed the following:
> - other.diff (implements a few other things needed by mauve)
> - finalize-hack.diff (nasty hack that comments out "throw new
> FeatureNotYetImplementedError()" in runFinalization() in java.lang.System.
> It's commented out because I don't know how to implement it properly.)
What is remaining are two particular patches:
(1) I am not sure what the patch on interpret.c (invokeinterface code)
is for. Would you mind to explain a bit more? As I understand
from the JVM spec the narg operand only counts the arguments
but not the objectref. Am I missing something?
(2) Concerning the following patch:
> - jpr.diff (patch to j_utf8_scan_qualified_name() and
> j_utf8_scan_java_simple_class_name(). I'm not sure these are the right
> fixes for the problem but I know there definitely is a problem with name
> recognition as mauve and several other programs expect JVMs to accept in
> there command line names like foo.bar as a java program to execute)
Do you mean that, say the main() method of a Java program resides
in class foo.bar, typing "aegisvm foo.bar" does not properly
start the program?
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: Philip F. <pw...@us...> - 2002-07-26 22:51:16
|
Hi Gildas,
I just committed a modified version of your patch to the cvs, with
the following log entry:
New feature: Implementation of SourceFile and LineNumberTable attributes
as contributed by Gildas Bazin <gb...@al...>.
The modification mainly has to do with placing code at the right
module, nothing really special. Attached is what the resulting
patch looks like.
I also committed your changes to resolve.c into the cvs. I will
commit more of your patches in the next few days. Thanks again
for your help.
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-07-26 19:49:26
|
Hi Gildas, On Thu, 25 Jul 2002, Gildas Bazin wrote: > Here is the updated version which will apply to the current cvs. It also > fixes a stupid but nasty bug from my former patch (I wasn't using the > correct local variable in one place). Thanks for the new patch. I am actually in the process of adding your stuff into the cvs. Most of what I did was really just moving things to the right module etc. One thing that I found out from rereading the relevant part of the JVM spec is that there might be multiple line number table attributes for a single method (if I am interpreting properly). I think most sane compilers will generate a single such attribute for each method, but still the spec allows it. I would propose to ignore the problem for now, add an entry to the BUGS file, and move on to something more productive. 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-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: Philip F. <pw...@us...> - 2002-07-26 19:20:42
|
Hi Gildas, On Thu, 25 Jul 2002, Gildas Bazin wrote: > I like to live on the bleeding edge so I'm always using an up to date CVS :) Good. I sometimes move code around just to amuse myself :-) If that starts to annoy you, please let me know, and I'll do that in a more disciplined way. > Humm, I'm not sure I understand you there. > > The only overhead that this patch adds in terms of memory usage is that it > stores an additional ju2 field in AEClass to keep the index of the java > source file name in the constant pool. And another additional 2 fields in > AEMethod to store an array of line numbers and pc correspondance and the > size of this array. > > Which means that only the additional array will really create an overhead, > but this array will be allocated only if the bytecode class file actually > contains the line numbers debug info. > If the user doesn't want this overhead than it should be up to him to > compile the java source code without this debug info. Yes, I agree that the additional memory usage is going to be quite insignificant when you run the VM as a standalone application on a typical desktop environment. However, my "secret" ambition is to target this VM to embedded environment, or simply have it embedded inside other applications as an extension framework (e.g. like Lisp to emacs). For such kind of applications, I am not sure if people actually need the additional memory overhead to track source line number. Therefore, I thought it might be nice to give the user a choice. What I would do is this: I will add an option to the configure script so that people can turn off the processing of line number information if they wish to. However, as I said before, this feature that you implemented is so useful for normal, sane users, the line number tracking mechanism is turned on by default. Does that sound fair? > ( that reminds me that "method->lines_count" and "method->lines" are not > properly initialised to 0 in the patch I sent you. I'll send you an updated > version ) Yes, I spotted that. And sure, an update would be helpful. > Sorry for confusing you, I'm already subscribed it's just that I didn't send > this email from the mail account which I used to suscribe. Welcome aboard. :-) 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 23:05:56
|
Hi, As I already told you, I've been trying to run mauve on aegisvm but with the current cvs version mauve doesn't even bootstrap. I finally got it running though. I had a really quick run at some of these tests and as you might already guess, there are quite a few which fail with aegisvm but at least now we've got an extensive testsuite to find and correct the problems :) So to be able to run mauve you have to apply the following patches: - jni.diff (patch that I already sent) - bug.diff (fixes two important bugs in aegisvm. the commentaries in the patch should be self explanatory) - other.diff (implements a few other things needed by mauve) - finalize-hack.diff (nasty hack that comments out "throw new FeatureNotYetImplementedError()" in runFinalization() in java.lang.System. It's commented out because I don't know how to implement it properly.) - jpr.diff (patch to j_utf8_scan_qualified_name() and j_utf8_scan_java_simple_class_name(). I'm not sure these are the right fixes for the problem but I know there definitely is a problem with name recognition as mauve and several other programs expect JVMs to accept in there command line names like foo.bar as a java program to execute) Enjoy :) -- Gildas |
|
From: Gildas B. <gb...@al...> - 2002-07-25 21:49:11
|
On Thursday 25 July 2002 11:39, Gildas Bazin wrote: > > ( that reminds me that "method->lines_count" and "method->lines" are not > properly initialised to 0 in the patch I sent you. I'll send you an updated > version ) > Here is the updated version which will apply to the current cvs. It also fixes a stupid but nasty bug from my former patch (I wasn't using the correct local variable in one place). Regards, -- Gildas |
|
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: Gildas B. <gb...@al...> - 2002-07-25 09:41:17
|
On Wednesday 24 July 2002 23:58, Philip Fong wrote: > Hi Gildas > > Yes, this is definitely useful. This is going to help debugging a lot. > I've just skimmed through the code a bit, and it looks okay. So, out of > which version (or CVS tag) is you patch made. I'll need this in order > to actually integrate your code into the CVS. I like to live on the bleeding edge so I'm always using an up to date CVS :) > I think what I will do is to add a configure switch so that your new > feature is on by default, and for those who really want to reduce class > size when the VM is deployed, they can choose to turn off the feature. > What do you think? Humm, I'm not sure I understand you there. The only overhead that this patch adds in terms of memory usage is that it stores an additional ju2 field in AEClass to keep the index of the java source file name in the constant pool. And another additional 2 fields in AEMethod to store an array of line numbers and pc correspondance and the size of this array. Which means that only the additional array will really create an overhead, but this array will be allocated only if the bytecode class file actually contains the line numbers debug info. If the user doesn't want this overhead than it should be up to him to compile the java source code without this debug info. ( that reminds me that "method->lines_count" and "method->lines" are not properly initialised to 0 in the patch I sent you. I'll send you an updated version ) > If you are tracking the CVS, you'll notice that I am doing quite a > bit of restructuring recently. Would you like to subscribe to > the development mailing list so that you can be kept up to date > about when it is a good time to synchronize your code with the CVS > repository? > Sorry for confusing you, I'm already subscribed it's just that I didn't send this email from the mail account which I used to suscribe. 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: Philip F. <pw...@us...> - 2002-07-24 21:58:42
|
Hi Gildas On Tue, 23 Jul 2002, Gildas Bazin wrote: > Here is my first contribution :) A patch that adds debug information to > printStackTrace(). > Basically it parses the SourceFile attributes and the LineNumberTable > attributes of the Code attributes in the class files. > > Could someone review this before applying to the cvs because I'm not too > familiar yet with aegisvm's internals and there might be some mistakes. > > Hope you'll find this useful, Yes, this is definitely useful. This is going to help debugging a lot. I've just skimmed through the code a bit, and it looks okay. So, out of which version (or CVS tag) is you patch made. I'll need this in order to actually integrate your code into the CVS. I think what I will do is to add a configure switch so that your new feature is on by default, and for those who really want to reduce class size when the VM is deployed, they can choose to turn off the feature. What do you think? > PS: there's a also a big patch to jni.c coming :) I am just curious... what is this big patch going to do? Can't wait to see it. If you are tracking the CVS, you'll notice that I am doing quite a bit of restructuring recently. Would you like to subscribe to the development mailing list so that you can be kept up to date about when it is a good time to synchronize your code with the CVS repository? Again, thanks a lot for your patch. 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. |