Posts Tagged ‘CLR’

Ruby on .NET?

December 7, 2005 Leave a comment

I appears that researchers at QUT‘s Programming Languages and Systems group are working on an implementation of Ruby for .NET. The “secret” is reveal on this page. The work is support by Microsoft Research. Davis Thomas also mentions it in an article about the emergence of agile languages. There seem to be no other sources of information at present.

It turns out that John Gough organised a birds of a feather for Implementing Dynamic Languages on the .NET CLR at the Dynamic Languages Symposium back in October (2005).

QUT is my old university and John Gough my was my favorite lecturer. I studied compiler construction under John and later wrote a small compiler under his supervision in C# targetting .NET (and using his book Compiling for the .NET CLR as a resource). It’s a small world. I’m working in the UK at the moment. The guy who sits next to me at work comes from South Africa. He studied under Pat Terry at Rhodes University. Pat is also a compiler guy. John and him were involved on the Modula-2 language commitee. Turn’s out that I used Pat’s Coco/R (C# version) on that project.

WCL and shared libraries

September 27, 2004 Leave a comment

Just read about WCL, a Common Lisp (CL) implementation I wasn’t aware of. The paper talks about how CL is compiled to C and linked into a shared library. This allows a memory efficient delivery environment. i.e. CL application share code via shared libraries including the core system/libraries. I missed whether the CL compiler is available at runtime which would be a drawback. Many problems were solved but still afew remained such as relocated data with embedded pointers in the shared library (causing slower startup times), generational GC is not implemented, the compiler could be more sophisticated and there is no thread support. The project appears to be stalled.

I wonder whether other CL implementations such as GCL and ECL using the CL->C method are able to provide sharing through shared libraries?

Java programs have similar problems that WCL attempts to solve for CL. When the same Java program is loaded by separate JVMs (in different processes), they don’t share any code. i.e. the classes will be jitted multiple times …being stored in memory multiple times. I believe that this problem occurs even within the *same* JVM when the class files are loaded via different class loaders! I’ve yet to confirm that though. This is one of the reasons why Java application take up alot of memory. Seems to be a problem with 1.4.2 anyways. Perhaps 1.5 fixes this problem. Microsoft’s CLR deals with this situation by using the assembly is the unit of deployment and having each assembly contain a version number. I imagine that with the CLR (and other CLI implementations), that each assembly is only compiled once within the same process. This doesn’t however solve the “multiple process runnings CLRs” problem though I believe there is an ahead-of-time option which stores compiled assemblies in an on-disk cache – this would would likely solve the problem (as long as the compiled assemblies are loaded into shared memory like a shared library).

Categories: Programming Tags: , , , , ,