Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inline caches #3

Open
indutny opened this issue Oct 29, 2014 · 2 comments
Open

Inline caches #3

indutny opened this issue Oct 29, 2014 · 2 comments
Milestone

Comments

@indutny
Copy link
Member

indutny commented Oct 29, 2014

We need to collect type information in inline caches.

They should be stored in a Code space of heap.js. The ICs should be used only for a baseline compiler to gather the type info for optimising compiler.

@indutny indutny added this to the 1.0 milestone Oct 29, 2014
@inikulin inikulin added the jit.js label Nov 3, 2014
@inikulin
Copy link
Member

inikulin commented Nov 3, 2014

I think we should start with simple ICs without type feedback collection. Since this is quite huge task it'll be better to move step by step. At first I suggest to start with unary/binary op stubs then implement property lookup/store (it's still quite unclear for me how we will optimize here - v8 hidden classes approach or something else?).

The proposed algorithm for the first iteration (monomorphic binary/unary op ICs for Numbers without type feedback collection) is quite simple:

  1. At first we have just generic dispatching stub we go through looooong sequence of conditions and try to seek appropriate specialized stub (uninitialized state).
  2. Install specialized stub then call it (monomorphic state).
  3. In specialized stub we perform simple assertions on operand type tags. If assertion fails we fallback to generic stub. If it passes assertions then we perform type-specific operation and tag result.

So, TODOs for first iteration for me looks like this:

  • Implement tagging for all primitives.
  • Figure out how to install/bailout stubs with minimal perfomance penalty. Using call with all the call-convention juggling doesn't look like a good option. However, otherwise we will need to recompile whole scope CFG with installed stub and re-run linearscan which is definitely sucks too. Any ideas?
  • Figure out if we can create somekind of IC generator instead of hand-written approach. As I see it: we can create hand-written stubs for same type operands (e.g. Int32 and Int32) with type-conversion place-holders. Then impement type conversion stubs. So, then we hit (Int32, String) we need generate (String, String) stub and inject (Int32->String) conversion stub for first argument.
  • Implement same-type stubs for Int32 and/or Smi
  • Implement same-type stubs for Double
  • Implement conversion stubs for Numbers

Update:

  • Benchmarks, benchmarks, benchmarks!

I think this should be enough to figure out techniques and approaches which we will use later. Then we can plan second iteration.

@indutny
Copy link
Member Author

indutny commented Nov 16, 2014

Sorry, I have reversed the steps a bit and implemented first IC for GetPropertySlot operation:

43cba4b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants