Managed Space

Managed Space : Jason Whittington's Radio Weblog

Updated: 3/26/2003; 9:19:25 AM.

Home

Saturday, December 21, 2002

But I want JITGen!

Joe's blog showed up in my referers today, and yielded a link to an interesting paper: vmgen - a Generator of Efficient Virtual Machine Interpreters:

Abstract: In a virtual machine interpreter, the code for each virtual machine instruction has similarities to code for other instructions. We present an interpreter generator that automatically generates code for the virtual machine instructions from simple instruction descriptions; it generates code for the virtual machine interpreter, for generating virtual machine code, for virtual machine code disassembly, for tracing, and for profiling [more]

There's a lot of juicy little tidbits in the paper discussion virtual machine idiosyncracies that directly apply to Java / CLR, and a terrific bibliography. I wonder how long until you can generate your own efficient JIT compiler using a tool like the one they describe (instead of an interpreter).   The obvious thing to do next is to take their work and build a JVM (or something like Mono's mint) and see how well it works. Amusing footnote - the paper references a 1991 paper on "the APL IL Interpreter". Ummm, different IL I think :)

4:25:43 PM      comment []

COM Interop - "It's like, hard and stuff" :)

Since .NET first shipped Sam has been a very visible critic and thinker about .NET / COM Interop. Today he says this:

I have been working and thinking about .NET COM Interop a lot for the past 14 months. I have spent time working with millions of lines of COM code and Interop with the managed world over three companies, as well as helping many people with their Interop problems. This includes at least one company with COM code bases in the millions of lines of code. I had initially come to a set of conclusions last July that COM Interop was Fundamentally Flawed. Since that time, I have done a lot of thinking on this issue and have talked with a lot of people and I have refined my ideas into that it is not fundamentally flawed but much harder than it appears to be, and is perhaps all that could have been done given the conditions. [Sam Gentile's Weblog]

1:16:39 PM      comment []

How to Call a .NET-based Web Service Using the SOAP::Lite Perl Library

Yes, this is a Microsoft MSDN article! "Learn how to call a .NET-based Web service from a UNIX-based system and how to return a Microsoft .NET DataSet to a Perl array using SOAP::Lite. " He starts the article talking about Interop and then returns a Microsoft .NET DataSet.... [Sam Gentile's Weblog]
Interesting. Perl is an example of an client where I would nominally think it inappropriate to return a DataSet object. The way it's used here I'd probably argue that use of a DataSet object on the server is a bit of overkill - just as easy to call selectCMD.ExecuteReader() and use the resulting IDataReader to manually stream XML down to the client. This way you could avoid the cost of creating a DataSet object for each request.   The article mentioned a tool I hadn't seen before - .NET WebService Studio:
The use of SOAP headers in the example above make it impossible to test and debug the Web service using Internet Explorer. There is another utility called .NET WebService Studio, which allows us to test and debug all Web services, even if they use only the SOAP protocol. WebService Studio is used in a way similar to how Internet Explorer is used—just point it at the URL of your Web service and it will read the WSDL of the Web service and generate the proxy class for you. You are presented with an interface similar to the Web page that Visual Studio .NET generates for you, but it is much more flexible. You can create SOAP requests on the fly and browse the XML SOAP request and response in either raw or tree format. You can download .NET WebService Studio for free from GotDotNet. [msdn]

The linked page on gotdotnet has some other nice looking tools as well - a DIME validator and a pair of WSDL tools.

10:49:45 AM      comment []