RFR: 8171855: Move package name transformations during module bootstrap into VM

[forax at univ-mlv.fr]

Ok,
I was sure to have seen java.base and not java.lang,
past midnight here, time to crawle back to my bedroom :)

Rémi

----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>, hotspot-runtime-dev at openjdk.java.net
> Envoyé: Mardi 3 Janvier 2017 00:21:48
> Objet: Re: RFR: 8171855: Move package name transformations during module bootstrap into VM

> Hi Rémi,
> 
> are you confusing package names with module names?
> 
> From the linked specification:
> 
> "Package names referenced from the Module attribute are stored in
> CONSTANT_Package_info entries in the constant pool. Such entries wrap
> CONSTANT_Utf8_info entries which represent package names encoded in
> internal form."
> 
> This still appears necessary since loading the module establishes the
> symbol entries representing the referenced packages.
> 
> Thanks!
> 
> /Claes
> 
> On 2017-01-03 00:06, Remi Forax wrote:
>> Hi Claes,
>> the whole replace dance should not be needed anymore with the latest revision of
>> the spec,
>> module names are not stored in internal form anymore.
>>
>> see http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.1
>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Claes Redestad" <claes.redestad at oracle.com>
>>> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>,
>>> hotspot-runtime-dev at openjdk.java.net
>>> Envoyé: Lundi 2 Janvier 2017 19:27:43
>>> Objet: RFR: 8171855: Move package name transformations during module	bootstrap
>>> into VM
>>
>>> Hi,
>>>
>>> during jigsaw bootstrap, package names - represented in external form,
>>> "java.lang" - are transformed into VM internal form, "java/lang",
>>> before calling into the VM.
>>>
>>> This, however, can effectively be moved into the VM, which removes the
>>> need to generate a lot of short-lived strings during bootstrap and heat
>>> up various String.replace-related methods.  This has a noticeable impact
>>> on startup metrics.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8171855/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171855
>>>
>>> JPRT -testset hotspot pass, and I've prepared to push this into jdk9/hs
>>> if there are no objections.
>>>
>>> Char-based replace on a UTF-8 source should be correct as long as the
>>> from and to chars are ASCII (0x00 through 0x7F).  A more general method
>>> would be needed to safely deal with char values above 0x7F, so adding
>>> some asserts to that effect should be considered.
>>>
>>> Thanks!
>>>
> >> /Claes