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: 
 <CAFAN8vygP+ZmWpxmFppt_ygB3EccAChjn_vbH2A_ubkXB1ikDw@mail.gmail.com>
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>
	<CAAS6=7gx3aAaVxgFdf2w5EJOXMikOVN1ymLfkfR_T37GAjGz2Q@mail.gmail.com>
	<4F95385B.7070701@aevum.de>
	<CAAS6=7jNC2HL4-sO_3ZOxzhCNdzOAa+LcD4aEqbj6VQxiCBeWg@mail.gmail.com>
	<CAFAN8vw1HFzBVt03b0LgoUM6q7zfkXaS8WR1hvZboxh7+bSMFw@mail.gmail.com>
	<CAAS6=7gwytH_wyXQYocVzrqxL5KFWxphk0JumuHCuNoccfLK_w@mail.gmail.com>
	<CAFAN8vxAT=Z8O_gQmGbEJxoiiWwB=8V=mF2NVFBB9zhfcGse5w@mail.gmail.com>
	<CAAS6=7gg4bESSEp5wHg-CQNTFyUaJhQWNVn3=4RVwX0--n5R1w@mail.gmail.com>
	<CAFAN8vz_2eC9zjXmW-pYFOMczgzN5-0h1KU==kvyZ3hWPC_imw@mail.gmail.com>
	<CAAS6=7i4f6_fh9SdGX6QXKax8P0ptZagawKt69kwRJ00RfB9ow@mail.gmail.com>
	<CAFAN8vxhMwXRpsnTx3iBAhunQT+pOdrBTuox73YLXa9y0DOeXQ@mail.gmail.com>
	<CAAS6=7j_bJ1c5Pimib9QYZRHBfdy7++SwTs+QDEBOHrZdBeHXQ@mail.gmail.com>
	<CAFAN8vygP+ZmWpxmFppt_ygB3EccAChjn_vbH2A_ubkXB1ikDw@mail.gmail.com>
Date: Wed, 25 Apr 2012 16:03:08 -0700
Message-ID: 
 <CAAS6=7jJfJM+OAku185kLATzyg4Q5=wpNDmUOQN7y9daNeFmvQ@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 Wed, Apr 25, 2012 at 3:27 PM, Nathan Kurz <nate@verse.com> wrote:
> Yes, very helpful. =A0That's essentially what I determined, but I got
> lost around S_bequeath_methods. =A0It's difficult reading through the
> sprintf()'s.
>
> Going one layer deeper to the object code level, which symbols are we
> currently using? I think I found where the OFFSETS come in, but I
> haven't figured out how overrides are signalled.

The output of CFC is definitely easier to understand than the code like
S_bequeath_methods() that does the work. :)  Let's look at some generated
code.

Here are TermQuery's methods:

cfish_method_t LUCY_TERMQUERY_METHODS[] =3D {
    (cfish_method_t)lucy_Obj_make,
    (cfish_method_t)lucy_Obj_get_refcount,
    (cfish_method_t)lucy_Obj_inc_refcount,
    (cfish_method_t)lucy_Obj_dec_refcount,
    (cfish_method_t)lucy_Obj_to_host,
    (cfish_method_t)lucy_Obj_clone,
    (cfish_method_t)lucy_TermQuery_destroy,
    (cfish_method_t)lucy_TermQuery_equals,
    (cfish_method_t)lucy_Obj_compare_to,
    (cfish_method_t)lucy_Obj_hash_sum,
    (cfish_method_t)lucy_Obj_get_vtable,
    (cfish_method_t)lucy_Obj_get_class_name,
    (cfish_method_t)lucy_Obj_is_a,
    (cfish_method_t)lucy_TermQuery_to_string,
    (cfish_method_t)lucy_Obj_to_i64,
    (cfish_method_t)lucy_Obj_to_f64,
    (cfish_method_t)lucy_Obj_to_bool,
    (cfish_method_t)lucy_TermQuery_serialize,
    (cfish_method_t)lucy_TermQuery_deserialize,
    (cfish_method_t)lucy_TermQuery_dump,
    (cfish_method_t)lucy_TermQuery_load,
    (cfish_method_t)lucy_Obj_mimic,
    (cfish_method_t)lucy_TermQuery_make_compiler,
    (cfish_method_t)lucy_Query_set_boost,
    (cfish_method_t)lucy_Query_get_boost,
    (cfish_method_t)lucy_TermQuery_get_field,
    (cfish_method_t)lucy_TermQuery_get_term,
    NULL
};

So, TermQuery overrides the following methods with its own "fresh"
implementations:

    Destroy        <--- Obj
    Equals         <--- Obj
    To_String      <--- Obj
    Serialize      <--- Obj
    Deserialize    <--- Obj
    Make_Compiler  <--- Query

TermQuery inherits many implementations from Obj.  It also inherits two
implementations from Query:

    Set_Boost
    Get_Boost

And then, TermQuery defines two "novel" methods of its own:

    Get_Field
    Get_Term

I wouldn't say that TermQuery "signals" to anyone that it has overridden a
method.  It's more that when somebody invokes a method on a TermQuery -- le=
t's
pick Equals() -- the caller goes to the slot indicated by
Lucy_TermQuery_Equals_OFFSET and uses whatever function pointer happens to =
be
there.  Here's the actual method invocation code:

static CHY_INLINE chy_bool_t
Lucy_TermQuery_Equals(const lucy_TermQuery *self, lucy_Obj* other) {
    char *const method_address
        =3D *(char**)self + Lucy_TermQuery_Equals_OFFSET;
    const Lucy_TermQuery_Equals_t method
        =3D *((Lucy_TermQuery_Equals_t*)method_address);
    return method((lucy_TermQuery*)self, other);
}

Note that *(char**)self is a way of getting at the first member variable of
the lucy_TermQuery struct, which is a VTable*.

The problem that Nick has been working on is how to cut down on the number =
of
OFFSET vars.  In order to guarantee that certain seemingly innocuous
refactoring actions won't break the ABI, the current release of Lucy genera=
tes
a huge number of OFFSET vars -- and they're all exposed as globals in the
DSO.  Under the new design, we will have far fewer OFFSET vars, and when th=
e
build environment supports it, they will not be visible as global symbols i=
n
the DSO.

Marvin Humphrey