lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] OFFSET globals
Date Mon, 23 Apr 2012 04:15:45 GMT
On Sun, Apr 22, 2012 at 8:11 AM, Nick Wellnhofer <wellnhofer@aevum.de> 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

Mime
View raw message