Attachment #261414 for bug #149283

View Details Raw Unified Return to Bug 149283



2015-09-17  Filip Pizlo  <fpizlo@apple.com>

        0.0 should really be 0.0
        https://bugs.webkit.org/show_bug.cgi?id=149283

        Reviewed by NOBODY (OOPS!).

        A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
        user wrote a number with a decimal point (like "0.0") then we should treat that number as
        a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
        The DFG would indeed treat such a number as a double by consulting the
        SourceCodeRepresentation, but the other execution engines would still see Int32:0.

        This patch makes it consistent.

        This is necessary for property type inference to perform well. Otherwise, a store of a
        constant would change type from the baseline engine to the DFG, which would then cause
        a storm of property type invalidations and recompilations.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addConstantValue):

2015-09-17  Saam barati  <sbarati@apple.com>

        Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions

Lines 1251-1256 RegisterID* BytecodeGenerator::addConsta Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp_sec1
- Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp +2 lines
1251		1251
1252	int index = m_nextConstantOffset;	1252	int index = m_nextConstantOffset;
1253		1253
		1254	if (sourceCodeRepresentation == SourceCodeRepresentation::Double && v.isInt32())
		1255	v = jsDoubleNumber(v.asNumber());
1254	EncodedJSValueWithRepresentation valueMapKey { JSValue::encode(v), sourceCodeRepresentation };	1256	EncodedJSValueWithRepresentation valueMapKey { JSValue::encode(v), sourceCodeRepresentation };
1255	JSValueMap::AddResult result = m_jsValueMap.add(valueMapKey, m_nextConstantOffset);	1257	JSValueMap::AddResult result = m_jsValueMap.add(valueMapKey, m_nextConstantOffset);
1256	if (result.isNewEntry) {	1258	if (result.isNewEntry) {

Return to Bug 149283

Lines 1-3 Source/JavaScriptCore/ChangeLog_sec1
- Source/JavaScriptCore/ChangeLog +22 lines
		1	2015-09-17 Filip Pizlo <fpizlo@apple.com>
		2
		3	0.0 should really be 0.0
		4	https://bugs.webkit.org/show_bug.cgi?id=149283
		5
		6	Reviewed by NOBODY (OOPS!).
		7
		8	A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
		9	user wrote a number with a decimal point (like "0.0") then we should treat that number as
		10	a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
		11	The DFG would indeed treat such a number as a double by consulting the
		12	SourceCodeRepresentation, but the other execution engines would still see Int32:0.
		13
		14	This patch makes it consistent.
		15
		16	This is necessary for property type inference to perform well. Otherwise, a store of a
		17	constant would change type from the baseline engine to the DFG, which would then cause
		18	a storm of property type invalidations and recompilations.
		19
		20	* bytecompiler/BytecodeGenerator.cpp:
		21	(JSC::BytecodeGenerator::addConstantValue):
		22
1	2015-09-17 Saam barati <sbarati@apple.com>	23	2015-09-17 Saam barati <sbarati@apple.com>
2		24
3	Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions	25	Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions