lucy-dev mailing list archives

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

Good point.

>> 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).

Yes, at least on some platforms.

>    * 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...

This could be handled with defines:

#define Lucy_Hash_Fetch_OFFSET ext_Hash_fetch_OFFSET

>      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...

That shouldn't be a problem. We'd have to that already, because of the 
lucy_bootstrap_parcel and lucy_init_parcel functions.

> 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.

Yeah, the changes are pretty intrusive and I'm not sure if the added 
complexity is worth it.


View raw message