RFR: 8031639: make dependency management (mostly) ci independent

[Doug Simon]

On Jan 21, 2014, at 5:19 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

>> 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.

I’ll leave that discussion/decision to the more experienced. However, getting rid of an abstraction that only serves a historic purpose sounds like an excellent idea!

> 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/

 102   uint ident() const {
 103     switch(type()) {
 104     case dep_ci_object:
 105       return ci_obj()->ident();
 106     case dep_metadata:
 107     case dep_jobject:
 108     default:
 109       fatal("unexpected type");
 110     }
 111   }

I assume that lines 106 and 107 above are incomplete. How would you compute an ident for these values and ensure the indents for each of the 3 DepValue types don’t clash with each other? Or are you relying on a Dependencies client to either be using dep_ci_object (e.g., c1 and c2) or dep_metadata and dep_jobject (e.g., Graal) and the client ensures that ident values are unique for all DepValues added to a Dependencies object?

> 
> 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.

Maybe you could hum a few bars on the advantages of this approach? Is it mainly about avoiding all VM_ENTRY concerns?

-Doug