aegisvm-devel Mailing List for The Aegis VM Project (Page 3)
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-07-23 21:33:40
|
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: Gildas B. <gb...@ne...> - 2002-07-23 08:40:15
|
And as always I forgot to actually include the patch :-O -- Gildas |
|
From: Gildas B. <gb...@ne...> - 2002-07-23 08:34:10
|
Hi, I discovered aegisvm a few weeks ago and I must say it is a really nice project especially for one who wants to learn about JVM internals :) 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, -- Gildas PS: there's a also a big patch to jni.c coming :) |
|
From: Philip F. <pw...@us...> - 2002-07-12 23:37:52
|
Hi Our project is listed on the Doxygen web site as one of their users. Check it out: http://www.stack.nl/~dimitri/doxygen/projects.html Speaking of Doxygen, it is the tool we use in order to generate cross-referenced HTML documentation for both libjpr and aegisvm. (Type "make dox" to generate them. See HACKING for more detail.) I am gradually populating the documentation pages, and the result looks really nice. Thanks to the suggestions from Chris, who initiated this documentation effort. 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-06-22 23:18:43
|
Hi Some of you have reported difficulty with setting up the build environment, especially with all its dependencies on other projects. As of last Wednesday, my supervisor has placed an order on a P4 linux box which will be used for supporting development of this and other projects. When it is ready, you may be given access to the machine via ssh. However, if you cannot wait, here is another solution. I have tried setting up the build environment on the x86 Linux machine of the SourceForge compile farm. I recorded everything I did in two bash shell scripts. You may access them from the Tools/Build module of the cvs repository. Just type two commands and everything will be downloaded, compiled, and installed for you. Check out the README file in the Tools/Build module. To access the compile farm, you need to be a member of a SourceForge project. So, if you are interested, please register at SourceForge, and then let me know. I'll add you into the developer list. With this set up, you may even work from your Windows box by ssh'ing into the SourceForge compile farm. The exercise also uncovers a number of bugs in the bootstrap script, configure.in/ac, and Makefile.am. A minor bug was also fixed in order to make things work with IBM's Jikes compiler. A stable snapshot of the cvs repository is the following: JPR/ release-libjpr-0_1_0a AegisVM/ release-aegisvm-0_1_0a You are advised to build your work on top of the above rather than release 0.1.0, which is now considered less robust. 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-06-12 10:47:02
|
Hi all,
Release 0.1.0 is finally out. The CVS tags for libjpr 0.1.0 and
aegisvm 0.1.0 are, as usual, release-libjpr-0_1_0 and
release-aegisvm-0_1_0 respectively. Please do check out a working
copy and play with it.
The HACKING file is now updated with a lot more information
on configuring and building the packages. As aegisvm now depends
on another pre-alpha package, the GNU Classpath library, you are
going to need such help. Also, Doxygen generated hypertext
documentation is now available ("make dox"). Thanks for Chis' input.
The 0.1.x cycle will focus on improving the usability and security of
the VM. Please consult the TODO file for a new list of tasks open
for contribution.
Two more good news. My supervisor has agreed to acquire a Linux
cpu server for supporting the development of this project. Rumor
has it that you guys will be able to access it when the plan
materializes. Also, there will be two more Masters students
working on follow up of my research, which means that we will
have new developers joining the team.
Happy hacking!
Philip
--
Philip W. L. Fong pw...@us...
The Aegis VM Project http://aegisvm.sourceforge.net
|
|
From: Philip F. <pw...@us...> - 2002-05-28 18:45:54
|
Hi It is unfortunate that a recent spam email was circled via the aegisvm-users and aegisvm-devel mailing lists. I have now restricted posting priviledges to list members only, and I hope this would stop the problem for good. If you are still concerned, or the problem persists, please do let me know. Thanks. Philip -- Philip W. L. Fong pw...@us... The Aegis VM Project http://aegisvm.sourceforge.net |
|
From: DR. S. T. <sul...@ma...> - 2002-05-28 04:22:55
|
DR. SULEIMON TAFIDA NIGERIA NATIONAL PETROLEUM CORPORATION FEDERAL SECRETARIAT,FALOMO- LAGOS, NIGERIA. TELEPHONE: 234-1-775-0572 Dear Sir, As-Salaam Alaikun Wa- Rahamatullah First, I must solicit your trust and strictest confidence in this transaction, this is by virtue of it's nature as been utterly confidential and top secret. You were introduced to us by a mutual acquaintance from the Nigerian Chamber of Commerce, Foreign Trade Division. He does not know of the nature of what I am about to introduce to you. He only knows that I have some funds to invest abroad, hence he recommended you. I am the Director of Engineering & Project of the Nigerian National Petroleum Corporation(N.N.P.C) in Lagos, Nigeria. I am seeking your assistance to enable me transfer the sum of US$36,400,000.00 into your private or company account for mutual benefits. This money came about as a result of a contract for the supply of two thousand, three hundred and sixty-seven computer unit, installation and the Y2K compliance turn-around maintenance executed on behalf of my Ministry(N.N.P.C), in the year 1999. This contract was officially assigned to be awarded and executed by two foreign contractors at the tune of US$116,500,000.00, but in the course of my negotiation, I bargained with only one foreign contractor, a Bulgarian firm which now executed the contract at the cost ofUS$80,100.000.00. Thus leaving the remaining US$36.4million floating in the escrow account of the Central Bank of Nigeria(C.B.N) to the benefits of we the three members of the contract award panel unknown to the contractor and any other person in my Ministry. This contract has been satisfactorily executed, inspected and commissioned, and the Bulgarian firm is presently securing his payment from my Ministry. It is however to this effect that I seek your maximum assistance and approval to present your company name alongside with the Bulgarian contractor as the second foreign contractor to enable me transfer the difference (US$36.4M) into your account for further investment depending on your advice. On actualization of the transaction ,the funds will be shared thus: 1. 20% of the money go to you for acting as the beneficiary of the funds. 2. 10% for incidental expenses that may be incurred ie insurance, phone bills, documentation etc. 3. 70% to we three members of the Contract Award Panel. All logistics are in place and all modalities worked out for the smooth actualization of the transaction within fourteen working days of commencement after receipt of the following information by fax: Your company's Name. Address. Phone/Fax number and activities. Also, if we opt for electronic transfer only other than payment by solar bank draft or cash call program, then your bank account particulars. The above information will enable me make the payment application and lodge claims to the concerned Ministries in favor of your company or name and it is pertinent to state here that this deal is entirely based on trust and the fear of God. If you are able to handle it, feel free to reach me on phone number via my Telephone:231-1-775-0572 . which is my confidential line. Also furnish me with your own phone and fax numbers as I will be sending you all necessary registration documents immediately I receive your positive response. Thanks in anticipation for your positive response. yours faithfully. And may Allah increase your knowledge abundantly with extreme happiness. Aameen. Wasalaam Dr. SULEIMON TAFIDA (Director-NNPC) -- |
|
From: Philip F. <pw...@us...> - 2002-05-26 01:15:31
|
Hi After an unexpectedly long period of struggle, the Aegis VM can finally make use of the java.io package from the GNU classpath library. We end up needing to implement float/double arithmatic, reflection, and jsr/ret instructions just to make it possible to print a string to System.out. This means that everything I want to be in release 0.1.0 is more or less in place. What is left is really just cleaning up the code, which means release 0.1.0 will be out soon. This release will depend on even more external libraries. For example, libjpr will now depend on libltdl (comes with libtool), and aegisvm will depend on GNU classpath, which is relatively more complex to configure and compile than many of the software packages you have worked with. Given these concerns, I think for now it is better for you guys to concentrate on learning to setup the build environment rather than writing code. There are a number of exercises I would like you to complete: Exercise #1 =========== Try to compile and install libjpr-0.0.3 and aegisvm-0.0.3. Look at the .java files under the testsuite subdirectory to see what aegisvm 0.0.3 is capable of (also consult the FEATURES file). You will notice that it does not even have java.io. Instead it makes use of a class called aegis.Echo to print out testing output. Now, try to write up a Java program that could be run on aegisvm 0.0.3. It does not need to be complicated (e.g. just do some trivial computation and then print out the result). You will notice that Sun's javac does not know where to locate aegis.Echo. You need to set up the classpath properly for javac to be able to compile your program. Try using your installed aegisvm to execute the code. When you make sure that you know how to do this, uninstall aegisvm 0.0.3 and libjpr 0.0.3. Exercise #2 =========== Use anonymous cvs to check out the modules JPR and AegisVM from the project repository. Make sure you check out the versions tagged at release-aegisvm-0_1_0_pre1 and release-aegisvm-0_1_0_pre1. Look at the HACKING file. Install ALL the tools mentioned in the file. Make sure you try as much as possible to install a tool using the native package manager. For example, autoconf/automake/libtool/libffi are all available in Mandrake 8.2. Avoid downloading source tarball and compile a package if possible. Make sure the right version is invoked when you activate a tool. Then compile the cvs working copy of JPR and AegisVM. You will need to bootstrap the configuration scripts before you can configure. Look at the HACKING file that you checked out for instructions on how this can be done. Compile and install the built packages. Now repeat the first exercise, and try to run your Java program using this newly installed aegisvm. When you are done, uninstall the packages. Philip -- Philip W. L. Fong pw...@us... The Aegis VM Project http://aegisvm.sourceforge.net |
|
From: Philip F. <pw...@us...> - 2002-05-23 08:36:41
|
Hi, It is getting late, and I forgot to actually attach the file... Here it is. Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-23 08:34:22
|
Hi As I have mentioned to some of you, I am writing this tutorial that aim to help new Linux converts to become productive developer quickly. Attached is the first installment. I would really appreciate if you could browse though it and offer me some feed back. Is it useful? Does it contain the kind of information that will make your life easier? Of course, correcting my grammar and spelling is also very useful. :-) Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-22 23:28:28
|
Hi all, Many of you complained about the difficulty of setting up the build environment properly. Yes, I felt your pain, and I also would like you to spend your time on something more productive than installing software. :-) This is what I am doing to help: 1/ It turns out that Jerry is quite a Linux wizard himself. And it turns out that there is no shortage of Redhat Linux 7.2 based machines in the CSIL lab. Jerry is now checking out if those machines have all the tools we need. If so, that would be a perfect development environment. 2/ As Wei have suggested, I talked to Rob, and he is now considering the setting up of Linux workstations and servers in the Computer Language and Software Systems Lab. When that becomes a reality, you will be able to connect to a shell server from you Windows/Linux machine at home, and all the development tools will be in place for you. There might even be possibility that you will have access to the lab. This is the best scenario we can have. 3/ I filed a service request to the sourceforge administration, asking them to install all our development tools on their compile farm. It is unlikely they will comply though. If any of the above three possibilities materializes, then you will no longer need to struggle with setting up your own build environment. So, stay tuned... :-) Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-20 20:40:45
|
Hi Many of the development tools that we use are actually available from the Mandrake Linux 8.2 (or other major brand). You should avoid building those from source tarballs. I have added instructions for installing such Mandrake packages into the HACKING file: ** Notes for Mandrake Linux 8.2 Users If you are using Mandrake Linux 8.2, some of the above tools are already included in Mandrake's offering. You should try to install such tools using the native software manager rather than building them from source. Mandrake offers both autoconf 2.13 and 2.52. The 2.13 release is the standard autoconf package, and the 2.52 release is called autoconf2.5. You may install both packages. Mandrake has wrapper scripts that will detect from your configure.in/ac which one you should be invoked. Mandrake offers both automake 1.4 and 1.5. The 1.4 release is the standard automake package, and the 1.5 release is called automake1.5. Make sure you have uninstalled the automake package and installed the automake1.5 package. Libtool 1.4.2 is the standard libtool package in the distribution. Cvs2cl.pl is offered as the standard cvs2cl package in the distribution. The Perl script is renamed as cvs2cl. The Aegis VM configure script will detect if you have cvs2cl.pl or cvs2cl, and use the right one accordingly. The libffi package from the Mandrake offering could be used for compiling libjpr. Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-20 18:49:30
|
Hi Some of you mentioned that, given the lack of documentation, it is difficult to find the definition of functions and structures. One tool you can use to help understanding the code base are tags tables. Follow the instructions I sent to you in the last email to generate tags tables, and consult the following for instructions on how tags tables are used in emacs: http://www.gnu.org/manual/emacs/html_node/emacs_334.html Tags tables are basically cross-reference databases. In emacs, you can point the cursor to an occurrence of a symbol (e.g. a call site), press a key, and emacs will jump to the file containing the definition of the symbol (e.g. the function definition). Of course, there are keystrokes for bringing you back to where you were. This is a great tool for program understanding. BTW, java code is currently not tagged. If you need this facility, let me know. Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-20 18:16:56
|
Hi all, I have added the following information to the HACKING file. Hope it is useful to you. * Make Targets As the Makefiles are generated by autoconf/automake, they provides the standard targets specified in the GNU Coding Standard. We describe some of the more useful ones here. ** clean A "make clean" will remove all files generated by "make all". Do this when you need a clean build. ** maintainer-clean A "make maintainer-clean" will remove all generated files, including those that comes with the distribution (e.g. Makefiles, configure, etc). Normally you do not need to do a maintainer-clean. All you need is to modify the sources of the generated files, and the targets will be regenerated by make. Do a maintainer-clean only if you have all the tools mentioned in the previous section (you don't need cvs2cl.pl unless you are doing a "make dist" or a "make distcheck"). ** check A "make check" will run all the regression test scripts. Do this after you make changes assures that you haven't broken anything. ** tags/TAGS A "make tags" or "make TAGS" will run GNU etag to generate TAGS files (i.e. cross-reference databases) for all subdirectories. You can then use the GNU emacs editor to navigate the code base. ** dist A "make dist" will create a tarball of the distribution. The ChangeLog file is generated by cvs2cl.pl. Therefore, you will need to install the Perl script if you are doing a "make dist" from a CVS checkout or if you "make dist" after "make maintainer-clean". ** distcheck A "make dist" will create a tarball of the distribution, test if installation and uninstallation is okay, and run the test scripts. Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-16 03:27:28
|
Hi Since we now have access control with the CVS repository, may I ask you guys to register at sourceforge.net as users, so I could add you guys to the developer list. We will figure out the rest along the way. :-) Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@us...> - 2002-05-15 21:29:28
|
Hi all, After playing with cvs_acls.pl and commitinfo for a while, I finally know how to set up an access control list for the CVS repository. Access can be granted by files/directories or by branches (or both): I could say, I want Pete to be able to work on AegisVM/interpret.c but not other files, or I want Chris to be able to work on a certain development branch (or some combination of such things). So, what do you think is the most convenient way to do this. Should I create a separate branch for each subproject (e.g. a branch for developing java.lang.reflect, and another branch for developing floating point arithmatic)? Or should I just limit your access to the set of files you need to work on? Which is more convenient for you? Or, do you think it is sufficient just to archive the commit logs in a mailing list, and forget about the whole access control idea? I think the criteria should be that the setup should be convenient for you to work, and also give me peace of mind so I can sleep tight at night. :-) Please offer feedback. Philip * Philip W. L. Fong * pw...@us... |
|
From: Philip F. <pw...@cs...> - 2002-05-06 08:26:53
|
Hi This just came out. Our project is listed on the GNU Classpath Project homepage as one of the consumers of their class libraries. http://www.gnu.org/software/classpath Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * pw...@cs... * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 |
|
From: Philip F. <pw...@cs...> - 2002-05-06 08:16:30
|
Hi On Sun, 5 May 2002, Chris Neumann wrote: > I think that this would be an excellent (and easy to implement) > solution to our documentation worries. Provided that the required > commenting conventions are not too crazy (I haven't had a chance to > review them yet), it should have a minimal learning curve, and thus, > significantly decrease the time required to understand the overall > code base. Good point. You have spelled out the most important criteria for picking an appropriate documentation tool. I only spent like half an hour reading doxygen's manual. It looks like it's pretty straightforward. For one thing, it accepts javadoc style documentation, which makes it possible to learn only one set of mark up to work with both C and Java. Secondly, I believe that one doesn't need to know every detail of a technology to be productive. I think, by just looking at how others write their documentation markup, you should have everything you need to start documenting your code. > Personally, I would still like to see some level of separate > documentation maintained in addition to the generated doxygen files. > Mainly, these would be the "big picture" items that give an overall > picture of the entire system (since it can be difficult to see how > everything fits together from dozens of separate interface files). I agree with you. > These might include: > > - A high-level overview of the entire AegisVM system and its major > modules. > - An appendix of naming conventions for functions and constants used > within the implementation (e.g. all values prefixed with "J_OPC" > represent XXX and are defined in file YYY) > - Some sort of basic, high-level architectural document to guide the > progression of the design/implementation (perhaps it's worth seeing > if doxygen can generate dependency diagrams...?) > - Others? This is perfect! Now it becomes very clear that as the first consumers of the documentation you guys know so much more about what is needed that I do. I think it is much better if you guys actually have some kind of access to the CVS repository in order to actually have more influence on this whole thing. However, as a language security researcher I am a very paranoid person. Do you know if there is any configuration thing I could do with the CVS repository to make sure that we can control the demage we would do to each other's work? Pete, how do other projects do this? I looked through the sourceforge admin interface but couldn't find anything useful... Philip |
|
From: Chris N. <cne...@sf...> - 2002-05-05 22:33:49
|
I was just thinking how much I've gotten used to using JavaDoc... =) I think that this would be an excellent (and easy to implement) solution to our documentation worries. Provided that the required commenting conventions are not too crazy (I haven't had a chance to review them yet), it should have a minimal learning curve, and thus, significantly decrease the time required to understand the overall code base. Personally, I would still like to see some level of separate documentation maintained in addition to the generated doxygen files. Mainly, these would be the "big picture" items that give an overall picture of the entire system (since it can be difficult to see how everything fits together from dozens of separate interface files). These might include: - A high-level overview of the entire AegisVM system and its major modules. - An appendix of naming conventions for functions and constants used within the implementation (e.g. all values prefixed with "J_OPC" represent XXX and are defined in file YYY) - Some sort of basic, high-level architectural document to guide the progression of the design/implementation (perhaps it's worth seeing if doxygen can generate dependency diagrams...?) - Others? Ok...there's my two cents. Enjoy the rest of your weekend! - Chris -----Original Message----- From: aeg...@li... [mailto:aeg...@li...]On Behalf Of Philip Fong Sent: Saturday, May 04, 2002 12:40 PM To: aeg...@li...; jt...@sf...; na...@sk... Subject: [Aegisvm-devel] Documentation Hi all, Pete brought up the issue of documentation a while ago, and Chris is bringing it up again. The fact is that the code base is not very well documented, which makes it hard for new contributors to become productive quickly. It has become quite a pressing issue now, and I would like to get some input from you guys. I guess my take is that I do not want to maintain a separate set of documentation on top of the code base. The reasons being the code is a rapidly moving target, and it is difficult to avoid the doc from going out of sync with the code. I think economy and low barrier of entry are both important for a young project like ours. My preference is to have a very simple document discribing in very high level terms the overall structure of the code base, and then leave all the detail documentation in the source file. Have you guys heard of this very wonderful project called doxygen (http://www.stack.nl/~dimitri/doxygen/)? It translates embedded javadoc style documentation in C/C++ source file into hyperlinked HTML docs. If we use it then we could maintain only the source files, but we still have external documentations that are much easier to navigate. What do you guys think? Would such set up solve the problem? Is doxygen the kind of tool that you would be happy to work with? Is it still an overkill, and you would prefer something even more lightweight? Let me know. Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * pw...@cs... * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: ban...@so... _______________________________________________ Aegisvm-devel mailing list Aeg...@li... https://lists.sourceforge.net/lists/listinfo/aegisvm-devel |
|
From: Philip F. <pw...@cs...> - 2002-05-04 19:39:50
|
Hi all, Pete brought up the issue of documentation a while ago, and Chris is bringing it up again. The fact is that the code base is not very well documented, which makes it hard for new contributors to become productive quickly. It has become quite a pressing issue now, and I would like to get some input from you guys. I guess my take is that I do not want to maintain a separate set of documentation on top of the code base. The reasons being the code is a rapidly moving target, and it is difficult to avoid the doc from going out of sync with the code. I think economy and low barrier of entry are both important for a young project like ours. My preference is to have a very simple document discribing in very high level terms the overall structure of the code base, and then leave all the detail documentation in the source file. Have you guys heard of this very wonderful project called doxygen (http://www.stack.nl/~dimitri/doxygen/)? It translates embedded javadoc style documentation in C/C++ source file into hyperlinked HTML docs. If we use it then we could maintain only the source files, but we still have external documentations that are much easier to navigate. What do you guys think? Would such set up solve the problem? Is doxygen the kind of tool that you would be happy to work with? Is it still an overkill, and you would prefer something even more lightweight? Let me know. Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * pw...@cs... * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 |
|
From: Philip F. <pw...@cs...> - 2002-04-27 00:33:48
|
Hi all, I have updated the HACKING file to include instructions for accessing the CVS repository, and an overview of the code base. In case you find the overview too brief, and would like me to add more information into it, please email me. Again, the latest version of the HACKING file can be found here: http://aegisvm.sourceforge.net/HACKING Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * pw...@cs... * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 |
|
From: Philip F. <pw...@cs...> - 2002-04-26 23:38:35
|
Hi all, I have finally finished with all the restructuring I would like to do before 0.1.0. (The truth is that I am finally bored of restructuring without putting in new feature...). I have tagged the restructured JPR and AegisVM modules by the following tags respectively: release-libjpr-0_1_0_pre1 release-aegisvm-0_1_0_pre1 I would encourage you to synchronize with this version if you are already working on something, or just start with this one if you are planning to begin some work. I'll post some instruction about how to access the project CVS repository in the HACKING link on the project home page soon. Also, Chris suggested me to write up a brief overview of the code base, which I think is a very good idea. I'll include that in the revised HACKING file also. Hope these help. Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * pw...@cs... * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 |
|
From: Philip F. <pw...@cs...> - 2002-04-24 01:48:31
|
Hi
Someone asked a while ago about what the longer-term goal for the
Aegis VM project is. Therefore I think it might be good to outline
how I would envision the future course of the project. Of course,
your input is always welcome.
Once upon a time, there were a number of very well crafted Java virtual
machines, Kaffe VM, Sable VM, IBM VM, etc. Some of them had nice
performance, the others were research platforms for performance research.
To them, performance is the big thing.
But then performance is not the only thing in the world. All these
VM shares a fundamental architectural constraint: the primary
protection mechanism, that bytecode verifier, is hard coded into
the VM. Users are forced to live with one, non-optimal, protection
mechanism. There are all these nice research on programming
language security, but none of them can be implemented on a Java
platform because of this fundamental architectural constraint.
It is this niche the Aegis VM tries to fill. As an enabling
technology, the Proof Linking architecture of the Aegis VM will
allow users to custom build a language protection mechanism that
best fits the problem at hand. This will make it possible for
programming language researchers to experiment on a realistic
platform with new protection mechanisms that are based on
static analysis. I would coin the term "pluggable verification
modules" to refer to such custom-built static analyzers that
could easily be integrated into the dynamic linking process of
a JVM. My hope is that, our effort will set a new standard of
how secure mobile code environments are built.
But to make this a reality, the Aegis VM cannot be just a toy
project. It has to be a realistic mobile code execution platform.
This means our goal is not just to create an idealized VM stripped
of all interesting features of a production JVM, but instead we
have to embrace the full complexity of both the Java language
and its execution platform. I believe that realism brings the most
interesting research. And realism comes from making the Aegis
VM a useful and practical Java platform.
And this is where we are standing: our work will contribute to the
realism of the Aegis VM, making it a credible Java platform that
offers the benefit of pluggable verification modules.
But how realistic is realistic? How much work do we need to put in
before the Aegis VM can be considered realistic? Fortunately,
the amount of work turns out to be quite tractable. If you are like
Pete, who has actually done some coding in the VM core, you will
notice that the VM itself is quite tractable. The problem is in
the class library. That is why we will integrate our VM with the
GNU Classpath class library, saving us years of work. In addition,
the license of GNU Classpath is compatible with our licensing
strategy: it allows the use of the library in commercial products,
and it works with LGPL.
Does it mean we are locked into Classpath? No. We will integrate
Classpath in a way different from what the Classpath authors
expected. We will actually provide our own version of classes
that requires internal support from the VM. We call these
built-in classes. In that way, our VM is more or less independent
of the choice of the class library. The number of built-in classes
is very small. Check out the list at the end of the FEATURE file
for the candidates.
So, what will happen in the immediate future? Release 0.1.0 will
inaugurate the 0.1.x development cycle. There are two goals to
this release:
(1) To make Aegis VM more hackable. This involves a lot of
refactoring, restructuring, and internal documentation.
(2) To make Aegis VM more useable. This involves, for example,
a preliminary integration with Classpath, which in turn involves,
for example, implementing the dynamic binding of native
libraries.
There are actually a number of tasks in (2) that I would like you guys
to help me with. The more urgent ones are listed below:
- floating point arithmetics (Pete has almost completed it, so this will
very likely go into 0.1.0)
- support for the jsr/ret instructions
- more support for the JNI interface
If you are interested in any of the above, or if there are some other
tasks in the TODO list you would like work on, let me know.
I am almost done with restructuring (i.e. item (1)). When that is
done, I'll tag the code base, and send you guys the CVS tag.
Hope this very long email gives you an idea of where we are heading.
Philip
* Philip W. L. Fong
* School of Computing Science
* Simon Fraser University, Burnaby, B.C., Canada V5A 1S6
* pw...@cs...
* http://www.cs.sfu.ca/~pwfong/
* (604)719-2333
|
|
From: Philip F. <pw...@cs...> - 2002-04-15 00:06:01
|
Hi The Aegis VM 0.0.3 was finally released last night. This release implements support for string internalization, exception handling, stack tracing, user-defined class loaders, and class unloading. Numerous bugs are fixed, making this release much more robust than its predecessors. Also, the VM is now ported to Solaris (SPARC) platforms. Release 0.0.3 is the last one in the 0.0.x development cycle. Please check out the detail release note at http://aegisvm.sourceforge.net/aegisvm-0.0.3 The release has a CVS tag release-aegisvm-0_0_3. Please synchronize. :-) Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * pw...@cs... * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 |