Storing external string type in JSString::length

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
9 years ago
9 years ago

People

(Reporter: igor, Assigned: igor)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
Currently for external strings their type type is stored using GC thing flags allocated for the string. This leads to extra checks during the finalization of the string. It also prevents shrinking GC flags down to 1 or 2 bits per thing with the type stored in the arena header. The latter would allow to minimize farther the amount of indirection during the marking and finalization.

Thus the idea is to store the external string type directly in JSString using the length bits. Inevitably this will restrict the maximum string length to 2**26 compared with the current 2*29 limit if 3 bits will be designated to the external type. But such limit is still rather generous since it means that a script would be able allocate strings with 128MB of data.
(Assignee)

Comment 1

9 years ago
Created attachment 400356 [details] [diff] [review]
v1

The patch moves the storage for external strings into JSString. As a consequence it shrinks the maximum string length from 256MB down to 32MB.

Comment 2

9 years ago
I think a much better approach of solving this is having external strings in a separate GC pool for each type. That avoids the virtual dispatch in the finalizer too. So separate GC pools for <double, object, function, regexp, internal-string, external-string-0, external-string-1>.
(Assignee)

Comment 3

9 years ago
(In reply to comment #2)
> I think a much better approach of solving this is having external strings in a
> separate GC pool for each type. That avoids the virtual dispatch in the
> finalizer too. So separate GC pools for <double, object, function, regexp,
> internal-string, external-string-0, external-string-1>.

Right, I have filed bug 517199 about this. I still keep this bug open as using separated free lists for external strings may cause excessive fragmentation especially if bugger GC arenas would be chosen. In that case we may opt for shared free list for all strings.

For example, for a browser run with GMail and few more sites I have 2 external string types taking 1%-4% and 0.1% - 0.3% of all allocated strings.
(Assignee)

Comment 4

9 years ago
This have not been relevant since introduction of typed GC free lists.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.