Re: Dynamic loading progress

[Daniel Colascione]

On 10/14/2015 03:34 PM, Philipp Stephani wrote:
> 
> 
> Daniel Colascione <address@hidden <mailto:address@hidden>> 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 type
>     >     > 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.
> 
> 
> A simple fixed array however puts a fixed upper bound on the number of
> local values used. That might be undesirable, especially for plugins
> dealing with large data structures.

Right. That's why we have multiple such arrays, each of a pretty decent
size, linked together.

Something like this:

struct emacs_value_frame {
    Lisp_Object objects[512];
    struct emacs_value_frame* next;
};

struct emacs_env_guts {
    ...
    struct emacs_value_frame initial_frame;
    struct emacs_value_frame* current_frame;
};

We get 512 local references for free just as a side
effect of having an emacs_env, and if we need more references, we can
heap-allocate another emacs_value_frame and make it current. This way, a
reasonable number of local references is free, but if you need more, you
can have them.

This is exactly the approach Java uses.

signature.asc
Description: OpenPGP digital signature