yuzu-emu/unicorn
1
0
Fork 0
mirror of https://github.com/yuzu-emu/unicorn.git synced 2024-10-20 05:18:19 +02:00
Code Issues Packages Projects Releases Wiki Activity
5a66d7f326
unicorn/qemu/qobject/qobject.c

32 lines
773 B
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 03:34:54 +01: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"
#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 03:45:54 +01: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 03:34:54 +01: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 23:43:24 +01: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 03:34:54 +01: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 03:45:54 +01: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 03:34:54 +01:00
qdestroy[obj->type](obj);
}
Reference in New Issue Copy Permalink