DE112016002416T5 - System für code-zwischenspeicherung - Google Patents

System für code-zwischenspeicherung Download PDF

Info

Publication number
DE112016002416T5
DE112016002416T5 DE112016002416.9T DE112016002416T DE112016002416T5 DE 112016002416 T5 DE112016002416 T5 DE 112016002416T5 DE 112016002416 T DE112016002416 T DE 112016002416T DE 112016002416 T5 DE112016002416 T5 DE 112016002416T5
Authority
DE
Germany
Prior art keywords
code
source code
execution
executable
primary source
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
DE112016002416.9T
Other languages
English (en)
Inventor
Yang Guo
Daniel Vogelheim
Jochen Mathias Eisinger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Publication of DE112016002416T5 publication Critical patent/DE112016002416T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • 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
    • 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/4434—Reducing the memory space required by the program code
    • 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
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Stored Programmes (AREA)

Abstract

Es werden Systeme und Verfahren für die Code-Zwischenspeicherung bereitgestellt. Ein erster Hinweis darauf, dass primärer Quellcode auf die Ausführung wartet, wird empfangen. Ein Ressourcen-Cache wird auf zwischengespeicherte Daten geprüft, die dem primären Quellcode entsprechen. Bei einem Cache-Fehltreffer im Ressourcen-Cache wird ein erster, aus dem primären Quellcode kompilierter ausführbarer Code erhalten. Ein sekundärer Quellcode, auf den im primären Quellcode verwiesen wird, wird ausgewählt. Ein zweiter ausführbarer Code, der aus dem ausgewählten sekundären Quellcode kompiliert ist, wird erhalten. Der erste ausführbare Code und der zweite ausführbare Code werden in serialisierten Code serialisiert. Der serialisierte Code wird als zwischengespeicherte Daten im Ressourcen-Cache gespeichert.

