Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule

[serguei.spitsyn at oracle.com]

Please, review the Jigsaw fix for the enhancement:
https://bugs.openjdk.java.net/browse/JDK-8159145


The Hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/


The Jdk webrev is the same:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/


Summary:

   This is the review round #3.
   Alan suggested to replace the function GetModuleByPackageName with 
the GetNamedModule.
   New function will return NULL if the package is not in a module 
defined to the class loader.
   It simplifies the API and makes it easier to specify.
JVM TI agents that instrument code in named modules need the Module at 
class load time.

   One question that came from the function semantics change.
   I had to implement the Modules::get_named_module() from scratch 
independently of the existing
   Modules::get_module_by_package_name() and Modules::get_module().
   The issue is that the Modules::get_module() can return the unnamed 
module whereas the
   JVMTI helper Modules::get_named_module() should return NULL instead 
of the unnamed module.
Please, let me know if it is Ok or if you have better ideas how to share 
the code.

   This is the Summary from review round #1:

   One way to do this is by introducing a new ClassFileLoadHook that 
takes an additional parameter but this approach is disruptive.
   The alternative option is a JVM TI function that maps a classloader + 
package name to a module.
   We were initially not confident with this approach so we introduced 
it as JVM function JVM_GetModuleByPackageName.
   Based on experience to date then this approach seems okay and so this 
function needs to be promoted to a JVMTI function.

   It includes new jtreg test with native JVMTI agent.


Testing:
    Run newly developed jtreg test.

Thanks,
Serguei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160627/3bd3d88a/attachment-0001.html>