Θέματα απόδοσης της Java virtual Machine και του περιβάλλοντος υποστήριξης για την υλοποίηση Oracle J ^ c K t

Transcript

1 ΤΑΚΟΥ ΕΛΕΥΘΕΡΙΑ Σ.Δ.Ο: ΣΧΟΛΗ ΔΙΟΙΚΗΣΗΣ ΚΑΙ ΟΙΚΟΝΟΜΙΑΣ ΤΜΗΜΑ: ΔΙΑΧΕΙΡΙΣΗ ΠΛΗΡΟΦΟΡΙΩΝ ΕΤΟΣ Θέματα απόδοσης της Java virtual Machine και του περιβάλλοντος υποστήριξης για την υλοποίηση Oracle J ^ c K t

2 ΠΕΡΙΕΧΟΜΕΝΑ Πρόλογος...5 ΕΙΣΑΓΩΓΗ... 6 ΚΕΦΑΛΑΙΟ 1 ΤΑ ΠΡΩΤΑ ΒΗΜΑΤΑ 1. Απόκτηση του JRockit JVM Μεταφορά στο JRockit Ιδιότητες συστήματος Τ υποποιημένες επιλογές Μη-τυποποιημένες επιλογές VM Flags Αλλαγές συμπεριφοράς Ένα σημείωμα στην οργάνωση JRockit Λήψη Βοήθειας ΙΟ.Περίληψη...11 ΚΕΦΑΛΑΙΟ 2 Κωδικός προσαρμοστικής παραγωγής Ανεξαρτησία πλατφόρμας Java το εικονικό μηχάνημα Μηχανή στοίβαξης Διάταξη Bytecode Λειτουργίες και τελεστές The constant pool Κωδικός στρατηγικής παραγωγής Διερμηνεία Pure byte code Στατική Μεταγλώττιση Συνολική JIT κατάρτιση Μεικτή λειτουργία επεξήγησης Προσαρμοστική παραγωγή κωδικού Προσδιορισμός Hotness Μετρητές Επίκλησης Δείγματα Λογισμικού (Thread) Δείγματα Υλικού Η Βελτιστοποίηση σε πρόγραμμα αλλαγής Μέσα στο JIT συλλέκτη Εργασία με bytecode Byte code συσκότιση Bytecode βελτιστοποιήσεις Αφηρημένη σύνταξη δέντρων Που να βελτιστοποιήσετε The JRockit code pipeline Γιατί το JRockit δεν έχει bytecode διερμηνέα; Bootstrapping

3 27. Παραγωγή κωδικού χρόνου λειτουργίας Trampolines back patching Αιτήσεις παραγωγής κωδικού Αιτήσεις βελτιστοποίησης Αντικατάσταση Σωρού Τήρηση βιβλίων Πληροφορίες αντικειμένου για το GC Πρωτογενής κωδικός και μεταβλητές πληροφορίες Υποθέσεις για τον κωδικό παραγωγής Μια ακολουθία της μεθόδου παραγωγής στο JRockit Το JRockit IR φόρμα Ροή δεδομένων Έλεγχος ροής Λίγα λόγια για τις εξαιρέσεις Παραγωγή HIR MIR LIR Κατανομή καταγραφής Native code emission Παραγωγή κωδικού βελτιστοποιήσεις Γενική επισκόπηση Πως λειτουργεί ο βελτιστοποιητής; Ελέγχοντας την παραγωγή κωδικών στο JROCKIT Σημεία γραμμής εντολών και αρχεία οδηγιών Σημεία γραμμής εντολών ΥΛΟΤΟΜΙΑ Αρχεία οδηγιών ΣΥΝΟΨΗ ΚΕΦΑΛΑΙΟ 3 Προσαρμοστική διαχείριση μνήμης. 1. Η έννοια της αυτόματης διαχείρισης μνήμης Προσαρμοστική διαχείριση μνήμης Πλεονεκτήματα της αυτόματης διαχείρισης μνήμης Μειονεκτήματα της διαχείρισης αυτόματης μνήμης Θεμελιώδη διαχείριση σωρού Η κατανομή και απελευθέρωση αντικειμένων Κατάτμηση και συμπίεση Σημειώστε και σαρώστε Παύση και αντιγραφή Διακοπή λειτουργίας του κόσμου Συντηρητικοί έναντι ακριβείς συλλέκτες Live maps / ζωντανός σχεδιασμός Συλλογή απορριμμάτων Γενιάς Multi generation nurseries Εμπόδια γραφής Βελτιστοποίηση για απόδοση Παλιές συλλέξεις Επιταχύνοντας και κλιμακώνοντας Σπείρωμα τοπικής κατανομής Φράγμα 32 BITS 4 G B Ο 64bit κόσμος

4 22. Συμπιεσμένες αναφορές Φιλικότητα CACHE Πρόληψη Τοποθέτηση δεδομένων NUMA Μεγάλες σελίδες Προσαρμογή Σε σχεδόν πραγματικό χρόνο συλλογής απορριμμάτων Σκληρός και πραγματικός χρόνος JRockit πραγματικός χρόνος Πως λειτουργεί? Η Java μνήμη API Οριστικοποιήσεις Αναφορές Αδύναμες αναφορές Μαλακές αναφορές Αναφορές 'φάντασμα' Διαφορές στην JVM συμπεριφορά Παγίδες και ψευδείς βελτιστοποιήσεις Η Java δεν είναι C Ο έλεγχος διαχείρισης μνήμης JRockit Βασικοί διακόπτες H παραγωγή (εξόδου) GC δεδομένων Έλεγχος για το τι να βελτιστοποιηθεί Προσδιορίζοντας τη στρατηγική μιας συλλογής απορριμμάτων Συμπιεσμένες αναφορές Προχωρημένες αλλαγές Σύνοψη...69 Βιβλιογραφία

5 Πρόλογος H Oracle JRockit είναι μια ολοκληρωμένη λύση Java SE που περιλαμβάνει υψηλής απόδοσης JVM, προφίλ, παρακολούθηση και διαγνωστικά εργαλεία και προβλέψιμη καθυστέρηση για εφαρμογές Java. 5

6 Εισαγωγή Μια επιχείρηση πρέπει να διαχειρίζεται σε καθημερινή βάση την αλλαγή προκειμένου να παραμείνει στην πρωτοπορία. Κι αυτό δεν αφορά μόνο την κάλυψη των συνεχώς μεταβαλλόμενων αναγκών των πελατών, αλλά και την αξιοποίηση των πλεονεκτημάτων από τις νέες τεχνολογίες. Με την Oracle, έχετε την ευκαιρία να μετατρέψετε την αλλαγή σε προοπτική για να μεταμορφώσετε την επιχείρησή σας. Είτε οι προκλήσεις που αντιμετωπίζετε αφορούν τις νέες συνθήκες της αγοράς είτε τις μεταβαλλόμενες ανάγκες των πελατών, το μέλλον σας εξαρτάται από τη δυνατότητά σας να ανταποκρίνεστε γρήγορα και να αξιοποιείτε αυτές τις προοπτικές. Η Oracle διαθέτει μια σειρά από λύσεις που θα σας βοηθήσουν να δημιουργήσετε ένα περιβάλλον εφαρμογών υψηλών επιδόσεων, να μειώνει το κόστος λειτουργίας απλοποιώντας τη διαχείριση και τις λειτουργικές δαπάνες, και να υποστηρίζει την καινοτομία μέσα σε μια αγορά που αλλάζει με καταιγιστικούς ρυθμούς. 6

7 1 Τα Πρώτα Βήματα Το πρώτο μέρος, περιέχει γενικές πληροφορίες για την εσωτερική λειτουργία όλων των προσαρμοστικών λειτουργιών, τα παραδείγματα και οι σε βάθος πληροφορίες ακόμα υποθέτουν ότι το JRockit JVM είναι σε χρήση. Αυτό το κεφάλαιο εξηγεί συνοπτικά πώς να αποκτήσετε το JRockit JVM και καλύπτει ζητήματα θυρίδας (port) που μπορεί να προκύψουν ενώ αναπτύσσετε η εφαρμογή Java στο JRockit. Σε αυτό το κεφάλαιο, θα μάθετε: Πώς να αποκτήσετε το JRockit Οι πλατφόρμες που υποστηρίζονται από το JRockit Πώς να μπείτε στο JRockit Για τις επιλογές της γραμμής εντολών του JRockit Πώς να ερμηνεύσετε αριθμούς έκδοσης του JRockit Που θα βρείτε βοήθεια εάν συναντήσετε πρόβλημα Απόκτηση του JRockit JVM Γ ια να αξιοποιήσετε στο έπακρο αυτές τις αναφορές, η τελευταία έκδοση του JRockit JVM είναι απαραίτητη. Γ ια εκδόσεις JRockit πριν το R27.5, απαιτητέ ένα κλειδί άδειας για την πρόσβαση σε ορισμένα από τα πιο προηγμένα χαρακτηριστικά του JRockit. Ως μέρος της Oracle απόκτησης του συστήματος BEA, το σύστημα των αδειών έχει αφαιρεθεί και τώρα είναι πλέον δυνατή η πρόσβαση σε όλες τις λειτουργίες του JRockit χωρίς καμία άδεια χρήσης κλειδιού (license key). Το γεγονός αυτό καθιστά πολύ ευκολότερο να αξιολογήσετε και να χρησιμοποιήσετε το JRockit στην ανάπτυξη. Γ ια την χρήση του JRockit στην παραγωγή, η άδεια πρέπει να αγοραστεί. Για τους πελάτες της Oracle, αυτό είναι σπάνια ένα ζήτημα, αφού το JRockit περιλαμβάνεται με τις επιλογές εφαρμογών, για παράδειγμα, όποια εφαρμογή περιλαμβάνει το Web Logic Server θα περιέχει επίσης και το JRockit. Κατά το χρόνο σύνταξης της παρούσας έκθεσης, ο ευκολότερος τρόπος να αποκτήσετε ένα JRockit JVM είναι να κάνετε λήψη και να εγκαταστήσετε το JRockit Mission Control (Αποστολή Έλεγχου) - τις διαγνωστικές και την εφαρμογή κατανομής εργαλείων για το JRockit. Ο φάκελος διάταξης της Αποστολής Έλεγχου (Mission Control) είναι σχεδόν ίδιος με οποιονδήποτε JDK και μπορεί εύκολα να χρησιμοποιηθεί ως JDK. Οι συγγραφείς θα ήθελαν πάρα πολύ να είναι σε θέση να παρέχουν ένα JVM που αυτό-περιέχεται - μόνο JDK για JRockit, αλλά αυτό είναι πέρα από τον έλεγχο μας. Προσδοκούμε ότι αυτό θα αλλάξει στο άμεσο μέλλον. Πριν γίνει λήψη του αρχείου JRockit Mission Control, βεβαιωθείτε ότι μια υποστηριζόμενη πλατφόρμα είναι σε χρήση. Το server μέρος του Mission Control υποστηρίζεται σε όλες τις πλατφόρμες για το οποίο υποστηρίζεται και το JRockit. Παρακάτω βρίσκεται μια πλατφόρμα matrix για το JRockit Mission Control 3.1.x: Platform Java Java 5.0 Java 6 Linux x86 X X X Linux x86-64 N/A X X Linux Itanium X (server only) X (server only) N/A Solaris SPARC (64-bit) X (server only) X (server only) X (server only) Windows x86 X X X Windows x86-64 N/A X (server only) X (server only) Windows Itanium X (server only) X (server only) N/A 7