Description

  • STAND DER TECHNIK
  • Die betrachtete Technologie bezieht sich auf das Zwischenspeichern von ausführbarem Code und bezieht sich im Besonderen auf die Auswahl von Quellcode für das Kompilieren, Serialisieren und Zwischenspeichern des ausführbaren Codes und das Deserialisieren des zwischengespeicherten ausführbaren Codes vor der Ausführung.
  • Virtuelle Maschinen (VMs) werden zur Ausführung von Softwarecode bei Kompilierung auf Anfrage, auch bezeichnet als „Just-in-Time-Compilation“ (JIT-Compilation), bei der die Kompilierung des Codes unmittelbar vor der Ausführung ausgeführt wird oder ein Teil des Codes auf Anfrage kompiliert wird (z. B. „träge“), verwendet. Wenn der Code in eine Ressource eingebettet ist, beispielsweise eine Ressource in einer Webseite, hängt die Geschwindigkeit, mit der die Ressource in einer Anwendung (z. B. einem Browser) gerendert werden kann, die auf einer Client-Einheit ausgeführt wird, von der Ausführungsgeschwindigkeit des eingebetteten Codes ab. Ein Benutzer der Client-Einheit kann innerhalb derselben Arbeitssitzung, beispielsweise einer Webbrowser-Sitzung, oder über mehrere unabhängige Arbeitssitzungen hinweg wiederholt auf dieselbe Ressource zugreifen. Wenn jedoch der Code jedes Mal kompiliert werden muss, wenn ein Benutzer auf die Ressource zugreift, wird für jede Kompilierung möglicherweise eine spürbar lange Zeit benötigt.
  • KURZDARSTELLUNG
  • Die offengelegte Betrachtungseinheit kann in verschiedener Hinsicht in einem System enthalten sein. Das System beinhaltet einen oder mehrere Prozessoren. Das System beinhaltet außerdem einen Speicher. Der Speicher beinhaltet Anweisungen, deren Ausführung den einen oder die mehreren Prozessoren veranlassen, ein Verfahren zu implementieren. Die Anweisungen beinhalten Code zum Empfang eines ersten Hinweises darauf, dass primärer Quellcode auf die Ausführung wartet. Die Anweisungen beinhalten in Reaktion auf den Empfang des ersten Hinweises Code zur Prüfung eines Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen. Die Anweisungen beinhalten, für den Fall eines Cache-Fehltreffers im Ressourcen-Cache, Code für das Erhalten des ersten, aus dem primären Quellcode kompilierten ausführbaren Codes. Die Anweisungen beinhalten Code zur Auswahl von sekundärem Quellcode, auf den im primären Quellcode verwiesen wird. Die Anweisungen beinhalten Code zum Erhalten von zweitem ausführbarem Code, der aus dem ausgewählten sekundären Quellcode kompiliert wird. Die Anweisungen beinhalten Code zum Serialisieren des ersten ausführbaren Codes und des zweiten ausführbaren Codes in serialisierten Code. Die Anweisungen beinhalten Code zum Speichern des serialisierten Codes als zwischengespeicherte Daten im Ressourcen-Cache.
  • Diese und weitere Implementierungen können ein oder mehrere der folgenden Leistungsmerkmale beinhalten. Die Anweisungen können Code zum Erhalten von Ausführungsergebnissen aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext beinhalten, wobei der sekundäre Quellcode basierend auf den Ausführungsergebnissen ausgewählt wird. Der sekundäre Quellcode kann, basierend auf einem oder mehreren des Folgenden, ausgewählt werden, und zwar aus: einer Größe des sekundären Quellcodes, einer Größe des zweiten ausführbaren Codes, einer Prognose, dass im primären Quellcode auf den sekundären Quellcode verwiesen wird, einer Anzahl der Male, die im primären Quellcode auf den sekundären Quellcode verwiesen wird, einer Häufigkeit der Verweise auf den sekundären Quellcode im primären Quellcode, oder einer Kompilierungsdauer des sekundären Quellcodes. Die Anweisungen können Code zum Empfangen eines zweiten Hinweises beinhalten, dass der primäre Quellcode auf die Ausführung in einem zweiten Ausführungskontext wartet, wobei der zweite Hinweis im Anschluss an den ersten Hinweis empfangen wird. Die Anweisungen können in Reaktion auf den Empfang des zweiten Hinweises Code zur Prüfung des Ressourcen-Cache auf zwischengespeicherte Daten beinhalten, die dem primären Quellcode und dem ausgewählten sekundären Quellcode entsprechen. Die Anweisungen können, für den Fall eines Cache-Treffers im Ressourcen-Cache, Code zum Abrufen der zwischengespeicherten Daten beinhalten, die den serialisierten Code aus dem Ressourcen-Cache umfassen. Die Anweisungen können Code zum Deserialisieren des abgerufenen serialisierten Codes in dritten ausführbaren Code beinhalten. Die Anweisungen können Code zum Bereitstellen des dritten ausführbaren Codes zur Ausführung im zweiten Ausführungskontext beinhalten.
  • Diese und weitere Implementierungen können ein oder mehrere der folgenden Leistungsmerkmale beinhalten. Der erste Ausführungskontext und der zweite Ausführungskontext können zwei unterschiedliche virtuelle Maschinenumgebungen zur Code-Ausführung sein. Der primäre Quellcode kann ein Script in einer Webseite sein und der erste Ausführungskontext und der zweite Ausführungskontext können Webbrowser-Sitzungen sein, in denen das Script ausgeführt wird. Der primäre Quellcode kann ein Script auf oberster Ebene einer Webseite sein. Der erste ausführbare Code kann einen Satz von Verweisen beinhalten, die feste, für den ersten Ausführungskontext spezifische Speicheradressen beinhalten, und die in den ersten Ausführungskontext eingebettet sind. Die Anweisungen, die den Code zum Serialisieren des ersten ausführbaren Codes beinhalten, können Code zum Ersetzen der eingebetteten Speicheradressen durch abstrakte Adressen, die für den ersten Ausführungskontext nicht spezifisch sind, beinhalten.
  • Bei einem innovativen Aspekt kann die offenbarte Betrachtungseinheit in einem System enthalten sein. Das System beinhaltet einen oder mehrere Prozessoren. Das System beinhaltet außerdem einen Speicher. Der Speicher beinhaltet Anweisungen, deren Ausführung den einen oder die mehreren Prozessoren veranlassen, ein Verfahren zu implementieren. Die Anweisungen beinhalten Code zum Empfang eines ersten Hinweises darauf, dass primärer Quellcode auf die Ausführung wartet. Die Anweisungen beinhalten in Reaktion auf den Empfang des ersten Hinweises Code zur Prüfung eines Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen. Die Anweisungen beinhalten, für den Fall eines Cache-Fehltreffers im Ressourcen-Cache, Code für das Erhalten des ersten, aus dem primären Quellcode kompilierten ausführbaren Codes. Die Anweisungen beinhalten Code zum Serialisieren des ersten ausführbaren Codes in serialisierten Code, basierend auf einem oder mehreren des Folgenden: einer Größe des primären Quellcodes, einer Anzahl der Male, die der primäre Quellcode innerhalb einer vorbestimmten Zeitspanne ausgeführt wird, oder einer Kompilierungsdauer des primären Quellcodes. Die Anweisungen beinhalten Code zum Speichern des serialisierten Codes als zwischengespeicherte Daten im Ressourcen-Cache.
  • Diese und weitere Implementierungen können ein oder mehrere der folgenden Leistungsmerkmale beinhalten. Die Anweisungen können Folgendes beinhalten: Code zum Auswählen von sekundärem Quellcode, auf den im primären Quellcode verwiesen wird, zumindest basierend auf einer Größe des sekundären Quellcodes, einer Anzahl von Malen, die im primären Quellcode auf den sekundären Quellcode verwiesen wird, einer Kompilierungsdauer des sekundären Quellcodes, oder einer Kombination derselben. Die Anweisungen können Code zum Erhalten von zweitem ausführbarem Code, der aus dem ausgewählten sekundären Quellcode kompiliert wird, beinhalten. Die Anweisungen können Code zum Serialisieren des zweiten ausführbaren Codes in den serialisierten Code beinhalten. Die Anweisungen können Code zum Erhalten von Ausführungsergebnissen aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext beinhalten, wobei der sekundäre Quellcode basierend auf den Ausführungsergebnissen ausgewählt wird. Die Anweisungen können Code zum Empfangen eines zweiten Hinweises darauf enthalten, dass der primäre Quellcode auf die Ausführung in einem zweiten Ausführungskontext wartet, wobei der zweite Hinweis im Anschluss an den ersten Hinweis empfangen wird. Die Anweisungen können in Reaktion auf den Empfang des zweiten Hinweises Code zur Prüfung des Ressourcen-Cache auf zwischengespeicherte Daten beinhalten, die dem primären Quellcode und dem ausgewählten sekundären Quellcode entsprechen. Die Anweisungen können, für den Fall eines Cache-Treffers im Ressourcen-Cache, Code zum Abrufen der zwischengespeicherten Daten beinhalten, die den serialisierten Code aus dem Ressourcen-Cache umfassen. Die Anweisungen können Code zum Deserialisieren des abgerufenen serialisierten Codes in dritten ausführbaren Code beinhalten. Die Anweisungen können Code zum Bereitstellen des dritten ausführbaren Codes zur Ausführung im zweiten Ausführungskontext beinhalten.
  • Diese und weitere Implementierungen können ein oder mehrere der folgenden Leistungsmerkmale beinhalten. Der erste Ausführungskontext und der zweite Ausführungskontext können zwei unterschiedliche virtuelle Maschinenumgebungen zur Code-Ausführung sein. Der erste ausführbare Code kann einen Satz von Verweisen, darunter auch im ersten ausführbaren Code eingebettete Speicheradressen, beinhalten, während die Anweisungen, die Code zum Serialisieren des ersten ausführbaren Codes beinhalten, Code zum Ersetzen der eingebetteten Speicheradressen durch abstrakte Adressen beinhalten können.
  • In einem innovativen Aspekt kann die offenbarte Betrachtungseinheit in einem computerlesbaren Medium enthalten sein, das Anweisungen beinhaltet, die von einem Computer ausgeführt werden können. Die Anweisungen beinhalten Code, die den Computer veranlassen, einen ersten Hinweis darauf zu empfangen, dass primärer Quellcode auf die Ausführung wartet. Die Anweisungen beinhalten Code, der den Computer in Reaktion auf den Empfang des ersten Hinweises veranlasst, einen Ressourcen-Cache auf zwischengespeicherte Daten zu prüfen, die dem primären Quellcode entsprechen. Die Anweisungen beinhalten, für den Fall eines Cache-Fehltreffers im Ressourcen-Cache, Code, der den Computer veranlasst, den ersten, aus dem primären Quellcode kompilierten ausführbaren Code zu erhalten. Die Anweisungen beinhalten Code, der den Computer veranlasst, Ausführungsergebnisse aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext zu erhalten. Die Anweisungen beinhalten Code, der den Computer veranlasst, basierend auf den Ausführungsergebnissen, den sekundären Quellcode auszuwählen, auf den im primären Quellcode verwiesen wird. Die Anweisungen beinhalten Code, der den Computer veranlasst, zweiten ausführbaren Code zu erhalten, der aus dem ausgewählten sekundären Quellcode kompiliert ist. Die Anweisungen beinhalten Code, der den Computer veranlasst, den ersten ausführbaren Code und den zweiten ausführbaren Code in serialisierten Code zu serialisieren. Die Anweisungen beinhalten Code, der den Computer veranlasst, den serialisierten Code als zwischengespeicherte Daten im Ressourcen-Cache zu speichern.
  • Diese und weitere Implementierungen können ein oder mehrere der folgenden Leistungsmerkmale beinhalten. Der erste ausführbare Code kann einen Satz von Verweisen, darunter im ersten ausführbaren Code eingebettete Speicheradressen, beinhalten, während die Anweisungen, die den Computer veranlassen, den ersten ausführbaren Code zu serialisieren, Anweisungen beinhalten können, der den Computer veranlasst, die eingebetteten Speicheradressen durch abstrakte Adressen zu ersetzen. Die Ausführungsergebnisse können eine Anzahl von Malen angeben, die der sekundäre Quellcode, auf den im primären Quellcode verwiesen wird, bei der Ausführung des primären Quellcodes ausgeführt wird. Die Anweisungen können Code beinhalten, der den Computer veranlasst, einen zweiten Hinweis darauf zu erhalten, dass der primäre Quellcode auf die Ausführung in einem zweiten Ausführungskontext wartet, wobei der zweite Hinweis im Anschluss an den ersten Hinweis empfangen wird. Die Anweisungen können Code beinhalten, der den Computer veranlasst, in Reaktion auf den Empfang des zweiten Hinweises den Ressourcen-Cache auf zwischengespeicherte Daten zu prüfen, die dem primären Quellcode und dem ausgewählten sekundären Quellcode entsprechen. Die Anweisungen können, für den Fall eines Cache-Treffers im Ressourcen-Cache, Code beinhalten, der den Computer veranlasst, die zwischengespeicherten Daten abzurufen, die den serialisierten Code aus dem Ressourcen-Cache umfassen. Die Anweisungen können Code beinhalten, der den Computer veranlasst, den abgerufenen serialisierten Code in dritten ausführbaren Code zu deserialisieren. Die Anweisungen können Code beinhalten, der den Computer veranlasst, den dritten ausführbaren Code zur Ausführung im zweiten Ausführungskontext bereitzustellen. Der erste Ausführungskontext und der zweite Ausführungskontext können zwei unterschiedliche virtuelle Maschinenumgebungen zur Code-Ausführung sein. Die Anweisungen können Code beinhalten, der den Computer veranlasst, ein mit einem ersten ausführbaren Code verknüpftes erstes Ausführungsprofil und ein mit einem zweiten ausführbaren Code verknüpftes zweites Ausführungsprofil zu erhalten. Die Anweisungen können außerdem Code beinhalten, der den Computer veranlasst, das erste Ausführungsprofil und das zweite Ausführungsprofil zu serialisieren. Die Anweisungen können außerdem Code beinhalten, der den Computer veranlasst, das serialisierte erste Ausführungsprofil und das zweite Ausführungsprofil im Ressourcen-Cache zu speichern, wobei das Deserialisieren des abgerufenen serialisierten Codes das Deserialisieren des ersten Ausführungsprofils und des zweiten Ausführungsprofils beinhaltet.
  • Es wird davon ausgegangen, dass andere Konfigurationen der betrachteten Technologie aus der folgenden ausführlichen Beschreibung für Fachleute auf dem Gebiet ohne weiteres ersichtlich sein werden, wobei verschiedene Konfigurationen der betrachteten Technologie als Veranschaulichung dargestellt und beschrieben sind. Wie zu erkennen, ist die betrachtete Technologie in der Lage, andere und unterschiedliche Konfigurationen hervorzubringen, wobei ihre verschiedenen Teile in der Lage sind, Modifizierungen in vielerlei anderen Hinsichten hervorzubringen, und das alles ohne vom Schutzumfang der betrachteten Technologie abzuweichen. Dementsprechend sind die Zeichnungen und die ausführliche Beschreibung als veranschaulichend und nicht als einschränkend anzusehen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Merkmale der betrachteten Technologie werden in den beiliegenden Ansprüchen dargelegt. Zum Zweck der Erläuterung und Darstellung werden jedoch mehrere Implementierungen der betrachteten Technologie in den folgenden Figuren dargelegt.
  • 1 veranschaulicht eine exemplarische Netzwerkumgebung, in der die Code-Zwischenspeicherung verarbeitet werden kann.
  • 2 veranschaulicht eine Client-Einheit, der Code-Zwischenspeicherung bereitgestellt werden kann.
  • 3 zeigt ein Ablaufdiagramm einer Code-Zwischenspeicherungsplattform, der die Serialisierung eines Scripts in zwischengespeicherten Code und die Deserialisierung von zwischengespeichertem Code in ausführbaren Code bereitgestellt werden kann.
  • 4A–4B veranschaulichen Beispiele von Prozessen, mit denen die Serialisierung eines Scripts in zwischengespeicherten Code bereitgestellt werden kann.
  • 5 veranschaulicht konzeptuell ein exemplarisches elektronisches System, bei dem einige Implementierungen der betrachteten Technologie implementiert sind.
  • AUSFÜHRLICHE BESCHREIBUNG
  • GLOSSAR
  • Abstrahieren (Abstraktion): Abstraktion bezeichnet ein Verfahren zum Ersetzen von Verweisen in einem Objekt (z. B. Code) zu Speicheradressen und weiteren, für einen Ausführungskontext spezifischen, Objekten durch Anweisungen zum Neuerstellen von Verweisen (z. B. Verlagerungsdaten), sodass das Objekt in einem neuen Ausführungskontext neu erzeugt werden kann.
  • Serialisieren (Serialisierung): Serialisierung bezeichnet ein Verfahren zum Erzeugen einer Repräsentation eines Objekts (z. B. kompilierten ausführbaren Codes) als sequentielle, transportierbare Daten, und beinhaltet die Daten des Objekts sowie Informationen über das Objekt, wie beispielsweise der Objekttyp oder die Typen der in dem Objekt gespeicherten Daten.
  • Deserialisieren (Deserialisierung): Deserialisierung bezeichnet ein Verfahren zum Extrahieren und Erzeugen eines Objekts (z. B. kompilierten ausführbaren Codes) aus den sequentiellen Daten eines serialisierten Objekts.
  • Quellcode: Quellcode bezeichnet eine Ansammlung von Computeranweisungen, die Aktionen spezifizieren, die von einem Computer auszuführen sind, und die unter Verwendung einer von Menschen lesbaren Computersprache geschrieben werden.
  • Ausführbarer Code: Ausführbarer Code bezeichnet einen Satz von Anweisungen in Maschinensprache, die von einem Computer ausführbar sind, und durch Analysieren und Kompilieren des Quellcodes erzeugt werden.
  • Ausführungskontext (Ausführungsumgebung): Ausführungskontext bezeichnet einen Satz von Betriebsparametern, die ein Computersystem oder eine Software-Emulation eines Computersystems (z. B. eine virtuelle Maschine) definieren, auf dem bzw. in der ausführbarer Code ausgeführt wird.
  • Verlagerungsdaten: Verlagerungsdaten sind Anweisungen oder Informationen, die zum Wiederherstellen abstrahierter Code-Verweise zu Speicherorten oder Objekten in einem aktuellen Ausführungskontext genutzt werden.
  • Die nachstehend dargelegte ausführliche Beschreibung soll als Beschreibung verschiedener Konfigurationen der betrachteten Technologie dienen, und ist nicht dazu vorgesehen, die einzigen Konfigurationen zu repräsentieren, mit denen die betrachtete Technologie betrieben werden kann. Die beiliegenden Zeichnungen werden hierin aufgenommen und bilden einen Teil der ausführlichen Beschreibung. Die ausführliche Beschreibung beinhaltet spezifische Angaben zu dem Zweck, ein gründliches Verständnis der betrachteten Technologie zu ermöglichen. Jedoch ist klar und ersichtlich, dass die betrachtete Technologie nicht auf die hierin dargelegten spezifischen Details beschränkt ist und ohne diese spezifischen Details angewendet werden kann. In manchen Fällen werden Strukturen und Komponenten in Blockdiagrammform dargestellt, um ein Verschleiern der Konzepte der betrachteten Technologie zu verhindern.
  • Die Ladedauer von Ressourcen ist ein nicht unerheblicher Teil der Benutzererfahrung, wenn versucht wird, über ein Computergerät auf eine Ressource zuzugreifen. Bei der Ressource kann es sich um eine Anwendung, eine Datei oder ein Dokument handeln, die bzw. das aus dem lokalen Speicher im Computergerät oder von einer Netzwerkressource, wie beispielsweise einer Datei oder einem Dokument geladen wird, die bzw. das sich in einer aus einem Netzwerk geladenen Webseite befindet. Dynamische Scripts, wie beispielsweise ein in einer Ressource eingebetteter JavaScript-Code, müssen jedoch vor der Ausführung kompiliert werden, und dies kann den Ladeprozess der Ressource verlangsamen. Deshalb ist es wünschenswert, die Effizienz des Renderns von Ressourcen auf Computergeräten durch das Zwischenspeichern von kompiliertem Code in einem Ressourcen-Cache und das Wiederverwenden des zwischengespeicherten Codes für den zukünftigen Zugriff auf die Ressource während nachfolgender Sitzungen zu steigern.
  • Quellcode kann durch ein Compiler-Programm in Low-Level-Maschinencode, der vom Computer ausgeführt werden kann, umgewandelt werden. Der Maschinencode könnte dann für die Ausführung gespeichert werden. Alternativ kann ein Interpretierprogramm genutzt werden, um das Quellcodeprogramm spontan und direkt zu analysieren und die Ergebnisse direkt auszuführen. Das Analysieren und Kompilieren von Quellcode (z. B. JavaScript-Code), der in einer Anwendung oder einem Dokument, wie beispielsweise einer Webseite, eingebettet ist, um ausführbaren Code zu erzeugen, liegt auf dem kritischen Pfad für das Laden der Ressource. Bei der Ausführung durch den Prozessor eines Computers veranlasst der ausführbare Code den Prozessor, Aufgaben gemäß den Anweisungen auszuführen. Maschinensprache bezeichnet den Satz nativer Anweisungen, die der Computer in der Hardware ausführt. Um den Ladeprozess zu beschleunigen, kann der kompilierte Code beispielsweise in einem binären Format serialisiert und zwischengespeichert werden. Sobald der ausführbare Code zwischengespeichert ist, muss der Quellcode bei nachfolgenden Ausführungen des Scripts nicht mehr reanalysiert und rekompiliert werden und der ausführbare Code kann aus dem Cache deserialisiert und ausgeführt werden.
  • Während der Serialisierung von kompiliertem Code kann die Beschaffenheit des Codes in eine Form umgewandelt werden, die von einer Ausführungsumgebung in andere Ausführungsumgebungen umgewandelt werden kann. Der Serialisierungsprozess übersetzt Datenstrukturen oder Objektzustände in ein Format, das, basierend auf den in dem serialisierten Objekt eingebetteten Informationen, in demselben oder einem anderen Kontext (z. B. einer Ausführungsumgebung) wiederhergestellt werden kann. Die Serialisierung kann aus dem kompilierten Code für verschiedene Komponenten des Codes und für Objekte, auf die der Code verweist, wie beispielsweise Datenstrukturen, die Konstanten, Zeichenfolgenliterale, Objektliterale, Funktionsobjekte, einschließlich Verlagerungsdaten, die für die Kompilierung auf Anfrage benötigt werden, gemeinsam genutzte Code-Elemente, Verweise zur Ausführungsumgebung (z. B. VM) usw. repräsentieren, ausführbaren Code bereitstellen.
  • 1 veranschaulicht eine exemplarische Netzwerkumgebung 100, in der die Code-Zwischenspeicherung verarbeitet werden kann. Die Netzwerkumgebung 100 beinhaltet die Client-Einheiten 101a und 101n sowie die Server 109a und 109m. Obgleich in 1 zwei Client-Einheiten 101a und 101n und zwei Server 109a und 109m dargestellt sind, ist die betrachtete Technologie nicht darauf beschränkt und kann für mehr als zwei Client-Einheiten und Server oder einfach für nur eine Client-Einheit und/oder einen Server Anwendung finden. Die Client-Einheiten 101a und 101n und die Server 109a und 109m können über das Netzwerk 105 miteinander kommunizieren. Die Server 109a und 109m können Computergeräte, die den Client-Einheiten ähnlich sind, sowie computerlesbare Speichereinheiten (nicht dargestellt) beinhalten.
  • Jede der Client-Einheiten 101a und 101n kann verschiedene Formen von Verarbeitungseinheiten repräsentieren. Exemplarische Verarbeitungseinheiten können einen Desktop-Computer, einen Laptop-Computer, einen Handheld-Computer, einen persönlichen digitalen Assistenten (PDA), ein Mobiltelefon, eine Netzwerk-Appliance, eine Kamera, ein Smartphone, ein Mobiltelefon mit Enhanced General Packet Radio Service (EGPRS), einen Media Player, ein Navigationsgerät, eine E-Mail-Einheit, eine Spielekonsole oder eine Kombination jeglicher dieser Datenverarbeitungseinheiten oder sonstiger Datenverarbeitungseinheiten beinhalten. Den Client-Einheiten 101a und 101n sowie den Servern 109a und 109m kann Zugriff auf Anwendungs-Software gewährt werden oder dieselben können Anwendungs-Software empfangen, die auf einer beliebigen der anderen Client-Einheiten 101a und 101n oder den Servern 109a und 109m ausgeführt wird oder gespeichert ist.
  • Bei den Servern 109a und 109m kann es sich um ein beliebiges System oder eine beliebige Einheit handeln, die über einen Prozessor, einen Speicher und eine Kommunikationsfähigkeit verfügt, um den Client-Einheiten 101a und 101n Inhalte bereitzustellen. In einigen exemplarischen Aspekten kann es sich beim Server 109a oder 109m um ein einzelnes Computergerät, beispielsweise einen Computer-Server, handeln. In anderen Implementierungen kann der Server 109a oder 109m mehr als ein Computergerät repräsentieren, wobei diese zusammenwirken, um die Aktionen eines Server-Computers (z. B. Cloud-Computing) auszuführen. Des Weiteren kann der Server 109a oder 109m verschiedene Arten von Servern repräsentieren, darunter auch unter anderem Folgende: einen Web-Server, einen Applikationsserver, einen Proxy-Server, einen Netzwerk-Server oder eine Server-Farm.
  • Bei einigen Aspekten kommunizieren die Client-Einheiten 101a und 101n möglicherweise drahtlos über eine Kommunikationsschnittstelle (nicht dargestellt), die bei Bedarf eine Schaltung für digitale Signalverarbeitung beinhalten kann. Die Kommunikationsschnittstelle unterstützt möglicherweise die Kommunikation unter verschiedenen Modi oder Protokollen, unter anderem beispielsweise GSM-Sprachanrufe (Globales System für mobile Kommunikation (GSM)), SMS (Kurznachrichtendienst), EMS (erweiterten Nachrichtenservice) oder MMS (Multimedia-Nachrichtenservice), CDMA (Codemultiplexverfahren), TDMA (Zeitmultiplexverfahren), PDC (Persönliches digitales Mobilfunksystem), WCDMA (Breitband-Codemultiplexverfahren), CDMA2000 oder GPRS (Allgemeiner paketorientierter Funkdienst). Die Kommunikation kann beispielsweise über einen Hochfrequenz-Sendeempfänger (nicht dargestellt) erfolgen. Zusätzlich kann eine Kurzstreckenkommunikation, wie beispielsweise unter Verwendung eines Bluetooth-, WLAN- oder eines anderen derartigen Sendeempfängers, erfolgen.
  • In einigen Aspekten kann es sich bei der Netzwerkumgebung 100 um ein verteiltes Client/Server-System handeln, das sich über Netzwerke, beispielsweise das Netzwerk 105, erstreckt. Bei dem Netzwerk 105 kann es sich um ein großes Computer-Netzwerk, beispielsweise ein lokales Netzwerk (LAN), ein Großraumnetzwerk (WAN), das Internet, ein Mobilfunknetz oder eine Kombination derselben handeln, wobei eine beliebige Anzahl mobiler Clients, ortsgebundener Clients und Server miteinander verbunden sind. Des Weiteren kann das Netzwerk 105 unter anderem beliebige der folgenden Netzwerk-Topologien beinhalten: ein Bus-Netzwerk, ein Stern-Netzwerk, ein Ring-Netzwerk, ein Mesh-Netzwerk, ein Stern-Bus-Netzwerk, ein Baum- oder hierarchisches Netzwerk und dergleichen. In einigen Aspekten kann die Kommunikation zwischen jedem Client (z. B. Client-Einheiten 101a und 101n) und dem Server 109a oder 109m über ein virtuelles privates Netzwerk (VPN), einen SSH-Tunnel (Secure Shell (SSH)) oder eine sonstige sichere Netzwerkverbindung erfolgen. In einigen Aspekten kann das Netzwerk 105 ferner ein Unternehmensnetzwerk (z. B. Intranet) und drahtlose Zugangspunkte (Wireless Access Points) beinhalten.
  • In exemplarischen Aspekten kann jede beliebige der Client-Einheiten 101a oder 101n miteinander und mit den Servern 109a oder 109 über das Netzwerk 105 kommunizieren, wobei ein Netzwerkprotokoll, wie beispielsweise das HTTP-Protokoll (Hypertext Transfer Protocol (HTTP)), genutzt wird. Die Client-Einheit 101a oder 101n kann Benutzereingaben für eine Anwendung 107a oder 107n (z. B. einen Webbrowser) innerhalb einer Benutzeroberfläche der Client-Einheit 101a oder 101n empfangen. Die Benutzereingaben können bestimmen, welche Inhalte zu laden sind. Beispielsweise kann es sich bei einer Benutzereingabe um eine mit einer Webseite verknüpfte URL-Adresse (Uniform Resource Locator (URL)) handeln, die spezifiziert, welche Web-Inhalte vom Server 109a oder 109m zu laden sind. Der Benutzer kann zudem Eingaben vornehmen, um zu spezifizieren, welchen Teil einer Webseite der Benutzer auf einer Benutzeroberfläche (UI) der Client-Einheit 101a oder 101n (in 1 nicht dargestellt) sehen möchte. In derartigen exemplarischen Aspekten kann jede der Client-Einheiten 101a oder 101n eine Code-Zwischenspeicherungsplattform 103a oder 103n beinhalten, die einen Cache, basierend auf einer Anfrage des Benutzers, auf zwischengespeicherten ausführbaren Code prüfen kann, und den zwischengespeicherten ausführbaren Code zur Ausführung auf der Client-Einheit 101a oder 101n bereitstellen kann. Die Code-Zwischenspeicherungsplattform 103a oder 103n kann zudem Teile des ausführbaren Codes für das Zwischenspeichern auswählen.
  • 2 veranschaulicht eine Client-Einheit, für die Code-Zwischenspeicherung bereitgestellt werden kann. Die Client-Einheit 200 ist den Client-Einheiten 101a und 101n von 1 ähnlich. Wie dargestellt, beinhaltet die Client-Einheit 200 einen Prozessor 201, eine Netzwerkschnittstelle 203 und einen Speicher 205. Der Prozessor 201 ist darauf ausgelegt, Computer-Anweisungen auszuführen, die in bzw. auf einem computerlesbaren Medium, z. B. dem Speicher 205, gespeichert sind. Bei dem Prozessor 201 kann es sich um eine zentrale Verarbeitungseinheit (CPU) handeln. Die Netzwerkschnittstelle 203 ist darauf ausgelegt, der Client-Einheit 201 zu ermöglichen, Daten im Netzwerk 105, beispielsweise im Internet, in einem Intranet, einem lokalen Netzwerk oder einen Mobilfunknetz, zu senden und zu empfangen. Die Netzwerkschnittstelle 203 kann Netzwerkkarten (NICs) beinalten.
  • Der Speicher 205 speichert Daten und Anweisungen. Wie dargestellt, beinhaltet der Speicher 205 eine Anwendung 207, die den Anwendungen 107a und 107n von 1 ähnlich ist, sowie eine Code-Zwischenspeicherungsplattform 209, die der Code-Zwischenspeicherungsplattform 103a und 103n von 1 ähnlich ist. Die Anwendung 207 und die Code-Zwischenspeicherungsplattform 209 können in einer Ausführungsumgebung, wie beispielsweise der virtuellen Maschine 211, arbeiten.
  • Bei der Anwendung 207 kann es sich um eine Software-Anwendung handeln, die auf der Client-Einheit 200 durch Prozessor 201 ausgeführt wird. Beispielsweise kann es sich bei der Anwendung 207 um einen Webbrowser handeln, der einem Benutzer der Client-Einheit 200 Zugriff auf Dienste bietet, die von den Servern 109a oder 109m über das Netzwerk 105 erbracht werden. Die Server 109a und 109m können Dienste für die Client-Einheit 200 in der Form von Webseiten erbringen, während eine durch Server 109a oder 109m bereitgestellte Webseite mehrere Quellcodes oder Scripts (z. B. JavaScript) beinhalten kann, die beim Laden an der Client-Einheit 200 kompiliert und ausgeführt werden.
  • Die Code-Zwischenspeicherungsplattform 209 kann darauf ausgelegt sein, Code-Zwischenspeicherungsdienste für Anwendung 207 zu erbringen, wobei Anwendung 207 von den Servern 109a und 109m für die Client-Einheit 200 erbrachte Dienste rendert. In einigen Aspekten empfängt die Code-Zwischenspeicherungsplattform 209 einen Hinweis darauf, dass in einer Anwendung 207 eingebetteter Quellcode auf der Client-Einheit 200 auf die Ausführung wartet. Bei dem Hinweis des Quellcodes kann es sich um einen Link handeln, der auf einen Ort des in Anwendung 207 eingebetteten Quellcodes im Speicher 205 verweist. Bei dem Hinweis kann es sich ebenso um eine mit dem Quellcode verknüpfte Kennung oder um den vollständigen Inhalt des Quellcodes handeln. In Reaktion auf den Erhalt des Hinweises kann die Code-Zwischenspeicherungsplattform 209 einen Ressourcen-Cache 213 im Speicher 205 auf zwischengespeicherten ausführbaren Code prüfen, der dem Quellcode entspricht. Der Ressourcen-Cache 213 kann im persistenten/nicht flüchtigen Speicher gespeichert sein.
  • Beispielsweise wurde(n) der Quellcode oder Teile des Quellcodes (z. B. ein Sub-Code, eine Funktion usw.) möglicherweise zuvor kompiliert und im Ressourcen-Cache 213 zwischengespeichert. Bei einem Sub-Code, auch als sekundärer Quellcode bezeichnet, kann es sich um eine Funktion handeln, auf die im Quellcode verwiesen wird (z. B. aufgerufen wird). Auf den sekundären Quellcode kann innerhalb des Quellcodes, basierend auf verschiedenen Bedingungen, wie beispielsweise einer Benutzereingabe, einer Ausgabe von einem anderen sekundären Quellcode usw., verwiesen werden. Darüber hinaus wurden mit dem Quellcode in Beziehung stehende Daten, wie beispielsweise Typinformationen, möglicherweise zwischengespeichert. Die zwischengespeicherten Daten können vom Compiler genutzt werden, um einen ausführbaren Code effizienter zu erzeugen. Beispielsweise kann die Code-Zwischenspeicherungsplattform 209 aus dem Quellcode kompilierten ausführbaren Code erhalten, indem der Quellcode an einen Compiler innerhalb der Client-Einheit 200 (in 2 nicht dargestellt) übermittelt wird, um in ausführbaren Code kompiliert zu werden, und der ausführbare Code zur Ausführung auf der Client-Einheit 200 bereitgestellt wird. Sofern der zwischengespeicherte ausführbare Code, der dem Quellcode oder einem sekundären Quellcode entspricht, auf den im Quellcode verwiesen wird, im Ressourcen-Cache 213 nicht gefunden wird, kann die Code-Zwischenspeicherungsplattform 209 sekundären Quellcode, auf den im Quellcode verwiesen wird, zum Kompilieren auswählen. Die Code-Zwischenspeicherungsplattform 209 kann ausführbaren Code, der dem Quellcode entspricht, und/oder ausführbaren Code, der dem sekundären Quellcode entspricht, zwischenspeichern. Falls jedoch der zwischengespeicherte ausführbare Code, der dem Quellcode entspricht, im Ressourcen-Cache 213 gefunden wird, kann der zwischengespeicherte ausführbare Code aus dem Quell-Cache abgerufen und ohne Notwendigkeit einer Kompilierung des Quellcodes ausgeführt werden.
  • Der ausführbare Code kann einen Satz von Verweisen beinhalten. Bei den im ausführbaren Code enthaltenen Verweisen kann es sich um Speicheradressen handeln, die beispielsweise im ausführbaren Code eingebettet sind, der der Ausführungsumgebung (z. B. einer virtuellen Maschine 211) entspricht, in der der ausführbare Code ausgeführt wird. Die eingebetteten Adressen sind möglicherweise nicht von einem Ausführungskontext zu einem anderen portabel. Jedoch können die Verlagerungsdaten, die durch Abstrahieren der eingebetteten Adressen erzeugt werden, über Ausführungskontexte hinweg portabel sein. Die Verlagerungsdaten können dazu genutzt werden, die Abstraktion der im ausführbaren Code eingebetteten Adressen zu implementieren, beispielsweise durch Wiederherstellen der nicht portablen Adressen nach dem Portieren. Nach dem Erhalten des ausführbaren Codes für den Quellcode und den ausgewählten sekundären Quellcode serialisiert die Code-Zwischenspeicherungsplattform 209 die ausführbaren Codes. Die Serialisierung beinhaltet das Abstrahieren des Satzes von Verweisen im ausführbaren Code von einem Ausführungskontext (z. B. der virtuellen Maschine 211). Der Ausführungskontext stellt innerhalb eines Computersystems eine Betriebsumgebung mit Zugang zu Verarbeitungsleistung und Speicher zur Ausführung des ausführbaren Codes bereit. Die Code-Zwischenspeicherungsplattform 209 generiert Verlagerungsdaten, die mit dem ausführbaren Code verknüpft sind, um die Abstraktionen so wiederzugeben, dass die weitere Umwandlung der abstrahierten Verweise, basierend auf den erzeugten Verlagerungsdaten, durchgeführt werden kann.
  • Die Code-Zwischenspeicherungsplattform 209 kann den serialisierten Code für den Quellcode und den ausgewählten sekundären Quellcode, auf den im Quellcode verwiesen wird, als zwischengespeicherte Daten im Ressourcen-Cache 213 im Speicher 205 speichern. Herkömmliche Strategien für das Cache-Management können zum Verwalten des Ressourcen-Cache genutzt werden. Darüber hinaus können Cache-Tags zur Bestimmung des Orts zwischengespeicherter Daten im Ressourcen-Cache genutzt werden. Die Code-Zwischenspeicherungsplattform 209 kann außerdem den ausführbaren Code zur Ausführung in der virtuellen Maschine 211 bereitstellen. In einigen Aspekten kann die Code-Zwischenspeicherungsplattform 209 zu einem Zeitpunkt nach der Speicherung des serialisierten Codes im Ressourcen-Cache 213 einen zweiten Hinweis darauf empfangen, dass der Quellcode in einer anderen Umgebung einer virtuellen Maschine auf die Ausführung wartet. Beispielsweise wurde die Client-Einheit 200 nach Ausführung des ausführbaren Codes, wie zuvor erörtert, möglicherweise neu gestartet oder wieder hochgefahren. Wie erläutert, kann die Code-Zwischenspeicherungsplattform 209 in Reaktion auf den Erhalt des Hinweises den Ressourcen-Cache 213 im Speicher 205 auf zwischengespeicherten ausführbaren Code prüfen, der dem Quellcode oder dem ausgewählten sekundären Quellcode entspricht, auf den im Quellcode verwiesen wird. Da der sekundäre Quellcode zuvor kompiliert und im Ressourcen-Cache 213 zwischengespeichert wurde, kann der zwischengespeicherte ausführbare Code, der dem sekundären Quellcode entspricht, im Ressourcen-Cache 213 gefunden werden. Beim Cache-Treffer im Ressourcen-Cache 213 ruft die Code-Zwischenspeicherungsplattform 209 die zwischengespeicherten Daten aus dem Ressourcen-Cache 213 im Speicher 205 ab.
  • Der zwischengespeicherte Code beinhaltet den serialisierten Code, der den Verweisen entspricht, die aus dem sekundären Quellcode während der vorhergehenden Kompilierung abstrahiert wurden. Die Code-Zwischenspeicherungsplattform 209 kann die abgerufenen serialisierten Codes in neue, ausführbare sekundäre Quellcodes deserialisieren. Der Deserialisierungsprozess extrahiert den Code aus einer Sequenz gespeicherter Daten, wobei Informationen (z. B. Verlagerungsdaten) genutzt werden, welche zu den serialisierten Daten über den ursprünglichen Code, zu den Typen der Objekttypen, auf die im ursprünglichen Code verwiesen wird, sowie zu den in den Objekten gespeicherten Datentypen gehören. Der durch die Deserialisierung erzeugte ausführbare Code besitzt, ähnlich wie der ursprüngliche ausführbare Code, Struktur, Eigenschaften und Verhalten. Deshalb führt die Ausführung des ausführbaren Codes und der Objekte, auf die in dem ausführbaren Code verwiesen wird, durch einen Computer dieselben Aufgaben aus, die durch Ausführung des ursprünglichen Codes ausgeführt werden. Sowohl der Code als auch die Objekte, auf die durch den Code verwiesen wird, unterliegen der Serialisierung und Deserialisierung. Die Deserialisierung kann das Wiederherstellen des Satzes von Verweisen aus jedem sekundären Quellcode in neuen ausführbaren sekundären Quellcode beinhalten, wobei der abgerufene serialisierte Code so genutzt wird, dass der neue ausführbare sekundäre Quellcode in einer neuen Umgebung einer virtuellen Maschine ausführbar ist, die auf der Client-Einheit 200 beim Neustart eingerichtet wird. Die Code-Zwischenspeicherungsplattform 209 kann daraufhin den neuen ausführbaren sekundären Quellcode zur Ausführung in der neuen Umgebung der virtuellen Maschine auf der Client-Einheit 200 bereitstellen. Der neue ausführbare sekundäre Quellcode kann mit anderem sekundären Quellcode, auf den im Quellcode verwiesen wird, ausgeführt werden, der nicht zwischengespeichert wurde und zur Ausführung kompiliert wird. Die Code-Zwischenspeicherungsplattform 209 kann bei unterschiedlichen Ausführungsvorgängen eines Quellcodes neuen sekundären Quellcode zum Zwischenspeichern auswählen. Die Code-Zwischenspeicherungsplattform 209 kann zudem, basierend auf einem Ausführungsverlauf des sekundären Quellcodes von Quellcode, früher ausgewählten und zwischengespeicherten sekundären Quellcode durch anderen, beispielsweise häufiger ausgeführten, sekundären Quellcode ersetzen.
  • Wie zuvor erläutert, kann die Code-Zwischenspeicherung durch die Code-Zwischenspeicherungsplattform 209 in einer Client-Einheit 101a oder 101b ohne Kommunikation mit einem Server 109a oder 109b über das Netzwerk 105 erfolgen. Beispielsweise kann es sich in einem exemplarischen Aspekt bei dem Quellcode, der von der Code-Zwischenspeicherungsplattform 209 serialisiert und deserialisiert wird, um Code handeln, der lokal in einem Speicher der Client-Einheit 101a oder 101n gespeichert wird.
  • 3 zeigt ein Ablaufdiagramm einer Code-Zwischenspeicherungsplattform, bei der die Kompilierung und Serialisierung von Quellcode und/oder ausgewählten Sun-Codes, auf die im Quellcode verwiesen wird, in zwischengespeicherten Code und die Deserialisierung von zwischengespeichertem Code in ausführbaren Code durchgeführt werden kann. Wie in 3 dargestellt, kann die Code-Zwischenspeicherungsplattform 209 ein Front-end 303, ein Serialisierungsmodul 309 und ein Deserialisierunsgmodul 319 beinhalten. Das Front-end 303 kann ein Prüfmodul 305 sowie ein Komprimierungsmodul 307 beinhalten. Das Front-end 303 empfängt den Quellcode 301. Bei Empfang des Quellcodes prüft das Prüfmodul 305 den Datenspeicher 313 (als Pfeil 311 dargestellt) auf zwischengespeicherten serialisierten Code, der dem Quellcode entspricht. Falls der serialisierte Code im Datenspeicher 313 nicht gefunden wird (Cache-Fehltreffer), sendet das Front-end 303 den Quellcode zum Compiler 327 (als Pfeil 325 dargestellt). Der Compiler 327 kompiliert den Quellcode und speichert den ausführbaren Code und die Verweise. Der Compiler 327 kann den ausführbaren Code und die Verweise an einem mit einer Ausführungsumgebung 331 verknüpften Speicherort speichern (in 3 nicht dargestellt). Der ausführbare Code kann zur Ausführung innerhalb der Ausführungsumgebung 331, beispielsweise einer virtuellen Maschine ähnlich der virtuellen Maschine 211 von 2, innerhalb einer Browser-Sitzung, an die Ausführungsumgebung 331 (dargestellt als Pfeil 329) übermittelt werden.
  • Der Compiler 327 kann den ausführbaren Code und die Verweise zur Serialisierung an das Serialisierungsmodul 309 (dargestellt als 335) übermitteln. Das Front-End 303 kann Teile (z. B. sekundäre Quellcodes), auf die im Quellcode verwiesen wird, zur Serialisierung auswählen, beispielsweise basierend auf einer Häufigkeit der Ausführung der Teile bei zurückliegenden Ausführungsvorgängen oder basierend auf der Häufigkeit der Funktionsaufrufe, die sich auf jene Teile innerhalb des Quellcodes beziehen. Die Code-Zwischenspeicherungsplattform 209 kann, basierend auf verschiedenen Kriterien (z. B. Heuristiken), Quellcode und/oder sekundären Quellcode, auf den im Quellcode verwiesen wird, zur Serialisierung und zum Zwischenspeichern auswählen. Einige exemplarische Kriterien können sein: Größe des Quellcodes oder der sekundären Quellcodes; Alter des Quellcodes oder der sekundären Quellcodes (z. B. basierend auf dem Datum der letzten Revision oder einem Ablaufdatum des Quellcodes oder der sekundären Quellcodes); Nutzungshäufigkeit des Quellcodes oder der sekundären Quellcodes (z. B. Zwischenspeichern des Codes nach dem n-ten Nutzungsereignis); eine Häufigkeit, mit der ein zwischengespeicherter Code im Ressourcen-Cache 213 ersetzt wird: Anzahl der Male, die der sekundäre Quellcode im primären Quellcode ersetzt wird; oder eine Kompilierungsdauer des sekundären Quellcodes. Die Code-Zwischenspeicherungsplattform 209 kann, basierend auf der Prognose, dass im Quellcode auf den sekundären Quellcode verwiesen wird, einen sekundären Quellcode, auf den im Quellcode verwiesen wird, zur Serialisierung und zum Zwischenspeichern auswählen. Beispielsweise kann die Code-Zwischenspeicherungsplattform 209, wenn der Quellcode kompiliert wird, prognostizieren, dass auf den sekundären Quellcode im Quellcode verwiesen wird. Die Ergebnisse der Kompilierung aus dem Quellcode können darauf hinweisen, dass während der Ausführung durch den Quellcode auf den sekundären Quellcode verwiesen wird.
  • Die Code-Zwischenspeicherungsplattform 209 kann Quellcode serialisieren, sofern der Quellcode eine Größe aufweist, die kleiner als ein Schwellenwert S ist. Die Grundüberlegung besteht darin, dass das Serialisieren von großen Code-Elementen eine lange Zeit dauern kann und (z. B. ermittelt basierend auf dem verfügbaren Platz auf der Festplatte auf der Client-Einheit 101a–101n) ggf. hohe Speichervolumina erfordert, um die zwischengespeicherten Daten zu speichern.
  • Weitere exemplarische Kriterien können sein: Zugriffslatenz des Cache (z. B. Eingangsgröße des Cache); Kompilierdauer des Quellcodes oder von Teilen des Quellcodes (z. B. Protokollierung, wie lange die erstmalige Kompilierung des Quellcodes dauerte, und Einrechnen bzw. Berücksichtigen dieser Dauer in die bzw. bei der Entscheidung); Speicherkapazität der Client-Einheit 101a–101n, die den Ressourcen-Cache 213 hostet; eine Häufigkeit der Aktualisierung des Quellcodes (z. B. ist das Zwischenspeichern des Quellcodes, sofern der Quellcode häufig aktualisiert wird, ggf. nicht vorteilhaft), usw. Die Code-Zwischenspeicherungsplattform 209 kann vor der Auswahl von Code zur Serialisierung eine Kosten-Nutzen-Abwägung zwischen den vorstehenden Faktoren treffen. Beispielsweise können für den Quellcode oder für Teile des Quellcodes Wichtungsfaktoren bestimmt werden, um eine Wichtigkeitsstufe der verschiedenen, vorstehend erörterten Kriterien zu bestimmen. Die Bestimmung der Kosten-Nutzen-Abwägung kann beispielsweise basierend auf den Wichtungsfaktoren erfolgen. Beispielsweise führt eine Abwägung zwischen der Code-Größe und der Speicherkapazität der Client-Einheit 101a–101n möglicherweise zum Ergebnis, dass auf das Zwischenspeichern eines Codes mit einer großen Größe, der möglicherweise auf der Client-Einheit 101a–101n beträchtlichen Speicherplatz belegt, selbst dann verzichtet wird, wenn der Code häufig aufgerufen wird.
  • In verschiedenen Fällen kann das Front-End eine Entscheidung darüber treffen, ob der ausführbare Code und die Verweise zu serialisieren sind. Beispielsweise werden möglicherweise einige Kriterien durch die Server 109a oder 109m für zu serialisierende Arten von Quellcode oder Teile des Quellcodes sowie ohne Serialisierung zu kompilierende und auszuführende Arten bestimmt. Außerdem müssen aus Sicherheitsgründen möglicherweise bestimmte Arten von Quellcode vor jeder Ausführung überprüft werden. In derartigen Fällen kann das Front-End 303 den Quellcode oder Teile des Quellcodes als nicht zu serialisierenden Quellcode kennzeichnen.
  • Ein weiteres Kriterium für die Code-Zwischenspeicherung kann die Anwendung von Code-Zwischenspeicherung auf Codes beinhalten, die öfter als eine vorbestimmte Anzahl von Malen kompiliert werden. Beispielsweise kann der Quellcode, wenn das erste Mal ein Cache-Fehltreffer erkannt wird, kompiliert, jedoch nicht serialisiert oder zwischengespeichert werden. Der Quellcode kann als „einmalig kompiliert“ gekennzeichnet werden, ohne dass die Serialisierung des Codes durchgeführt wird. In ähnlicher Weise kann der Quellcode mit einem Zähler gekennzeichnet werden, der eine Anzahl von Malen anzeigt, die der Quellcode kompiliert wurde, bis ein vorbestimmter Schwellenwert C erreicht wird, wobei die Code-Zwischenspeicherungsplattform 209 beim C-ten Cache-Fehltreffer den Quellcode serialisieren und zwischenspeichern kann. Alternativ kann beim ersten Cache-Fehltreffer anstelle eines generischen Kennzeichens ein Zeitstempel gesetzt werden, während die Zeitdifferenz zwischen dem ersten und dem C-ten Cache-Fehltreffer dazu genutzt werden kann, die Serialisierungsentscheidung zu treffen. Die Kriterien lassen sich beispielsweise übersetzen in: „Wenn der kompilierte Code mindestens C Male pro Woche ausgeführt wird, dann soll der kompilierte Code zwischengespeichert werden“. Weitere Kriterien zur Entscheidung über das Zwischenspeichern von Quellcode, wie beispielsweise die Kompilierungsdauer, die Größe des erzeugten Codes, HTTP-Cache-Kopfdaten usw., können in Betracht gezogen werden.
  • Die Code-Zwischenspeicherungsplattform 209 kann Ausführungsdaten des Quellcodes nutzen, um auszuwählen, dass der sekundäre Quellcode zwischengespeichert und bei nachfolgenden Ausführungen weiterhin genutzt wird. Die Ausführungsdaten können beispielsweise: weitere Elemente des Codes, auf den der ausgeführte Quellcode während der Ausführung verweist, Ausführungsprofil des Quellcodes, ob der Quellcode häufig genug ausgeführt wird (z. B. häufiger als eine vorbestimmte Anzahl von Malen), damit sich die Zwischenspeicherung lohnt, Informationen zum Typ (z. B. benutzerdefinierte Datenstrukturen), die während der Ausführung festgestellt wurden, usw. beinhalten. Außerdem können die Ausführungsdaten serialisiert werden, damit die Daten in einen Ausführungskontext deserialisiert werden können. Nach der Deserialisierung können die Ausführungsdaten zusammen mit dem deserialisierten Code genutzt werden. Beispielsweise kann das Ausführungsprofil im Ausführungskontext genutzt werden, um zu entscheiden, ob Zeit für die Optimierung des ausführbaren Codes aufzuwenden ist oder nicht.
  • Sprachen vom dynamischen Typ, wie beispielsweise JavaScript, bieten einen Überfluss an Typinformationen für im Quellcode definierte Objekte. Die dynamischen Typen ermöglichen es einem Objekt des Quellcodes, während unterschiedlicher Ausführungen des Quellcodes unterschiedliche Typen aufzuweisen. Das Beobachten verschiedener Ausführungen des Quellcode kann jedoch Erkenntnisse darüber bieten, wie häufig der Typ eines Objekts variiert.
  • Der Typ T eines bestimmten Objekts O lässt sich, basierend auf dem Objektinhalt, bestimmen. Wenn jedoch ein Quellcode mit Objekt O interagiert, hat der Quellcode keinen Zugriff auf die Typinformationen, weshalb der Objekttyp T für den Quellcode unbekannt ist. Infolgedessen muss der Quellcode Typ T vor dem Zugriff auf das Objekt O bestimmen. In einigen Aspekten bestimmt und cacht die Code-Zwischenspeicherungsplattform 209 den Objekttyp T. Beispielsweise stellt die Code-Zwischenspeicherungsplattform 209 möglicherweise im Quellcode einen bestimmten Typ des Objekts zu dem Zeitpunkt fest, an dem auf Objekt O in einer Ausführungsumgebung (z. B. in einer Webseite) zugegriffen wird. Die Code-Zwischenspeicherungsplattform 209 kann die im Zugriff stehende Webseite mit dem Typ T des von der Webseite aus zugegriffenen Objekts verknüpfen. Einhergehend mit Typ T kann die Code-Zwischenspeicherungsplattform 209 zudem die „wie-zuzugreifen-ist“-Information, die zur Zugriffszeit ermittelt wurde, zwischenspeichern. Wenn anschließend von einem Quellcode in derselben Ausführungsumgebung auf Objekt O aus zugegriffen wird, sind der erwartete Typ T und die Zugriffsmethode für das Zugreifen auf Objekt O aus den zwischengespeicherten Daten bekannt. Die Code-Zwischenspeicherungsplattform 209 kann außerdem prüfen, ob der erwartete Typ T derselbe ist, wie der Typ des Objekts beim derzeitigen Zugriff. Falls die Typen übereinstimmen, kann die zwischengespeicherte Zugriffsmethode für das Zugreifen auf Objekt O genutzt werden, ohne dass eine weitere Bestimmung der Zugriffsmethode erforderlich ist.
  • Darüber hinaus kann der Objekttyp T Informationen über die Zugriffsmethode für das Zugreifen auf Objekt O in einem Ausführungskontext bereitstellen. Sobald die Zugriffsmethode für das Zugreifen auf Objekt O bestimmt ist, können Informationen über die Zugriffsmethode im Ressourcen-Cache als Typinformationen gespeichert und während der Serialisierung mit der Zugriffsmethode verknüpft werden. Durch Nutzung der gespeicherten Typinformationen zum Zeitpunkt der Deserialisierung können nachfolgende Zugriffe auf Objekt O schneller erfolgen, ohne die Zugriffsmethode bestimmen zu müssen.
  • Die Serialisierung durch das Serialisierungsmodul 309 kann Verweise im ausführbaren Code abstrahieren, indem Adressen im ausführbaren Code durch abstrakte Adressen ersetzt werden. Das Serialisierungsmodul 309 stellt serialisierten Code bereit, der ausführbarem Code entspricht, sowie Verlagerungsdaten, die der Abstraktion der Verweise im ausführbaren Code zum Front-End 303 (dargestellt als 323) entsprechen. Durch die Bereitstellung des serialisierten Codes kann das Serialisierungsmodul 309 relevante Teile und Verweise, die dem ausführbaren Code entsprechen, sowie Verweise aus der Ausführungsumgebung 331 finden. Das Serialisierungsmodul 309 kann die Teile und Verweise in eine zusammenhängende, von der Ausführungsumgebung 331 unabhängige, binäre Repräsentation umwandeln, die in den serialisierten Code einzubeziehen ist. Das Front-End 303 kann den vom Serialisierungsmodul 309 erzeugten Code im Datenspeicher 313 als zwischengespeicherten serialisierten Code speichern. Das Serialisierungsmodul 309 kann den serialisierten Code, welcher der Abstraktion entspricht, kodieren, wobei ein Kennzeichen (Tag) genutzt wird, um den Code von anderen Datentypen innerhalb des serialisierten Codes zu unterscheiden.
  • In einem anderen Fall kann, nachdem der serialisierte Code durch das Front-End 303 im Datenspeicher 313 und die Verlagerungsdaten innerhalb von Metadaten 315 gespeichert sind, das Front-End 303 eine neue Anfrage zur Ausführung des Quellcodes in einer unterschiedlichen Ausführungsumgebung 333, beispielsweise einer neuen VM innerhalb einer neuen Browser-Sitzung, empfangen. In diesem Fall kann das Prüfmodul 305 den zwischengespeicherten serialisierten Code im Datenspeicher 313 erfolgreich finden (Cache-Treffer). Beim Cache-Treffer kann das Front-End 303 den zwischengespeicherten serialisierten Code aus dem Datenspeicher 313 (dargestellt als 317) laden und den geladenen zwischengespeicherten serialisierten Code an das Deserialisierungsmodul 319 übermitteln. Vor dem Laden des zwischengespeicherten serialisierten Codes kann das Front-End 303 feststellen, ob der zwischengespeicherte serialisierte Code derselben Version des Quellcodes entspricht. Falls die Versionen nicht übereinstimmen, kann das Front-End 303 die Entscheidung treffen, den zwischengespeicherten serialisierten Code nicht zu deserialisieren und eine Anfrage an den Compiler 327 übermitteln, den Quellcode zu kompilieren. Das Front-End 303 kann außerdem die obsoleten zwischengespeicherten Codes entfernen, um Speicherplatz verfügbar zu machen. Das Front-End 303 kann, basierend auf einem standardmäßigen Versionsbestätigungsverfahren, das durch ein Kommunikationsprotokoll im Netzwerk 105, wie beispielsweise das Hypertext-Transfer-Protokoll (HTTP), bereitgestellt wird, die Versionen des zwischengespeicherten serialisierten Codes und des Quellcodes ermitteln.
  • Beim Erhalten des zwischengespeicherten serialisierten Codes vom Datenspeicher 313 überprüft das Deserialisierungsmodul 319 die Gültigkeit des zwischengespeicherten serialisierten Codes und deserialisiert mittels Verlagerungsdaten im serialisierten Code den zwischengespeicherten serialisierten Code in ausführbaren Code und Verweisen. Das Deserialisierungsmodul 319 übermittelt den ausführbaren Code und die Verweise zur Ausführung an die Ausführungsumgebung 333 (dargestellt als 321). Falls der deserialisierte Code Teilen des Quellcodes entspricht, können die Teile des Quellcodes, die nicht zwischengespeichert wurden, durch den Compiler 327 in ausführbaren Code kompiliert werden, während der ausführbare Code vor der Ausführung in der Ausführungsumgebung 333 mit dem deserialisierten ausführbaren Code kombiniert werden kann.
  • Es wird darauf hingewiesen, dass das Serialisierungsmodul 309 und das Deserialisierungsmodul 319 in unterschiedlichen Ausführungsumgebungen 331 und 333 aktiviert werden können. Der serialisierte Code wird in der Ausführungsumgebung 331 erzeugt (wo der ausführbare Code und die Verweise erzeugt und ausgeführt werden), während der vom Deserialisierungsmodul 319 bereitgestellte ausführbare Code und die Verweise in einer nachfolgenden Ausführungsumgebung 333 erzeugt werden.
  • Um die Größe der zwischengespeicherten Daten im Datenspeicher 313 zu verringern, kann das Komprimierungsmodul 307 die Daten komprimieren, beispielsweise indem auf den serialisierten Code vor dem Speichern des serialisierten Codes im Datenspeicher 313 verschiedene Komprimierungsalgorithmen angewendet werden. Das Komprimierungsmodul 307 kann zudem den zwischengespeicherten serialisierten Code vor dem Übermitteln des zwischengespeicherten serialisierten Codes an das Deserialisierungsmodul 319 dekomprimieren.
  • Der zwischengespeicherte serialisierte Code kann darüber hinaus als kontextunabhängige vollständige Repräsentation des ausführbaren Codes und der Verweise in einer anderen Ausführungsumgebung genutzt werden. Beispielsweise kann das Deserialisierungsmodul 319 bei der Erzeugung des ausführbaren Codes und der Verweise für die Ausführungsumgebung 333 das Verhalten des Compilers 327 imitieren, wenn der ausführbare Code und die Verweise für die Ausführungsumgebung 331 erzeugt werden. Deshalb kann die Ausführung des ausführbaren Codes und der Verweise in einer Ausführungsumgebung 333 nach Deserialisierung des zwischengespeicherten serialisierten Codes in den ausführbaren Code und die Verweise Ergebnisse bereitstellen, die mit der Ausführung des vom Compiler 327 in der Ausführungsumgebung 331 bereitgestellten ausführbaren Codes und Verweise gleichzusetzen sind.
  • Der Prozess der Deserialisierung durch das Deserialisierungsmodul 319 kann Verweise mittels der Verlagerungsdaten in den Metadaten 315 wiederherstellen, sodass die Verweise Unterschiede zwischen der Ausführungsumgebung 331 und der Ausführungsumgebung 333 wiedergeben. Da das Serialisieren und das Deserialisieren in unterschiedlichen Ausführungsumgebungen (z. B. VM-Instanzen) durchgeführt werden können, sind beispielsweise, wie vorstehend erläutert, Speicheradressen des ausführbaren Codes und der Verweise, die der Ausführungsumgebung 331 entsprechen, in der Ausführungsumgebung 333 ggf. nicht gültig. Die Serialisierung und die Deserialisierung stellen jedoch sicher, dass die Speicheradressen im deserialisierten ausführbaren Code und den Verweisen in der Ausführungsumgebung 333 gültige Adressen sind. Beispielsweise werden Verweise zu Funktionsadressen in der Ausführungsumgebung vom Serialisierungsmodul 309 nicht unverändert kodiert, da sich jene Funktionsadressen zwischen den unterschiedlichen Ausführungsumgebungen 331 und 333 unterscheiden können.
  • Das Serialisierungsmodul 309 kann jedes Objekt im Quellcode und im ausführbaren Code und den Verweisen inspizieren, um zu bestimmen, wie jedes Objekt zu serialisieren ist. Beispielsweise können bestimmte eindeutige Objekte (z. B. der kanonisch undefinierte Wert) im ausführbaren Code und den Verweisen in einem abstrakten Index (z. B. Root Array) enthalten sein. Wenn ein derartiges eindeutiges Objekt vom Serialisierungsmodul 309 serialisiert wird, serialisiert das Serialisierungsmodul 309 das Objekt durch einen eindeutigen abstrakten Index. Bei der Deserialisierung des eindeutigen Objekts durch das Deserialisierungsmodul 319 wird der Index zur Bestimmung des Objekts genutzt.
  • Darüber hinaus kann der Quellcode integrierten Code beinhalten, bei dem es sich um erzeugte Elemente von ausführbarem Code handelt, die elementare Aufgaben ausführen. Der integrierte Code kann von mehreren Objekten im Quellcode gemeinsam genutzt werden und sollte deshalb in der Ausführungsumgebung 331 (oder 333) stets vorhanden sein. Das Serialisierungsmodul 309 kann jeden integrierten Code einer integrierten Kennung zuordnen und serialisiert die integrierte Kennung als Stellvertreter des integrierten Codes im serialisierten Code. Bei der Deserialisierung kann das Front-End 303 ein integriertes Objekt mit derselben Kennung in der Ausführungsumgebung 333 finden.
  • In ähnlicher Weise kann der Quellcode einen Code-Stub beinhalten. Ein Code-Stub ist integriertem Code ähnlich, jedoch mit dem Unterschied. dass Code-Stubs bedarfsgesteuert erzeugt werden können und nicht notwendigerweise in der Ausführungsumgebung 333 vorhanden sind. Das Serisalisierungsmodul 309 kann beim Erzeugen des serialisierten Codes einen Code-Stub einem Code-Stub-Schlüssel zuordnen. Beim Deserialisieren kann das Front-End 303 prüfen, ob die Ausführungsumgebung 333 den Code-Stub beinhaltet. Falls die Ausführungsumgebung 333 den Code-Stub nicht beinhaltet, wird der dem Code-Stub entsprechende Code-Stub-Schlüssel vom Deserialisierungsmodul 319 erzeugt.
  • Darüber hinaus kann der Quellcode eindeutige Zeichenfolgenliterale beinhalten. Die eindeutigen Zeichenfolgenliterale können vom Serialisierungsmodul 309 unverändert serialisiert werden. Bei der Deserialisierung prüft das Front-End 303, ob dasselbe Zeichenfolgenliteral in der Ausführungsumgebung 333 bereits existiert. Falls das eindeutige Zeichenfolgenliteral in der Ausführungsumgebung 333 existiert, kanonisiert das Deserialisierungsmodul 319 das Zeichenfolgenliteral zur bereits existierenden eindeutigen Zeichenkette. Der Kanonisierungsprozess wandelt das Zeichenfolgenliteral mit mehr als einer Repräsentation (z. B. einer Repräsentation im zwischengespeicherten serialisierten Code und einer zweiten Repräsentation in der Ausführungsumgebung 333) in eine standardmäßige oder kanonische Form um.
  • In einigen Fällen haben serialisierte Objekte Verweise auf eine Quell-Zeichenkette des Quellcodes. In derartigen Fällen kann das Serialisierungsmodul 309 das Objekt durch eine spezielle Repräsentation ersetzen. Beim Deserialisieren kann das Deserialisierungsmodul 319 den speziellen Code durch eine Referenz zur Quellzeichenkette ersetzen, welche getrennt zum Zeitpunkt der Deserialisierung in der Ausführungsumgebung 333 bereitgestellt wird.
  • Über die vorstehend erläuterte Serialisierung von Objektadressen hinaus kann es sich bei in den ausführbaren Code eingebetteten Adressen um Adressen bestimmter Werte in der Ausführungsumgebung oder um Adressen von Funktionen der VM handeln. Die Adressen bestimmter Werte in der Ausführungsumgebung und Adressen von Funktionen der VM sind dem Compiler und der VM bekannt. Diese Adressen können beispielsweise durch eine Referenzkennung repräsentiert werden, wobei die Referenzkennung dazu genutzt werden kann, die Adresse beim Deserialisieren wiederherzustellen. Außerdem kann der Quellcode uneindeutige Objekte beinhalten. Die uneindeutigen Objekte können als Kopien serialisiert werden. Die uneindeutigen Objekte können beispielsweise aus Datenfeldern und Verweisen auf andere Objekte bestehen. Beim Serialisieren können die Datenfelder kopiert und Verweise auf andere Objekte können, sofern diese eindeutig sind, wie vorstehend im Hinblick auf eindeutige Objekte erläutert, serialisiert werden.
  • Das folgende Beispiel beschreibt ein Code-Zwischenspeicherungsverfahren von der Kompilierung zur Serialisierung und Deserialisierung eines Muster-Codes. Der musterhafte JavaScript-Code (A) ist in diesem Beispiel dargestellt. function foo () {return 1;} foo (); (A)
  • Der ausführbare Code des Muster-Codes (A) kann Anweisungen beinhalten, wie beispielsweise: Funktionskopf, Anweisungen zum Prüfen auf einen Stapelüberlauf (Aufrufen des integrierten Stapelüberlaufs), Variablendeklaration „foo“, Instanziierung des Funktionsabschlusses für innere Funktion () {return 1;}, Zuweisung des Funktionsabschlusses zu einer globalen Eigenschaft mit dem Namen „foo“, Laden einer globalen Eigenschaft mit dem Namen „foo“, Aufrufen der geladenen Eigenschaft, und Zurückmelden eines undefinierten Wertes.
  • Darüber hinaus kann der ausführbare Code (A) Verweise auf Verlagerungsinformationen beinhalten, wobei die Verlagerungsinformationen darauf hinweisen können, dass: der integrierte Stapelüberlauf ein integrierter Code ist, das Zeichenfolgenliteral „foo“ ein Objekt auf dem „Heap“ ist, die Funktionsbeschreibung für () {return 1;} ein Objekt auf dem „Heap“ ist, die Initialisierung des Funktionsabschlusses als ein Laufzeit-Aufruf implementiert und von daher ein externer Verweis ist, das Laden der Eigenschaft ein Aufruf zu einem Stub ist, das Aufrufen der Eigenschaft ein Aufruf zu einem Stub ist, und der undefinierte Wert, wie vorstehend im Hinblick auf 3 erläutert, ein Objekt auf dem „Heap“, beispielsweise ein eindeutiges Objekt, sein kann.
  • Der ausführbare Code für den Muster-Code (A) kann außerdem Metadaten beinhalten, die mit dem Zeichenfolgenliteral „foo“ verknüpft sind, beispielsweise ist „foo“ ein Objekt des Typs „internalisierte Zeichenfolge“, bezeichnet durch ein „Map-Objekt“, wobei der Inhalt der Zeichenkette „foo“ und die Länge der Zeichenkette 3 entspricht. Der ausführbare Code für den Muster-Code (A) kann zudem Funktionsbeschreibungen für die Funktion auf oberster Ebene sowie die innere Funktion function () {return 1;} beinhalten. Die Funktionsbeschreibungen können Objekte des Typs „gemeinsam genutzte Funktionsinformationen“ („Shared Function Information“), bezeichnet durch ein „Map-Objekt“, sein. Die Funktionsbeschreibungen können Zeichenpositionen für Start- und Endpunkte im Quellcode enthalten. Die Funktionsbeschreibungen können zudem auf den kompilierten Code verweisen, falls der Muster-Code (A) bereits kompiliert wurde.
  • Die innere Funktion „foo“ wird erstmalig „träge“ („lazily“) kompiliert. Träges Kompilieren bedeutet, dass die innere Funktion „foo“ nicht kompiliert wird, wenn der Code der obersten Ebene kompiliert wird, sondern dass während der Kompilierung des Codes der obersten Ebene nur eine Beschreibung der inneren Funktion „foo“ erzeugt wird. Wenn die innere Funktion „foo“ schließlich (z. B. während einer Ausführung des Codes der obersten Ebene) aufgerufen wird, wird die innere Funktion „foo“ bei Bedarf kompiliert. So lange die innere Funktion „foo“ nicht kompiliert ist, existiert für sie jedoch noch kein ausführbarer Code, und der ausführbare Code für die innere Funktion „foo“ kann nicht serialisiert werden.
  • Für eine Code-Zwischenspeicherungsplattform 209 bestehen verschiedene Möglichkeiten, den für die innere Funktion „foo“ kompilierten Code in die zwischengespeicherten Daten aufzunehmen. Die Code-Zwischenspeicherungsplattform 209 kann erkennen, dass die innere Funktion „foo“ innerhalb des Codes der obersten Ebene („foo“ ist in Muster-Code (A) definiert und wird darin aufgerufen) aufgerufen wird. Bei Vorliegen dieser Erkennung kann die Code-Zwischenspeicherungsplattform 209 die innere Funktion „foo“ als Teil der Kompilierung des Codes der obersten Ebene kompilieren und den kompilierten Code der inneren Funktion „foo“ in die Kompilierung des Codes der obersten Ebene mit einbeziehen und den kompilierten Code für das Serialisieren nach dem Kompilieren des Codes der obersten Ebene nutzen.
  • Eine weitere Möglichkeit zum Einbeziehen des kompilierten Codes für die innere Funktion „foo“ in den serialisierten Code besteht darin, dass die Code-Zwischenspeicherungsplattform 209 den Code der obersten Ebene vor der Serialisierung mindestens einmal ausführt. Da die innere Funktion „foo“ während der Ausführung des Codes der obersten Ebene aufgerufen wird, kann „foo“, wie vorstehend erläutert, „träge“ kompiliert werden, und der kompilierte Code kann in einem Speicher gespeichert werden. In diesem Fall zeigt die Beschreibung der inneren Funktion für „foo“ (während der erstmaligen Kompilierung des Codes der obersten Ebene erzeugt) beim nachfolgenden Serialisieren des Codes der obersten Ebene auf den „träge“ kompilierten Code der inneren Funktion „foo“. Dies kann die Code-Zwischenspeicherungsplattform 209 veranlassen, die innere Funktion „foo“ zu serialisieren, sobald der Code der obersten Ebene serialisiert wird.
  • Das Serialisierungsmodul 309 kann den Muster-Code (A) serialisieren, indem das Objektdiagramm aufgesucht wird, wobei Verweise beginnend an der Funktionsbeschreibung für den Code der obersten Ebene durchlaufen werden. Die Code-Zwischenspeicherungsplattform 209 kann eine Historie der im Datenspeicher 313 bereits aufgesuchten Objekte führen, sodass ein Objekt nicht mehr als einmal serialisiert wird oder in eine unendliche Schleife gerät. Die bereits aufgesuchten und serialisierten Objekte können als Rückverweise (Back References) repräsentiert (kodiert) werden. Ein Objekt kann entweder Inhalte oder Verweise zu anderen Objekte enthalten. Objektinhalte können unverändert serialisiert werden. Bei Verweisen zu anderen Objekten kann es sich jedoch entweder um Verweise auf bekannte Objekte oder um Verweise auf Objekte handeln, die ebenfalls serialisiert werden müssen. Beispielsweise kann die Funktionsbeschreibung einen Verweis auf das Verzeichnis (Map) „gemeinsam genutzter Funktionsinformationen“ („Shared Function Information“) und auf den kompilierten Code für die Funktion enthalten. Sie kann außerdem Informationen zu Zeichenpositionen enthalten, die unverändert serialisiert werden. Verzeichnisobjekte (Map Objects), auf die das Serialisierungsmodul 309 stößt, können kanonische Objekte und Teil der Root-Liste sein. Das Serialisierungsmodul 309 findet die Verzeichnisobjekte ggf. in der Root-Liste und nutzt den Index der Root-Liste, um die Objekte zu repräsentieren.
  • Das Code-Objekt für die Funktion der obersten Ebene kann, abgesehen von den Verweisen auf dessen Verzeichnis (für Code-Objekte) und dem Verweis auf die Verlagerungsinformationen, unverändert serialisiert werden. Der Anweisungsstrom kann eingebettete Zeiger enthalten, die durch die Verlagerungsinformationen beschrieben werden. Diese Zeiger werden während der Serialisierung ebenfalls aufgesucht. Da die Zeiger beim Deserialisieren aktualisiert werden müssen, können sie vor der unveränderten Serialisierung durch Nullwerte (0) ersetzt werden.
  • Das Code-Objekt der Funktion der obersten Ebene zeigt auf die Funktionsbeschreibung der inneren Funktion „foo“. Falls die innere Funktion „foo“ zu diesem Zeitpunkt bereit kompiliert wurde, zeigt deren Funktionsbeschreibung auf den kompilierten Code, sodass das Serialisierungsmodul 309 von der Funktion der obersten Ebene zur inneren Funktion „foo“ übergehen und die Code-Objekte sowohl der Funktion der obersten Ebene als auch die der inneren Funktionen serialisieren kann. Darüber hinaus können Code-Stubs durch einen Code-Stub-Schlüssel repräsentiert werden, während integrierte Codes (Built-Ins) durch „Built-In-IDs“ repräsentiert werden können. Der Inhalt einer Zeichenkette kann unverändert serialisiert werden (abgesehen von dem Zeichenkettenverzeichnis (String Map)), während externe Verweise den IDs externer Verweise (External Reference IDs) zugeordnet werden können.
  • Der Prozess der Deserialisierung durch das Deserialisierungsmodul 319 kann durch das Aufsuchen des Objektgraphen das Zurückverfolgen der Reihenfolge, in der die Serialisierung durchgeführt wurde, beinhalten. Dieses Zurückverfolgen kann dazu genutzt werden, Repräsentationen serialisierten Codes zurück in die Gegenstücke in der Ausführungsumgebung 333 zu übersetzen, in welcher der deserialisierte Code ausgeführt werden kann. Falls beispielsweise während der Serialisierung ein undefinierter Wert als Index in der Root-Liste kodiert wurde, kann das Deserialisierungsmodul 319 den Index der Root-Liste dazu verwenden, den undefinierten Wert in der Ausführungsumgebung 333 aufzufinden. Außerdem können Rückverweise (Back References) zurück in Verweise auf Objekte übersetzt werden, die bereits deserialisiert wurden. Das Ergebnis der Deserialisierung kann die Funktionsbeschreibung für die Funktion der obersten Ebene sein.
  • 4A–4B veranschaulichen Beispiele von Prozessen, mit denen die Serialisierung von Code in zwischengespeicherten Code durchgeführt werden kann. Obgleich 4A–4B in Bezug auf 1, 2 und 3 beschrieben sind, ist die betrachtete Technologie nicht darauf beschränkt und kann auf andere Client-Einheiten und -Systeme angewendet werden. 4A veranschaulicht ein Beispiel eines Prozesses zum Serialisieren von Code in zwischengespeicherten Code. Bei Block 401 empfängt das Front-End 303 einen Hinweis (z. B. einen Link, eine Adresse, eine URL usw.), dass ein primärer Quellcode auf Ausführung wartet. Beim primären Quellcode kann es sich beispielsweise um ein Script in einer Webseite zur Ausführung in einer aktuellen Browser-Sitzung handeln. Ein Benutzer der Client-Einheit 101a oder 101n, welche die Code-Zwischenspeicherungsplattform 103a oder 103n von 1 (oder Code-Zwischenspeicherungsplattform 209 von 2) hostet, kann die Ausführung des primären Quellcodes anfordern, indem er in der aktuellen Browser-Sitzung eine URL-Adresse eingibt. Die URL-Adresse kann einen Link zum Laden einer Webseite bereitstellen, welche den eingebetteten primären Quellcode beinhaltet.
  • Beim Laden der Webseite kann der Browser den Hinweis hinsichtlich des primären Quellcodes an das Front-End 303 übermitteln. In Reaktion auf den Empfang des Hinweises bei Block 403 prüft das Prüfmodul 305 einen Ressourcen-Cache im Datenspeicher 313 auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen. Beispielsweise wurde die Webseite ggf. vor der aktuellen Browser-Sitzung in einem anderen Webbrowser geladen, während die Code-Zwischenspeicherungsplattform 209 den ausführbaren Code, der dem primären Quellcode entspricht, ggf. im Datenspeicher 313 gespeichert hat. Falls der Datenspeicher 313 einen ausführbaren Code beinhaltet, der dem primären Quellcode entspricht, kann die Prüfung von Block 403 einen Cache-Treffer als Ergebnis zurückmelden. Falls die Prüfung bei Block 403 jedoch keinen Treffer erzielt, kann es sich bei dem zurückgemeldeten Ergebnis um einen Cache-Fehltreffer (dargestellt als Block 405) handeln.
  • Bei Block 407 kann das Front-End 303 bei einem Cache-Fehltreffer im Datenspeicher 313 den ausführbaren Code erhalten, der aus dem primären Quellcode kompiliert wurde. Beispielsweise kann das Front-End 303 den primären Quellcode zum Kompilieren an den Compiler 327 übermitteln.
  • Bei Block 409 kann das Front-End 303 Teile des Quellcodes oder des sekundären Quellcodes auswählen, auf den im primären Quellcode verwiesen wird. Beim sekundären Quellcode kann es sich beispielsweise um eine Funktion handeln, auf die im primären Quellcode verwiesen wird. Die Auswahl der Teile des Quellcodes kann, wie im Hinblick auf 2 und 3 erläutert, auf verschiedenen Faktoren und Kriterien (Heuristiken) basieren. Bei Block 411 kann das Front-End 303 einen ausführbaren Code erhalten, der aus dem sekundären Quellcode kompiliert wurde. Beispielsweise kann das Front-End 303 den sekundären Quellcode zum Kompilieren an den Compiler 327 übermitteln. In manchen Fällen kann das Front-End 303 einen gesamten Quellcode, einschließlich des primären Quellcodes und eines Satzes von sekundären Quellcodes, auf die im primären Quellcode verwiesen wird, an den Compiler übermitteln, ohne die Teile auszuwählen. Das Front-End 303 kann beispielsweise bei Erhalt des Cache-Fehltreffers den Quellcode und/oder die ausgewählten sekundären Quellcodes, auf die im Quellcode verwiesen wird, an den Compiler 327 übermitteln.
  • Der Compiler 327 kompiliert den empfangenen primären Quellcode oder den sekundären Quellcode und übermittelt den ausführbaren Code an das Serialisierungsmodul 309. Der Compiler 327 kann den ausführbaren Code in einem Speicher der Client-Einheit 101a oder 101n speichern. Der ausführbare Code beinhaltet einen Satz von Verweisen, wie beispielsweise Adressen und Kennungen, die sich auf Objekte im Quellcode oder die ausgewählten Teile beziehen. Der Satz von Verweisen, der sich auf den ausführbaren Code bezieht, kann Speicheradressen beinhalten, die im ausführbaren Code eingebettet sind, welcher der Ausführungsumgebung 331 entspricht. Bei der Ausführungsumgebung 331 (oder 333) kann es sich um VMs innerhalb der Webbrowser-Sitzung handeln, in welcher der Quellcode ausgeführt wird. Die Verweise stellen Ausführungsdaten für den ausführbaren Code 329 für Prozessor 201 bereit, wenn der ausführbare Code in einer Ausführungsumgebung 331, beispielsweise einer VM-Umgebung, ausgeführt wird, die von einer Ausführungsmaschine (nicht dargestellt) für den ausführbaren Code erzeugt wird.
  • Beim Empfang des ausführbaren Codes durch den Compiler 327 bei Block 413 serialisiert das Serialisierungsmodul 309 den ausführbaren Code. Die Serialisierung beinhaltet, wie vorstehend im Hinblick auf 2 und 3 erläutert, das Abstrahieren des Satzes von Verweisen im ausführbaren Code aus der Ausführungsumgebung 331 sowie das Bestimmen von mit dem serialisierten Code verknüpften Verlagerungsdaten, um die Abstraktionen wiederzugeben. Das Abstrahieren des Satzes von Verweisen aus der Ausführungsumgebung 331 durch das Serialisierungsmodul 309 kann das Ersetzen von eingebetteten Speicheradressen durch abstrakte Adressen beinhalten. Beispielsweise kann eine eingebettete Adresse zu einer Funktion der VM in einen bestimmten Index in einer vorbestimmten Liste von Funktionen umgewandelt werden. In manchen Fällen kann, falls der ausführbare Code eine Adresse enthält, die auf denselben Code zeigt, eine abstrakte Adresse erzeugt werden, indem eine Speicheradresse durch eine Distanzadresse ab einer Startadresse eines dem ausführbaren Code zugewiesenen Speicherblocks ersetzt wird, während die eingebettete Adresse in die relative Distanz ab der Startadresse des Codes umgewandelt werden kann.
  • Bei Block 415 speichert das Front-End 303 den serialisierten Code als zwischengespeicherte Daten in einem Ressourcen-Cache im Datenspeicher 313, der zur Ausführung in der Ausführungsumgebung 331 bereitzustellen ist. In manchen Fällen kann das Front-End 303 vor der Serialisierung des ausführbaren Codes durch das Serialisierungsmodul 309 die Verfügbarkeit eines Prozessors 201 zur Durchführung der Serialisierung feststellen. In diesen Fällen kann, sofern ein Prozessor nicht verfügbar ist, das Front-End 303 die Serialisierung so lange verzögern, bis der Prozessor verfügbar wird.
  • Der Quellcode kann Verweise auf mehrere sekundäre Quellcodes (z. B. Funktionen) beinhalten. In diesen Fällen kann der ausführbare Code mehrere ausführbare sekundäre Quellcodes beinhalten, sodass sich jeder ausführbare sekundäre Quellcode auf einen sekundären Quellcode bezieht, auf den im Quellcode verweisen wird. Das Front-End 303 kann ausführbaren sekundären Quellcode zur Serialisierung auswählen. Das Front-End 303 kann außerdem bestimmen, dass ausführbarer sekundärer Quellcode innerhalb des serialisierten Codes deserialisiert bleibt. Das Front-End 303 kann das Deserialisieren des sekundären Quellcodes basierend auf den mit dem ausführbaren Code verknüpften Verweisen, basierend auf den Verlagerungsdaten, basierend auf einem Typ der sekundären Quellcodes, basierend auf einer Sicherheitskennung der sekundären Quellcodes usw. bestimmen. Bei dem Quellcode kann es sich um ein Script der obersten Ebene einer Anwendung 207 handeln. Das Front-End 303 kann das Script der obersten Ebene der Anwendung 207, beispielsweise basierend auf vorbestimmten Bedingungen, zur Serialisierung als Quellcode auswählen.
  • In manchen Fällen kann das Front-End 303 einen Hinweis (z. B. einen Link, eine Adresse, eine URL usw.) darauf empfangen, dass der primäre Quellcode auf Ausführung wartet. Bei dem primären Quellcode kann es sich beispielsweise um ein Script in einer Webseite handeln. In Reaktion auf den Empfang des Hinweises prüft das Prüfmodul 305, wie im Hinblick auf Block 403 von 4A erläutert, den Ressourcen-Cache im Datenspeicher 313 auf zwischengespeicherte Daten, die dem primären Quellcode und dem in Block 409 von 4A ausgewählten sekundären Quellcode entsprechen. Bei einem Cache-Treffer im Ressourcen-Cache im Datenspeicher 313 kann das Front-End 303 die zwischengespeicherten Daten, einschließlich des serialisierten Codes, aus dem Ressourcen-Cache im Datenspeicher 313 abrufen.
  • Das Deserialisierungsmodul 319 kann den abgerufenen zwischengespeicherten serialisierten Code in ausführbaren Code deserialisieren. Die Deserialisierung durch das Deserialisierungsmodul 319 kann das Wiederherstellen des Satzes von Verweisen im ausführbaren Code, basierend auf einer Ausführungsumgebung 333, mittels des abgerufenen zwischengespeicherten serialisierten Codes beinhalten. Das Front-End 303 kann den ausführbaren Code und die Verweise zur Ausführung in der Ausführungsumgebung 333 bereitstellen.
  • Es wird darauf hingewiesen, dass die Deserialisierung durch das Deserialisierungsmodul 319 in einigen Fällen, beispielsweise bedingt durch eine Datenkorruption, scheitern kann. In diesen Fällen kann das Front-End 303 den zwischengespeicherten serialisierten Code aus dem Datenspeicher 313 löschen. Deshalb kann das Prüfmodul 305 beim nächsten Mal, wenn ein Hinweis darauf, dass der Quellcode auf die Ausführung wartet, empfangen wird, wie bei Block 403 von 4A dargestellt, einen Cache-Fehltreffer als Ergebnis zurückmelden, und der Serialisierungsprozess kann gemäß 4A ausgeführt werden.
  • In manchen Fällen basiert die Auswahl des sekundären Quellcodes von Block 409 möglicherweise auf Ausführungsergebnissen, die aus der Ausführung des bei Block 407 erhaltenen ausführbaren Codes erhalten wurden. Beispielsweise kann der erste, bei Block 407 erhaltene ausführbare Code, vor Auswahl des sekundären Codes ggf. einmal oder mehrere Male ausgeführt werden. In diesen Fällen kann die Code-Zwischenspeicherungsplattform 209 die Ausführungsergebnisse aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext erhalten und den sekundären Quellcode basierend auf den Ausführungsergebnissen auswählen. Bei Ausführung des ersten ausführbaren Codes kann die Code-Zwischenspeicherungsplattform 209 Daten erfassen, die mit der Ausführung in Beziehung stehen, um sekundäre Quellcodes (z. B. Funktionen) zu bestimmen, auf die verwiesen wird und welche ausgeführt werden.
  • Anstatt den gesamten Quellcode zu zwischenspeichern, kann die Code-Zwischenspeicherungsplattform 209 die ausgeführten sekundären Quellcodes zum Zwischenspeichern auswählen. Aufgrund verschiedener Bedingungen im primären Quellcode, mit der Ausführungsumgebung auf der Client-Einheit 200 in Zusammenhang stehender Bedingungen, Benutzereingaben usw., werden ggf. einige sekundäre Quellcodes (z. B. Funktionen) ausgeführt und einige nicht. Die Code-Zwischenspeicherungsplattform 209 kann sekundäre Quellcodes bestimmen, die ausgeführt werden, indem mit mehrfachen Ausführungen des primären Quellcodes auf der Client-Einheit 200 in Beziehung stehende Daten erfasst werden, und kann sekundäre Quellcodes bestimmen, die häufiger als andere sekundäre Quellcodes ausgeführt werden. Die Code-Zwischenspeicherungsplattform 209 kann, basierend auf der Bestimmung, den sekundären Quellcode für das Zwischenspeichern auswählen. Die Code-Zwischenspeicherungsplattform 209 kann außerdem Funktionsaufrufe innerhalb des primären Quellcodes bestimmen, wobei jeder Funktionsaufruf die Ausführung einer Funktion beinhaltet. Die Code-Zwischenspeicherungsplattform 209 kann Informationen über die Ausführung der Funktionsaufrufe erfassen und die Funktionen auswählen, die während der Ausführung zum Zwischenspeichern ausgeführt werden.
  • Die Code-Zwischenspeicherungsplattform 209 kann den sekundären Quellcode, basierend auf verschiedenen weiteren Faktoren, wie beispielsweise Größe des sekundären Quellcodes, Größe des sekundären ausführbaren Codes, Anzahl der Male, die im primären Quellcode auf den sekundären Quellcode verwiesen wird, Kompilierungsdauer des sekundären Quellcodes usw., auswählen.
  • Zum Beispiel veranschaulicht 4B einen exemplarischen Prozess zum Serialisieren von Code in zwischengespeicherten Code basierend auf einem Satz von Bedingungen. Bei Block 421 empfängt das Front-End 303 einen Hinweis (z. B. einen Link, eine Adresse, eine URL usw.) darauf, dass ein primärer Quellcode auf Ausführung wartet. In Reaktion auf den Empfang des Hinweises bei Block 423 prüft das Prüfmodul 305, wie vorstehend im Hinblick auf 4A erläutert, einen Ressourcen-Cache im Datenspeicher 313 auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen. Falls die Prüfung bei Block 423 keinen Treffer erzielt, kann es sich bei dem zurückgemeldeten Ergebnis um einen Cache-Fehltreffer (dargestellt als Block 425) handeln.
  • Bei Block 427 kann das Front-End 303 bei einem Cache-Fehltreffer im Datenspeicher 313 den ausführbaren Code erhalten, der aus dem primären Quellcode kompiliert wurde. Beispielsweise kann das Front-End 303 den primären Quellcode zum Kompilieren an den Compiler 327 übermitteln.
  • Bei Block 429 serialisiert das Serialisierungsmodul 309 den ausführbaren Codes in serialisierten Code, basierend auf der Größe des primären Quellcodes, der Anzahl der Male oder der Häufigkeit, die der primäre Quellcode innerhalb einer vorbestimmten Zeitspanne ausgeführt wird, der Kompilierungsdauer des primären Quellcodes oder einer Kombination derselben. Wird beispielsweise der primäre Quellcode weniger als 10 Mal während einer Woche ausgeführt, kann sich das Serialisierungsmodul 309 dafür entscheiden, auf die Serialisierung des primären Quellcodes zu verzichten. Ein häufig (z. B. mehr als 10 Mal innerhalb einer Woche) ausgeführter primärer Quellcode wird jedoch möglicherweise serialisiert. Bei Block 431 speichert das Front-End 303 den serialisierten Code als zwischengespeicherte Daten in einem Ressourcen-Cache im Datenspeicher 313, der zur Ausführung in einer Ausführungsumgebung 331 oder 333 bereitzustellen ist.
  • Wie vorstehend dargelegt, werden Aspekte der betrachteten Technologie in Bezug auf das Zwischenspeichern von ausführbarem Code zur Ausführung in unterschiedlichen Ausführungsumgebungen, wie z. B. in Instanzen von Webbrowsern, beschrieben, wo die Daten in einer Webbrowser-Sitzung serialisiert und in einer anderen Webbrowser-Sitzung deserialisiert werden. Die betrachtete Technologie ist jedoch nicht auf die Webbrowser-Umgebung beschränkt. Die betrachtete Technologie kann für das Zwischenspeichern von ausführbarem Code in jeder beliebigen Ausführungsumgebung anwendbar sein. Darüber hinaus kann die betrachtete Technologie für das Serialisieren und Zwischenspeichern von Daten in einer ersten Client-Einheit 101a–101n von 1 (oder Server 109a–109m von 1) und das Übertragen der zwischengespeicherten Daten an eine zweite Client-Einheit 101a–101n (oder Server 109a–109m) anwendbar sein, sodass die zwischengespeicherten Daten in der zweiten Client-Einheit 101a–101n (oder Server 109a–109m) deserialisiert und ausgeführt werden.
  • Die vorstehend beschriebenen Leistungsmerkmale und Anwendungen können als Softwareprozesse implementiert werden, die als ein Satz von Anweisungen spezifiziert sind, die auf einem computerlesbaren Speichermedium (auch als ein von einem Computer lesbares Medium bezeichnet) aufgezeichnet sind. Wenn diese Anweisungen von einer oder mehreren Verarbeitungseinheit(en) (z. B. Prozessoren, Prozessorkernen oder sonstigen Verarbeitungseinheiten) ausgeführt werden, veranlassen sie die Verarbeitungseinheit(en) dazu, die in den Anweisungen angegebenen Aktionen auszuführen. Beispiele computerlesbarer Medien beinhalten unter anderem CD-ROMs, Flash-Laufwerke, RAM-Chips, Festplatten, EPROMs usw. Die computerlesbaren Medien beinhalten keine Trägerwellen und elektronische Signale, die drahtlos oder über drahtgebundene Verbindungen gesendet werden.
  • In dieser Spezifikation wird der Begriff „Software“ so verstanden, dass er Firmware beinhaltet, die sich im schreibgeschützten Speicher oder in auf Magnetspeicher gespeicherten Anwendungen befindet, die zur Verarbeitung durch einen Prozessor in den Speicher eingelesen werden kann. Darüber hinaus können in einigen Implementierungen mehrere Softwaretechniken als Teilelemente eines größeren Programms implementiert sein, während sie ihren Charakter als voneinander abgegrenzte Softwaretechniken beibehalten. In einigen Implementierungen können mehrere Softwaretechniken zudem als separate Programme implementiert sein. Letztendlich liegt jede beliebige Kombination von separaten Programmen, die gemeinsam eine hierin beschriebene Softwaretechnik implementieren, im Schutzumfang der betrachteten Technologie. In einigen Implementierungen definieren die Software-Programme, wenn sie dafür installiert werden, auf elektronischen Systemen betrieben zu werden, spezifische Maschinenimplementierungen, welche die Operationen der Software-Programme ausführen und abarbeiten.
  • Ein Computerprogramm (auch als Quellcode, Programm, Software, Software-Anwendung, Script, Code bekannt), kann in jeder beliebigen Form einer Programmiersprache, darunter auch in Form von kompilierten oder interpretierten Sprachen, deklarativen oder prozeduralen Sprachen, geschrieben sein. Darüber hinaus kann ein Computerprogramm in jeglicher Form bereitgestellt werden, darunter auch als eigenständiges Programm oder als ein Modul, eine Komponente, eine Subroutine, ein Objekt oder eine andere, zur Nutzung in einer Computerumgebung geeigneten Einheit. Ein Computerprogramm kann, muss jedoch nicht einer Datei in einem Dateisystem entsprechen. Ein Programm kann in einem Teil einer Datei, die andere Programme oder Daten enthält (z. B. ein oder mehrere Scripts, die in einem Dokument in Markup-Sprache gespeichert sind), in einer einzelnen Datei speziell für das betreffende Programm oder in mehreren koordinierten Dateien (z. B. Dateien, die ein oder mehrere Module, Unterprogramme oder Teile von Code speichern) gespeichert sein. Ein Computerprogramm kann auf einem Computer oder auf mehreren Computern bereitgestellt und ausgeführt werden, die sich an einem Standort oder auf mehreren Standorten verteilt befinden und über ein Kommunikationsnetzwerk miteinander verbunden sind.
  • 5 veranschaulicht konzeptuell ein exemplarisches elektronisches System, bei dem einige Implementierungen der betrachteten Technologie implementiert sein können. Das elektronische System 500 kann ein Computer, ein Mobilgerät, PDA oder jede andere beliebige Art von elektronischem Gerät sein. Dieses elektronische System beinhaltet verschiedene Arten an computerlesbaren Medien und Schnittstellen für unterschiedliche andere Arten an computerlesbaren Medien. Das elektronische System 500 beinhaltet einen Bus 508, Verarbeitungseinheit(en) 512, einen Systemspeicher 504, einen schreibgeschützten Speicher (ROM) 510, eine Speichereinheit zur dauerhaften Speicherung 502, eine Eingabegerätschnittstelle 514, eine Ausgabegerätschnittstelle 506 sowie eine Netzwerkschnittstelle 516.
  • Der Bus 508 repräsentiert kollektiv alle System-, Peripherie- und Chipsatzbusse, welche die zahlreichen internen Einheiten des elektronischen Systems 500 kommunikativ verbinden. Beispielsweise verbindet der Bus 508 kommunikativ die Verarbeitungseinheit(en) 512 mit dem ROM 510, dem Systemspeicher 504 sowie der Speichereinheit zur dauerhaften Speicherung 502.
  • Aus diesen verschiedenen Speichereinheiten ruft/rufen die Verarbeitungseinheit(en) 512 Anweisungen zum Ausführen sowie Daten zum Verarbeiten ab, um die Prozesse der betrachteten Offenbarung auszuführen. Bei der/den Verarbeitungseinheit(en) kann es sich um einen einzelnen Prozessor oder einen Multikernprozessor in unterschiedlichen Implementierungen handeln.
  • Der schreibgeschützte Speicher (ROM) 510 speichert statische Daten und Anweisungen, die von der/den Verarbeitungseinheit(en) 512 und von anderen Modulen des elektronischen Systems benötigt werden. Bei der Speichereinheit zur dauerhaften Speicherung 502 handelt es sich anderseits um ein lesbares und beschreibbares Speichergerät. Dieses Gerät ist eine nicht flüchtige Speichereinheit, die Anweisungen und Daten selbst dann speichert, wenn das elektronische System 500 ausgeschaltet ist. Einige Implementierungen der betrachteten Offenbarung verwenden eine Massenspeichereinheit (beispielsweise eine magnetische oder optische Platte und deren entsprechenden Plattenlaufwerke) als Speichereinheit zur dauerhaften Speicherung 502.
  • Andere Implementierungen verwenden ein Wechselspeichergerät (beispielsweise eine Diskette, ein Flash-Laufwerk und dessen entsprechendes Laufwerk) als Speichereinheit zur dauerhaften Speicherung 502. Wie bei der Speichereinheit zur dauerhaften Speicherung 502 handelt es sich beim Systemspeicher 504 um ein Speichergerät zum Lesen und Schreiben. Im Unterschied zur Speichereinheit zur dauerhaften Speicherung 502 handelt es sich beim Systemspeicher 504 um einen flüchtigen Schreib-/Lese-Speicher, wie beispielsweise einen Speicher mit wahlfreiem Zugriff. Der Systemspeicher 504 speichert einige der Anweisungen und Daten, die der Prozessor während der Laufzeit benötigt. Bei einigen Implementierungen werden die Prozesse der betrachteten Offenbarung im Systemspeicher 504, in der Speichereinheit zur dauerhaften Speicherung 502 oder im ROM 510 gespeichert. Beispielsweise beinhalten die verschiedenen Speichereinheiten gemäß einigen Implementierungen Anweisungen zur Darstellung von Web-Elementen. Aus diesen verschiedenen Speichereinheiten ruft/rufen die Verarbeitungseinheit(en) 512 Anweisungen zum Ausführen und Verarbeiten der Daten ab, um die Prozesse einiger Implementierungen auszuführen.
  • Der Bus 508 ist ebenfalls mit den Ein- und Ausgabegeräteschnittstellen 514 und 506 verbunden. Die Eingabegeräteschnittstelle 514 ermöglicht dem Benutzer, Befehle auszuwählen und Informationen an das elektronische System zu kommunizieren. Eingabegeräte, die mit der Eingabegeräteschnittstelle 514 verwendet werden, beinhalten beispielsweise alphanumerische Tastaturen und Zeigegeräte (auch „Cursor-Steuergeräte“ genannt). Ausgabegeräteschnittstellen 506 ermöglichen beispielsweise die Anzeige von Bildern, die vom elektronischen System 500 erzeugt werden. Ausgabegeräte, die mit Ausgabegerätschnittstelle 506 verwendet werden, beinhalten beispielsweise Drucker und Anzeigegeräte, wie beispielsweise Kathodenstrahlröhren (Cathode Ray Tubes, CRT) oder Flüssigkristallanzeigen (Liquid Crystal Displays, LCD). Einige Implementierungen beinhalten Geräte, wie beispielsweise einen Berührungsbildschirm, die als Eingabe- und Ausgabegeräte fungieren.
  • Schließlich koppelt, wie in 5 dargestellt, der Bus 508 außerdem das elektronische System 500 durch eine Netzwerkschnittstelle 516 an ein Netzwerk (nicht dargestellt). Auf diese Weise kann der Computer ein Teil eines Netzwerks von Computern (beispielsweise ein lokales Netzwerk („LAN“), ein Großraumnetzwerk („WAN“) oder ein Intranet oder ein Netzwerk von Netzwerken, wie beispielsweise das Internet, sein. Jede beliebige oder alle Komponenten des elektronischen Systems 500 können in Verbindung mit der betrachteten Offenbarung verwendet werden.
  • Diese vorstehend beschriebenen Funktionen können in einer digitalen elektronischen Schaltungsanordnung, einer Computer-Software, Firmware oder Hardware implementiert sein. Die Techniken können unter Verwendung von Computerprogrammprodukten implementiert sein. Programmierbare Prozessoren und Computer können in Mobilgeräte integriert oder in Form von Mobilgeräten gebündelt werden. Die Prozesse und logischen Abläufe können von programmierbaren Prozessoren und mit programmierbaren Logikschaltungen ausgeführt werden. Universal- und Spezial-Client-Einheiten und -Speichergeräte können über Kommunikationsnetzwerke miteinander verbunden sein.
  • Einige Implementierungen beinhalten elektronische Komponenten, beispielsweise Mikroprozessoren, Datenspeicher und Arbeitsspeicher, die Computer-Programmanweisungen auf einem maschinenlesbaren oder computerlesbaren Medium (alternativ als computerlesbare Speichermedien, maschinenlesbare Medien oder maschinenlesbare Speichermedien bezeichnet) speichern. Einige Beispiele dieser computerlesbaren Medien beinhalten RAM, ROM, schreibgeschützte CDs (CD-ROM), beschreibbare CDs (CD-R), überschreibbare CDs (CD-RW), schreibgeschützte DVDs (z. B. DVD-ROM, Dual-Layer DVD-ROM), eine Vielzahl von beschreibbaren oder überschreibbaren DVDs (z. B. DVD-RAM, DVD–RW, DVD+RW, usw.), Flash-Speicher (z. B. SD-Karten, Mini-SD-Karten, Mikro-SD-Karten, usw.), magnetische oder Halbleiter-Festplatten, schreibgeschützte und beschreibbare Blu-Ray® Discs, optische Platten mit ultrahoher Dichte (Ultra Density Optical Discs), andere optische oder magnetische Medien und Disketten. Die computerlesbaren Medien können ein Computerprogramm speichern, das von mindestens einer Verarbeitungseinheit ausführbar ist, und Sätze von Anweisungen zum Ausführen verschiedener Operationen beinhalten. Beispiele von Computerprogrammen oder Computercode beinhalten Maschinencode, der beispielsweise von einem Compiler erzeugt wird, und Dateien, die Code höherer Ebene beinhalten, der durch einen Computer, eine elektronische Komponente oder einen Mikroprozessor ausgeführt wird, der ein Interpretierprogramm verwendet.
  • Während sich die vorstehende Erläuterung in erster Linie auf Mikroprozessoren oder Mehrkernprozessoren bezieht, die Software ausführen, werden einige Implementierungen durch integrierte Schaltungen, beispielsweise durch anwendungsspezifische integrierte Schaltungen (ASICs) oder durch feldprogrammierbare Universalschaltkreise (FPGAs) ausgeführt. In einigen Implementierungen führen diese integrierten Schaltungen Anweisungen aus, die auf der Schaltung selbst gespeichert werden.
  • Wie in dieser Spezifikation und jeglichen Ansprüchen dieser Anmeldung verwendet, beziehen sich die Begriffe „Computer“, „Server“, „Prozessor“ und „Speicher“ in ihrer Gesamtheit auf elektronische oder sonstige technologische Geräte bzw. Vorrichtungen. Diese Begriffe schließen Menschen oder Menschengruppen aus. Für die Zwecke dieser Spezifikation bedeuten die Begriffe „Anzeigen“ oder „Anzeige“ das Anzeigen auf einem elektronischen Gerät. Wie in dieser Spezifikation und jeglichen Ansprüchen dieser Anmeldung verwendet, beziehen sich die Begriffe „computerlesbares Medium“ und „computerlesbare Medien“ ausschließlich auf physische Objekte, die Informationen in einer Form speichern, die von einem Computer eingelesen werden kann. Diese Begriffe schließen alle drahtlosen Signale, Signale, die über drahtgebundene Systeme heruntergeladen werden, und alle anderen ephemeren Signale aus.
  • Um Interaktionen mit einem Benutzer zu ermöglichen, können die in dieser Spezifikation beschriebenen Implementierungen der Betrachtungseinheit auf einem Computer implementiert werden, der über ein Anzeigegerät, wie z. B. einen CRT-Monitor (Kathodenstrahlröhre) oder LCD-Monitor (Flüssigkristallanzeige) zur Anzeige von Informationen für den Benutzer, sowie über eine Tastatur und ein Zeigegerät (z. B. eine Maus oder einen Trackball), mit denen der Benutzer den Computer bedienen kann, verfügt. Ebenso können andere Arten von Geräten bzw. Vorrichtungen verwendet werden, um die Interaktion mit einem Benutzer zu ermöglichen. Zum Beispiel kann es sich bei der Rückmeldung an den Benutzer um jegliche Art von sensorischer Rückmeldung, wie z. B. visuelle, akustische oder taktile Rückmeldungen, handeln. Auch die Eingaben des Benutzers können in beliebiger Form, darunter auch akustisch, sprachlich oder taktil, empfangen werden. Außerdem kann ein Computer durch das Senden von Dokumenten an und das Empfangen von Dokumenten von einem Gerät bzw. einer Vorrichtung, das bzw. die vom Benutzer verwendet wird, mit einem Benutzer interagieren, beispielsweise durch das Senden von Webseiten an einen Webbrowser auf der Client-Einheit eines Benutzers in Reaktion auf die vom Webbrowser empfangenen Anfragen.
  • Die in dieser Spezifikation beschriebenen Implementierungen der Betrachtungseinheit können in einem Computersystem implementiert werden, das eine Back-End-Komponente, beispielsweise als Datenserver, beinhaltet oder eine Middleware-Komponente, beispielsweise als Anwendungsserver, beinhaltet oder eine Front-End-Komponente, beispielsweise einen Client-Computer beinhaltet, der über eine grafische Benutzeroberfläche oder über einen Webbrowser verfügt, durch den ein Benutzer mit einer in dieser Spezifikation beschriebenen Implementierung der Betrachtungseinheit interagieren kann, oder eine beliebige Kombination derartiger Back-End-, Middleware- oder Front-End-Komponenten beinhaltet. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium digitaler Datenkommunikation, wie beispielsweise ein Kommunikationsnetzwerk, miteinander verbunden sein. Beispiele für Kommunikationsnetzwerke beinhalten ein lokales Netzwerk („LAN“) und ein Großraumnetzwerkwerk („WAN“), ein Inter-Netzwerk (z. B. das Internet) und Peer-to-Peer-Netzwerke (z. B. ad hoc-Peer-to-Peer-Netzwerke).
  • Das Computersystem kann Clients und Server beinhalten. Ein Client und Server befinden sich im Allgemeinen entfernt voneinander und interagieren über ein Kommunikationsnetzwerk. Die Beziehung zwischen Client und Server entsteht aufgrund von Computerprogrammen, die auf den jeweiligen Computern ausgeführt werden, und die eine Client-Server-Beziehung zueinander aufweisen. Bei einigen Implementierungen sendet ein Server Daten (z. B. eine HTML-Seite) an eine Client-Einheit (z. B. zu Zwecken des Anzeigens von Daten und Empfangens von Benutzereingaben von einem Benutzer, der mit der Client-Einheit interagiert). Daten, die an der Client-Einheit erzeugt werden (z. B. ein Ergebnis der Benutzerinteraktion) können von der Client-Einheit am Server empfangen werden.
  • Es wird davon ausgegangen, dass jede spezifische Reihenfolge oder Hierarchie von Schritten in den offenbarten Verfahren eine Veranschaulichung von exemplarischen Herangehensweisen bzw. Ansätzen darstellt. Basierend auf den Design-Präferenzen wird davon ausgegangen, dass die spezifische Reihenfolge oder Hierarchie der Schritte in den Verfahren geändert werden kann, oder dass alle veranschaulichten Schritte durchgeführt werden. Einige der Schritte können gleichzeitig durchgeführt werden. Unter bestimmten Umständen können beispielsweise Multitasking und Parallelverarbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung verschiedener Systemkomponenten in den vorstehend beschriebenen Implementierungen nicht als in allen Implementierungen erforderlich ausgelegt werden, zudem sollte davon ausgegangen werden, dass die beschriebenen Programmkomponenten und Systeme im Allgemeinen in einem einzelnen Software-Produkt oder in mehreren Software-Produkten gebündelt integriert sein können.
  • Die vorstehende Beschreibung wird bereitgestellt, um sämtliche Fachleute auf dem Gebiet in die Lage zu versetzen, die verschiedenen, hierin beschriebenen Aspekte in die Tat umzusetzen. Verschiedene Modifikationen dieser Aspekte sind für Fachleute auf dem Gebiet ohne weiteres erkennbar, darüber hinaus können die hierin definierten allgemeinen Prinzipien auf andere Aspekte angewendet werden. Die Ansprüche sollen daher die hierin dargestellten Aspekte in keiner Weise einschränken, sondern ihnen gemäß den Ansprüchen bezüglich der Sprache den vollen Schutzumfang zugestehen, wobei ein Bezug auf ein Element im Singular, sofern nicht anders angegeben, nicht „ein und nur ein“, sondern vielmehr „ein oder mehrere“ bedeuten soll. Sofern nicht ausdrücklich anders angegeben, bezieht sich der Begriff „einige“ bzw. „manche“ auf „ein oder mehrere“. Pronomen im Maskulin (z. B. „sein“) beinhalten auch den weiblichen und sächlichen Genus (z. B. „ihr“ und „sein“) und umgekehrt. Überschriften und Zwischenüberschriften, falls vorhanden, werden nur der Einfachheit halber verwendet und sollen die betrachtete Offenbarung in keiner Weise einschränken.
  • Eine Phrase, wie beispielsweise ein „Aspekt“ bedeutet nicht, dass der Aspekt für die betrachtete Technologie von wesentlicher Bedeutung ist oder dass der Aspekt für alle Konfigurationen der betrachteten Technologie gilt. Eine sich auf einen Aspekt beziehende Offenbarung kann auf alle, eine oder mehrere Konfigurationen zutreffen. Eine Phrase, wie beispielsweise ein Aspekt, kann sich auf einen oder auf mehrere Aspekte und umgekehrt beziehen. Eine Phrase, wie beispielsweise eine „Konfiguration“, bedeutet nicht, dass diese Konfiguration für die betrachtete Technologie von wesentlicher Bedeutung ist, oder dass diese Konfigurationen für alle Konfigurationen der betrachteten Technologie gelten. Eine sich auf eine Konfiguration beziehende Offenbarung kann auf alle, eine oder mehrere Konfigurationen zutreffen. Eine Phrase, wie beispielsweise eine Konfiguration, kann sich auf eine oder mehrere Konfigurationen und umgekehrt beziehen.

Claims (21)

  1. System für Code-Zwischenspeicherung umfassend: einen oder mehrere Prozessoren; und ein maschinenlesbares Medium, das darin gespeicherte Anweisungen umfasst, bei deren Ausführung durch den einen oder die mehreren Prozessoren der eine oder die mehreren Prozessoren veranlasst werden, Operationen auszuführen, die Operationen umfassend: Empfangen eines ersten Hinweises darauf, dass primärer Quellcode auf die Ausführung wartet; in Reaktion auf den Empfang des ersten Hinweises Prüfen eines Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen; und bei einem Cache-Fehltreffer im Ressourcen-Cache: Erhalten des ersten, aus dem primären Quellcode kompilierten, ausführbaren Codes; Auswählen von sekundärem Quellcode, auf den im primären Quellcode verwiesen wird; Erhalten von zweitem ausführbarem Code, der aus dem ausgewählten sekundären Quellcode kompiliert ist; Serialisieren des ersten ausführbaren Codes und des zweiten ausführbaren Codes in serialisierten Code; und Speichern des serialisierten Codes als zwischengespeicherte Daten im Ressourcen-Cache.
  2. System nach Anspruch 1, wobei die Anweisungen den einen oder die mehreren Prozessoren außerdem veranlassen, Operationen auszuführen, die Operationen umfassend: Erhalten von Ausführungsergebnissen aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext, wobei der sekundäre Quellcode basierend auf den Ausführungsergebnissen ausgewählt wird.
  3. System nach Anspruch 1, wobei der sekundäre Quellcode, basierend auf einem oder mehreren des Folgenden, ausgewählt wird, und zwar aus: einer Größe des sekundären Quellcodes, einer Größe des zweiten ausführbaren Codes, einer Prognose, dass im primären Quellcode auf den sekundären Quellcode verwiesen wird, einer Anzahl der Male, die im primären Quellcode auf den sekundären Quellcode verwiesen wird, einer Häufigkeit, mit der im primären Quellcode auf den sekundären Quellcode verwiesen wird, oder einer Kompilierungsdauer des sekundären Quellcodes.
  4. System nach Anspruch 1, wobei die Anweisungen den einen oder die mehreren Prozessoren außerdem veranlassen, Operationen auszuführen, die Operationen umfassend: Empfangen eines zweiten Hinweises darauf, dass der primäre Quellcode auf die Ausführung in einem zweiten Ausführungskontext wartet, wobei der zweite Hinweis im Anschluss an den ersten Hinweis empfangen wird; in Reaktion auf den Empfang des zweiten Hinweises Prüfen des Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode und dem ausgewählten sekundären Quellcode entsprechen; und bei einem Cache-Treffer im Ressourcen-Cache: Abrufen der zwischengespeicherten Daten, die den serialisierten Code aus dem Ressourcen-Cache umfassen; Deserialisieren des abgerufenen serialisierten Codes in dritten ausführbaren Code; und Bereitstellen des dritten ausführbaren Codes zur Ausführung im zweiten Ausführungskontext.
  5. System nach Anspruch 4, wobei der erste Ausführungskontext und der zweite Ausführungskontext zwei unterschiedliche virtuelle Maschinenumgebungen zur Code-Ausführung sind.
  6. System nach Anspruch 5, wobei der primäre Quellcode ein Script in einer Webseite ist und der erste Ausführungskontext und der zweite Ausführungskontext Webbrowser-Sitzungen sind, in denen das Script ausgeführt wird.
  7. System nach Anspruch 1, wobei der primäre Quellcode ein Script auf oberster Ebene einer Webseite ist.
  8. System nach Anspruch 1, wobei der erste ausführbare Code einen Satz von Verweisen, darunter auch im ersten ausführbaren Code eingebettete Speicheradressen, umfasst, und wobei das Serialisieren des ersten ausführbaren Codes das Ersetzen der eingebetteten Speicheradressen durch abstrakte Adressen beinhaltet.
  9. System für Code-Zwischenspeicherung umfassend: einen oder mehrere Prozessoren; und ein maschinenlesbares Medium, das darin gespeicherte Anweisungen umfasst, bei deren Ausführung durch den einen oder die mehreren Prozessoren der eine oder die mehreren Prozessoren veranlasst werden, Operationen auszuführen, die Operationen umfassend: Empfangen eines ersten Hinweises darauf, dass primärer Quellcode auf die Ausführung wartet; in Reaktion auf den Empfang des ersten Hinweises Prüfen eines Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen; und bei einem Cache-Fehltreffer im Ressourcen-Cache: Erhalten des ersten, aus dem primären Quellcode kompilierten, ausführbaren Codes; Serialisieren des ersten ausführbaren Codes in serialisierten Code, basierend auf einem oder mehreren der Folgenden: einer Größe des primären Quellcodes, einer Anzahl der Male oder einer Häufigkeit, mit welcher der primäre Quellcode innerhalb einer vorbestimmten Zeitspanne ausgeführt wird, oder eine Kompilierungsdauer des primären Quellcodes; und Speichern des serialisierten Codes als zwischengespeicherte Daten im Ressourcen-Cache.
  10. System nach Anspruch 9, wobei die Anweisungen den einen oder die mehreren Prozessoren außerdem veranlassen, Operationen auszuführen, die Operationen umfassend: Auswahl von sekundärem Quellcode, auf den im primären Quellcode verwiesen wird, zumindest basierend auf einer Größe des sekundären Quellcodes, einer Größe des zweiten ausführbaren Codes, einer Anzahl der Male, mit der im primären Quellcode auf den sekundären Quellcode verwiesen wird, einer Häufigkeit, mit der im primären Quellcode auf den sekundären Quellcode verwiesen wird, oder einer Kompilierungsdauer des sekundären Quellcodes, oder einer Kombination derselben; Erhalten von zweitem ausführbarem Code, der aus dem sekundärem Quellcode kompiliert ist; und Serialisieren des zweiten ausführbaren Codes in den serialisierten Code.
  11. System nach Anspruch 9, wobei die Anweisungen den einen oder die mehreren Prozessoren außerdem veranlassen, Operationen auszuführen, die Operationen umfassend: Erhalten von Ausführungsergebnissen aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext, wobei der sekundäre Quellcode basierend auf den Ausführungsergebnissen ausgewählt wird.
  12. System nach Anspruch 10, wobei die Anweisungen den einen oder die mehreren Prozessoren außerdem veranlassen, Operationen auszuführen, die Operationen umfassend: Empfangen eines zweiten Hinweises darauf, dass der primäre Quellcode auf die Ausführung in einem zweiten Ausführungskontext wartet, wobei der zweite Hinweis im Anschluss an den ersten Hinweis empfangen wird; in Reaktion auf den Empfang des zweiten Hinweises Prüfen des Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode und dem ausgewählten sekundären Quellcode entsprechen; und bei einem Cache-Treffer im Ressourcen-Cache: Abrufen der zwischengespeicherten Daten, welche den serialisierten Code aus dem Ressourcen-Cache umfassen; Deserialisieren des abgerufenen serialisierten Codes in dritten ausführbaren Code; und Bereitstellen des dritten ausführbaren Codes zur Ausführung im zweiten Ausführungskontext.
  13. System nach Anspruch 12, wobei der erste Ausführungskontext und der zweite Ausführungskontext zwei unterschiedliche virtuelle Maschinenumgebungen zur Code-Ausführung sind.
  14. System nach Anspruch 9, wobei der erste ausführbare Code einen Satz von Verweisen, darunter auch im ersten ausführbaren Code eingebettete Speicheradressen, umfasst, und wobei das Serialisieren des ersten ausführbaren Codes das Ersetzen der eingebetteten Speicheradressen durch abstrakte Adressen beinhaltet.
  15. Computerlesbares Medium, das Anweisungen umfasst, bei deren Ausführung durch einen Computer der Computer veranlasst wird, Folgendes durchzuführen: Empfangen eines ersten Hinweises darauf, dass primärer Quellcode auf die Ausführung wartet; in Reaktion auf den Empfang des ersten Hinweises Prüfen eines Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode entsprechen; und bei einem Cache-Fehltreffer im Ressourcen-Cache: Erhalten des ersten, aus dem primären Quellcode kompilierten, ausführbaren Codes; Erhalten von Ausführungsergebnissen aus der Ausführung des ersten ausführbaren Codes in einem ersten Ausführungskontext; Auswählen von sekundärem Quellcode, auf den im primären Quellcode verwiesen wird, basierend auf den Ausführungsergebnissen; Erhalten von zweitem ausführbarem Code, der aus dem ausgewählten sekundären Quellcode kompiliert ist; Serialisieren des ersten ausführbaren Codes und des zweiten ausführbaren Codes in serialisierten Code; Speichern des serialisierten Codes als zwischengespeicherte Daten im Ressourcen-Cache.
  16. Computerlesbares Medium nach Anspruch 15, wobei der erste ausführbare Code einen Satz von Verweisen, darunter auch im ersten ausführbaren Code eingebettete Speicheradressen, umfasst, und wobei das Serialisieren des ersten ausführbaren Codes das Ersetzen der eingebetteten Speicheradressen durch abstrakte Adressen beinhaltet.
  17. Computerlesbares Medium nach Anspruch 15, wobei die Ausführungsergebnisse bei der Ausführung des primären Quellcodes eine Anzahl von Malen angeben, die der sekundäre Quellcode, auf den im primären Quellcode verwiesen wird, ausgeführt wird.
  18. Computerlesbares Medium nach Anspruch 15, wobei die Anweisungen den Computer außerdem veranlassen, Folgendes durchzuführen: Empfangen eines zweiten Hinweises darauf, dass der primäre Quellcode auf die Ausführung in einem zweiten Ausführungskontext wartet, wobei der zweite Hinweis im Anschluss an den ersten Hinweis empfangen wird; in Reaktion auf den Empfang des zweiten Hinweises Prüfen des Ressourcen-Cache auf zwischengespeicherte Daten, die dem primären Quellcode und dem ausgewählten sekundären Quellcode entsprechen; und bei einem Cache-Treffer im Ressourcen-Cache: Abrufen der zwischengespeicherten Daten, welche den serialisierten Code aus dem Ressourcen-Cache umfassen; Deserialisieren des abgerufenen serialisierten Codes in dritten ausführbaren Code; und Bereitstellen des dritten ausführbaren Codes zur Ausführung im zweiten Ausführungskontext.
  19. Computerlesbares Medium nach Anspruch 18, wobei der erste Ausführungskontext und der zweite Ausführungskontext zwei unterschiedliche virtuelle Maschinenumgebungen zur Code-Ausführung sind.
  20. System nach Anspruch 18, wobei die Anweisungen dem Computer außerdem veranlassen, Folgendes durchzuführen: Erhalten eines ersten, mit dem ersten ausführbaren Code verknüpften Ausführungsprofils und eines zweiten, mit dem zweiten ausführbaren Code verknüpften Ausführungsprofils; Serialisieren des ersten Ausführungsprofils und des zweiten Ausführungsprofils; und Speichern des serialisierten ersten Ausführungsprofils und des zweiten Ausführungsprofils im Ressourcen-Cache, wobei das Deserialisieren des abgerufenen serialisierten Codes das Deserialisieren des ersten Ausführungsprofils und des zweiten Ausführungsprofils beinhaltet.
  21. System nach Anspruch 15, wobei die Anweisungen den Computer außerdem veranlassen, Folgendes durchzuführen: Bestimmen der Verfügbarkeit eines Ausführungskontextes für das Serialisieren des primären Quellcodes; und Verzögern der Serialisierung, wenn die Bestimmung die Nichtverfügbarkeit des Ausführungskontextes angibt.
DE112016002416.9T 2015-05-29 2016-03-29 System für code-zwischenspeicherung Withdrawn DE112016002416T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/726,376 2015-05-29
US14/726,376 US9811324B2 (en) 2015-05-29 2015-05-29 Code caching system
PCT/US2016/024791 WO2016195790A1 (en) 2015-05-29 2016-03-29 Code caching system

Publications (1)

Publication Number Publication Date
DE112016002416T5 true DE112016002416T5 (de) 2018-03-08

Family

ID=57398598

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016002416.9T Withdrawn DE112016002416T5 (de) 2015-05-29 2016-03-29 System für code-zwischenspeicherung

Country Status (8)

Country Link
US (1) US9811324B2 (de)
EP (1) EP3304293B1 (de)
JP (1) JP6329329B2 (de)
KR (1) KR101851357B1 (de)
CN (1) CN107408055B (de)
DE (1) DE112016002416T5 (de)
GB (1) GB2553444B (de)
WO (1) WO2016195790A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170123760A1 (en) * 2015-10-30 2017-05-04 AppDynamics, Inc. Code Correction During a User Session in a Distributed Business Transaction
US11360750B1 (en) * 2020-12-23 2022-06-14 Sony Interactive Entertainment LLC Systems and methods for converting a legacy code into an updated code
CN114328061B (zh) * 2021-12-30 2024-03-29 湖南泛联新安信息科技有限公司 一种用于逻辑仿真系统的高性能信号监视方法

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5452457A (en) 1993-01-29 1995-09-19 International Business Machines Corporation Program construct and methods/systems for optimizing assembled code for execution
US5509129A (en) 1993-11-30 1996-04-16 Guttag; Karl M. Long instruction word controlling plural independent processor operations
US6393415B1 (en) * 1999-03-31 2002-05-21 Verizon Laboratories Inc. Adaptive partitioning techniques in performing query requests and request routing
US7761857B1 (en) * 1999-10-13 2010-07-20 Robert Bedichek Method for switching between interpretation and dynamic translation in a processor system based upon code sequence execution counts
US20060206874A1 (en) 2000-08-30 2006-09-14 Klein Dean A System and method for determining the cacheability of code at the time of compiling
US7640153B2 (en) * 2001-06-04 2009-12-29 Hewlett-Packard Development Company, L.P. Networked client-server architecture for transparently transforming and executing applications
KR100503077B1 (ko) * 2002-12-02 2005-07-21 삼성전자주식회사 자바 실행 장치 및 자바 실행 방법
US7805710B2 (en) * 2003-07-15 2010-09-28 International Business Machines Corporation Shared code caching for program code conversion
US7890961B2 (en) * 2003-08-29 2011-02-15 Yahoo! Inc. Method and apparatus for providing desktop application functionality in a client/server architecture
US7818724B2 (en) * 2005-02-08 2010-10-19 Sony Computer Entertainment Inc. Methods and apparatus for instruction set emulation
US8402224B2 (en) 2005-09-20 2013-03-19 Vmware, Inc. Thread-shared software code caches
JP2007233472A (ja) * 2006-02-27 2007-09-13 Canon Inc 情報処理装置、情報処理装置の制御方法および制御プログラム
US8245202B2 (en) * 2007-04-18 2012-08-14 Sony Computer Entertainment Inc. Processor emulation using speculative forward translation
US8286152B2 (en) * 2007-08-22 2012-10-09 International Business Machines Corporation Systems, methods, and computer products for just-in-time compilation for virtual machine environments for fast application startup and maximal run-time performance
US8392881B1 (en) 2008-05-13 2013-03-05 Google Inc. Supporting efficient access to object properties in a dynamic object-oriented programming language
US8321850B2 (en) 2008-06-06 2012-11-27 Vmware, Inc. Sharing and persisting code caches
US8095507B2 (en) 2008-08-08 2012-01-10 Oracle International Corporation Automated topology-based statistics monitoring and performance analysis
US8707161B2 (en) 2009-09-30 2014-04-22 Facebook, Inc. Executing server side script code specified using PHP on a server to generate dynamic web pages
US9003380B2 (en) * 2010-01-12 2015-04-07 Qualcomm Incorporated Execution of dynamic languages via metadata extraction
US8479176B2 (en) * 2010-06-14 2013-07-02 Intel Corporation Register mapping techniques for efficient dynamic binary translation
US20110321010A1 (en) 2010-06-24 2011-12-29 Yifei Wang Web application framework based on object oriented class mapping
KR101782995B1 (ko) 2011-01-13 2017-09-29 삼성전자주식회사 자바스크립트 코드 저장 및 최적화를 통한 웹 브라우징 방법 및 장치
US8867337B2 (en) * 2011-04-26 2014-10-21 International Business Machines Corporation Structure-aware caching
US9069876B2 (en) * 2011-05-25 2015-06-30 Nokia Corporation Memory caching for browser processes
US9047407B2 (en) 2011-12-16 2015-06-02 Microsoft Technology Licensing, Llc State capture after execution in dependent sequences
US9110751B2 (en) * 2012-02-13 2015-08-18 Microsoft Technology Licensing, Llc Generating and caching software code
US10339069B2 (en) * 2012-09-28 2019-07-02 Oracle International Corporation Caching large objects in a computer system with mixed data warehousing and online transaction processing workload
US20140095778A1 (en) * 2012-09-28 2014-04-03 Jaewoong Chung Methods, systems and apparatus to cache code in non-volatile memory

Also Published As

Publication number Publication date
EP3304293B1 (de) 2021-09-15
JP6329329B2 (ja) 2018-05-23
KR20170125398A (ko) 2017-11-14
US20160350089A1 (en) 2016-12-01
US9811324B2 (en) 2017-11-07
GB2553444B (en) 2018-09-05
CN107408055A (zh) 2017-11-28
WO2016195790A1 (en) 2016-12-08
GB2553444A (en) 2018-03-07
JP2018510428A (ja) 2018-04-12
GB201715440D0 (en) 2017-11-08
KR101851357B1 (ko) 2018-04-24
CN107408055B (zh) 2019-08-16
EP3304293A1 (de) 2018-04-11

Similar Documents

Publication Publication Date Title
Brown et al. Implementation patterns for microservices architectures
US20170323026A1 (en) Patching Base Document Object Model (DOM) with DOM-Differentials to Generate High Fidelity Replay of Webpage User Interactions
US20120191840A1 (en) Managing Application State Information By Means Of A Uniform Resource Identifier (URI)
US20110231784A1 (en) System and method for desktop application migration
Brunelle et al. The impact of JavaScript on archivability
DE202014010938U1 (de) Omega-Namen: Namenserzeugung und -ableitung
US9952835B2 (en) Generation of hybrid enterprise mobile applications in cloud environment
US20170004221A1 (en) Establishment of state representation of a web page represented in a web browser
CN111010364B (zh) 用于基于离线对象的存储和模拟rest响应的系统
CN105550206B (zh) 结构化查询语句的版本控制方法及装置
USRE45021E1 (en) Method and software for processing server pages
CN112612943A (zh) 一种基于异步处理框架的具有自动测试功能的数据爬取方法
DE112016002416T5 (de) System für code-zwischenspeicherung
Mendoza et al. BrowStEx: A tool to aggregate browser storage artifacts for forensic analysis
CN104980464B (zh) 一种网络请求处理方法、网络服务器和网络系统
CN106294760A (zh) 表单处理方法及服务器、客户端
CN107506597A (zh) 医学文档获取方法、终端及服务器
Parker et al. Using caching and optimization techniques to improve performance of the Ensembl website
CN112231534A (zh) 一种配置爬虫的方法与设备
CN105117473A (zh) 一种基于Web的信息查询系统及信息查询方法
Xiaoshu Optimized development of web front-end development technology
Brodie et al. Accelerating dynamic web content delivery using keyword-based fragment detection
Wang Optimized Development of Web Front-end Development Technology
Irimus Sequential and asynchronous fetching of large amounts of data in web applications
Roche Copying websites

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: GOOGLE LLC (N.D.GES.D.STAATES DELAWARE), MOUNT, US

Free format text: FORMER OWNER: GOOGLE INC., MOUNTAIN VIEW, CALIF., US

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee