[JSC] JSPropertyNameEnumerator could be destructorless.
authorakling@apple.com <akling@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 17 Nov 2015 22:13:41 +0000 (22:13 +0000)
committerakling@apple.com <akling@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 17 Nov 2015 22:13:41 +0000 (22:13 +0000)
commitc6f12f306231e91d67a33678b19f6c46ad78895d
treea86caf6d88e362ac066dc89d79923291f4469d2b
parent4d8f2295f5ba00352436b09bff63d2d98023c8d3
[JSC] JSPropertyNameEnumerator could be destructorless.
<https://webkit.org/b/151242>

Reviewed by Mark Lam.

Make JSPropertyNameEnumerator destructorless and have it store the property names
cache in CopiedSpace. This was the most popular occupant of 64-byte destructor cells
in MarkedSpace, so making it destructorless gets rid of some ill-filled MarkedBlocks.

This patch had two issues on 32-bit platforms when first landed:

- Copied space allocations are required to be 8-byte divisible in size.

- WriteBarrier<Unknown> and WriteBarrier<JSString> are not the same size on 32-bit;
  the former is a 64-bit EncodedJSValue internally, and the latter is a 32-bit JSCell*.
  My patch was reinterpret_cast'ing a WriteBarrier<JSString> to a WriteBarrier<Unknown>
  when passing to SlotVisitor::appendValues(), which led to invalid addresses getting
  marked and strings getting GC'd prematurely.

* heap/CopyToken.h:
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation):
(JSC::JSPropertyNameEnumerator::visitChildren):
(JSC::JSPropertyNameEnumerator::copyBackingStore):
(JSC::JSPropertyNameEnumerator::destroy): Deleted.
* runtime/JSPropertyNameEnumerator.h:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@192536 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/heap/CopyToken.h
Source/JavaScriptCore/runtime/JSPropertyNameEnumerator.cpp
Source/JavaScriptCore/runtime/JSPropertyNameEnumerator.h