8 Παρακάτω υπάρχει μια πλατφόρμα matrix για το JRockit Mission Control 4.0.0: Platform Java 5.0 Java 6 Linux x86 X X Linux x86-64 X X Solaris SPARC (64-bit) X (server only) X (server only) Windows x86 X X Windows x86-64 X Σημείωσε ότι το JRockit Mission Control client δεν υποστηρίζεται (ακόμα) στο Solaris, αλλά ότι το 64 - bit Windows υποστήριξη έχει προστεθεί στο Κατά την εκτέλεση του JRockit Mission Control στο Windows, βεβαιωθείτε ότι το σύστημα προσωρινού καταλόγου είναι στο σύστημα αρχείων που υποστηρίζει τα δικαιώματα πρόσβασης αρχείων ανά χρήστη. Με άλλα λόγια, σιγουρευτείτε ότι δεν είναι σε FAT διαμορφωμένη δισκέτα, βασικές λειτουργίες όπως αυτόματη ανακάλυψη τοπικών JVM's θα απενεργοποιηθούν. Ο ευκολότερος τρόπος για να φτάσετε στην αρχική σελίδα του JRockit είναι να πάτε στην αγαπημένη σας μηχανή αναζήτησης και να πληκτρολογήσετε download JRockit. Θα πρέπει να καταλήξετε σε μια σελίδα στο Oracle τεχνολογικό δίκτυο από το οποίο το JVM και το Mission Control suite μπορούν να γίνουν λήψη. Αυτή η διαδικασία εγκατάστασης διαφέρει ανάμεσα στις πλατφόρμες, αλλά πρέπει να είναι αρκετά επεξηγηματική. Μεταφορά στο JRockit Εδώ, θα αναφερθούμε στον κατάλογο (directory) όπου το JRockit είναι εγκατεστημένο ως JROCKIT_HOME. Ίσως απλοποιήσει τα πράγματα για να καταστήσει το JRockit μια μεταβλητή συστήματος με κατεύθυνση προς τη συγκεκριμένη διαδρομή. Μετά την ολοκλήρωση της εγκατάστασης είναι καλή ιδέα να τοποθετηθεί το JROC KIT_HOME/bin στον κατάλογο της διαδρομής και να ενημερώσετε τις δέσμες ενεργειών για όποια JAVA αίτηση που θα έπρεπε να κατευθυνθεί προς το JROCKIT. Η ρύθμιση της JAVA_HOME μεταβλητής περιβάλλοντος στο JROCKIT_HOME συνίσταται επίσης. Στα περισσότερα σημεία το JRockit είναι μια άμεση πτώση σε αντικατάσταση άλλων JVMs, αλλά κάποια επιχειρήματα εκκίνησης, για παράδειγμα, επιχειρήματα που ελέγχουν την συμπεριφορά συλλογής σκουπιδιών συνήθως διαφέρουν μεταξύ JVMs από διαφορετικούς προμηθευτές. Πιο συνήθεις επιχειρήματα, ωστόσο, επιχειρήματα για την ρύθμιση του μέγιστου μεγέθους της σωρού, τείνουν να τυποποιηθούν ανάμεσα στα JVMs. Γ ια περισσότερες πληροφορίες πάνω σε συγκεκριμένες λεπτομερείς μεταφοράς, δείτε την Αίτηση Μεταφοράς στο Oracle JRockit JDK κεφάλαιο στο online έγγραφο του JRockit. Επιλογές Γ ραμμής Εντολών Υπάρχουν τρεις βασικοί τύποι επιλογής γραμμών εντολών του JRockit - ιδιότητες συστήματος, τυποποιημένων επιλογών (-x flags) και μη-τυπικής φύσεως (-xx flags). Ιδιότητες συστήματος Επιχειρήματα εκκίνησης σε ένα JVM προέρχονται από πολλές διαφορετικές επιλογές. Επιχειρήματα που ξεκινούν από -D ερμηνεύονται ως μια οδηγία για να ρυθμίσετε το σύστημα ιδιοκτησίας. Τέτοια συστήματα ιδιοκτησίας μπορούν να παρέχουν ρύθμιση παραμέτρων διαμόρφωσης για διάφορα μέρη της JAVA class libraries, για παράδειγμα RMI. Το JRockit Mission Control παρέχει πληροφορίες εντοπισμού σφαλμάτων εάν το ξεκινήσετε με -Dcom.JRockit.mc.debug=true. Στις εκδόσεις JRockit R28, η χρήση της ιδιότητας συστημάτων για να παρέχει παραμέτρους στο JVM είναι κυρίως ανεπιθύμητη. Αντίθετα, οι περισσότερες επιλογές για το JVM παρέχονται μέσο μη-τυποποιημένων επιλογών και στις καινούριες HotSpot στυλ των VM flags. 8

9 Τυποποιημένες επιλογές Ρυθμίσεις διαμόρφωσης για το JVM συνήθως ξεκινούν με -x για ρύθμισης που συνήθως υποστηρίζονται από προμηθευτές. Γ ια παράδειγμα, η επιλογή για την ρύθμιση μέγιστου μεγέθους σωρού, -Xmx, είναι η ίδια στα περισσότερα JVMs, συμπεριλαμβανομένου και του JRockit. Υπάρχουν κάποιες εξαιρέσεις εδώ. Η JRockit σημαία -Xverbose παρέχει σύνδεση με προαιρετικές υπό-εντολές. Παρόμοια (αλλά πιο ορισμένη) σημαία στο HotSpot απλά ονομάζεται -verbose. Μη-τυποποιημένες επιλογές Των προμηθευτών οι ειδικές επιλογές διαμόρφωσης είναι συνήθως με πρόθεμα -xx. Αυτές οι επιλογές θα έπρεπε να αντιμετωπίζονται ως ενδεχομένως μη-υποστηριζόμενες και υπόκεινται σε αλλαγή χωρίς προειδοποίηση. Εάν οποιαδήποτε εγκατάσταση JVM εξαρτάται από -xx προθεματικές επιλογές, εκείνες οι σημαίες πρέπει να αφαιρούνται ή να αποβάλλονται πριν ξεκινήσει μια εφαρμογή σε JVM από διαφορετικό προμηθευτή. Μόλις οι επιλογές του JVM έχουν καθοριστεί, η εφαρμογή του χρηστή μπορεί να ξεκινήσει. Συνήθως η μετακίνηση μιας υπάρχουσας εφαρμογής στο JRockit οδηγεί σε αύξηση του χρόνου απόδοσης και σε μια μικρή αύξηση της κατανάλωσης μνήμης. Το JVM έγγραφο θα πρέπει πάντα να το συμβουλεύεστε για να προσδιοριστεί εάν μη-τυποποιημένες επιλογές της γραμμής εντολών έχουν την ίδια σημασιολογία ανάμεσα σε διαφορετικές εκδόσεις JVMs και JVM. VM Flags Σε εκδόσεις JRockit R28, υπάρχει πάντα ένα υποσύνολο από μη-τυποποιημένες επιλογές που ονομάζονται VM σημαίες. Αυτές χρησιμοποιούν τη σύνταξη -xx:(flag)=(value). Αυτές οι σημαίες μπορούν επίσης να διαβαστούν και ανάλογα με την συγκεκριμένη σημαία, να γραφτεί χρησιμοποιώντας το βοηθητικό πρόγραμμα γραμμής εντολών JRCMD αφού το JMV έχει ξεκινήσει. Για περισσότερες πληροφορίες πάνω στο JRCMD, δείτε το κεφάλαιο 11. Αλλαγές συμπεριφοράς Μερικές φορές υπάρχει μια αλλαγή στη συμπεριφορά του χρόνου λειτουργίας όταν γίνεται μετακίνηση από ένα JMV σε άλλο. Συνήθως καταλήγει σε διαφορετικά JMV να ερμηνεύουν τη γλώσσα προδιαγραφών Java ή Java Virtual Machine (εικονικό μηχάνημα) διαφορετικά αλλά σωστά. Σε μερικά σημεία υπάρχουν κάποια περιθώρια για τον χαρακτηρισμό που δίνουν διαφορετικοί προμηθευτές για να εφαρμοστεί η λειτουργικότητα με έναν τρόπο που ταιριάζει καλύτερα στην αρχιτεκτονική του πωλητή. Εάν μια εφαρμογή βασίζετε πάρα πολύ σε συγκεκριμένη εκτέλεση των προδιαγραφών, η εφαρμογή είναι πιο πιθανόν να αποτύχει όταν γίνετε μετάβαση σε άλλη εφαρμογή. Γ ια παράδειγμα, κατά τη διάρκεια της αρόσιμης δοκιμής για μια παλαιότερη εκδοχή της Eclipse μερικές από τις δοκιμές άρχισαν να αποτυγχάνουν όταν λειτουργούσαν στο JRockit. Με αυτόν τον τρόπο λόγο των δοκιμών που έχουν εξάρτηση από τον εσωτερικό έλεγχο, και αυτή η συγκεκριμένη σειρά των δοκιμών εξαρτιόταν από υπό-σκευή στη λειτουργία των δοκιμών σε συγκεκριμένη σειρά. Η JRockit εφαρμογή μεθόδων ανακλαστικής απαρίθμησης δεν είχε επιστρέψει τις μεθόδους στην ίδια σειρά όπως άλλα JVMs, που σύμφωνα με τους προσδιορισμούς ήταν εντάξει. Αργότερα αποφασίστηκε από την αναπτυξιακή ομάδα του Eclipse ότι η στήριξη σε μια συγκεκριμένη μέθοδο σειράς ήταν bug (ιός) και έτσι οι εφαρμογές διορθώθηκαν. Εάν μια εφαρμογή δεν έχει γραφτεί με λεπτομέρεια, αλλά με την συμπεριφορά του JVM από κάποιον προμηθευτή, μπορεί να αποτύχει. Μπορεί ακόμα να αποτύχει όταν λειτουργεί με μια πιο πρόσφατη εκδοχή από τον ίδιο προμηθευτή. Όταν υπάρχει αμφιβολία, συμβουλέψου τη Java προδιαγραφή γλώσσας και το έγγραφο JDK. Διαφορές στην επίδοση μπορεί επίσης να είναι θέμα όταν μεταβάλεις JVM για μια εφαρμογή. Κρυμμένοι ιοί που δεν ήταν θέμα με ένα JVM ίσως είναι θέμα με άλλο, εάν για παράδειγμα, οι διαφορές στις επιδόσεις προκαλούν συμβάντα νωρίτερα ή αργότερα από ότι πιο πριν. Αυτά τείνουν να δημιουργούν θέματα υποστήριξης αλλά σπανίως είναι φταίξιμο του JMV. 9

