Closed Bug 741772 Opened 12 years ago Closed 10 years ago

Universal builds contain one type of jsloader cache in omni.ja instead of two

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: glandium, Unassigned)

References

Details

AIUI, jsloader cache is endianness and bit-width dependent, which is why it's stored in zip files depending on these two parameters in the user profile. However, we only ship one type of files in osx universal builds, which contain both 32-bits and 64-bits binaries. I don't know which bit-width we ship the jsloader files for, but obviously, they are wrong for one of the architectures.
njn made optimizations to the js parser. We should benchmark whether caching js is a win at all.
Depends on: 742899
So what are we currently shipping on OS X? 32 or 64-bit? Does it make sense to change this?
Flags: needinfo?(mh+mozilla)
IIRC, at the time I filed this bug, it was 32-bits. Nowadays, it's 64-bits. IIRC that changed at the time I changed the packager (around Firefox 22)
Flags: needinfo?(mh+mozilla)
Saying this completely off-the-cuff, but I expect it's not useful to update it to facilitate providing 32-bit in addition to 64 bit, considering 32-bit OS X is (however slowly) on the way out, and probably won't be with us at least in 2-3 years, if not (much) sooner. Should we mark wontfix/wfm ?
Indeed
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.