Differences between revisions 3 and 4
Revision 3 as of 2005-05-27 15:38:37
Size: 1692
Editor: NickLothian
Comment: Link to tech faq
Revision 4 as of 2009-09-20 21:55:29
Size: 1696
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
* Java-in-Java VMs deal with low-level memory management through a small set of type safe extensions, supported by the compiler, which allow typed access to memory in a variety of ways. See [http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html JikesRVM docs] for more information. * Java-in-Java VMs deal with low-level memory management through a small set of type safe extensions, supported by the compiler, which allow typed access to memory in a variety of ways. See [[http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html|JikesRVM docs]] for more information.
Line 15: Line 15:
See also [http://wiki.apache.org/harmony/TechnicalFAQ The TechnicalFAQ] See also [[http://wiki.apache.org/harmony/TechnicalFAQ|The TechnicalFAQ]]

* Java-in-Java VMs deal with low-level memory management through a small set of type safe extensions, supported by the compiler, which allow typed access to memory in a variety of ways. See JikesRVM docs for more information.

* Having written an extensive high performance memory management toolkit, which includes a wide range of GC algorithms, and which can outperform the standard glibc malloc(), I can assure you (as I and others have stated in previous posts), that a Java-in-Java VM is not encumbered by any such limitations.

* The Java-in-Java VM has some performance *advantages* through the lack of impedence mismatch between the supported language and the implementation language (this is one of the reasons for 2. above).

* There are a number of successful instances of this technology, including OVM, Jikes RVM, and Bartok (a C# in C# VM at MSR which can match the MS product VM on some benchmarks, despite having vastly less resoures applied to it).

* Having harmony Java code maximized will will also optimize the maintenability of the code. Mixed code (Java + native) is complex to debug and required multiple expert skills that are quite rare.

* Having Java-in-Java will also be profitable for the project management opportunities, as "Java interrested" developpers are also Java developpers or Java experts. But the change that they are good potential C or C++ resources are much less.

* Having Java-in-Java will help port of the VM on any new platform (from embeded to mainframe and portable devices)

See also The TechnicalFAQ

JvmInJava (last edited 2009-09-20 21:55:29 by localhost)