10 Γ ια παράδειγμα, ένας πελάτης ανέφερε ότι το JRockit συντρίβει μετά από μόλις μια μέρα. Η έρευνα κατέληξε στο ότι η εφαρμογή επίσης συντρίβει με το JVM από άλλον προμηθευτή, αλλά πήρε περισσότερες μέρες για αυτήν την εφαρμογή να συντριβεί. Βρέθηκε ότι το πρόγραμμα συντριβής λειτούργησε πιο γρήγορα στο JRockit, και ότι το πρόβλημα, διαρροή μνήμης, ήρθε στην επιφάνεια πολύ σύντομα. Φυσικά, οποιοδήποτε JVM συμπεριλαμβανομένου το JRockit, μπορεί να έχει ιούς. Για να ονομαστεί Java μια εικονική μηχανή εφαρμογής Java πρέπει να περάσει μια εκτεταμένη δόκιμη στη Java συμβατότητα JCK. To JRockit μόνιμα υπόκειται σε μια σειρά δοκιμών χρησιμοποιώντας ένα κατανεμημένο σύστημα δοκιμής. Μεγάλες δοκιμαστικές σουίτες, στις οποίες το JCK είναι ένα μέρος τους, είναι σε λειτουργία για να εξασφαλίσει, ότι το JRockit μπορεί να εκδοθεί ως σταθερό, Java συμβατό, και πιστοποιημένο JVM. Μεγάλες δοκιμαστικές σουίτες από διάφορα προϊόντα υψηλού προφίλ, όπως το Eclipse και το WebLogic Server, καθώς επίσης και ειδικά σχεδιασμένες στρες δόκιμες (καταπόνησης) είναι σε λειτουργία σε όλες τις υποστηριζόμενες πλατφόρμες πριν γίνει η έκδοση τους. Συνεχές δοκιμές της απόδοσης αποκρύπτονται, επίσης γίνεται ως θεμελιώδες μέρος της QA υποδομής. Ακόμα κι έτσι οι ιοί εμφανίζονται. Εάν το JRockit όντως συντρίβει πάντα θα πρέπει να αναφέρετε στους μηχανικούς της Oracle. Ένα σημείωμα στην οργάνωση JRockit Ο τρόπος με τον οποίο το JRockit έχει οργανωθεί μπορεί να είναι λίγο μπερδεμένο. Υπάρχουν τουλάχιστον τρεις αριθμοί έκδοσης ενδιαφέροντος για κάθε έκδοση του JRockit: 1. Η JRockit JVM έκδοση. 2. Η JDK έκδοση 3. Η Mission Control έκδοση Ένας τρόπος για να αποκτήσεις τους αριθμούς έκδοσης του JVM είναι να θέσεις σε λειτουργία το java - version από τη γραμμή εντολών. Αυτό τυπικά θα είχε αποτέλεσμα κάτι σαν τις ακόλουθες γραμμές που θα εμφανιστούν στην κονσόλα: Java version 1.6.0_14 Java SE Runtime Environnent (build 1.6.0_14-b08) Oracle JRockit (build R _ windows-ia32, compiled mode) Ο πρώτος αριθμός έκδοσης είναι η έκδοση JDK, που είναι μαζί με το JVM. Au^ ο αριθμός είναι σε συγχρονισμό με την πρότυπη έκδοση JDK, για το JDK που πλέει με το HotSpot. Από το παράδειγμα, ερχόμαστε στο συμπέρασμα ότι το Java 1.6 υποστηρίζεται και ότι συμπεριλαμβάνετε στις JDK τάξεις από την αναβάθμιση 14-b08. Εάν εσύ, για παράδειγμα, ψάχνεις να δεις ποιες JDK class - διορθώσεις επιπέδου περιλαμβάνονται σε συγκεκριμένη έκδοση, αυτός θα είναι ο αριθμός έκδοσης που θα ελέγξεις. Η έκδοση JRockit είναι ο αριθμός έκδοσης που αρχίζει με R. Στο παραπάνω παράδειγμα αυτό θα είναι R Κάθε έκδοση του JRockit JVM είναι φτιαγμένη για πολλά διαφορετικά JDK. Η R27.6.5, για παράδειγμα, υπάρχει στις εκδόσεις για Java 1.4, 1.5 (5.0) και 1.6 (6.0). Με την R28 έκδοση του JRockit, η υποστήριξη για Java 1.4 σταδιακά απορροφήθηκε. Ο αριθμός που ακολουθεί τον αριθμό έκδοσης είναι ο αριθμός build, και ο αριθμός μετά από αυτόν είναι ο αριθμός αλλαγής από το σύστημα εφαρμογής. Στο παράδειγμα ο αριθμός build ήταν 582 και ο αριθμός αλλαγής Οι δυο αριθμοί μετά τον αριθμό αλλαγής είναι η ημερομηνία (σε συμπίεση ISO 8601 φόρμα) και η ώρα (CET) που έγινε το built. Μετά από αυτό έρχεται το λειτουργικό σύστημα και η αρχιτεκτονική του CPU για το οποίο φτιάχτηκε το JVM. Ο αριθμός έκδοσης του JRockit Mission Control μπορεί να συγκεντρωθεί με την εκτέλεση Jrmc -version ή jrmc -version I more από την γραμμή εντολών. 10

11 Note: Στα Windows το JRockit Mission Control launcher (προωθητης) (jrmc) βασίζετε στο java launcher για την αποφυγή ανοίγματος παραθύρου στην κονσόλα. Η έξοδος από την κονσόλα δεν θα παρουσιαστεί εκτός αν ρητά ξαναπροωθηθεί, για παράδειγμα στο more. Λήψη Βοήθειας Υπάρχουν πολλές διαθέσιμες χρήσιμες πηγές του JRockit και του JRockit Mission Control σκι δίκτυο τεχνολογίας Oracle, όπως ιστολόγια, άρθρα και φόρουμ. Οι δημιουργοί και το προσωπικό υποστήριξης του JRockit συνεχώς παρακολουθούν τα φόρουμ, έτσι όταν δεν μπορεί να βρεθεί μια απάντηση σε κάποια συγκεκριμένη ερώτηση στο φόρουμ, συνήθως απαντιέται σε λίγες μέρες. Κάποιες ερωτήσεις είναι πιο συχνές από άλλες και υπάρχουν σε μορφή σημειώσεων - σε φόρουμ θέσεις που θα παραμείνουν στην κορυφή των θεματικών καταλόγων. Υπάρχει, για παράδειγμα, ένα σημείωμα διαθέσιμο για το πώς να αποκτήσεις άδεια αρχείων για παλαιότερες εκδόσεις του JRockit. Note: Το JRockit φόρουμ μπορεί να βρεθεί εδώ, την ώρα της γραφής Εδώ είναι οι τοποθεσίες από κάποια δημοφιλή JRockit ιστολόγια Περίληψη Αυτό το κεφάλαιο περιείχε ένα σύντομο οδηγό στο πώς να ξεκινήσει το JRockit JVM και το πώς να εγκαταστήσεις υφιστάμενες εφαρμογές στο JRockit JVM. Εμείς καλύψαμε την εγκατάσταση του JRockit και παρείχαμε ανάλυση σε συνηθισμένες παγίδες κατά την μετεγκατάσταση της Java εφαρμογής από το ένα JVM στο άλλο. Οι διάφορες κατηγορίες των γραμμών εντολών που υποστηρίζει το JRockit εξηγήθηκαν και εμείς δείξαμε παραδείγματα του πώς να βρεις αριθμούς έκδοσης από διάφορα εξαρτήματα του JRockit JDK. 11

