The contents of this file are public domain. Linux Day 2005: Mono Project Massimiliano Mantione massi@ximian.com Presentation authors: Miguel de Icaza, Massimiliano Mantione, Paolo Molaro Agenda The Mono project .NET vs. Java as a platform C# vs. Java as a language The Mono JIT Whatever: demo, Q&A... Project Mono The .NET Framework as Free Software Highly portable Operating systems Unix family: Linux, MacOS X, Solaris, BSDs... Windows family: NT, 2000, XP Embedded systems (tiny profile) CPU architectures x86, PowerPC, Amd64, Sparc, s390, IA64, arm 64 bits supported where possible Actively developed More than 300 contributors More than 20 full time developers (5 before Novell acquired Ximian) July 19 2000, Ottawa Linux Symposium: Unix Sucks! .NET: a Virtual Platform for Software Components Motivations Increase developer productivity Modern platform to Unix Managed environment Mainstream language with the features most free software languages had for ages Evolving platform Unify API reuse Reduce API-based language fragmentation Multiple language support Side effect: Windows to Linux migration Mono C# Compiler. C# written in C# Fast: 2.5 seconds to rebuild itself. 54,000 lines of code. Includes JIT time. Implements C# 1.2 2.0: generics and iterators. Self-hosting since Jan 2002. Six months since start. Two developers. The Mono Approach: the Two Stacks Software Reuse Existing .NET: Third party components written in C#, VB. Third party compilers: Eiffel, Ada, Fortran, C/C++, Python Existing Libraries: GUIs, Gnome, Gecko, Databases, OpenGL, Cairo... Java: The IKVM Virtual Machine Seemless integration of Java libraries and applications Execute C# and Java code side-by-side Share components, expose components The Ultimate Open Source Reuse Mono Users Today Novell's desktop development platform For new software For extending existing software Beagle, Dashboard, F-Spot, Evolution 2.next Gtk# community ASP.NET applications on Unix Voelcker: 400 servers, 150,000 users Apple/Cocoa#: recent community Embedded systems Mono Today Mono 1.0 released June 30, 2004 .NET framework 1.1-based Minus Windows.Forms, EnterpriseServices Gtk# and other Unix integration assemblies Extensive third-party database support Relax NG extensions Mono.* namespaces GUI Tools: Monodoc and Monodevelop Mono 1.1 is actually the recommended platform now... Where are we going? Continue improving Unix, Gnome, Cocoa iFolder Beagle/Novell Dashboard Continue .NET/Java compatibility work: To allow reuse of third party .NET libraries To allow reuse of Java third party libraries Support scripting and new languages: IronPython, Boo, Nemerle Improve our development tools: MonoDevelop Mono Debugger Mono Documentation Stetic Mono Development Development tracks: Mono 1.0: Stable Mono 1.1: Incremental development Mono 1.2: Windows.Forms, C# 2.0 Mono 2.0: .NET 2.0 APIs and bigger runtime changes Future of Mono: Short Term Mono 1.2: incremental update Add Windows.Forms Add Visual Basic compiler ASP.NET, ADO.NET scalability C# 2.0 compiler Mono features: Debugger Faster (20-50% faster than 1.0 already in many tasks) Stability Scalability Memory footprint Future of Mono: Long Term Mono 2.0: Support the .NET 2.0 profile ASP.NET 2.0 ADO.NET 2.0 System.Xml 2.0 Windows.Forms 2.0 Code Access Security Generational precise garbage collector More ports (S/390x, PPC64, MIPS...) More optimizations in the JIT New register allocator New intermediate representation .NET vs. Java Platform Similar platforms Virtual execution environment Use of intermediate code (both machine and language independent) Garbage collection, no pointer arithmetic, finalization hooks Virtualized (and controlled) access to system resources Strong emphasis on security Similar features Object oriented type system: single implementation inheritance multiple inheritance for interfaces Powerful reflection capabilities Thread and locking support Support for exception handling and finally clauses Attributes (declarative programming) Key Platform Differences Assembly vs. class loader CIL vs. bytecode Designed to support multiple languages The handling of primitive types: the concept of "ValueType" "ref" parameters are fully supported Arrays are not necessarily jagged Easy integration with native code and OS resources Pointer arithmetic Remoting vs. RMI The approach to generic types C# vs. Java Language Similar structural concepts No header files, everything belongs to classes All code scoped to packages or assemblies No circular dependencies issues with class declarations But in C# you can have: multiple public classes per file one class definition spanning more files Similar semantics for types All classes descend from object All instances must be allocated with the new keyword Multiple-inheritance of interfaces Single inheritance of implementations Inner classes (in c# only "static") No concept of inheritance with a specified access level No global functions or constants All values are initialized before use But remember the differences between the platforms! Similar language cleanness Arrays and strings with: built-in length property mandatory bounds checking strings are immutable The '.' operator is always used, no '->' or '::' operators null and boolean/bool are keywords Can't use integers to govern if statements Try Blocks can have a finally clause Enums are supported Thread support by putting a lock on objects when entering code marked as locked/synchronized C# specific features Properties (manage getters and setters) Indexers (like overloading the '[]' operator) Delegates (type-safe object-oriented function pointers) Events (manage a list of delegates to invoke) Operator overloading The approach to generic types Unsafe code Brighter future? (lambda expressions, LINQ...) Java specific features Checked Exceptions Strict floating point semantics (strictfp) Interfaces that contain fields Anonymous inner classes Somebody thinks these are Java advantages... Cross Platform Portability Extensions Dynamic Class Loading Technical Aspects of the JIT and VM Mini JIT Two intermediate representations IL -> Tree based Most optimizaions done on the trees BURS rules transforms trees into list of quadruples quadruples of opcode, dreg, sreg1, sreg2 Close to the CPU, but still allow for easy porting and code sharing between multiple targets Optimizations Can be individually enabled The quick ones are enabled by default SSA framework enabled manually (in the future during recompilation with profiling info): SCCP, ABC removal, SSAPRE, DEADCE Embeddable VM The complete VM is on a library. Extend existing applications. Add scripting. Gradual transition to managed code. Do not lose investment in current code base. Create snippets of code that get jitted. Export new facilities to the CLR. Plugin interface for multiple languages. Easy to use and low overhead. Ongoing work Optimizations SSA-Partial Redundancy Elimination. HSSA, alias analysis, use SSA also with try/catch/finally New register allocator + scheduler (PPC, SPARC) Moving more VM code into managed land Avoid managed<->unmanaged transitions Per-architecture rule tuning AOT with ELF-like relocations (increase page sharing) Precise Garbage Collector Today we use Boehm (using as precise as possible). Currently incrementally fixing to introduce a moving GC Future of Mono as a VM More 'scripting' language runtimes and compilers Perl, ruby, Tcl ported to run on Mono and other VMs Will have more than one implementation, driving stabilization of interfaces and standardization It will push for enhancements of Mono (not just speed, but new features at the runtime and IL level) Dynamic optimizations (self-modifying IL code) Creation of a common interface for use when the concepts of types and methods in a language aren't (can't be) mapped to types and methods in the VM Future of Mono as a VM Smaller footprint for embedded systems. Tradeoff memory for speed Remove some features (Decimal, Re.Emit, locales, verification, Remoting support,...) Realtime extensions Desktop systems Reduce GC pause times Reduce startup time (fast JIT, AOT) Reduce memory footprint Scalability enhancements for SMP, server loads Threaded GC Better performance with shared code Future of Mono as a VM Security and sandboxing Statistic-based low-overhead resource accounting Support from cpu designers and operating systems Thread local access (ABI issue): pthread, __thread Needs to be fast for appdomains, code sharing VM dirty bits for use in GC Virtualized performance counters IP-relative addressing (on 64 bit platforms tradeoffs between icache footprint, memory reads) Don't pessimize writes to code (callsite patching) Standards for controlling a thread (suspend/resume, move to safe points...) More Information Mono: http://www.mono-project.com Email: massi@ximian.com Mailing list: http://lists.ximian.com/mailman/listinfo/mono-devel-list