runtime 6.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169
  1. * The Mono runtime
  2. The Mono runtime implements a JIT engine for the CIL virtual
  3. machine (as well as a byte code interpreter, this is to
  4. quickly port it to new systems), the class loader, the garbage
  5. collector, threading system and metadata access libraries.
  6. We currently have two runtimes:
  7. <ul>
  8. * <b>mono:</b> The Just In Time compiler implemented
  9. using a BURS instruction selector. We only support
  10. x86 machines in the JIT engine at this point.
  11. * <b>mint:</b> The Mono interpreter. This is an
  12. easy-to-port runtime engine.
  13. </ul>
  14. Currently we are using the Bohem conservative garbage
  15. collector.
  16. The Mono runtime can be used as a stand-alone process, or it
  17. can be <a href="embedded-api">embedded into applications</a> (see
  18. the documentation in mono/samples/embed for more details).
  19. Embedding the Mono runtime allows applications to be extended
  20. in C# while reusing all of the existing C and C++ code.
  21. Paolo Molaro did a presentation on the current JIT engine and
  22. the new JIT engine. You can find his <a
  23. href="http://primates.ximian.com/~lupus/slides/jit/">slides
  24. here</a>
  25. ** Current JIT Engine (<b>updated, July 8th, 2002</b>)
  26. The JIT engine uses a code-generator generator approach for
  27. compilation. Given the properties of CIL byte codes, we can
  28. take full advantage of a real instruction selector for our
  29. code generator.
  30. The JIT engine implements a number of optimizations:
  31. <ul>
  32. * Opcode cost estimates (our architecture allows
  33. us to generate different code paths depending
  34. on the target CPU dynamically).
  35. * Inlining.
  36. * Constant folding.
  37. Although compilers typically do
  38. constant folding, the combination of inlining with
  39. constant folding gives some very good results.
  40. * Linear scan register allocation. In the past,
  41. register allocation was our achilles heel, but now
  42. we have left this problem behind.
  43. </ul>
  44. There are a couple of books that deal with this technique: "A
  45. Retargetable C Compiler" and "Advanced Compiler Design and
  46. Implementation" are good references. You can also get a
  47. technical description of <a
  48. href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
  49. A few papers that describe the instruction selector:
  50. <ul>
  51. * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/interface.pdf&pub=wiley">A code generation interface for ANSI C</a>
  52. * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">Engineering efficient code generators using tree matching and dynamic programming.</a>
  53. </ul>
  54. ** New JIT engine.
  55. We are working on a new JIT engine. The new JIT engine
  56. focuses on portability and in two intermediate representations
  57. that simplify the development of optimizations. This together
  58. with the Ahead-of-Time compilation will allow developers to
  59. deploy applications that match the speed of natively compiled code.
  60. ** Garbage Collection
  61. Currently we are using the Boehm conservative GC. Although our plans
  62. are to move to the Intel ORP GC engine, our plans on a next generation
  63. dual-JIT engine have to be taken into account.
  64. We will be using the Intel ORP GC engine as it provides a precise
  65. garbage collector engine, similar to what is available on the
  66. .NET environment.
  67. Although using a conservative garbage collector like Bohem's
  68. would work, all the type information is available at runtime,
  69. so we can actually implement a better collector than a
  70. conservative collector.
  71. <ul>
  72. * Garbage collection list and FAQ:<br>
  73. <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
  74. * "GC points in a Threaded Environment":<br>
  75. <a href="http://research.sun.com/techrep/1998/abstract-70.html">
  76. http://research.sun.com/techrep/1998/abstract-70.html</a>
  77. * "A Generational Mostly-concurrent Garbage Collector":
  78. <a href="http://research.sun.com/techrep/2000/abstract-88.html">
  79. http://research.sun.com/techrep/2000/abstract-88.html</a>
  80. * Details on The Microsoft .NET Garbage Collection Implementation:<br>
  81. <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp</a>
  82. <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp</a>
  83. </ul>
  84. ** IO and threading
  85. The ECMA runtime and the .NET runtime assume an IO model and a
  86. threading model that is very similar to the Win32 API.
  87. Dick Porter has been working on the Mono abstraction layer
  88. that allows our runtime to execute code that depend on this
  89. behaviour.
  90. ** Useful links
  91. Paolo Molaro found a few interesting links:
  92. <ul>
  93. * On compilation of stack-based languages:<br>
  94. <a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
  95. http://www.complang.tuwien.ac.at/projects/rafts.html</a>
  96. * A paper on fast JIT compilation of a stack-based language:<br>
  97. <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
  98. http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
  99. * Vmgen generates much of the code for efficient virtual machine (VM)
  100. interpreters from simple descriptions of the VM instructions:<br>
  101. <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
  102. http://www.complang.tuwien.ac.at/anton/vmgen</a>
  103. </ul>
  104. ** PInvoke
  105. PInvoke is the mechanism we are using to wrap Unix API calls
  106. as well as talking to system libraries.
  107. Initially we used libffi, but it was fairly slow, so we have
  108. reused parts of the JIT work to create efficient PInvoke trampolines.
  109. ** Remoting
  110. Mono has support for remoting and proxy objects, just like
  111. .NET does. The runtime provides these facilities.
  112. ** Porting
  113. If you are interested in porting the Mono runtime to other
  114. platforms, you might find the pre-compiled <a
  115. href="archive/mono-tests.tar.gz">Mono regression test
  116. suite</a> useful to debug your implementation.
  117. * COM and XPCOM
  118. We plan on adding support for XPCOM on Unix and COM on Microsoft
  119. Windows later in our development process.