DE112011103406T5 - Verwaltung von nicht geänderten Objekten - Google Patents

Verwaltung von nicht geänderten Objekten Download PDF

Info

Publication number
DE112011103406T5
DE112011103406T5 DE112011103406T DE112011103406T DE112011103406T5 DE 112011103406 T5 DE112011103406 T5 DE 112011103406T5 DE 112011103406 T DE112011103406 T DE 112011103406T DE 112011103406 T DE112011103406 T DE 112011103406T DE 112011103406 T5 DE112011103406 T5 DE 112011103406T5
Authority
DE
Germany
Prior art keywords
code
objects
singleton
unmodified
analyzing
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
DE112011103406T
Other languages
English (en)
Inventor
Paolina Centonze
Marco Pistoia
Peter K. Malkin
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112011103406T5 publication Critical patent/DE112011103406T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/44Encoding
    • G06F8/443Optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design
    • G06F8/24Object-oriented

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)
  • Adornments (AREA)

Abstract

Ein Verfahren beinhaltet, unter Verwenden einer statischen Analyse, die an Code ausgeführt wird, Analysieren des Codes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Codes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden. Das Verfahren enthält auch Ausgeben des modifizierten Codes. Vorrichtungen und Programmprodukte werden ebenfalls offenbart. Ein weiteres Verfahren beinhaltet Zugreifen auf Code von einem Client aus und in Reaktion darauf, dass der gesamte Code Quellcode ist, Kompilieren des Quellcodes in Objektcode, bis der gesamte Code von dem Client Objektcode aufweist. Das Verfahren beinhaltet des Weiteren, unter Verwenden einer statischen Analyse, die an dem Objektcode ausgeführt wird, Analysieren des Objektcodes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Objektcodes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden. Das Verfahren beinhaltet außerdem Zurückgeben des modifizierten Objektcodes an den Client.