12 ΚΕΦΑΛΑΙΟ 2 Κωδικός προσαρμοστικής παραγωγής Αυτό το κεφάλαιο καλύπτει τον κωδικό παραγωγής και τον κωδικό βελτιστοποίησης στο περιβάλλον λειτουργίας του JVM, και τα δυο ως γενική έννοια καθώς επίσης και μια πιο προσεκτική ματιά στον κωδικό παραγωγής internals. Ξεκινάμε συζητώντας τον κωδικό με τη μορφή byte και πως ένας IIT συλλέκτης δουλεύει, κάνοντας μια υπόθεση για την ισχύ της προσαρμοσμένης λειτουργίας. Μετά από αυτό συνεχίζουμε μέσα στο JRockit JVM. Τελικά, ο αναγνώστης μαθαίνει πώς να χειρίζεται τον κωδικό παραγωγής και βελτιστοποίησης στο JRockit. Θα μάθεις τα παρακάτω από αυτό το κεφάλαιο: Τα οφέλη της φορητής πλατφόρμας - ανεξάρτητης γλώσσας όπως το Java. Τη δομή της διάταξης του Java byte code και βασικά στοιχεία προσδιορισμού του Java Virtual Machine. Πως το JVM ερμηνεύει το bytecode προκειμένου να εκτελέσει ένα πρόγραμμα στη Java. Προσαρμοστικές βελτιστοποιήσεις στο χρόνο λειτουργίας έναντι της στατικής εν' όψει χρόνου κατάρτισης. Γ ιατί το πρώτο είναι καλύτερο αλλά πιο δύσκολο να γίνει. «Η απόδοση των στόχων» μεταφορικά. Γ ιατί ο κωδικός παραγωγής είναι σε προσαρμοσμένο χρόνο λειτουργίας, είναι ενδεχομένως πιο δυναμικός. Πως η Java μπορεί να προσαρμοστεί σε native κωδικό και ποια είναι τα κύρια προβλήματα που πρέπει να γίνονται βελτιστοποιήσεις - από τον Java προγραμματιστή, από το JVM ή στο επίπεδο bytecode; Πως ο JRockit pipeline κωδικός λειτουργεί και ο λογικός του σχεδιασμός Πώς να ελέγξεις τον κωδικό παραγωγής στο JRockit. Ανεξαρτησία πλατφόρμας Το κύριο προκείμενο πώλησης της Java, όταν πρωτοεμφανίστηκε, και η κύρια πηγή στην επιτυχία της σαν βασική γλώσσα ήταν η έννοια του ότι το γράφεις μια φορά και λειτουργεί παντού. Τα προγράμματα Java συντάσσονται σε πλατφόρμες ανεξαρτησίας σε συμπαγής Java bytecodes (.class files). Δεν υπάρχει ανάγκη για μεταγλώττιση της εφαρμογής Java για διαφορετικές αρχιτεκτονικές, αφού όλες οι πλατφόρμες Java λειτουργούν σε συγκεκριμένες πλατφόρμες Java Virtual Machine που φροντίζει για την μετάβαση σε native κωδικό. Αυτή η ευρέως βελτιωμένη φορητότητα είναι καλό πράγμα. Μια εφαρμογή, όπως ένα C++ πρόγραμμα, που ομαδοποιείται σε μια μορφή εξαρτημένης πλατφόρμας, έχει πολύ λεπτομερή ευεξία. Ο C++ συλλέκτης μπορεί να 12

13 συλλέξει και να βελτιστοποιήσει σε μεγάλο βαθμό το πρόγραμμα, για παράδειγμα, για x86 αρχιτεκτονική. Τότε x86 θα είναι η μόνη αρχιτεκτονική στην οποία το πρόγραμμα θα μπορεί να λειτουργήσει. Δεν μπορούμε να μετακινήσουμε το πρόγραμμα, βελτιστοποιήσεις και τα συναφή, στο SPARC. Πρέπει να συλλεχτεί ξανά, ίσως με πιο δυνατό συλλέκτη που δεν βελτιστοποιείται τόσο καλά για το x86. Επίσης εάν η x86 αρχιτεκτονική αναβαθμιστεί με νέες οδηγίες, το πρόγραμμα δεν θα μπορέσει να εκμεταλλευτεί αυτά χωρίς να γίνει επανασυλλογή. Η φορητότητα μπορεί φυσικά να επιτευχθεί με τη διανομή του κωδικού πηγής, αλλά αυτό μπορεί άντ' αυτού να υπόκεινται σε διάφορους περιορισμούς εφαρμογής. Στη Java το πρόβλημα φορητότητας μεταφέρεται στο JVM, κι έτσι γίνετε ευθύνη ενός τρίτου για τον προγραμματιστή. Στον κόσμο της Java, όλες οι πλατφόρμες στις οποίες υπάρχει ένα JVM μπορεί να εκτελεστεί Java. Ανεξάρτητες πλατφόρμες bytecode δεν είναι καινούρια έννοια ανά se, και έχει χρησιμοποιηθεί σε αρκετές γλώσσες στο παρελθόν, για παράδειγμα Pascal και Smalltalk. Ωστόσο, η Java ήταν η πρώτη γλώσσα, όπου ήταν σημαντικός παράγοντας στην ευρεία υιοθέτηση της. Όταν η Java ήταν καινούρια, οι εφαρμογές της ήταν κυρίως σε μορφές Applets (μικρό-εφαρμογές) σχεδιασμένη για ενσωματωμένη εκτέλεση σε πρόγραμμα περιήγησης στο διαδίκτυο. Οι μικρό-εφαρμογές είναι τυπικά παραδείγματα παράπλευρα προγράμματα πελατών. Ωστόσο, η Java δεν είναι μόνο ανεξάρτητης πλατφόρμας αλλά επίσης έχει αρκετές άλλες καλές native ιδιότητες γλώσσας όπως ενσωματωμένη διαχείριση μνήμης και προστασία από υπέρβαση λειτουργίας ρύθμιση. Το JVM επίσης παρέχει την εφαρμογή ασφαλείας του μοντέλου πλατφόρμας. Όλα αυτό κάνουν την Java ιδανική όχι μόνο για εφαρμογές πελατών αλλά επίσης για σύνθετη λογική του server. Πήρε αρκετά χρόνια πριν τα οφέλη της Java σαν γλώσσα server-side ήταν πλήρως αναγνωρίσιμα. Η εγγενείς στιβαρότητα οδήγησε σε ραγδαία μικρότερης αναπτυξιακής εφαρμογής σε σύγκριση με C++ και σε ευρεία υιοθέτηση server. Μικρότεροι αναπτυξιακοί κύκλοι έχουν μεγάλη σημασία όταν η εφαρμογή που αναπτύσσετε είναι αρκετά περίπλοκη όπως είναι τυπικά η υπόθεση για το server side. Java το εικονικό μηχάνημα Ενώ οι ανεξάρτητες πλατφόρμες bytecode προσφέρουν απόλυτη φορητότητα ανάμεσα σε διάφορες πλατφόρμες υπολογιστών, ένα φυσικό CPU ακόμα δεν μπορεί να το εκτελέσει. Το CPU μόνο ξέρει να εκτελεί τα συγκεκριμένα είδη του native κωδικού. Note: Σε αυτό το κείμενο θα αναφερθούμε στον κωδικό που είναι συγκεκριμένο σε ορισμένες αρχιτεκτονικές μηχανημάτων υπολογιστών ως native κωδικός. Γ ια παράδειγμα, x86 συμβολική γλώσσα ή x86 κώδικας μηχανής είναι ο native κωδικός για την x86 πλατφόρμα. Ο κωδικός μηχανής θα πρέπει να εννοείται ότι σημαίνει κωδικός σε δυαδική εξαρτημένη πλατφόρμα φορματ. Η συμβολική γλώσσα θα πρέπει να θεωρείται ότι σημαίνει κωδικό μηχανής σε μορφή αναγνωρίσιμη στους ανθρώπους. Έτσι, το JVM απαιτείται για να γυρίσει τα byte codes σε native κωδικούς για το CPU για το οποίο η εφαρμογή Java εκτελείται. Αυτό μπορεί να γίνει με έναν από τους δυο ακολούθους τρόπους: Οι προσδιορισμοί του Java Virtual Machine περιγράφει πλήρως το JVM ως μηχάνημα κατάστασης, έτσι δεν υπάρχει ανάγκη για ακριβής μεταγλώττιση του bytecode σε native κωδικό. Το JVM μπορεί να μιμηθεί ολόκληρη την εκτελεστική κατάσταση του προγράμματος Java, συμπεριλαμβανόμενης της μίμησης κάθε bytecode οδηγίας ως λειτουργία της JVM κατάστασης. Αυτό αναφέρεται ως εξήγηση bytecode. Ο μονός native κωδικός (εκτός από JM) που εκτελείται κατευθείαν εδώ είναι το JVM, καθ' αυτού. Το Java Virtual Machine συμμορφώνει το bytecode που είναι να εκτελεστεί σε native κωδικό για συγκεκριμένη πλατφόρμα και τότε καλείται ο native κωδικός. Όταν τα bytecode προγράμματα είναι συμβατά με το native κωδικό, αυτό τυπικά γίνεται με μια μέθοδο τη φορά, μόλις πριν αυτή η μέθοδος είναι να εκτελεστεί για πρώτη φορά. Αυτό είναι γνωστό ως Κατάρτιση ακριβής στιγμής (Just-in-time compilation JIT). Φυσικά, μια μορφή native κωδικού ενός προγράμματος εκτελεί διαταγές σημασίας γρηγορότερα από αυτά της διερμηνείας. Το δίλημμα είναι, όπως θα δούμε, διπλογραφικού συστήματος και γενικής κατάρτισης χρόνου. 13

