[Mono-dev] JaCIL Project
Eyal Alaluf
eyala at mainsoft.com
Mon May 22 03:26:05 EDT 2006
Hi, all.
Just regarding feasibility and practicality - there is already a product implementing
this idea.
Not coincidently, the product is implemented by my company (Mainsoft) and is called
Grasshopper. You can access our DevZone at <http://dev.mainsoft.com>
As the guy who already implemented the conversion from .Net byte code to JBC, I
can tell you that all the managed opcodes of .Net are implemented in our converter.
The product implements .Net 1.1 and We are currently working on .Net 2.0 (i.e. Generics).
As for performance, it's not a slam dunk but we managed to get comparable performance
with .Net on large customer projects (ISV ASP.Net projects of > 100K lines).
Eyal.
On Sun, 21 May 2006, Zac Bowling wrote:
> Date: Sun, 21 May 2006 20:03:03 -0500
> From: Zac Bowling <zac at zacbowling.com>
> To: Almann T. Goo <almann.goo at gmail.com>
> Cc: Andreas Nahr <ClassDevelopment at a-softtech.com>,
> Mono Developers <mono-devel-list at lists.ximian.com>
> Subject: Re: [Mono-dev] JaCIL Project
>
> This might be off the radar but what about translating internal members and
> attribute data?
>
> ----
> Zac Bowling <zac at zacbowling.com>
> http://www.zacbowling.com/
>
> Almann T. Goo wrote:
>> On 5/21/06, *Andreas Nahr* <ClassDevelopment at a-softtech.com
>> <mailto:ClassDevelopment at a-softtech.com>> wrote:
>>
>> The hard part is likely that CIL has lots of construcs that Java
>> bytecode does not have. Just to name a few common/important ones:
>> Generics, Pointers and Pointer arithmetic, unchecked exceptions,
>> events, delegates, ...
>>
>>
>> Just a note, from the JVM point of view, all exceptions are unchecked.
>> The JVM "has" checked exceptions in the same way that it "has" generics;
>> they are represented as meta-data in the class file but actually are not
>> used by the JVM itself. It is only the compiler that deals with this.
>> And a lot of exceptions in the Java are unchecked, the whole "Error" and
>> "RuntimeException" hierarchy for instance.
>>
>> How are you planning to solve that problem?
>>
>>
>> The simple answer is that I'm not--at least not right now. I am trying to
>> keep the scope maintainable and as such have explicitly laid out what
>> minimal set of CLI features that I am supporting in my project proposal.
>> Now, despite bowing out of implementing such features right now, I have
>> given such things considerable thought and I have no doubt that most of
>> them can be implemented--it is the cost of implementation that is probably
>> the big question.
>>
>> Let me address you question a little more specifically, it is a good one.
>>
>> * Generics will be tough, I hate to cop out and type erase like
>> Java does, but that could be one implementation option.
>> * Regarding un-managed pointers, there are ways you can emulate
>> this, but because of the JVM programming model, it will come at
>> a cost.
>> o Others have dealt with this by doing things like paging
>> with arrays--NestedVM (IVME '04), does this for the memory
>> model of a MIPS R2000 ISA which it emulates.
>> o This is not in my radar yet, because I think it would be a
>> huge win just to support the verifiable subset of CIL.
>> Un-managed pointers are not in this subset.
>> * Regarding managed pointers, I will likely employ a boxing
>> technique to do this. Managed method pointers could be handled
>> by using reflection.
>> o These will of course take a performance hit (especially if
>> reflection is involved), but at least we can have it.
>> * Delegates are classes with methods from the programming model
>> point of view (there are CLI rules with regard to what can be
>> in a delegate's definition, however).
>> o With regard to the run-time provided method
>> implementations in a delegate, one approach could be to
>> actually emit the implementation of the delegate methods.
>> * Events and properties are really just meta-data "sugar", there
>> are no CIL instructions associated with them specifically and
>> they look like methods in the programming model.
>> * Although you didn't list these, here are a couple of other items.
>> o I am actually very concerned with "newslot" methods,
>> non-virtual instance method calls, and explicit interface
>> method definition for near term future work. This will
>> undoubtedly be a pain to implement; there is a lot of
>> opportunity to make really inefficient implementations.
>> o Tail calls will be another really tough thing to implement
>> since the JVM programming model does not have native
>> support for tail recursive calls. This is probably not a
>> highly used CLI feature anyhow (Unless you are a Scheme
>> compiler), so it is not really on my radar at the moment
>> because there are much larger fish to fry before I wrestle
>> with that. A lot of literature on the subject--some kind
>> of trampolining implementation may be a way to support this.
>>
>> Here is a link to my proposal--it more clearly defines the scope for the
>> first phase of this project.
>> http://www.cs.rit.edu/~atg2335/project/proposal.pdf
>> <http://www.cs.rit.edu/%7Eatg2335/project/proposal.pdf>
>>
>> I hate labeling a lot of these items as "future work", but we have to
>> start somewhere manageable. Note that future work is not the same thing
>> as "never planning on implementing", so any insight on these issues are
>> always appreciated.
>>
>> Regards,
>> Almann
>>
>> --
>> Almann T. Goo
>> almann.goo at gmail.com <mailto:almann.goo at gmail.com>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
More information about the Mono-devel-list
mailing list