Mailing-List: contact dev-help@lucy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucy.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4F941F97.4090504@aevum.de>
References: <4F903955.5020608@aevum.de>
	<CAAS6=7hMpzOg8xdC3=1gv5tGGyA=pcUSdXeO2sijG+heQr9AJw@mail.gmail.com>
	<4F913440.10100@aevum.de>
	<CAAS6=7gGQAyNsC+T-63zdfAzGCAc4BK8KOj4eZ_-JPdnqFTwbg@mail.gmail.com>
	<4F941F97.4090504@aevum.de>
Date: Sun, 22 Apr 2012 21:15:45 -0700
Message-ID: 
 <CAAS6=7gx3aAaVxgFdf2w5EJOXMikOVN1ymLfkfR_T37GAjGz2Q@mail.gmail.com>
From: Marvin Humphrey <marvin@rectangular.com>
To: dev@lucy.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [lucy-dev] OFFSET globals

On Sun, Apr 22, 2012 at 8:11 AM, Nick Wellnhofer <wellnhofer@aevum.de> wrot=
e:
> 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 neve=
r
>> 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 variabl=
es
> per-parcel even for included classes. Then we lookup the offsets of inclu=
ded
> 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() {
> =A0 =A0ext_Hash_fetch_OFFSET
> =A0 =A0 =A0 =A0=3D cfish_VTable_find_offset(LUCY_HASH, "Fetch");
> =A0 =A0...
> }

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 f=
or
    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 t=
wo
    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