I wasn't happy with the handling of map.xml, so I rewrote the code that deals with it to use XmlSerialization. Cool stuff, but it turns out to be totally unsuitable for this purpose. I only need to parse the xml file once (at startup of the VM), and the XmlSerializer generates a C# file (and compiles it) to do the parsing. This is great if you have to parse lots of files (that adhere to the same schema), but it is very wasteful (i.e. slow) if you only need to parse a single file.
After a lot of thinking, I came to the conclusion that I should statically generate an assembly from the map.xml file. In other words, compile it.
Other thoughts: I'm still trying to find ways to make implementing the classpath "native" methods easier (and more efficient, by getting rid of reflection) and I'm contemplating the following idea: Turning classpath.dll, ik.vm.net.dll & the new compiled map.xml into a multi module assembly. This solves two problems: 1) The native methods implementations no longer have to be public, 2) native methods can be statically compiled against the non-native (i.e. compiled Java) code. Downside: more icky circular dependencies and it won't be possible anymore to run without a precompiled classpath.dll
9:49:12 AM  Comments
|