Description

  • HINTERGRUND
  • Diese Erfindung betrifft allgemein die Analyse von Code wie beispielsweise Objektcode, Bytecode, ausführbaren Code und Bibliotheken und betrifft insbesondere die statische Analyse von Code.
  • Objektorientierte (OO) Programmierung hat viele Vorzüge. Zum Beispiel kann ein Programmierer mit OO-Programmierung ein einzelnes Objekt definieren und dann dieses Objekt während der Programmausführung mehrmals instanziieren. Des Weiteren können Objekte auch Merkmale von anderen Objekten übernehmen. Dies ermöglicht eine problemlose Wiederverwendung von Objekten in verschiedenen Programmen.
  • Zwar weist OO-Programmierung viele Vorzüge auf, doch kann dieser Programmierungstyp auch verbessert werden.
  • KURZDARSTELLUNG
  • In einem Aspekt der Erfindung enthält ein Verfahren, das eine statische Analyse verwendet, die an Code ausgeführt wird, Analysieren des Codes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Codes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden. Das Verfahren enthält auch Ausgeben des modifizierten Codes. Vorrichtungen und Programmprodukte werden ebenfalls offenbart.
  • In einem weiteren beispielhaften Aspekt der Erfindung wird ein Verfahren offenbart, das Zugreifen auf Code von einem Client aus und in Reaktion darauf, dass der gesamte Code Quellcode ist, Kompilieren des Quellcodes in Objektcode enthält, bis der gesamte Code von dem Client Objektcode aufweist. Das Verfahren enthält des Weiteren unter Verwendung einer statischen Analyse, die an dem Objektcode ausgeführt wird, Analysieren des Objektcodes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Objektcodes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden. Das Verfahren enthält außerdem Zurückgeben des modifizierten Objektcodes an den Client.
  • KURZE BESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNGEN
  • 1 ist ein Ablaufplan eines beispielhaften Verfahrens für die Verwaltung von nicht geänderten Objekten;
  • 2 ist ein Ablaufplan eines beispielhaften Verfahrens zum Analysieren von Code, um einen Satz von nicht geänderten Zielobjekten zu ermitteln;
  • 3 ist ein Blockschaubild eines Systems für die Verwaltung von nicht geänderten Objekten gemäß einer beispielhaften Ausführungsform;
  • 4 ist ein Ablaufplan eines beispielhaften Verfahrens zum Ermitteln von nicht geänderten Objekten;
  • 5 ist ein Ablaufplan eines weiteren beispielhaften Verfahrens zum Ermitteln von nicht geänderten Objekten;
  • 6 ist ein Ablaufplan eines beispielhaften Verfahrens zum Modifizieren von Code, so dass alle Verwendungen der Mitglieder eines Satzes von nicht geänderten Zielobjekten die Singleton-Muster-Technik anwenden; und
  • 7 ist ein Ablaufplan eines beispielhaften Verfahrens zum Ermitteln von nicht veränderbaren Objekten.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Wie vorher beschrieben, hat objektorientierte (OO) Programmierung viele Vorzüge. OO-Systeme ermöglichen jedoch auch dann die Erstellung mehrerer Objekte, wenn diese Objekte dieselbe Entität logisch darstellen. Mit diesem Ansatz sind mindestens drei Probleme verbunden:
    • 1. In OO-Systemen müssen Objekte zwei Methoden implementieren: „equals” und „hashCode”. Die equals-Methode nimmt ein anderes Objekt als einen Parameter: a.equals(b) gibt „wahr” zurück, wenn a und b logisch dieselbe Entität darstellen. Die equals-Methode muss sorgfältig implementiert werden. Typischerweise testen Entwickler auf die Gleichheit der inneren Felder der beiden Objekte, was bedeutet, dass die equals-Methode rekursiv aufgerufen wird, bis die Gleichheit an Feldern von Basiselementtypen oder Zeichenketten getestet ist. Die hashCode-Methode erzeugt eine Zahl innerhalb eines festen Bereichs auf der Grundlage des Objekts, auf dem die Methode abgerufen wird. Diese Methode ist sehr wichtig, wenn Objekte in hashSets eingefügt werden. Wenn ein Objekt in ein hashSet eingefügt wird, wird zunächst sein hashCode berechnet, und das Objekt wird dann in das hashSet in dem Bucket eingefügt, das dem hashCode des Objekts entspricht. Bevor das Objekt eingefügt wird, wird das Bucket durchsucht, um zu überprüfen, dass vorher kein anderes gleiches Objekt eingefügt wurde. Auf diese Weise sind in dem Satz unter Einhaltung der mathematischen Definition von „Satz” keine doppelten Einträge vorhanden. Wenn jedoch hashCode und equals nicht konsistent implementiert werden, können Fehler (so genannte „Bugs”) entstehen. Wenn beispielsweise zwei gleiche Objekte letztendlich unterschiedliche hashCodes haben könnten, würden sie in unterschiedlichen Buckets desselben hashSets eingefügt, was doppelte Einträge in einem Satz zur Folge hätte. Die Konsequenzen eines Bugs dieses Typs könnten sehr schwerwiegend sein.
    • 2. Eine weitere Einschränkung dieser Auslegung ist besteht darin, dass die Auslegung eine Menge Speicher beanspruchen kann. Die Tatsache, dass logisch gleichwertige Objekte mehrfach in demselben System instanziiert werden können, kann eine unnötige Inanspruchnahme von Speicher verursachen. Im Idealfall sollte kein Objekt instanziiert werden, wenn ein logisch gleichwertiges Objekt (wobei das equals-Verfahren ”wahr” zurückgibt) bereits instanziiert worden ist.
    • 3. Schließlich liegt eine weitere Einschränkung dieses Ansatzes in der Zeit, die jedes Mal beim Ausführen der equals-Methode in Anspruch genommen wird. Wie oben erwähnt, muss die equals-Methode implementiert werden, um die Gleichheit sämtlicher der inneren Felder der Objekte zu testen, und dieser Prozess löst einen kaskadierenden Test aus, in dem sämtliche Felder der Felder rekursiv auf Gleichheit getestet werden. Wenn es möglich wäre, die Erstellung eines Objekts jedes Mal zu verhindern, wenn ein anderes Objekt, das dem ursprünglichen Objekt logisch gleichwertig ist, bereits im Speicher vorhanden ist, wäre es nicht notwendig, solche kostenintensiven Gleichheitstests auszuführen, und es wäre ausreichend, auf Zeigergleichheit zu testen (z. B. unter Verwendung des „==”-Operators).
  • Diese Probleme werden ad hoc gelöst. Entwickler müssen einen Zwischenspeicherungsmechanismus implementieren, der auf vorhandene Objekte in Cachespeichern prüft und, wann immer dies möglich ist, diese Objekte zurückgibt statt neue zu erstellen. Darüber hinaus können diese Lösungen nicht auf Bibliothekscode angewendet werden, in dem bereits Klassen ohne derartige Zwischenspeicherungsmechanismen implementiert sind und dessen Quellcode möglicherweise nicht einmal verfügbar ist.
  • Hierin werden beispielhafte Techniken vorgeschlagen, um wenigstens die drei oben beschriebenen Probleme zu lösen. Eine statische Analyse kann statisch (d. h. ohne Ausführung von Code) die Gleichheit von Objekten in Code erkennen. Wenn zwei Objekte als gleich erachtet werden, kann die statische Analyse angeben, dass die beiden Objekte eigentlich dasselbe Objekt sein sollten. Des Weiteren kann die statische Analyse die Arbeit eines Bytecode-Rewriters steuern, um Bibliothekscode zu modifizieren, dessen Quellcode nicht mehr zur Verfügung steht.
  • In einer beispielhaften Ausführungsform werden die folgenden Modifizierungen von der statischen Analyse empfohlen, wobei die Modifizierungen Code so modifizieren, dass alle Verwendungen von Mitgliedern eines Satzes von nicht geänderten Zielobjekten die Singleton-Muster-Technik anwenden:
    • 1. Jede Klasse hat einen zugehörigen Cachespeicher.
    • 2. Jedes Mal, wenn der Konstruktor einer Klasse aufgerufen wird, wird in dem entsprechenden Cachespeicher nachgesehen.
    • 3. Wenn ein Objekt mit den Merkmalen, die in den Konstruktoraufrufen angegeben sind, bereits in dem Cachespeicher vorhanden ist, wird das Objekt nicht erstellt. Stattdessen wird das Objekt aus dem Cachespeicher zurückgegeben.
    • 4. Wenn ein Objekt mit den Merkmalen, die in den Konstruktoraufrufen angegeben sind, noch nicht in dem Cachespeicher vorhanden ist, wird das Objekt erstellt, zu dem Cachespeicher hinzugefügt und zurückgegeben.
  • Als eine weitere Optimierung können die oben genannten Modifizierungen nur angewendet werden, wenn zwei oder mehrere gleiche Objekte statisch erkannt worden sind. Zu weiteren Modifizierungen gehört für Klassen, für die ein Cachespeicher erstellt worden ist, dass Aufrufe der equals-Methode durch den „==”-Operator ersetzt werden können (das heißt, einen Operator, der zwei Gleichheitszeichen hintereinander aufweist). Eine weitere Optimierung enthält das Szenario, in dem „equals” (ist gleich) ein Singleton-relevanter Operator ist, wobei „==” die Singleton-relevante Operatorentsprechung ist.
  • Eine beispielhafte Ausführungsform der Erfindung ist nicht auf Client-Code beschränkt, sondern kann auch auf Bibliothekscode angewendet werden. Bei Bibliothekscode ist der typische Nachteil, dass eventuell kein Quellcode verfügbar ist. Eine beispielhafte Lösung wird auf der Grundlage von neugeschriebenem Bytecode vorgeschlagen, wodurch der Bytecode der Bibliothek modifiziert wird. Das Gleichheitsprinzip (a == b) ==> (a.equals(b) == wahr) garantiert, dass die oben aufgelisteten Modifizierungen die Programmsemantik nicht modifizieren, z. B. so lange die statische Analyse einwandfrei ist.
  • Des Weiteren wird angemerkt, dass die hierin offenbarten Verfahren auch als Dienst bereitgestellt werden könnten. Zum Beispiel würde der Dienstanbieter in einer beispielhaften Ausführungsform zum Standort eines Client kommen, einen Zwischenspeicherungsdienst bereitstellen (z. B. eine Datenbank), die oben genannte Methode für den gesamten Objektcode des Client ausführen, um so den Objektcode zu modifizieren und dann den modifizierten Objektcode ausführen. In einem anderen Beispiel kann der Client Code (z. B. Quell-, Objekt-, ausführbaren Code) an einen Server senden, und der Server führt die hierin beschriebene(n) Verfahren für den gesamten Code des Clients aus, um so den Code zu modifizieren und dann den modifizierten Code an den Client zu senden. Der Client kann dem Server auch gestatten, auf den Code des Clients zuzugreifen, indem der Serverzugriff auf ein internes System mit dem Client-Code gestattet wird. Diese beispielhaften Techniken ermöglichen es dem Client, die betrieblichen Vorteile der oben genannten Erfindung zu erhalten, ohne tatsächlich die hierin beschriebenen Techniken ausführen zu müssen.
  • Unter folgender Bezugnahme auf die beispielhaften Ausführungsformen ist in 1 ein Ablaufplan eines beispielhaften Verfahrens 100 für die Verwaltung von nicht geänderten Objekten dargestellt. Das Verfahren 100 beginnt im Block 1A, in dem auf ein System 105 von Code 110 zugegriffen wird. Der Code 110 enthält einen oder mehrere von Quellcode 115 (z. B. Client-Quellcode 115-1) oder Objektcode 120 (z. B. Bibliothekscode 120-1 und/oder Client-Objektcode 120-2). Ein typisches System würde z. B. den Client-Quellcode 115-1 und den Bibliotheks-Objektcode 120-1 enthalten. Dies ermöglicht, dass der Client-Quellcode 115-1 kompiliert (Block IE) und somit ein „vollständiges” Programm erstellt werden kann, z. B. ein System 121 des Objektcodes 120. Es sind jedoch andere Beispiele möglich. Zum Beispiel könnte das Verfahren 100 nur auf dem Bibliotheks-Objektcode 120-1 oder nur auf dem Quellcode 115 arbeiten (z. B. nach dem Kompilieren im Block IE, um den Objektcode 120 zu erstellen). In dem letzteren Fall (in dem nur auf dem Quellcode 115 gearbeitet wird) wäre eine Kompilierung nicht notwendig.
  • Zu Beispielen für das Zugreifen auf das System 105 von Code 110 zählen Empfangen des Codes 110 von einem Client (Block 1B), Zugreifen auf Code vom Speicher aus (Block 1C) oder Zugreifen auf Code in der Einrichtung eines Clients (Block 1D). Ein „Client” enthält interne Kunden (z. B. einen Bereich einer Entität, wobei ein anderer Bereich der Entität die hierin beschriebenen Techniken ausführt) oder externe Kunden (z. B. führt ein Bereich einer Entität die hierein beschriebenen Techniken an Code von einer anderen Entität aus). Der Block 1B kann durch Empfangen des Codes 110 z. B. über eine Netzwerkschnittstelle ausgeführt werden. Es wird angemerkt, dass bedingt durch den Block 1B der empfangene Code in einem Speicher abgelegt und zu einem späteren Zeitpunkt auf den Speicher zugegriffen werden kann (Block 1C).
  • Die Blöcke 1F, 1G und optional 1J werden unter Verwendung einer statischen Analyse statisch ausgeführt. Das heißt, die statische Analyse führt nicht den Objektcode 120 (oder das System 121 des Objektcodes 120) aus, sondern arbeitet stattdessen auf dem Objektcode 120, ohne einen derartigen Code auszuführen. Im Block 1F wird das System 121 des Objektcodes analysiert, um einen Satz 125 von nicht geänderten „Ziel”-Objekten zu ermitteln. Die Analyse und Ermittlung von nicht geänderten Zielobjekten wird unter Bezugnahme auf 2 als eine beispielhafte Ausführungsform ausführlich beschrieben. Nicht geänderte Zielobjekte sind kurz gesagt nicht geänderte Objekte, bei denen eine Maßzahl für eine Singleton-Muster-Technik einen gewissen Schwellenwert einhält. Ein nicht geändertes Objekt ist ein Objekt, das sich während nachfolgender Laufzeit (z. B. Ausführung) nicht ändert. Ein Objekt ändert sich, wenn sein Wert – oder die Werte von irgendeiner seiner Instanzvariablen – sich ändert. Zum Beispiel würde sich bei vorgegebenen einem Objekt eines komplexen Typs, wie beispielsweise „Employee” (Mitarbeiter), eine Instanz employee_123 ändern, wenn sich irgendeine ihrer Instanzvariablen ändert, z. B. wenn sich employee_123.lastname von „Doe” in „Smith” ändert. Eine statische Analyse kann ermitteln, ob sich ein Objekt während nachfolgender Laufzeit ändern würde.
  • Im Block 1G wird der Objektcode 120 so modifiziert, dass alle Verwendungen der Mitglieder des Satzes 125 von nicht geänderten Zielobjekten die Singleton-Muster-Technik anwenden. Das heißt, alle Mitglieder des Satzes 125 von nicht geänderten Zielobjekten schränken das Instanziieren einer Klasse auf ein einziges Objekt ein. Ein Beispiel des Blocks 1G wird im Block 1H bereitgestellt, in dem alle Instanzen ermittelt werden, in denen ein Singleton-relevanter Operator auf ein Singleton angewendet wird, und in dem der vorgegebene Singleton-relevante Operator in jeder Instanz durch seine Singleton-relevante Operatorentsprechung ersetzt wird. Ein weiteres Beispiel des Blocks 1G wird im Block 1P gezeigt, in dem Aufrufe von relevanten Operatoren durch ihre Singleton-Muster-Entsprechung ersetzt werden (z. B. durch Ersetzen der equals-Methode durch Verwendungen des „==”-Operators) für alle Mitglieder des Satzes 125 von nicht geänderten Zielobjekten. Ein Beispiel könnte die hashCode()-Methode sein, die auf jedem Java-Objekt gemäß der Tatsache aufgerufen werden kann, dass java.lang.Object (die Superklasse aller Objekte in Java) hashCode() implementiert. Wenn Objekte eines bestimmten Typs dem Singleton-Muster folgen, bedeutet dies, dass keine zwei verschiedenen Objekte auf equals() mit „wahr” antworten können. Dies vereinfacht die Implementierung von hashCode() auch dadurch, dass es hinreichend ist, den Zeiger zu dem Objekt in einen Hashwert umzuwandeln und nicht kostenintensive Hashwerte auf der Grundlage der internen Darstellung jedes Objekts berechnen zu müssen.
  • Im Block 1J wird das modifizierte System 130 des modifizierten Objektcodes 140 zurückgegeben (z. B. ausgegeben). Die Ausgabe könnte einfach an einen Speicher (z. B. eine Datenbank) erfolgen. Zu Beispielen des Blocks 1J gehören Zurückgeben des modifizierten Objektcodes 140 an den Client durch Übertragen des modifizierten Objektcodes an einen Client (Block 1K), Zurückgeben des modifizierten Objektcodes 140 an den Speicher (Block 1L) oder Zurückgeben des Codes an den Client, indem der modifizierte Objektcode 140 an einer geeigneten Adresse in der Einrichtung des Client abgelegt wird (Block 1M). Zum Beispiel könnte für die Letztere von einer Datenbank aus auf den Quellcode 115 zugegriffen werden (Block 1D), und der modifizierte Code 140 könnte wieder in der Datenbank abgelegt werden (Block 1M).
  • Im Block 1N wird das modifizierte System 130 des modifizierten Objektcodes 140 ausgeführt, z. B. von einer Laufzeitumgebung. Es wird angemerkt, dass der Block 1N eventuell nicht ausgeführt wird, beispielsweise wenn das Verfahren 100 verwendet wird, um ausschließlich auf dem Bibliotheks-Objektcode 120-1 oder ausschließlich auf dem Client-Objektcode 120-2 zu arbeiten und der Client-Objektcode 120-2 den Bibliothekscode 120-1 zum Arbeiten benötigt und der Code 120-1 nicht verfügbar ist.
  • Unter folgender Bezugnahme auf 2 wird ein Ablaufplan eines beispielhaften Verfahrens 200 zum Analysieren von Code und Ermitteln eines Satzes 125 von nicht geänderten Zielobjekten gezeigt. Das Verfahren 200 ist ein Beispiel dafür, wie der Block 1F von 1 ausgeführt werden könnte.
  • Im Kontext der vorliegenden Erfindung schlagen zwei Faktoren zu Buche: Inanspruchnahme des Speichers und Laufzeitauslastung. Dass es mehrere Instanzen eines Objekts gibt, jede mit demselben Wert, ist wie oben beschrieben insofern nachteilig, als Computerspeicher verschwendet wird. Wenn drei Instanzen eines Java-Zeichenkettenobjekts vorhanden sind, jede zum Beispiel mit dem Wert „No”, werden (mindestens) 6 Bytes an Speicher verwendet, ein Byte für jedes Zeichen. Wenn diese drei Objekte den Wert nie ändern, wird tatsächlich nur eine Zeichenkettenobjekt-Instanz mit einem Wert „No” benötigt, wofür nur 2 Bytes erforderlich sind. Des Weiteren (ebenfalls wie oben beschrieben) erhöhen Objektmethoden, z. B. equals() und hashCode(), die Belastung während einer vorgegebenen Laufzeit. Um zum Beispiel die equals()-Methode an zwei Zeichenkettenobjekten auszuführen, deren beider Wert = „No” ist, muss die Laufzeit zuerst das erste Zeichen „N” abrufen und vergleichen und dann das zweite Zeichen „o” abrufen und vergleichen. Andernfalls, wenn nur ein einziger zwischengespeicherter Wert verwendet wird, muss die Laufzeit nur einen numerischen Vergleich „==” der Instanzen vornehmen. Auf der anderen Seite weist das Zwischenspeichern von Singletons einen ersten Aufwand auf. Tatsächlich muss die Zwischenspeicherungslogik jedes Mal, wenn ein neues Objekt einer Klasse konstruiert wird, die das Singleton-Muster implementiert, im Zwischenspeicher nachsehen, um festzustellen, ob ein Objekt mit identischen Merkmalen (z. B. für Zeichenkettenobjekte, eine Zeichenkette mit derselben Zeichenabfolge) bereits konstruiert und zwischengespeichert wurde. Dieser Anfangsaufwand entfällt, wenn ein Programm versucht, mehrere Instanzen desselben Objekts zu konstruieren. Wenn nur eine Instanz mit gewissen Merkmalen konstruiert wird, besteht keine Notwendigkeit für eine Zwischenspeicherung, und dieser Anfangsaufwand kann eingespart werden. Im Block 2A wird der Aufwand für jede Ausführung der Singleton-Muster-Technik erhalten. Im Block 2B wird ein akzeptabler Mindestschwellenwert für den Ersetzungsaufwand erhalten.
  • Block 2C betrifft das Identifizieren aller nicht veränderbaren Objekte und Hinzufügen jedes nicht veränderbaren Objekts zu dem unchangedObjects-Satz 210. Ein nicht veränderbares Objekt ist ein Objekt, das während nachfolgender Laufzeitausführung nicht geändert werden kann. Nicht veränderbare Objekte besitzen eine stärkere Eigenschaft als nicht geänderte Objekte. Nicht geänderte Objekte werden während der Ausführung eines gewissen Programms nicht verändert. Nicht veränderbare Objekte werden ebenfalls nicht verändert, doch hängt diese Eigenschaft nicht von einem bestimmten Programm ab; sie werden nicht verändert, weil sie nicht verändert werden können. Nachdem der Konstruktor die Ausführung beendet hat, bleibt der Zustand eines nicht veränderbaren Objekts während der gesamten Lebensdauer dieses Objekts derselbe. Im Wesentlichen ist ein nicht veränderbares Objekt auch nicht geändert, aber die Umkehrung trifft nicht notwendigerweise zu.
  • Wie oben erwähnt können nicht veränderbare Objekte nicht verändert werden. Stattdessen ist dies eine Eigenschaft, die durch die Klasse erzwungen wird, zu der diese Objekte gehören, und aus diesem Grund ist es möglich, nicht veränderbare Objekte zu ermitteln, ohne das gesamte Programm analysieren zu müssen. Eine Analyse zum Berechnen von nicht veränderbaren Objekten verläuft wie folgt (siehe 7). Für jede Klasse des Codes (z. B. Softwareprogramm) (Block 7A) prüft die Analyse, dass kein Feld, das von den Feldern irgendeines Objekts dieser Klasse aus erreichbar ist, durch direkten Zugriff (z. B. a.f = x verändert das Feld f durch einen direkten Zugriff) oder durch indirekten Zugriff (a.setF(x) ist eine indirekte Möglichkeit, das Feld f durch das Verfahren setF zu modifizieren) verändert wird, nachdem der Konstruktor dieser Klasse seine Ausführung beendet hat (Block 7B). Diese Analyse erfordert das Berücksichtigen aller möglichen Aktionen, die durch Aufrufen von irgendeinem der Verfahren dieser Klasse ausgeführt werden können (Block 7C). Wenn nicht alle möglichen Aktionen berücksichtigt worden sind (Block 7C = NEIN), wird das Verfahren 700 im Block 7B fortgesetzt; andernfalls (Block 7C = JA) wird das Verfahren 700 im Block 7D fortgesetzt. Wenn nicht alle Klassen untersucht worden sind (Block 7D = NEIN), wird das Verfahren 700 im Block 7A fortgesetzt; andernfalls (Block 7D = JA) endet das Verfahren 700 im Block 7E.
  • Unter erneuter Bezugnahme auf 2 werden im Block 2D alle Objekte identifiziert, die nie geändert werden, und jedes von diesen wird zum unchangedObjects-Satz 210 hinzugefügt. Derartige Objekte können wie folgt identifiziert werden (siehe 4). Zuerst werden der Aufrufgraph und Points-to-Graph eines einer Analyse unterzogenen Programms konstruiert (Block 4A des Verfahrens 400 von 4). Der Aufrufgraph 393 ist ein Graph, in dem jeder Knoten ein Verfahren darstellt und jede Kante einen Verfahrensaufruf darstellt. Ein Points-to-Graph 394 ist ein zweiteiliger Graph, in dem Knoten entweder Instanzen oder Zeiger darstellen. Eine Kante von einer Instanz zu einem Zeiger stellt die Tatsache dar, dass diese Instanz ein Feld aufweist, das durch diesen Zeiger dargestellt wird. Eine Kante von einem Zeiger zu einer Instanz stellt die Tatsache dar, dass dieser Zeiger während der Programmausführung auf diese Instanz zeigen kann. Um nicht geänderte Objekte eines bestimmten Typs zu erkennen, sucht die Analyse zuerst nach Konstruktorknoten dieses Typs (Block 4B). Konstruktorknoten sind diejenigen, die Aufrufe an Konstruktoren darstellen, wobei Objekte instanziiert werden.
  • Es gibt mehrere Objektabstraktionen, die implementiert werden können (Block 4C). Beispielhaft dafür ist eine Abstraktion von Objekten auf der Grundlage ihrer Zuordnungsadressen. Mit anderen Worten, zwei Objekte werden als gleichwertig betrachtet (und werden daher in derselben statischen Darstellung zusammengefasst). wenn sie dieselbe Zuordnungsadresse gemeinsam nutzen. Differenziertere Abstraktionen sind möglich, wodurch zum Beispiel zwei Objekte als gleichwertig betrachtet werden können, wenn sie nicht nur dieselbe Zuordnungsadresse sondern auch das Aufrufprogramm des Verfahrens gemeinsam nutzen, auf dem die Zuordnungsadresse liegt. Weniger differenzierte Abstraktionen sind ebenfalls möglich, wodurch zum Beispiel zwei Objekte als gleichwertig betrachtet werden, wenn sie denselben Typ haben.
  • Die Analyse enthält dann Berücksichtigen einer Objektabstraktion und Suchen nach all den Zeigern, die transitiv von dieser Abstraktion in dem Points-to-Graph erreicht wurden (Block 4D), wobei ermittelt wird, ob irgendein Aufruf-Graphknoten vorhanden ist, der den Wert modifiziert, auf den von diesem Zeiger gezeigt wird, nachdem die Konstruktion abgeschlossen ist (Block 4E). Wenn ein Aufruf-Graphknoten vorhanden ist (Block 4F = JA), wird das Objekt, das dem Aufruf-Graphknoten entspricht, zu einem Satz von nicht geänderten Objekten hinzugefügt (Block 4G) wie beispielsweise unchangedObjects. Falls nicht (Block 4F = NEIN), wird das Verfahren 400 im Block 4D fortgesetzt. Wenn nicht alle Objekte untersucht worden sind (Block 4H = NEIN), wird das Verfahren 400 ebenfalls im Block 4D fortgesetzt. Wenn alle Verfahren untersucht worden sind (Block 4H = JA), wird ermittelt, ob alle Abstraktionen untersucht worden sind (Block 4I). Falls nicht, wird das Verfahren im Block 4C fortgesetzt; falls ja, endet das Verfahren im Block 4I. An diesem Punkt (nach Block 2D) sollte der unchangedObjects-Satz 210 alle Objekte enthalten, die während einer nachfolgenden Laufzeitausführung des Systems 121 des Objektcodes 120 nicht geändert werden.
  • Um außerdem alle Objekte, die nie geändert werden, für einen bestimmten Kombinationstyp eines bestimmten Typs von nicht geänderten Objekten zu identifizieren, kann ermittelt werden, dass sich ein nicht geändertes Objekt aus der Kombination ergibt. Zum Beispiel ergibt eine Verkettung von zwei Zeichenketten, die beide nicht geänderte Objekte sind, ein nicht geändertes Objekt. Dieses Verfahren ist in 5 gezeigt. Es wird angemerkt, dass dieses Verfahren mit anderen Verfahren kombiniert werden könnte, wie beispielsweise dem in 4 gezeigten Verfahren.
  • Unter erneuter Bezugnahme auf 2 vermindern die Blöcke 2E bis 2I die Objekte in dem Satz nicht geänderter Objekte 210 um alle nicht geänderten Objekte auf einen Satz 125 von nicht geänderten Zielobjekten. Die nicht geänderten Zielobjekte des Satzes 125 sind diejenigen nicht geänderten Objekte, bei denen eine Maßzahl für eine Singleton-Muster-Technik einen gewissen Schwellenwert einhält. Dies verhindert, dass die Single-Muster-Technik einen Aufwand verursacht, der größer als die Einsparung einer vorbestimmten Menge (z. B. durch einen Schwellenwert ermittelt) auf dem System 121 des Objektcodes 120 ist.
  • Für jedes Objekt in unchangedObjects (Block 2E) werden die Einsparungen ermittelt, die sich durch die Singleton-Muster-Technik für ein ausgewähltes Objekt ergeben (Block 2F). Der Block 2F kann durch Ermitteln, wie oft das Objekt verwendet wird, ausgeführt werden. Als weiteres Beispiel kann der Block 2F ausgeführt werden, indem ermittelt wird, wie oft die equals-Methode oder die hashCode()-Methode oder beide auf dieses Objekt angewendet wurden, wobei die equals-Methode durch den „==”-Operator ersetzt werden könnte. Wenn der Aufwand, der im Block 2A ermittelt und von den im Block 2F ermittelten Einsparungen subtrahiert wird, größer ist als der im Block 2B ermittelte Schwellenwert (Block 2G = JA), wird das Verfahren 200 im Block 2I fortgesetzt. Andernfalls (Block 2G = NEIN) wird das Verfahren 200 im Block 2H fortgesetzt, wobei das nicht geänderte Objekt aus dem unchangedObjects-Satz 210 gelöscht wird. Das Verfahren 200 wird im Block 2I fortgesetzt.
  • Im Block 2I wird ermittelt, ob keine weiteren Objekte im unchangedObjects-Satz 210 mehr vorhanden sind. Wenn weitere Objekte in dem unchangedObjects-Satz 210 vorhanden sind (Block 2I = NEIN), wird das Verfahren 200 im Block 2E fortgesetzt, wo ein weiteres nicht geändertes Objekt ausgewählt wird. Falls dem so ist (Block 2I = JA), endet das Verfahren 200 im Block 2J.
  • Unter Bezugnahme auf 3 wird ein Blockschaubild eines Systems 300 für die Verwaltung von nicht geänderten Objekten gemäß einer beispielhaften Ausführungsform gezeigt. Das System 300 enthält das Computersystem 305, das einen oder mehrere Speicher 310, einen oder mehrere Prozessoren 320 und eine oder mehrere Netzwerkschnittstellen (I/Fs) 330 aufweist. Der eine bzw. die mehreren Speicher 310, der eine bzw. die mehreren Prozessoren 320 und die eine bzw. mehreren Netzwerkschnittstellen (I/Fs) 330 sind über einen oder mehrere Busse 307 miteinander verbunden. Es wird angemerkt, dass der eine bzw. die mehreren Busse 307 auch Datenübertragungsverbindung(en) sein können wie beispielsweise eine Infiniband-Datenübertragungsverbindung. Die eine bzw. mehreren Netzwerkschnittstellen 330 können drahtgebundene oder drahtlose Netzwerkschnittstellen sein.
  • Der eine bzw. die mehreren Speicher 310 enthalten Code 350, nicht geänderte Objekte 355, modifizierten Code 365, einen Points-to-Graph 393 und einen Aufruf-Graph 394. Der Code 350 könnte den Quellcode 115, den Objektcode 120 oder jeden anderen Code enthalten. Die nicht geänderten Objekte 355 können die nicht geänderten Objekte in dem unchangedObjects-Satz 210 enthalten. Das heißt, die nicht geänderten Objekte 355 können alle nicht geänderten Objekte (z. B. die nicht geänderten Objekte, die nach Block 2D von 2 erkannt wurden) und einen typisch verminderten Satz von nicht geänderten Objekten enthalten, nachdem die Blöcke 2E bis 2I ausgeführt worden sind. In einer beispielhaften Ausführungsform sind die nicht geänderten Objekte 355 der unchangedObjects-Satz 210. Der modifizierte Code 365 ist der modifizierte Code, der entsteht, nachdem die Verfahren 100 und 200 an dem Code 350 ausgeführt worden sind.
  • Die Anweisungen 370 sind computerlesbarer Programmcode, der, wenn er von dem einen bzw. den mehreren Prozessoren 320 ausgeführt wird, das Computersystem 305 veranlasst, eine oder mehrere der hierin beschriebenen Aktionen auszuführen. Die Anweisungen 370 enthalten eine statische Analyse-Engine, die eine Nicht-geändertes-Objekt-Kennung 380 und einen Code-Modifikator 385 enthält. Die Anweisungen 370 enthalten des Weiteren einen Compiler 390 und eine Laufzeitumgebung 395.
  • Die statische Analyse-Engine 375 erstellt den Points-to-Graph 393 und den Aufruf-Graph 394. Die Nicht-geändertes-Objekt-Kennung 380 führt z. B. den Block 1F und das Verfahren 200 von 2 aus (einschließlich 4 und 5) und identifiziert nicht geänderte Objekte 355 unter Verwendung einer statischen Analyse. Es wird angemerkt, dass die Analyse des Verfahrens 200 nur nicht geänderte Objekte unter Verwendung der Blöcke 2C und 2D ermitteln muss, und die anderen Blöcke 2A, 2B, 2E bis 2I würden nicht ausgeführt. In dieser beispielhaften Ausführungsform würden die nicht geänderten Zielobjekte nicht ermittelt, und die nicht geänderten Objekte 355 würden alle erkannten nicht geänderten Objekte enthalten.
  • Der Code-Modifikator 385 führt Code-Modifizierung aus, wie oben unter Bezugnahme auf die Blöcke 1G, 1H, 1P und 1J beschrieben. Es wird angemerkt, dass diese Struktur rein beispielhaft ist. Die Nicht-geändertes-Objekt-Kennung 380 und der Code-Modifikator 385 können zum Beispiel zu einem einzigen Programm geformt oder weiter unterteilt werden.
  • Der Compiler 390 wird zum Kompilieren des Quellcodes 115 in den Objektcode 120 verwendet. Der Compiler 390 führt den Block 1E von 1 aus. Die Laufzeitumgebung 395 wird verwendet, um das modifizierte System 130 des modifizierten Objektcodes 140 auszuführen (z. B. Block 1N von 1).
  • In einem Beispiel wird der Code 350 über die eine oder mehrere Netzwerkschnittstellen 330 als Client-Code 335 empfangen, der Client-Quellcode 115-1, Client-Objektcode 120-2 oder beides sein kann. Nach der in 1 beschriebenen Analyse und Ermittlung des modifizierten Codes 365 wird der modifizierte Code 365 über die eine oder mehrere Netzwerkschnittstellen als der modifizierte Client-Code 340 zu dem Client übertragen.
  • Es wurden einige Beispiele beschrieben, um Code so zu modifizieren, dass alle Verwendungen der Mitglieder des Satzes von nicht geänderten Zielobjekten die Singleton-Muster-Technik anwenden, jetzt wird eine andere Technik insbesondere in Beziehung auf 6 beschrieben. Viele Elemente von 6 wurden oben kurz beschrieben. In einer beispielhaften Ausführungsform beginnt das Verfahren 600, wenn jede Klasse einem Cachespeicher 610 (Block 6A) zugeordnet wird. Jedes Mal, wenn der Konstruktor einer Klasse aufgerufen wird, wird in dem entsprechenden Cachespeicher 610 nachgesehen (Block 6B). Wenn ein Objekt mit den Merkmalen, die in den Konstruktoraufrufen angegeben sind, bereits in dem Cachespeicher (Block 6C = JA) vorhanden ist, wird das Objekt nicht erstellt (Block 6G). Stattdessen wird das Objekt aus dem Cachespeicher zurückgegeben (Block 6H).
  • Wenn ein Objekt mit den Merkmalen, die in den Konstruktoraufrufen angegeben sind, in dem Cachespeicher noch nicht bereits vorhanden ist (Block 6C = NEIN), wird das Objekt erstellt (Block 6D), zu dem Cachespeicher hinzugefügt (Block 6E) und zurückgegeben (Block 6F). Im Block 6I wird ermittelt, ob der gesamte Code untersucht worden ist. Falls nicht (Block 6I = NEIN), wird das Verfahren 600 im Block 6B fortgesetzt. Falls dem so ist (Block 6I = JA), endet das Verfahren 600 im Block 6J.
  • Wie von einem Fachmann anerkannt werden wird, können Aspekte der vorliegenden Erfindung als ein System, Verfahren oder Computerprogrammprodukt ausgeführt werden. Dementsprechend können Aspekte der vorliegenden Erfindung in Gestalt einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (darunter Firmware, residente Software, Mikrocode usw.) oder einer Ausführungsform vorliegen, die Software- und Hardware-Aspekte kombiniert, auf die alle hierin als „Schaltung”, „Modul” oder „System” Bezug genommen werden kann. Des Weiteren können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit einem darin ausgeführten computerlesbaren Programmcode ausgeführt ist.
  • Jede Kombination von einem oder mehreren computerlesbaren Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann zum Beispiel ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine derartige Vorrichtung oder Einheit oder jede geeignete Kombination aus dem Vorgenannten sein, ist aber nicht darauf beschränkt. Zu spezielleren Beispielen (eine nicht erschöpfende Liste) für das computerlesbare Speichermedium würden folgende zählen: eine elektrische Verbindung mit einer oder mehreren Drahtleitungen, eine tragbare Computerdiskette, eine Festplatte, ein Arbeitsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer CD-ROM, eine optische Speichereinheit, eine Magnetspeichereinheit oder jede geeignete Kombination des Vorgenannten. In dem Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes konkrete Medium sein, das ein Programm enthalten oder speichern kann, das von oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Anweisungsausführung verwendet werden kann.
  • Ein computerlesbares Signalmedium kann ein verbreitetes Datensignal mit einem darin ausgeführten computerlesbaren Programmcode enthalten, zum Beispiel in Basisband oder als Teil einer Trägerwelle. Ein derartiges verbreitetes Signal kann jede einer Vielfalt von Formen annehmen, darunter elektromagnetisch, optisch oder jede geeignete Kombination davon, ist aber nicht darauf beschränkt. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist, und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Anweisungsausführung übertragen, verbreiten oder transportieren kann.
  • In einem computerlesbaren Medium integrierter Programmcode kann unter Verwendung jedes geeigneten Mediums übertragen werden, darunter drahtlos, drahtgebunden, über ein Lichtwellenleiterkabel, HF usw. oder eine geeignete Kombination des Vorgenannten, ist aber nicht darauf beschränkt.
  • Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in jeder Kombination von einer oder mehreren Programmiersprachen geschrieben werden, einschließlich einer objektorientierten Programmiersprache wie Java, Smalltalk, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen wie der Programmiersprache „C” oder ähnlichen Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In dem letzteren Szenario kann der ferne Computer mit dem Computer des Benutzers über jeden Typ von Netzwerk verbunden werden, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann zu einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Nutzung eines Internet-Dienstanbieters).
  • Aspekte der vorliegenden Erfindung werden im Folgenden unter Bezugnahme auf Veranschaulichungen des Ablaufplans und oder der Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block in den Veranschaulichungen von Ablaufplan und/oder den Blockschaubildern und Kombinationen von Blöcken in den Veranschaulichungen von Ablaufplan und/oder den Blockschaubildern durch Computerprogrammanweisungen implementiert werden können. Diese Computerprogrammanweisungen können für einen Prozessor eines Mehrzweckcomputers, eines Spezialcomputers oder andere Vorrichtungen, die programmierbare Daten verarbeiten, bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die über den Prozessor des Computers oder andere Vorrichtungen, die programmierbare Daten verarbeiten, ausgeführt werden, Mittel zum Implementieren der Funktionen/Handlungen erstellen, die in dem Block oder den Blöcken von Ablaufplan und/oder Blockschaubild angegeben sind.
  • Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, eine andere Vorrichtung, die programmierbare Daten verarbeitet, oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Weise funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Fertigungsartikel erzeugen, einschließlich Anweisungen, die die in dem Block oder den Blöcken von Ablaufplan und/oder Blockschaubild angegebene Funktion/Handlung implementieren.
  • Die Computerprogrammanweisungen können auch auf einen Computer, eine andere Vorrichtung, die programmierbare Daten verarbeitet, oder andere Einheiten geladen werden, um die Ausführung einer Serie von Vorgangsschritten auf dem Computer, einer anderen Vorrichtung, die programmierbare Daten ausführt, oder anderen Einheiten zu veranlassen, um einen computerimplementierten Prozess zu erzeugen, so dass die Anweisungen, die auf dem Computer oder einer anderen programmierbaren Vorrichtung ausgeführt werden, Prozesse zum Implementieren der Funktionen/Handlungen bereitstellen, die in dem Block oder den Blöcken des Ablaufplans und/oder des Blockschaubilds angegeben sind.
  • Die hierin verwendete Terminologie dient nur zum Zweck der Beschreibung von bestimmten Ausführungsformen und soll die Erfindung nicht einschränken. Die hierin verwendeten Singularformen „ein”, „eine” und „der/die/das” sollen auch die Pluralformen mit einschließen, es sei denn, der Kontext gibt eindeutig anderes vor. Es versteht sich des Weiteren, dass die Begriffe „aufweisen” und/oder „aufweisend” bei Verwendung in dieser Patentschrift das Vorhandensein ausgewiesener Merkmale, Ganzzahlen, Schritte, Operationen, Elemente und/oder Komponenten angeben, das Vorhandensein oder die Hinzufügung von einem oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon aber nicht ausschließen.
  • Die entsprechenden Strukturen, Materialien, Handlungen und Entsprechungen aller Mittel oder Schritt-plus-Funktion-Elemente in den nachstehenden Ansprüchen sollen alle Strukturen, Materialien oder Handlungen zum Ausführen der Funktion in Kombination mit anderen beanspruchten Elementen enthalten, wie speziell beansprucht. Die Beschreibung der vorliegenden Erfindung wurde zum Zweck der Veranschaulichung und Beschreibung erstellt, sie soll aber keineswegs erschöpfend oder auf die Erfindung in der offenbarten Form eingeschränkt sein. Für Fachleute sind viele Modifizierungen und Variationen offenkundig, ohne vom Schutzbereich und dem Erfindungsgedanken der Erfindung abzuweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundsätze der Erfindung und die praktische Anwendung am besten zu erklären und es anderen Fachleuten zu ermöglichen, die Erfindung für verschiedene Ausführungsformen mit verschiedenen Modifizierungen zu verstehen, die für die vorgesehene bestimmte Verwendung geeignet sind.

Claims (25)

  1. Verfahren, aufweisend: Verwenden einer statischen Analyse, die an Code ausgeführt wird, Analysieren des Codes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Codes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden; und Ausgeben des modifizierten Codes.
  2. Verfahren nach Anspruch 1, des Weiteren aufweisend Ausführen des modifizierten Codes.
  3. Verfahren nach Anspruch 1, wobei der Code Bibliotheks-Objektcode aufweist, das Analysieren des Weiteren ein Analysieren des Bibliotheks-Objektcodes aufweist, um einen Satz von nicht geänderten Objekten zu ermitteln, das Modifizieren des Weiteren ein Modifizieren des Bibliotheks-Objektcodes aufweist, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden, und das Ausgeben des Weiteren ein Ausgeben des modifizierten Bibliotheks-Objektcodes aufweist.
  4. Verfahren nach Anspruch 1, wobei der Code Quellcode aufweist und das Verfahren des Weiteren vor dem Analysieren Kompilieren des Quellcodes in Objektcode aufweist, und das Analysieren des Codes des Weiteren ein Analysieren des Objektcodes, um einen Satz von nicht geänderten Objekten zu ermitteln, und ein Modifizieren des Objektcodes aufweist, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden.
  5. Verfahren nach Anspruch 1, wobei das Modifizieren des Weiteren aufweist: Ermitteln aller Instanzen, in denen ein Singleton-relevanter Operator auf ein Singleton angewendet wird, und Ersetzen des Singleton-relevanten Operators in jeder Instanz durch seine Singleton-relevante Operatorentsprechung.
  6. Verfahren nach Anspruch 5, wobei „equals” (ist gleich) ein Singletonrelevanter Operator ist, wobei „==” die Singleton-relevante Operatorentsprechung ist.
  7. Verfahren nach Anspruch 1, wobei das Analysieren des Weiteren für jedes nicht geänderte Objekt in dem Satz von nicht geänderten Objekten aufweist: Berechnen, ob Einsparungen, die sich aus Verwenden der Singleton-Muster-Technik für die nicht geänderten Objekte ergeben, einen Aufwand des Anwendens der Singleton-Muster-Technik um einen Schwellenwert überschreiten, und in Reaktion auf das Berechnen, dass die Einsparungen, die sich aus dem Verwenden der Singleton-Muster-Technik für das nicht geänderten Objekt ergeben, den Aufwand des Anwendens der Singleton-Muster-Technik nicht um einen Schwellenwert überschreiten, Entfernen des nicht geänderten Objekts aus dem Satz von nicht geänderten Objekten.
  8. Verfahren nach Anspruch 7, des Weiteren aufweisend Berechnen der Einsparungen durch Ermitteln, wie oft das Objekt verwendet wird.
  9. Verfahren nach Anspruch 7, des Weiteren aufweisend Berechnen der Einsparungen durch Ermitteln, wie oft die „equals”- und „hashCode”-Methoden auf dem Objekt verwendet werden.
  10. Verfahren nach Anspruch 1, wobei das Analysieren des Weiteren für einen bestimmten Kombinationstyp eines bestimmten Typs von nicht geänderten Objekten ein Ermitteln aufweist, dass sich ein nicht geändertes Objekt aus der Kombination ergibt.
  11. Verfahren nach Anspruch 11, wobei es sich bei dem bestimmten Kombinationstyp um eine Verkettung und bei dem bestimmte Typ von nicht geänderten Objekten um Zeichenketten handelt, wobei eine Verkettung von zwei Zeichenketten, die beide nicht geänderte Objekte sind, ein nicht geändertes Objekt ergibt.
  12. Computerprogrammprodukt, aufweisend: ein computerlesbares Speichermedium mit einem darin enthaltenen computerlesbaren Programmcode, wobei der computerlesbare Programmcode aufweist: computerlesbaren Programmcode zum Verwenden einer statischen Analyse, die an Code ausgeführt wird, Analysieren des Codes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Codes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden; und computerlesbaren Programmcode zum Ausgeben des modifizierten Codes.
  13. Computerprogrammprodukt nach Anspruch 12, des Weiteren aufweisend computerlesbaren Programmcode zum Ausführen des modifizierten Codes.
  14. Computerprogrammprodukt nach Anspruch 12, wobei der Code Bibliotheks-Objektcode aufweist, das Analysieren des Weiteren ein Analysieren des Bibliotheks-Objektcodes aufweist, um einen Satz von nicht geänderten Objekten zu ermitteln, das Modifizieren des Weiteren ein Modifizieren des Bibliotheks-Objektcodes aufweist, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden, und das Ausgeben des Weiteren ein Ausgeben des modifizierten Bibliotheks-Objektcodes aufweist.
  15. Computerprogrammprodukt nach Anspruch 12, wobei der Code Quellcode aufweist und der computerlesbare Programmcode des Weiteren vor dem Analysieren Kompilieren des Quellcodes in Objektcode aufweist, und das Analysieren des Codes des Weiteren ein Analysieren des Objektcodes, um einen Satz von nicht geänderten Objekten zu ermitteln, und ein Modifizieren des Objektcodes aufweist, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden.
  16. Computerprogrammprodukt nach Anspruch 12, wobei das Modifizieren des Weiteren aufweist: Ermitteln aller Instanzen, in denen ein Singleton-relevanter Operator auf ein Singleton angewendet wird, und Ersetzen des Singleton-relevanten Operators in jeder Instanz durch seine Singleton-relevante Operatorentsprechung.
  17. Computerprogrammprodukt nach Anspruch 12, wobei das Analysieren des Weiteren für jedes nicht geänderte Objekt in dem Satz von nicht geänderten Objekten aufweist: Berechnen, ob Einsparungen, die sich aus Verwenden der Singleton-Muster-Technik für das nicht geänderte Objekt ergeben, einen Aufwand des Anwendens der Singleton-Muster-Technik um einen Schwellenwert überschreiten, und in Reaktion auf das Berechnen, dass die Einsparungen, die sich aus dem Verwenden der Singleton-Muster-Technik für die nicht geänderten Objekte ergeben, den Aufwand des Anwendens der Singleton-Muster-Technik nicht um einen Schwellenwert überschreiten, Entfernen des nicht geänderten Objekts aus dem Satz von nicht geänderten Objekten.
  18. Computerprogrammprodukt nach Anspruch 12, wobei das Analysieren des Weiteren für einen bestimmten Kombinationstyp eines bestimmten Ergebnistyps von nicht geänderten Objekten ein Ermitteln aufweist, dass sich ein nicht geändertes Objekt aus der Kombination ergibt.
  19. Vorrichtung, aufweisend: mindestens einen Speicher, der Computercode aufweist; und mindestens einen Prozessor, wobei der Computercode den mindestens einen Prozessor steuert, um mindestens das Folgende auszuführen: Verwenden einer statischen Analyse, die an Code ausgeführt wird, Analysieren des Codes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Codes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden; und Ausgeben des modifizierten Codes.
  20. Vorrichtung nach Anspruch 19, wobei Modifizieren des Weiteren aufweist: Ermitteln aller Instanzen, in denen ein Singleton-relevanter Operator auf ein Singleton angewendet wird, und Ersetzen des Singleton-relevanten Operators in jeder Instanz durch seine Singleton-relevante Operatorentsprechung.
  21. Vorrichtung nach Anspruch 19, wobei das Analysieren des Weiteren für jedes nicht geänderte Objekt in dem Satz von nicht geänderten Objekten aufweist: Berechnen, ob Einsparungen, die sich aus Verwenden der Singleton-Muster-Technik für die nicht geänderten Objekte ergeben, einen Aufwand des Anwendens der Singleton-Muster-Technik um einen Schwellenwert überschreiten, und in Reaktion auf das Berechnen, dass die Einsparungen, die sich aus dem Verwenden der Singleton-Muster-Technik für das nicht geänderten Objekt ergeben, den Aufwand des Anwendens der Singleton-Muster-Technik nicht um einen Schwellenwert überschreiten, Entfernen des nicht geänderten Objekts aus dem Satz von nicht geänderten Objekten.
  22. Vorrichtung nach Anspruch 19, wobei das Analysieren des Weiteren für einen bestimmten Kombinationstyp eines bestimmten Ergebnistyps von nicht geänderten Objekten ein Ermitteln aufweist, dass sich ein nicht geändertes Objekt aus der Kombination ergibt.
  23. Verfahren, aufweisend: Zugreifen auf Code von einem Client aus; in Reaktion darauf, dass der gesamte Code Quellcode ist, Kompilieren des Quellcodes in Objektcode, bis der gesamte Code von dem Client Objektcode aufweist; Verwenden einer statischen Analyse, die an dem Objektcode ausgeführt wird, Analysieren des Objektcodes zum Ermitteln eines Satzes von nicht geänderten Objekten und Modifizieren des Objektcodes, um eine Singleton-Muster-Technik für ein oder mehrere Mitglieder des Satzes von nicht geänderten Objekten anzuwenden; und Zurückgeben des modifizierten Objektcodes an den Client.
  24. Verfahren nach Anspruch 23, wobei das Verfahren in einer Client-Einrichtung ausgeführt wird.
  25. Verfahren nach Anspruch 23, wobei der Code von dem Client über eine oder mehrere Netzwerkschnittstellen empfangen wird, und wobei der modifizierte Objektcode an den Client über die eine oder mehrere Netzwerkschnittstellen zurückgegeben wird.
