959331 - attribute/element initialize/release statics functions take up a lot of space

Status: NEW

(Core :: DOM: HTML Parser, defect)

Description

[Nathan Froyd [:froydnj]]

Looking at code sizes for ARM Android, I see:

[froydnj@cerebro build-android]$ for o in $(find parser -name '*.o'); do readelf -s -W $o; done | grep FUNC |sort -k 3 -n -r 2>/dev/null|head -n 15|c++filt
  1685: 000091b1 28608 FUNC    GLOBAL HIDDEN    55 nsHtml5AttributeName::initializeStatics()
  1684: 00005b1d 13970 FUNC    GLOBAL HIDDEN    55 nsHtml5ElementName::initializeStatics()
  2431: 0000dd01 13360 FUNC    GLOBAL HIDDEN   202 nsHtml5Tokenizer::tokenizeBuffer(nsHtml5UTF16Buffer*)
  1657: 00002695 12576 FUNC    GLOBAL HIDDEN    55 nsHtml5AttributeName::releaseStatics()
  1003: 0000b755  9644 FUNC    LOCAL  DEFAULT  202 _ZN16nsHtml5Tokenizer9stateLoopI19nsHtml5SilentPolicyEEiiDsiPDsbii.clone.6
  1656: 000005cd  8392 FUNC    GLOBAL HIDDEN    55 nsHtml5ElementName::releaseStatics()

Those initializeStatics functions are awfully large and are just allocating and initializing what should be constant data tables.  The tables need some cleverness (and maybe help from elsewhere) to avoid introducing a large amount of relocations, though, and I'm not sure that's possible with the automagic translation from Java.  (Assuming we're still doing that...)

Comment 1

[Henri Sivonen (:hsivonen)]

(In reply to Nathan Froyd (:froydnj) from comment #0)
> Those initializeStatics functions are awfully large and are just allocating
> and initializing what should be constant data tables.  The tables need some
> cleverness (and maybe help from elsewhere) to avoid introducing a large
> amount of relocations, though, and I'm not sure that's possible with the
> automagic translation from Java. 

The reason for this stuff isn't Java. The reason is that the element/attribute objects have pointers to nsIAtoms and our static atoms aren't plain old C data.

I'd be happy to pursue making these plain static C data if our static atoms become plain static C data first.

> (Assuming we're still doing that...)

We are.

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Henri Sivonen (:hsivonen) from comment #1)
> (In reply to Nathan Froyd (:froydnj) from comment #0)
> > Those initializeStatics functions are awfully large and are just allocating
> > and initializing what should be constant data tables.  The tables need some
> > cleverness (and maybe help from elsewhere) to avoid introducing a large
> > amount of relocations, though, and I'm not sure that's possible with the
> > automagic translation from Java. 
> 
> The reason for this stuff isn't Java. The reason is that the
> element/attribute objects have pointers to nsIAtoms and our static atoms
> aren't plain old C data.

I don't see why that is necessarily a problem: the initialization process could simply fill in those pointers (at least in the case of elements; attributes have pointers to pointers, which don't require anything special).  And initialization could become some short memory copy loop, which would be significantly smaller than the mass of function calls we currently have now.