PL193009B1 - Sposób wprowadzania nowego kodu do systemu przetwarzania Java z modyfikowaną pulą stałą - Google Patents

Abstract

1. Sposób wprowadzania nowego kodu do systemu przetwarzania Java z modyfikowana pula stala, w którym za pomoca interpetera opartego na stosie wykonuje sie pakiet zawie- rajacy kody posrednie i struktury klas, zna- mienny tym, ze laczy sie wewnetrznie nowy kod z pakietem istniejacym w systemie, przy czym przesuniecie adresowe nowego kodu wzgledem niego samego zastepuje sie przez odniesienie znane dopiero w czasie laczenia, okresla sie lacza zewnetrzne przy uzyciu iden- tyfikatorów jako indeksów w puli stalej pakietu i usuwa sie z puli stalej przynajmniej informa- cje, która stosowano do zastapienia przez od- niesienia znane dopiero w czasie laczenia. PL PL PL

Description

Opis wynalazku

Przedmiotem wynalazku jest sposób wprowadzania nowego kodu do systemu przetwarzania Java z modyfikowaną pulą stałą, przez dynamiczne ładowanie i łączenie kodu w środowisku przetwarzania języka Java z ograniczeniami zasobów.

Java jest językiem programowania i środowiskiem opracowanym przez firmę Sun Microsystems z USA. Wyczerpujące omówienie języka Java i jego implementacji jest przedstawione przez J. Goslina, B. Joya i G. Tele'a w publikacji „The Java Language Specification” - Opis języka Java oraz T. Lindholma i F. Yellina w publikacji „The Java Virtual machinę Specification” - Opis maszyny wirtualnej Java.

W znanym systemie Java, odniesienia do struktur klas wewnętrznych i zewnętrznych są określane przy użyciu przeglądania pośredniego nazw przez tak zwaną pulę stałą. Takie podejście stosuje się tylko w systemie zapewniającym zasoby dostateczne pod względem mocy przetwarzania i zasobów wewnętrznych.

W systemie przetwarzania z ograniczonymi zasobami, na przykład JavaCard, to podejście nie jest zadawalające. Zamiast tego stosuje się określanie odniesienia do struktur klas, unikając pośrednictwa i konieczności utrzymywania puli stałej. Określanie odniesień ma znaczenie przy łączeniu.

Sposób według wynalazku charakteryzuje się tym, że łączy się wewnętrznie nowy kod z pakietem istniejącym w systemie, przy czym przesunięcie adresowe nowego kodu względem niego samego zastępuje się przez odniesienie znane dopiero w czasie łączenia, określa się łącza zewnętrzne przy użyciu identyfikatorów jako indeksów w puli stałej pakietu i usuwa się z puli stałej przynajmniej informację, którą stosowano do zastąpienia przez odniesienia znane dopiero w czasie łączenia.

Korzystnie z puli stałej usuwa się również informację stosowaną do łączenia pakietów zewnętrznych.

Korzystnie za pomocą informacji pozostałej w puli stałej udostępnia się innym pakietom i apletom, które ładuje się później, poprawnie nowy kod i późniejsze wiązanie kodu.

Korzystnie jako system przetwarzania Java stosuje się system przetwarzania JavaCard.

Zaletą wynalazku jest osiągnięcie skutecznego łączenia w środowisku przetwarzania języka Java z ograniczeniami zasobów, szczególnie w odniesieniu do przestrzeni i czasu.

Przedmiot wynalazku jest pokazany w przykładach wykonania na rysunku, na którym fig. 1 przedstawia łączenie przy użyciu formatu pliku CAP proponowanego przez JavaSoft, fig. 2 - łączenie przez przesunięcie adresowe przy użyciu formatu pakietu według wynalazku i fig. 3 - łączenie przez nazwę przy użyciu formatu pliku według wynalazku.

