Podczas analizowania zrzutów sterty za pomocą jhat zaobserwowałem wiele instancji DelegatingClassLoader, mimo że nie zostały one wywołane jawnie w kodzie. Oczekuję, że będzie to jakiś mechanizm optymalizacji refleksji. Czy ktoś zna szczegóły?Co dla Sun JVM tworzy wystąpienia sun.reflect.DelegatingClassLoader w czasie wykonywania?
Tak, to prawdopodobnie optymalizacja odbicia.
W wirtualnej maszynie JVM początkowy dostęp do właściwości i metod jest wykonywany przez wywołanie przez JNI do implementacji JVM. Jeśli JVM zauważy, że dostęp do metody lub pola jest uzyskiwany przez dużą refleksję, wygeneruje kod bajtowy, aby zrobić to samo - mechanizm, który nazywa "inflacją". To ma początkową prędkość, ale po tym działa około 20 razy szybciej. Wielka wygrana, jeśli dużo się zastanowisz.
Ten bajt żyje w klasach utworzonych przez instancje DelegatingClassLoader. Miej oko na to: te klasy mogą wywierać presję na przestrzeni permen i powodować przerażające błędy "java.lang.OutOfMemoryError: PermGen space". Jeśli jest to problem, możesz wyłączyć inflację, ustawiając właściwość systemową sun.reflect.inflationThreshold na 0 (zero).
nie widzę (przynajmniej dla Hotspot), patrząc na kod
http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/reflect/ReflectionFactory.java.html
i
że ustawienie zera spowoduje wyłączenie funkcji. Wydaje mi się, że tylko duża wartość dla sun.reflect.inflationThreshold wykona zadanie.
IBM zachowuje się inaczej, wyłączy je 0 lub 1. (Nie jestem pewien, czy robi coś innego dla 0 lub 1, ale z obydwoma nie widzę załadowania DelegatingClassLoader). – eckes
Ostrzeżenie, właściwość działa na Oracle/OpenJDK i IBM JDK, jednak na IBM włącza inflację, na Sun natychmiast nadyma (próbowałem tego przy użyciu -verbose: klasa, która zwraca się w DelegatedClassLoaders w instancji, jako kod dla IBM jest niedostępne). Na obu wartości domyślnej jest 15, myślę o ustawieniu go na 1000 lub coś w celu zmniejszenia inflacji, ale nadal korzystać z przyspieszenia. – eckes