ACM Home Page
Please provide us with feedback. Feedback
Complete translation of unsafe native code to safe bytecode
Full text PdfPdf (165 KB)
Source Interpreters, Virtual Machines And Emulators archive
Proceedings of the 2004 workshop on Interpreters, virtual machines and emulators table of contents
Washington, D.C.
SESSION: Research papers II table of contents
Pages: 32 - 41  
Year of Publication: 2004
ISBN:1-58113-909-8
Authors
Brian Alliet  Rochester Institute of Technology
Adam Megacz  University of California, Berkeley
Sponsors
ACM: Association for Computing Machinery
SIGPLAN: ACM Special Interest Group on Programming Languages
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 5,   Downloads (12 Months): 40,   Citation Count: 3
Additional Information:

abstract   references   cited by   collaborative colleagues  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1059579.1059589
What is a DOI?

ABSTRACT

Existing techniques for using code written in an unsafe language within a safe virtual machine generally involve transformations from one source code language (such as C, Pascal, or Fortran) to another (such as Java) which is then compiled into virtual machine bytecodes.We present an alternative approach which translate MIPS binaries produced by any compiler into safe virtual machine bytecodes. This approach offers four key advantages over existing techniques: it is language agnostic, it offers bug-for-bug compiler compatibility, requires no post-translation human intervention, and introduces no build process modifications.We also present NestedVM, an implementation of this technique, and discuss its application to six software packages: LINPACK (Fortran), which was used as one of our performance tests, TEX (Pascal), which was used to typeset this document, libjpeg, libmspack, and FreeType (all C source), which are currently in production use as part of the Ibex Project [13], and gcc, which was used to compile all of the aforementioned.Performance measurements indicate a best case performance within 3x of native code and worst case typically within 10x, making it an attractive solution for code which is not performance-critical.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
 
2
 
3
 
4
 
5
 
6
The cygnus native interface for c++/java integration, http://gcc.gnu.org/java/papers/cni/tl.html.
 
7
The java hotspot performance engine architecture, 1999, http://java.sun.com/products/hotspot/whitepaper.html.
8
 
9
C. W. Fraser and D. R. Hanson, A retargetable compiler for ANSI C, Tech. Report CS-TR-303-91, Princeton, N.J., 1991, citeseer.ist.psu.edu/fraser91retargetable.html.
 
10
11
 
12
 
13
Adam Megacz, The ibex reference, http://www.ibex.org/reference.pdf.
 
14
Novosoft, (September 2001), C2J: a C to Java translator.
 
15
William Pugh, The java memory model is fatally flawed, Concurrency: Practice and Experience (2000), 1--11.
 
16
T. Waddington, Java backend for gcc, (November 2000), http://archive.csee.uq.edu.au/\~csmweb/uqbt.htm1\#gccjvm.

Collaborative Colleagues:
Brian Alliet: colleagues
Adam Megacz: colleagues