Rotor Projects

The Kahu team has three projects for Rotor: Gyro X; “JIT Objects”; and an investigation of dynamic typing on the CLR.

Rotor on Panther

Note: If you get Gyro X you don’t need this patch as it is included.

Panther is here, and it is claimed to be faster. Oliver working on Gyro X reported build times of over 2 hours on an eMac, a slow turnaround. So I borrowed an eMac, loaded up Panther, and built Rotor... A few days later after spending the odd hour at it and fixing some of the issues I mentioned it in passing to Peter Drayton, “Have you seen Eric’s Weblog?” Nope I hadn’t and Eric had finished the job, so that would save some work.

Eric noted a problem or two, first one was one of the samples fell over. Time to dig. It turns out that realpath(3) works differently on Panther (Darwin 3.3) than it does on Jaguar. Rotor relies on this returning a case-correct verison of a path, but this feature doesn’t seem to be in the realpath(3) spec. Once found fixing wasn't a big problem and now Panther compiles all the way through. As realpath(3) is used by a number of the file routines in the PAL this change may affect other parts of Rotor yet to be discovered.

I’ve combined Eric’s patch file with mine to produce a single rotor_mark2_diffs.txt.gz. To install gunzip them then in your SSCLI root directory enter:

Checked on Panther (one eMac) and Jaguar (one PowerMac G4). I haven’t looked into the network tests problem’s Eric found.

And how fast? Well the build time is down to a smidgen over 1 hour, so either Oliver’s clock is fast or (at least on this) Panther rocks!

Gyro X

This is a port of Gyro to Rotor on MacOS X.

JIT Objects

This project is winding down, and getting ready to start up as JIT Objects II...

Introduction

The Mondrian [1] language supports JIT Evaluation, usually termed non-strict evaluation in the functional community, where values are not computed until needed. The aim of this project it to investigate a new concept we term JIT Objects, where the contents of an object is not computed until needed. A JIT Object is the object-oriented equivalent of JIT Evaluation. When, and only when, the first method/property of a JIT Object is invoked is the contents of the object computed.

Status

• Done: Add JIT Objects to the CLR/Rotor. A prototype assembly has been developed which given a “construction delegate” returns a JIT Object. This mechanism is sufficient for a compiler to generate code which uses JIT objects. Can also be used directly, and the new anonymous delegates coming in Whidbey C# help.
   
• Partial: Investigate the application of JIT Objects by constructing a suite of example programs. Yes, we have some sample programs, but need more..,
   
• Done: Determine the feasibility of directly incorporating JIT Objects into the Rotor CLR based on the experience gained from C#. There are a number of options to embed JIT Objects into Rotor, with various tradeoffs.

Future Work 

• Modify the Rotor CLR to support JIT Objects.
   
• Develop a functional language compiler which uses JIT Objects to support non-strict evaluation. This might be Mondrian (2?) or some other language.

Dynamic Typing Investigation

(From the original research proposal.)

Introduction

Languages with parametric polymorphic type systems, such as Mondrian [1], can be executed on conventional un-typed architectures without runtime type checks. However on .NET dynamic type checks must be performed, impacting performance, even though the programs are type correct. Research at MSR Cambridge has produced a design for .NET generics [3] which promises to address the performance of parametric polymorphism. Dynamically typed languages require runtime checks on conventional architectures, though techniques such as soft typing [4] have been developed to reduce these, and hence improve performance. The reflection libraries enable dynamic typing on .NET, however the overhead of these is of concern. Indeed it is reported that the performance of Visual Basic .NET is rather poor when performing dynamic binding of method calls [2].

Project

Using the Mondrian language, which is already running under Rotor, as a platform, this project will:

• Develop Dynamic Mondrian, a version of the language which supports dynamic typing, for example by allowing late binding of method calls. The first version will use Rotor’s reflection mechanisms to support dynamic typing.
   
• Develop/apply techniques such as soft typing to Dynamic Mondrian to reduce the number of required runtime type checks. This is expected to produce situations which, though determined to be type correct, will still require runtime checks on Rotor.
   
• Analyze the cases where runtime checks should not be required but are made by Rotor, and investigate the feasibility of modifying Rotor to remove the need for these.

Relationship to Existing Work

This work investigates improving Rotor’s support for dynamic languages along the lines the MSR Cambridge work [3] has done for parametric polymorphic languages. Various dynamically typed, including Scheme and Smalltalk, have been, or are being, implemented under .NET. The approaches adopted by these implementations will be examined as part of this work.

References

[1] E. Meijer, N. Perry, and A. v. IJzendoorn, “Scripting .NET using Mondrian,Æ Proceedings of European Conference on Object Oriented Programming, 2001. Also see the Mondrian web site.

[2] Programming tip given out at Microsoft PDC 2001.

[3] D. Syme and A. Kennedy, “Design and Implementation of Generics for the .NET Common Language Runtime,” PLDI 2001, Snowbird, Utah, 2001.

[4] R Cartwright and M Fagan, “Soft Typing,” Proceedings of the ACM SIGPLAN’91 Conference on Programming Language Design and Implementation.