mirrors-yuzu-emu/unicorn
1
0
Fork 0
mirror of https://github.com/yuzu-emu/unicorn synced 2024-11-25 11:28:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
unicorn/qemu/qobject/qobject.c

63 lines
1.4 KiB
C
Raw Normal View History

qobject: Simplify QObject The QObject hierarchy is small enough, and unlikely to grow further (since we only use it to map to JSON and already cover all JSON types), that we can simplify things by not tracking a separate vtable, but just inline the code element of the vtable QType directly into QObject (renamed to type), and track a separate array of destroy functions. We can drop qnull_destroy_obj() in the process. The remaining QObject subclasses must export their destructor. This also has the nice benefit of moving the typename 'QType' out of the way, so that the next patch can repurpose it for a nicer name for 'qtype_code'. The various objects are still the same size (so no change in cache line pressure), but now have less indirection (although I didn't bother benchmarking to see if there is a noticeable speedup, as we don't have hard evidence that this was in a performance hotspot in the first place). A future patch could drop the refcnt size to 32 bits for a smaller struct on 64-bit architectures, if desired (we have limits on the largest JSON that we are willing to parse, and will probably never need to take full advantage of a 64-bit refcnt). Backports commit 55e1819c509b3d9c10a54678b9c585bbda13889e from qemu
2018-02-20 02:34:54 +00:00
/*
* QObject
*
* Copyright (C) 2015 Red Hat, Inc.
*
* This work is licensed under the terms of the GNU LGPL, version 2.1
* or later. See the COPYING.LIB file in the top-level directory.
*/
#include "qemu-common.h"
#include "qapi/qmp/qbool.h"
qdict qlist: Make most helper macros functions The macro expansions of qdict_put_TYPE() and qlist_append_TYPE() need qbool.h, qnull.h, qnum.h and qstring.h to compile. We include qnull.h and qnum.h in the headers, but not qbool.h and qstring.h. Works, because we include those wherever the macros get used. Open-coding these helpers is of dubious value. Turn them into functions and drop the includes from the headers. This cleanup makes the number of objects depending on qapi/qmp/qnum.h from 4551 (out of 4743) to 46 in my "build everything" tree. For qapi/qmp/qnull.h, the number drops from 4552 to 21. Backports commit 15280c360e54a65e2c7be1a47bfbe41dce1ef986 from qemu
2018-03-08 13:29:56 +00:00
#include "qapi/qmp/qnull.h"
#include "qapi/qmp/qnum.h"
qobject: Simplify QObject The QObject hierarchy is small enough, and unlikely to grow further (since we only use it to map to JSON and already cover all JSON types), that we can simplify things by not tracking a separate vtable, but just inline the code element of the vtable QType directly into QObject (renamed to type), and track a separate array of destroy functions. We can drop qnull_destroy_obj() in the process. The remaining QObject subclasses must export their destructor. This also has the nice benefit of moving the typename 'QType' out of the way, so that the next patch can repurpose it for a nicer name for 'qtype_code'. The various objects are still the same size (so no change in cache line pressure), but now have less indirection (although I didn't bother benchmarking to see if there is a noticeable speedup, as we don't have hard evidence that this was in a performance hotspot in the first place). A future patch could drop the refcnt size to 32 bits for a smaller struct on 64-bit architectures, if desired (we have limits on the largest JSON that we are willing to parse, and will probably never need to take full advantage of a 64-bit refcnt). Backports commit 55e1819c509b3d9c10a54678b9c585bbda13889e from qemu
2018-02-20 02:34:54 +00:00
#include "qapi/qmp/qdict.h"
#include "qapi/qmp/qlist.h"
#include "qapi/qmp/qstring.h"
qapi: Convert QType into QAPI built-in enum type What's more meta than using qapi to define qapi? :) Convert QType into a full-fledged[*] builtin qapi enum type, so that a subsequent patch can then use it as the discriminator type of qapi alternate types. Fortunately, the judicious use of 'prefix' in the qapi definition avoids churn to the spelling of the enum constants. To avoid circular definitions, we have to flip the order of inclusion between "qobject.h" vs. "qapi-types.h". Back in commit 28770e0, we had the latter include the former, so that we could use 'QObject *' for our implementation of 'any'. But that usage also works with only a forward declaration, whereas the definition of QObject requires QType to be a complete type. [*] The type has to be builtin, rather than declared in qapi/common.json, because we want to use it for alternates even when common.json is not included. But since it is the first builtin enum type, we have to add special cases to qapi-types and qapi-visit to only emit definitions once, even when two qapi files are being compiled into the same binary (the way we already handled builtin list types like 'intList'). We may need to revisit how multiple qapi files share common types, but that's a project for another day. Backports commit 7264f5c50cc1be0f1406e3ebb45aedcca02f603a from qemu
2018-02-20 02:45:54 +00:00
static void (*qdestroy[QTYPE__MAX])(QObject *) = {
qobject: Simplify QObject The QObject hierarchy is small enough, and unlikely to grow further (since we only use it to map to JSON and already cover all JSON types), that we can simplify things by not tracking a separate vtable, but just inline the code element of the vtable QType directly into QObject (renamed to type), and track a separate array of destroy functions. We can drop qnull_destroy_obj() in the process. The remaining QObject subclasses must export their destructor. This also has the nice benefit of moving the typename 'QType' out of the way, so that the next patch can repurpose it for a nicer name for 'qtype_code'. The various objects are still the same size (so no change in cache line pressure), but now have less indirection (although I didn't bother benchmarking to see if there is a noticeable speedup, as we don't have hard evidence that this was in a performance hotspot in the first place). A future patch could drop the refcnt size to 32 bits for a smaller struct on 64-bit architectures, if desired (we have limits on the largest JSON that we are willing to parse, and will probably never need to take full advantage of a 64-bit refcnt). Backports commit 55e1819c509b3d9c10a54678b9c585bbda13889e from qemu
2018-02-20 02:34:54 +00:00
NULL, /* No such object exists */
NULL, /* qnull_ is indestructible */
qapi: merge QInt and QFloat in QNum We would like to use a same QObject type to represent numbers, whether they are int, uint, or floats. Getters will allow some compatibility between the various types if the number fits other representations. Add a few more tests while at it. Backports commit 01b2ffcedd94ad7b42bc870e4c6936c87ad03429 from qemu
2018-03-03 22:43:24 +00:00
qnum_destroy_obj,
qobject: Simplify QObject The QObject hierarchy is small enough, and unlikely to grow further (since we only use it to map to JSON and already cover all JSON types), that we can simplify things by not tracking a separate vtable, but just inline the code element of the vtable QType directly into QObject (renamed to type), and track a separate array of destroy functions. We can drop qnull_destroy_obj() in the process. The remaining QObject subclasses must export their destructor. This also has the nice benefit of moving the typename 'QType' out of the way, so that the next patch can repurpose it for a nicer name for 'qtype_code'. The various objects are still the same size (so no change in cache line pressure), but now have less indirection (although I didn't bother benchmarking to see if there is a noticeable speedup, as we don't have hard evidence that this was in a performance hotspot in the first place). A future patch could drop the refcnt size to 32 bits for a smaller struct on 64-bit architectures, if desired (we have limits on the largest JSON that we are willing to parse, and will probably never need to take full advantage of a 64-bit refcnt). Backports commit 55e1819c509b3d9c10a54678b9c585bbda13889e from qemu
2018-02-20 02:34:54 +00:00
qstring_destroy_obj,
qdict_destroy_obj,
qlist_destroy_obj,
qbool_destroy_obj,
};
void qobject_destroy(QObject *obj)
{
assert(!obj->refcnt);
qapi: Convert QType into QAPI built-in enum type What's more meta than using qapi to define qapi? :) Convert QType into a full-fledged[*] builtin qapi enum type, so that a subsequent patch can then use it as the discriminator type of qapi alternate types. Fortunately, the judicious use of 'prefix' in the qapi definition avoids churn to the spelling of the enum constants. To avoid circular definitions, we have to flip the order of inclusion between "qobject.h" vs. "qapi-types.h". Back in commit 28770e0, we had the latter include the former, so that we could use 'QObject *' for our implementation of 'any'. But that usage also works with only a forward declaration, whereas the definition of QObject requires QType to be a complete type. [*] The type has to be builtin, rather than declared in qapi/common.json, because we want to use it for alternates even when common.json is not included. But since it is the first builtin enum type, we have to add special cases to qapi-types and qapi-visit to only emit definitions once, even when two qapi files are being compiled into the same binary (the way we already handled builtin list types like 'intList'). We may need to revisit how multiple qapi files share common types, but that's a project for another day. Backports commit 7264f5c50cc1be0f1406e3ebb45aedcca02f603a from qemu
2018-02-20 02:45:54 +00:00
assert(QTYPE_QNULL < obj->type && obj->type < QTYPE__MAX);
qobject: Simplify QObject The QObject hierarchy is small enough, and unlikely to grow further (since we only use it to map to JSON and already cover all JSON types), that we can simplify things by not tracking a separate vtable, but just inline the code element of the vtable QType directly into QObject (renamed to type), and track a separate array of destroy functions. We can drop qnull_destroy_obj() in the process. The remaining QObject subclasses must export their destructor. This also has the nice benefit of moving the typename 'QType' out of the way, so that the next patch can repurpose it for a nicer name for 'qtype_code'. The various objects are still the same size (so no change in cache line pressure), but now have less indirection (although I didn't bother benchmarking to see if there is a noticeable speedup, as we don't have hard evidence that this was in a performance hotspot in the first place). A future patch could drop the refcnt size to 32 bits for a smaller struct on 64-bit architectures, if desired (we have limits on the largest JSON that we are willing to parse, and will probably never need to take full advantage of a 64-bit refcnt). Backports commit 55e1819c509b3d9c10a54678b9c585bbda13889e from qemu
2018-02-20 02:34:54 +00:00
qdestroy[obj->type](obj);
}
qapi: Add qobject_is_equal() This generic function (along with its implementations for different types) determines whether two QObjects are equal. Backports commit b38dd678a21582e03ecd2dec76ccf8290455628a from qemu
2018-03-08 13:41:40 +00:00
static bool (*qis_equal[QTYPE__MAX])(const QObject *, const QObject *) = {
NULL, /* No such object exists */
qnull_is_equal,
qnum_is_equal,
qstring_is_equal,
qdict_is_equal,
qlist_is_equal,
qbool_is_equal,
};
bool qobject_is_equal(const QObject *x, const QObject *y)
{
/* We cannot test x == y because an object does not need to be
* equal to itself (e.g. NaN floats are not). */
if (!x && !y) {
return true;
}
if (!x || !y || x->type != y->type) {
return false;
}
assert(QTYPE_NONE < x->type && x->type < QTYPE__MAX);
return qis_equal[x->type](x, y);
}
Reference in a new issue Copy permalink