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

2020-04-16 Thread Claes Redestad
On 2020-04-16 23:05, Ioi Lam wrote: Did you revert the change in jvmtiEnv.cpp as well? It's still changed in your latest webrev below but this change doesn't seem to be needed. Fixed - a minor mishap. New webrev: http://cr.openjdk.java.net/~redestad/8242452/open.01/ Updated in-place

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

2020-04-16 Thread Ioi Lam
On 4/16/20 12:56 PM, Claes Redestad wrote: Hi Ioi, On 2020-04-16 01:04, Ioi Lam wrote: Hi Claes, This is very good optimization. Thanks! I have a few nit picks: Uh oh! [1] I think the following is unnecessary. The original Java_java_lang_Module_defineModule0 and

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

2020-04-16 Thread Claes Redestad
Hi Ioi, On 2020-04-16 01:04, Ioi Lam wrote: Hi Claes, This is very good optimization. Thanks! I have a few nit picks: Uh oh! [1] I think the following is unnecessary. The original Java_java_lang_Module_defineModule0 and GetInternalPackageName function did not perform null check or

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

2020-04-16 Thread Claes Redestad
Hi, my intent has been to not remove any checks in the VM endpoints that were there previously. Some of the package == NULL checks might not be as immediately apparent, but they should all be there (and checked for by pre-existing tests such as runtime/modules/JVMAddModuleExports.java) /Claes

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

2020-04-16 Thread Alan Bateman
On 16/04/2020 00:04, Ioi Lam wrote: Hi Claes, This is very good optimization. I have a few nit picks: [1] I think the following is unnecessary. The original Java_java_lang_Module_defineModule0 and GetInternalPackageName function did not perform null check or type check. I think this