Fig. 1 i 2 przedstawiają łączenie przy użyciu formatu pliku CAP czyli formatu programowania wspomaganego komputerowo oraz według wynalazku. Zastosowano maszynę wirtualną JavaCard, która różni się od maszyny wirtualnej Java pod kilkoma względami, ponieważ stosuje tylko pewien podzbiór i dodatkowe kody pośrednie.

Propozycja formatu pliku CAP JavaSoft polega na tym, że format pliku CAP dzieli plik CAP na kilka sekcji. Plik CAP zawiera ogólnie sekcję tekstową i sekcję danych. Sekcja tekstowa zawiera struktury klas, struktury metod i rozkazy kodu pośredniego. Sekcja danych zawiera pola statyczne subarkusza.

Sekcja tekstowa odnosi się do wszystkich symboli - klas, metod, itp., których rzeczywiste adresy nie są znane przed momentem połączenia za pośrednictwem przesunięcia adresowego w puli stałej. Dla każdego takiego symbolu pula stała zawiera identyfikator AID dla pakietu docelowego i przesunięcie adresowe symbolu w tym pakiecie docelowym, to znaczy pakiecie dołączonym. Pula stała zapewnia przesunięcia adresowe dla wszystkich symboli importowanych, to jest symboli zdefiniowanych w innych pakietach i dla wszystkich symboli eksportowanych, to jest symboli zdefiniowanych i dostępnych w ładowanym subarkuszu.

Organizacja sekcji tekstowej, sekcji danych i puli stałej zapewnia informację dostateczną do wykonania subarkusza. Po załadowaniu subarkusza program łączący jest w stanie przechodzić krokami przez pulę stałą i zastępować przesunięcia adresowe symboli pakietami docelowymi z rzeczywistymi adresami. Program łączący musi po prostu przejrzeć specyficzny pakiet według danego identyfikatora AID, dodać adres początkowy do przesunięcia adresowego symbolu i zapamiętać tę informację z powrotem wpuli stałej. Maszyna wirtualna JavaCard stosuje adresy w puli stałej do interpretacji. Jednak sama pula stała nie jest potrzebna w czasie przetwarzania. W rzeczywistości dla znalezienia adresu symbolu podczas interpretacji żąda ona jednej dodatkowej, niekoniecznej drogi pośredniej.

PL 193 009 B1

Ponadto pula stała zajmuje niepotrzebnie przestrzeń na arkuszu. Format pliku CAP JavaSoft stosuje zatem tablice uporządkowania dla poszczególnych sekcji do usuwania żądania z puli stałej po połączeniu. Tablica uporządkowania zawiera w sekcji tekstowej wszystkie pozycje, w których nastąpiła relokacja. Program łączący przechodzi krokami przez tablicę uporządkowania i pobiera przesunięcie adresowe pozycji wpuli stałej, a następnie ustala adres tego symbolu i zapamiętuje go w pozycji pierwotnej w sekcji tekstowej. Interpreter stosuje wtedy bezpośrednio adresy w czasie przetwarzania, a pulę stalą po procesie łączenia usuwa się. Po procesie łączenia na arkuszu pozostaje jedynie sekcja tekstowa i sekcja danych.

Łączenie subarkuszy z obliczonymi wstępnie lub kodowanymi sprzętowo przesunięciami adresowymi w pakiety docelowe zapewnia zwartość systemu, jednak nie zapewnia elastyczności dostatecznej do umożliwienia różnych implementacji klas systemowych i specyficznych rozszerzeń na różnych arkuszach. Na przykład jest mało prawdopodobne, aby subarkusz, który został poddany konwersji względem klas systemowych IBM i rozszerzenia JavaSoft, działał na arkuszu z subarkuszem systemowym JavaSoft i subarkuszem pochodzącym z IBM. Podstawowym tego powodem jest to, że przesunięcia adresowe poszczególnych klas, metod i przesunięcia adresowe pól różnią się dla różnych implementacji.

