> On 30 Jan 2017, at 21:55, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Jan 30, 2017, at 10:38 AM, Doug Simon <doug.si...@oracle.com> wrote: >> >> I’ve extended the webrev with that change - please re-review: >> >> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >> > > +1
Thanks. Is that a “Reviewed”? I think I should get at least one sign-off from the security team. Also, since this is effectively making jdk.vm.compiler an upgradeable module, what’s the implication for it being a hash-checked module? It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. -Doug > >> Strangely, there was no existing declaration of jdk.vm.compiler in >> Modules.gmk. >> > > Default is to be defined by the application class loader. The build will > find all modules from the source. There is no need to list all modules. > >> BTW, I never answered your question: >> >> "How does JVMCI call out to jdk.vm.compiler? does it load classes using >> Class::forName with the system class loader?” >> >> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard >> ServiceLoader. > > Thanks for the pointer. That confirms my understanding that loads the service > providers using the system class loader. > > Mandy