14 Μηχανή στοίβαξης Το Java Virtual Machine είναι μια μηχανή στοίβαξης. Όλες οι bytecode λειτουργίες, με μερικές εξαιρέσεις, υπολογίζονται από τη στοίβα αξιολόγησης από πρωτοφανής τελεστές από τη σωρό, εκτελώντας τη λειτουργία και βασίζοντας το αποτέλεσμα πίσω στη στοίβα. Γ ια παράδειγμα, η προσθήκη αυτή εκτελείται βάζοντας τους δυο όρους πίσω στη στοίβα, εκτελώντας μια προσθήκη οδηγιών που καταναλώνει το μικρό αριθμό τελεστών και παράγει ένα άθροισμα, το οποίο τοποθετείται στη σωρό. Ο ενδιαφερόμενος για το αποτέλεσμα της προσθήκης τότε βγάζει το αποτέλεσμα. Επιπλέον στη στοίβα, το bytecode φορματ ορίζει μέχρι 65,536 καταγραφές ή τοπικές μεταβολές. Μια εκτέλεση σε bytecode κωδικοποιημένη από μόνο ένα byte, έτσι το Java υποστηρίζει μέχρι 256 opcodes, από τα οποία απαιτούνται περισσότερες διαθέσιμες αξίες. Κάθε εκτέλεση έχει μια μοναδική bytecode αξία και ένα αναγνωρίσιμο από τον άνθρωπο μνημονικό. Note: Η μόνη καινούρια bytecode αξία που έχει προσδιοριστεί μέσα από την ιστορία του Java Virtual Machine όρο είναι το Oxba-εξαφανισμένο από πριν άλλα σχεδόν έτοιμο να χρησιμοποιηθεί σε καινούρια εκτέλεση invokedynamic. Αυτή η εκτέλεση μπορεί να χρησιμοποιηθεί για να εφαρμόσει δυναμική αποστολή, όταν μια δυναμική γλώσσα (όπως το Ruby) έχει συγκεντρωθεί στο Java bytecode. Γ ια περισσότερες πληροφορίες για τη χρήση Java bytecode για δυναμικές γλώσσες παρακαλώ παραπεμφθείτε στο Java Specification Request (JSR) 292 στο διαδίκτυο. Διάταξη Bytecode Θεωρήστε το παρακάτω παράδειγμα μιας μεθόδου add στο Java native κωδικό και μετά στη διάταξη bytecode του Java. Public int add (int a, int b) { Return a + b; } Public int adc (int, int ); Code: 0: iload_1 //stack: a 1: iload_2 //stack: a, b 2: iadd // stack: (a+b) 3: ireturn // stack: Οι παράμετροι εισόδου για τη μέθοδο add, a & b, περνούν στις υποδοχές 1&2 της τυπικής μεταβλητής (Υποδοχή 0 σε μια παραδειγματική μέθοδο προορίζεται για αυτό, σύμφωνα με το JVM όρο και αυτό το συγκεκριμένο παράδειγμα είναι παραδειγματική μέθοδος). Οι πρώτες δυο εφαρμογές, με opcode iload_1 & iload_2, σπρώχνουν τα περιεχόμενα από τις τοπικές μεταβλητές στη στοίβα αξιολόγησης. Η τρίτη εφαρμογή, iadd, πετάει τις δυο αξίες από τη στοίβα, τις προσθέτει και σπρώχνει το άθροισμα που προκύπτει. Η τετάρτη, και τελική εφαρμογή, ireturn, πετάει το άθροισμα από τη στοίβα του bytecode και τερματίζει τη μέθοδο χρησιμοποιώντας το άθροισμα ως επιστρεφόμενη αξία. Το bytecode στο προηγούμενο παράδειγμα σχολιαστεί με τα περιεχόμενα της στοίβας αξιολόγησης μετά από κάθε εφαρμογή που έχει εκτελεστεί. Note: Το bytecode για μια τάξη μπορεί να πεταχτεί με τη χρήση javap εντολής με την -c γραμμή εντολών του switch. Η εντολή javap είναι μέρος του JDK. 14

15 Λειτουργίες και τελεστές Όπως βλέπουμε, το Java bytecode είναι σχετικά συμπαγής μορφής η προηγούμενη μέθοδος που είναι μόνο για bytes σε μήκος (ένα κλάσμα του κωδικού μαζικής πηγής). Οι εφαρμογές πάντα είναι κωδικοποι ημένες με ένα byte για το opcode, που ακολουθείται από έναν προαιρετικό αριθμό των πράξεων του μεταβλητού μήκους. Τυπικά, μια bytecode οδηγία συμπληρωμένη με πράξεις είναι μόνο ένα στα τρία bytes. Εδώ είναι άλλο ένα μικρό παράδειγμα, μια μέθοδος που καθορίζει εάν ένας αριθμός είναι ζυγός ή όχι. Το bytecode έχει υποσημειωθεί με δεκαεξαδικές τιμές αντίστοιχες με τα opcodes και τελεστές δεδομένων. Public Boolean even (int number) { Return (number & 1) == 0; } Public Boolean even (int); Code: 0 iload_1 //0x1b number 1 iconst_1 //0x04 number, 1 2 iand //0x7e (number & 1) 3 ifne 10 //0x9a 0x00 0x07 6 iconst_1 //0x goto 11 //0xa7 0x00 0x04 10: iconst_0 //0x : ireturn //0xac Το πρόγραμμα σπρώχνει τα της παραμέτρου του αριθμό και σταθερή 1 στην στοίβα εκτίμησης. H ifne οδηγία είναι μια υποθετική διακλάδωση που πετάει τους τελεστές από τη στοίβα και από την διακλάδωση εάν δεν είναι μηδενικοί. Η iconst_0 εφαρμογή σπρώχνει το σταθερό 0 στη στοίβα εκτίμησης. Έχει την αξία opcode 0x3 σε bytecode και δεν παίρνει τελεστές. Με παρόμοιο τρόπο iconst_1 σπρώχνει το σταθερό 1. Τα σταθερά χρησιμοποιούνται για τη Boolean αξία επιστροφής. Σύγκριση και πέταγμα των οδηγιών, για παράδειγμα ifne (διακλάδωση μη ισότιμη 0x9a) γενικά παίρνει δυο bytes από τελεστή δεδομένων (αρκετά για ένα 16bit jump offset) Note: Για παράδειγμα, εάν μια μετάβαση υπό-ροής πρέπει να μετακινήσει τον δείκτη οδηγιών 10,000 bytes μπροστά σε περίπτωση αληθινής κατάστασης, η εκτέλεση θα κωδικοποιηθεί ως 0x9a 0x27 0x10 (0x2710 είναι 10,000 σε δεκαεξαδικό. Όλες οι αξίες σε bytecode είναι big-endian). Άλλες πιο πολύπλοκες κατασκευές όπως πίνακας διακοπτών υπάρχει επίσης σε bytecode με έναν ολόκληρο πινάκα μετάβασης των offset ακλουθώντας το opcode και το bytecode. The constant pool Ένα πρόγραμμα απαιτεί στοιχεία καθώς και έναν κωδικό. Τα δεδομένα αυτά χρησιμοποιούνται για τελεστές. Τα δεδομένα τελεστών για ένα bytecode πρόγραμμα μπορεί, όπως είδαμε να κρατηθεί στις οδηγίες bytecode καθ' αυτού. Αλλά αυτό ισχύει μόνο όταν τα δεδομένα είναι αρκετά μικρά ή συχνά χρησιμοποιούνται (όπως το σταθερό 0). Μεγάλα μέρη των δεδομένων, όπως σταθερά string ή μεγάλους αριθμούς, αποθηκεύονται σε constant pool στην αρχή του.class αρχείου. Δείκτες δεδομένων στο pool χρησιμοποιούνται ως τελεστές αντί για τα πραγματικά δεδομένα. Εάν το string averylongfunctionname έπρεπε να κωδικοποιηθεί χωριστά σε καταρτιζόμενη μέθοδο κάθε φορά που ήταν σε λειτουργία, το bytecode δεν θα ήταν συμβατό καθόλου. Επιπλέον αναφορές σε άλλα μέρη του Java προγράμματος σε μορφή μεθόδου είναι επίσης μέρος του.class αρχείου και αποθηκεύεται στο constant pool. 15

16 Κωδικός στρατηγικής παραγωγής Υπάρχουν αρκετοί τρόποι εκτέλεσης bytecode σε ένα JVM από απλή μίμηση των byte code της καθαρής διερμηνείας bytecode σε μετατροπή όλων σε native κωδικό για συγκεκριμένη πλατφόρμα. Διερμηνεία Pure byte code Τα πρώτα JVMs περιείχαν μόνο απλά bytecode διερμηνείες ως μέσο εκτέλεσης του κωδικού Java. Γ ια να απλοποιηθεί αυτό λίγο, ένας διερμηνέας bytecode είναι απλά μια κύρια λειτουργία με μεγάλη κατασκευή switch στα δυνατά opcodes. Η λειτουργία αυτή ονομάζεται με μια κατάσταση που εκπροσωπεί τα περιεχόμενα της αξιολόγησης σωρού της Java και τις τυπικές μεταβλητές. Η ερμηνεία λειτουργίας ενός bytecode χρησιμοποιεί αυτή την κατάσταση ως είσοδο και έξοδο. Τελικά, τα βασικά χαρακτηριστικά της εργασίας ενός διερμηνέα δεν θα πρέπει να ανέρχεται σε περισσότερο από δυο χιλιάδες γραμμές από κωδικούς. Υπάρχουν αρκετά οφέλη με τη χρήση μιας καθαρής διερμηνείας. Η παραγωγή κωδικού ενός JVM που διερμηνεύει πρέπει απλά να επανα-μεταγλωττιστεί για να υποστηρίξει την νέα αρχιτεκτονική του υλικού. Κανένας νέος native συλλέκτης δεν χρειάζεται να γραφτεί. Επίσης ένας native συλλέκτης για μόνο μια πλατφόρμα είναι πιθανών πιο μεγάλη από την απλή μας switch κατασκευή. Ένας αγνός διερμηνέας bytecode επίσης χρειάζεται λίγο καταστοιχογραφία. Ένα JVM που συλλέγει μερικές ή όλες τις μεθόδους του native κωδικού θα πρέπει να παρατηρεί όλους τους κωδικούς συλλογής. Εάν μια μέθοδος αλλαχτεί στη λειτουργία, το οποίο επιτρέπει η Java πρέπει να κανονιστεί εγγραφή καθώς ο παλιός κωδικός είναι απαρχαιωμένος. Σε έναν αγνό διερμηνέα τα καινούρια του bytecode απλά μεταγλωττίζουν ξανά από την αρχή την επόμενη φορά που εμείς θα επαναλάβουμε τη μέθοδο. Αυτό που προκύπτει είναι ότι ο αριθμός καταστοιχογραφίας σε ένα εντελώς μεταγλωττισμένο μοντέλο είναι ελάχιστο. Αυτό προσφέρεται να χρησιμοποιηθεί σε προσαρμοστική λειτουργία όπως το JVM, όπου τα πράγματα αλλάζουν συνεχώς. Φυσικά, υπάρχει μια σημαντική πηγή απόδοσης σε μια αγνή γλώσσα ερμηνείας κατά τη σύγκριση χρόνου εκτέλεσης της μεθόδου ερμηνείας με μια έκδοση native κωδικού του ίδιου κωδικού. Το Sun Microsystems's Class Virtual Machine ξεκίνησε ως μια αγνή ερμηνεία bytecode βάζοντας σε λειτουργία την προηγούμενη add μέθοδο, με τις 4 bytecode οδηγίες, μπορεί εύκολα να απαιτεί την εκτέλεση δέκα φορές περισσότερων native οδηγιών σε μετατροπέα γραμμένο στο C. Ενώ, μια native εκδοχή είναι μόνο δυο οδηγίες συναρμολόγησης (add & return). Int evaluate (int opcode, int* stack, int* localvars) { Switch (opcode) { Case iload_1: Case iload_2: Int Lslot = opcode - iload_1; Stack [sp++] = localvars [lslot]; Break; Case ireturn; Return stack [--sp]; ' ' } } Το προηγούμενο παράδειγμα δείχνει από pseudo κωδικό για ένα διερμηνέα bytecode με μόνο αρκετή λειτουργικότητα να εκτελέσει την μέθοδο μας add. Ακόμα και αυτός ο απλός κωδικός μικρής πληροφορίας ανέρχεται σε δεκάδες οδηγίες συναρμολόγησης του native που συγκεντρώνονται στο JVM. Εκτιμώντας ότι μια native καταρτιζόμενη έκδοση της μεθόδου add θα είναι μόνο δυο οδηγίες, αυτό δείχνει το πρόβλημα απόδοσης με επεξήγηση αγνού bytecode. 16

17 JIT συλλογή της μεθόδου add στο x86 μας παράγει: Add eax, edx Ret // eax= edx + eax //return eax Note: Σημειώστε ότι αυτό το βιβλίο μερικές φορές θα δείχνει παράδειγμα κωδικού συγκροτήματος σε ορισμένα σημεία για να δείχνουν κάποια σημεία. Καμία προηγούμενη γνώση κωδικού συγκροτήματος σε καμία πλατφόρμα δεν χρειάζεται να αποκομίσουν τα πλήρη οφέλη των κειμένων. Ωστόσο η γενική ιδέα του χαμηλού επιπέδου γλωσσών θα έπρεπε να είναι γνωστή στον αναγνώστη. Εάν αισθάνεσαι αβεβαιότητα στις λίστες του συγκροτήματος που εμφανίζονται σε ορισμένα σημεία του κειμένου μην ανησυχείς. Δεν τα χρειάζεσαι για να καταλάβεις την γενική εικόνα. Στατική Μεταγλώττιση Στις αρχές του Java, αρκετά απλές «brute force» προσεγγίσεις έγιναν για να περιηγηθείς γύρο από τα προβλήματα απόδοσης. Αυτές συνήθως συμπεριλάμβαναν τη στατική μεταγλώττιση σε κάποιες μορφές. Συνήθως, ένα ολόκληρο πρόγραμμα Java είχε συνταχθεί σε native κωδικό πριν την εκτέλεση. Αυτό είναι γνωστό ως εν όψει του χρόνου κατάρτισης. Βασικά σημαίνει ότι το κάνει ο μέσος C++ συλλέκτης συνέχεια. Ως ένα μικρό υπό-σύνολο του προβλήματος της στατικής κατάρτισης για τη Java είναι εύκολο να λυθεί, μια σειρά από προϊόντα εμφανίστηκαν στα τέλη του 1990, χρησιμοποιώντας μεθοδολογίες όπως η αλλαγή των byte codes σε native C κωδικούς και μετά το πέρασμα τους στο C συλλέκτη. Τ ις πιο πολλές φορές ο αποτελεσματικός κωδικός λειτουργούσε πολύ πιο γρήγορα από αγνά μεταγλωττισμένο bytecode. Ωστόσο, αυτού του είδους τα προϊόντα σπάνια υποστήριζαν την ολική δυναμική φύση της Java γλώσσας και δεν ήταν ικανά να αντιμετωπίσουν τα πράγματα όπως κωδικούς που αντικαθιστούνταν στη λειτουργία χωρίς πολλές λύσεις. Τα εμφανή μειονεκτήματα της στατικής κατάρτισης για τη Java είναι ότι τα οφέλη της ανεξαρτήτως πλατφόρμας εμφανίζονται στιγμιαία. Το jvm αφαιρείται από την εξίσωση. Άλλο μειονέκτημα είναι η μνήμη αυτόματης διαχείρισης της Java που πρέπει να χειριστεί με περισσότερη ή λιγότερη σαφήνεια, που οδηγεί σε περιορισμένη υλοποίηση με δυνατότητα κλιμάκωσης ζητημάτων. Καθώς η Java κινήθηκε όλο και πιο κοντά στις εφαρμογές server, όπου η δυναμική της φύση χρησιμοποιήθηκε ακόμα περισσότερο, οι στατικές λύσεις έγιναν αδύνατες. Γ ια παράδειγμα, μια εφαρμογή στο server που παρήγαγε αρκετές σελίδες Java server (JSP) στην πράξη μειώνει έναν στατικό συλλέκτη σε ένα JIT συντάσσοντας JVM, πιο αργά και λιγότερο προσαρμοσμένα. Note: σημειώστε ότι η στατική των λύσεων εν όψει του χρόνου, ενώ είναι ακατάλληλη για την εκτέλεση της Java μπορεί να είναι χρήσιμο σε ορισμένες άλλες καταστάσεις, για παράδειγμα ahead-of-time ανάλυση. Το πρόγραμμα ανάλυσης είναι χρονοβόρα εκτέλεση. Εάν κάποιο μέρος της μπορεί να γίνει εκτός σύνδεσης πριν την εκτέλεση του προγράμματος, και μεταβιβαζόμενο στο JVM, μπορεί να υπάρχουν οφέλη απόδοσης. Γ ια παράδειγμα,.class αρχεία μπορεί να σχολιάζονται με εκτός σύνδεσης κατανομές δεδομένων, ίσως με τη μορφή της Java Annotations. 17

18 Συνολική JIT κατάρτιση Άλλος ένας τρόπος για να επιταχυνθεί η bytecode εκτέλεση είναι να μην χρησιμοποιηθεί καθόλου διερμηνέας, και το JIT συντάσσει όλες τις μεθόδους στο native κωδικό αμέσως μόλις συναντηθούν. Η κατάρτιση παίρνει μέρος σε ώρα λειτουργίας μέσα στο JVM, όχι από πριν. Αντίθετα εντελώς με τη στατική εν όψει χρόνου κατάρτισης, η fly συλλογή ταιριάζει καλύτερα στο μοντέλο Java με μια κινητή προσαρμοστική γλώσσα. Η συμβολική JIT κατάρτιση έχει το πλεονέκτημα το ότι δεν είναι ανάγκη να διατηρούμε διερμηνέα αλλά το μειονέκτημα είναι ότι η ώρα συλλογής γίνετε παράγοντας στη συνολική λειτουργία. Ενώ σίγουρα βλέπουμε οφέλη στη συλλογή JIT hot μέθοδο, επίσης ξοδεύουμε περιττή πολύτιμη ώρα συλλογής σε cold μεθόδους και μεθόδους που λειτουργούν μόνο μια φορά. Αυτές οι μέθοδοι θα μπορούσαν άνετα να μεταγλωττιστούν. Note: Μια συχνή μέθοδος εκτέλεσης ονομάζεται hot. Μια μέθοδος που δεν εκτελείτε συχνά και δεν μοιράζεται στη συνολική απόδοση του προγράμματος ανεξάρτητα από την εκτέλεση ονομάζεται cold. Αυτό μπορεί να διορθωθεί με την εφαρμογή διαφορετικών επιπέδων της ποιότητας του συλλέκτη στον JIT συλλέκτη, ξεκινώντας με κάθε μέθοδο ως γρήγορη και βρόμικη έκδοση. Όταν το jvm γνωρίζει πως η μέθοδος είναι hot, για παράδειγμα εάν ο αριθμός επικλήσεων της μεθόδου φτάσει σε ορισμένα παράθυρα αξίας, μπορεί να μπει στη σειρά για επενακατάρτηση με πιο εφαρμοσμένες βελτιστοποιήσεις. Αυτό φυσικά είναι πιο χρονοβόρο. Το κύριο μειονέκτημα της συνολικής συλλογής του JIT είναι ακόμα η χαμηλή ταχύτητα παραγωγής κωδικού. Με τον ίδιο τρόπο που μια μέθοδος ερμηνείας εκτελεί εκατοντάδες φορές πιο αργά από τον native, μια native μέθοδος που πρέπει να παραχθεί από τους Java byte codes παίρνει εκατοντάδες φορές πιο πολύ για να ετοιμαστεί για εκτέλεση από μια μέθοδο ερμηνείας. Ο μηχανισμός που εντοπίζει hot μεθόδους πρέπει να είναι πραγματικά πολύ προηγμένος. Ακόμα και ένας γρήγορος και βρώμικος JIT συλλέκτης είναι σημαντικά πιο αργός στο να ετοιμάσει κωδικούς για εκτέλεση από έναν αγνό διερμηνέα. Ο διερμηνέας ποτέ δεν χρειάζεται να μεταφράσει byte codes σε οτιδήποτε άλλο. Ένα άλλο θέμα που γίνετε πιο σημαντικό με συνολική JIT σύνταξη είναι τα μεγάλα ποσά από άχρηστους κωδικούς που παράγονται. Εάν μια μέθοδος αναπαραχθεί, για παράδειγμα αφού οι υποθέσεις που έγιναν από το συλλέκτη δεν είναι πλέον έγκυρες, ο παλιός κωδικός πιάνει πολύτιμη μνήμη. Το ίδιο ισχύει για μια μέθοδο που έχει βελτιστοποιηθεί. Έτσι το JVM απαιτεί κάποιο είδος περισυλλογής απορριμμάτων για παραγωγή κωδικού ή ένα σύστημα με μεγάλα ποσά από JIT συλλογής που σιγά θα ξεμείνει από native μνήμη καθώς μεγαλώνει ο ρυθμιστικός κωδικός. Το JRockit είναι ένα παράδειγμα ενός JVM που χρησιμοποιεί μια εξελιγμένη παραλλαγή από συνολική συλλογή JIT ως στρατηγική κωδικού παραγωγής. Μεικτή λειτουργία επεξήγησης Η πρώτη πρακτική λύση που προτάθηκε, και που θα αύξανε την ταχύτητα εκτέλεσης και δεν θα συμβιβαζόταν με τη δυναμική φύση της Java ήταν η μεικτή λειτουργία επεξήγησης. Σε JVM που χρησιμοποιεί μεικτή λειτουργία επεξήγησης όλες οι μέθοδοι ξεκινούν ως ερμηνείες όταν πρώτοσυναντιούνται. Ωστόσο, όταν μια μέθοδος βρίσκετε να είναι hot, προγραμματίζεται για JIT σύνταξη και στρέφεται ως έναν πιο αποτελεσματικό native κωδικό. Αυτή η προσαρμοστική προσέγγιση είναι παρόμοια με εκείνη του να κρατάς διαφορετικές ποιότητας επίπεδα κωδικού στο JIT, που περιγράφεται σε προηγούμενο τμήμα. 18