Wynalazek rozciąga się na idee aktualnej propozycji JavaSoft i wzbogaca je o dodatkowy nieskomplikowany i elastyczny, symboliczny mechanizm łączenia.

Format pliku CAP według wynalazku również dzieli plik CAP na różne sekcje. Sekcja tekstowa zawiera struktury klas, struktury metod i rozkazy kodu pośredniego, natomiast sekcja danych - pola statyczne. Plik CAP w tablicach uporządkowania przechowuje również niezbędną informację relokacji. Dla każdego pakietu, do którego jest dołączany subarkusz, to znaczy dla pakietu docelowego, występuje jedna tablica uporządkowania.

Tablica uporządkowania zawiera z kolei pozycję w sekcji tekstowej lub danych, w której ma nastąpić relokacja. W prostym przypadku miejsca te są również przemieszczane o wartość wstępnie obliczonego przesunięcia adresowego do sprawdzonych i znanych pakietów docelowych. W tym przypadku program łączący przegląda adres początkowy pakietu o danym identyfikatorze docelowym AID, dodaje przesunięcie adresowe do pakietu docelowego i zapisuje tę wartość w pozycji pierwotnej w sekcji tekstowej. Przesunięcie adresowe do pakietu docelowego jest przechowywane albo w tablicy uporządkowania albo w sekcji tekstowej w adresie relokacji dla otrzymania mniejszych rozmiarów tablicy uporządkowania. Relokacja z przesunięciem adresowym jest zawsze stosowana dla większości odniesień w samym załadowanym subarkuszu. Do obliczania wstępnego przesunięć adresowych bez utraty kompatybilności jest stosowany przetwornik.

Ze względu na integralność systemową, odniesień do pakietów zewnętrznych nie należy dołączać przez obliczanie wstępne przesunięcia adresowego. Zamiast tego do odniesień do innych pakietów w procesie łączenia należy używać nazwy lub identyfikatora. Te nazwy i przyporządkowane im wartości są przechowywane tylko na arkuszu pakietów, które są dzielone między wiele apletów. Ponieważ te tablice par nazw/wartości powinny być możliwie małe, to w tym formacie pliku CAP ogranicza się nazewnictwo elementów pliku klas, lecz nadal z zachowaniem możliwości stosowania specyficznych implementacji różnych specyfikacji dostawcy. Mianowicie klasy publiczne muszą być nazwane i eksportowalne, podobnie jak i publiczne statyczne metody i konstruktory oraz publiczne pola statyczne. Stosuje się metody wirtualne, w których interpreter wyszukuje metodę wirtualną za pośrednictwem indeksu wskazującego w wirtualnej tablicy metod. Te indeksy i wirtualna tablica metod są określana na arkuszu, jeżeli środowisko JavaCard ma obsługiwać późniejsze wiązanie metod wirtualnych standardowego kodu Java. Podczas zestawiania tablicy metod, program łączący decyduje, czy dana metoda w tablicy metod dziedziczy inną metodę. Ponieważ te metody mogłyby być definiowane w różnych subarkuszach, to konieczne jest wprowadzenie globalnego układu nazewniczego dla metod wcelu decydowania, czy dwie metody są tego samego typu. Ponieważ późniejsze wiązanie metody wirtualnej wymaga globalnego układu nazewniczego i dodatkowych zasobów na arkuszu dla określania i nazywania metod wirtualnych, to format pliku CAP według wynalazku nie obsługuje go. Nawet przy tym ograniczeniu pozostaje dostateczna przestrzeń dla specyficznej implementacji pakietów podstawowych i rozszerzeń dostawcy. Programista swobodnie wprowadza prywatne lub statyczne metody i klasy, a także nieprywatne przykładowe metody, jeżeli nie są dziedziczone i opisywane jako ostateczne. Następnie przetwornik zastępuje wywołania tych metod wywołaniami bezpośrednimi.

PL 193 009 B1

