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

[Claes Redestad]

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.

http://cr.openjdk.java.net/~redestad/8242452/open.02/

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. :-)

/Claes