Re: Ahead of time compiler solutions

[Philippe Laporte <plaporte at wgate dot com>]

Per Bothner wrote:

> A fair amount of work, but probably quite feasible.  But note that GCJ
> would be used to compile the *non-native* Java methods.  Therefore you
> also need a tool to create a Java class where *all* the non-constructor
> methods are native, so the JVM will know to look for the methods using
> JNI.  Another GCJ modification shoudl do it
I have a good compiler (both front and back-end) and Java VM background, 
and am bright enough. How many 40-hours one man weeks do you think?

> > My performance measure is space, not speed...:-)
>
> And the space usage will suck really bad too.  mage replacing a
> getfield JVM instruction (3 bytes plus whatever space is used in
> the constant pool) with a function call, were you also need to
> look up the field by name, so the field and class names also have
> to be in the executable.
>
> It still makes no sense. 

What if I have 20 JVMs running on the system? Do you have a quantitative 
idea, in the following line:

-If I have one JVM, the dynamically loaded byte-coded core classes take 
up X Megs

-If I have one JVM, the statically loaded native-coded core classes take 
up Y * X Megs (The important question obviously is, what is Y)

-If I have 20 JVMs, the dynamically loaded byte-coded core classes take 
up 20 * X Megs

-If I have 20 JVMs, the statically loaded native-coded core classes take 
up Y * X Megs, instead of 20 * Y * X Megs

Given this argument, are you really saying that Y is that big? That's 
hard to imagine, even given the fact that when classes are loaded 
dynamically, they usually don't ALL get loaded...

Say Hi to Ian if he's still at Brainfood for me please,

Best Regards,
--

Philippe Laporte

Software Engineer

WorldGate 
3190 Tremont Avenue
Trevose PA 19053
Tel: 215-354-5389
Email: plaporte@wgate.com