Liczba i typy przykładowych pól w klasie nie są zwykle definiowane przez specyfikacje i zmieniają się dla implementacji różnych dostawców. Stosowanie pól odnoszących się do procesu łączenia dzieli się na następujące trzy kategorie.

Pierwszą kategorią są obliczane wstępnie przesunięcia adresowe pól. Rozkaz pobierz/wstaw pole odnosi się do pola, którego klasa i wszystkie superklasy są zdefiniowane w zawierającym je subarkuszu. Przesunięcie adresowe tego pola jest wtedy obliczane wstępnie przez przetwornik i nie musi być łączone podczas procesu ładowania. Jeżeli jest uzgodnienie, że klasa Obiekt nie zawiera żadnych opisów pola, to na tę kategorię przypada wiele dostępów do pól.

Drugą kategorią jest dostęp do pól klas wewnętrznych subarkusza z dowolnymi superklasami zewnętrznymi subarkusza. Ten przypadek wymaga obsługi przez format pliku CAP dla umożliwienia podziału na podklasy klas zdefiniowanych w oddzielnych pakietach. Przetwornik oblicza przesunięcie adresowe pola w odniesieniu do przykładowego rozmiaru superklasy zewnętrznej subarkusza i zapisuje tę wartość w pliku CAP. Podczas procesu łączenia rzeczywiste przesunięcie adresowe pola wymaga obliczenia na podstawie rozmiaru klasy bazowej. To samo odbywa się w przypadku elementu o przykładowym rozmiarze klasy wewnętrznej subarkusza.

Trzecią kategorią jest dostęp do pól w klasach zewnętrznych subarkusza lub w dowolnej klasie zewnętrznej. Chociaż przykładowe pola są rzadko opisywane jako publiczne, to są często opisywane jako chronione. Dostęp do pól chronionych jest zawsze przyznawany przy specyfikacji chronionych metod pobierz/wstaw pole, lecz proponowany format pliku CAP umożliwia dostęp bezpośredni również do takich pól opisywanych jako chronione lub publiczne. Pakiet, który eksportuje chronione lub publiczne pole przykładowe, musi zawierać nazwę i przesunięcie adresowe dla takiego pola wcelu umożliwienia łączenia symbolicznego.

Pakiet, który eksportuje klasy, metody lub pola, zawiera pulę stałą, której pozycje zawierają typ klasy itp., nazwę i wartość dla tego symbolu. Ponieważ format pliku CAP nie wymaga utrzymywania globalnego układu nazewniczego, to łatwa jest specyfikacja nazw dla przyporządkowanych symboli. Symbole są numerowane od 0do n lub są wydawane wraz ze specyfikacją interfejsu programów użytkowych API.

Programista wykonujący taką specyfikację jest nadal w stanie eksportować dodatkowe klasy itp. przez wybór nowych nazw, rozpoczynając od n +1.

Fig. 3 przedstawia symboliczne powiązanie apletu z pakietem docelowym. Zapisy w tablicy uporządkowania zawierają typ relokacji, przesunięcie adresowe relokacji w sekcji tekstowej i nazwę symbolu, który dla oszczędności przestrzeni jest również przechowywany w pozycji przeznaczonej do relokacji. W proponowanym układzie nazewniczym nazwa jest stosowana w charakterze indeksu wpuli stałej pakietu docelowego. Zapisy w puli stałej zawierają typ pozycji, nazwę i przyporządkowaną wartość. Program łączący dokonuje relokacji zapisów w tablicy uporządkowania, zależnie od typu zapisu.

Relokacja metody polega na tym, że pozycja puli stałej pakietu docelowego o danej nazwie musi być typu metody. Wartość musi być przesunięciem adresowym w pakiecie docelowym, w którym metoda jest określona. Program łączący oblicza adres metody i wyznacza sekcję tekstową z danym przesunięciem adresowym.

Relokacja klasy jest jak powyżej, z tym wyjątkiem, że pozycja puli stałej z indeksem symbolu i nazwą musi być typu klasy.