DE112011103406T 2010-10-08 2011-10-11 Verwaltung von nicht geänderten Objekten Withdrawn DE112011103406T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
USUS-12/900,643 2010-10-08
US12/900,643 US20120089962A1 (en) 2010-10-08 2010-10-08 Unchanged Object Management
PCT/US2011/055718 WO2012048336A2 (en) 2010-10-08 2011-10-11 Unchanged object mamagement

Publications (1)

Publication Number Publication Date
DE112011103406T5 true DE112011103406T5 (de) 2013-08-22

Family

ID=45926120

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112011103406T Withdrawn DE112011103406T5 (de) 2010-10-08 2011-10-11 Verwaltung von nicht geänderten Objekten

Country Status (5)

Country Link
US (2) US20120089962A1 (de)
CN (1) CN103443761A (de)
DE (1) DE112011103406T5 (de)
TW (1) TW201235943A (de)
WO (1) WO2012048336A2 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8839215B2 (en) * 2010-07-19 2014-09-16 International Business Machines Corporation String cache file for optimizing memory usage in a java virtual machine
US9507613B2 (en) * 2012-03-30 2016-11-29 Oracle International Corporation Methods and apparatus for dynamically preloading classes
EP2687981B1 (de) * 2012-07-18 2017-12-27 MStar Semiconductor, Inc. Automatisierte Compilerspezialisierung für globale Optimierung
US8826254B2 (en) * 2012-11-08 2014-09-02 Concurix Corporation Memoizing with read only side effects
US9262416B2 (en) 2012-11-08 2016-02-16 Microsoft Technology Licensing, Llc Purity analysis using white list/black list analysis
US9436462B2 (en) * 2014-02-14 2016-09-06 Red Hat, Inc. Identifying singleton classes
US9448818B2 (en) * 2014-02-14 2016-09-20 Red Hat, Inc. Defining classes as singleton classes or non-singleton classes
US10191753B2 (en) 2016-03-30 2019-01-29 Oracle International Corporation Generating verification metadata and verifying a runtime type based on verification metadata
US10394528B2 (en) 2016-03-30 2019-08-27 Oracle International Corporation Returning a runtime type loaded from an archive in a module system
US10768913B2 (en) * 2018-08-23 2020-09-08 Oracle International Corporation Method for performing deep static analysis with or without source code

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7051188B1 (en) * 1999-09-28 2006-05-23 International Business Machines Corporation Dynamically redistributing shareable resources of a computing environment to manage the workload of that environment
US6925638B1 (en) * 2000-09-21 2005-08-02 International Business Machines Corporation Mutability analysis in Java
US6606377B2 (en) * 2001-06-25 2003-08-12 Bellsouth Intellectual Property Corporation Method and system for analyzing and preparing an optimum telephone services call plan
US6951012B2 (en) * 2001-10-02 2005-09-27 Hewlett-Packard Development Company, L.P. API to increase debug log performance
FR2864655B1 (fr) * 2003-12-31 2006-03-24 Trusted Logic Procede de controle d'integrite de programmes par verification d'empreintes de traces d'execution
US7945904B2 (en) * 2005-08-22 2011-05-17 Microsoft Corporation Embedding expression in XML literals
EP1870829B1 (de) * 2006-06-23 2014-12-03 Microsoft Corporation Softwareschutz durch Erzwingen der Datenflussintegrität
US8191054B2 (en) * 2006-10-20 2012-05-29 Analog Devices, Inc. Process for handling shared references to private data
CN101211273B (zh) * 2006-12-25 2010-05-19 上海科泰世纪科技有限公司 在构件编程中自动生成Singleton模式的方法
US7778893B2 (en) * 2008-05-21 2010-08-17 At&T Intellectual Property Ii, L.P. Access network optimization methodology for leased switched and dedicated facilities
JP2009282690A (ja) * 2008-05-21 2009-12-03 Toshiba Corp 情報検索方法および情報処理装置
US8250589B2 (en) * 2009-04-03 2012-08-21 Lsi Corporation Method for simplifying interfaces having dynamic libraries
US8359435B2 (en) * 2009-12-16 2013-01-22 International Business Machines Corporation Optimization of software instruction cache by line re-ordering
CN101814053B (zh) * 2010-03-29 2013-03-13 中国人民解放军信息工程大学 一种基于功能模型的二进制代码漏洞发现方法

