Używam JProfiler do analizy fragmentu kodu Java, który wywołuje natywny kod C przez JNI, i otrzymuję dziwne wyniki z okna "CPU Views". W szczególności informacje na zakładce "Drzewo wywołania" informują mnie, że metoda Java, która wywołuje kod natywny, pochłania największą część czasu pracy, ale zakładka "Hot spots" nie wymienia nawet tej metody w ogóle. Zauważyłem również podobną historię dla klas org.joda.time, o których informuje się, że mają dość dużą część procesora, ale nie są zgłaszane jako hot spoty, i zastanawiam się, czy to dlatego, że spędzają dużo czasu dzwoniąc macierzysty kod konwersji daty.Czy widok "Hot Spot" jprofiler poprawnie uwzględnia procesor zużywany przez natywny kod wywoływany przez JNI?
Każdy wgląd w ten problem byłby doceniony.
EDYCJA: Właśnie odkryłem bardzo niepokojący dokument akademicki zatytułowany "Ocena dokładności profili Java" (podaję link, ale wygląda na to, że serwer Uniwersytetu Kolorado, do którego odnosi się wynik Google, jest bardzo nieszczęśliwy, teraz musiałem ściągnąć kopię z linku "Szybki podgląd" Google'a. Podejrzewam, że problem z natywnymi metodami polega na tym, że są one nadmiernie liczone, ponieważ jest ich wiele, są krótkie, a wywołanie prawdopodobnie prowadzi do granicy plastyczności; jednak nie jestem pewien, czy to samo dotyczy rutyny konwersji czasu. Zwróć uwagę, że uzyskuję znacznie różne wyniki, gdy używam profilowania instrumentalnego i profilowania próbkowanego dla tego samego uruchomienia testowego, a wyniki oprzyrządowania lepiej zgadzają się z moją intuicją. Polecam ten artykuł każdemu, kto choć raz znalazł się w jego głowie nad wynikami z profilowania. Wciąż mam nadzieję, że ktoś ma więcej informacji na ten temat; "profiler się myli" nie jest zbytnio kojącym wynikiem.
EDIT 2: Wygląda colorado.edu jest klasyfikowane się na zewnątrz, oto link: http://www-plan.cs.colorado.edu/klipto/mytkowicz-pldi10.pdf