Relokacja pola statycznego jest jak powyżej, z tym wyjątkiem, że pozycja puli stałej z indeksem symbolu i nazwą musi być typu pola statycznego, a wartość stanowi przesunięcie adresowe w sekcji danych pakietu.

Relokacja względnego przykładowego przesunięcia adresowego pola lub względna wartość rozmiaru przykładowej klasy polega na tym, że pozycja puli stałej pakietu docelowego o danej nazwie musi być typu klasy. Program łączący oblicza adres klasy docelowej i pobiera przykładowy rozmiar klasy, który stanowi element struktury klasy. Program łączący dodaje przykładowy rozmiar do wartości podanej w przesunięciu adresowym sekcji tekstowej i zastępuje to sumą.

Dostęp bezwzględny pola do niezdefiniowanej klasy polega na tym, że pozycja puli stałej pakietu docelowego o danej nazwie musi być typu przykładowego pola. Wartość tej pozycji stanowi bezwzględne przesunięcie adresowe tego pola w przykładzie jego klasy.

Jeżeli załadowany subarkusz jest wspólnym pakietem i eksportuje pola chronione lub publiczne, to program łączący przemieszcza jego zapisy również w puli stałej. Ich rzeczywiste przesunięcia adresowe są przemieszczane w ten sam sposób, jak przesunięcia adresowe przykładowych pól.

PL 193 009 B1

Tablice uporządkowania po zakończeniu procesu łączenia są ewentualnie usuwane. Aplety nie wymagają puli stałej, a tylko pakiety, które mogą być dzielone między wiele apletów, wymagają puli stałej do przyszłego stosowania. Rozmiar puli stałej zależy od liczby eksportowanych pozycji i od rozmiaru pozycji. Pula stała dla aktualnych klas systemu JavaCart zajmuje obecnie około 160 pozycji. Pozycja puli stałej zawiera pole typu, nazwę i wartość, które są zapisywane w 4 bajtach, a przy użyciu układu nazewniczego według wynalazku są redukowane nawet do trzech bajtów. Daje to w wyniku rozmiar puli stałej wynoszący 720 bajtów dla wszystkich klas systemowych.

Różnice względem propozycji JavaSoft polegają na tym, że pula stała JavaSoft aktualnie nie dokonuje rozróżnienia między pozycjami określanymi wewnętrznie i zewnętrznie. Utrudnia to usunięcie pozycji puli stałej, zajmujących pozycje definiowane wewnętrznie. Przesunięcia adresowe pola w rozkazach pobierz/wstaw pole i pola o przykładowym rozmiarze w strukturze klasy mają szerokość tylko 8 bitów. Uniemożliwia to obecnie stosowanie tych wartości jako indeksów w puli stałej, gdzie jest przechowywana informacja do wiązania przesunięcia adresowego pola podczas procesu łączenia.

Z powodu tych dwóch ograniczeń, aktualna propozycja JavaSoft wymaga rozszerzeń dla umożliwienia uproszczenia niezbędnego układu nazewniczego, jak w przypadku tej propozycji.

Rozszerzenia o mniejszym znaczeniu polegają na tym, że w niektórych środowiskach podczas procesu łączenia może nie być potrzebna w ogóle jakakolwiek informacja symboliczna na arkuszu, na przykład wystarcza stosowanie tylko obliczonych z góry przesunięć adresowych. Format pliku CAP według wynalazku jest rozszerzany w bezpieczny sposób w tym kierunku, że pakiet lub aplet zawiera nie tylko numer wersji, lecz również identyfikator dostawcy lub identyfikator implementacji. Zapisy tablic uporządkowania mają pozycje odniesienia puli stałej, zawierające również przesunięcia adresowe, które przetwornik oblicza także w czasie przetwarzania. Na początku procesu ładowania program ładujący sprawdza, czy pakiety żądane przez aplet pochodzą od tego samego dostawcy, na przykład z tej samej implementacji, co już aktualnie zainstalowane na arkuszu. Jeżeli tak jest, to program ładujący stosuje podczas procesu łączenia przesunięcia adresowe pliku CAP apletu. W przeciwnym przypadku proces ładowania nie kończy się pomyślnie.

