It's unclear how important this is, but it's in any case part of the agenda of cracking down on GCRoot abuse: AvmCore currently contains pointers to about 200 string constants. They are created at startup and are GC'd at the earliest when the AvmCore has been deleted. They are scanned (conservatively) every time the AvmCore is scanned, which is twice per GC. There's no danger of misidentifying pointers, but the conservative scanning and the second scanning seem like pointless overhead, and in any case the number of entries just makes writing and maintaining an exact scanner for AvmCore more work. The alternative would be to move these string constants off into a second, precisely scanned, object.

There are a far larger number in PlayerAvmCore in Flash, which should also be converted.

Related: bug 572204, bug 623926

(In reply to comment #2) > Related: bug 572204, bug 623926 Right. I was envisioning something easy here - hang an object off AvmCore that is an array of strings, that way we get one pointer in a small root rather than hundreds in a large root - but maybe I'm deluding myself.

(In reply to comment #3) > (In reply to comment #2) > > Related: bug 572204, bug 623926 > > Right. I was envisioning something easy here - hang an object off AvmCore that > is an array of strings, that way we get one pointer in a small root rather than > hundreds in a large root - but maybe I'm deluding myself. So, an extra load in most cases?

(In reply to comment #4) > So, an extra load in most cases? That was the plan. I don't have any data on how often these are accessed though. Do you have misgivings?

No data either, although kEmptyString seems popular. Probably no measurable effect of the extra load on performance, at least not now. Ideally the strings would be refactored into a separate object that could hang off of AvmCore, but it would be easy to embed it in AvmCore in case it makes a difference at some point.

I assume cleaning this up will be a desirable aspect of the ANI work, so moving to Steven.

It can wait.

Note that a simliar change was made in the player using an enum header (StringConstants.h), a const char *str[] file (StringConstants.hh included into .cpp) and a RCList hanging off a root and that worked fairly well. The motivation there was that thousands of GCMember's in one class caused GCC to bumps its head into 32 bit memory allocation limits.

No assignee, updating the status.

No assignee, updating the status.

No assignee, updating the status.

No assignee, updating the status.

Tamarin isn't maintained anymore. WONTFIX remaining bugs.