AOT and max. JIT methods

Hi!

I read about the limitation of the maximum number of JITed methods and
wondered if the AOT compiler can help here. If I AOT compile a class, there's
just one Java class for the whole file and not one per method, right? So I
could use the AOT compiler to make sure that performance critical methods are
always compiled and let JIT handle the rest.. would that work?
(Unfortunately, I don't really have a suitable project at hand to test this,
I'm just curious :) )

Thanks

Mirko

[Charles Oliver Nutter-2]

Mirko Stocker wrote:
> Hi!
>
> I read about the limitation of the maximum number of JITed methods and
> wondered if the AOT compiler can help here. If I AOT compile a class, there's
> just one Java class for the whole file and not one per method, right? So I
> could use the AOT compiler to make sure that performance critical methods are
> always compiled and let JIT handle the rest.. would that work?
> (Unfortunately, I don't really have a suitable project at hand to test this,
> I'm just curious :) )

So many options, so little documentation!

Yes, if you AOT compile, you avoid the JIT cost of one Java class being
generated per method. However the methods generated into that class
still need to be bound into DynamicMethod objects somehow, so we
generate a class-per-method for the handles. In general, this should be
cheaper.

You can also AOT compile and turn on reflection, which will mean no
generation of handles at runtime other than additional methods that
might JIT.

I'd like to also expose the ability to dump out handles, so you can
generate them once and never have to generate them again (and you can
share them across multiple instances of an app). But it's not quite
there yet.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Morten-11]

Charles Oliver Nutter <charles.nutter@...> skrev:

So many options, so little documentation!

Yes, if you AOT compile, you avoid the JIT cost of one Java class being
generated per method. However the methods generated into that class
still need to be bound into DynamicMethod objects somehow, so we
generate a class-per-method for the handles. In general, this should be
cheaper.

You can also AOT compile and turn on reflection, which will mean no
generation of handles at runtime other than additional methods that
might JIT.

Interesting topic! What is your recommendation regarding possible AOT compile for a rails project deployet as a war on a java app server using JRuby? I.e. Would that be beneficial for performance/gc etc ?

/Morten

---

Få en billig laptop. Se Kelkoos gode tilbud her!

[Charles Oliver Nutter-2]

M C wrote:

>
>
> */Charles Oliver Nutter <charles.nutter@...>/* skrev:
>
>     So many options, so little documentation!
>
>     Yes, if you AOT compile, you avoid the JIT cost of one Java class being
>     generated per method. However the methods generated into that class
>     still need to be bound into DynamicMethod objects somehow, so we
>     generate a class-per-method for the handles. In general, this should be
>     cheaper.
>
>     You can also AOT compile and turn on reflection, which will mean no
>     generation of handles at runtime other than additional methods that
>     might JIT.
>
>
> Interesting topic! What is your recommendation regarding possible AOT
> compile for a rails project deployet as a war on a java app server using
> JRuby? I.e. Would that be beneficial for performance/gc etc ?

Well at the moment I'm not sure a full AOT of a rails app is possible
Rails uses a lot of filesystem tricks to load its libraries, which means
that turning them into classes would probably interfere with loading.

In general AOT is going to be great for large single applications, where
you can have the whole app load up and execute. I'm also looking for
folks to play with it, try it out, and see what more needs to be done to
improve it. It's also certainly possible we could have it generate all
method handles up front to avoid generating them at runtime.

There's lots of room for ideas :)

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email