Re: Unterschied Compiler / Interpreter mit und ohne JIT usw.

"Ernst Baumann" skribis:

> >> Der Compiler kann schon _vor_ der Laufzeit, also während des
> >> Compilierens feststellen, dass die Methode printAllAttributs() in der
> >> Oberklasse und in mindestens einer Unterklassen vorkommt. D.h. Der
> >> Compiler weiss also, wenn ein als Oberklasse deklariertes Objekt wie
> >> z.B. f auf die Methode printAllAttributs() zugreift, dass dann diese
> >> Methode virtuell sein muss.
> >> Dies kann er aber schon _vor_ der Laufzeit, also während des
> >> Compilierens feststellen (und dann virtuelle Tabellen erstellen, usw.)
> >
> >Wenn aber etwa deine random()-Funktion kaputt ist und etwa immer
> >zufall == 2 ist, und in der Quadrat-Klasse die Methode nicht
> >überschrieben war, hätte man es sich sparen können.
>
> wenn die Quadrat-Klasse die Methode printAllAttributs() nicht
> überschreibt, dannn merkt dies auch der klasssische Compiler _vor_ der
> Laufzeit (und kann sie nicht virtuell machen), oder mache ich da einen
> Denkfehler ?

Du hast ja nicht nur die Quadrat-Klasse, sondern auch noch
die anderen Subklassen von GeoForm, in denen vielleicht die
Methode überschrieben wurde.

Ich meinte jetzt den Fall, dass man (wie bei deinem Quelltext)
ohne Analyse der random()-Funktion nicht vorher herausbekommt,
von welcher Klasse denn nun wirklich das Exemplar erstellt
wurde.

> >Außerdem gibt es ja in Java noch die Möglichkeit, dass Klassen
> >zur Laufzeit dazukommen - man kennt also zur Compile-Zeit nicht
> >alle Unterklassen einer Klasse.
>
> Und wenn so eine Klasse dann eine Methode verwendet, die die Methode
> der Oberklasse überschreibt, dann kann das _nur_ während (und nicht
> vor) der Laufzeit festgestellt werden, oder ?

Genau. Ein statischer Compiler müsste also vorsorglich _alle_
Methoden, die nicht final (oder private) sind (oder in einer
final-Klasse stecken), virtuell machen.

Den Aufwand kann sich ein JIT-Compiler sparen, indem er
erstmal gescheit rät (etwa anhand der Klassen, die schon
da sind), welche Methoden denn virtuell sein müssen, und
die anderen nicht-virtuell macht. Stellt sich dann heraus,
dass das falsch war, macht er es eben (für die Methoden,
die in den zusätzlichen Klassen dazukommen) rückgängig.

> Bemerkung:
> Dass Klassen während der Laufzeit dazukommen können, ist _nur_ durch
> das importieren von Packages möglich (mit import ...).

Nein. Du kannst in einer Klasse andere Klassen verwenden,
ohne dass sie dort irgendwo im Quelltext auftauchen, oder
auch nur importiert werden.

---
public class A
{
public B getB()
{
return new B();
}
}

public class B
{
public String hallo() { return "Welt"; }
}


public class Test
{
public static void main(String[] egal)
{
System.out.println(new A().getB().hallo());
}
}
---

Hier gibt es keine Subklassen von B, also könnte
man "eigentlich" die hallo()-Methode von B nicht-virtuell
machen.

Nun kommt aber jemand auf die Idee, heimlich die A-Klasse
auszutauschen, etwa so:
---
public class C extends B
{
public String hallo() { return "Leute"; }
}

public class A
{
public B getB()
{
return new C();
}
}
---

Ups, jetzt gibt es auf einmal eine B-Subklasse (C),
welche auch noch die hallo()-Methode überschreibt.

Und dann geht das ganze auch noch ohne Austauschen
der A-Klasse, sondern indem da etwa mit Class.forName()
eine Klasse geladen wird. (Deren Bytecode kann man
auch noch zur Laufzeit erzeugen ...)

> Wenn also der Java-Interpreter auf eine Methode oder Klasse trifft,
> die sich nicht in seinem aktuellen Quellcode befindet, dann durchsucht
> er die mit import angegebenen pakages, oder ?

Nein. Die Importe sind nur für den Compiler gut, zur Laufzeit
sind die nicht mehr da.
Das ist nur dazu gut, dass du nicht immer jeden Klassennamen
ausführlich (inklusive Packagenamen) hinschreiben musst - im
Bytecode ist das dann schon mit Packagenamen aufgeführt.

> >Man könnte nun sagen "wir lassen alle Methoden, die nicht
> >final sind, virtuell", aber der Trick ist eben, dass nur
> >die wenigsten solchen Methoden dies wirklich benötigen,
> >und damit kann man eine Menge Zeit sparen.
>
> virtuell braucht mehr Zeit als nicht virtuell. Siehe mein Posting an
> Theo.

Genau das meinte ich ja - der naive Ansatz ist
viel zu teuer.


Paul
--
Wem es darum zu tun ist, dauerhafte Achtung sich zu erwerben; [...] der würze
nicht ohne Unterlass seine Gespräche mit Lästerungen, Spott und Medisance und
gewöhne sich nicht an den auszischenden Ton von Persiflage.
Adolf Freiherr Knigge, Über den Umgang mit Menschen, 1.17
.

Relevant Pages

  • Re: Unterschied Compiler / Interpreter mit und ohne JIT usw.
    ... >> Compiler weiss also, wenn ein als Oberklasse deklariertes Objekt wie ... >> z.B. f auf die Methode printAllAttributs() zugreift, ... Laufzeit, ... Und wenn so eine Klasse dann eine Methode verwendet, ...
    (de.comp.lang.java)
  • Re: Weg-Optimierung leerer Methoden
    ... Der Compiler optimiert gar nichts. ... Die JVM wird zur Laufzeit allerdings möglicherweise die Methode inlinen -- ... doch noch eine Klasse hinzu, die in dieser Methode mehr macht, wird die JVM ...
    (de.comp.lang.java)
  • Re: Unterschied Compiler / Interpreter mit und ohne JIT usw.
    ... Eine ausgetauschte Klasse A kann er nur ... >> Der Compiler besitzt also beim Kompilieren volle Information und kennt ... Die neu kompilierte Bibliothek enthält A und damit funktioniert auch ... das gesamte Programm. ...
    (de.comp.lang.java)
  • Re: [LangSpec] Bindung privater und finale Methoden
    ... diese dynamisch zu binden. ... Solange eine Methode private ist, kann sie auch nur *aus derselben Klasse*, ... Compiler also klar sagen, da passiert nichts Unerwartetes mehr (hmmm ... ... Aus diesem Gesichtspunkt würde ich mal so behaupten: Es ist in der LangSpec ...
    (de.comp.lang.java)
  • Re: C++ Grundsatzfrage bzgl. Zuweisungsoperator
    ... Am sichersten ist es, wenn man solche Sachen, die der Compiler nicht ... Klasse implementieren, die dafür sorgt, dass beim Kopieren ein neues Element ... Statt eines Pointers auf ein Array sollte man einen std::vector (oder statt ... Wenn die problematischen Typen auf eine solche Weise ersetzt werden, ...
    (microsoft.public.de.vc)