Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

Ulf Zibis
Hi,


Am 23.07.2017 um 15:37 schrieb Claes Redestad:
> 1. it reduces the size of the generated bytecode, which is necessary
> to keep code below method bytecode limits if the arrays generated are
> very large

I always was wondering why filling large lookup tables is done by static
java code in the class. Wouldn't it be more clever, to load the lookup
table content from a binary resource file? Then we must not bother to
initialize tables by static fake strings to save bytecode footprint.
The same thoughts would apply to the charset mappings in sun.nio.charset
classes.

-Ulf

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

Claes Redestad
Hi,

On 07/25/2017 01:14 PM, Ulf Zibis wrote:

> Hi,
>
>
> Am 23.07.2017 um 15:37 schrieb Claes Redestad:
>> 1. it reduces the size of the generated bytecode, which is necessary
>> to keep code below method bytecode limits if the arrays generated are
>> very large
>
> I always was wondering why filling large lookup tables is done by
> static java code in the class. Wouldn't it be more clever, to load the
> lookup table content from a binary resource file? Then we must not
> bother to initialize tables by static fake strings to save bytecode
> footprint.
> The same thoughts would apply to the charset mappings in
> sun.nio.charset classes.

while I think it's something to be avoided for CharacterDataLatin1
(since it's small enough anyway, as shown here), it seems like a fine
thing to do to experiment with loading arrays from binary resource files
instead of via "fake Strings". As a follow-up, of course.

Doing so may have both some good and some bad[1] startup implications,
but only an actual experiment will tell if the good outweighs the bad.

/Claes

[1] Loading some more classes, need to drop into the runtime image from
java code etc..
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

Xueming Shen
In reply to this post by Ulf Zibis
+1

On 7/23/17, 6:37 AM, Claes Redestad wrote:

> Hi,
>
> java.lang.CharacterDataLatin1 and others are generated at build time
> by the GenerateCharacter tool, which has a -string mode to generate
> lookup tables as Strings literals rather than arrays directly. This
> serves multiple purposes:
>
> 1. it reduces the size of the generated bytecode, which is necessary
> to keep code below method bytecode limits if the arrays generated are
> very large
> 2. it may under certain circumstances (large enough arrays, JITed
> code) be a performance optimization
>
> While having other performance benefits, the compact strings feature
> that went into 9 made String::toCharArray less friendly to startup,
> and since the same feature means we're now always loading
> CharacterDataLatin1 on bootstrap in all locales it seemed reasonable
> to re-examine whether this class in particular really gains from
> generating its lookup tables via String literals.
>
> Turns out it doesn't. By generating CharacterDataLatin1 tables as
> arrays explicitly:
>
> - executed bytecode drop from 21,782 to 2,077 when initializing this
> class (approximately 2% of executed bytecode; 1.5% of total instructions)
> - slight reduction (~1Kb) in the minimum retained heap usage
> - the size of CharacterDataLatin1.class only grows from 6458 to 7385
> bytes
>
> Proposed patch is to drop passing -string to GenerateCharacter for the
> latin1 case:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8185104
>
> Thanks!
>
> /Claes

Loading...