RFR: 8031639: make dependency management (mostly) ci independent (original) (raw)
Roland Westrelin roland.westrelin at oracle.com
Mon Jan 20 08:13:20 PST 2014
- Previous message: RFR: 8031639: make dependency management (mostly) ci independent
- Next message: RFR: 8031639: make dependency management (mostly) ci independent
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Doug,
More informative assert messages than “oops” would be appreciated.
dependencies.hpp:
comment needs to be fixed: 249 GrowableArray* _dep_seen; // (seen[h->ident] & (1<<dept))
dependencies.cpp:
75 if (is_java_primitive(elemt)) return; // Ex: int[][] align comment with // Ex: String[][]
121 void Dependencies::assert_call_site_target_value(jobject call_site, jobject method_handle) { 122 Klass* ctxk = JNIHandles::resolve(call_site)->klass(); 123 check_ctxk(ctxk); 124 assert_common_2(call_site_target_value, DepValue(_oop_recorder, call_site), DepValue(_oop_recorder, method_handle)); 125 }
Don’t you need a VM_ENTRY?
Have you verified that compilation time is not affected?
I don’t really feel comfortable with this change. I wonder if it wouldn’t be simpler to have a base class for Dependencies, then one subclass for Dependencies that work on ci objects and one subclass that work directly on objects and Metadata. Then either accept code duplication or maybe use a parallel hierarchy for DepValue.
Anyway, I’m not strongly against this either and I welcome another opinion.
Roland.
- Previous message: RFR: 8031639: make dependency management (mostly) ci independent
- Next message: RFR: 8031639: make dependency management (mostly) ci independent
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the hotspot-compiler-dev mailing list