19 Η ανίχνευση hot μεθόδου είναι μια θεμελιώδη λειτουργικότητα κάθε σύγχρονου JVM, ανεξάρτητα από το μοντέλο κωδικού εκτέλεσης, και θα καλυφτεί σε μεγαλύτερο βαθμό σ'αυτό το κεφάλαιο. Οι πρώτοι μεικτοί διερμηνείς λειτουργίας συνήθως ανίχνευαν την hotness μιας μεθόδου μετρώντας τον αριθμό των φορών της επίκλησης. Εάν αυτός ο αριθμός ήταν αρκετά μεγάλος, η βελτιστοποίηση JIT σύνταξης θα ενεργοποιούνταν για τη μέθοδο. Παρόμοιο με τη συνολική JIT σύνταξη, εάν η διαδικασία προσδιορισμού εάν η μέθοδος είναι hot είναι αρκετά καλή, το JVM ξοδεύει χρόνο σύνταξης μόνο στις μεθόδους όπου κάνει τη μεγίστη διαφορά. Εάν μια μέθοδος σπανία εκτελείται το JVM δεν θα ξόδευε χρόνο στο να αλλάξει σε native κωδικό αλλά προτιμά να την μεταφράζει κάθε φορά που καλείται Η καταστοιχογραφία του JIT κωδικού είναι απλό πρόβλημα με μεικτό τρόπο επεξήγησης. Εάν μια εκδοχή από μια μέθοδο συλλογής πρέπει να αναπαραχθεί ή μια υπόθεση ακυρώνεται, ο κωδικός του απορρίπτετε. Την επόμενη φορά που καλείται η μέθοδος πάλι θα γίνει επεξήγηση. Εάν η μέθοδος είναι ακόμα hot, τελικά θα ξανάμεταγλωττιστεί με το αλλαγμένο μοντέλο ενσωματωμένου κόσμου. Note: Η Sun Microsystems ήταν ο πρώτος προμηθευτής που αναγνώρισε την επεξήγηση μεικτών λειτουργιών στο HotSpot συλλέκτη, διαθέσιμο και σε έκδοση πελάτη και σε πλάγια έκδοση server κωδικού, το δεύτερο με πιο προηγμένο κωδικό βελτιστοποίησης. Το HotSpot με τη σειρά του, βασίζοντας στην απαραίτητη τεχνολογία από της Longview Technologies LLC (που ξεκίνησαν ως Anamorphic). Προσαρμοστική παραγωγή κωδικού Η Java είναι δυναμική από τη φύση της και ορισμένες στρατηγικές παραγωγές κωδικού είναι πιο κατάλληλες από άλλες. Από την προηγούμενη αναφορά, τα παρακάτω συμπεράσματα μπορεί να προκύψουν: Η παραγωγή κώδικα πρέπει να γίνει σε χρόνο λειτουργίας όχι πριν από αυτόν. Όλες οι μέθοδοι δεν μπορούν να συμπεριφερθούν ισότιμα από την παραγωγή κωδικού. Πρέπει να υπάρξει ένας τρόπος να διακριθεί μια Hot από μια cold μέθοδο. Αλλιώς μη-απαραίτητες προσπάθειες βελτιστοποίησης ξοδεύονται στην cold μέθοδο, η ακόμα χειρότερα δεν γίνονται αρκετές προσπάθειες βελτιστοποίησης για την hot μέθοδο. Σε ένα JIT συλλέκτη, η καταστοιχογραφία πρέπει να βρίσκετε παρόν προκειμένου να συμβαδίσει με τον προσαρμοστικό χρόνο λειτουργίας. Αυτό είναι επειδή η παραγωγή του native κωδικού εισβάλετε από αλλαγές στο πρόγραμμα λειτουργίας, πρέπει να αποβάλλετε και δυνητικά να αναπαράγεται. Η επίτευξη της εκτέλεσης αποδοτικότητας κωδικού σε προσαρμοστικό χρόνο λειτουργίας, χωρίς να έχει σημασία τι JIT ή στρατηγική ερμηνεία χρησιμοποιεί, όλα καταλήγουν στην εξίσωση: Συνολικός χρόνος εκτέλεσης = κωδικό παράγωγης χρόνου + χρόνο εκτέλεσης Με αλλά λόγια, εάν ξοδέψουμε πολύ προσπάθεια στην προσεκτική παραγωγή και βελτιστοποίηση κάθε μεθόδου για να σιγουρευτούμε ότι θα γίνει ένας αποτελεσματικός native κωδικός, συνεισφέρουμε πολύ ώρα παραγωγής κωδικού στο χρόνο συνολικής εκτέλεσης. Εμείς θέλουμε το JVM να εκτελέσει το Java κωδικό μας σε κάθε διαθέσιμο χρόνο όχι να χρησιμοποιούμε ακριβούς κύκλους χρόνου για να συλλέγουμε απορρίμματα ή να παράγουμε κωδικό. Εάν περάσουμε πολύ λίγο χρόνο στην προετοιμασία μεθόδων για εκτέλεση η επίδοση του χρόνου λειτουργίας είναι πολύ πιθανών να είναι κακή και έτσι συμβάλλει σε πάρα πολλούς ανεπαρκείς κύκλους στο συνολικό χρόνο εκτέλεσης. Το JVM πρέπει να γνωρίζει ακριβώς ποιες μέθοδοι αξίζουν την επιπλέον ώρα που ξοδεύετε σε πιο επεξεργάσιμο κωδικό παραγωγής και προσπάθειες βελτιστοποίησης. Υπάρχον φυσικά και άλλες απόψεις της συνολικής ώρας εκτέλεσης, όπως η ώρα που ξοδεύεται στη συλλογή απορριμμάτων. Αυτό, ωστόσο, είναι περά από το σκοπό αυτού του κεφαλαίου και θα το καλύψουμε με περισσότερες λεπτομέρειες στο κεφάλαιο της διαχείρισης μνήμης. Εδώ είναι αρκετό να αναφερθεί ότι ο κωδικός βελτιστοποίησης μερικές φορές μπορεί να βοηθήσει στη μείωση περισυλλογής απόβλητων εξαρχής με την παραγωγή επαρκούς κωδικού, που δεσμεύετε λιγότερη μνήμη. Ένα παράδειγμα θα ήταν η εφαρμογή ανάλυσης διαφυγής, η οποία καλύπτεται σε συντομία σε αυτό το κεφάλαιο. 19

