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

[David M. Lloyd]

Keeping (additional) maps of every class seems ludicrous to me.  In 
JBoss Modules, we do everything by package, with additional filters 
which can be (optionally) applied for the non-common case where you want 
to only partially export a package.  It is far more memory-efficient, 
and empirically seems to be very fast.

Note that it is important not to over-promise the contract.  If you tell 
people that they can and should routinely pick and choose classes within 
a package to export or not export, you're encouraging a usage pattern 
that may not be easy to implement efficiently.

By encouraging users to export whole packages only, but give the option 
of partial package export (at a possible performance cost) you are 
encouraging much more performant behaviors without reducing your total 
functionality.

On 06/10/2011 12:48 PM, Roger Riggs wrote:
> 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
>>


-- 
- DML