Główne zmiany:
- Do wywołań metod dodano pamięć podręczną, aby uniknąć rozwiązywania przeciążeń, co znacznie zmniejsza wpływ rozpoznawania metod na wydajność, zwłaszcza jeśli to samo przeciążenie jest wywoływane wiele razy, jak podczas wykonywania pętli.
- Od 4 do 100 razy, w zależności od typu danych, transfer list, krotek i buforów do tablic prymitywów Java jest przyspieszany. Konwersja wykorzystuje zoptymalizowane przetwarzanie buforów w pamięci zamiast interfejsu API sekwencji. Po napotkaniu bufora Pythona pod kątem konwersji sprawdzany jest tylko pierwszy element, ponieważ bufory te są jednorodne.
- Przetwarzanie operacji zamykania (zaimplementowane w JPype 1.0.0, ale zostało pominięte podczas przygotowywania dziennika zmian). JPype wywołuje teraz procedurę zamykania maszyny JVM, która próbuje bezpiecznie zakończyć działanie. Prowadzi to do kilku zmian w zachowaniu. Wątki inne niż działające w tle (wywołania proxy) mogą teraz utrzymywać maszynę JVM otwartą do czasu ich zakończenia. Połączenia proxy będą przetwarzane do momentu zakończenia połączenia, ale otrzymają komunikat o przerwaniu. Pliki są teraz poprawnie zamykane i przesyłane na dysk, jeśli wątki obsługują wyjątek zgodnie z oczekiwaniami. Wykonywane są haki i finalizatory oczyszczania zasobów. Kiedy wątki są tworzone, wywoływane są haki AtExit. Za pośrednictwem demona realizowane jest automatyczne dołączanie wątków podczas korzystania z maszyny JVM z Pythona. Błędny kod, który nie może poprawnie obsłużyć czyszczenia wątków, prawdopodobnie zawiesi się po wykonaniu zamknięcia. Dodatkową dokumentację można znaleźć w instrukcji obsługi.
- Opakowanie dla Throwable zamiast oczekiwanego wyniku otrzymało opakowanie dla obiektu, co doprowadziło do dziwnych konwersji z klas Pythona.
- Naprawiono literówki w systemie importu, które powodowały błąd „nie znaleziono nazwy j”.
- Upewnij się, że „^C” było poprawnie promowane w KeyboardInterrupt.
- Naprawiono problem z symbolami od wersji Python 3.5.3. PySlice_Unpack został wprowadzony w kolejnej wersji poprawki (3.5.4) i nie powinien był być używany.
- Naprawiono błąd z numpy.linalg.inv, który doprowadził do awarii. Problem został powiązany z komunikacją wątkową między maszyną JVM a niektórymi wersjami numpy. Proponowane rozwiązanie polega na wywołaniu numpy.linalg.inv przed uruchomieniem JVM.
Źródło: opennet.ru