RFR: 8242452: During module definition, move conversion of packages from native to VM

Claes Redestad claes.redestad at oracle.com
Fri Apr 17 14:48:52 UTC 2020

Hi Harold,

On 2020-04-17 15:32, Harold Seigel wrote:
> Hi Claes,
> The change looks good.  Just a couple of minor things.

thank you for reviewing!

> In JavaClasses.cpp, line 652, does length need to be initialized to zero?

Good point, most of the length variables passed by reference to retrieve
the length can be left uninitialized.

> The indentation looks wrong at line 658.

Hmm, yeah. Not sure how to make it look right, though.

> The changes in modules.cpp look good!  Maybe as_symbol() could 
> eventually be moved to symbolTable.hpp.

Seems reasonable, but as I want to avoid Handle'ing the oop I felt more
comfortable with a local utility method for now.

> Very minor typos in modules.hpp ("to to").

Fixed both places.


Have verified VM module tests locally and re-running a sanity tier1
before push.

> I don't need to see another webrev.
> One change that we looked at but did not do is to have one call from the 
> JDK to the JVM to, for example, add all of a module's qualified 
> exports.  Currently, each export is a separate call from the JDK to the 
> VM.  I'm not sure if this is worth doing.

Could be, but I think we'd have to refactor the interaction more to be
able to turn it into a real gain.

A less granular API might be better suited for archiving optimizations,
which I know Ioi has been giving some thought to. That is: we're able to
archive the java object model for module descriptors and the default
model graph - why not also the VM model? Not today, but let's keep the
door open. :-)


More information about the hotspot-runtime-dev mailing list