Also Published As

Publication number Publication date
US20120089962A1 (en) 2012-04-12
WO2012048336A2 (en) 2012-04-12
US20120331445A1 (en) 2012-12-27
TW201235943A (en) 2012-09-01
WO2012048336A3 (en) 2014-10-16
CN103443761A (zh) 2013-12-11

Similar Documents

Publication Publication Date Title
DE112011103406T5 (de) Verwaltung von nicht geänderten Objekten
DE112013001711T5 (de) Optimieren von Unterroutine-Aufrufen auf der Grundlage der Architekturebene einer aufgerufenen Unterroutine
DE202014010938U1 (de) Omega-Namen: Namenserzeugung und -ableitung
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE112010003144T5 (de) Erweiterbare Grundstruktur zur Unterstützung verschiedener Einsatzarchitekturen
DE202014010893U1 (de) Rufwegsucher
DE102013200029A1 (de) Bereitstellen leistungsangepasster versionen kompilierten codes für eine cpu in einem system heterogener kerne
DE202011110124U1 (de) Hybridabfrageausführungsplan
DE112013005993T5 (de) Verfahren, Vorrichtung und computerlesbares Medium für eine optimale Bestimmung von Daten-Teilmengen
DE112013001735T5 (de) Optimieren des Verbindens von Anweisungen
DE102016110195A1 (de) Erzeugen von Code in statisch typisierten Programmiersprachen für eine dynamisch typisierte array-basierte Sprache
DE102021130906A1 (de) Optimieren von zugriffen auf begrenzungsinformationen beim pufferschutz
DE102022129946A1 (de) Verfahren und vorrichtungen zum bestimmen eines verfeinerten kontexts für softwarefehlererkennung und - korrektur
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE102021116315A1 (de) Verfahren zum Zusammenführen von Architekturinformationen
DE102021123578A1 (de) Messen der datenqualität von daten in einer graphendatenbank
EP2965199A1 (de) Verfahren zur überprüfung und/oder transformation eines computerprogramms mit statischen funktionen erster klasse
DE112020000657T5 (de) Dienstverwaltung in einem dbms
DE202015009280U1 (de) Integrierte domänenspezifische Sprachen als erstklassige Codeartefakte
DE102019008598A1 (de) Identifikation und Visualisierung von Assoziationen zwischen Code, der von einem Modell generiert ist, und Quellen, welche die Codegeneration beeinflussen
DE112011103505T5 (de) Verfahren zum Validieren von Laufzeitreferenzen
DE112020003634T5 (de) Automatische verifizierung der optimierung von konstrukten auf hoher ebene unter verwendung von prüfvektoren
EP0973091B1 (de) Verfahren zum Erzeugen eines regel- und anpassbaren Netzwerkes von Modellen von Verhaltensmustern
EP1343078B1 (de) System zur Modellierung und Generierung von Softwaregenerierungssystemen
WO2010026151A1 (de) Verfahren zur einräumung einer zugriffsberechtigung auf ein rechnerbasiertes objekt in einem automatisierungssystem, computerprogramm und automatisierungssystem

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee