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

[Doug Simon]

I’ve uploaded a new webrev to http://cr.openjdk.java.net/~dnsimon/JDK-8031639-v2/

One thing I’m not sure about is whether I’ve guarded assert_call_site_target_value properly now. Given that Graal calls this method while already in a VM_ENTRY, I don’t think I can blindly add VM_ENTRY_MARK here (or can the VM be entered recursively?). Unfortunately this means the non-Graal callers need to do their own VM_ENTRY_MARK.

On Jan 20, 2014, at 10:57 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

>> Stepping back a moment, what is the requirement for VM_ENTRY here? 
> 
> The compiler threads run concurrently with the GC.
> You get an oop from JNIHandles::resolve(call_site) and then load its klass. The GC may run in between, move objects around and when the klass is read, what you get may be garbage.
> 
>> It does’t seem to make any real difference. In fact, the "Code Installation” time after applying the changes decreased by about 4% although it’s hard to say what the error bars are for this measurement. See the details of my mini-experiement at the end of this message.
> 
> Thanks for doing the experiments.
> 
>> I can understand that extracting the raw pointers from ciMetadata needs to be done carefully. However, the only difference this change makes is that it extracts the raw values earlier (i.e. as dependencies are recorded) instead of when they are serialized (in Dependencies::encode_content_bytes()).
> 
> If we take your change as it is then it means the ciMetadata subtree of classes are effectively deprecated and should be removed. I wonder whether we want that or not.

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.

-Doug