On Sun, Apr 22, 2012 at 8:11 AM, Nick Wellnhofer <[email protected]> wrote:
> On 20/04/2012 19:44, Marvin Humphrey wrote:
>> Creating OFFSET vars for every invocant/method-name combo solved that
>> problem, though at the cost of considerable DLL symbol proliferation.
>> However, as you point out, a mechanism to propagate the offsets was never
>> introduced.
>
> OK, I see. Then I would propose the following solution: We go back to
> defining offsets only for novel methods. But we define the offset variables
> per-parcel even for included classes. Then we lookup the offsets of included
> methods by method name at run-time. We'll have to store a bit of method
> metadata to make this work. Patch 03 in LUCY-231 already goes in that
> direction.
>
> So a compiled extension would have something like the following in parcel.c:
>
> size_t ext_Hash_fetch_OFFSET;
>
> ...
>
> void
> ext_bootstrap_parcel() {
> ext_Hash_fetch_OFFSET
> = cfish_VTable_find_offset(LUCY_HASH, "Fetch");
> ...
> }
It's a provocative idea -- I definitely had not considered such an approach!
> Note that the offsets of included classes are also prefixed with "ext_", not
> "lucy_".
I think you need both prefixes: "Ext_Lucy_Hash_Fetch_OFFSET", or after
Hash moves under Clownfish, "Ext_Cfish_Hash_Fetch_OFFSET". Otherwise you
couldn't have a class named "Hash" in your extension.
> Every extension will use its own private copy. This makes it possible to
> hide the offset variables in the DLL.
OK, so this means...
* A novel method will spawn one variable for each extension, rather than one
variable for each subclass.
* Or to think of it another way, each extension will duplicate the vars for
all of its direct dependencies. (I don't believe an extension needs to
dupe the vars of indirect dependencies.)
* Lookups of OFFSET vars will not go through the GOT (global offset table).
* Generating headers suddenly get more complicated, because the content
derived from each .cfh file will be different for each target parcel!
Plus, things like METHOD and SUPER_METHOD will require parcel-specific
implementations... I think this means Lucy, which will have at least two
parcels eventually including a separate parcel for tests, will need to run
CFC multiple times and output into different dirs...
Sounds like this would be a significant improvment in terms of DSO symbol
economy over the current system.
I'm wincing at how messy CFC would have to become to pull it off, though.
Marvin Humphrey
