Review request: exports runtime support + jdk modules converted to use exports

[Roger Riggs]

Hi Mandy,

The size of the meta-data seems significant.  What is the percentage 
overhead
added by the configuration tables?  Does the entire configuration occupy 
the heap?
 From a small system perspective; the total memory numbers seem out of 
scale.

If it is just an optimization then it can wait.  But if the current API 
implies
a huge data structure is needed; then the design should be re-examined.

Roger


On 6/10/11 3:27 AM, Mandy Chung wrote:
>  On 6/9/11 11:32 AM, Mandy Chung wrote:
>>  On 6/9/11 5:48 AM, Alan Bateman wrote:
>>> I've been looking at the webrev and was wondering about this. I 
>>> grabbed the patch file from the webrev and did some tests and it 
>>> looks like the stored configuration for simple tests jumps very 
>>> significantly, like from about 6.5MB to 90MB. The reason is that 
>>> java -m spends several seconds loading it. Are you seeing this too? 
>>
>> I can reproduce this.  My test cases require jdk.base and thus I 
>> didn't see this.  The current default is "requires jdk" if no jdk 
>> module is specified in the module-info that causes all jdk modules 
>> (contexts and their local/remote maps) be included in the 
>> configuration. I am looking into an optimization to this.
>>
> An update on the analysis:
>
> I instrumented the simple library. This single context's name itself
> takes up 80% of the config file size (~75M).
>
> +jdk.boot+sun.charsets+sun.compat+sun.corba+sun.desktop+sun.ext+sun.instrument+sun.jaas+sun.jaxp+sun.jdbc+sun.jndi+sun.jsse+sun.jta+sun.kerberos+sun.localedata+sun.logging+sun.management+sun.resources+sun.rmi+sun.security.acl+sun.sunec 
>
>
> count  per-string bytes total bytes
> 327099     235          76868265
>
> Each context contains a map from a remote class name to a context's name.
> When the map's key is changed from package name to a class name, the
> number of context's name is thus significantly increased.  A simple
> fix would be using an integer as the context ID and storing the name
> only once.
>
> Top 15 strings with the highest total of bytes in the config file:
> count   bytes    total  contexts name
> 327099    235 76868265   41     
> +jdk.boot+sun.charsets+sun.compat+sun.corba+sun.desktop+sun.ext+sun.instrument+sun.jaas+sun.jaxp+sun.jdbc+sun.jndi+sun.jsse+sun.jta+sun.kerberos+sun.localedata+sun.logging+sun.management+sun.resources+sun.rmi+sun.security.acl+sun.sunec
>   5550     16    88800    1     sun.desktop at 7-ea
>   4121     10    41210   11     +jdk.javac
>   3722     10    37220    6     +sun.jaxws
>   3467     13    45071    1     jdk.boot at 7-ea
>   3325     14    46550    1     jdk.tools at 7-ea
>   2502     13    32526    1     sun.jaxp at 7-ea
>   2405     14    33670    1     sun.jaxws at 7-ea
>   1677     14    23478    1     sun.corba at 7-ea
>   1441     20    28820    1     jdk.tools.jaxws at 7-ea
>    801     13    10413    9     +jdk.compiler
>    768     14    10752    1     jdk.javac at 7-ea
>    558     19    10602    1     sun.management at 7-ea
>
> Total number of strings in the config file is 729694 but 26185
> unique strings. Total bytes occupied by these strings is 91839030.
>
> The strings created in the configuration includes
>    context's name
>    module's name at version
>    module library path
>    class name
>
> There is other opportunity for optimization.  For example, for each class
> from jdk.boot, there are 40 copies in the config as one in each remote 
> map
> of each context and there are 40 contexts requiring it.
>
> Mandy
>