Specyfikacje w przypadku odnośnych pozycji formatu pliku CAP polegają na tym, że celem szczegółowego opisu nie jest dokładne wyszczególnianie zawartości pliku CAP.

Zamiast tego zapewnia się szczegółowe omówienie elementów, które powinny i które muszą znaleźć się w pliku CAP, wychodząc z propozycji JavaSoft. Tym niemniej, zapewnia się również bardziej formalne specyfikacje pozycji formatu pliku CAP wspomnianego w tym opisie w postaci wyrażeń zgłoszonych do języka C.

Dla przejrzystości wyszczególniono je poniżej w postaci nieoptymalizowanej:

//format tablicy uporządkowania typedef struct_fixup_table{ u1 target_aid_cnt;

u1 target_aid[ ]; u1 entries_cnt; fixup_entry_t entries[ ];

};

//układ zapisu uporządkowania typedef struct_fixup_entry{ u1 type;

u2 offset;

//przesunięcie tekstu lub danych union{ u2 target_offset;

//przesunięcie pakietu docelowego u2 symbol_name;

//nazwa i indeks docelowej puli stałej } value;

} fixup_entry_t;

PL 193 009 B1 // typy poszczególnych zapisów uporządkowania //relokacja 16-bitowego adresu w sekcji tekstowej lub danych za pomocą przesunięcia, //to może pokryć adresy klas, metod itp.

#define RELO_TEXT_16BIT_WITH_OFFSET #define RELO_TEXT_16BIT_WITH_OFFSET //relokacja wartości symbolu do sekcji tekstu #define RELO_CLASS_BY_SYM #define RELO_METHOD_BY_SYM #define RELO_STATICFIELD_BY_SYM #define RELO_INSTANCEFIELD_BY_SYM //układ puli stałej typedef struct_constant_pool{ u2 cnt;

cp_item_t items [cnt];

};

// układ pozycji puli stałej typedef struct_cp_item{ unsigned type:4 //typ pozycji unsigned name:12;

//nazwa, jeżeli w ogóle potrzebna u2 offset;

//offset };

//typy pozycji puli stałej #define CONSTPOOL_CLASS #define CONSTPOOL_METHOD #define CONSTPOOL_STATICFIELD #define CONSTPOOL_INSTANCEFIELD.

Claims (4)

1. Zastrzeżenia patentowe

   1. Sposób wprowadzania nowego kodu do systemu przetwarzania Java z modyfikowaną pulą stałą, w którym za pomocą interpetera opartego na stosie wykonuje się pakiet zawierający kody pośrednie i struktury klas, znamienny tym, że łączy się wewnętrznie nowy kod z pakietem istniejącym w systemie, przy czym przesunięcie adresowe nowego kodu względem niego samego zastępuje się przez odniesienie znane dopiero w czasie łączenia, określa się łącza zewnętrzne przy użyciu identyfikatorów jako indeksów wpuli stałej pakietu i usuwa się z puli stałej przynajmniej informację, którą stosowano do zastąpienia przez odniesienia znane dopiero w czasie łączenia.
2. 2. Sposób według zastrz. 1, znamienny tym, że z puli stałej usuwa się również informację stosowaną do łączenia pakietów zewnętrznych.
3. 3. Sposób według zastrz. 1, znamienny tym, że za pomocą informacji pozostałej wpuli stałej udostępnia się innym pakietom i apletom, które ładuje się później, poprawnie nowy kod i późniejsze wiązanie kodu.
4. 4. Sposób według zastrz. 1, znamienny tym, że jako system przetwarzania Java stosuje się system przetwarzania JavaCard.