Skip to content

aggregating string constant/identifiers #25

@toshok

Description

@toshok

right now all strings constants (including identifiers) are created in the .data segment of the resulting executable. that way we don't pay any heap cost for their usage (yay.)

This mostly works, but there are a couple of problems with the approach:

  1. they're not aggregated across different .js files - each .js file gets its own string constants. I haven't measured how much duplication we have, but switching to es6 modules with each file in the bindings (115+ in UIKit) having their own strings.. I expect we could be saving some memory.
  2. They have a startup cost associated with them - or rather a toplevel func invocation cost. This is because we need them to be represented as ejsvals. so we generate three globals in llvm IR during compilation - an ejsval for the actual value we'll be using for a given constant, an EJSPrimString, and a ucs2 buffer. The initialization of a given constant string looks something like:
  ejs_prim_string_%1235.length = <compile-time-known-constant>;
  ejs_prim_string_%1235.data.flat = ucs2_buffer_%1235;
  ejsval_%1235 = STRING_TO_EJSVAL_IMPL(&ejs_prim_string_%1235);

it would be lovely if we could use relocs + other magic to have all this happen at link time.

Fixing 1 up there is as easy as just keeping a map during compilation and spitting out the right stuff after we've processed all the .js, similar to what we do for the require map. We could even spit it out as a .c file like the require map.. maybe the C compiler will do a better job of linking everything together without requiring runtime initialization.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions