From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 04 Oct 2015 19:47:05 +0000 Message-ID: References: <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@[87.69.4.28]> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> <56117F37.9060808@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c262bce92ba905214ca9cb X-Trace: ger.gmane.org 1443988051 19276 80.91.229.3 (4 Oct 2015 19:47:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 19:47:31 +0000 (UTC) Cc: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 21:47:30 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZipFn-0005zn-Vl for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 21:47:28 +0200 Original-Received: from localhost ([::1]:43538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZipFn-0004vg-EI for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 15:47:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZipFf-0004ni-Gn for emacs-devel@gnu.org; Sun, 04 Oct 2015 15:47:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZipFe-0006Vi-7O for emacs-devel@gnu.org; Sun, 04 Oct 2015 15:47:19 -0400 Original-Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:34923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZipFc-0006U9-0m; Sun, 04 Oct 2015 15:47:16 -0400 Original-Received: by wicge5 with SMTP id ge5so93847372wic.0; Sun, 04 Oct 2015 12:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=CtZ4W8Z7LMBVNwW1ku/rdJ6/WyevTYBrwbkBW3PMQ2E=; b=y9nAme9RYVMnK4ANGRrwEbv9NRRND74tkI3tG1ycl1/rf2o6i0uBVTybvKXUatI5dG FaFlyjaKD+LLr9lLZz2JnY626gGLwLBGnCb88FPIw6sd0rtNsXSBaLniUTyW8IPrytMj 3yEJ2xbWOlk+ltKH+S2wduxa6Zq9Xyw5t38TiKdD+AJIrL77u41QPDjqkAdDa0PcGlfm i47IciilVcOedoVztfGQxe+s67P4iaLtkbzh5tyRT62pywgLfo8kMZPKg98ogbWY1ZXu Fz/MDBXaJCGz7ZYhMBYjAyfuEnqAoIUdNRtK4qRndWjD8WXIvT2rrNFXLMDGf+N+ISqV FsVQ== X-Received: by 10.180.211.177 with SMTP id nd17mr8382893wic.69.1443988035412; Sun, 04 Oct 2015 12:47:15 -0700 (PDT) In-Reply-To: <56117F37.9060808@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190902 Archived-At: --001a11c262bce92ba905214ca9cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Colascione schrieb am So., 4. Okt. 2015 um 21:34 Uhr: > On 10/04/2015 02:41 AM, Philipp Stephani wrote: > > > > > > > > > typedef struct emacs_value_tag* emacs_value; > > > > > > > > > I think it's important that this is a pointer to a struct (for ty= pe > > > safety and size correctness) rather than just an arbitrary type. > > > > A typedef is exactly as typesafe. The question of whether to use a > > struct or a typedef is aesthetic. I strongly prefer a typedef, just > like > > pthreads, and I believe that the people who advocate using structs > > directly are simply wrong. > > > > > > Ah, I'm not against the typedef, I'm just asking whether you would make > > it part of the API contract that it's a typedef of a struct pointer, or > > whether it can be any type. > > The problem with defining it as a pointer type is that NULL is now the > invalid sentinel value, which seems incompatible with both making this > thing literally a Lisp_Object and Qnil having all zero bits. > > That's why I strongly prefer making emacs_value a _pointer_ to a > Lisp_Object, where we store the Lisp_Object in an array owned by the > emacs_env. This way, allocating local values is very cheap. > Aur=C3=A9lien, is that something you agree with and could implement? > > > > Modules can use make_global_reference to allocate a global > > reference > > > (i.e., a GC root) for any emacs_value; modules must then free > > these > > > references explicitly. > > > > > > All routines (except make_global_reference) that return > > emacs_value > > > values return local references. It's up to modules to regist= er > > > long-lived references explicitly. > > > > > > > > > In which cases would global references be necessary? > > > > Any time you want to hold onto a lisp value outside the dynamic > extent > > of your emacs_env. > > > > > > Isn't the dynamic extent of the emacs_env the whole program, starting > > from the module initializer? > > Not necessarily. An emacs_env is valid only for the current call into > module code on the current thread. So if we call module-function-1, wait > for it to return, then call module-function-2, the two calls can have > different environments, and using local references from one might not be > valid on the other. (This approach opens up very important optimizations > in JNI, and it'd be good for us to use the same approach.) A global > reference is just an emacs_env in a heap-allocated object we register as > a GC root. > > (To answer the question another way: global references are GC roots.) > > OK, IIUC the examples in Aur=C3=A9lien's branch are then invalid because th= ey store the result of intern("nil") in a static variable, right? One more thing: is equality of two emacs_value objects defined? Right now it's `eq', but that's probably also an implementation detail. If equality is not defined as `eq', we also need a "null" function in the environment that returns bool, otherwise there would be no way to implement conditions. --001a11c262bce92ba905214ca9cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am So., 4. Okt. 2015 um 21:34=C2=A0Uhr:
On 10/04/2015 02:41 AM, Philipp Stephani wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0typedef struct emacs= _value_tag* emacs_value;
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I think it's important that this is a poin= ter to a struct (for type
>=C2=A0 =C2=A0 =C2=A0> safety and size correctness) rather than just = an arbitrary type.
>
>=C2=A0 =C2=A0 =C2=A0A typedef is exactly as typesafe. The question of w= hether to use a
>=C2=A0 =C2=A0 =C2=A0struct or a typedef is aesthetic. I strongly prefer= a typedef, just like
>=C2=A0 =C2=A0 =C2=A0pthreads, and I believe that the people who advocat= e using structs
>=C2=A0 =C2=A0 =C2=A0directly are simply wrong.
>
>
> Ah, I'm not against the typedef, I'm just asking whether you w= ould make
> it part of the API contract that it's a typedef of a struct pointe= r, or
> whether it can be any type.

