• Home
    • View
    • Login
    This page
    • Normal
    • Export PDF
    • Page Information

    Loading...
  1. Dashboard
  2. Undefined Space
  3. Multi-Language VM
  4. InterfaceInjection

Page History

Versions Compared

Old Version 6

changes.mady.by.user John Rose

Saved on Jan 24, 2009

compared with

New Version 7

changes.mady.by.user John Rose

Saved on Jan 26, 2009

  • Previous Change: Difference between versions 5 and 6
  • Next Change: Difference between versions 7 and 8
  • View Page History

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

If two types are related by inheritance, it may be best to query supertypes before subtypes. (But never Object.)

Compile-time optimizations

If interfaces are marked as being injectable or not, then the JIT would not have to emit the code for looking up the interface in the extension list if it's not injectable. To do this
the method that emits the instructions needs to have access to the klass representing the interface; this needs to be done through the ciKlass API.

Customizing code like that is usually only done by the JIT's optimizer. (Esp. the server JIT.) The interpreter can usually afford (until proven otherwise!) to use the most generic code sequences.

There are five places where interface types must be checked by the JIT:

1. invokeinterface
2. instanceof
3. checkcast
4. checkcast implicit in aastore checks
5. reflective versions of 1, 2, or 3.

In cases 1, 3, and 4, there is no strong need to customize for non-injectable interfaces, because the cost of failure is always an expensive exception, so it doesn't matter if you did a useless check of the extension records.

In case 2, there is definitely a need for a negative supertype cache in class Klass.

In case 5, if there is a JIT intrinsic which folds the reflective idiom to a non-reflective one, then it can be reduced to one of the previous cases (1,2,3). Otherwise, it is probably slow, and can be treated in full generality all the time. A possible exception is that the negative supertype cache should be consulted for reflective instanceof.

Cases 4 and 5 are interesting in that the interface type being tested against is non-constant (aastore checks against a varying array element type). In those cases, you either use full generality all the time, or use both code sequences, selected by a dynamic test for injectability.

Bottom line, per case:
1. always check for extension records
2. always use the negative cache (after fast positive tests), and customize the code in the JIT (GraphKit::gen_subtype_check)
3. customize in the JIT; negative cache buys nothing
4. customize in the JIT if possible; negative cache buys nothing
5. let the JIT do its thing for intrinsics; use the negative cache for Class.isInstance and Class.isAssignableFrom

References

  • http://blogs.sun.com/jrose/entry/interface_injection_in_the_vm
  • http://journal.thobe.org/2008/07/my-jvm-whishlist-pt-1-interface.html
Overview
Content Tools
ThemeBuilder

Terms of Use
• License: GPLv2
• Privacy • Trademarks • Contact Us

Powered by a free Atlassian Confluence Open Source Project License granted to https://www.atlassian.com/software/views/opensource-community-additional-license-offer. Evaluate Confluence today.

  • Kolekti ThemeBuilder Powered by Atlassian Confluence 8.5.23
  • Kolekti ThemeBuilder printed.by.atlassian.confluence
  • Report a bug
  • Atlassian News
Atlassian
Kolekti ThemeBuilder EngineAtlassian Confluence
{"serverDuration": 412, "requestCorrelationId": "b2c20671296a6377"}