Java JITC将尝试内联出现的任何函数(基于运行时统计信息),这些函数经常被调用以使其值得使用。调用该函数是在一个位置还是在几十个位置上都没关系-
每个调用站点都单独进行分析。
请注意,该决定基于几个因素。该方法有多大?-如果有很多潜在的内联候选人,则仅内联最有利可图的候选人,以避免“代码膨胀”。但是呼叫的频率(乘以感知的呼叫费用)是最大的“得分”因素。
阻止内联的一件事是明显的多态调用。如果调用 可能
是多态的,则在到达的类不是预期的类时,必须由执行原始调用的代码“保护”。如果统计数据证明呼叫经常是多态的(并且不值得包含所有多态变体),则内联可能没有足够的利润。静态或最终方法最吸引人,因为它不需要保护。
奇怪的是,可以阻止内联(以及许多其他东西)的另一件事是,无法从该方法返回。如果您输入了一个方法,然后在内部循环了1000万次而没有返回,则JITC将永远没有机会“交换”出已解释的方法并“交换”出已编译的方法。但是JITC通过使用仅编译一部分方法的技术来在某种程度上克服了这一问题,而其余部分则得到了解释。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)