Review request: exports runtime support + jdk modules converted to use exports
David M. Lloyd
david.lloyd at redhat.com
Fri Jun 10 11:23:18 PDT 2011
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
On 06/10/2011 12:48 PM, Roger Riggs wrote:
> Hi Mandy,
> The size of the meta-data seems significant. What is the percentage
> added by the configuration tables? Does the entire configuration occupy
> the heap?
> From a small system perspective; the total memory numbers seem out of
> If it is just an optimization then it can wait. But if the current API
> a huge data structure is needed; then the design should be re-examined.
> 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).
>> 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
>> 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
>> of each context and there are 40 contexts requiring it.
More information about the jigsaw-dev