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

    Loading...
  1. Dashboard
  2. Undefined Space
  3. HotSpot
  4. InterfaceCalls

Page History

Versions Compared

Old Version 1

changes.mady.by.user John Rose

Saved on Jul 19, 2008

compared with

New Version 2

changes.mady.by.user John Rose

Saved on Jul 19, 2008

  • Next Change: Difference between versions 2 and 3
  • View Page History

Key

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

...

It is a curious fact that the searching process described above, while currently a linear search over an array embedded in the receiver's klassOop, could also be implemented, with roughly equivalent performance, as a pointer-chasing search over a linked-list representation of implemented interfaces. Indeed, some languages use pointer chasing for dynamic lookup. The advantage of such a representation is a looser coupling between a class and its methods (or in JVM terms, its itables; an itable may contain either single methods or groups of methods). The looser coupling would allow a class to extend its implemented interfaces in a type-safe and compatible manner, just as a SmallTalk class can add new methods with a modest amount of pointer swapping.

Sample Code

Since most call sites are monomorphic, they complete very quickly; see the monomorphic sample code under VirtualCalls.

Here is a generic instruction trace of a polymorphic interface call.

No Format
titlepolymorphic call to an interface method

callSite:
    set #calledInterface, CHECK
    call #itableStub[itableSlot]
---
itableStub[itableSlot]:
    load (RCVR + #klass), KLASS_TEM
    load (KLASS_TEM + #vtableSize), TEM
    add  (KLASS_TEM + TEM), SCAN_TEM
tryAgain:
        # this part is repeated zero or more times, usually zero
	load (SCAN_TEM + #itableEntry.interface), TEM
	cmp TEM, CHECK
	jump,eq foundInterface
	test TEM
	jump,z noSuchInterface
	inc #sizeof(itableEntry), SCAN_TEM
	jump tryAgain
tryAgain:
    load (SCAN_TEM + #itableEntry.interface), TEM
    cmp TEM, CHECK
    jump,eq foundInterface
foundInterface:
    load (SCAN_TEM + #itableEntry.offset), TEM
    load (KLASS_TEM + TEM + #itableSlot), METHOD
    load (METHOD + #compiledEntry), TEM
    jump TEM
---
compiledEntry:
    ...

In all, that is six memory references and two nonlocal jumps.

Note that the intermediate "itable stub" is customized to the itable offset (which is always small and often zero). It is not customized to the interface; the call site uses the CHECK register (also used by monomorphic calls) to transmit the desired interface.

For some other approaches to reducing the cost of this operation, see Faster Interface Invocation in the Da Vinci Machine Project pages.

(The alert reader will note that updating the call site from its monomorphic state to its polymorphic state requires a two-word MP-safe transaction. This is simulated by "bungee patching", in which the target of the call is temporarily patched to a safely initialized copy of the desired call site. This extra indirection is later retracted at a safe moment, by the routine ICStub::finalize.)

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": 142, "requestCorrelationId": "ed880b6dd44784a7"}