--- /dev/null
+From: Etienne Gagnon <gagnon.etienne_m@uqam.ca>
+Subject: IVME 04 Author Notification
+To: Adam Megacz <adam@megacz.com>
+Date: Thu, 22 Apr 2004 13:00:54 -0400
+Organization: UQAM
+Resent-From: nobody@nowhere.com
+
+Dear Adam Megacz,
+
+I am pleased to inform you that your paper (#17):
+
+ "Complete Translation of Unsafe Native Code to Safe Bytecode"
+
+has been selected for publication and presentation at IVME 04. This
+year a total of 15 papers were submitted and of these 6 were selected
+for publication.
+
+Below please find the reviewers' comments. Please incorporate any
+suggestions made by the reviewers and prepare the final version of your
+paper according to the ACM SIG Proceedings Templates at
+ http://www.acm.org/sigs/pubs/proceed/template.html
+Please follow the SIGS style carefully.
+
+Please note that papers should normally be limited to 8 pages, including
+figures, bibliography, possible appendixes, etc. Please ask for permission
+by email (gagnon.etienne_m@uqam.ca) if you need more than one or two
+additional pages.
+
+IMPORTANT TASKS TO DO
+=====================
+
+** The electronic final camera-ready version is due on (strict deadline)
+Monday May 10th, 2004. You must send your paper as attachment to an email
+message to gagnon.etienne_m@uqam , in a compressed .zip or .tar.gz archive
+which should include both of the following:
+- A PostScript or a PDF version of your camera-ready paper.
+- The source version of your document (LaTeX, Microsoft Word), suitable
+ for modification (to add heading/footing information such as line numbers).
+ *** If you used another software, please inform us of this fact by replying
+ to this message as soon as possible.
+
+** You must also print, fill and sign the copyright form attached to this message
+and send it by mail to:
+
+ Prof. Etienne M. Gagnon
+ Departement d'informatique
+ Universite du Quebec a Montreal
+ Case postale 8888, succursale Centre-ville
+ Montreal (Quebec)
+ Canada H3C 3P8
+
+
+Do not hesistate to communicate with me as soon as possible if you have any
+problem with formating your paper according the the ACM SIGS style.
+
+Regards,
+
+Etienne Gagnon
+Program Chair
+IVME 04
+
+-------------------------------
+
+Legend
+
+1 Strong Reject
+2 Weak Reject
+3 Undecided
+4 Weak Accept
+5 Strong Accept
+
+-------------------------------
+
+Appropriateness to the Conference: 4
+Originality: 4
+Technical Strength: 4
+Presentation: 4
+Overall Evaluation: 4
+Comments
+
+An interesting paper demonstrating the translation of MIPS R2000 binaries to safe JVM bytecodes.
+
+The paper has some novelty value, since everybody knows that in theory an arbitrary native code binary could be emulated in this way, but nobody seems to have done a complete job. Thus the paper answers the existence question, and provides some implementation details. Of course a remaining problem is the issue of emulating the runtime/sys-call interface of the native binary.
+
+The discussion of the techniques by which the quality of the bytecode representation of the program may be improved was helpful.
+
+However, a wider range of measurements of performance would have improved the paper. Some discussion of the theoretical limits to performance using such a compilation path would have been of interest also.
+
+There are a number of typos in the paper as presented. A careful proof reading would be in order before final submission.
+
+Finally, there are a host of unanswered questions regarding the practical use of such techniques. Unsafe code is, well, unsafe. Users of managed frameworks expect a certain degree of safety. It seems that there are several levels of insecurity here. Type violations in the native code should be bug for bug equivalent in this framework. Stray pointers presumably lead to array bounds violations in the JVM (?). So what happens with unsafe use of the system call interface? Is this trapped in the NestedVM runtime? Is it trapped inside the Java sandbox, or does it require high privilege setting and wreak its damage anyhow?
+
+-------------------------------
+
+Appropriateness to the Conference: 4
+Originality: 2
+Technical Strength: 4
+Presentation: 4
+Overall Evaluation: 4
+Comments
+
+Interesting paper to read. There are some typos which should be fixed, many of which a spell-checker should catch (my favorite is "highlym odular" on page 2).
+
+I'm not convinced that the MIPS ISA and the JVM have a "close similarity" (Section 4.1), but one could argue that they have "similarities" as they go on to explain.
+
+The citation to the JLS needs fixing, as does capitalization in a number of references.
+
+Some data needs to be shown on the size of translated binaries.
+
+What about code that uses non-libc libraries?
+
+A C to Java translator was done in 1996 which bears a lot of similarity to this work (including the big array to represent memory). See C. W. Fraser and D. R. Hanson's "A Lean Retargetable C Compiler," 1996, at http://www.cs.princetom.edu/software/lcc/doc/lean.pdf. The work by Fraser and Huelsberger is the C to Java translation.
+
+-------------------------------
+
+Appropriateness to the Conference: 5
+Originality: 5
+Technical Strength: 5
+Presentation: 4
+Overall Evaluation: 5
+Comments
+
+I really liked this paper (the best one in my batch). However, I would have preferred to see more technical detail instead of the blurb in Sections 2 and 3, which wastes almost 1 1/2 pages. This space could be spent much better on a deeper technical discussion.
+
+Also, I am a bit sceptical of the results, which look almost too good. I cannot imagine that translating MIPS instructions into Java of the sort shown really only has 10x worst case overhead. I would have expected more like 1000x overhead... A further discussion would be welcome.
+
+But overall, this is very interesting and novel.
+
+-------------------------------
+
+Appropriateness to the Conference: 5
+Originality: 4
+Technical Strength: 4
+Presentation: 4
+Overall Evaluation: 4
+Comments
+
+Nice paper, well-presented, but a little light on details.
+
+You chose MIPS because it was likely to be the easiest. Have you thought
+much about x86, Power, etc.? How much harder would it be to do
+this for other ISAs?
+
+Were there any peculiarities of the JVM that were gratuitously
+difficult to deal with? I would have expected the lack of
+unsigned int types to be a pain.
+
+I'm guessing that NestedVM can't handle multi-threaded apps;
+please mention this. (I note that bug-for-bug compiler
+compatibility is very hard, perhaps impossible to achieve
+for multi-threaded apps, because the memory models of the
+original machine and the JVM are unlikely to be the same).
+
+There is no mention of the work on binary translation to bytecode
+done by Cifuentes et al, (see, e.g., the paper in Computer, Mar 2000,
+or the paper in the Workshop on Binary Translation (1999)).
+
+You should make
+a pass with a spell checker.
+
+
+[2. application/octet-stream; copyright_form.pdf]...
+
--- /dev/null
+GCC
+- Needs fork/exec support ¨C through the compiling, assembling, and linking process multiple different binaries are executed, making this all run inside a single executable would be very difficult. Getting GCC to run was the primary motivation for implementing fork and exec support in NestedVM
+- GCC makes extensive use of the 64bit ¡°long long¡± type. In order to support this type on a machine with 32-bit words a few instructions are used in obscure ways. Building gcc uncovered one new bug in the binary translator\816¦5
+Runtime/Syscall interface
+- The nestedvm runtime provides all the functions a kernel normally provides in a traditional environment plus a few extra functions that can be done more efficiently in java
+- Translated binaries interact with the runtime using the SYSCALL instruction. The binary translator translates this instruction into a call to the syscall() method of the Runtime. When the syscall() method is invoked the runtime carries out whatever actions were requested (usually modifying the process¡¯ memory or other state information in the process) and returns a value to the caller.
+- The NestedVM runtime is broken up into two parts, the standard runtime and the ¡°Unix runtime¡±. The standard runtime only implements a minimal number of syscalls. Just enough to get simple ansi-c applications to run. Using this is sufficient if you have a binary that simply reads and writes from streams or memory.
+- Runtime syscalls
+o Open ¨C The open syscall creates a file descriptor from a local file. After checking with an optional SecurityManager to see if access to the requested file is allowed the local file with the given name is opened and a file descriptor for that files is added to the file descriptor table for the process (simply an FD[] array
+\817¬1 Local files are opened using the RandomAccessFile class to allow reading, writing, and seeking
+o Read/write /seek syscalls ¨C The read, write, and seek syscalls invoke the corresponding methods of the FileDescriptor objects they are called on.
+o Close ¨C Simply closes the file descriptor and frees up the file descriptor table entry it uses
+o Fcntl ¨C The fcntl syscall gets and sets various attributes of the file descriptor is is called on
+o Sbrk ¨C the sbrk syscall extends the heap of the process. This is accomplished by adding more ¡°pages¡± (int[] arrays) to the memory page table
+o Exit ¨C The exit syscall records the exit status passed to it then sets the ¡°state¡± instance variable to exited to indicate to subclasses that they should stop executing code. In most cases this will eventually cause control to return to the run() method in runtime where the exit status recorded earlier is returned
+o Pause ¨C The pause syscall was previously used to implement a crude form of communication between the java caller and the mips binary. The pause syscall temporarily pauses execution of the mips binary and return control to java. At that point the caller in java can modify the state of the process and resume it. Using the call() method and _call_java() interfaces are preferable to this method though.
+o Memset and Memcpy ¨C while these two functions can me implemented purely in user space, they can be done much more efficiently in java. Memcpy, for example, can usually be turned into a single call to System.arraycopy() which on most JVMs is executed in a very fast native loop. These two syscalls exist only for performance reasons
+- UnixRuntime syscalls
+o The unix runtime offers a more complete set of syscalls that are commonly found on unix systems. It also offers a more complex filesystem interface (including support for mount points and the /dev filesystem). The unix runtime also makes the host¡¯s filesystem looks like a unix filesystem (¡°/¡± root directory, forward slash path separator, etc. Fork and exec are also implemented in the unix runtime and it allows for different unixruntime process¡¯s to communicate with eachother
+o Filesystem interface
+\817¬1 UnixRuntime abstracts away all filesystem access to a filesystem class. This allows new filesystem to be added to NestedVM at any file.
+\817¬1 NestedVM included a filesystem class for accessing the Hosts¡¯s filesystem and a special DevFS filesystem implementing some traditional /dev devices.
+\817¬1 New filesystem classes can be added to access any kind of file file store including Zip files, filesystem images, or even http servers.
+o Fork ¨C the fork() creates a new instance of a UnixRuntime and begins executing it in a new thread. To make the actual copy of the currently running UnixRuntime instance java¡¯s clone() function is used. Where appropriate state information is deeply copied. This includes, unfortunately, all writeable memory pages. Copy-on-write cannot be easily implemented in the JVM so this is necessary. After the new cloned process has been created it is added to the process table. This is stored in the ¡°GlobalState¡± object. Multiple global states can exist in a single VM which allows for multiple independent collections of processes. Finally, the setCPUState() method is used on the new process to set the return value (register r2 to 0 and increment the program counter past the syscall instruction). At this point a new java thread is created and the new process is executed in the new thread
+o Waitpid ¨C the waitpid function causes a process to block waiting for a child process to complete. Whenever a child exits it is added to its parents ¡°exitedChildren¡± queue. If this queue is empty the parent blocks waiting for a chick to finish. This is done using java¡¯s wait() method. Completed children add themselves to their parents exitedChildren queue and notify their parent with the notify() method
+o Exec - The exec() function is probably the most complicated one in NestedVM. It compiles mips binaries from the filesystem on the fly and executes them in place of the existing process
+\817¬1 Reading from the filesystem ¨C the mips binary is read from the filesystem using the standard filesystem access methods. This allows binaries to be loaded from any source readable by the nestedvm runtime.
+\817¬1 The binary is then run through the binary to source translator (which is run in the same VM) where it is compiled to bytecode. Finally, the bytecode is loaded into the running VM using a custom classloader and it is instantiated.
+\817¬1 Next the new UnixRuntime instance is populated with the values of various attributes of the caller, including, the file descriptor table, current working directory, pid, ppid, etc.
+\817¬1 A special variable is set in the unix runtime class to indicate that an EXEC has taken place and control a similar process follows as does for EXIT (control is returned to the run() method in the runtime). At this point run() notices an exec() not an exits has taken place and runs the new unixruntime instance. This is used to prevent stack space from being used up for each exec() and to allow the old unused instance to be Gced
+o Pipe ¨C In unix Pipes are commonly used for IPC. The pipe() syscall creates a unidirectional pipe just like in unix. Forked() process can then communicate though this pipe.
+o State/lstat/mkdir/unlink ¨C These functions simple call the appropriate functions in the filesystem class. In the case of the HostFS filesystem the SecurityManager is checked before any actions are carried out on the hohst filesystem
+o Chdir ¨C Since java has no concept of a ¡°current working directory¡± and even if it did it wouldn¡¯t be of much use since multiple binaries can be run in a single VM and the filesystem isn¡¯t necessarily the hosts¡¯s filesystem chdir() has to be fakes. This is accomplished by setting a variable in the unixruntime instance containing this process¡¯ cwd as a string. This variable is consulted whenever a relative path is used by any filesystem accessing function.
+o Getdents ¨C the getdents syscall is used to read directory entries. It works just like the traditional unix getdents syscall. It writes ¡°struct dirent¡± structures to the buffer passed to it.
+o Opensocket ¨C the open socket syscall is use to create a filedescriptor that maps to a tcp socket. A hostname and port is passed to this syscall which simply passes them on to javas Socket() constructor. If the connection is successful the socket¡¯s input and outputstreams are connected to a file descriptor and returned to the caller
+o Listensocket ¨C similar to open socket, creates a ServerSocket
+o Accept ¨C calls the accept() method on the ServerSocket passed to it and creates a new FD for the accepted connection
projects / nestedvm.git / commitdiff