Bug 106066
| Summary: | LLint: Number.MIN_VALUE is 0 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Dominic Szablewski <dominic.szablewski> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Major | CC: | ap, barraclough, fpizlo, ggaren |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://jsfiddle.net/Gz9QC/ | ||
Dominic Szablewski
At least I suspect it's an issue with LLint: The JSFiddle test case work correctly in Mobile Safari on iOS6 (which uses the JIT), but fails in Chrome for iOS (which isn't allowed to use the JIT and thus falls back to LLint).
A standalone version of libJavaScriptCore for iOS ( https://github.com/phoboslab/JavaScriptCore-iOS ) also has this problem on real hardware (again, using LLint), but works fine in the iPhone Simulator (using the classic interpreter).
Number.MIN_VALUE is defined as 5E-324, but the smallest representable number with LLint seems to be somewhere in the 5E-308 range - console.log(5E-309) shows 0 again.
An easy workaround would be to allow us to use the JIT on iOS ;-)
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Geoffrey Garen
The smallest representable number is a per-process CPU setting, not controlled by JavaScriptCore.
Dominic Szablewski
Sorry, I don't understand. Even if it's a CPU setting, shouldn't JSC return _that_ current setting for MIN_VALUE instead of 0? In the JSC source, MIN_VALUE is set to a fixed value (5E-324).
Dominic Szablewski
In case it wasn't clear, I'm talking about the "Number" object in the JS runtime. Specifically, the Number Constructor. It has a property "MIN_VALUE" that you can access in JavaScript code.
This works fine when using the JSC JIT (it returns 5E-309), but fails when using LLint (it returns 0).
See 'numberConstructorMinValue' in NumberConstructor.cpp around line 109
https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore/runtime/NumberConstructor.cpp
Geoffrey Garen
In processes that don't support denormal doubles, 5E-309 rounds to 0.
Dominic Szablewski
Ok. So who is to blame? Is this an OS issue? Clearly MIN_VALUE should not be 0.
From the ECMA standard ( http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf ):
15.7.3.3 Number.MIN_VALUE
The value of Number.MIN_VALUE is the smallest positive value of the Number type, which is approximately 5E-324
Dominic Szablewski
Pardon my ignorance. TN2293 ( http://developer.apple.com/library/ios/#technotes/tn2293/_index.html ) explains a bit more. So I guess it is expected to always run JSC with support for denormal numbers enabled, correct?
Wouldn't a fix where MIN_VALUE returns the _actual_ smallest representable number still make sense? I.e. if denormal support is enabled, return 5E-324, otherwise 5E-308.
Geoffrey Garen
> Wouldn't a fix where MIN_VALUE returns the _actual_ smallest representable number still make sense? I.e. if denormal support is enabled, return 5E-324, otherwise 5E-308.
That sounds like a good idea. Why don't you file a new bug requesting that. (This bug is cluttered with a lot of confusing speculation about the LLInt, the JIT, and some third party software.)