RFR: 8031639: make dependency management (mostly) ci independent
Roland Westrelin
roland.westrelin at oracle.com
Tue Jan 21 08:19:59 PST 2014
> You’re saying ciMethod, ciKlass, ciMethodData etc are no longer needed? I can’t imagine that’s true as they seemed to be used extensively.
C1 & C2 run concurrently with GCs as much as possible. This is achieved through the CI machinery. The CI objects mirror actual objects of the JVM and they cache information useful to the compilers. So most of the time, the compilers only work with the CI objects. If the compilers need something that is not cached in a CI object, they need access to the actual underlying JVM object, and then the compilers must “enter the VM” and become subject to the GC. Before permgen removal, Klasses and Methods and MethodDatas could move as well. That’s why the ciMethod, ciKlass etc exist. Now that the permgen is gone, Klasses and Methods can’t move anymore and ciMethod, ciKlass etc. lost a big part of their reason for existence. That’s also why it’s ok to call get_Method() or get_Klass() on a ciMethod or ciKlass in your patch without “entering the VM”. But it’s not the pattern that the rest of the code follows.
So yes, ciMethod and friends are used all over the place. But whether it is only for historical reasons (it was easier during the switch to no perm gen to keep them around) or because we think they have actual value is unclear to me.
FWIW I played with an alternate way of doing this: wrap the CI objects in a DepValue earlier and make the core of the Dependencies code work only with DepValue objects:
http://cr.openjdk.java.net/~roland/dependencies/webrev/
Similarly:
void assert_evol_method(Method* m);
void assert_leaf_type(Klass* ctxk);
void assert_abstract_with_unique_concrete_subtype(Klass* ctxk, Klass* conck);
void assert_abstract_with_no_concrete_subtype(Klass* ctxk);
void assert_concrete_with_no_concrete_subtype(Klass* ctxk);
void assert_unique_concrete_method(Klass* ctxk, Method* uniqm);
void assert_abstract_with_exclusive_concrete_subtypes(Klass* ctxk, Klass* k1, Klass* k2);
void assert_exclusive_concrete_methods(Klass* ctxk, Method* m1, Method* m2);
void assert_has_no_finalizable_subclasses(Klass* ctxk);
void assert_call_site_target_value(jobject call_site, jobject method_handle);
Could be implemented so they wrap Method*, Klass* etc in DepValue objects and DepValue::is_instance_klass() etc. could be implemented to work with Metadata* and jobject.
I wonder if templates could be used after refactoring the Dependencies class.
Roland.
More information about the hotspot-compiler-dev
mailing list