aegisvm-devel Mailing List for The Aegis VM Project
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: Justin B. <jus...@ya...> - 2003-05-05 16:16:37
|
Hello all, I've implemented a new Double.toString() routine as described in the paper by Burger and Dybvig, and suggested in the AegisVM BUGS file. Previously this routine could cause OutOfMemory Exceptions or rounding errors. The new implementation is generally much faster, rounds correctly in nearly all cases, and doesn't crash. In it's implementation I have made an effort to mirror the paper's implementation where possible for purposes of clarity. Things left variable in the paper (like output base - which for us is always 10) are named constants, etc. I have also made some optimizations to the DoubleParser class which fix many imprecisions by reducing inexact intermediate calculations to a minimum. These updated routines are not perfect however; there are a few cases where toString will round imperfectly. This may be due to the need to use double arithmetic for intermediate calculations (due to the large range of possible numbers). There are somewhat more cases where parseDouble() generates an imprecise double. The cases I've noted are near the resolution of the double type (up to two bits of imprecision). Of course, that isn't good enough for some applications. I've included the modified version of JavaLangNumber.java which I used to test these routines, which show where they may fail. To conclude, both routines are improved, but remain imperfect. Additionally, both of these routines may benefit by being made native, instead of implemented in Java, given their complexity and low-level nature. Regardless, I hope they are useful. -Justin Briggs __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Justin B. <jus...@ya...> - 2003-05-05 07:50:48
|
Hello all, I've got a working version of aegis that is based on older sources, and to which I've made some modifications. I've tried to incorporate these changes into the latest development source code. I think I've got everything right but it's possible I've missed something new. All of this code works with my version. As well as fixing various minor typos and removing some compilation warnings under my compiler, the changes can be summarized as follows: 1) JNI additions, which were heavily based on code from Gildas Bazin. These implement New<PrimitiveType>Array(), Get<PrimitiveType>ArrayRegion and Set<PrimitiveType>ArrayRegion, as well as GetObjectArrayElement. Files affected: jni.c, jni.h 2) Invocation of static native methods changed to pass class as second parameter, as per the Java Native Interface Specification 1.1, Ch 2, Section Native Method Arguments. Previously only the JNIEnv pointer was being passed to static native methods. This required changing all the built-in static native methods' prototypes. Files affected: invoke.c, jni.c, prepare.c, jpr/ff.c, jpr/ff.h 3) Dynamic expansion of the internal heap used by java programs, by using an algorithm that grows the heap at garbage collection time. Maximum and minimum limits can be set, as well as a maximum number of garbage collection executions before growing. There are surely other ways of making the heap dynamic (probably by re-implementing the gc), but this method allows the garbage collector to largely remain intact. In this algorithm, the heap is seperated into two sections. When the garbage collector copies from one to another (thus performing the garbage collection by only copying valid pointers), and it finds that there isn't enough space left over in the heap afterwards, it re-allocates a larger memory slice for the target section of the heap, effectively growing it. (The next garbage collection the other section grows also). Files Affected: gc.h, gc.c, builtin.c 3) Implemented updated java/lang/String and java/lang/StringBuffer support, allowing sharing of backing arrays whenever reasonable. These were taken from the GNU classpath project, and modified. StringBuffer is essentially the same, with only one added check to ensure that large backing arrays are not hanging around needlessly. String is a mix of (mostly) GNU's String, aegis' String, and some other additions. These changes were made mostly because of internal aegis dependence upon the format of string class. Notably, the StringHashTable has been retained from aegis' version, and the ToUpperCase/toLowerCase() functions were modified. These changes at times provide a big improvement in efficiency and space usage. Note: the GNU StringBuffer class can be used unchanged. The Error.java I submit IS the GNU class. Files affected: java/lang/String.java, java/lang/StringBuffer.java, java/lang/Error.java, gc.c, jni.c, builtin.c, object.h, resolve.c A zip of the diffs is attached. I think aegis is well written and hope these changes will prove useful to it's further development. Please let me know if there are any problems or if you have questions. -Justin Briggs __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Philip F. <pw...@us...> - 2003-01-16 17:57:10
|
Hi, Yes, the project is still alive. I have recently turned my focus to thesis writing and job search, and so development has slowed down. Now that I got some foundational chapters written, I will resume coding again hopefully next week or even sooner. As for the garbage collection algorithm, I highly recommend the following book: Richard Jones Garbage collection : algorithms for automatic dynamic memory management Wiley 1996 The algorithm I used is the basic copying garbage collection algorithm. Nothing fancy has been done. Let me know if you need more information. Philip On Thu, 16 Jan 2003 mad...@ne... wrote: > Hello! Anyone still working on this project? Was just curious if it still had life in it. I like the > project and would like to contribute more if it's still going. Phillip, I had a question. Do you have > any info/documentation on the garbage collector used by AegisVM? > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Thawte.com > Understand how to protect your customers personal information by implementing > SSL on your Apache Web Server. Click here to get our FREE Thawte Apache > Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en > _______________________________________________ > Aegisvm-devel mailing list > Aeg...@li... > https://lists.sourceforge.net/lists/listinfo/aegisvm-devel > -- 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: <mad...@ne...> - 2003-01-16 16:21:49
|
Hello! Anyone still working on this project? Was just curious if it still had life in it. I like the project and would like to contribute more if it's still going. Phillip, I had a question. Do you have any info/documentation on the garbage collector used by AegisVM? |
|
From: Philip F. <pw...@us...> - 2002-12-22 04:32:36
|
Hi Manish Thank you for your interest. Yes, it is great that you want to contribute. One task is to look at the JNI implementation and try to fill in whatever is missing. I think this is a nice way to get you started. A more challenging one is to set up Aegis VM to run the Mauve test suite (http://sources.redhat/mauve). This is *REALLY* going to help the project a lot in the long run. Do they sound interesting? Let me know if you would prefer something else. BTW, I apologize for the unpromptly reply. I am currently rushing my PhD thesis proposal, which I am defending on Dec 30. After that, I'll have more time coding. :-) Philip On Thu, 19 Dec 2002, manish handa wrote: > Hi, > My name is manish handa and i am a software engineer. > I read about Aegis project from one of the sourceforge > mailing > lists. I would like to contribute to this project. So > please help me out by teliing me ... how and where > should i start with. I am > familiar with C/C++ and Java. I am also quite familiar > with the Linux Platfor(red hat and a bit of debian as > well). So it would > be very kind of you if you could suggest me something. > > Regards > Manish Handa > Software Engineer > Newgen Software Technologies Ltd. > India > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- 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-10-23 19:02:37
|
Hi Gildas, Well, I tried my best, and libffi even seems to install properly, with only one seemingly innocent linker warning: some of the symbols are not defined! Trying to link the patched JPR against this version of libffi fails because of the missing symbols. Do you think you could use "make dist" to create a copy of your working libffi snapshot, so I could work with that? Otherwise, I really have run out of ideas as to how I could proceed. Also, if I understand correctly, your libffi patch is only needed for compiling with VC++, right? Thanks. Philip On Tue, 22 Oct 2002, Philip Fong wrote: > Hi Gildas, > > Sorry about the whining. I found a clean fix of the libffi problem. > Their current version of configure.in/Makefile.am is likely broken. > I'll include fixing instruction in your README file. Thanks. > > Philip > > On Tue, 22 Oct 2002, Philip Fong wrote: > > > Hi Gildas, > > > > I am trying very hard to merge your win32 port into the CVS tree, but > > I am having major difficulty setting up the environment on my winME box. > > The main thing is that I am not able to build the latest cvs snapshot > > of libffi. I tried several things: > > 1/ In the cvs checkout there is a copy of configure script. If I use it > > directly, it complains missing a certain ./../config-ml.in. Obviously, > > the setting of $libffi_basedir was messed up inside the configure > > script. > > 2/ I then tried running automake/autoconf to regenerate the configure > > script. The ones that seem to work produce Makefiles that require > > the substitutions @CCAS@ and @CCASFLAGS@, which are not actually > > defined. With this broken Makefile, assembly fails. > > 3/ I even tried brute-force mutilating of the generated Makefiles and > > configure scripts, but nothing works. > > 4/ I tried working with the cross-compiler you suggested, same thing > > happened. > > 5/ I then tried doing a normal unix build on my linux box. The > > same things occurred, and so I conclude that it has nothing to do > > with the windows setup. Even building libffi for linux would > > not work. > > > > So, would you let me know exactly which CVS snapshot of libffi are you > > using (e.g. which date)? And which exact version of autoconf/automake > > did you use? Somehow, the latest snapshot of libffi doesn't like my > > autotools installation. > > > > Thank you in advance. I really look forward to merging your port into the > > cvs tree. > > > > 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. > > > > > > > > ------------------------------------------------------- > > This sf.net emial is sponsored by: Influence the future > > of Java(TM) technology. Join the Java Community > > Process(SM) (JCP(SM)) program now. > > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > > _______________________________________________ > > Aegisvm-devel mailing list > > Aeg...@li... > > https://lists.sourceforge.net/lists/listinfo/aegisvm-devel > > > > -- > 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. > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Aegisvm-devel mailing list > Aeg...@li... > https://lists.sourceforge.net/lists/listinfo/aegisvm-devel > -- 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-10-22 23:16:28
|
Hi Gildas, Sorry about the whining. I found a clean fix of the libffi problem. Their current version of configure.in/Makefile.am is likely broken. I'll include fixing instruction in your README file. Thanks. Philip On Tue, 22 Oct 2002, Philip Fong wrote: > Hi Gildas, > > I am trying very hard to merge your win32 port into the CVS tree, but > I am having major difficulty setting up the environment on my winME box. > The main thing is that I am not able to build the latest cvs snapshot > of libffi. I tried several things: > 1/ In the cvs checkout there is a copy of configure script. If I use it > directly, it complains missing a certain ./../config-ml.in. Obviously, > the setting of $libffi_basedir was messed up inside the configure > script. > 2/ I then tried running automake/autoconf to regenerate the configure > script. The ones that seem to work produce Makefiles that require > the substitutions @CCAS@ and @CCASFLAGS@, which are not actually > defined. With this broken Makefile, assembly fails. > 3/ I even tried brute-force mutilating of the generated Makefiles and > configure scripts, but nothing works. > 4/ I tried working with the cross-compiler you suggested, same thing > happened. > 5/ I then tried doing a normal unix build on my linux box. The > same things occurred, and so I conclude that it has nothing to do > with the windows setup. Even building libffi for linux would > not work. > > So, would you let me know exactly which CVS snapshot of libffi are you > using (e.g. which date)? And which exact version of autoconf/automake > did you use? Somehow, the latest snapshot of libffi doesn't like my > autotools installation. > > Thank you in advance. I really look forward to merging your port into the > cvs tree. > > 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. > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Aegisvm-devel mailing list > Aeg...@li... > https://lists.sourceforge.net/lists/listinfo/aegisvm-devel > -- 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-10-22 21:04:14
|
Hi Gildas, I am trying very hard to merge your win32 port into the CVS tree, but I am having major difficulty setting up the environment on my winME box. The main thing is that I am not able to build the latest cvs snapshot of libffi. I tried several things: 1/ In the cvs checkout there is a copy of configure script. If I use it directly, it complains missing a certain ./../config-ml.in. Obviously, the setting of $libffi_basedir was messed up inside the configure script. 2/ I then tried running automake/autoconf to regenerate the configure script. The ones that seem to work produce Makefiles that require the substitutions @CCAS@ and @CCASFLAGS@, which are not actually defined. With this broken Makefile, assembly fails. 3/ I even tried brute-force mutilating of the generated Makefiles and configure scripts, but nothing works. 4/ I tried working with the cross-compiler you suggested, same thing happened. 5/ I then tried doing a normal unix build on my linux box. The same things occurred, and so I conclude that it has nothing to do with the windows setup. Even building libffi for linux would not work. So, would you let me know exactly which CVS snapshot of libffi are you using (e.g. which date)? And which exact version of autoconf/automake did you use? Somehow, the latest snapshot of libffi doesn't like my autotools installation. Thank you in advance. I really look forward to merging your port into the cvs tree. 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-10-17 11:20:25
|
On Thursday 17 October 2002 02:39, Philip Fong wrote: > Hi Gildas, > > I am trying to process your win32 port. Need to ask you for help with > some configuration stuff. > > 1. I set up the mingw environment on my winME box. Somehow the cvs > from msysDTK hangs whenever I perform cvs operations. It kind of > performs the operation, but then does not known how to shut down. > Have you experienced this anomaly before? I could have lived > with WinCVS, but it is also buggy (it does not do cvs release), > and I would hope to get my familiar command line cvs working. :-) To be honest, I never tried the cvs included with msysDTK so I don't know, it might have a problem. Lately, I have been expermimenting with cygwin (www.cygwin.com). Cygwin is a quite stable environment and I know for sure its cvs command is working fine. Theoretically, you should also be able to use cygwin to build JPR and AegisVM, although I'm pretty sure you'll have to make a few changes to the build system (and I haven't tried myself). One of this changes would be to use CC="gcc -mno-cygwin" in order to build to build an exectuable which isn't dependant on the cygwin portability layer. > 2. If I understand correctly, the patch to libffi is only for building > libffi with MSVC and for cross-compiling from linux. So, I tried > building a cvs version of libffi without your patch on mingw, but > the configure script does not seem to be working on the mingw > environment. What I am asking is, which snapshot of libffi are > you using (e.g. date tag)? Would it be because I am using the > wrong snapshot? > Ah sorry, I forgot to tell you that you need to use the current cvs version of libffi (from http://sources.redhat.com/libffi/). This version already had some work done to support mingw32. > Thanks for your help. I am really eager to merge your work into > the cvs tree. :-) > Thanks for you time. -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-10-17 00:39:43
|
Hi Gildas, I am trying to process your win32 port. Need to ask you for help with some configuration stuff. 1. I set up the mingw environment on my winME box. Somehow the cvs from msysDTK hangs whenever I perform cvs operations. It kind of performs the operation, but then does not known how to shut down. Have you experienced this anomaly before? I could have lived with WinCVS, but it is also buggy (it does not do cvs release), and I would hope to get my familiar command line cvs working. :-) 2. If I understand correctly, the patch to libffi is only for building libffi with MSVC and for cross-compiling from linux. So, I tried building a cvs version of libffi without your patch on mingw, but the configure script does not seem to be working on the mingw environment. What I am asking is, which snapshot of libffi are you using (e.g. date tag)? Would it be because I am using the wrong snapshot? Thanks for your help. I am really eager to merge your work into the cvs tree. :-) Philip On Sun, 22 Sep 2002, Gildas Bazin wrote: > 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 -- 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-10-12 10:48:24
|
Can't believe how careless I was: I missed the compiler warnings generated by the previously committed patch. Here is the corrected one. 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-10-12 10:38:05
|
Hi Gildas,
I just committed your JNI code with the following log:
New feature: Implementation of JNI functions Throw, ThrowNew,
ExceptionOccurred, AllocObject, and NewObjectV. Based on a patch
contributed by Gildas Bazin <gb...@al...>.
I modified your patch a bit:
- I like the way you reuse primitive JNI functions to implement
higher level JNI functions. I push your idea as much as I could.
That is why some of the low level calls in ThrowNew & NewObjectV
are eliminated. The most noticable one is the elimination for the
need to create yet another method invocation function.
- As for accessibility, I am as lost as you are. The JNI spec does
not prescribe any accessibility tests at the sites you pointed out.
The general philosophy is that JNI should be allowed to by-pass
accessibility checks. This is actually how some of the built-in
classes are implemented. My guess is that we don't really need
anything at those two spots.
- ThrowNew: The local reference allocated for the string should
be released before returning.
- ExceptionOccurred: The exception object should be wrapped by
a local reference.
The rest are basically the same as your patch. Attached is the
diff I actually committed.
Philip
PS: Please let me know if you need ae_invoke_method_v for other
purpose. I'll then add it back.
On Sun, 22 Sep 2002, Gildas Bazin wrote:
> Hi,
>
> I implemented another few JNI functions:
>
> jint ae_jni_Throw(JNIEnv *env, jthrowable obj)
> jint ae_jni_ThrowNew(JNIEnv *env, jclass clazz, const char *message)
> jthrowable ae_jni_ExceptionOccurred(JNIEnv *env)
> jobject ae_jni_AllocObject(JNIEnv *env, jclass clazz)
> jobject ae_jni_NewObjectV(JNIEnv *env, jclass clazz, jmethodID methodID,
> va_list args)
>
> ae_jni_AllocObject, ae_jni_NewObjectV are not complete. They are missing an
> accessibility check at the beginning, but to be honest I don't really know
> how to do that and I'm kind of hoping you'll add it yourself ;-)
>
> Regards,
>
> --
> Gildas
--
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-10-11 23:36:53
|
Hi, I just committed your patch with the following log: Bug fix: Segmentation fault would result when AegisVM shutdown with several namespaces (for instance when you loaded native lib). This patch was contributed by Gildas Bazin <ab...@al...>. Philip On Wed, 9 Oct 2002, Gildas Bazin wrote: > Hi Philip, > > Here is a small fix for a bug that happens only during AegisVM shutdown when > several namespaces where defined (for instance when you load native lib). > > Regards, > > -- > Gildas -- 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-10-10 00:41:16
|
Hi Gildas, Thanks for the patch. BTW, I have not forgotten your mingw port. I just finished setting up my Windows box recently. It now has MinGW, emacs, ssh, etc. I'll work on your thing asap. It's just that I think it would be very irresponsible for me to just commit your changes without actually trying to compile and run it on an actual Windows box. That is why the delay... How come I always manage to find an excuse when I procrastinate... ;-) Philip On Wed, 9 Oct 2002, Gildas Bazin wrote: > Hi Philip, > > Here is a small fix for a bug that happens only during AegisVM shutdown when > several namespaces where defined (for instance when you load native lib). > > Regards, > > -- > Gildas -- 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-10-09 19:54:00
|
Hi Philip, Here is a small fix for a bug that happens only during AegisVM shutdown when several namespaces where defined (for instance when you load native lib). Regards, -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-10-09 19:02:02
|
Hi I just committed your patch to the CVS repository with the following log: Bug fix: Division by zero is now properly handled in idiv/irem/ldiv/lrem. The fix is contributed by madhatter <mad...@al...>. The committed code is basically the same as yours, except for minor stylistic adjustment. I also added in some simple test scripts for trying out your code. Attached is the actual diff that I committed. Thanks for contributing. Philip On Tue, 8 Oct 2002, madhatter wrote: > Hi, attached is a patch that does a divide by zero check, and if necessary throws an ArithmeticException on all division opcodes. It's also at http://www.alpha-beta.org/madhatter/aegisvm.div_ArithmeticException.diff if you want to get it there. Um, the code is directly in the inner loop of ae_interpret_bytecode, which might not be what you want, since it's the same code written twice for each data type (division and remainder ops), if you want me to implement it as a macro that's fine. I hope to do more with AegisVM, let me know. > > > -- 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-10-09 18:04:40
|
Hi madhatter, On Tue, 8 Oct 2002, madhatter wrote: > Hi, attached is a patch that does a divide by zero check, and if necessary throws an ArithmeticException on all division opcodes. It's also at http://www.alpha-beta.org/madhatter/aegisvm.div_ArithmeticException.diff if you want to get it there. Um, the code is directly in the inner loop of ae_interpret_bytecode, which might not be what you want, since it's the same code written twice for each data type (division and remainder ops), if you want me to implement it as a macro that's fine. I hope to do more with AegisVM, let me know. Thank you for contributing. The code that fixes idiv/irem/ldiv/lrem looks fine to me. I'll commit the diff today. However, the code that throw exceptions on the floating point cases is actually redundant. According to the JVM Spec, division by zero should result in NaN in the floating point cases. The standard semantics of C's floating point division already covers this. Thanks again for contributing. There is still a lot of work to be done on Aegis VM. Any further help is welcome. 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: madhatter <mad...@al...> - 2002-10-08 13:49:29
|
Hi, attached is a patch that does a divide by zero check, and if necessary throws an ArithmeticException on all division opcodes. It's also at http://www.alpha-beta.org/madhatter/aegisvm.div_ArithmeticException.diff if you want to get it there. Um, the code is directly in the inner loop of ae_interpret_bytecode, which might not be what you want, since it's the same code written twice for each data type (division and remainder ops), if you want me to implement it as a macro that's fine. I hope to do more with AegisVM, let me know. |
|
From: madhatter <mad...@al...> - 2002-10-07 22:36:44
|
Hello, I was just working on throwing an ArithmeticException on a divide by zero in the DO_n_REDUCE macros, and had a question. I went through the dox html and found ae_thread_exception_throw() and figured that's what I'll be using (unless you tell me otherwise), and am not sure how to fill in the first argument (the thread). Is there a function to fill in this value for me (i.e. how do i retrieve the current thread)? Thanks. mad...@al... |
|
From: Philip F. <pw...@us...> - 2002-09-28 05:49:16
|
Hi Gildas, Just committed your patch to the cvs repository, with the following log entry: A new JFile abstraction, contributed by Gildas Bazin (gb...@al...), that supports file mapping on win32 platforms. I also update the doxygen documentation accordingly. 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-09-26 21:49:22
|
On Thursday 26 September 2002 22:43, Philip Fong wrote: > > Thanks for contributing again. I just got back from a vacation. Ah, lucky you ;) > Will look at your patches asap. > Ok, thanks. > > BTW, how do you get GNU Classpath running on win32? Have they already > ported it to win32, or did you do it single-handedly? If you did it > yourself, it must have been a lot of work! > Well, actually it could have been worse because I made use of ansi functions provided by Microsoft's standard C runtime library (MSVCRT.DLL). That means that I basically had to port only the bits that are not ansi conformant. But not everything is tested, for instance the network stuff isn't so it may not work at all. Cheers, -- Gildas |
|
From: Philip F. <pw...@us...> - 2002-09-26 20:43:41
|
Hi Gildas,
On Sat, 21 Sep 2002, Gildas Bazin wrote:
> I've got a few more patches to propose you :)
Thanks for contributing again. I just got back from a vacation.
Will look at your patches asap.
> 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.
This is great. Don't feel bad about breaking the JPR API. I do that
all the time. :-) I don't think the JPR API will be stable until
we get AegisVM and the coming Prelude package are more mature.
> 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.
Perfect.
> I think hidding the platform specific details in a structure like this does
> make aegisvm more platform independant.
You are right.
> 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.
I'll look at the other patches asap. Thanks for your effort.
BTW, how do you get GNU Classpath running on win32? Have they already
ported it to win32, or did you do it single-handedly? If you did it
yourself, it must have been a lot of work!
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-09-22 20:50:47
|
On Sunday 22 September 2002 21:37, Gildas Bazin wrote: > Hi Philip, > > Here are a few patches needed to build ( and run :) a Win32 version of > AegisVM. > ... > 5) jpr_misc.diff: a few other changes to JPR which are needed for the > win32 build. > Sorry about this but this diff was broken. Here is an updated version. Regards, -- Gildas |
|
From: Gildas B. <gb...@al...> - 2002-09-22 19:45:27
|
Hi, I implemented another few JNI functions: jint ae_jni_Throw(JNIEnv *env, jthrowable obj) jint ae_jni_ThrowNew(JNIEnv *env, jclass clazz, const char *message) jthrowable ae_jni_ExceptionOccurred(JNIEnv *env) jobject ae_jni_AllocObject(JNIEnv *env, jclass clazz) jobject ae_jni_NewObjectV(JNIEnv *env, jclass clazz, jmethodID methodID, va_list args) ae_jni_AllocObject, ae_jni_NewObjectV are not complete. They are missing an accessibility check at the beginning, but to be honest I don't really know how to do that and I'm kind of hoping you'll add it yourself ;-) Regards, -- Gildas |
|
From: Gildas B. <gb...@al...> - 2002-09-22 19:37:20
|
Hi Philip, Here are a few patches needed to build ( and run :) a Win32 version of AegisVM. 1) README.win32: instructions on how to build the aegisvm for win32. 2) aegisvm_build.diff: a few modifications to the build system to be able to compile or cross-compile the win32 build. 3) aegisvm_correctness.diff: various fixed typos and also syntax fixes that MSVC needs in order to get rid of annoying warnings. 4) aegisvm_static.diff: A big problem of the win32 build is that I didn't manage yet to correctly build and run the shared libraries version of aegisvm. Currently aegisvm for win32 will only work when libaegisvm is statically linked into the final executable. In order to have aegisvm working when statically linked, I had to declare an array with all the names and pointers of all the builtin native functions. Each time aegsivm wants to load a native function, we first loop through this array to check if the function is a builtin native... This is maybe not really nice because we need to maintain this array each time we add or remove builtin natives from builtin.c but this is the only way to have aegisvm still working when statically linked. 5) jpr_mis.diff: a few other changes to JPR which are needed for the win32 build. 6) jpr_log.diff and aegisvm_log.diff: Ah these ones are kind of kludgy... These patches work around the fact that MSVC (microsof visual c++ compiler) is not C99 compliant and doesn't recognize variadic macros. I basically replaced all statements like: #define ae_debug_wrapper(...) j_log(__VA_ARGS__) with: #define ae_debug_wrapper j_log 7) classpath.win32.patch: is a patch for the GNU Classpath distribution so it can be compiled for win32 too. There are instructions in on how to compile this in the INSTALL.win32 file included in the patch. I guess that's it. You should be able to run aegisvm on Windows with this :) Don't hesitate to ask any questions you've got. Regards, -- Gildas |
