AllocationMetadataBuilder is too general
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
People
(Reporter: jimb, Unassigned)
References
(Blocks 1 open bug)
Details
Letting an arbitrary AllocationMetadataBuilder drive metadata collection for JS object allocations makes it hard for multiple consumers to request metadata collection simultaneously. Because the virtual base class gives no information about what the implementation actually does, there's no reasonable way to determine the "union" of multiple requests.
For example, both the devtools and the profiler may want allocation metadata (see bug 1545582), but if the two provide distinct AllocationMetadataBuilder instances, there's no way to reconcile them.
The only reason the situation is tenable at the moment is that, in fact, there is only one AllocationMetadataBuilder anyone wants to use, outside of testing code. So there would be no loss in observable functionality if we simply had a single form of metadata that can be collected, and let it be either on or off. This would substantially simplify the plumbing, and free bug 1545582 from inventing unsatisfying answers to questions nobody really cares about.
If different consumers really have different needs, perhaps we could have a bitmask of data to include - but still have a single builder.
Updated•7 years ago
|
Updated•3 years ago
|
Updated•1 year ago
|
Description
•