[Mono-list] IKVM+Rhino=JS for mono?

[Carlos Alberto Cortez]

Hi again,

I think that some of the points you exposed are valid and are very
interesting. However, the Rhino lexer & parser have together only about
300 lines of code, so that is not *that much* code.

However, it looks like the approach you mentioned could be valid for
other projects that could need it and have a bigger complexity.

Regards,
Carlos.

El jue, 17-06-2004 a las 14:56, Stuart Ballard escribi=C3=B3:
> Carlos Alberto Cortez wrote:
> > Hi:
> >=20
> > Currently I'm helping Cesar Lopez Nataren to port the Rhino Lexer and
> > Parser stuff, and then finish the JScript compiler implementation. Mayb=
e
> > it would be a good idea to finish to port to C#, than trying to use the=
m
> > with IKVM, since you would have to run ikvm on top on mono, and then ru=
n
> > rhino on top of ikvm, representing a big overhead.
>=20
> If you use ikvmc, the overhead isn't that huge and could be reduced=20
> further with a small amount of work (which would help other users of=20
> IKVM as well).
>=20
> A small amount of overhead for mapping certain method calls (not all) on=20
> java.lang.Object and java.lang.String is unavoidable, as is a larger=20
> amount of overhead when exceptions are used, but exceptions are slow=20
> anyway and shouldn't be used in performance-critical parts of the code.
>=20
> The rest of the current overhead, as far as I know, is memory overhead=20
> caused by the need to have all of IKVM.GNU.Classpath.dll and all of=20
> IKVM.Runtime.dll loaded even when not all of it is in use. Classpath.dll=20
> could be split up by Java package so that you might only need to load=20
> the java.lang equivalents and maybe java.io. IKVM.Runtime.dll could have=20
> the JIT compiler split out because you don't need it when you're in=20
> static mode, unless you're doing dynamic loading of classes. I believe=20
> that the IKVM author plans on doing these things anyway, eventually,=20
> although they won't make Mono 1.0.
>=20
> It occurs to me that perhaps Rhino *does* do dynamic loading of classes=20
> and so that overhead would be significant. Still, I imagine that adding=20
> a CIL-generator as an alternative to the Java bytecode generator would=20
> be less work than porting the entire code to C# - and you could benefit=20
> from ongoing improvements to Rhino in the future. (Of course, you can=20
> use System.Reflection.Emit directly from Java code to make the CIL=20
> generator simpler to write)
>=20
> Obviously I can't tell you what to do, and like I said, I don't have=20
> time to work on this myself. I can only suggest what I think would save=20
> you some work...
>=20
> Stuart.