KR20160040257A - 동적 타입 어레이 객체들에 액세스할 시의 크기 의존적 타입 - Google Patents

동적 타입 어레이 객체들에 액세스할 시의 크기 의존적 타입 Download PDF

Info

Publication number
KR20160040257A
KR20160040257A KR1020167005489A KR20167005489A KR20160040257A KR 20160040257 A KR20160040257 A KR 20160040257A KR 1020167005489 A KR1020167005489 A KR 1020167005489A KR 20167005489 A KR20167005489 A KR 20167005489A KR 20160040257 A KR20160040257 A KR 20160040257A
Authority
KR
South Korea
Prior art keywords
code
value
array
attribute
inline
Prior art date
Application number
KR1020167005489A
Other languages
English (en)
Other versions
KR101872625B1 (ko
Inventor
마크 하흐넨베르그
Original Assignee
애플 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 애플 인크. filed Critical 애플 인크.
Publication of KR20160040257A publication Critical patent/KR20160040257A/ko
Application granted granted Critical
Publication of KR101872625B1 publication Critical patent/KR101872625B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F9/4431—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G06F8/4441—Reducing the execution time required by the program code
    • G06F8/4443—Inlining
    • G06F9/4443—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G06F9/449—Object-oriented method invocation or resolution
    • G06F9/4491—Optimising based on receiver type
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G06F9/4552—Involving translation to a different instruction set architecture, e.g. just-in-time translation in a JVM
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45529—Embedded in an application, e.g. JavaScript in a Web browser
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62—Details of cache specific to multiprocessor cache arrangements
    • G06F2212/621—Coherency control relating to peripheral accessing, e.g. from DMA or I/O device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Human Computer Interaction (AREA)

Abstract

동적 타입 프로그램들에 대한 객체 모델에 플랫 어레이 타입을 제공하기 위한 방법 및 장치가 기술된다. 어레이 객체가 플랫 어레이 타입의 것인지 여부가 동적 언어 기반 프로그램에 대해 동적으로 추적될 수 있다. 플랫 어레이 타입의 어레이 객체의 어레이 요소들이 어레이 객체의 객체 셀 내의 인라인 저장소에 저장될 수 있다. 인라인 저장소는 인접 객체 셀들 사이의 가용 메모리 공간에 의해 제한될 수 있다. 어레이 객체의 플랫 어레이 타입은 인라인 저장소가 어레이의 요소들을 저장할 충분한 메모리 공간을 갖는지 여부에 기초하여 검출될 수 있다. 플랫 어레이 타입의 어레이 객체는 어레이 객체의 어레이 요소들이 객체 셀에 저장된 포인터를 통한 추가 메모리 로딩 없이 객체 셀 내에 액세스되게 할 수 있다.

Description

동적 타입 어레이 객체들에 액세스할 시의 크기 의존적 타입{SIZE DEPENDENT TYPE IN ACCESSING DYNAMICALLY TYPED ARRAY OBJECTS}
관련 출원들의 상호 참조
본 출원은 2013년 8월 30일자로 출원되었고 발명의 명칭이 "RUNTIME ACCESS OF DYNAMIC OBJECTS"인 Filip Pizlo 등의 미국 가특허 출원 제61/872,386호에 관한 것이고, 그의 이익을 주장하며, 이 미국 가특허 출원은 이에 의해 전체적으로 본 명세서에 참고로 포함된다.
기술분야
본 발명은 대체로 동적 타입 데이터(dynamically typed data)에 대한 런타임 액세스들에 관한 것이다. 더 구체적으로, 본 발명은 동적 언어 기반 코드를 실행할 시의 어레이 데이터 액세스들을 최적화하는 것에 관한 것이다.
자바스크립트(JavaScript), 루비(Ruby), 파이썬(Python), 펄(Perl), 및 PHP 등과 같은 동적 언어들은 C 및 C++과 같은 정적 언어들에 대한 대체물로서 더욱 더 고려되고 있다. 동적 언어들은 프로그래머 생산성 및 상대적으로 얕은 학습 곡선과 같은 이익을 가져온다. 그러나, 동적 언어들 - 자바스크립트, 루비, 파이썬, 및 기타등등을 포함함 - 의 추가 채택에 대한 장애는, 스레드 앤드 록(threads and locks) 또는 libdispatch와 같은, 정적 언어에서 평범하게 이용가능한 고성능 공유 메모리 동시성 메커니즘(high-performance shared-memory concurrency mechanism)의 부재이다. 이러한 문제는 동적 언어에서 객체가 작동하는 방법으로 인해 다루기 어렵고, 이에 따라 해결되지 않는 것으로까지 여겨진다.
이러한 문제를 다루고자 하는 이전의 시도는 각각의 객체 액세스에 맞춰 로킹 메커니즘(locking mechanism)들을 추가하는 것을 수반했다. 로킹 메커니즘이 희망하는 동시성 의미(concurrency semantics)를 보장할 수 있지만, 그것은 너무 느리다. 로킹 앤드 언로킹은 일반 히프 액세스(heap access)보다 더 느린 크기 정도로 수행될 수 있고, 그런 이유로 엄두가 나지 않는 오버헤드를 도입한다.
또한, 종종, 인라인 캐시(inline cache, IC)가 자바스크립트 기반 코드의 고성능 구현에 사용된다. 전형적으로, 인라인 캐시는 자가 수정(self-modifying) 코드를 포함한다. 그러나, 다수의 프로세서들 상에서 실행될 수 있는 동시 자가 수정 코드는 다루기 어려우면서 느릴 수 있다. 따라서, 자바스크립트 기반 코드에 대한 인라인 캐시 기반 구현물에 동시성을 추가하는 것은 비실용적으로 비용이 많이 들 수 있다.
또한, 언어로서의 자바스크립트는 선택적 가변량(즉, 처음 16개 바이트들 직후)의 가외 메모리 인라인과 함께 메모리에서 16-바이트 셀을 통해 객체로서 표현되는 요소들의 어레이에 대한 통지를 갖는다. 자바스크립트 기반 프로그램이 그의 인라인 속성 저장소에 포함될 수 있는 것보다 더 많은 속성들을 객체에 추가하도록 실행되는 경우, 그의 추가 속성들을 저장하도록 메모리의 개별 행외 청크(out-of-line chunk)가 할당되어야 한다. 자바스크립트 어레이들은 주로 인덱싱된 속성 저장소에 사용된다. 객체에 대한 인덱싱된 속성들의 존재는 항상 행외 인덱스 속성 저장소 객체의 할당을 요구한다.
따라서, 동적 언어 기반 프로그램들을 실행하기 위한 기존의 구현물들은 효율성, 동시성, 및 효과적인 최적화가 결여되는 경향이 있다.
자바스크립트와 같은 동적 프로그래밍 언어들로부터 생성된 코드가 런타임 동안에 데이터 액세스들에 대한 동시 실행을 허용하는 증강된 객체 모델을 포함할 수 있다. 인덱스 구조가 객체의 속성 또는 필드 값들을 저장하는 타입 구조 및 데이터 페이로드뿐만 아니라 동적 타입 객체를 표현하는 객체 모델에 도입될 수 있다. 인덱스 구조의 요소들은 객체에 액세스하기 위한 간접접근으로서 대응하는 속성 값들을 가리킬 수 있다.
일 실시예에서, 동적 타입 프로그램 코드(예컨대, 소정 알고리즘을 구현함)가 레이스 상태들을 생성하는 일 없이 객체의 인덱스 구조에 걸쳐서 추가 간접접근을 통해 객체의 단일 속성 값에 대한 각각의 액세스 동작을 동시에 수행하도록 허용될 수 있다. 객체의 단일 속성 값에 대한 각각의 액세스(예컨대, 로딩/저장) 동작이 다수의 명령어들 및/또는 원자적 동작들을 요구할 수 있다. 동시 실행 동안에, 이러한 다수의 명령어들은 비동기화된 방식으로 인터리빙되도록 허용될 수 있다.
다른 실시예에서, 단일 스레드에서의 동적 타입 객체들에 액세스하기 위한 인라인 캐시 초기화가 불필요한 동기화 오버헤드를 유발하는 일 없이 인터프리터로 오프로드될 수 있다. 스레드 바이어스 메커니즘이, 코드 블록이 단일 스레드에서 실행되는지 여부를 검출하도록 제공될 수 있다. 또한, 베이스라인 JIT 컴파일러와 같은 컴파일러를 통해 수행된 인라인 캐시 초기화의 수가 감소되어 프로세싱 성능을 개선할 수 있다.
다른 실시예에서, 다수의 스레드들에 의해 공유되는 코드 블록들에서의 인라인 캐시 초기화는 실행가능 코드를 초기화로 업데이트하기 위해 요구되는 프로세서 동기화(예컨대, 라이트 포인트(light point)들)의 발생을 감소시키도록 지연 및 타이밍될 수 있다. 예를 들어, 각각의 스레드는 런타임 동안에 버퍼 내에 초기화된 코드를 저장할 수 있다. 버퍼가 요구되는 프로세서 동기화로 비어 있지 않는 한, (예컨대, 특수한 스레드를 통한) 라이트 포인트 타이머는 모든 인라인 캐시들이 주기적으로(예컨대, 매 10 ms마다) 초기화(예컨대, 런타임에 대해 업데이트)되게 할 수 있다. 그 결과, 인라인 캐시 초기화에 요구되는 값비싼 또는 느린 동기화 동작들의 작동 수가 감소될 수 있다.
다른 실시예에서, 어레이들 내의 요소들의 개수는 동적 언어 기반 프로그램의 실행 동안에 추적될 수 있거나, 또는 그들은 프로그램의 소스 코드로부터 정적으로 가정될 수 있는데, 이는 런타임이 향후 할당되는 요소 어레이들을 얼마나 많이 가져야 하는지 추론하게 한다. 플랫 어레이 타입의 어레이 객체의 어레이 요소들은 어레이 객체를 표현하도록 할당된 객체 셀 내의 선택적 인라인 저장소에 저장될 수 있다. 객체 셀 내의 인라인 저장소는 메모리에 할당된 인접 객체 셀들 사이의 가용 메모리 공간에 의해 제한될 수 있다. 객체의 플랫 어레이 타입은 객체가 어레이를 표현하는지 여부 그리고 객체 셀의 인라인 저장소가 어레이의 요소들을 저장할 충분한 메모리 공간을 갖는지 여부에 기초할 수 있다. 플랫 어레이 타입의 어레이 객체는 객체 셀에 저장된 포인터를 통한 추가 메모리 로딩 없이 어레이 객체의 어레이 요소들이 객체 셀 내에 액세스되게 할 수 있다. 또한, 플랫 어레이 타입을 지원하는 실행가능 코드를 생성하는 컴파일러의 타입 시스템은 컴파일러가 플랫 어레이 타입에 기초하여 코드 최적화를 수행하게 할 수 있다.
본 발명의 다른 특징들이 첨부 도면 및 다음의 상세한 설명으로부터 자명할 것이다.
본 발명이 첨부 도면의 도면들에 제한이 아닌 예로서 도시되며, 도면에서 유사한 도면 부호는 유사한 요소를 지시한다.
도 1은 네트워킹된 디바이스들로부터 검색된 동적 언어 기반 소스 코드들에 대한 예시적인 실행 런타임을 도시한 네트워크 다이어그램이고;
도 2는 동적 타입 객체들에 액세스하기 위한 동시 및/또는 최적화된 실행을 위한 시스템의 일 실시예를 도시한 블록 다이어그램이고;
도 3은 공통의 동적 타입 객체들을 공유하는 다수의 실행 스레드들을 위한 하나의 예시적인 런타임을 도시한 블록 다이어그램이고;
도 4는 동시 실행을 통해 공유되는 동적 타입 객체의 예시적인 할당을 도시하고;
도 5는 동적 타입 객체에 액세스하기 위한 동시 실행가능 명령어들을 생성하는 프로세스의 일 실시예를 도시한 흐름도이고;
도 6은 인덱스 레퍼런스를 갖는 객체 모델에 기초하여 객체의 속성 값들에 동시에 액세스하는 프로세스의 일 실시예를 도시한 흐름도이고;
도 7a 및 도 7b는 동시 실행을 위해 인라인 캐싱된 코드 블록들을 최적화하는 런타임 시스템을 도시한 블록 다이어그램들이고;
도 8은 인라인 캐시 코드들을 갖는 코드 블록들을 동적으로 컴파일하기 위한 동시 실행의 예시적인 타임 라인들을 도시하고;
도 9는 동시 실행을 위해 동적 타입 객체에 액세스하도록 인라인 코드들을 자가 수정하는 프로세스의 일 실시예를 도시한 흐름도이고;
도 10은 인덱스 레퍼런스를 갖는 객체 모델에 기초하여 객체의 인라인 캐시 동시 액세스 속성 값들을 갖는 함수 코드 블록을 동적으로 컴파일하는 프로세스의 일 실시예를 도시한 흐름도이고;
도 11은 플랫 어레이 객체들을 위해 인라인으로 저장된 어레이 데이터를 지원하는 객체 모델들의 예들을 도시하고;
도 12는 동적 프로그래밍 언어에서 지정된 객체 데이터 액세스를 최적화하기 위해 어레이 데이터를 인라인으로 동적으로 할당하는 시스템의 일 실시예를 도시한 블록 다이어그램이고;
도 13은 어레이 데이터를 인라인으로 할당하도록 코드를 동적으로 컴파일하는 프로세스의 일 실시예를 도시한 흐름도이고;
도 14는 인라인으로 할당된 플랫 어레이들을 통해 객체들에 반복적으로 액세스하기 위한 명령어들을 생성하도록 런타임 동안에 플랫 어레이 데이터 타입을 식별하는 프로세스의 일 실시예를 도시한 흐름도이고;
도 15는 본 명세서에 기술되는 실시예들과 연동하여 사용될 수 있는, 컴퓨터 시스템과 같은 데이터 프로세싱 시스템의 일례를 도시한다.
동적 타입 객체들을 공유하고, 동적 타입 데이터에 액세스하기 위한 인라인 캐시 코드를 최적화하고, 동적 타입 객체들 내의 어레이 데이터를 최적화하기 위한 방법들 및 장치들이 본 명세서에 기술된다. 하기의 설명에서, 많은 구체적인 상세사항이 본 발명의 실시예의 완벽한 설명을 제공하기 위해 기재된다. 그러나, 본 발명의 실시예가 이들 구체적인 상세사항 없이도 실시될 수 있음이 당업자에게 자명할 것이다. 다른 경우에, 주지된 컴포넌트, 구조, 및 기법은 본 설명의 이해를 어렵게 하지 않도록 상세히 나타내지 않았다.
본 명세서에서의 "하나의 실시예" 또는 "일 실시예"에 대한 언급은 그 실시예와 관련하여 기술된 특정한 특징, 구조, 또는 특성이 본 발명의 적어도 하나의 실시예에 포함될 수 있음을 의미한다. 본 명세서 내의 여러 곳에 나오는 문구 "일 실시예에서"는 반드시 모두 동일한 실시예를 언급하는 것은 아니다.
뒤따르는 도면에 묘사된 프로세스들은 하드웨어(예컨대, 회로, 전용 로직 등), (범용 컴퓨터 시스템 또는 전용 기계 상에서 구동되는 것과 같은) 소프트웨어, 또는 양측 모두의 조합을 포함하는 프로세싱 로직에 의해 수행된다. 프로세스들이 몇 개의 순차적 동작들의 관점에서 하기에 기술되지만, 기술된 동작들 중 일부는 상이한 순서로 수행될 수 있음이 이해되어야 한다. 또한, 일부 동작들은 순차적인 대신에 동시에 수행될 수 있다.
도 1은 네트워킹된 디바이스들로부터 검색된 동적 언어 기반 소스 코드들에 대한 예시적인 실행 런타임을 도시한 네트워크 다이어그램이다. 일 실시예에서, 네트워크 시스템(100)은 클라이언트 디바이스에서 실행되는 클라이언트 애플리케이션(105)을 위해 이용가능한 콘텐츠를 제공하도록 하나 이상의 서버 디바이스들에서 호스팅되는 하나 이상의 서버 애플리케이션들, 예컨대 서버 애플리케이션(101)을 포함할 수 있다. 예를 들어, 서버 애플리케이션(101)은 웹 서버일 수 있고, 클라이언트 애플리케이션(105)은 웹 브라우저일 수 있다. 서버(101)와 클라이언트(105)는, 예를 들어 HTTP(Hypertext Transport Protocol)와 같은 인터넷 프로토콜들 또는 다른 적용가능한 프로토콜들에 기초하여, 네트워크(103)를 통해 서로 통신할 수 있다.
일 실시예에서, 서버(101)로부터 검색된 콘텐츠는 하이퍼텍스트 언어들, 예컨대 HTML(Hypertext Markup Language), XML(Extensible Markup Language), 또는 자바스크립트, 루비, 파이썬 또는 다른 동적 타입 언어와 같은 동적 프로그래밍 언어에 임베드되거나 그의 소스와 링크(예컨대, 하이퍼링크)되는 다른 마크업 언어에 기초한 웹 페이지들을 포함할 수 있다. 클라이언트(105)는 실행을 위해 링크된 소스들을 동적으로 다운로드하거나 페치(fetch)할 수 있다. 일 실시예에서, 클라이언트(105)는, 예를 들어 다수의 실행 스레드들 및/또는 다수의 프로세서들 또는 프로세싱 유닛들을 포함하는, 동시 실행 환경에서의 성능을 개선하기 위해 코드 실행을 최적화하도록 다운로드된 소스들을 동적으로 컴파일할 수 있다.
도 2는 동적 타입 객체들에 액세스하기 위한 동시 및/또는 최적화된 실행을 위한 시스템의 일 실시예를 도시한 블록 다이어그램이다. 일 실시예에서, 시스템(200)은 하나 이상의 프로세서들에 의해 호스팅되는, 도 1의 클라이언트 애플리케이션(105)을 호스팅하는 운영 체제와 같은 운영 환경(201)을 포함할 수 있다. 운영 환경(201)은, 예컨대 JIT(Just-In-Time) 컴파일에 기초하여, 런타임 동안에 소스 코드(203)를 실행가능 코드(215)에 동적으로 그리고/또는 연속적으로 컴파일하는 컴파일러(205)를 포함할 수 있다.
소스 코드(203)는 자바스크립트, 루비, 파이썬, 또는 다른 적용가능한 동적 타입 언어와 같은 동적 프로그래밍 언어의 프로그램들을 포함할 수 있다. 소스 코드(203)는 코드 구문에서 레퍼런스되는 데이터 또는 객체들의 타입 또는 형상을 지정하거나 선언하지 않을 수 있다. 일 실시예에서, 소스 코드(203)는 운영 환경(201)에서 실행되는 브라우저 애플리케이션 또는 다른 적용가능한 애플리케이션에 의해 원격 디바이스로부터, 예컨대 도 1의 서버(101)로부터 검색될 수 있다. 컴파일 모듈(205)은 브라우징 동작들을 수행하도록 브라우저 애플리케이션에 의해 제어될 수 있다.
컴파일러(205)는 소스 코드(203)로부터 실행가능 코드(215)를 생성할 수 있다. 일 실시예에서, 컴파일러(205)는 소스 코드(203)에서 지정된 데이터 프로세싱 동작들을 수행하기 위해 중간 코드, 바이트코드, 또는 다른 적용가능한 컴파일 코드를 방출하도록 소스 코드(203)를 정적으로 또는 동적으로 파싱할 수 있다. 컴파일러(205)는 동시 실행을 가능하게 하도록 동적 타입 객체들을 표현하는 객체 모델들을 제공할 수 있다. 예를 들어, 객체 모델들은 다중 프로세서 환경에서 다수의 실행 스레드들 또는 다수의 실행 프로세스들 사이에서의 공통의 객체들의 공유를 허용하는 객체 값들에 대한 간접 레퍼런스들을 포함할 수 있다.
일 실시예에서, 최적화된 인라인 캐시 코드 생성기 모듈(207)은 다수의 실행 스레드들에 의해 공유되는 동적 타입 객체들에 액세스(예컨대, 판독, 기록, 업데이트 등)하기 위한 인라인 캐시 코드를 방출할 수 있다. 방출된 인라인 캐시 코드는 값비싼 프로세서 명령어 동기화 없이 동시 실행을 위한 최적화된 런타임 바인딩(runtime binding)을 지원할 수 있다. 방출된 코드는, 예를 들어 인라인 캐시 코드를 초기화하도록, 실행되고 있는 동안에 자신의 명령어들을 변경할 수 있는 자가 수정 코드를 포함할 수 있다.
일 실시예에서, 동시 코드 실행 모듈(217)은 컴파일러(205)를 통해 생성된 코드에 기초하여 동작들을 수행하는 인터프리터(213)를 작동시킬 수 있다. 예를 들어, 인터프리터(213)는, 명령어 캐시 플러시(flush)를 활성화시켜서 상이한 프로세서들 사이에서 명령어들을 동기화시키는 일 없이, 컴파일러(205)를 통해 방출된 자가 수정 명령어들에 따라 바이트코드들을 업데이트할 수 있다. 일부 실시예들에서, 명령어 캐시 플러시 모듈(219)은, 예를 들어 전용 스레드를 통해, 명령어 캐시 플러시를 주기적으로 작동시킬 수 있다.
소정 실시예들에 따르면, 컴파일러(215)는 어레이 데이터 프로세싱을 최적화하기 위해 런타임 동안에 특수한 타입(예컨대, 플랫 어레이 타입)의 동적 타입 데이터를 식별할 수 있는 실행가능 코드를 제공하는 최적화된 어레이 객체 핸들러 모듈(209)을 포함할 수 있다. 그 결과, 동시 코드 실행 모듈(217)을 통한 어레이 객체들의 반복 프로세싱이 정적 타입 어레이 데이터 타입(예컨대, 어레이 데이터 프로세싱을 최적화하는 사전 지정된 어레이 타입)과 컴파일된 유사한 동작들에 대한 명령어들을 실행하는 것과 비슷한 실행 성능을 달성할 수 있다.
동시 코드 실행 모듈(217)은, 값비싼 소프트웨어 기반 록/언록 메커니즘에 의존하는 일 없이, 동기화된 업데이트 동작들을 수행하도록 실행가능 코드(215)에 기초하여 원자적 비교 및 스왑(atomic compare and swap, ACS) 핸들러 모듈(221)을 작동시킬 수 있다. ACS 핸들러 모듈(221)은 (예컨대, 하나의 프로세서 명령어 사이클 내에서) 인터럽트 없이 원자적 업데이트(atomic update) 동작이 수행되는 것을 보장하도록 프로세서 하드웨어 로직을 통해 직접적으로 지원될 수 있다.
일 실시예에서, 프로그램(예컨대, 실행가능 코드(217))이 실행되고 있으면서, 프로그램 또는 실행가능 코드 내의 변수들에 대한 런타임 값들의 타입들이 런타임 동안에 식별 및 프로파일링(예컨대, 분석, 요약 등)될 수 있다. 과거 실행 이력을 통해 식별된 타입들에 기초하여, 런타임 값들의 향후 타입들이 예측되어, 타입 예측을 활용하여 프로그램 또는 코드 중 일부분을 대체하도록 프로그램을 업데이트하거나 리컴파일하게 할 수 있다.
예를 들어, 프로파일링 데이터(예컨대, 런타임 동안에 데이터 또는 객체들의 타입들을 나타냄)가 런타임 데이터(211)에 수집될 수 있다. 컴파일러(205)는 프로파일링 데이터에 기초하여 리컴파일을 통해 실행가능 코드(215)를 지속적으로 최적화할 수 있다. 프로파일링 코드는 실행가능 코드(215) 내에 임베드되어 런타임 동안에 프로파일링 데이터의 수집을 가능하게 할 수 있다.
동적 타입 객체들에 대한 동시 액세스
일 실시예에서, 동시 객체 모델들은, 메모리 히프들을 손상시키는 일 없이, 동적 타입 객체에 액세스(예컨대, 판독, 기록, 업데이트 등)하는 데 필요한 다수의 기계 명령어들의 동시 실행을 허용하도록 제공될 수 있다. 객체는 하나 이상의 필드들 또는 속성들을 포함할 수 있다. 동적 타입 객체의 필드들 또는 속성들은 실행가능 코드를 통해 처음 할당될 때 런타임 동안에 나타날 수 있다. 실행가능 코드에 대응하는 동적 언어 기반 소스 프로그램 또는 코드가 객체의 모든 필드들의 우선 선언(up front declaration)들을 포함하는 것은 아닐 수 있다. 객체는 복잡한 데이터 구조(또는 형상)로 표현될 수 있다. 객체에의 각각의 액세스는 다수의 기계 명령어들을 실행시키는 것을 포함할 수 있다.
동시 객체 모델들은 속성 인덱스들을 포함하여, 가외의 동기화를 통한 조정(coordination)을 요구하는 일 없이, (예컨대, 다중프로세서 환경에서) 다수의 실행 스레드들(또는 프로세스들)로부터 인터리빙된 다수의 기계 명령어들을 통한 레이싱 메모리 액세스(racing memory access) 또는 공통의 객체에의 동시 액세스를 허용하게 할 수 있다. 객체에의 액세스의 결과는 이러한 명령어들이 인터리빙되는 방법의 순서와는 무관하게 일관될 수 있다. 따라서, 동시 객체 모델은 다수의 명령어들을 통한 원자적 액세스를 가능하게 할 수 있는데, 각각의 명령어는 원자적 실행의 단일-기계-명령어 속성을 갖는다. 따라서, 동시 객체 모델은 레이싱 메모리 액세스들이 히프 손상 없이 (예컨대, 이러한 액세스 동작들의 의미에 따라) 일관되고 명확하게 동적 타입 객체를 동시에 판독, 기록, 및 업데이트하게 할 수 있다.
소정 실시예들에 따르면, 객체는 셀 및 페이로드를 통해 표현될 수 있다. 셀은 구조 및 페이로드에 대한 레퍼런스들을 포함할 수 있다. 예를 들어, 셀은 구조를 식별하는 구조 식별자 및 페이로드가 저장되는 장소를 가리키는 페이로드 포인터를 포함할 수 있다. 구조는 객체가 어떤 필드들 또는 속성들을 갖는지 그리고 그러한 필드들의 어떤 인덱스들이 페이로드 내에 있는지 나타낼 수 있다. 일부 실시예들에서, 구조는 필드들을 표현하는 속성명들의 세트를 포함할 수 있다. 페이로드는 그러한 필드들의 값들(또는 속성 값들)을 포함할 수 있다.
동시 객체 모델에 기초하여 동적 타입 객체를 표현하는 셀의 예시적인 할당은 다음을 포함할 수 있다:
struct Cell
{
int structure;
Value **index;
};
여기서, Cell.Value은 정수, 또는 객체에 대한 다른 적용가능한 속성 값들 또는 필드 값들을 표현할 수 있다. Cell.structure는 객체의 구조에 대한 정수 레퍼런스일 수 있다. Cell.structure의 공통 값을 공유하는 2개의 객체들은 그러한 2개의 객체들이 동일한 동적 타입 또는 형상의 것임을 나타낼 수 있다. 일 실시예에서, Cell.structure는 상이한 타입의 동적 구조들을 표현하는 테이블에 대한 인덱스를 표현할 수 있다.
Cell.index는 객체의 페이로드 또는 속성 값들에 대한 간접 레퍼런스를 포함할 수 있다. 일 실시예에서, Cell.index는 하나의 간접 층을 제공하여, 일관되지 않은 데이터 액세스 결과들을 갖는 레이싱 상태들을 야기하는 일 없이, 객체의 페이로드가 객체 데이터(예컨대, 속성 값들)의 동시 액세스를 위해 동적으로 성장하게 할 수 있다. 인덱스 자체는 필드 오프셋들을 통해 인덱싱된 어레이를 포함할 수 있고, 실제 필드 값들(또는 속성 값들)에 대한 포인터들을 내부에 포함한다.
일 실시예에서, Cell.index는 객체 데이터 액세스에서의 불변량으로서 불변 필드 레퍼런스들 또는 값들을 포함할 수 있다. 객체의 필드 값들이 변화할 수 있지만, 객체를 표현하는 객체 셀은 필드 값들에 대한 불변 레퍼런스들을 포함할 수 있다. 동시 객체 액세스는 동기화 비용 없이 구현될 수 있다.
예를 들어, 객체에 액세스하기 위한 전형적인 객체 판독 프로그램 구문(예컨대, 객체 o의 속성 f를 판독하는 v = o.f)은 인라인 캐시 최적화와 함께 하기의 동작들(예컨대, 컴파일러에 의해 발생됨)로 수행될 수 있다:
if (o->structure == ExpetedStructure)
v= *(o->index[OffsetOfF]);
else
v = SlowPathRead(o);
SlowPathRead()는, 예를 들어 객체의 동적 구조 또는 형상에 걸쳐서 테이블 룩업 또는 해시 동작들을 통해, 객체의 속성 또는 필드 값을 분해 또는 위치시키는 실행을 포함하는 객체 판독 루틴을 표현할 수 있다. ExpectedStructure는 이미 분해된 오프셋 값 OffsetOfF를 갖는 런타임 동안에 이전에 조우된 객체 타입을 표현할 수 있다.
객체에 액세스하기 위한 전형적인 객체 기록 프로그램 구문(예컨대, 값 v를 갖는 객체 o의 속성 f를 업데이트하는 o.f = v)은 객체(예컨대, o)가 레퍼런스된 필드(예컨대, f)를 이미 갖고 있는지 여부에 따라 상이하게 컴파일될 수 있다. 자바스크립트와 같은 동적 언어들에서의 객체들이 우선적으로 사전 선언된 그들의 필드들을 가져야 하는 것은 아니기 때문에, 런타임 동안의 임의의 시간에 새로운 필드를 동적으로 생성하는 객체 기록을 수행하는 것은 보편적일 수 있다. 마찬가지로, 다른 긴요한 프로그래밍 언어들에서와 같이, 객체의 기존 필드들의 필드 값들을 오버라이트하는 것은 보편적이다.
일 실시예에서, 이미 존재하는 필드에 기록하는 객체에의 기록 액세스(예컨대, o.f = v)에 대한 경우(예컨대, 객체 o의 기존 필드 f에 값 v를 기록하는 o.f = v)는 하기의 동작들, 예컨대 ExistingWrite()를 통해 수행될 수 있다:
if (o->structure == ExpetedStructure)
*(o->index[OffsetOfF]) =v;
else
SlowPathWrite(o,v);
ExistingWrite()는, 예를 들어 원자적 기계 명령어를 통해 Cell.index를 통한 간접접근(indirection)(예컨대, 포인터로 포인터를 로딩함)을 포함할 수 있다. Cell.index에서의 포인터의 값은 필드 값들이 변경되는 경우에도 불변 상태로 유지될 것을 보장받을 수 있다. SlowPathWrite()는 SlowPathRead()와 유사한 객체의 필드 값을 분석하는 실행을 포함하는 객체 기록 루틴을 표현할 수 있다.
존재하지 않는 필드에 기록하는 객체에의 기록 액세스(예컨대, o.f = v)에 대한 경우는 하기의 동작들, 예컨대 AdditiveWrite()를 통해 수행될 수 있다:
if (o->structure == ExpetedStructure)
{
Value** oldIndex = o->index;
Value** newIndex = reallocateIndex(oldIndex);
newIndex[OffsetOfF] = new Value(v);
if(!CAS(&o->structure,&o->index,ExpectedStructure,
oldIndex,NewStructgure, newIndex))
SlowPathWrite(o,v);
}
Else
SlowPathWrite(o,v);
일 실시예에서, AdditiveWrite()는 (예컨대, 객체의 구조 및 페이로드를 표현하는) Cell.strucutre 및 Cell.index가 CAS() 동작과 같은 하나의 원자적 동작으로 동시에 변경되는 것을 보장할 수 있다.
CAS(compare and switch) 동작은 인터럽트 없이 원자적으로 비교 동작 및 스위치 동작 양측 모두의 완료를 보장하는 하드웨어 또는 프로세서 지원 루틴일 수 있다. 일 실시예에서, 2개의 단어들이 메모리에서 인접하게 위치되어 있다면, CAS 동작은 객체의 구조(예컨대, Cell.structure) 및 인덱스(예컨대, Cell.index) 양측 모두를 동시에 변경하도록 원자적인 2개의 단어들일 수 있다.
인덱스의 Value* 엔트리들은, 엔트리들에 의해 레퍼런스되는 임의의 필드 값들을 복제하는 일 없이, 'reallocateIndex()'를 통해 AdditiveWrite()에 복제될 수 있다. 추가 필드 값 또는 밸류 박스(Value box)는 객체에 대한 하나의 필드 또는 속성 값을 보유하도록 'new Value()'를 통해 메모리 내에 할당될 수 있다. 값 v는 이러한 새롭게 할당된 밸류 박스 내에 저장될 수 있다.
일 실시예에서, 동시 객체 모델에 기초하여 객체의 필드를 삭제하기 위한 객체에의 액세스는 객체의 인덱스(예컨대, Cell.index)가 불변 포인터들을 포함한다는 것을 보장할 수 있다. 필드들의 반복 삭제는 객체가 객체 액세스에 대한 최적화가 비활성화될 수 있는 플레인 해시테이블(plain hashtable)이 되도록 강제할 수 있다. 예를 들어, 동시 객체 모델은 객체가 플레인 해시테이블이 되기 전에 객체의 삭제된 필드가 추가된 경우에 삭제된 필드의 메모리를 회수하지 않을 수 있다. 일단 객체가 (예컨대, 해시테이블 모드에서) 해시테이블이 되면, 객체에의 액세스들은 다수의 액세스들을 동기화시키기 위한 객체별 록(per-object lock)을 이용할 수 있다. 소정 실시예들에서, 폐영역 수집 메커니즘(garbage collection mechanism)이 더 이상 사용되지 않거나 비활성 상태인 객체 인덱스들을 압축 또는 회수할 수 있다.
도 3은 공통의 동적 타입 객체들을 공유하는 다수의 실행 스레드들을 위한 하나의 예시적인 런타임을 도시한 블록 다이어그램이다. 런타임(301)은 도 2의 시스템(200)과 연관될 수 있다. 예를 들어, 런타임(301)은 도 2의 런타임 데이터(211) 중 일부를 포함할 수 있다. 일 실시예에서, 공유된 히프(303)는 다수의 스레드들 또는 프로세스들, 예컨대 Thread1(315), Thread2(317), 또는 하나 이상의 프로세서들을 통한 다른 적용가능한 스레드들 또는 프로세스들을 통해 공유되는 런타임 데이터 또는 객체들을 포함할 수 있다.
예를 들어, Thread1(315)과 Thread2(317) 사이에 공유되는 동적 타입 객체 O(319)는 객체 셀(307)에 대응할 수 있다. 객체 O(319)는 구조(305) 및 하나 이상의 속성 값(311, 313 등)을 통해 표현되는 동적 속성들을 가질 수 있다. 구조(305)는 객체 O(319)의 동적 타입을 지정할 수 있다. 예를 들어, 구조(305)는 동적 속성들의 속성명들, 및 대응하는 속성 값들을 위치시키는 위치 정보, 예컨대 메모리 오프셋들을 포함할 수 있다.
객체 셀(307)은 직접 또는 간접 포인터들을 통해 그의 속성들을 레퍼런스할 수 있다. 예를 들어, 객체 셀(307)은 구조(305)를 가리키는 직접 포인터들, 및 인덱스들(309)을 통한 속성 값들(311, 313)에 대한 간접 포인터를 포함할 수 있다. 인덱스들(309)은 포인터들의 어레이를 저장할 수 있는데, 포인터 각각은 하나의 속성 값(또는 속성 저장소)을 가리킨다. 구조(305) 내의 속성 값 각각에 대한 위치 정보는 인덱스들(309)의 포인터 어레이에 대한 인덱스에 대응할 수 있다.
객체 O(31)에 액세스하기 위한 동작들은 Thread1(315) 및 Thread2(317)를 통해 동시에 수행될 수 있다. 객체 액세스 동작들은 Read(), ExistingWrite(), AdditiveWrite() 및/또는 Delete() 등을 포함할 수 있다. 객체 액세스 동작 각각은 하나 초과의 원자적 기계 명령어를 요구할 수 있다. 동시 객체 모델은, 기존 속성 값들(311, 313)을 복제하여 속성 값들의 복제와 속성 값들의 업데이트 사이에서의 레이스 상태들을 회피시키는 일 없이, 추가 속성들을 객체 O(319)에 추가하는 것을 허용할 수 있다.
도 4는 동시 실행을 통해 공유되는 동적 타입 객체의 예시적인 할당을 도시한다. 일례(400)는 도 2의 시스템(200)의 일부 컴포넌트들에 기초할 수 있다. 예를 들어, 객체 O(403)는 도 2의 런타임 데이터(211)에서 할당될 수 있다. 시간 인스턴스 T1(423)에서, 객체 O(403)는 대응하는 속성 값들 10, 12 및 8과 함께 구조(401)에 나타낸 속성(E, F, G)을 가질 수 있다. 객체 O(403)는 속성 값들을 가리키는 포인터들을 갖는 포인터 어레이를 저장하는 인덱스들(405)을 레퍼런스할 수 있다.
일 실시예에서, 구조(401)는 각각의 속성(예컨대, E, F, 또는 G)에 대한 오프셋을 지정하여, 대응하는 속성 값에 대한 인덱스들(405) 내에 포인터를 위치시키게 할 수 있다. 예를 들어, 2의 오프셋은 구조(401)에서 속성 F에 대해 식별되어, 속성 값 12를 저장하는 속성 저장소(411)를 가리키는 오프셋 2에 포인터를 위치시키게 할 수 있다. 시간 T1(423)에서 객체 O(403)는 (E:10, F:12, G:8)와 같은 이름-값 쌍들(또는 필드 값들)에 대응하는 동적 속성을 가질 수 있다.
스레드들 T1 및 T2(409)는, 록, 임계 섹션 등과 같은 소프트웨어 동기화 메커니즘들을 채용하는 일 없이, 객체 O(403)에 동시에 액세스할 수 있다. 예를 들어, 스레드 T1은 (예컨대, ExistingWrite()를 통해) 프로그램 구문 o.f = 3을 수행하여 속성 F를 값 3으로 업데이트하게 할 수 있다. 동시에, 스레드 T2는 (예컨대, AdditiveWrite()를 통해) 프로그램 구문 o.h = 5를 수행하여 객체 O(403)에 값 5를 갖는 새로운 속성 H를 추가하게 할 수 있다.
T1 및 T2의 동시 실행(409)의 결과로서, 객체 O(403)는 개별 구조(413) 및 개별 인덱스들(415)과 연관되어, 새롭게 추가된 속성(또는 특질, 필드) H를 수용하도록 그의 구조를 동적으로 성장시킬 수 있다. 구조(413)는 (이전) 구조(401)의 복제본 및 새롭게 추가된 속성 H의 특질들을 포함할 수 있다. 인덱스들(415)은 (이전) 인덱스들(415)의 복제본, 및 속성 값 5를 저장하는 새롭게 할당된 속성 저장소(421)에 대한 포인터를 포함할 수 있다. 다시 말해, 객체 O(403)의 구조는 구조(401)로부터 구조(413)로 재할당될 수 있고, 객체 O(403)의 인덱스들은 인덱스들(405)로부터 인덱스들(415)로 재할당될 수 있다.
기존 속성 값들에 대한 속성 저장소들, 예컨대 속성 E에 대한 속성 저장소(419)는 불변 상태로 유지된다. 속성 저장소(411)는 속성 F에 대한 속성 값 3으로 업데이트된다. 기존 속성 값들이 동일한 속성 저장소에 저장된 상태로 유지됨에 따라, 속성 값들을 업데이트하고 재위치시키는 레이스 상태들이 회피될 수 있다.
도 5는 동적 타입 객체에 액세스하기 위한 동시 실행가능 명령어들을 생성하는 프로세스의 일 실시예를 도시한 흐름도이다. 예시적인 프로세스(500)는, 예를 들어 도 2의 시스템(200)의 일부 컴포넌트들을 포함하는 프로세싱 로직에 의해 수행될 수 있다. 블록(501)에서, 프로세스(500)의 프로세싱 로직은 런타임 동안에 메모리에 객체 모델을 제공하여, 자바스크립트와 같은 동적 프로그래밍 언어로 소스 코드에서 지정된 동적 타입 객체를 표현할 수 있다. 소스 코드는 객체에 대한 타입 또는 구조를 선언하는 일 없이 객체를 지정하는 구문들을 포함할 수 있다.
객체 모델은 소스 코드에서 지정되거나 레퍼런스된 객체에 대해 할당된 속성 구조, 인덱스 구조, 및/또는 값 저장소들을 포함할 수 있다. 속성 구조는 객체의 하나 이상의 기존 속성들을 저장하도록 메모리(또는 메모리의 어드레스 공간)에 할당된 구조화된 데이터일 수 있다. 기존 속성들은 런타임 동안에 객체에 대한 현재 동적 타입을 나타낼 수 있다.
일 실시예에서, 객체의 값 저장소들은 객체의 기존 속성 값들을 저장하도록 메모리에 동적으로 할당될 수 있다. 각각의 속성 값은 객체의 기존 속성들 중 하나에 개별적으로 대응할 수 있다. 객체의 인덱스 구조는 대응하는 기존 속성들에 대한 속성 값들의 레퍼런스들을 저장하도록 동적으로 할당될 수 있다. 레퍼런스는 속성 값을 저장하는 값 저장소를 위치시키기 위한 메모리 어드레스에 대한 (예컨대, 코드 또는 다른 적용가능한 메커니즘들의 실행을 통한) 직접 또는 간접 포인터일 수 있다.
블록(503)에서, 프로세스의 프로세싱 로직은 소스 코드로부터 객체에의 제1 액세스에 대한 제1 명령어들을 생성할 수 있다. 소스 코드는 제1 액세스에 대한 업데이트된 속성 값으로 기존 속성들 중 하나를 업데이트하는 프로그램 구문들을 포함할 수 있다. 일부 실시예들에서, 업데이트된 속성 값에의 제1 액세스는 속성이 객체로부터 삭제되었음을 나타낼 수 있다. 제1 명령어들은 ExistingWrite(), Delete() 등과 같은 동작들을 포함할 수 있다.
일부 실시예들에서, 객체에의 제1 액세스는 객체의 기존 속성을 업데이트된 속성 값으로 업데이트하도록 소스에서 지정될 수 있다. 제1 명령어들은 객체의 예상된 속성 구조에 대한 레퍼런스를 포함하도록 인라인 캐시 코드에의 제1 액세스에 대해 컴파일될 수 있다. 예상된 속성 구조는 기존 속성에 대한 속성 저장소를 위치시키기 위한 오프셋 위치를 지정할 수 있다. 예를 들어, 오프셋 위치는 속성 저장소를 가리키는 포인터에 대한 인덱스 구조에 대한 인덱스 오프셋일 수 있다. 제1 명령어들은 객체의 예상된 속성 구조 및 객체에의 제1 액세스에 대한 오프셋 위치를 임베드할 수 있다.
일부 실시예들에서, 제1 명령어들은 객체의 예상된 속성 구조 및 객체의 기존 속성의 속성 값을 위치시키기 위한 오프셋 위치를 임베드할 수 있다. 오프셋 위치는 예상된 속성 구조에서 지정될 수 있다. 예를 들어, 오프셋 위치는 인덱스 구조에서 포인터 어레이에 대한 인덱스를 포함할 수 있다. 일 실시예에서, 제1 명령어들은 객체의 속성 구조가 객체의 예상된 속성 구조에 대응하는지 여부를 판정하는 동작들을 포함할 수 있다. 제1 명령어들은, 객체의 속성 구조가 예상된 속성 구조에 대응하는 경우에 테이블 룩업 동작을 수행하는 일 없이, 제1 명령어들 내에 임베드된 오프셋 위치를 통해 속성 저장소를 업데이트된 속성 값으로 업데이트하는 제1 액세스를 수행하도록 실행될 수 있다.
도 2의 컴파일러(205)와 같은 컴파일러는 런타임 실행과 연관된 런타임 데이터에 기초하여 객체에 대한 예상된 속성 구조를 갖는 제1 명령어들을 생성할 수 있다. 예를 들어, 프로세스(500)의 프로세싱 로직은 도 2의 런타임 데이터(211)에서 수집된 프로파일 데이터와 같은 런타임 프로파일을 분석하여, 객체에 액세스하기 위한 예상된 프로파일 구조를 예측할 수 있다. 대안으로 또는 선택적으로, 프로세스(500)의 프로세싱 로직은 사용자 입력 또는 다른 프로세싱 모듈에 대한 인터페이스들과 같은 외부 입력으로부터 제공된 휴리스틱스 또는 힌트에 기초하여 객체의 예상된 속성 구조를 판정할 수 있다.
블록(505)에서, 프로세스(500)의 프로세싱 로직은 객체에의 제2 액세스에 대한 제2 명령어들을 생성할 수 있다. 제2 액세스는 소스 코드에 의해 지정되어 추가 속성을 객체에 대한 추가 속성 값으로 업데이트할 수 있다. 객체의 기존 속성들은 제2 명령어들이 객체에의 제2 액세스에 대해 실행되는 경우에 추가 속성을 포함하지 않을 수 있다.
제2 명령어들은 개별 속성 구조, 개별 인덱스 구조, 및 객체에 대한 추가 속성 값을 저장하는 추가적인 값 저장소를 할당하도록 실행될 수 있는데, 개별 속성 구조는 기존 속성들 및 추가 속성을 저장하고, 개별 인덱스 구조는 값 저장소들에 대한 개별 레퍼런스들 및 추가 속성에 대응하는 추가적인 값 저장소에 대한 추가 레퍼런스를 저장한다.
일 실시예에서, 소스 코드는 객체에의 제2 액세스에 대한 제2 속성 식별자를 지정할 수 있다. 프로세스(500)의 프로세싱 로직은 제2 속성 식별자가 속성 구조에 저장된 기존 속성들 중 하나를 식별하는지 여부를 판정할 수 있다. 예를 들어, 프로세스(500)의 프로세싱 로직은 제2 속성 식별자가 기존의 속성들 중 어느 것도 속성 구조(예컨대, AdditiveWrite())가 아님을 식별함에 따라 제2 명령어들을 생성할 수 있다.
블록(507)에서, 프로세스(500)의 프로세싱 로직은 제1 명령어들 및 제2 명령어들을 동시에 실행하여, 예를 들어 개별 스레드들을 통해, 객체에의 제1 액세스 및 제2 액세스를 수행할 수 있다. 제1 명령어들은 기존 속성들 중 하나에 대응하는 값 저장소들 중 하나를 업데이트(예컨대, ExistingWrite())하도록 실행될 수 있다. 제2 명령어들은 객체의 기존 속성들에 추가 속성을 추가(예컨대, AdditiveWrite())하도록 실행될 수 있다.
소정 실시예에 따르면, 객체 모델(또는 동시 객체 모델)은 속성 레퍼런스 및 인덱스 레퍼런스를 포함할 수 있다. 속성 구조를 가리키는 속성 레퍼런스는 객체의 동적 타입을 표현할 수 있다. 인덱스 구조를 가리키는 인덱스 레퍼런스는 그 동적 타입 하에 있는 객체의 동적 데이터 값들 또는 속성 값들을 표현할 수 있다. 속성 구조는 속성 값들에 대한 포인터들 또는 레퍼런스들을 저장하는 인덱스 구조의 인덱스 레퍼런스로부터의 오프셋들을 저장할 수 있다. 오프셋들은 인덱스 구조를 통해 속성 값들에 대한 간접 레퍼런스를 허용할 수 있다.
일 실시예에서, 객체의 속성 레퍼런스는 제1 명령어들 및 제2 명령어들의 실행 이전에 속성 구조를 가리키는 포인터를 포함할 수 있다. 속성 레퍼런스는 제1 명령어들 및 제2 명령어들의 동시 실행 뒤의 개별 속성 구조를 가리킬 수 있다.
일부 실시예들에서, 제2 명령어들은 속성 레퍼런스 및 인덱스 레퍼런스 양측 모두를 동시에 업데이트하는, 객체 상에서의 원자적 업데이트 동작을 포함할 수 있다. 예를 들어, 원자적 업데이트 동작은 속성 레퍼런스를 속성 구조에 대한 레퍼런스와 비교하도록 그리고 그 비교에 기초하여 속성 레퍼런스가 속성 구조에 대한 레퍼런스에 대응하는 경우에 속성 레퍼런스가 업데이트된 속성 구조를 나타내게 설정하도록 수행될 수 있다. 비교 및 설정 동작들은 하드웨어 지원부(예컨대, 프로세서 내의 내장 로직)를 통해 원자적으로 수행될 수 있다.
프로세스(500)의 프로세싱 로직은 소스 코드로부터 객체에의 제3 액세스에 대한 제3 명령어들을 생성할 수 있다. 제3 액세스는 소스 코드에서 지정되어 객체의 속성 값을 검색하거나 판독하게 할 수 있다. 제3 명령어들은 객체의 속성 레퍼런스가 속성 구조를 나타내는지 여부를 판정하는 인라인 캐시 동작들을 포함할 수 있다. 동시 객체 모델은 제2 명령어들 및 제3 명령어들이 동시에 실행되게 할 수 있다.
도 6은 인덱스 레퍼런스를 갖는 객체 모델에 기초하여 객체의 속성 값들에 동시에 액세스하는 프로세스의 일 실시예를 도시한 흐름도이다. 예시적인 프로세스(600)는, 예를 들어 도 2의 시스템(200)의 일부 컴포넌트들을 포함하는 프로세싱 로직에 의해 수행될 수 있다. 블록(601)에서, 프로세스(600)의 프로세싱 로직은 소스 코드에서 지정된 객체에의 제1 액세스에 대한 제1 명령어들을 생성할 수 있다. 객체는 객체의 기존 속성 값들을 저장하는 하나 이상의 값 저장소들에 대한 포인터들을 레퍼런스하는 인덱스 레퍼런스를 가질 수 있다. 제1 명령어들은 기존 속성 값들을 저장하는 값 저장소들 및 추가 속성 값을 저장하는 추가적인 값 저장소를 나타내는 개별 포인터들을 나타내는 인덱스 레퍼런스를 원자적으로 업데이트할 수 있다.
블록(603)에서, 프로세스(600)의 프로세싱 로직은 소스 코드로부터 객체에의 제2 액세스에 대한 제2 명령어들을 생성할 수 있다. 제2 액세스는 소스 코드에서 지정되어 객체의 기존 속성 값들 중 하나를 업데이트된 속성 값으로 업데이트할 수 있다.
블록(605)에서, 프로세스(600)의 프로세싱 로직은 제1 명령어들 및 제2 명령어들을 동시에 실행하여 객체에의 제1 액세스 및 제2 액세스를 수행할 수 있다. 객체는 실행 뒤의 업데이트된 속성 값 및 추가 속성 값을 포함하는 속성 값들을 가질 것을 보장받을 수 있다.
동시 인라인 캐시 최적화
동시 설정에서의 최적화된 인라인 캐싱을 위해 동적 타입 객체들에 액세스하는 인라인 캐시 코드가 런타임 동안에 자가 수정될 수 있다. 인라인 캐시 코드는 동적 객체에 액세스하기 위한 패스트 코드 경로 및 슬로우 코드 경로를 포함할 수 있다. 실행 시, 인라인 캐시 코드는 조우되는 객체의 동적 타입 또는 속성에 따라 패스트 코드 경로를 작동시킬 것인지 또는 슬로우 코드 경로를 작동시킬 것인지 판정할 수 있다.
일 실시예에서, 동시 설정은 하나 이상의 프로세서들에 의해 호스팅되는 다수의 스레드들 및/또는 다수의 프로세스들을 통해 동시 실행을 허용하는 운영 환경을 포함할 수 있다. 수정된 인라인 캐시 코드는 프로세서들이 수정된 인라인 캐시 코드에서의 명령어들의 변화를 관찰하도록 최적화된 인라인 캐싱에서 재설정될 수 있다.
소정 실시예에 따르면, 최적화된 인라인 캐싱은 초기 동작들 및 연쇄 동작들을 통해 인라인 캐시 코드를 수정(예컨대, 정치 편집(in place editing))할 수 있다. 초기 동작들은 미설정된(또는 비초기화된) 인라인 캐시 코드를 수정(또는 초기화)하여 특정 객체 속성 또는 구조에 대한 인라인 캐시 코드를 특화시키도록 수행될 수 있다. 특화된 인라인 캐시 코드는 특정 객체 속성을 갖는 객체가 조우되는 경우에 작동되는 패스트 코드 경로를 포함할 수 있다. 연쇄 동작들은 (예컨대, 초기화되거나 비초기화된) 인라인 캐시 코드를 수정하여 생성된 스터브(예컨대, 생성된 함수 코드를 가리키는 일편의 코드 또는 함수 포인터)를 통해 슬로우 코드 경로를 작동시키도록 수행될 수 있다.
초기 동작들은 효율적인 방식으로 인라인 캐시들이 록인(또는 초기화)되게 하는 프로세서 명령어 캐시 플러싱을 요구하는 일 없이 수행될 수 있다. 일 실시예에서, 초기 동작들은 (예컨대, 상이한 스레드들 사이의) 교차 수정 코드(cross modifying code)의 필요 없이 초기화 코드가 그의 인라인 캐시 코드들 대부분을 안정화(예컨대, 초기화)시킬 수 있도록 특정 스레드들, 예컨대 스레드 바이어싱에 의해 수행될 수 있다. 스레드 바이어싱은 상이한 스레드들 사이의 동기화 명령어들의 필요 없이 코드 수정을 가진 인라인 캐시들이 하나의 스레드 상에서 실행되게 할 수 있다.
일 실시예에서, 최적화된 인라인 캐싱에서 다수의 스레드들에 의해 공유되는 코드 블록들에 대한 수정은 즉각적 코드 변경을 행하는 대신에 버퍼링될 수 있다. 이러한 변경은 재설정 동작들이 수행되는 경우에 코드 블록들에 대해 (예컨대, 함수 포인터들 등을 통해) 업데이트될 수 있다. 따라서, 이미 동시에 실행되고 있는 인라인 캐시를 수정하는 비용이 감소될 수 있다.
인라인 캐시 코드에 대한 재설정 동작들은 지정된 시간 스케줄에 따라 그리고/또는 빈번하게 작동되는 시스템 루틴, 예컨대 폐영역 수집 루틴들을 통해 초기화되어 실행 환경의 전체적인 시스템 성능에 대한 영향을 감소시킬 수 있다. 일 실시예에서, 예컨대 도 2의 명령어 캐시 플러시 모듈(219)에 기초한 감시점(watchpoint) 루틴이 지정된 스케줄에 따라(예컨대, 매 10 ms 또는 다른 적용가능한 시간 간격마다) 웨이크되어 재설정 동작들을 수행하게 할 수 있다.
일 실시예에서, 최적화된 인라인 캐싱에서 다수의 스레드들에 의해 공유되는 코드 블록들에 대한 수정은 즉각적 코드 변경을 행하는 대신에 버퍼링될 수 있다. 이러한 변경은 재설정 동작들이 수행되는 경우에 코드 블록들에 대해 (예컨대, 함수 포인터들 등을 통해) 업데이트될 수 있다. 따라서, 이미 동시에 실행되고 있는 인라인 캐시를 수정하는 비용이 감소될 수 있다.
일 실시예에서, 인라인 캐싱은 동적 객체 속성 룩업에 대한 최적화 메커니즘을 포함할 수 있다. 예를 들어, 인라인 캐시 코드는 컴파일 시에 (예컨대, 의사 코드로 표현되는 바와 같이) 하기와 같이 방출될 수 있다:
if (o->structure == ExpectedStructure)
v = o->payload[OffsetOfF] /* fast code path */
else
v = SlowPathRead(o)
ExpectedStructure 및 OffsetOfF의 값들이 아직 알려져 있지 않으므로, 초기 생성 코드는 비교 구문에 대한 거짓 결과, 즉 o->structure가 ExpectedStructure와 동일하지 않는다는 것을 부여할 것을 보장받을 수 있는 ExpectedStructure에 대한 더미 값을 가질 수 있다.
이후, SlowPathRead()가 처음으로 실행될 때, ExpectedStructure 및 OffsetOfF가 수정될 수 있다. ExpectedStructure 및 OffsetOfF의 값들이 코드 내의 상수들이므로, 수정은 기계 코드 시퀀스를 직접적으로 변경할 수 있다. 동시 설정에서의 최적화된 인라인 캐싱은 다른 프로세서들이 이러한 기계 코드의 그러한 변경 또는 편집을 관찰할 시기 및 코드의 일부분이 변경되는 순서에 대한 보증을 제공할 수 있다. 예를 들어, OffsetOfF가 ExpectedStructure 이전에 편집되는 경우, 다른 프로세서가 반대 순서 대신에 동일한 순서로 편집을 확인하여, OffsetOfF의 값의 변경을 관찰하기 전에 패스트 경로가 그 프로세서를 통해 취해질 가능성을 제거하도록 요구될 수 있다.
일 실시예에서, 인라인 캐싱은 호출 사이트에서 이전 방법 룩업의 결과들을 직접적으로 기억함으로써 런타임 방법 바인딩을 가속화할 수 있다. 특정 호출 사이트에서 발생한 객체들이 종종 동일한 타입의 것임을 가정하면, 성능은 방법 룩업의 결과를 "인라인"으로 저장함으로써, 즉 인라인 캐싱을 통해 호출 사이트에 직접적으로 저장함으로써 증가될 수 있다. 일 실시예에서, 호출 사이트들은, 예를 들어 ExpectedStructure 및 OffsetOfF의 값들이 아직 알려져 있지 않은 경우에 초기화되지 않을 수 있다. 일단 언어 런타임이 특정 비초기화 호출 사이트에 도달하면, 그것은 동적 룩업을 수행할 수 있고, 호출 사이트에 결과를 저장할 수 있고, 호출 사이트를 초기화할 수 있다. 언어 런타임이 동일한 호출 사이트에 다시 도달하는 경우, 그것은 그로부터 피호출자를 검색할 수 있고, 더 이상 룩업들을 수행하는 일 없이 그것을 직접적으로 작동시킬 수 있다.
상이한 타입의 객체들이 동일한 호출 사이트에서 발생할 수 있는 가능성을 다루기 위해, 언어 런타임은 가드 상태들, 예컨대 o->structure == ExpectedStructure의 구문을 코드 내에 삽입할 필요가 있을 수 있다. 가장 보편적으로, 이들은 호출 사이트에서라기보다 피호출자의 프리앰블(preamble) 내에 삽입되어, 브랜치 예측을 더 잘 활용하며 프리앰블 내의 하나의 복제본으로 인해 각각의 호출 사이트에서의 다수의 복제본들에 비해 공간을 절약한다. 이미 초기화된 호출 사이트가 그것이 예상하는 것 외의 타입을 조우하는 경우, 그것은 마치 그것이 초기화되지 않은 것처럼 전체 동적 룩업을 다시 수행할 수 있다.
일 실시예에서, 최적화된 인라인 캐싱은, 프로세서가 변경된 명령어들을 즉각적으로 관찰할 것을 요구하는 일 없이, 명령어들에서의 1 초과의 워드 크기의 코드 위치들을 수정하는 동시 자가 수정 코드를 허용할 수 있다. 프로세서 캐시 플래시 메커니즘들은 프로세서(들)를 변경된 명령어들과 동기화시키도록 실행될 수 있다.
예를 들어, 프로세서는, 어느 쪽이 더 작든, 1개 미만의 정렬 워드 또는 1개의 명령어를 한 번에 판독하지 못할 수 있다. Intel® x86 프로세서 상에서의 5-바이트 명령어의 즉시값(immediate)(예컨대, 명령어 내에 포함된 상수 피연산자)은 32-비트 워드일 수 있고, 그 워드는 정렬된다. 즉시값이 다른 스레드로부터의 기록을 이용하여 변경되거나 수정되는 경우, 그 명령어를 실행하는 프로세서(들)는, 구 명령어의 일부 및 신 명령어의 일부를 포함하는 명령어의 해체(torn) 버전을 확인하는 일 없이, 기록 "전"의 명령어 또는 기록 "후"의 명령어를 항상 확인(또는 프로세싱)할 수 있다.
인라인 캐싱이 1 초과의 워드 크기의 코드 위치들을 수정할 것을 요구함에 따라, 프로세서 명령어 캐시로 인해 프로세서가 변경된 명령어들을 즉각적으로 관찰한다는 보장이 없을 수 있다. 또한, 수정된 명령어들을 페치할 때 프로세서가 수행하는 메모리 로딩의 순서 및 입도에 대한 보장이 없을 수 있다. 예를 들어, 2개의 상이한 명령어들은 코드 수정에 대한 정확한 순서, 예컨대 하나의 명령어 상에서의 "제1" 기록 뒤에 다른 명령어 상에서의 "제2" 기록이 이어지는 순서로 수정될 수 있다. 명령어들의 "제2" 기록이 일부 다른 프로세서에 의한 명령어들의 "제1" 기록 전에 그 프로세서에 의해 디코딩되지 않는다는 보장이 없을 수 있다.
일 실시예에서, 프로세서가 변경되거나 수정된 명령어들을 확인(또는 관찰)하는 때는 캐시 플러시 메커니즘이 그 프로세서 상에서 실행되는 때에 의존할 수 있다. 캐시 플러시 메커니즘들은, 예를 들어 Intel® 기반 프로세서들에 대한 CPUID 또는 ARM®과 같은 다른 하드웨어 상에서의 다른 유사한 플러싱 메커니즘들을 포함할 수 있다. 예를 들어, 큐피드(cupid)가 프로세서에 의해 페치될 명령어들의 순서를 강제하도록 프로세서 상에서 실행될 수 있다. 유사하게, 하나의 명령어가 변경되고, 이어서 CPUID의 등가물이 그 프로세서 상에서 실행되는 경우, 프로세서가 그 새로운 명령어를 관찰할 것이라는 것이 보장될 수 있다.
일 실시예에서, CPUID는, 예를 들어 명령어 캐시 플러싱을 수행하기 위해, 각각의 프로세서에 피닝된(pinned)(예컨대, 프로세서 상에서 실행되도록 제한된) 스레드를 통해 다수의 프로세서들 상에서 실행되어 프로세서를 웨이크시킬 수 있다. CPUID는, 예컨대 실행이 나중에 동일한 포인트에서 재개될 수 있도록 프로세스의 상태 또는 콘텍스트를 저장하고 복원하는 콘텍스트 스위칭의 일부로서 실행될 수 있다. 이러한 실행 포인트들(또는 명령어들)(예컨대, 라이트 세이프 포인트(light safe point)들 또는 라이트 포인트들)은 전형적인 다중스레드형 가상 기계들에서 발견되는 세이프 포인트 기계류(safe-point machinery)에 비해 더 라이트한 성능 영향을 야기할 수 있다.
일 실시예에서, 인라인 캐시 초기화는 하기와 같은 수정 어셈블리 코드에 기초하여 수행될 수 있다:
bnpneq 0, [t0],.slow
loadq 0[t0], t0
예를 들어, 코드 내의 상수들, 예컨대 포인터-와이드 상수(pointer-wide constant)(예컨대, "bnpneq 0"에서 0), 및/또는 바이트-와이드 또는 int-와이드 상수(예컨대, "loadq 0[t0]"에서 0)는 초기화 동안에 다른 값들로 패치(patch)되거나 수정될 수 있다. 포인터-와이드 상수는 체크할 구조 값(structure-to-check value)을 표현할 수 있고, 바이트-와이드 또는 int-와이드 상수는 로딩할 오프셋(offset-to-load-from) 값을 표현할 수 있다. "bnpneq 0"에서의 상수 값 0은 슬로우 코드 경로(예컨대, ".slow")가 초기에 작동되는 것을 보장할 수 있다. 어셈블리 코드의 프로세서는 "loadq"에 대한 상수가 패치(또는 초기화)될 때까지 "bnpneq"에 대한 상수에 대해 0이 아닌 값을 관찰하지 않을 수 있다.
최적화된 인라인 캐싱은 (예컨대, 프로세서 명령어 캐시를 플러싱하기 위한) 라이트 포인트를 요구하여 매 인라인 캐시 코드를 초기화하도록 하는 일 없이 인라인 캐시 코드들이 매우 빠르게 로킹(또는 초기화)되게 할 수 있다. 초기화된 인라인 캐시 코드들은 추가 오버헤드를 유발(예컨대, 더 느린 실행을 야기)하는 일 없이 인라인 캐싱을 최적화할 시에 실행될 수 있다. 일 실시예에서, 메모리 버퍼들이 채용되어, 인라인 캐시 코드들을 동시에 실행시키는 수정 시의 잠재적 고비용을 감소시킬 수 있다.
최적화된 인라인 캐싱은 프로세서가 거동하는 방식(예컨대, 명령어들이 프로세서에서 페치되고 실행되는 방식)에 대한 특정 상정안(assumption)에 의존하는 일 없이 수행될 수 있다. 일부 실시예들에 따르면, 최적화된 인라인 캐싱은, 예를 들어 비동시 인라인 캐싱 실행과 비교할 때 단일 프로세서를 통한 단일 인스턴스에 따른 성능 열화 없이, 다중 코어(예컨대, N 코어) 프로세서들을 통해, 예를 들어 Google® 자바스크립트 벤치마크 버전 7 코드(JavaScript benchmark version 7 code)(또는 V8 벤치마크 코드)의 코드 실행의 다수(예컨대, N개)의 인스턴스들을 실행하기 위한 선형 가속을 제공할 수 있다.
일 실시예에서, 인라인 캐시 초기화는 교차 수정 코드를 피하기 위해 인터프리터에 오프로드될 수 있다.
인터프리터가 실행하는 "코드"는 상이한 프로세서들 사이의 "데이터"에 적용가능한 규칙들과 유사한 메모리 순서 규칙들의 적용을 받는다. 따라서, 인터프리트된 코드는 실행가능한 기계 명령어들보다 수정하기가 더 용이할 수 있다. 예를 들어, 이중 CAS(예컨대, 이중 워드 비교 및 스위치 원자적 동작들)가 체크할 구조 및 로딩할 오프셋을 변경하여 인터프리트된 코드를 수정하도록 적용가능할 수 있다. 이어서, 동일한 인라인 캐시 코드가 JIT(또는 런타임) 컴파일러를 통해 컴파일되는 경우, 인라인 캐시 코드는 인터프리터에 의해 마지막으로 확인된 상태로 사전 초기화될 수 있다. 그 결과, 값비싼 초기화 절차들(예컨대, 명령어 캐시 플러싱을 갖는 자가 수정 코드)을 실행할 필요가 없을 수 있다.
추가로, 코드 블록 바이어싱(예컨대, 특정 스레드를 통해 실행됨)이 인라인 캐시 코드의 초기화된 상태와 비초기화된 상태 사이의 빈번한 변경(예컨대, 핑퐁 변경)과 같은 인라인 캐시 코드 초기화의 오버헤드를 더 감소시킬 수 있다. 코드 블록(예컨대, 함수 코드)의 실행은 스레드-로컬 상정(예컨대, 단 하나의 스레드로 실행됨)으로 시작될 수 있다. (인라인 캐시 코드들의) 초기화 동안에, 대부분의 코드들이 단 하나의 스레드 상에서 실행될 수 있다. 그들의 스레드 바이어스는 코드 블록을 컴파일한 스레드에 의해 판정될 수 있다.
일 실시예에서, 각각의 코드 블록은 코드 블록의 최상부에서 스레드에 대한 바이어스(bias-to thread)에 대한 스레드 체크 가드를 포함할 수 있다. 실행 동안에, 이러한 가드 코드는 (코드 블록에 대한) 호출자가 스레드에 대한 바이어스에 대해 이미 실행되고 있는 경우에 스킵될 수 있다. 바이어싱된(예컨대, 스레드에 대한 바이어스를 통해 실행된) 코드 블록들의 인라인 캐시 코드는 동시 고려사항 없이 패치되도록 허용될 수 있다.
상이한 스레드로부터의 호출 때문에 코드 블록의 스레드 체크 가드가 슬로우 경로를 취하자마자, 코드 블록은 동시 인라인 캐시들을 요구하는 것으로 마킹(또는 수정)될 수 있고, 스레드 체크 가드는 패치되어, 예컨대 스레드 체크 명령어를 NOP(또는 비연산 코드)로 대체할 수 있다. 스레드 체크 가드의 존재는 코드 블록 내에 호출하고자 하는 모든 다른 스레드들이 코드 블록 내의 인라인 캐시 코드에 대한 슬로우 코드 경로를 취하도록 강제할 수 있다. 동시 인라인 캐시 코드는 인터프리터 웜업(warm-up)(예컨대, 인터프리터를 통한 초기화 또는 프리베이킹(pre-baking)) 후에 (예컨대, 초기화된) 상태를 변경하는 인라인 캐시들에 대해 그리고 공유되는 코드 블록들 내에서만 작동될 수 있다.
인라인 캐시 코드 상에서 수행될 수 있는 동작들은, 예를 들어 미설정 인라인 캐시를 취하고 그것을 수정하여 그것이 일부 속성/구조에 대해 특화되도록 하는 초기 동작들, 초기화되거나 미설정된 인라인 캐시를 취하고 그것을 수정하여 슬로우 경로 브랜치가 생성된 스터브로 진행하도록 하는 연쇄 동작들, 감시점 실행(예컨대, 스케줄링된 프로세서 명령어 캐시 플러싱)으로 인해 인라인 캐시를 재설정하는 감시점 동작들, 및 객체들이 사용불가하기 때문에 GC(garbage collection) 동안에 인라인 캐시를 재설정하는 GC 동작들을 포함할 수 있다.
초기 및 연쇄 동작들은 2개의 이산적인 동작들을 요구할 수 있다. 초기 동작들의 경우, 2개의 동작들은 하기를 포함할 수 있다: 1) 오프셋(예컨대, 로딩할 오프셋 값)을 로딩(예컨대, 로딩 어셈블리 코드)에 패치하는 것, 및 2) 구조(예컨대, 체크할 구조 값)를 비교(예컨대, 비교 어셈블리 코드)에 패치하는 것. 연쇄 동작들의 경우, 이러한 2개의 동작들은 하기를 포함할 수 있다: 1) 스터브(예컨대, 함수를 표현하는 일편의 코드)를 생성하는 것, 및 2) 슬로우 경로 브랜치(예컨대, 어셈블리 코드 내의 포인터)를 스터브에 패치하는 것. 최적화된 인라인 캐싱은 이미 관찰된 동작들(1)을 프로세서가 가질 때까지 프로세서가 동작들(2)을 관찰(또는 확인)하는 것을 금지할 수 있는데, 이때 각각의 초기 및 연쇄 동작들에 대해 동작들(1)과 동작들(2) 사이에 라이트 포인트(예컨대, 명령어 캐시 플러싱)를 수행할 것을 요구하지 않는다.
예를 들어, ARM® 기반 프로세서들에서의 연쇄 동작들에 대한 동작들(2)은 JIT 코드에 대한 브랜치(예컨대, 그러한 작은 즉시값들 중 하나)로서 원자적일 수 있다. ARM® 기반 프로세서들에서의 초기 동작들에 대한 동작들(1)은 다수의 명령어들을 수반할 수 있고, 원자적이 아닐 수 있다. ARM® 기반 프로세서들(예컨대, ARMv7® 프로세서들)에서의 초기 동작들에 대한 동작들(1)과 동작들(2) 사이의 순서를 강제하기 위해, 오프셋(예컨대, 로딩할 오프셋 값)은 로딩(예컨대, 로딩 어셈블리 코드) 및 구조(예컨대, 체크할 구조 값)의 하위 16비트들에 대해 패치되어, 상위 비트들을 여전히 0으로 남겨둘 수 있다. 값 < 2^16을 갖는 구조(예컨대, 객체의 동적 타입을 표현함)가 없을 수 있으므로, 인라인 캐시 코드는 오프셋에 대한 패치가 프로세서에 의해 관찰되는 경우에도 슬로우 코드 경로를 작동시킬 수 있다. 이어서, 구조(예컨대, 체크할 구조 값)의 상위 16 비트들이, 값비싼 프로세싱 리소스들(예컨대, 약 100 마이크로초의 성능 오버헤드를 가짐)을 요구할 수 있는 라이트 포인트(예컨대, 명령어 캐시 플러싱) 뒤에 비교(예컨대, 비교 어셈블리 코드)에 패치될 수 있다.
일 실시예에서, 최적화된 인라인 캐싱은 성능 비용을 감소시키는 버퍼링 메커니즘을 제공하여 동시 인라인 캐싱에 대한 동작 순서를 강제하게 할 수 있다. 예를 들어, 스레드(예컨대, 라이트 포인트 스레드)가 하기 동작들을 (의사 코드들로) 수행한다는 것을 가정한다:
loop {
sleep 10ms;
if (buffer.empty())
continue;
lightpoint;
while (item = buffer.pop())
item.execute();
}
라이트 포인트(예컨대, 전용 명령어 캐시 플러싱 스레드를 통해 작동됨)는 (예컨대, 폐영역 수집기를 통해 작동되는 바와 같이) 세이프포인트로 대체될 수 있다. 초기 및 연쇄 동작들은 하기를 포함하도록 허용될 수 있다:
동작들(1)
buffer.push(new Item()
{
void execute()
{
동작들(2)
}
}
여기서 동작들(1)에서 오프셋이 패치되거나 스터브가 생성되며, 동작들(1)은 관찰될 수 있지만 프로세서에 의해 실행가능하지 않을 수 있는데, 그 이유는 동작들(2)이 수행되지 않았기 때문이다. 그 결과, 공유 코드 블록들에서의 인라인 캐시 초기화는 최대 10 ms(또는 라이트 포인트 스레드를 스케줄링할 시에 적용가능한 다른 시간 간격들)만큼 지연될 수 있다. 일 실시예에서, 라이트 포인팅 스레드는 버퍼가 비어 있지 않아서 불필요한 라이트 포인트 실행을 제거하는 경우(예컨대, 명령어들이 수정되지 않는 경우 또는 버퍼가 비어 있는 경우)에만 스케줄링(또는, 웨이크, 작동)될 수 있다.
GC 루틴이 작동되는 경우, 실행의 세이프 포인트들이 보장된다. 따라서, GC 루틴은 프로세스들/스레드들이 웨이크되기 전에 CPUID(예컨대, 명령어 캐시 플러싱)가 실행된다는 보장을 가진 채 원하는 만큼 인라인 캐시 코드들을 수정할 수 있다.
감시점 루틴이 (그것이 발생할 수 있는 장소를 지정하는 일 없이 주어진 표현식의 값이 변할 때마다 애플리케이션의 실행을 중지하도록) 작동되는 경우, 모든 스레드들은 점프 대체(예컨대, 동시 슬로우 코드 경로) 또는 인라인 캐시 재설정을 즉시 관찰할 것을 요구받을 수 있다. 예를 들어, watchpoint.fire()를 요청하는 스레드는 모든 다른 스레드들이 그들의 코드에 대한 변경을 관찰한 뒤에까지 더 진행하도록 허용되어서는 안 된다. 그러나, 감시점들은 덜 보편적이다.
일 실시예에서, 감시 포인팅 코드(예컨대, watchpoint.fire()를 통해 실행됨)는 인라인 캐시 코드들에서의 모든 점프들이 대체되고 인라인 캐시 코드들이 재설정된 뒤에 라이트 포인트 동작(예컨대, 명령어 캐시 플러싱)을 수행할 수 있다. 코드 블록 스레드 바이어싱 최적화가 감시점 코드에 적용가능할 수 있다. 예를 들어, 라이트 포인트 동작은, 코드 변경들 중 어느 것도 감시점 코드를 실행하는 스레드 외의 스레드에 의해 공유되거나 소유되지 않는 경우에는 수행되지 않을 수 있다.
따라서, 최적화된 인라인 캐시들은 인라인 캐시 코드들을 매우 빠르게 로킹하는 초기화 코드를 감속하는 일 없이 그리고 모든 인라인 캐시 코드를 초기화하는 라이트 포인트 동작을 요구하는 일 없이 수행될 수 있다. 인라인 캐시 코드들이 초기화될 수 있는데, 이때 인라인 캐시 코드들 중 대부분이 교차 수정 코드의 필요 없이 저레벨 인터프리터를 통해 안정화될 수 있다. JIT로의 재설정 상태(예컨대, 비초기화됨)에서 존속하는 이러한 인라인 캐시 코드들의 경우, 그들 중 대부분은 그 포인트에서 하나의 스레드에 대해 여전히 실행될 것이다.
일 실시예에서, 스레드 바이어싱은 동시 오버헤드 없이 스레드가 다른 스레드들에 의해 공유되지 않는 인라인 캐시 코드들을 수정하게 할 수 있다. 인라인 캐시 코드 업데이트 버퍼링으로부터의 감속은, 예를 들어 하나 초과의 스레드에 의해 공유되는 적은 수의 인라인 캐시 코드들에서만 발생할 수 있다. 최적화된 인라인 캐싱은 초기화된 인라인 캐시 코드들을 실행시키기 위한 추가 오버헤드를 추가하지 않을 수 있다.
일 실시예에서, 버퍼링 메커니즘들은 동시에 실행되는 인라인 캐시 코드들을 수정하도록 요구되는 값비싼 프로세싱 리소스들에 대한 부담을 잠재적으로 완화시킬 수 있다. 인라인 캐시 코드들을 업데이트하기 위한 버퍼링 메커니즘들은 인라인 캐시 업데이트들을 (예컨대, 버퍼링 없이) 업데이트하는 것과 비교할 때 매우 극적인 감속을 야기하지 않을 수 있다. 버퍼링 메커니즘들은 라이트 포인트들이 실행해야 하는 빈도가 매우 한정적이라는 것을 보장할 수 있다. 실제로 작동하는 감시점들이 공유 코드들에 영향을 미칠 수 있는 경우라 해도, 감시점들이 자동으로 작동하지 않는 것일 수 있는 경우들(예컨대, 감시점들이 작동되지 않을 것이라고 여기는 타당한 이유를 갖는 경우)을 제외하면 감시점들은 채용되지 않을 수 있다.
최적화된 인라인 캐싱은 프로세서가 거동하는 방식에 대한 임의의 가정과는 무관할 수 있다. 라이트 포인트들(예컨대, 스케줄링된 명령어 캐시 플러싱)은 X86 프로세서들, AMR 프로세서들, 또는 다른 적용가능한 프로세서들과 같은 프로세서들의 기존 능력들이 명령어들의 시퀀스들을 동기화시키는 명령어 캐시 플러싱과 같은 최적화된 인라인 캐싱의 요건들과 일치하는 것을 보장하도록 적용될 수 있다. 패치되거나 수정된 각각의 즉시값들(예컨대, 인라인 캐시 코드들의 체크할 구조 값 또는 로딩할 오프셋 값과 같은 명령어 피연산자들)이 다수의 명령어들에 의해 구축될 수 있지만, 최적화된 인라인 캐싱은 정확히 하나의 명령어가 플립(flip)될 때까지 인라인 캐시 코드들이 느리게 실행되는 것을 유지할 수 있는 것을 보장할 수 있다. 명령어는 프로세서(들)가 인라인 캐시 코드들에 대해 이루어진 변경들 중 나머지를 관찰하도록 강제된 후에만 플립될 수 있다.
그 결과, 최적화된 인라인 캐싱은 다중 코어(예컨대, N개의 코어) 프로세서들 상에서 벤치마크 코드(예컨대, V8 벤치마크 기반 자바스크립트 코드)의 다수(예컨대, N개)의 인스턴스들을 실행할 때 선형 가속을 제공할 수 있다. 벤치마크 코드들을 실행하기 위해 생성된 대부분의 인라인 캐시 코드들은, 예를 들어 JIT(예컨대, 컴파일러)들이 키킹(kick)(즉, 작동)되기 전에 매우 일찍 초기화될 수 있다. JIT에 미설정 상태로 존속하는(예컨대, JIT가 작동될 때 아직 초기화되지 않은) 이러한 몇 개의 인라인 캐시 코드들의 경우, 캐시 업데이트 버퍼링의 사용이 (예컨대, 동시에 실행되는 인라인 캐시 코드들을 수정하는 것으로 인해) 감속을 무시할만하게 할 수 있다. 다시 말해, 버퍼는 다른 웜업 활동(예컨대, 인라인 캐시 코드들의 초기화)이 진정되기 전에 플러싱될 수 있다.
도 7a 및 도 7b는 동시 실행을 위해 인라인 캐싱된 코드 블록들을 최적화하는 런타임 시스템을 도시한 블록 다이어그램들이다. 시스템(700)은 도 2의 시스템(200)의 일부 컴포넌트들을 포함할 수 있다. 이제, 도 7a를 참조하면, 최적화된 인라인 캐시 코드 생성기 모듈(207)이 초기 인라인 코드 생성기 모듈(701) 및 동시 인라인 코드 생성기 모듈(703)을 포함하여 최적화된 인라인 캐싱을 위한 자가 수정 코드를 생성할 수 있다.
일 실시예에서, 초기 인라인 코드 생성기 모듈(701)은 도 2의 컴파일러(205)와 같은 JIT 컴파일러를 통해 컴파일된 소스 코드로부터 비초기화된 직렬 인라인 캐시 코드를 제공할 수 있다. 직렬 인라인 캐시 코드는 직렬 슬로우 코드 경로(예컨대, SlowPathRead()) 및 패스트 코드 경로(예컨대, 로딩할 오프셋 값에 기초한 어셈블리 코드)를 포함할 수 있다. 패스트 코드 경로는 (메모리 어드레스들 대신에) 프로세서 레지스터들로부터의 값들에 액세스하거나 이들을 로딩하는 적은 수의 어셈블리 명령어들(예컨대, 4개의 명령어들)을 포함할 수 있다.
직렬 슬로우 코드 경로는 단 하나의 단일 스레드에 의해 실행될 수 있다. 일부 실시예들에서, 초기 인라인 코드 생성기 모듈(701)은 직렬 인라인 캐시 코드를 실행하기 위한 스레드 바이어스를 제공하는 가드 코드들(예컨대, 스레드 아이덴티티를 체크하기 위함)을 방출할 수 있다. 예를 들어, 초기 인라인 코드 생성기 모듈(701)은 스레드를 통해 작동될 수 있는데, 이러한 스레드는 또한 초기 인라인 코드 생성기(701)에 의해 생성된 직렬 인라인 캐시 코드를 실행한다. 스레드 바이어스는, 정치 코드 수정에 대한 프로세서 명령어 캐시를 플러싱할 필요 없이, 드물게 작동되는 코드들이 단일 스레드에서 실행되게 할 수 있다.
동시 인라인 코드 생성기 모듈(703)은 초기화되었을 수 있거나 초기화되지 않았을 수 있는 동시 인라인 캐시 코드를 제공할 수 있다. 동시 인라인 캐시 코드는 다수의 스레드들에 의해 동시에 실행될 때 자가 수정할 수 있다. 일 실시예에서, 동시 인라인 캐시 코드는 동시 슬로우 코드 경로 및 패스트 코드 경로를 포함할 수 있다. 동시 슬로우 코드 경로는 하나 초과의 스레드에 의해 실행될 수 있다. 일 실시예에서, 동시 슬로우 코드 경로는, 코드 버퍼를 통해 (예컨대, 인라인 캐시 코드 초기화를 위해) 자가 코드 수정을 수행하여, 코드 수정을 각각의 프로세서와 동기화시키는 값비싼 명령어 캐시 플러싱의 수를 감소시키는 버퍼링 동작들을 포함할 수 있다.
이제, 도 7b를 참조하면, 런타임(709)은 도 2의 런타임 데이터(211) 중 일부를 포함할 수 있다. 일 실시예에서, 코드 포인터(711)는, 예를 들어 소스 코드에서 지정된 함수를 구현하는 일편의 코드 또는 코드 블록을 작동시키기 위한 포인터, 예컨대 함수 포인터일 수 있다. 일 실시예에서, 코드 포인터(711)는 함수의 개별 구현예들(또는 컴파일된 코드)로서 인라인 캐시 코드 블록(713) 또는 인라인 캐싱된 코드 블록(717)을 레퍼런스할 수 있다.
인라인 캐싱된 코드 블록(717)은 도 7a의 초기 인라인 코드 생성기 모듈(701)을 통한 함수에 대해 생성될 수 있다. 예를 들어, 인라인 캐싱된 코드 블록(717)은 함수에서의 객체 데이터 액세스에 대한 슬로우 직렬 코드 경로를 갖는 슬로우 직렬 코드(721)를 포함할 수 있다. 스레드 체크 가드(719)는 인라인 캐싱된 코드 블록(717)의 실행을 위한 스레드 바이어스 능력을 제공할 수 있다.
인라인 캐싱된 코드 블록(713)은 도 7a의 동시 인라인 코드 생성기 모듈(703)을 통한 함수에 대해 생성될 수 있다. 인라인 캐싱된 코드 블록(713)은 동시 슬로우 코드 경로에 대한 슬로우 동시 코드(715) 및 슬로우 직렬 코드 경로를 갖는 슬로우 직렬 코드(721)를 포함할 수 있는데, 이들은 각각 함수에서의 객체 데이터 액세스에 대한 것이다. 슬로우 동시 코드(715)는 하나 초과의 스레드에 의해 동시에 실행될 때 자가 코드 수정이 가능할 수 있다. 예를 들어, 슬로우 동시 코드(715)는 아직 작동되지 않은 코드 버퍼(723)에서의 함수에 대한 코드 블록을 수정할 수 있다. 따라서, 코드 버퍼(723)에 대한 변경은 로킹 메커니즘을 통하지만 프로세서 명령어 플러싱의 필요 없이 동기화될 수 있다. 일부 실시예들에서, 코드 버퍼(723)에서의 코드 블록은 코드 포인터(711)에 의해 레퍼런스될 때(또는 가리켜질 때) 활성 상태가 될 수 있다.
도 8은 인라인 캐시 코드들을 갖는 코드 블록들을 동적으로 컴파일하기 위한 동시 실행의 예시적인 타임 라인들을 도시한다. 일례(800)는 도 2의 시스템(200)의 일부 컴포넌트들에 기초할 수 있다. 예를 들어, thread1(803) 및 thread2(805)는 도 2의 실행가능 코드(215) 중 일부를 포함하는 명령어들을 실행할 수 있다. thread1(803) 및 thread2(805) 양측 모두는 자바스크립트와 같은 동적 프로그래밍 언어에서 지정된 함수 foo(807)에 대한 호출을 포함하는 코드들을 실행할 수 있다.
일 실시예에서, 시간 인스턴트 T1(801)에서(또는 그 즈음에), thread1(803) 및 thread2(805)는 함수 foo(807)를 실질적으로 동시에 호출한다. 함수 foo(807)는, 처음으로 작동될 때(예컨대, 코드들이 실행될 때까지 컴파일되지 않을 때), 예컨대 도 2의 JIT 컴파일러(205)를 통해 컴파일될 수 있다. 시간 인스턴스 T2(813)에서, thread2(805)는 함수 foo(807)를 컴파일하기를 진행할 수 있고, 그 반면에 thread1(803)은 컴파일의 결과를 대기하기를 차단한다(예컨대, 단 하나의 스레드만이 한 번에 동일한 코드를 JIT 컴파일하도록 허용된다).
시간 인스턴스 T3(815)에서, thread2(805)는 함수 foo(807)를 컴파일하기를 완료하여, 예를 들어 도 7의 초기 인라인 코드 생성기 모듈(701)을 통해, 초기 인라인 캐싱된 코드 블록(809)을 생성할 수 있다. Thread2(805)는 함수 foo의 컴파일의 완료를 thread1(803)로 통지할 수 있다. 코드 블록(809)은 함수 foo에서의 객체 액세스에 대한 직렬 슬로우 코드 경로들 S2 및 S3을 포함할 수 있다. 일 실시예에서, 코드 블록(809)은 스레드 바이어싱을 위한 가드 코드(예컨대, thread2(805)를 식별하는 스레드 식별자 thread_2를 포함함)를 포함할 수 있다. 예를 들어, 코드 블록(809)의 가드 코드 S1은 직렬 슬로우 코드 경로들 S2 및 S3의 실행을 thread2(805)로 제한할 수 있다. 시간 인스턴스 T3에서 함수 foo의 컴파일을 완료한 뒤에, thread2(805)는 코드 블록(809)에 따라 실행 단계들 또는 동작들 S1, S2, … S5를 진행할 수 있다.
Thread1(803)은 thread2(805)를 통해 함수 foo(807)의 컴파일의 완료를 통지받은 후에 코드 블록(809)의 함수 foo를 호출하도록 웨이크할 수 있다. thread1(803)이 thread2(805)와는 상이한 스레드 식별자(예컨대, 코드 블록(809)의 thread_2)와 연관되므로, 코드 블록(809)의 가드 코드 S1의 실행은 thread1(803)이 함수 foo(807)를 리컴파일하게 할 수 있다.
시간 인스턴스 T4(817)에서, 함수 foo(807)는 thread1(803)을 통해 코드 블록(811)에 리컴파일될 수 있고, 반면에 thread2(805)는 함수 foo(807)에 대한 코드 블록(809)의 명령어들을 계속 실행한다. 하나의 스레드에서의 리컴파일은 차단할 다른 실행 스레드들을 요구하지 않을 수 있다. 일부 실시예들에서, threadt1(803)은 리컴파일을 수행하기 위해 (예컨대, 약 20 내지 40 나노초의 성능 오버헤드를 갖는) 록을 그랩(grab)/해제하도록 요구될 수 있다.
코드 블록(811)은, 예를 들어 도 7의 동시 인라인 코드 생성기 모듈(703)을 통해 방출되는 동시 인라인 캐시 코드 S7, S8을 포함할 수 있다. 일 실시예에서, 코드 블록(811)은 코드 블록(809)의 수정에 기초할 수 있다. 예를 들어, 코드 블록(809)의 가드 코드 S1은 코드 블록(811)에서 비연산(예컨대, 널 연산) 등가 스텝 S6이 될 수 있다. T3(815)과 T4(817) 사이의 기간(819) 동안에, 코드 블록(809)은 thread1(803) 및 thread2(805)의 런타임 동안에 함수 foo(807)를 구현하기 위한 활성 코드 블록에 대응할 수 있다. 기간(821)과 같은 시간 인스턴스 T4(817) 이후, 코드 블록(811)은 코드 블록(809)을 런타임 시의 함수 foo(807)에 대한 활성 코드 블록으로서 대체할 수 있다.
도 9는 동시 실행을 위해 동적 타입 객체에 액세스하도록 인라인 코드들을 자가 수정하는 프로세스의 일 실시예를 도시한 흐름도이다. 예시적인 프로세스(900)는 도 2의 시스템(200)의 일부 컴포넌트들을 포함하는 프로세싱 로직에 의해 수행될 수 있다. 블록(901)에서, 프로세스(900)의 프로세싱 로직은, 예를 들어 도 7의 초기 인라인 캐시 코드 생성기 모듈(701)을 통해, 소스 코드 블록으로부터 초기 인라인 코드를 생성할 수 있다. 소스 코드 블록은 동적(또는 동적 타입) 프로그래밍 언어로 지정된 소스 코드에 속할 수 있다.
예를 들어, 소스 코드 블록은 객체에의 적어도 하나의 액세스를 지정하는 프로그램 구문들을 포함할 수 있다. 소스 코드는 객체에 대한 타입 또는 구조를 선언하는 임의의 프로그램 구문들을 포함하지 않을 수 있다. 일 실시예에서, 객체는 대응하는 속성 값들을 갖는 하나 이상의 속성들을 갖는 동적 구조와 연관될 수 있다. 객체의 타입은 런타임 동안에 판정된 동적 구조에 대응할 수 있다.
일 실시예에서, 초기 인라인 코드는 객체에의 액세스(예컨대, 판독, 기록, 업데이트, 삭제, 또는 다른 적용가능한 데이터 로딩/조작 동작들)를 수행하도록 직렬 인라인 캐시 코드를 가질 수 있다. 직렬 인라인 캐시 코드는 직렬 슬로우 코드 경로 및 패스트 코드 경로를 포함할 수 있다. 코드 경로는 프로세서에 의해 실행될 어셈블리 명령어들의 시퀀스일 수 있다. 패스트 코드 경로는, 예를 들어 약 5 나노초의 성능 오버헤드를 갖는 적은 수(예컨대, 10개 미만)의 어셈블리 명령어들로 실행될 수 있다. 일 실시예에서, 직렬 슬로우 코드 경로는 인터프리터에 의해 수행되는 테이블 룩업 동작(예컨대, 약 100 나노초의 성능 오버헤드를 가짐)을 포함할 수 있다. 직렬 인라인 캐시 코드는 객체에의 액세스를 패스트 코드 경로를 통해 수행할 것인지 또는 직렬 슬로우 코드 경로를 통해 수행할 것인지 판정하는 비교 동작들을 포함할 수 있다.
블록(903)에서, 프로세스(900)의 프로세싱 로직은, 예를 들어 도 7의 동시 인라인 코드 생성기 모듈(703)을 통해, 소스 코드 블록으로부터 동시 인라인 코드를 생성할 수 있다. 동시 인라인 코드는 동적 타입 객체에의 데이터 액세스를 수행하는 동시 인라인 캐시 코드를 가질 수 있다. 동시 인라인 캐시 코드는 동시 슬로우 코드 경로 및 패스트 코드 경로를 포함할 수 있다. 동시 인라인 캐시 코드는 객체에의 데이터 액세스를 패스트 코드 경로를 통해 수행할 것인지 또는 동시 슬로우 코드 경로를 통해 수행할 것인지 판정하는 비교 동작들을 포함할 수 있다. 동시 슬로우 코드 경로는 인터프리터와는 무관하게 수행될 테이블 룩업 동작을 포함할 수 있다.
블록(905)에서, 프로세스(900)의 프로세싱 로직은 특정 스레드를 통해 초기 인라인 코드를 실행하여 객체에의 데이터 액세스를 수행할 수 있다. 일 실시예에서, 직렬 인라인 캐시 코드는 객체 타입 또는 객체의 동적 타입과 연관된 하나 이상의 상수 파라미터들, 예컨대 로딩할 오프셋 상수 값들 및/또는 체크할 구조 값들을 (예컨대, 명령어들의 즉시값들로서) 임베드할 수 있다. 상수 파라미터들 중 적어도 하나, 예컨대 로딩할 오프셋 값은 패스트 코드 경로에 포함될 수 있다.
패스트 코드 경로를 실행할 것인지 또는 직렬 슬로우 코드 경로를 실행할 것인지는 상수 파라미터들에 기초하여 판정될 수 있다. 직렬 슬로우 코드 경로는 특정 스레드를 통해 실행되어 직렬 인라인 캐시 코드 내에 임베드된 상수 파라미터들을 업데이트(또는 자가 수정)할 수 있다. 직렬 슬로우 코드 경로는 리컴파일을 위해 컴파일러(예컨대, JIT 컴파일러)에 대한 콜백(callback)들을 포함할 수 있다.
일 실시예에서, 프로세스(900)의 프로세싱 로직은 인터프리터를 통해 직렬 슬로우 코드 경로를 실행하여, 패스트 코드 경로를 초기화하기 위한 상수 파라미터들을 업데이트할 수 있다. 인터프리터는, 다수의 프로세서들 사이에 명령어 가간섭성 메커니즘(예컨대, 명령어 캐시 플러싱)을 작동시키는 일 없이, 다수의 프로세서들 사이의 데이터 가간섭성 또는 동기화 메커니즘을 작동시켜서, 초기화된 패스트 코드 경로를 공유하게 할 수 있다. 프로세서는 명령어들을 명령어 캐시에 사전 페치할 수 있다. 명령어 캐시 플러싱은 명령어 캐시가 클리어된 후에 중지 및 재개될 것을 프로세스서에 요구할 수 있다.
소정 실시예들에 따르면, 직렬 인라인 캐시 코드에서의 상수 파라미터들의 값들은 동시 인라인 코드가 생성되기 전에 특정 스레드를 통해 업데이트될 수 있다. 직렬 인라인 캐시 코드에서의 상수 파라미터들의 업데이트된 값들은 동시 인라인 캐시 코드를 생성할 때 (예컨대, JIT 컴파일러를 통해) 레퍼런스될 수 있다.
일 실시예에서, 상수 파라미터들 중 하나는 객체의 타입을 표현하는 객체의 동적 구조에 대한 포인터를 나타낼 수 있다. 상수 파라미터들 중 개별적인 하나의 파라미터는 객체에 액세스하기 위한 메모리 어드레스를 위치시키도록 오프셋에 대응하는 값을 가질 수 있다. 예를 들어, 객체는 메모리 어드레스에 저장된 속성 값과 연관될 수 있다. 객체에의 액세스는 메모리 어드레스에 저장된 속성 값에 대한 로딩(또는 저장) 동작들을 포함할 수 있다. 객체가 (예컨대, 동적 구조를 가리키는 포인터를 나타내는) 상수 파라미터들의 값들에 대응하지 않는 동적 구조(또는 타입)을 갖는 경우에, 메모리 어드레스는 객체에 액세스하기 위한 테이블 룩업 또는 검색 동작을 통해 판정될 수 있다.
초기 인라인 코드는 스레드가 직렬 인라인 캐시 코드를 실행하는 것을 금지하는 가드 코드를 포함할 수 있다. 예를 들어, 초기 인라인 코드는 특정 스레드를 통해 생성될 수 있고, 가드 코드는 스레드가 직렬 인라인 캐시 코드를 포함하는 초기 인라인 코드를 실행하도록 허용될 특정 스레드로서 식별되는지 여부를 판정하도록 실행될 수 있다.
일 실시예에서, 동시 인라인 코드는 초기 인라인 코드에서 가드 코드를 실행시킨 결과로서 생성될 수 있다. 가드 코드는 가드 코드를 실행하는 스레드가 초기 인라인 코드를 생성하는 특정 스레드와는 상이한 경우에 동시 인라인 코드를 생성하는 리컴파일 동작을 야기할 수 있다. 초기 인라인 코드 및 동시 인라인 코드 양측 모두는 공통 소스 코드 블록으로부터 컴파일될 수 있다. 동시 인라인 코드의 생성은 초기 인라인 코드의 수정에 기초할 수 있다. 예를 들어, 초기 인라인 코드의 가드 코드는 스레드의 아이덴티티와는 무관하게 스레드가 동시 인라인 캐시 코드를 수행하게 하는 비연산 코드이도록 패치될 수 있다.
블록(907)에서, 프로세스(900)의 프로세싱 로직은 하나 이상의 스레드들을 통해 동시 인라인 코드를 실행하여 객체에의 데이터 액세스 동작들을 수행할 수 있다. 동시 인라인 캐시 코드는 패스트 코드 경로의 실행에 대한 상수 파라미터들을 임베드할 수 있다. 동시 인라인 캐시 코드의 동시 슬로우 코드 경로는 동시 인라인 캐시 코드의 상수 파라미터들의 값들을 업데이트하도록 동시에 실행될 수 있다.
일 실시예에서, 동시 인라인 코드의 복제본이 코드 버퍼에 저장될 수 있다. 코드 버퍼에서의 동시 인라인 코드의 복제본은, 예를 들어 자가 수정 코드를 통해 상수 파라미터들을 업데이트하도록 수정될 수 있다. 동시 인라인의 복제본의 수정은 다수의 스레들 사이에서 동시 인라인 코드의 실행과 비동기식으로 수행될 수 있다.
일 실시예에서, 동시 인라인 코드는 명령어 캐싱이 가능한 하나 이상의 프로세서들에 의해 실행될 수 있다. 전용 스레드가, 예를 들어 코드 버퍼에서의 동시 인라인 코드의 복제본이 수정되는 때와는 무관하게 지정된 스케줄에 따라, 프로세서들 상에서 명령어 캐시 플러싱(예컨대, 명령어 캐시를 비게 만듦)을 작동시킬 수 있다.
명령어 캐시들의 플러싱 뒤에, 코드 버퍼에서의 업데이트된 상수 파라미터들로 수정된 동시 인라인 코드는 소스 코드 블록에 대한 컴파일된 코드로서 이전에 실행된 동시 인라인 코드를 대체하도록 작동될 수 있다. 일부 실시예들에서, 코드 버퍼에서 동시 라인 코드를 실행시킬 때, 비어 있는 새로운 코드 버퍼가 제공될 수 있다.
패스트 코드 경로는 직렬 인라인 캐시 코드의 업데이트된 상수 파라미터들 또는 동시 인라인 캐시 코드의 업데이트된 상수 파라미터들이 객체의 동적 타입과 일치하는 객체 타입에 대응하는 경우에 객체에 액세스하도록 실행될 수 있다.
도 10은 인덱스 레퍼런스를 갖는 객체 모델에 기초하여 객체의 인라인 캐시 동시 액세스 속성 값들을 갖는 함수 코드 블록을 동적으로 컴파일하는 프로세스의 일 실시예를 도시한 흐름도이다. 예시적인 프로세스(1000)는 도 2의 시스템(200)의 일부 컴포넌트들을 포함하는 프로세싱 로직에 의해 수행될 수 있다. 블록(1001)에서, 프로세스(1000)의 프로세싱 로직은 초기 스레드를 통해 함수에 대한 직렬 인라인 캐시 코드를 컴파일할 수 있다. 함수는 객체에 액세스하기 위해 소스 코드에서 지정될 수 있다. 직렬 인라인 캐시 코드는 직렬 슬로우 코드 경로 및 패스트 코드 경로를 포함할 수 있다.
직렬 슬로우 코드 경로는, 느릴 수 있고 값비싼 프로세싱 리소스들을 요구할 수 있는 테이블 룩업 또는 다른 적용가능한 검색 동작들을 통해 객체의 액세스를 수행하도록 실행될 수 있다. 패스트 코드 경로는 패스트 코드 경로 내측에 임베드된 메모리 어드레스를 통해 (예컨대, 룩업 동작을 수행할 필요 없이) 직접 메모리 로딩 동작들을 통해 객체의 액세스를 수행하도록 실행될 수 있다.
블록(1003)에서, 프로세싱 로직 또는 프로세스(1000)는 직렬 슬로우 코드 경로를 컴파일한 초기 스레드를 통해 인터프리터에 의해 객체에 액세스하는 직렬 슬로우 코드 경로를 실행할 수 있다. 패스트 코드 경로의 메모리 어드레스는 직렬 슬로우 코드 경로의 실행을 통해 초기화될 수 있다.
블록(1005)에서, 초기 스레드와는 별개인 스레드를 통한 함수에 대한 호출에 응답하여, 프로세스(1000)의 프로세싱 로직은 소스 코드에서 지정된 함수에 대한 동시 인라인 캐시 코드를 컴파일할 수 있다. 동시 인라인 캐시 코드는 직렬 슬로우 코드 경로의 실행을 통해 초기화된 메모리 어드레스가 임베드되는 패스트 코드 경로를 포함할 수 있다.
일 실시예에서, 동시 인라인 캐시 코드는 테이블 룩업 동작들을 통해 객체의 액세스에 대한 동시 슬로우 코드 경로를 가질 수 있다. 동시 인라인 캐시 코드는 객체에의 액세스를 동시 슬로우 코드 경로를 통해 수행할 것인지 또는 패스트 코드 경로를 통해 수행할 것인지 판정하는 명령어들을 포함할 수 있다.
블록(1007)에서, 프로세스(1000)의 프로세싱 로직은 하나 이상의 스레드들을 통해 동시 인라인 캐시 코드를 실행하여 인터프리터를 작동시키는 일 없이 기능을 수행할 수 있다. 패스트 코드 경로에서의 메모리 어드레스는 동시 인라인 캐시 코드의 동시 슬로우 코드 경로가 실행되는 경우에 재초기화될 수 있다.
동적 타입 객체 모델들에 대한 플랫 어레이 타입
일 실시예에서, 플랫 어레이 객체 또는 인라인 저장 어레이 데이터 객체는 동적 프로그래밍 언어로 지정된 동적 타입 객체에 대한 객체 셀에 기초할 수 있다. 객체 셀은 할당 시에 식별된 고정 크기로 할당될 수 있다. 예를 들어, 객체 셀은 타입 포인터(예컨대, 8 바이트), 데이터 포인터(예컨대, 8 바이트), 및 선택적 인라인 저장소(예컨대, 다수의 64-비트 또는 다른 고정 크기 비트의 메모리 공간)를 포함할 수 있으며, 이들은 예를 들어 순차적으로 서로 인접하거나 바로 옆에 할당된다. 인라인 저장소(또는 인라인 속성 저장소)는 객체 셀 내의 인라인 보조 기억 장치(backing store)일 수 있다. 타입 포인터는 객체 타입을 표현하는 타입 구조를 가리킬 수 있다. 데이터 포인터는 객체 타입에 대한 속성 값들을 저장하기 위한 저장소 구조(예컨대, 보조 기억 장치)를 가리킬 수 있다.
일 실시예에서, 선택적 저장소는 객체 셀이 할당될 때(예컨대, 대응하는 객체가 런타임 동안에 생성될 때)의 메모리 할당의 상태에 기초하여 판정될 수 있다. 선택적 저장소는 이미 할당된 인접 객체 셀들 사이의 가용 메모리 공간에 기초하여 판정될 수 있다.
동적 프로그래밍 언어에 대한 플랫 어레이 객체들은 런타임 동안에 (예컨대, 객체의 수명 전체에 걸쳐서) 크기 한도 내의 고정 크기를 갖는 어레이 데이터를 표현하는 객체의 존재를 검출하는 기능을 제공받을 수 있다. 예를 들어, 크기 한도는 동적 타입 객체를 표현하는 할당(예컨대, 저장소 또는 메모리 할당)에 따라 사전 지정되거나 판정될 수 있다.
어레이 타입의 어레이 또는 데이터는 요소들(값들 또는 변수들)의 집합을 포함할 수 있는데, 각각의 요소는 런타임에서 계산될 수 있는 하나 이상의 인덱스들(키(key)들을 식별함)에 의해 선택될 수 있다. 어레이는 어레이 데이터 구조들을 통해 할당된 벡터 및/또는 행렬을 포함할 수 있다. 어레이 데이터 구조는 어레이의 제1 요소를 저장하는 메모리 어드레스로부터의 오프셋과 같은, 수학 공식을 통해 그의 인덱스로부터 계산될 수 있는 위치(메모리 위치)에 각각의 요소를 저장하도록 할당될 수 있다.
자바스크립트에서의 많은 어레이들은 그들의 수명 전체에 걸쳐서 고정 크기를 가질 수 있다. 예를 들어, 어레이 리터럴(Array literal)들(예컨대, ['hello', 1, {}])은 그들이 처음 런타임에서 생성될 때의 알려진 크기를 가질 수 있고, 이러한 방식으로 생성된 어레이들 중 대부분은 프로그램에서 그들의 수명 전체에 걸쳐서 증가하지 않는다. 추가로, 어레이들은 (예컨대, 도 2의 런타임 데이터(211)에 수집된 프로파일 데이터를 통해) 프로파일링 메커니즘들에 기초하여 소정 길이 이내에서 증가하는 것(또는 그 이상으로 결코 증가하지 않는 것)으로 검출될 수 있다. 소정 고정 크기 이상으로 결코 증가하지 않는 어레이의 경우, 어레이의 인덱싱된 데이터를 저장하는 보조 기억 장치는 어레이 자체의 객체 셀과 나란히 할당될 수 있다.
일부 실시예들에서, 바이트 코드 또는 컴파일된 코드와 같은 실행가능 코드는 인덱스 i를 통해 어레이 a[i]=x의 요소를 표현하는 어레이 액세스 코드를 포함할 수 있는데, 요소 x의 값 및 가외 포인터는 어레이 프로파일 객체를 레퍼런스한다. 어레이 액세스 코드가 실행되는 경우, 어레이 프로파일은 어레이에 대한 런타임 프로파일을 확립하도록 요소 값(예컨대, x)의 타입 정보를 축적할 수 있다.
플랫 어레이 객체는 속성 값들(즉, 인덱싱된 데이터)을 저장하는 대응하는 저장소 구조를 할당하는 일 없이 할당될 수 있다. 따라서, 런타임 동안에 인덱싱된 데이터를 표현하는 플랫 어레이 객체에 대해 요구되는 메모리 할당의 수는 저장소 구조를 통해 인덱스 데이터를 표현하는 객체에 대해 요구되는 메모리 할당의 수에 비해 (예컨대, 절반만큼) 감소될 수 있다.
일 실시예에서, 인덱싱된 데이터를 표현하는 플랫 어레이 객체들은 런타임 최적화가 플랫 어레이 객체들을 통한 인덱싱된 데이터에 액세스하거나 그에 대한 동작들을 수행하는 코드들을 (예컨대, JIT 컴파일러를 통해) 컴파일하게 할 수 있다. 컴파일된 코드들은 플랫 어레이 객체들 상에서만 동작할 수 있다.
예를 들어, 도 2의 동시 코드 실행 모듈(217)과 같은 런타임은 인덱싱된 데이터를 표현하는 플랫 어레이 객체의 인라인 보조 기억 장치로부터의 인덱싱된 데이터에 액세스하는 직접 로딩을 수행할 수 있다. 객체에 대한 객체 셀의 데이터 포인터를 통해 저장소 구조를 통해 로딩하는 것에 의해 객체의 데이터에 간접적으로 액세스하고 이어서 저장소 구조(또는 보조 기억 장치)로부터 값의 또는 데이터를 로딩하는 것에 비해, 플랫 어레이 객체들은 동적 언어들에 기초하여 동적 타입 객체들에 액세스하기 위한 성능 최적화를 허용하여 C와 같은 하위 레벨 또는 하위 타입 언어들의 어레이들의 성능과 거의 동등함(parity)을 달성할 수 있다.
일 실시예에서, 인덱싱된 데이터 또는 어레이 데이터는 양방향 방식으로 객체(예컨대, 자바스크립트 객체)의 속성 값들을 편성하도록 구조화된 버터플라이 저장소(butterfly storage)에 저장될 수 있다. 객체의 속성 값들을 저장하는 저장소 구조는 버터플라이 저장소에 기초할 수 있다.
예를 들어, 동적 타입 객체(예컨대, 자바스크립트 객체)에 추가될 수 있는 속성들은 두 가지 타입, 즉 인덱싱된 속성들 및 비인덱싱된 속성들이 있을 수 있다. 인덱싱된 속성들은 0 이상의 정수일 수 있는 이름들을 갖는 속성들을 포함할 수 있다. 비인덱싱된 속성들은 ECMA(Ecma International for Information Communication Technology and Consumer Electronics) 사양에 의해 정의된 바와 같이 "foo" 및 "bar"와 같은 유효 식별자들인 이름들을 갖는 속성들을 포함할 수 있다. 상이한 타입의 속성들이 액세스를 위해 단일화된 방식을 허용하도록 상이한 장소들에서 버터플라이 저장소에 저장될 수 있다.
일 실시예에서, 객체의 인덱싱된 속성들(또는 인덱싱된 속성들의 속성 값들)은 버터플라이 저장소의 중앙에서 시작되는 메모리 셀들의 0-인덱싱된 시퀀스로 버터플라이 저장소에 저장될 수 있다. 객체의 비인덱싱된 속성들(또는 비인덱싱된 속성들의 속성 값들)은 버터플라이 저장소의 중앙으로부터 후방으로 가는 0-인덱싱된 시퀀스로 저장될 수 있다. 일부 실시예들에서, 객체를 표현하는 객체 셀로부터의 데이터 포인터는 버터플라이 저장소의 인덱싱된 부분의 0번째 엔트리를 가리킬 수 있다.
메모리 내의 버터플라이 저장소에 저장된 속성들(또는 속성 값들)의 레이아웃이 하기와 같이 표현될 수 있다:
[..., p3, p2, p1, p0][ip0, ip1, ip2,...]
^
여기서, pN은 오프셋 N에서의 비인덱싱된 속성을 표현하고, ipN은 오프셋 N에서의 인덱싱된 속성을 표현한다. 이러한 속성들의 객체를 표현하는 객체 셀에서의 데이터 포인터는 버터플라이 저장소에서의 메모리 어드레스 ^ (예컨대, ip0의 어드레스)를 가리킬 수 있다. 객체가 인덱싱된 속성들을 갖지 않는 경우, 레이아웃은 하기와 같이 표현될 수 있다:
[..., p3, p2, p1, p0]
^
이때, 데이터 포인터는 할당된 버터플라이 저장소의 단부를 지난 (또는 p0이 저장된 곳의 단부에 있는) 메모리 어드레스를 가리킨다. 유사하게, 객체가 비인덱싱된 속성들에 대한 저장소를 요구하지 않는 경우, 버터플라이 저장소에서의 속성들의 레이아웃은 하기와 같이 표현될 수 있다:
[ip0, ip1, ip2,...]
^
일부 실시예에서, 객체는 객체를 표현하는 대응하는 객체 셀의 인라인 저장소에 인라인으로 저장될 속성들을 가질 수 있다. 인라인 저장소는 버터플라이 저장소를 포함할 수 있다. 객체 셀 내의 데이터 포인터(또는 버터플라이 포인터)는 객체 셀 내의 그 인라인 저장소(또는 메모리 세그먼트)의 단부를 지나 가리킬 수 있다.
소정 실시예들에 따르면, 동적 타입 객체를 표현하는 객체 셀은 16-바이트(또는 다른 적용가능한 크기)의 저장소 영역을 포함할 수 있다. 객체 셀의 처음 8개 바이트들은 타입 구조에 대한 포인터를 포함할 수 있는데, 이는 그것을 가리키는 객체의 타입/형상의 추출(abstraction)에 대응할 수 있다. 구조들 또는 타입 구조들은 프로그램(예컨대, 자바스크립트 또는 동적 언어들에 기초함)이 실행되고 그것이 사용하는 객체들을 변이시킴에 따라 구축되고 수정될 수 있다. 타입 구조는 비인덱싱된 속성명들을 그들의 대응하는 오프셋에 맵핑할 수 있다.
16-바이트 셀의 두 번째 8개 바이트들은 제2 구조 또는 저장소 구조, 예컨대 버터플라이 저장소에 대한 포인터 또는 데이터 포인터일 수 있다. 객체 셀 내의 데이터 포인터의 옆 또는 뒤에, 인라인 비인덱싱된 속성 저장소에 이용되는 선택적 개수의 64-비트 값들이 할당될 수 있다. 따라서, 자바스크립트(또는 다른 적용가능한 동적 언어) 기반 객체에 대한 객체 셀이 (64-비트 워드 크기를 가정하면) 하기와 같이 표현되는 메모리 레이아웃을 가질 수 있다:
[structure pointer][butterfly pointer][optional inline property storage …]
0 8 16
여기서, 구조 포인터는 객체 셀에 대해 오프셋된 0 바이트로 어드레싱된 타입 포인터일 수 있고; 버터플라이 포인터는 오프셋된 8 바이트로 어드레싱된 데이터 포인터일 수 있고; 선택적 인라인 속성 저장소는 오프셋된 16 바이트로 어드레싱될 수 있다. 인라인 저장소 내에 저장된 속성 값들은 버터플라이 포인터를 통한 가외 간접접근의 필요 없이 액세스될 수 있다.
일 실시예에서, 인덱싱 타입은, 예를 들어 비트 필드들로서, 객체와 연관된 저장소 구조에서 유지될 수 있다. 객체의 인덱싱 타입은 그의 보조 기억 장치 또는 저장소 구조에 저장된 속성 값들의 타입, 예컨대 Int32, 이중(Double), '기타', 또는 다른 적용가능한 값 타입들을 나타낼 수 있다. 알려진 타입을 갖지 않는 속성 값은 타입 '기타'를 할당받을 수 있다.
인덱싱 타입은 저장소 구조의 형상을 나타낼 수 있다. 예를 들어, 속성 값들은 형상 Contiguous의 저장소 구조에서의 인접한 메모리 공간에 편성될 수 있다. 선택적으로 또는 대안으로, 인덱싱된 속성 값들은 형상 ArrayStorage의 저장소 구조에 데이터 어레이로서 저장될 수 있다.
일 실시예에서, 인덱싱 타입은 객체의 속성 값들이 어레이 데이터(예컨대, 어레이 객체에 대한 Array 타입)를 포함하는지 또는 비어레이 데이터(비어레이 객체에 대한 NonArray 타입)를 포함하는지 나타낼 수 있다. 추가로, 인덱싱 타입은 객체가 플랫 어레이 객체인지 아닌지 여부를 나타낼 수 있다. 예를 들어, 인덱싱 타입은, 인덱싱된 속성들이 인라인으로 저장되는지 아닌지 여부에 따라, 인덱싱된 속성들을 갖는 객체가 플랫 어레이 객체, 예컨대 Flat Array 타입인지 아닌지의 표시를 제공할 수 있다. 다시 말해, 인덱싱 타입은 어레이 객체가 플랫 어레이 객체인지 아닌지 여부를 나타낸다.
어레이 액세스 또는 할당 사이트(또는 코드 위치)는 런타임 동안에 조우된 어레이들 또는 어레이 객체들 상에 도 2의 런타임 데이터(211)에서의 프로파일링 데이터와 같은 런타임 프로파일링 데이터를 기록하기 위한 대응하는 프로파일링 데이터 구조를 포함할 수 있다. 일 실시예에서, 조우된 어레이 객체들의 인덱싱 타입들은 런타임 프로파일링 데이터에 수집된다.
일 실시예에서, 인덱싱 타입들을 포함하는 프로파일링 데이터는 런타임 최적화를 허용할 수 있다. 예를 들어, 최적화 컴파일러의 타입 시스템은 조우된 어레이 객체들의 형상(또는 Flat Array 타입과 같은 타입들)에 대해 추론하도록 허용될 수 있다. 컴파일러는 플랫 어레이 객체들이 Flat Array 타입의 객체 상에서 동작한다는 가정에 기초하여 코드를 확실하게 생성하도록 컴파일된 실행가능 코드에 런타임 체크를 삽입할 수 있다.
추가로, '플랫도(flatness)'의 개념이 이제 컴파일러의 타입 시스템의 일부이므로, 그것은 핫 루프들(예컨대, 반복되는 또는 반복적으로 실행되는 명령어들)로부터의 이러한 런타임 체크를 향상(또는 최적화)시킬 수 있어서, 예를 들어 프로그램을 실행하는 데 걸리는 시간 또는 그에 요구되는 메모리를 최소화할 수 있다. 컴파일러의 타입 시스템은 타입을 다양한 구성들 - 예컨대, 프로그램의 변수들, 표현식들, 함수들 또는 모듈들 - 에 할당하는 규칙들의 집합을 포함할 수 있다. 컴파일러는 또한 (객체가 플랫 어레이 객체이든 아니든) 이러한 타입 정보를 이용하여, 인라인 저장 어레이 데이터를 활용하여 런타임 메모리 할당의 수를 감소시키고, 간접 메모리 로딩을 제거하고 등등을 하는 코드를 생성할 수 있다.
도 11은 플랫 어레이 객체들에 대해 인라인으로 저장된 어레이 데이터를 지원하는 객체 모델들의 예들을 도시한다. 일례(1100)는, 예를 들어 도 2의 시스템(200)의 일부 컴포넌트들에 기초하여 제공된 예시적인 객체 모델들을 포함할 수 있다. 예를 들어, 객체 셀들(1105, 1107)은 도 2의 런타임(211)과 같은 런타임에서 개별 객체들을 표현하도록 메모리에 연속으로 할당될 수 있다. 객체 셀(1105)은 타입 포인터(또는 구조 포인터)(1109)(예컨대, 8 바이트), 데이터(또는 값) 포인터(1111)(예컨대, 8 바이트), 및 선택적 인라인 저장소(1113)를 포함할 수 있다. 객체 셀(1107)은 타입 포인터(1109)와 공통 크기를 갖는 타입 포인터(1115), 데이터 포인터(1111)와 공통 크기를 갖는 데이터 포인터(1121), 인라인 저장소(1113)와는 상이하게 크기 조정된 인라인 저장소(1123)를 포함할 수 있다.
일 실시예에서, 객체 셀(1105)은 인라인 저장소(1113) 내에 인라인으로 저장되는 인덱싱된 어레이 데이터를 갖는 플랫 어레이 객체를 표현할 수 있다. 데이터 포인터(1111)는 메모리 로딩의 간접접근 없이 객체 셀(1105) 자체 내에서 어레이 데이터의 직접 액세스를 허용하는 인라인 저장소(1113)를 가리킬 수 있다. 인라인 저장소(1113)는, 예를 들어 객체 셀(1107)에 의해 제한된 크기에서 증가하지 않을 수 있다. 타입 포인터(1109)는 인라인 저장소(113)에 저장된 어레이 데이터의 인덱스들(또는 오프셋들)을 저장하는 타입 구조(1101)를 가리킬 수 있다. 일부 실시예들에서, 타입 구조(1101)는 대응하는 객체에 대한 플랫 어레이 타입을 나타내는 인덱싱 타입 필드들(1103)을 포함할 수 있다.
객체 셀(1107)은 속성들을 갖는 객체를 어레이 데이터 및 비어레이 데이터 양측 모두로 표현할 수 있다. 예를 들어, 데이터 포인터(1121)는 저장소 구조(1117)에 대한 구조 데이터 어드레스(1119)에 대응하는 포인터 값을 가질 수 있다. 객체 셀(1107)과 연관된 비어레이 속성 값들 P0, P1 … PN 및 어레이 속성 값들 IP0, IP1 … IPM은 저장소 구조(1117)에 버터플라이 양방향 방식(butterfly bidirectional manner)으로 할당될 수 있다.
도 12는 동적 프로그래밍 언어에서 지정된 객체 데이터 액세스를 최적화하기 위해 인라인으로 어레이 데이터를 동적으로 할당하는 시스템의 일 실시예를 도시한 블록 다이어그램이다. 시스템(1200)은 도 2의 시스템(200)의 일부 컴포넌트들을 포함할 수 있다. 예를 들어, 컴파일러(205)는, 예컨대 코드의 요소들 사이의 통사적 관계 또는 속성들에 대해, 소스 코드(예컨대, 자바스크립트 코드)에 대한 통사적 또는 정적 분석을 수행하는 파서 모듈(parser module)(1205)을 포함할 수 있다. 통사적 분석은, 예컨대 속성 값들(정수, 스트링, 텍스트, 구조 등)의 타입들 또는 소스 코드의 다른 적용가능한 통사적 구조들에 기초하여, 잠재적 어레이 객체들을 식별할 수 있다. 일부 실시예들에서, 어레이 객체(또는 어레이 데이터)에 대한 어레이 데이터의 최대 길이가 통사적 분석의 결과에 기초하여 판정될 수 있다.
컴파일러(205)는, 예를 들어 런타임 프로파일(1209)에서의 프로파일링 데이터 및/또는 사용자 입력들에 기초하여, 런타임 객체들의 가능성있는 타입들을 동적으로 추론하는 객체 타입 예측자 모듈(1207)을 포함할 수 있다. 런타임 프로파일(1209)은 프로그램 실행 동안에, 예를 들어 도 2의 런타임 데이터(211)에, 연속으로 수집될 수 있다. 사용자 입력들은 소정 동적 타입 객체들에 대한 가능성있는 타입들에 대해 프로그램에 의해 또는 사용자 인터페이스 메커니즘들을 통해 수신된 힌트들 또는 휴리스틱스를 포함할 수 있다.
일 실시예에서, 최적화된 어레이 객체 핸들러 모듈(209)은, 예를 들어 객체 타입 예측자(1207)로부터의 타입 예측 정보에 기초하여, 플랫 어레이 객체들을 동적으로 식별할 수 있다. 플랫 어레이 객체가 아닌 어레이 객체에 액세스하기 위한 최적화된 코드는, 예를 들어 정규 어레이 코드 생성 모듈(1201)을 통해 생성될 수 있다. 플랫 어레이 객체들과 같은, 짧거나 제한된 길이의 어레이 데이터는 플랫 어레이 코드 생성기 모듈(1203)로부터 생성된 코드에 기초하여 대응하는 객체 셀들의 인라인 저장소들로부터 직접적으로 액세스될 수 있다.
도 13은 어레이 데이터를 인라인으로 할당하도록 코드를 동적으로 컴파일하는 프로세스의 일 실시예를 도시한 흐름도이다. 예시적인 프로세스(1300)는, 예를 들어 도 2의 시스템(200)의 일부 컴포넌트들을 포함하는 프로세싱 로직에 의해 수행될 수 있다. 블록(1301)에서, 프로세스(1300)의 프로세싱 로직은 동적 언어 기반 프로그램을 실행하기 위해 메모리에 객체 모델을 제공할 수 있다. 객체 모델은 동적 프로그래밍 언어의 소스 코드에서 하나 이상의 속성들로 지정된 객체를 표현할 수 있다. 각각의 속성은 속성 값과 연관된 속성명을 가질 수 있다.
객체 모델은 메모리에 할당되는 객체 셀을 포함할 수 있다. 객체 셀은 값 포인터(또는 데이터 포인터) 및 인라인 저장소를 포함할 수 있다. 값 포인터는 메모리에 할당된 값 저장소들에 저장된 속성 값들에 대한 레퍼런스를 포함할 수 있다. 객체의 속성들은 데이터의 어레이를 표현하는 어레이 관계를 가질 수 있다.
예를 들어, 객체는 도 2의 컴파일러(205)와 같은 컴파일러를 통해 식별가능한 인덱스 타입(또는 인덱싱 타입)과 연관될 수 있다. 인덱스 타입은 제한된(예컨대, 사전결정된) 수의 객체 타입들 중 객체가 어느 것에 속하는지 나타낼 수 있다. 각각의 객체 타입은, 예를 들어 코드 최적화 및/또는 생성을 위해 컴파일러 내의 타입 시스템을 통해 컴파일러와 의미론적으로 연관될 수 있다.
프로세스(1300)의 프로세싱 로직은 런타임 동안에 객체의 타입을 식별할 수 있다. 객체의 타입은 객체에 대해 할당된 객체 셀을 포함하는 객체 모델을 통해 저장될 수 있다. 예를 들어, 객체의 타입은 객체가 어레이 객체인지 또는 비어레이 객체인지 여부 그리고 객체가 어레이 객체인 경우에 객체가 플랫 어레이 객체인지 여부를 나타내는 인덱스 타입일 수 있다.
프로세스(1300)의 프로세싱 로직은 객체의 속성들에서의 어레이 관계의 존재에 따라 객체가 어레이 객체인지 여부를 판정할 수 있다. 예를 들어, 어레이 관계를 갖는 객체의 속성들의 각각의 속성명은 소스 코드에서 어레이 인덱스를 표현하도록 지정될 수 있다.
일 실시예에서, 객체에서의 어레이 관계의 존재는 프로그램 소스 및/또는 실행 런타임 분석 메커니즘들에 기초하여 식별될 수 있다. 예를 들어, 소스 코드에 대한 정적 분석은 객체의 속성명이 어레이 인덱스를 표현할 수 있는 정수 값에 대응하는 것을 나타낼 수 있다.
객체의 인덱스 타입은, 객체가 어레이 객체이고 객체 셀의 인라인 저장소가 객체의 속성 값들 또는 어레이 데이터를 저장하기 위한 충분한 공간(예컨대, 메모리 또는 저장소 공간)으로 크기 조정되는 경우에 플랫 어레이 객체를 나타낼 수 있다. 일 실시예에서, 객체 셀 내의 인라인 저장소는 할당된 인접 객체 셀들 사이의 가용 메모리 공간에 의해 제한될 수 있고, 임의적으로 증가하지 않을 수 있다. 기존 플랫 어레이 객체는, 추가 어레이 요소들이 객체의 속성들에 (예컨대, 런타임 동안에) 추가되고 추가 어레이 요소들을 갖는 속성들의 전체 어레이를 저장하는 데 요구되는 공간이 대응하는 객체 셀 내의 인라인 저장소의 가용 용량을 초과하는 경우에 비플랫 어레이 객체가 될 수 있다.
블록(1303)에서, 프로세스(1300)의 프로세싱 로직은 인라인 저장소가 속성 값을 저장할 정도로 값 저장소들에 대해 충분한 공간으로 크기 조정되는지 여부를 판정할 수 있다. 예를 들어, 데이터의 어레이를 저장하기 위한 저장소 공간의 양은 어레이의 길이(예컨대, 인덱스들의 최대 개수) 및 어레이 요소 각각에 대한 값 타입에 의존할 수 있다. 프로세스(1300)의 프로세싱 로직은 인덱싱된 어레이를 표현하는 객체에 추가되는 속성 값들의 개수에 기초하여 어레이의 길이를 동적으로 검출할 수 있다.
블록(1305)에서, 프로세스(1300)의 프로세싱 로직은 어레이 데이터와 같은 객체의 속성 값들을 저장하는 값 저장소들을 객체에 대응하는 객체 셀의 인라인 저장소 내에 할당할 것인지 또는 객체 셀 외부에 할당할 것인지 판정할 수 있다. 예를 들어, 인라인 저장소가 값 저장소들에 대해 충분한 공간으로 크기 조정되는 경우, 속성 값들은 인라인 저장소에 저장된다. 속성 값들은 인라인 저장소의 크기가 속성 값들을 저장하기 위해 요구되는 크기 미만인 경우에 객체 셀 외부에 또는 라인 외 저장소에 저장될 수 있다. 인덱싱된 어레이 또는 데이터의 어레이를 저장하기 위한 라인 외 저장소는, 예를 들어 기존 플랫 어레이 객체의 인덱스 타입이, 객체가 더 이상 플랫 어레이 타입의 것이 아니라는 것을 나타내도록 업데이트될 때 할당될 수 있다.
일 실시예에서, 플랫 어레이 객체의 인덱스 타입은 어레이 관계에 대한 경계 외 인덱스 값에 대응하는 업데이트 속성명이 플랫 어레이 객체와 연관되는 경우에 객체가 어레이 객체이지만 플랫 어레이 객체가 아니라는 것을 나타내도록 업데이트될 수 있다. 경계 외 인덱스 값은, 예를 들어 플랫 어레이 객체에 대한 객체 셀의 인라인 저장소가 경계 외 인덱스 값의 어레이 길이를 갖는 속성 값들의 어레이를 저장하는 데 불충분한 공간으로 크기 조정된다는 것을 나타낼 수 있다.
일 실시예에서, 객체와 연관된 객체 셀은 객체의 기존 속성명들을 저장하도록 할당된 구조 저장소를 레퍼런스하는 타입 포인터를 포함할 수 있다. 런타임 동안에, 추가 이름 속성명을 갖는 객체의 액세스는 속성 포인터가 기존 속성명들의 복제본들 및 추가 속성명을 저장하는 개별 구조 저장소를 나타내도록(예컨대, 가리키도록) 업데이트되게 할 수 있다. 타입 포인터는 동적 타입 프로그래밍 언어에 기초하여 소스 코드에서 지정된 객체의 동적 타입을 표현할 수 있다. 객체의 인덱스 타입은 타입 포인터, 타입 포인터에 의해 레퍼런스되는 타입 구조, 또는 객체의 객체 셀과 연관된 필드에 저장될 수 있다.
블록(1307)에서, 프로세스(1300)의 프로세싱 로직은 소스 코드에서 지정된 객체의 속성 값들에의 액세스에 대한 명령어들을 생성할 수 있다. 일 실시예에서, 명령어들은 가드 코드, 패스트 코드 경로, 및 슬로우 코드 경로를 포함할 수 있다. 슬로우 코드 경로는 객체를 표현하는 객체 셀 외부에 속성 값들을 저장하는 값 저장소들을 위치시키도록 실행될 수 있다. 예를 들어, 슬로우 코드 경로는 속성 값의 액세스를 수행하도록 객체 셀의 값 포인터 또는 데이터 포인터를 통한 간접 메모리 로딩을 요구할 수 있다. 패스트 코드 경로는 값 포인터를 통해 값 저장소들을 간접적으로 위치시키는 일 없이 객체 셀 내의 속성 값들에 액세스하도록 실행될 수 있다.
일 실시예에서, 가드 코드는 객체의 속성 값들에 액세스하기 위해 슬로우 코드 경로를 작동시킬 것인지 또는 패스트 코드 경로를 작동시킬 것인지 동적으로 판정하도록 실행될 수 있다. 예를 들어, 패스트 코드 경로는, 속성 값들이 어레이 관계를 갖고 객체를 표현하는 객체 셀의 인라인 저장소가 속성 값들을 저장할 값 저장소들로서 충분한 공간으로 크기 조정되는 경우에 작동될 수 있다.
소정 실시예들에서, 패스트 코드 경로를 작동시킬 것인지 여부는 객체의 인덱스 타입에 기초할 수 있다. 예를 들어, 패스트 코드 경로는 객체의 인덱스 타입이 객체가 플랫 어레이 객체임을 나타내는 경우에 가드 코드를 통해 작동될 수 있다. 객체의 속성 값들에 액세스하기 위해 동적으로 생성된 명령어들은 객체를 표현하는 객체 셀에 저장된 값 포인터를 통해 속성 값들에 액세스하는 메모리 로딩 동작을 포함할 수 있다. 객체가 플랫 어레이 객체인 경우, 명령어들은 값 포인터를 통해 (예컨대, 객체 셀 내부로부터 직접적으로) 로딩 동작을 수행하는 일 없이 (예컨대, 값 저장소들에 저장된) 속성 값들을 위치시키도록 실행될 수 있다.
일 실시예에서, 객체에 액세스하기 위한 루프(예컨대, 행렬 동작들, 벡터 동작들, 또는 다른 반복 동작들과 연관됨)가 소스 코드에서 지정될 수 있다. 루프는 객체의 속성 값들에의 다수의 액세스들을 포함할 수 있다. 객체의 인덱스 타입이 객체가 플랫 어레이 객체임을 나타내는 경우, 객체에의 다수의 액세스들에 대해 생성된 명령어들은, 루프에서의 객체에의 각각의 액세스에 대한 개별 가드 코드 대신에, 객체 셀 내에서 직접적으로 객체에의 다수의 액세스들 각각에 대해 패스트 코드 경로를 작동시킬 것인지 여부를 판정하는 하나의 공통 가드 코드를 포함하도록 최적화될 수 있다.
도 14는 인라인으로 할당된 플랫 어레이들을 통해 객체들에 반복적으로 액세스하기 위한 명령어들을 생성하도록 런타임 동안에 플랫 어레이 데이터 타입을 식별하는 프로세스의 일 실시예를 도시한 흐름도이다. 예시적인 프로세스(1400)는, 예를 들어 도 2의 시스템(200)의 일부 컴포넌트들을 포함하는 프로세싱 로직에 의해 수행될 수 있다. 블록(1401)에서, 런타임 동안에 메모리에 객체 모델을 제공하는데, 객체 모델은 소스 코드에서 하나 이상의 속성들로 지정된 객체를 표현하고, 각각의 속성은 속성 값과 연관된 속성명을 가지며, 객체 모델은 메모리에 할당된 객체 셀을 포함하고, 객체 셀은 속성 포인터, 값 포인터 및 인라인 저장소를 가지며, 값 포인터는 속성 값들을 저장하기 위해 할당된 값 저장소를 가리키고, 속성 포인터는 속성명들을 저장하기 위해 할당된 속성 저장소를 가리킨다.
블록(1403)에서, 런타임 동안에 객체에 대한 플랫 어레이 타입을 식별하는데, 여기서 플랫 어레이 타입은 객체가 어레이 구조를 표현함을 나타내고, 객체의 각각의 속성명은 어레이 구조의 인덱스에 대응하고, 객체의 각각의 속성 값은 어레이 구조의 인덱싱된 값에 대응하고, 어레이 구조는 런타임 동안의 제한적 길이의 것이고, 어레이 구조는 값 저장소에 대한 객체 셀의 인라인 저장소 내에 할당된다.
블록(1405)에서, 소스 코드에서 지정된 객체의 반복 액세스에 대한 명령어들을 생성하는데, 여기서 객체의 반복 액세스는 객체의 개별 속성 값들에의 복수의 액세스들에 대응하고, 명령어들은 가드 코드, 복수의 패스트 코드 경로들 및 슬로우 코드 경로를 포함하고, 슬로우 코드 경로는 셀 객체 외부의 값 저장소를 위치시키는 값 포인터를 통해 값 저장소들을 위치시켜서 속성 값의 반복 액세스를 수행하고, 패스트 코드 경로는 객체의 인덱스 타입을 체크하는 일 없이 객체 셀 내에서 개별 속성 값들에의 복수의 액세스들을 수행하고, 가드 코드는 객체에의 반복 액세스를 위해 슬로우 코드 경로를 작동시킬 것인지 또는 패스트 코드 경로를 작동시킬 것인지 판정하고, 패스트 코드 경로는 객체의 플랫 어레이 타입이 식별된 경우에 작동된다.
도 15는 본 발명의 일 실시예에서 사용될 수 있는, 컴퓨터 시스템과 같은 데이터 프로세싱 시스템의 일례를 도시한다. 예를 들어, 시스템(1500)은 도 1에 도시된 시스템의 일부로서 구현될 수 있다. 도 15가 컴퓨터 시스템의 다양한 컴포넌트들을 도시하고 있지만, 그것은 그러한 상세사항이 본 발명과 밀접한 관련이 없기 때문에 그 컴포넌트들을 상호접속시키는 임의의 특정 아키텍처 또는 방식을 나타내도록 의도되지 않는다는 것에 유의한다. 또한, 더 적은 컴포넌트들 또는 아마도 더 많은 컴포넌트들을 갖는 네트워크 컴퓨터들 및 다른 데이터 프로세싱 시스템들이 또한 본 발명에 사용될 수 있다는 것이 이해될 것이다.
도 15에 도시된 바와 같이, 데이터 프로세싱 시스템의 일 형태인 컴퓨터 시스템(1500)은 마이크로프로세서(들)(1505), ROM(Read Only Memory)(1507), 휘발성 RAM(1509), 및 비휘발성 메모리(1511)에 커플링된 버스(1503)를 포함한다. 마이크로프로세서(1505)는 메모리들(1507, 1509, 1511)로부터 명령어들을 검색할 수 있고, 상기에 기술된 동작들을 수행하도록 명령어들을 실행할 수 있다. 버스(1503)는 이러한 다양한 컴포넌트들을 함께 상호접속시키고, 또한 이러한 컴포넌트들(1505, 1507, 1509, 1511)을 디스플레이 제어기 및 디스플레이 디바이스(1513)에 그리고 마우스, 키보드, 모뎀, 네트워크 인터페이스, 프린터, 및 당업계에 주지되어 있는 다른 디바이스들일 수 있는 입력/출력(I/O) 디바이스들과 같은 주변기기 디바이스들에 상호접속시킨다. 전형적으로, 입력/출력 디바이스들(1515)은 입력/출력 제어기들(1517)을 통해 시스템에 커플링된다. 휘발성 RAM(Random Access Memory)(1509)은, 전형적으로, 메모리에서 데이터를 리프레시시키거나 유지하기 위해 전력을 지속적으로 요구하는 동적 RAM(DRAM)으로서 구현된다.
대량 저장소(1511)는, 전형적으로, 자기 하드 드라이브, 자기 광 드라이브, 광 드라이브, DVD RAM, 플래시 메모리, 또는 전력이 시스템으로부터 제거된 후에도 데이터(예컨대, 다량의 데이터)를 유지하는 다른 유형의 메모리 시스템들이다. 전형적으로, 대량 저장소(1511)는 또한 랜덤 액세스 메모리일 것이지만, 이것이 요구되지는 않는다. 도 15는 대량 저장소(1511)가 데이터 프로세싱 시스템 내의 컴포넌트들 중 나머지에 직접적으로 커플링된 로컬 디바이스임을 도시하고 있지만, 본 발명은 모뎀 또는 이더넷 인터페이스 또는 무선 네트워킹 인터페이스와 같은 네트워크 인터페이스를 통해 데이터 프로세싱 시스템에 커플링된 네트워크 저장 디바이스와 같은, 시스템으로부터 떨어져 있는 비휘발성 메모리를 활용할 수 있다는 것이 이해될 것이다. 버스(1503)는 당업계에 주지되어 있는 바와 같은 다양한 브리지들, 제어기들, 및/또는 어댑터들을 통해 서로 접속되는 하나 이상의 버스들을 포함할 수 있다.
상기에 기술된 것들 중 일부는 전용 로직 회로와 같은 로직 회로로 구현되거나, 마이크로제어기 또는 프로그램 코드 명령어들을 실행시키는 다른 형태의 프로세싱 코어로 구현될 수 있다. 따라서, 상기 논의에 의해 교시되는 프로세스는 이들 명령어를 실행시키는 기계가 소정의 기능을 수행하게 하는 기계 실행가능 명령어들과 같은 프로그램 코드로 수행될 수 있다. 이와 관련하여, "기계"는 중간 형태(또는 "추상적") 명령어들을 프로세서 특정 명령어들(예컨대, "가상 기계"(예컨대, 자바 가상 기계), 인터프리터, 공통 언어 런타임, 고급 언어 가상 기계 등과 같은 추상적 실행 환경)로 변환하는 기계, 및/또는 범용 프로세서 및/또는 특수 목적 프로세서와 같은, 명령어들을 실행하도록 설계된 반도체 칩(예컨대, 트랜지스터들로 구현된 "로직 회로") 상에 배치되는 전자 회로일 수 있다. 상기 논의에 의해 교시되는 프로세스는 또한 (기계에 대한 대안으로 또는 기계와 조합하여) 프로그램 코드의 실행 없이 프로세스(또는 그의 일부)를 수행하도록 설계된 전자 회로에 의해 수행될 수 있다.
제조 물품이 프로그램 코드를 저장하는 데 사용될 수 있다. 프로그램 코드를 저장하는 제조 물품은 하나 이상의 메모리(예컨대, 하나 이상의 플래시 메모리, 랜덤 액세스 메모리(정적, 동적 또는 기타)), 광 디스크, CD-ROM, DVD ROM, EPROM, EEPROM, 자기 또는 광학 카드, 또는 전자 명령어들을 저장하는 데 적합한 다른 유형의 기계 판독가능 매체로서 구현될 수 있지만, 이들로 제한되지 않는다. 프로그램 코드는 또한 (예컨대, 통신 링크(예컨대, 네트워크 접속)를 통해) 전파 매체에 구현되는 데이터 신호에 의해 원격 컴퓨터(예컨대, 서버)로부터 요청 컴퓨터(예컨대, 클라이언트)로 다운로딩될 수 있다.
상기의 상세한 설명은 컴퓨터 메모리 내의 데이터 비트에 대한 동작들의 알고리즘 및 심볼 표현의 관점에서 제시된다. 이들 알고리즘 설명 및 표현은 데이터 처리 분야의 당업자에 의해 사용되어 그의 작업 요지를 다른 당업자에게 가장 효과적으로 전하기 위한 툴이다. 알고리즘은 여기서 그리고 일반적으로 바람직한 결과로 이어지는 동작들의 자기-무모순 시퀀스(self-consistent sequence)인 것으로 이해된다. 그 동작들은 물리적 양들의 물리적 조작을 요구하는 것들이다. 보통, 필수적인 것은 아니지만, 이들 양은 저장, 전송, 조합, 비교, 및 달리 조작될 수 있는 전기 또는 자기 신호의 형태를 취한다. 주로 공통 사용의 이유로, 이들 신호를 비트, 값, 요소, 심볼, 문자, 용어, 수 등으로 언급하는 것이 때때로 편리한 것으로 판명되었다.
그러나, 이들 및 유사한 용어들 모두는 적절한 물리적 양들과 관련될 것이며 단지 이들 양에 적용되는 편리한 라벨들임을 명심해야 한다. 상기 논의로부터 자명한 바와 같이, 명시적으로 달리 언급되지 않는 한, 설명 전반에 걸쳐, "프로세싱하는" 또는 "컴퓨팅하는" 또는 "계산하는" 또는 "판정하는" 또는 "디스플레이하는" 등과 같은 용어를 사용한 논의는 컴퓨터 시스템의 레지스터 및 메모리 내의 물리적 (전자) 양으로 표현되는 데이터를, 컴퓨터 시스템 메모리 또는 레지스터 또는 다른 그러한 정보 저장, 전송 또는 디스플레이 디바이스 내의 물리적 양으로 유사하게 표현되는 다른 데이터로 조작 및 변환하는 컴퓨터 시스템 또는 유사한 전자 컴퓨팅 디바이스의 작용 및 프로세스를 지칭함이 이해된다.
본 발명은 또한 본 명세서에 기술된 동작을 수행하기 위한 장치에 관한 것이다. 이러한 장치는 요구되는 목적을 위해 특별하게 구성될 수 있거나, 그것은 컴퓨터에 저장된 컴퓨터 프로그램에 의해 선택적으로 활성화되거나 재구성되는 범용 컴퓨터를 포함할 수 있다. 그러한 컴퓨터 프로그램은 플로피 디스크, 광 디스크, CD-ROM, 및 자기-광 디스크를 비롯한 임의의 유형의 디스크, 판독 전용 메모리(ROM), RAM, EPROM, EEPROM, 자기 또는 광학 카드, 또는 전자 명령어들을 저장하기에 적합하고 컴퓨터 시스템 버스에 각각 커플링된 임의의 유형의 매체들과 같은 - 그러나 이들로 제한되지 않음 - 컴퓨터 판독가능 저장 매체에 저장될 수 있다.
본 명세서에 제시된 프로세스 및 디스플레이는 내재적으로 임의의 특정 컴퓨터 또는 다른 장치에 관련되지 않는다. 다양한 범용 시스템이 본 명세서의 교시에 따라 프로그램과 함께 사용될 수 있거나, 기술된 동작들을 수행하도록 보다 특수화된 장치를 구성하는 것이 편리한 것으로 판명될 수 있다. 다양한 이들 시스템에 요구되는 구조가 하기의 기술로부터 명백할 것이다. 또한, 본 발명은 임의의 특정의 프로그래밍 언어를 참조하여 기술되어 있지 않다. 다양한 프로그래밍 언어가 본 명세서에 기술된 바와 같은 본 발명의 교시를 구현하는 데 사용될 수 있음이 이해될 것이다.
상기 논의는 단지 본 발명의 일부 예시적인 실시예들을 기술한다. 당업자는, 그러한 논의, 첨부 도면 및 청구범위로부터, 본 발명의 사상 및 범주로부터 벗어남이 없이 다양한 수정이 이루어질 수 있다는 것을 용이하게 인식할 것이다.

Claims (20)

  1. 기계에 의해 실행될 때, 상기 기계로 하여금 방법을 수행하게 하는 명령어들을 내부에 갖는 기계 판독가능한 비일시적 저장 매체로서,
    상기 방법은,
    런타임 동안에 메모리에 객체 모델을 제공하는 단계 - 상기 객체 모델은 소스 코드에서 하나 이상의 속성들로 지정된 객체를 표현하고, 각각의 속성은 속성 값과 연관된 속성명을 가지며, 상기 객체의 상기 속성들은 어레이 관계를 가지며, 상기 객체 모델은 메모리에 할당된 객체 셀을 포함하고, 상기 객체 셀은 값 포인터 및 인라인 저장소를 가지며, 상기 값 포인터는 상기 메모리에 할당된 값 저장소들에 저장된 상기 속성 값들에 대한 레퍼런스(reference)에 대한 것임 -;
    상기 인라인 저장소가 상기 값 저장소들에 대해 상기 속성 값들을 저장할 정도로 충분한 공간으로 크기 조정되는지 여부를 판정하는 단계;
    상기 인라인 저장소가 상기 값 저장소들에 대해 충분한 공간으로 크기 조정된 경우에 상기 객체 셀의 상기 인라인 저장소 내에 상기 값 저장소들을 할당하는 단계 - 상기 값 저장소들은 상기 인라인 저장소가 상기 값 저장소들에 대해 불충분한 공간으로 크기 조정된 경우에 상기 객체 셀의 외부에 할당됨 -; 및
    상기 소스 코드에서 지정된 상기 객체의 상기 속성 값들에의 액세스에 대한 명령어들을 생성하는 단계 - 상기 명령어들은 가드 코드(guard code), 패스트 코드 경로, 및 슬로우 코드 경로를 포함하고, 상기 슬로우 코드 경로는 상기 값 포인터를 통해 상기 객체 셀의 외부에 상기 값 저장소들을 위치시켜서 상기 속성 값의 상기 액세스를 수행하고, 상기 패스트 코드 경로는 상기 값 포인터를 통해 상기 값 저장소들을 위치시키는 일 없이 상기 객체 셀 내의 상기 속성 값들의 상기 액세스를 수행하고, 상기 가드 코드는 상기 속성 값들에의 상기 액세스를 위해 상기 슬로우 코드 경로를 작동시킬 것인지 또는 상기 패스트 코드 경로를 작동시킬 것인지 판정하고, 상기 패스트 코드 경로는, 상기 속성 값들이 상기 어레이 관계를 갖고 상기 객체 셀의 상기 인라인 저장소가 상기 값 저장소들에 대해 상기 속성 값들을 저장할 정도로 충분한 공간으로 크기 조정된 경우에 작동됨 - 를 포함하는, 기계 판독가능한 비일시적 저장 매체.
  2. 제1항에 있어서, 상기 객체는 인덱스 타입과 연관되고, 상기 인덱스 타입은 상기 객체가 다수의 객체 타입들 중 어느 객체 타입에 속하는지 나타내고, 상기 방법은,
    상기 런타임 동안에 상기 객체의 상기 인덱스 타입을 식별하는 단계; 및
    상기 객체 셀을 통해 상기 객체의 상기 인덱스 타입을 저장하는 단계 - 상기 명령어들의 상기 가드 코드는 상기 객체의 상기 인덱스 타입에 기초하여 상기 패스트 코드 경로를 작동시킬지 여부를 판정함 - 를 추가로 포함하는, 기계 판독가능한 비일시적 저장 매체.
  3. 제2항에 있어서, 상기 인덱스 타입은 상기 객체가 어레이 객체인지 비어레이 객체인지 나타내고, 상기 객체는 상기 어레이 관계가 상기 객체의 상기 속성들 사이에 존재하는 경우에 어레이 객체인, 기계 판독가능한 비일시적 저장 매체.
  4. 제3항에 있어서, 상기 인덱스 타입은 상기 객체가 플랫 어레이 객체인지 비플랫 어레이 객체인지 나타내고, 상기 객체는 상기 객체가 어레이 객체이고 상기 객체 셀의 상기 인라인 저장소가 상기 속성 값들을 저장하기 위한 충분한 공간으로 크기 조정된 경우에 플랫 어레이 객체인, 기계 판독가능한 비일시적 저장 매체.
  5. 제4항에 있어서, 상기 패스트 코드 경로는 상기 인덱스 타입이 상기 객체가 플랫 어레이 객체임을 나타내는 경우에 상기 가드 코드를 통해 작동되는, 기계 판독가능한 비일시적 저장 매체.
  6. 제4항에 있어서, 상기 명령어들은 상기 값 포인터를 통해 상기 값 저장소들을 위치시키는 로딩 동작을 포함하고, 상기 명령어들은 상기 객체가 플랫 어레이 객체인 경우에 상기 값 포인터를 통해 상기 로딩 동작을 수행하는 일 없이 상기 값 저장소들을 위치시키도록 실행되는, 기계 판독가능한 비일시적 저장 매체.
  7. 제4항에 있어서, 상기 소스 코드는 상기 객체에 액세스하기 위한 루프를 지정하고, 상기 루프는 상기 액세스, 및 상기 객체의 상기 속성 값들에의 적어도 하나의 개별 액세스를 포함하고, 상기 방법은,
    상기 인덱스 타입이 상기 객체가 플랫 어레이 객체임을 나타내는 경우에 상기 객체에의 상기 액세스에 대한 상기 명령어들을 최적화하는 단계 - 상기 최적화된 명령어들은 상기 가드 코드를 포함하지 않고, 상기 패스트 경로는 상기 루프에 대해 생성된 공통 가드 코드를 통해 작동됨 - 를 추가로 포함하는, 방법.
  8. 제2항에 있어서, 상기 객체의 상기 속성 값들에의 각각의 액세스는 상기 메모리에 할당된 런타임 프로파일과 연관되고, 상기 명령어들은 상기 런타임 프로파일에서 상기 객체에 대해 액세스된 상기 속성 값들의 타입들을 동적으로 기록하는 프로파일링 코드를 포함하는, 기계 판독가능한 비일시적 저장 매체.
  9. 제8항에 있어서, 상기 런타임 프로파일은 상기 객체와 연관된 값 타입들의 이력을 포함하고, 상기 객체의 상기 인덱스 타입의 상기 식별은 상기 런타임 프로파일에 기록된 상기 이력에 기초하는, 기계 판독가능한 비일시적 저장 매체.
  10. 제9항에 있어서, 상기 식별 단계는,
    상기 런타임 프로파일에 기초하여 상기 어레이 관계에 대한 어레이 길이를 검출하는 단계를 포함하고, 상기 검출 단계는 상기 객체가 플랫 어레이 객체인 경우에 상기 런타임 동안에 상기 어레이 길이가 고정 경계 내에서 유지됨을 나타내는, 기계 판독가능한 비일시적 저장 매체.
  11. 제2항에 있어서,
    상기 객체의 상기 속성들로부터 상기 어레이 관계를 식별하는 단계 - 상기 어레이 관계가 식별되는 경우에 각각의 속성명이 상기 소스 코드에서 어레이 인덱스를 표현하도록 지정됨 - 를 추가로 포함하는, 기계 판독가능한 비일시적 저장 매체.
  12. 제11항에 있어서, 상기 식별은 상기 소스 코드의 정적 분석에 기초하고, 상기 정적 분석은 각각의 속성명이 상기 어레이 인덱스를 표현하는 정수 값에 대응함을 나타내는, 기계 판독가능한 비일시적 저장 매체.
  13. 제1항에 있어서, 상기 객체 셀은 상기 속성들의 속성명들을 저장하도록 상기 메모리에 할당된 구조 저장소를 레퍼런스하는 타입 포인터를 포함하고, 상기 타입 포인터는 상기 객체가 상기 속성명들에 속하지 않는 새로운 속성명으로 액세스되는 경우에 상기 런타임 동안에 상기 새로운 속성명 및 상기 속성명들의 복제본들을 저장하는 개별 구조 저장소를 나타내도록 업데이트되는, 기계 판독가능한 비일시적 저장 매체.
  14. 제13항에 있어서, 상기 인덱스 타입은 상기 새로운 속성명이 상기 어레이 관계에 대한 경계 외 인덱스 값(out of bound index value)에 대응하는 경우에 상기 객체가 어레이 객체임을 나타내도록 업데이트되고, 상기 객체 셀의 상기 인라인 저장소는 상기 경계 외 인덱스 값의 어레이 길이를 갖는 상기 속성 값들의 어레이를 저장하기에 불충분한 공간으로 크기 조정되는, 기계 판독가능한 비일시적 저장 매체.
  15. 제14항에 있어서, 상기 방법은,
    상기 인덱스 타입이 상기 객체가 플랫 어레이 객체가 아님을 나타내도록 업데이트되는 경우에 상기 객체에 대한 상기 속성 값들을 저장하도록 상기 메모리 내의 라인 외 저장소(out of line storage) - 상기 라인 외 저장소는 상기 메모리 내의 상기 객체 셀과는 별개임 - 를 할당하는 단계를 추가로 포함하는, 기계 판독가능한 비일시적 저장 매체.
  16. 제13항에 있어서, 상기 소스 코드는 동적 타입 프로그래밍 언어에 기초하고, 상기 타입 포인터는 상기 객체의 동적 타입을 표현하도록 상기 런타임 동안에 동적으로 업데이트되는, 기계 판독가능한 비일시적 저장 매체.
  17. 제13항에 있어서, 상기 저장소 구조는 타입 필드를 포함하고, 상기 객체의 상기 인덱스 타입은 상기 타입 필드에 저장되는, 기계 판독가능한 비일시적 저장 매체.
  18. 기계에 의해 실행될 때, 상기 기계로 하여금 방법을 수행하게 하는 명령어들을 내부에 갖는 기계 판독가능한 비일시적 저장 매체로서,
    상기 방법은,
    런타임 동안에 메모리에 객체 모델을 제공하는 단계 - 상기 객체 모델은 소스 코드에서 하나 이상의 속성들로 지정된 객체를 표현하고, 각각의 속성은 속성 값과 연관된 속성명을 가지며, 상기 객체 모델은 메모리에 할당된 객체 셀을 포함하고, 상기 객체 셀은 속성 포인터, 값 포인터, 및 인라인 저장소를 가지며, 상기 값 포인터는 상기 속성 값들을 저장하기 위해 할당된 값 저장소를 가리키고, 상기 속성 포인터는 상기 속성명들을 저장하기 위해 할당된 속성 저장소를 가리킴 -;
    런타임 동안에 상기 객체에 대한 플랫 어레이 타입을 식별하는 단계 - 상기 플랫 어레이 타입은 상기 객체가 어레이 구조를 표현함을 나타내고, 상기 객체의 각각의 속성명은 상기 어레이 구조의 인덱스에 대응하고, 상기 객체의 각각의 속성 값은 상기 어레이 구조의 인덱싱된 값에 대응하고, 상기 어레이 구조는 상기 런타임 동안의 제한적 길이의 것이고, 상기 어레이 구조는 상기 값 저장소에 대해 상기 객체 셀의 상기 인라인 저장소 내에 할당됨 -; 및
    상기 소스 코드에서 지정된 상기 객체의 반복 액세스에 대한 명령어들을 생성하는 단계 - 상기 객체의 상기 반복 액세스는 상기 객체의 개별 속성 값들에의 복수의 액세스들에 대응하고, 상기 명령어들은 가드 코드, 복수의 패스트 코드 경로들, 및 슬로우 코드 경로를 포함하고, 상기 슬로우 코드 경로는 상기 셀 객체의 외부에 상기 값 저장소를 위치시키는 상기 값 포인터를 통해 상기 값 저장소들을 위치시켜서 상기 속성 값의 상기 반복 액세스를 수행하고, 상기 패스트 코드 경로는 상기 객체의 상기 인덱스 타입을 체크하는 일 없이 상기 객체 셀 내의 상기 개별 속성 값들에의 상기 복수의 액세스들을 수행하고, 상기 가드 코드는 상기 객체에의 상기 반복 액세스를 위해 상기 슬로우 코드 경로를 작동시킬 것인지 상기 패스트 코드 경로를 작동시킬 것인지 판정하고, 상기 패스트 코드 경로는 상기 객체의 상기 플랫 어레이 타입이 식별되는 경우에 작동됨 - 를 포함하는, 기계 판독가능한 비일시적 저장 매체.
  19. 컴퓨터 구현 방법으로서,
    런타임 동안에 메모리에 객체 모델을 제공하는 단계 - 상기 객체 모델은 소스 코드에서 하나 이상의 속성들로 지정된 객체를 표현하고, 각각의 속성은 속성 값과 연관된 속성명을 가지며, 상기 객체 모델은 메모리에 할당된 객체 셀을 포함하고, 상기 객체 셀은 속성 포인터, 값 포인터, 및 인라인 저장소를 가지며, 상기 값 포인터는 상기 속성 값들을 저장하기 위해 할당된 값 저장소를 가리키고, 상기 속성 포인터는 상기 속성명들을 저장하기 위해 할당된 속성 저장소를 가리킴 -;
    런타임 동안에 상기 객체에 대한 플랫 어레이 타입을 식별하는 단계 - 상기 플랫 어레이 타입은 상기 객체가 어레이 구조를 표현함을 나타내고, 상기 객체의 각각의 속성명은 상기 어레이 구조의 인덱스에 대응하고, 상기 객체의 각각의 속성 값은 상기 어레이 구조의 인덱싱된 값에 대응하고, 상기 어레이 구조는 상기 런타임 동안의 제한적 길이의 것이고, 상기 어레이 구조는 상기 값 저장소에 대해 상기 객체 셀의 상기 인라인 저장소 내에 할당됨 -; 및
    상기 소스 코드에서 지정된 상기 객체의 반복 액세스에 대한 명령어들을 생성하는 단계 - 상기 객체의 상기 반복 액세스는 상기 객체의 개별 속성 값들에의 복수의 액세스들에 대응하고, 상기 명령어들은 가드 코드, 복수의 패스트 코드 경로들, 및 슬로우 코드 경로를 포함하고, 상기 슬로우 코드 경로는 상기 셀 객체의 외부에 상기 값 저장소를 위치시키는 상기 값 포인터를 통해 상기 값 저장소들을 위치시켜서 상기 속성 값의 상기 반복 액세스를 수행하고, 상기 패스트 코드 경로는 상기 객체의 상기 인덱스 타입을 체크하는 일 없이 상기 객체 셀 내의 상기 개별 속성 값들에의 상기 복수의 액세스들을 수행하고, 상기 가드 코드는 상기 객체에의 상기 반복 액세스를 위해 상기 슬로우 코드 경로를 작동시킬 것인지 상기 패스트 코드 경로를 작동시킬 것인지 판정하고, 상기 패스트 코드 경로는 상기 객체의 상기 플랫 어레이 타입이 식별되는 경우에 작동됨 - 를 포함하는, 컴퓨터 구현 방법.
  20. 컴퓨터 시스템으로서,
    데이터 프로세싱 태스크를 수행하기 위해 명령어들 및 소스 코드를 저장하는 메모리 - 상기 소스 코드는 객체에의 반복 액세스를 지정함 -; 및
    상기 메모리에 커플링되어 상기 메모리로부터의 상기 명령어들을 실행하는 프로세서를 포함하고,
    상기 프로세서는,
    런타임 동안에 상기 메모리에 객체 모델을 제공하도록 - 상기 객체 모델은 상기 소스 코드에서 하나 이상의 속성들로 지정된 상기 객체를 표현하고, 각각의 속성은 속성 값과 연관된 속성명을 가지며, 상기 객체 모델은 메모리에 할당된 객체 셀을 포함하고, 상기 객체 셀은 속성 포인터, 값 포인터, 및 인라인 저장소를 가지며, 상기 값 포인터는 상기 속성 값들을 저장하기 위해 할당된 값 저장소를 가리키고, 상기 속성 포인터는 상기 속성명들을 저장하기 위해 할당된 속성 저장소를 가리킴 -;
    런타임 동안에 상기 객체에 대한 플랫 어레이 타입을 식별하도록 - 상기 플랫 어레이 타입은 상기 객체가 어레이 구조를 표현함을 나타내고, 상기 객체의 각각의 속성명은 상기 어레이 구조의 인덱스에 대응하고, 상기 객체의 각각의 속성 값은 상기 어레이 구조의 인덱싱된 값에 대응하고, 상기 어레이 구조는 상기 런타임 동안의 제한적 길이의 것이고, 상기 어레이 구조는 상기 값 저장소에 대해 상기 객체 셀의 상기 인라인 저장소 내에 할당됨 -; 그리고
    상기 소스 코드에서 지정된 상기 객체의 상기 반복 액세스에 대한 명령어들을 생성하도록 - 상기 객체의 상기 반복 액세스는 상기 객체의 개별 속성 값들에의 복수의 액세스들에 대응하고, 상기 명령어들은 가드 코드, 복수의 패스트 코드 경로들, 및 슬로우 코드 경로를 포함하고, 상기 슬로우 코드 경로는 상기 셀 객체의 외부에 상기 값 저장소를 위치시키는 상기 값 포인터를 통해 상기 값 저장소들을 위치시켜서 상기 속성 값의 상기 반복 액세스를 수행하고, 상기 패스트 코드 경로는 상기 객체의 상기 인덱스 타입을 체크하는 일 없이 상기 객체 셀 내의 상기 개별 속성 값들에의 상기 복수의 액세스들을 수행하고, 상기 가드 코드는 상기 객체에의 상기 반복 액세스를 위해 상기 슬로우 코드 경로를 작동시킬 것인지 상기 패스트 코드 경로를 작동시킬 것인지 판정하고, 상기 패스트 코드 경로는 상기 객체의 상기 플랫 어레이 타입이 식별되는 경우에 작동됨 - 구성되는, 컴퓨터 시스템.
KR1020167005489A 2013-08-30 2014-08-25 동적 타입 어레이 객체들에 액세스할 시의 크기 의존적 타입 KR101872625B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361872386P 2013-08-30 2013-08-30
US61/872,386 2013-08-30
US14/280,377 US9672152B2 (en) 2013-08-30 2014-05-16 Size dependent type in accessing dynamically typed array objects
US14/280,377 2014-05-16
PCT/US2014/052581 WO2015031286A1 (en) 2013-08-30 2014-08-25 Size dependent type in accessing dynamically typed array objects

Publications (2)

Publication Number Publication Date
KR20160040257A true KR20160040257A (ko) 2016-04-12
KR101872625B1 KR101872625B1 (ko) 2018-08-02

Family

ID=52584914

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020167005435A KR101778479B1 (ko) 2013-08-30 2014-08-22 동적 타입 객체들에 액세스함에 있어서의 동시 인라인 캐시 최적화
KR1020167005494A KR101769260B1 (ko) 2013-08-30 2014-08-22 동적 타입 객체 데이터의 동시 액세스
KR1020167005489A KR101872625B1 (ko) 2013-08-30 2014-08-25 동적 타입 어레이 객체들에 액세스할 시의 크기 의존적 타입

Family Applications Before (2)

Application Number Title Priority Date Filing Date
KR1020167005435A KR101778479B1 (ko) 2013-08-30 2014-08-22 동적 타입 객체들에 액세스함에 있어서의 동시 인라인 캐시 최적화
KR1020167005494A KR101769260B1 (ko) 2013-08-30 2014-08-22 동적 타입 객체 데이터의 동시 액세스

Country Status (5)

Country Link
US (3) US9251071B2 (ko)
EP (3) EP3039536B1 (ko)
KR (3) KR101778479B1 (ko)
CN (3) CN105493042B (ko)
WO (3) WO2015031192A1 (ko)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10482194B1 (en) * 2013-12-17 2019-11-19 EMC IP Holding Company LLC Simulation mode modification management of embedded objects
US9104434B2 (en) * 2013-12-20 2015-08-11 Microsoft Technology Licensing, Llc Property accesses in dynamically typed programming languages
US9207914B2 (en) 2013-12-20 2015-12-08 Microsoft Technology Licensing, Llc Execution guards in dynamic programming
US9740504B2 (en) * 2014-01-23 2017-08-22 Qualcomm Incorporated Hardware acceleration for inline caches in dynamic languages
US9710388B2 (en) 2014-01-23 2017-07-18 Qualcomm Incorporated Hardware acceleration for inline caches in dynamic languages
US10776378B2 (en) * 2014-07-09 2020-09-15 Oracle Interntional Corporation System and method for use of immutable accessors with dynamic byte arrays
EP3086233B1 (en) * 2015-04-23 2020-05-06 CODESYS Holding GmbH Method and system for measuring a runtime by means of watchpoints
US10614126B2 (en) 2015-05-21 2020-04-07 Oracle International Corporation Textual query editor for graph databases that performs semantic analysis using extracted information
JP6603495B2 (ja) * 2015-07-01 2019-11-06 株式会社Ｌｉｘｉｌ 抗菌・抗ウィルス性コーティング剤
US10127025B2 (en) * 2015-07-22 2018-11-13 Oracle International Corporation Optimization techniques for high-level graph language compilers
US10025582B2 (en) 2015-12-10 2018-07-17 International Business Machines Corporation Applying program patch sets
US9971570B2 (en) 2015-12-15 2018-05-15 Oracle International Corporation Automated generation of memory consumption aware code
CN106897051B (zh) * 2015-12-24 2022-01-25 北京奇虎科技有限公司 一种进程清理的方法及装置
US11263110B1 (en) * 2015-12-31 2022-03-01 EMC IP Holding Company LLC Inter-object validation system and method for the objects of a test system
CN105912398A (zh) * 2016-04-06 2016-08-31 北京小米移动软件有限公司 内存检测方法及装置
US9952982B2 (en) * 2016-06-06 2018-04-24 International Business Machines Corporation Invoking demote threads on processors to demote tracks indicated in demote ready lists from a cache when a number of free cache segments in the cache is below a free cache segment threshold
US9852202B1 (en) * 2016-09-23 2017-12-26 International Business Machines Corporation Bandwidth-reduced coherency communication
CN108920149B (zh) * 2017-03-29 2020-12-08 华为技术有限公司 编译方法和编译装置
CN108694185B (zh) * 2017-04-07 2021-06-04 成都阜特科技股份有限公司 一种数据存储与提取的方法
US10691609B2 (en) 2017-07-24 2020-06-23 International Business Machines Corporation Concurrent data erasure and replacement of processors
US10585945B2 (en) 2017-08-01 2020-03-10 Oracle International Corporation Methods of graph-type specialization and optimization in graph algorithm DSL compilation
US10866806B2 (en) * 2017-11-14 2020-12-15 Nvidia Corporation Uniform register file for improved resource utilization
CN108154463B (zh) * 2017-12-06 2021-12-24 中国航空工业集团公司西安航空计算技术研究所 一种模型化gpu显存系统管理方法
CN108647241A (zh) * 2018-04-09 2018-10-12 宁波诺信睿聚投资有限责任公司 数据存储方法、装置、计算机设备及计算机可读存储介质
US10552185B2 (en) * 2018-05-24 2020-02-04 International Business Machines Corporation Lightweight and precise value profiling
CN110825531B (zh) * 2018-08-14 2023-05-30 斑马智行网络(香港)有限公司 针对动态类型语言的优化方法、装置、设备以及存储介质
CN110908850A (zh) * 2018-09-14 2020-03-24 阿里巴巴集团控股有限公司 数据获取方法及装置
CN109725955A (zh) * 2018-12-30 2019-05-07 北京城市网邻信息技术有限公司 一种访问对象属性方法、装置、设备及存储介质
US11880669B2 (en) 2019-10-08 2024-01-23 Intel Corporation Reducing compiler type check costs through thread speculation and hardware transactional memory
CN110753056B (zh) * 2019-10-25 2022-05-13 高秀芬 一种非交互式加密访问控制方法
CN110825369A (zh) * 2019-11-07 2020-02-21 四川长虹电器股份有限公司 一种基于java语言的代码自动生成的方法
US11188316B2 (en) 2020-03-09 2021-11-30 International Business Machines Corporation Performance optimization of class instance comparisons
US11275671B2 (en) * 2020-07-27 2022-03-15 Huawei Technologies Co., Ltd. Systems, methods and media for dynamically shaped tensors using liquid types
US11487565B2 (en) * 2020-10-29 2022-11-01 Hewlett Packard Enterprise Development Lp Instances of just-in-time (JIT) compilation of code using different compilation settings
US11307834B1 (en) * 2020-11-11 2022-04-19 Fileonq, Inc. Platform for rapid application development
CN112957068B (zh) * 2021-01-29 2023-07-11 青岛海信医疗设备股份有限公司 超声信号处理方法及终端设备
US11940994B2 (en) * 2021-10-29 2024-03-26 Salesforce, Inc. Mechanisms for maintaining chains without locks
US20230229525A1 (en) * 2022-01-20 2023-07-20 Dell Products L.P. High-performance remote atomic synchronization
CN115373645B (zh) * 2022-10-24 2023-02-03 济南新语软件科技有限公司 一种基于可动态定义的复杂数据包操作方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120030661A1 (en) * 2010-07-30 2012-02-02 Apple Inc. Observation and analysis based code optimization
US8392881B1 (en) * 2008-05-13 2013-03-05 Google Inc. Supporting efficient access to object properties in a dynamic object-oriented programming language
US20130205286A1 (en) * 2012-02-03 2013-08-08 Apple Inc. Runtime optimization using meta data for dynamic programming languages

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815719A (en) * 1996-05-07 1998-09-29 Sun Microsystems, Inc. Method and apparatus for easy insertion of assembler code for optimization
US5915114A (en) * 1997-02-14 1999-06-22 Hewlett-Packard Company Dynamic trace driven object code optimizer
GB2377283B (en) * 2001-04-10 2004-12-01 Discreet Logic Inc Initialising modules
US7062761B2 (en) 2001-07-10 2006-06-13 Micron Technology, Inc. Dynamic arrays and overlays with bounds policies
US7010783B2 (en) * 2002-03-18 2006-03-07 Sun Microsystems, Inc. Method and apparatus for deployment of high integrity software using reduced dynamic memory allocation
US7805710B2 (en) 2003-07-15 2010-09-28 International Business Machines Corporation Shared code caching for program code conversion
US7321965B2 (en) 2003-08-28 2008-01-22 Mips Technologies, Inc. Integrated mechanism for suspension and deallocation of computational threads of execution in a processor
US7519639B2 (en) 2004-01-05 2009-04-14 International Business Machines Corporation Method and apparatus for dynamic incremental defragmentation of memory
US7526760B1 (en) 2004-03-17 2009-04-28 Sun Microsystems, Inc. Methods for implementing virtual method invocation with shared code
JP2005346407A (ja) 2004-06-03 2005-12-15 Hitachi Ltd 動的コンパイルにおけるインライン展開実施方法
US20060242635A1 (en) * 2005-04-21 2006-10-26 Scott Broussard Method and system for optimizing array sizes in a JAVA virtual machine
US20080005728A1 (en) * 2006-06-30 2008-01-03 Robert Paul Morris Methods, systems, and computer program products for enabling cross language access to an addressable entity in an execution environment
US7761676B2 (en) 2006-12-12 2010-07-20 Intel Corporation Protecting memory by containing pointer accesses
US8146054B2 (en) 2006-12-12 2012-03-27 International Business Machines Corporation Hybrid data object model
US7975001B1 (en) 2007-02-14 2011-07-05 The Mathworks, Inc. Bi-directional communication in a parallel processing environment
CN101271398B (zh) * 2007-03-23 2010-06-09 北京大学 多路分支结构的识别方法
US8001070B2 (en) 2007-12-17 2011-08-16 Honeywell International Inc. Object oriented rule-based system and method
US8108649B2 (en) 2008-06-13 2012-01-31 International Business Machines Corporation Method of memory management for server-side scripting language runtime system
US8631051B2 (en) 2008-09-22 2014-01-14 Filip Pizlo Hybrid fragmenting real time garbage collection
US8370822B2 (en) 2008-11-20 2013-02-05 Apple Inc. Compiling techniques for providing limited accuracy and enhanced performance granularity
US20110138373A1 (en) 2009-12-08 2011-06-09 American National Laboratories, Inc. Method and apparatus for globally optimizing instruction code
JP5466601B2 (ja) 2010-08-31 2014-04-09 インターナショナル・ビジネス・マシーンズ・コーポレーション コード生成方法、システム及びプログラム
US9009726B2 (en) 2010-12-10 2015-04-14 Microsoft Technology Licensing, Llc Deterministic sharing of data among concurrent tasks using pre-defined deterministic conflict resolution policies
US8819649B2 (en) 2011-09-09 2014-08-26 Microsoft Corporation Profile guided just-in-time (JIT) compiler and byte code generation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8392881B1 (en) * 2008-05-13 2013-03-05 Google Inc. Supporting efficient access to object properties in a dynamic object-oriented programming language
US20120030661A1 (en) * 2010-07-30 2012-02-02 Apple Inc. Observation and analysis based code optimization
US20130205286A1 (en) * 2012-02-03 2013-08-08 Apple Inc. Runtime optimization using meta data for dynamic programming languages

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Shisheng Li 외 2명. TypeCaster: Demystify Dynamic Typing of JavaScript Applications. 2011년. *

Also Published As

Publication number Publication date
US9501409B2 (en) 2016-11-22
EP3039535A1 (en) 2016-07-06
CN105493041B (zh) 2019-04-09
EP3039535B1 (en) 2022-05-04
WO2015031286A1 (en) 2015-03-05
US9251071B2 (en) 2016-02-02
CN105493041A (zh) 2016-04-13
EP3039537B1 (en) 2022-04-20
WO2015031192A1 (en) 2015-03-05
WO2015031193A1 (en) 2015-03-05
US20150067267A1 (en) 2015-03-05
KR101778479B1 (ko) 2017-09-26
EP3039536A1 (en) 2016-07-06
CN105493042B (zh) 2019-09-10
KR101872625B1 (ko) 2018-08-02
EP3039537A1 (en) 2016-07-06
KR101769260B1 (ko) 2017-08-17
US20150067639A1 (en) 2015-03-05
US9672152B2 (en) 2017-06-06
KR20160038044A (ko) 2016-04-06
CN105493040A (zh) 2016-04-13
KR20160040254A (ko) 2016-04-12
CN105493042A (zh) 2016-04-13
CN105493040B (zh) 2019-09-20
US20150067658A1 (en) 2015-03-05
EP3039536B1 (en) 2022-04-20

Similar Documents

Publication Publication Date Title
KR101872625B1 (ko) 동적 타입 어레이 객체들에 액세스할 시의 크기 의존적 타입
US6721944B2 (en) Marking memory elements based upon usage of accessed information during speculative execution
US8402224B2 (en) Thread-shared software code caches
US6353881B1 (en) Supporting space-time dimensional program execution by selectively versioning memory updates
US20020199179A1 (en) Method and apparatus for compiler-generated triggering of auxiliary codes
US7168076B2 (en) Facilitating efficient join operations between a head thread and a speculative thread
KR100931460B1 (ko) 단일 스레드 응용을 지원하기 위한 시간-멀티플렉스된스펙큘레이티브 멀티 스레딩
US6453463B1 (en) Method and apparatus for providing finer marking granularity for fields within objects
Glossner et al. Delft-Java link translation buffer
Guan et al. Multithreaded optimizing technique for dynamic binary translator CrossBit
Choi HW-SW co-design techniques for modern programming languages
박혁우 A Study on Optimization of Compilation Process for JavaScript Engine
Gunnerson Deeper into C#
WO2000070452A1 (en) Dynamic handling of object versions to support space and time dimensional program execution

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right