RFR(L): 8024070: C2 needs some form of type speculation
vladimir.kozlov at oracle.com
Wed Sep 4 16:50:43 PDT 2013
;) We just talked about this with John on lunch. It may help Rickard too.
Did you consider using second type table PhaseTransform::_speculative_types instead of using CastPP and modified
TypeOopPtr (_speculative)? I may be can accept CastPP (it can cause problems not only to stringOpts) but I don't like
the idea that one type can represent 2 types.
Code which use speculative type looks fine.
On 9/4/13 1:59 PM, Roland Westrelin wrote:
> Either we find a use for type profiling data at the profile point that produces them (guarded inlining based on invokevirtual type profile for instance) or we drop it. In particular if static optimizations are good enough then we make no use of the profiling data (invokevirtual can be resolved statically so we type profile data is ignored for instance). This change extends the type system for oops with a const TypeOopPtr* _speculative that is used to record unused profiling data and propagate them. At points where we lack useful profiling data (no profiling, polluted profiling), we can then query the type system for speculative information and use it if it helps. This change includes the machinery to record, propagate and query the speculative type information. It also attempts to use it where it makes sense. Performance (reference_server or nashorn) is not affected (no benefit or regression). This is in preparation for more profiling points to feed more speculative type i!
to the type system.
More information about the hotspot-compiler-dev