The problem with defining it as a pointer type is that NULL is now the
invalid sentinel value, which seems incompatible with both making this
thing literally a Lisp_Object and Qnil having all zero bits.

That's why I strongly prefer making emacs_value a _pointer_ to a
Lisp_Object, where we store the Lisp_Object in an array owned by the
emacs_env. This way, allocating local values is very cheap.

Aur=C3=A9lien, is that something you agree with and co= uld implement?
=C2=A0

>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Modules can use make_global= _reference to allocate a global
>=C2=A0 =C2=A0 =C2=A0reference
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(i.e., a GC root) for any e= macs_value; modules must then free
>=C2=A0 =C2=A0 =C2=A0these
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0references explicitly.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0All routines (except make_g= lobal_reference) that return
>=C2=A0 =C2=A0 =C2=A0emacs_value
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0values return local referen= ces.=C2=A0 It's up to modules to register
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0long-lived references expli= citly.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In which cases would global references be nece= ssary?
>
>=C2=A0 =C2=A0 =C2=A0Any time you want to hold onto a lisp value outside= the dynamic extent
>=C2=A0 =C2=A0 =C2=A0of your emacs_env.
>
>
> Isn't the dynamic extent of the emacs_env the whole program, start= ing
> from the module initializer?

Not necessarily. An emacs_env is valid only for the current call into
module code on the current thread. So if we call module-function-1, wait for it to return, then call module-function-2, the two calls can have
different environments, and using local references from one might not be valid on the other. (This approach opens up very important optimizations in JNI, and it'd be good for us to use the same approach.) A global
reference is just an emacs_env in a heap-allocated object we register as a GC root.

(To answer the question another way: global references are GC roots.)


OK, IIUC the examples in Aur=C3=A9lien= 's branch are then invalid because they store the result of intern(&quo= t;nil") in a static variable, right?

One more= thing: is equality of two emacs_value objects defined? Right now it's = `eq', but that's probably also an implementation detail. If equalit= y is not defined as `eq', we also need a "null" function in t= he environment that returns bool, otherwise there would be no way to implem= ent conditions.
--001a11c262bce92ba905214ca9cb--