• 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 4

changes.mady.by.user John Rose

Saved on Jan 24, 2009

compared with

New Version 5

changes.mady.by.user John Rose

Saved on Jan 24, 2009

  • Previous Change: Difference between versions 3 and 4
  • Next Change: Difference between versions 5 and 6
  • View Page History

Key

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

...

A wrapper methodOop for a method handle mh of type R(A...) could look like bytecodes for this pseudocode:

...

The meth.patch code already uses the oop-in-a-constant-pool technique for autogenerated MethodHandle.invoke methods (of which there is an infinite variety).

...

This needs a linked list search and a whole new negative logic side. As with invokeinterface, if the initial searches fail, there needs to be a backoff and upcall to the JVM, to possibly inject the interface. Since negative interface checks are too common to handle this way (via an upcall) some negative filtering needs to be put in. We could do it in a couple of ways:

  • Wiki Markup
    Interface {{klass}}esklasses which are not injectable (the vast majority) should have bits in their header which identifies them as such, so that instanceof can return false more quickly.  A good way to do this is, I think, is may be to add a second {{Klass::secondary_super_cache}} just for injectable interfaces; then the secondary_super_offset for an interface will take one of two distinct values (instead of the single value it takes today), depending on which secondary_super_cache it uses.  This simultaneously makes it easy to detect injectables (by {{secondary_super_offset == offsetof(&secondary_super_cache\[1]))}} and also allocates a word in every {{klass}} to optimize the lookup of injected interfaces.
  • (Can delay this for the POC.) Introduce a negative super type cache: Klass::secondary_non_super_cache. Use it as a first resort, to avoid upcalls on negative type tests of injectables.

...

Somehow we must record on each klass which interfaces have refused to inject. (They are the guys that show up in secondary_non_super_cache.) Probably a chunky linked list: A linked list of arrays, like the extension records above. (Or something else; I don't know. ?) The important thing is not to ask the same injection question twice; record yesses as extension records and noes as entries on the negative injection list.

...

(Can delay this a while; we'll get a GC guy to help fix it.) References to interface {{klass}}es klasses on both positive and negative sides should be weak, so that the GC can delete entries for unreachable interfaces.

...

Requires great precision to say exactly when injection requests happen, how they are resolved, and how the resolutions affect subsequent execution. The basic idea (as I see it) is to have each exact, concrete type get injected at most once, and exactly once if an (exact) instance of that type (exactly) gets an invokeinterface, checkcast, or instanceof. (Or reflective or optimized versions thereof!)

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

...

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.21
  • Kolekti ThemeBuilder printed.by.atlassian.confluence
  • Report a bug
  • Atlassian News
Atlassian
Kolekti ThemeBuilder EngineAtlassian Confluence
{"serverDuration": 296, "requestCorrelationId": "d15516576c7eae53"}