RFR: 8242452: During module definition, move conversion of packages from native to VM
claes.redestad at oracle.com
Fri Apr 17 14:48:52 UTC 2020
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
> 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