Open Bug 1540824 Opened 7 years ago Updated 4 years ago

Statically allocate XPCNativeInterface and XPCNativeMember

Categories

(Core :: XPConnect, defect, P3)

Product:
Core
Component:
XPConnect
Type:
defect

Tracking

()

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [overhead:20k])

This is another bundle of information used for calls between JS and C++. I think this is the XPConnect layer for calls from JS into C++. It looks like it could all be statically allocated.

In the content processes, it looks like it is using 9760 bytes to 21392 bytes of memory. In the main process, it is using 67360 bytes of memory. That memory usage doesn't include the jsid, which probably adds up to a decent amount.

Speaking of the jsid, I think the hard part of this will be eliminating the jsid, because those are dynamically allocated. Right now, we statically store this information in the XPT info, so there will have to be a conversion of code that deals with names internally, and some kind of conversion of passing in "real" jsid when method calls are made. Maybe there could be a stack-only helper class to deal with it. In theory there could be perf implications, because the stored names are atomized, so comparisons are fast, but in practice I doubt we compare the names of two different names. Also, we could rely on the fact that we deduplicate XPT strings and actually do constant time comparisons, but I don't know if I like that.

I think we can probably just store jsid values as indexes into a lookup table that we initialize per-process at startup.

That's a good idea. I was hoping to eliminate the dynamic allocation for the jsids, but it looks like the names are passed into the JS engine to create objects, so they do need to be turned into something the JS engine can deal with.

Though maybe external strings backed by statically allocated char* could work.

Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.