Inlining methods with large switch statements

[Vitaly Davidovich]

Hi Roland,

By "handled better" I mean for the JIT to not get scared about the bytecode
size since machine code is rather compact and quick to execute (especially
if the indirect jump via the jump table is predicted well).  This is
somewhat analogous to the JIT being spooked by methods > MaxInlineSize
where the actual bytecode size isn't representative of the real cost (e.g.
dead code, asserts, etc), but for FreqInlineSize.

Thanks

On Fri, Jun 5, 2015 at 11:38 AM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:

> > Is this something that can be handled better?
>
> You could try forcing inlining with -XX:CompileCommand I suppose but then
> it can have cascading effects (other inlining may not happen as a
> consequence). Not sure if that’s what you meant by "handled better".
>
> Roland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150605/b0769406/attachment.html>