[Mono-dev] JaCIL Project

[Almann T. Goo]

On 5/21/06, Andreas Nahr <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.
      - 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.
      - 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.
      - 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).
      - 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.
      - 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.
   - 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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060521/901f039d/attachment.html