20 Προσδιορισμός Hotness Όπως έχουμε δει ένα μέγεθος παραγωγής κωδικού που ερμηνεύει κάθε μέθοδο ή το JIT συλλέγοντας κάθε μέθοδο με υψηλό επίπεδο βελτιστοποίησης είναι κακή ιδέα σε προσαρμοστικό χρόνο λειτουργίας. Το πρώτο, επειδή παρ' ολ' αυτά κρατάει το χρόνο παραγωγής κωδικού χαμηλά, ο χρόνος εκτέλεσης πάει πολύ ψηλά. Το δέντρο, επειδή ακόμα κι αν η εκτέλεση είναι γρήγορη, η παραγωγή του μέγιστου κωδικού βελτιστοποίησης παίρνει ένα μεγάλο μέρος του σημαντικού χρόνου λειτουργίας. Πρέπει να ξέρουμε εάν μια μέθοδος είναι hot ή όχι για να ξέρουμε εάν θα έπρεπε να της δώσουμε πολύ προσοχή παραγωγής κωδικού, καθώς δεν μπορούμε να μεταχειριστούμε όλες τις μεθόδους το ίδιο. Δημιουργώντας προφίλ για να προσδιορίσουμε το hotness μπορεί, όπως υπαινίχτηκε στα προηγούμενα τμήματα, να εκτελεστεί με διάφορους τρόπους δημιουργίας προφίλ είναι ότι ένας αριθμός από δείγματα από όπου ο κωδικός ξοδεύει χρόνο εκτέλεσης συλλογής. Αυτά χρησιμοποιούνται από το χρόνο λειτουργίας για να παρθούν αποφάσεις βελτιστοποίησης - όσο περισσότερα δείγματα είναι διαθέσιμα, τόσο καλύτερα ενημερωμένες αποφάσεις παίρνονται. Μόνο μερικά απομονωμένα δείγματα σε διαφορετικές μεθόδους δεν θα μας πουν και πολλά για το προφίλ εκτέλεσης ενός προγράμματος. Φυσικά, στη συλλογή δειγμάτων πάντα προκύπτουν ορισμένα overhead από μόνα τους, και υπάρχει δίλημμα ανάμεσα στο να υπάρχουν αρκετά δείγματα και το overhead να τα συλλέξει. Μετρητές Επίκλησης Ένας τρόπος για το δείγμα μεθόδου hot είναι να χρησιμοποιήσεις μετρητές επίκλησης. Ένας μετρητής επίκλησης συνήθως συνδέεται με κάθε μέθοδο και αυξάνεται όταν η μέθοδος είναι σε ζήτηση. Αυτό γίνετε είτε από το bytecode ερμηνευτή ή σε μορφή επιπλέων add οδηγία συλλογής στον πρόλογο της εκδοχής του native κωδικού της μεθόδου. Ειδικά στον JIT κόσμο συλλογής όπου η ταχύτητα εκτέλεσης κωδικού δεν εμφανίζεται σε διερμηνεία overhead, μετρητές επίκλησης μπορεί να υποστούν κάποιον ορατά overhead χρόνο λειτουργίας, συνήθως με τη μορφή cache στο CPU. Αυτό γίνεται επειδή μια συγκεκριμένη λειτουργία στη μνήμη πρέπει συχνά να γράφεται από το add στην αρχή κάθε μεθόδου. Δείγματα Λογισμικού (Thread) Ένα άλλο, πιο φιλικό cache, τρόπο να προσδιοριστεί το hotness είναι με thread δείγματα. Αυτό σημαίνει περιοδική εξέταση, όπου στο πρόγραμμα Java threads προς το παρόν εκτελούνται και συνοδεύουν τους δείκτες εντολών. Η δειγματοληψία thread δεν απαιτεί κωδικό ενοργάνισης. Η παύση των threads η οποία φυσικά απαιτείται για να αποσπάσεις τα συμφραζόμενα είναι, ωστόσο, αρκετά ακριβή επιχείρηση. Έτσι, το να παίρνεις μεγάλο αριθμό από δείγματα χωρίς να διασπάς τίποτα απαιτεί ολοκληρωμένο JVM - εσωτερική thread εκτέλεση, είναι συνηθισμένο σύστημα λειτουργίας όπως το Oracle JRockit Virtual Edition ή ειδική υποστήριξη υλικού. Δείγματα Υλικού Ορισμένες πλατφόρμες υλικού, όπως η Intel Ian-64, παρέχουν ενόργανους υλικούς μηχανισμούς που μπορεί να χρησιμοποιηθούν από μια εφαρμογή. Ένα παράδειγμα είναι τα υλικά του IP δείγμα ρυθμιστή. Ενώ η παραγωγή κωδικού για το IA-64 είναι αρκετά περίπλοκη δουλειά τουλάχιστον η αρχιτεκτονική του υλικού επιτρέπει την περισυλλογή ενός μεγάλου αριθμού δειγμάτων φτηνά, έτσι διευκολύνει την καλύτερη απόφαση βελτιστοποίησης. Άλλο ένα όφελος του δείγματος υλικού είναι ότι μπορεί να παρέχει κι άλλα δεδομένα, όχι μόνο δείκτες οδηγιών, φτηνά. Γ ια παράδειγμα, οι profilers υλικού μπορούν να εξάγουν δεδομένα με το πόσο συχνά ένα κλαδί υλικού προεπιλέγουν να κάνει λανθασμένη υπόθεση, ή στο πόσο συχνά το CPU caches αποτυγχάνουν σε συγκεκριμένες τοποθεσίες. Ο χρόνος λειτουργίας μπορεί να χρησιμοποιήσει αυτές τις πληροφορίες για να παράγει πιο βέλτιστο κωδικό. Αναστρέφοντας την κατάσταση του άλματος οδηγίας που προκάλεσε την αστοχία του κλάδου πρόγνωσης και την πρόωρη λήψη των οδηγιών που αστόχησε το cache έλυνε αυτά τα προβλήματα. Έτσι, επαρκή δείγματα βασισμένα στα υλικά μπορεί να σαρώσει άριστα προεργασία για την περαιτέρω προσαρμογή κωδικού βελτιστοποίησης στο χρόνο λειτουργίας. 20

21 Η Βελτιστοποίηση σε πρόγραμμα αλλαγής Σε κωδικό συναθροίσματος οι κλήσεις μεθόδων τυπικά καταλήγουν ως κλήσεις οδηγιών. Οι παραλλαγές αυτές υπάρχουν σε όλες τις αρχιτεκτονικές υλικού, το φορματ της κλήσης οδηγίας διαφέρει ανάλογα με τον τύπο της κλήσης. Σε γλώσσες προσανατολισμένες σε αντικείμενα, μεθόδους virtual αποστολής συνήθως καταρτίζονται ως έμμεσες κλήσεις (όπου σημαίνει ότι ο προορισμός πρέπει να διαβαστεί από τη μνήμη) σε διευθύνσεις σε αποστολή πίνακα. Αυτό γίνετε επειδή η virtual κλήση μπορεί να έχει αρκετούς πιθανούς δέκτες ανάλογα με την τάξη ιεραρχίας. Ένας πίνακας αποστολής υπάρχει για κάθε τάξη και περιέχει δέκτες των virtual κλήσεων. Μια στατική μέθοδος ή virtual μέθοδος που είναι γνωστό ότι έχει μόνο μια εκτέλεση μπορεί σε αντικατάσταση να μετατραπεί σε απευθείας κλήση με σταθερό προορισμό. Αυτό είναι τυπικά πιο γρήγορο στην εκτέλεση. Note: Στον native κωδικό, η στατική κλήση θα μοιάζει με: Call 0x (με ένα άλμα σε σταθερή τοποθεσία) Μια virtual κλήση θα μοιάζει με: Mov eax, [eax + 0x4c] (eax + 0x4c είναι η είσοδος του πίνακα αποστολής) Καθώς έχουμε μη-αναφορά μνήμης δυο φορές για την virtual κλήση, είναι πιο αργή από την κλήση σε μια διεύθυνση σταθερού προορισμού. Θεωρήστε ένα στατικό περιβάλλον, όπως ένα πρόγραμμα συλλογής C++. Για την παραγωγή κωδικού, ότι μπορεί να είναι γνωστό για την εφαρμογή γίνετε γνωστό την ώρα συλλογής. Γ ια παράδειγμα, γνωρίζουμε ότι όποια δεδομένη μέθοδος παραγωγής με μόνο μια εκτέλεση πότε δεν θα καταπατηθεί από άλλη, απλά επειδή δεν υπάρχει άλλη virtual μέθοδος. Νέος κωδικός δεν μπορεί να εισβάλει στο σύστημα, έτσι ο καταπατητής επίσης δεν θα υπάρξει ποτέ. Αυτό όχι μόνο αφαιρεί την ανάγκη από έξτρα καταστοιχογραφία που απαιτείται για την αφαίρεση του παλιού κωδικού, αλλά επίσης επιτρέπει το C++ συλλέκτη να παράγει στατικές κλήσεις στην virtual μέθοδο. Τώρα, λάβετε υπ' όψιν σας την ίδια virtual μέθοδο σε πρόγραμμα Java. Αυτή τη στιγμή αυτό υπάρχει σε μια μόνο εκδοχή, αλλά η Java επιτρέπει να καταπατηθεί οποιαδήποτε στιγμή κατά τη διάρκεια εκτέλεσης προγράμματος όταν ο συλλέκτης JIT θέλει να παράγει μια κλήση σ'αυτή τη μέθοδο, θα προτιμούσε η μέθοδος να παραμείνει σε ενιαία εκτέλεση για πάντα. Τότε, η προηγούμενη C++ βελτιστοποίηση μπορεί να παραχθεί ως γρήγορη σταθερή κλήση αντί για μια αργή virtual αποστολή. Ωστόσο εάν η μέθοδος δεν κηρυχτεί τελική, μπορεί να καταπατηθεί οποιαδήποτε στιγμή. Φαίνεται πως ούτε τολμούμε να χρησιμοποιήσουμε άμεση κλήση καθόλου, ακόμα και αν είναι απίθανο ότι η μέθοδος να μπορεί να καταπατηθεί. Υπάρχουν ένα σορό από άλλες καταστάσεις στη Java όπου ο κόσμος μοιάζει καλός τώρα στον συλλέκτη, και βελτιστοποιήσεις μπορούν να εφαρμοστούν, αλλά εάν ο κόσμος αλλάξει στο μέλλον, οι βελτιστοποιήσεις θα πρέπει να επανα-στραφούν αμέσως. Γ ια σύλλεξη Java, για να ταιριάξει η συλλογή C++ σε ταχύτητα, θα πρέπει να υπάρχει τρόπος να γίνουν αυτού του είδους οι βελτιστοποιήσεις οπωσδήποτε. Το JVM το λύνει αυτό με χαρτοπαίγνιο. Βασίζει την απόφαση της παραγωγής κωδικού σε υποθέσεις ότι ο κόσμος θα μείνει αμετάβλητος για πάντα, η οποία συνήθως είναι η περίπτωση. Εάν καταλήξει να μην είναι έτσι, το σύστημα λογιστικής διεγείρει επανα-κλήσεις εάν υπάρξει παραβίαση υπόθεσης. Όταν συμβαίνει αυτό, ο κωδικός που περιέχει την αρχική υπόθεση πρέπει να αναπαραχθεί - στο δικό μας παράδειγμα η στατική αποστολή πρέπει να αντικατασταθεί με μια virtual. Έχοντας παράγει έναν κωδικό επαναφοράς βασιζόμενο στην υπόθεση για έναν κλειστό κόσμο τυπικά είναι πολύ δαπανηρό, αλλά εάν συμβαίνει, αρκετά σπάνια, το όφελος της αρχικής υπόθεσης θα διανέμει μια αύξηση εκτέλεσης έτσι κι αλλιώς. 21