QV4::IdentifierHashData doesn't need to be visible to all the clients.
Furthermore, it can be completely inline. The public functions of
QV4::IdentifierHash need to be out of line, but the private ones can be
all inline. This shouldn't make much of a difference as most of the
public functions call at least one private function. Finally, the files
should be named by the class names.

Change-Id: I931f2aa71103e41fdd3dae9cc47d204edece0e12
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

They all had some interesting bugs and duplicated each other:
a, propertiesFrozen() changed each property individually, creating a lot
of unnecessary intermediate classes. frozen() changed them all at once.
b, If a class happened to contain only properties that matched the
characteristics of being "sealed" or "frozen", sealed(), frozen() and
propertiesFrozen() would set the flags in place and return the same
class. This is bad because it violates the assumption that an
InternalClass is immutable and it breaks the recursive freezing
algorithm we rely on for the global object. It would stop freezing child
objects at any such class, even if the children were not frozen.
c, propertiesFrozen() did not set any of the flags even though it
effectively sealed and froze the class. Therefore, when requesting the
same class as frozen() it would iterate through all the properties
again.
d, frozen() implicitly also sealed the object and made it
non-extensible. sealed() also implicitly made it non-extensible. This is
impractical as we want to allow objects to be extensible even though all
their properties are frozen. Therefore we only set the flag that belongs
to each method now. We do know, however, that a frozen object is
implicitly sealed. Therefore we can short-circuit this transition.

Furthermore, we need to remove the assert in InternalClass::init() as
you can indeed use frozen objects as prototypes for others, but that
needs to be recorded in the original InternalClass via the isUsedAsProto
flag. In order to set this flag, we need to perform a transition and
therefore, derive from the old InternalClass.

The JavaScript isFrozen() method asks for an _implicitly_, "duck typed",
frozen state, which is different from what our "isFrozen" flag denotes.
Therefore we add a separate const method that just checks whether all
properties are frozen.

Task-number: QTBUG-76033
Change-Id: I375fef83fb99035d470490fdf2348766b090831e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
 

Make it completely inline, move the (4 times duplicated) primeForNumBits
function into its own file, address some warnings, move
QHashedString::compare into qhashedstring.cpp.

Change-Id: I778bb3d3e176cfec45eda9be9d7e5982585e6474
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>

We can effectively only deal with values of < 2GB for m_alloc *
sizeof(Data). This is not much more than the values seen in the wild.

Change-Id: Ia6972df33d34a320b5b087d38db81aae24ce5bbe
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

There is no reason to start from the empty class in that case.
Furthermore, if the properties are already frozen, starting from the
empty class will walk the IC hierarchy to the current IC. However, if
the garbage collector has removed the intermediate classes in the mean
time, we end up at a new IC which is equivalent but not the same.
Therefore, the freezing never terminates.

Task-number: QTBUG-74190
Change-Id: Id544bd00d3b4b563fb06dfce0edd0385e1d32a6c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

As we check the icAllocator's slots on shouldRunGC() we should also
check shouldRunGC() when adding slots. Otherwise we might never run the
GC when only allocating InternalClasses. In addition, account for the
"unmanaged" size of the PropertyAttributes that are part of the
InternalClass objects. Those can be large.

In cases where an excessive number of large InternalClass objects is
created the garbage collector is now invoked frequently, which costs a
significant number of CPU cycles, but prevents the memory usage from
growing indefinitely.

Task-number: QTBUG-58559
Change-Id: Icf102cb6100f6dba212b8bffe1c178897880eda0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

The parent pointer is only kept so that we can update the parent's
transitions when removing a child. There is no need to keep the parents
alive for the children.

Fixes: QTBUG-58559
Change-Id: Ia28183966bde6d478ca030fe11195489925dfc13
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>

In line with the previous commit, allow entries with a valid
PropertyKey, but invalid attributes in the InternalClass. Those
entries mark a deleted property.

This cleans up/unifies some of the code in the internal class
implementation and allows re-using the slot if a deleted property
gets added again.

Change-Id: I1bada697486e3cafce7689bae87b7f884200dd99
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>

Until now, changing an existing property into an accessor
property would cause the slots in the object to get re-arranged
to make space for the additional setter required.

Change this by dropping the requirement that getter and setter
slot have to be next to each other. This has the advantage, that
any slot we define to be at a certain position in the internal
class/object will stay there and we can use that assumption to
optimize accesses to the slot.

Change-Id: Ib37c2a49fc6aae42ea4b2da36ac1dc3036540c12
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>

The only place where we now assume that getters and setters are
next to each other in the MemberData is in the internal class.

Change-Id: I3285f3abb1cbfe051853e808339cd360eb602262
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>