1 / 35

Java Support Fairy Tales

rhona
Télécharger la présentation

Java Support Fairy Tales

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract.It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

  2. Java Support Fairy Tales Misha Bykov, OracleNikita Lipsky, Excelsior LLC

  3. Fairy Tales (Program Agenda) • Mysterious JVM Crash • Face Control • JNI Issues • Multithreading Problems • Java Specification Ignoring Consequences

  4. Mysterious JVM Crash

  5. Mysterious JVM Crash Hotspot Log File # A fatal error has been detected by the Java Runtime Environment: # #  SIGSEGV (0xb) at pc=0xff380700, pid=583, tid=3156104 # # JRE version: 6.0_16-b01 # Java VM: Java HotSpot(TM) Server VM (14.2-b01 mixedmode) # Problematicframe: # C  [libc_psr.so.1+0x700]  memcpy+0x2f8

  6. Mysterious JVM Crash What’s going on? • Is the problem in native code? • Is this issue related to any Operating System failure? • Is this a memory problem? • Could this be an issue with libc_psr.so.1? • Processor Specific Runtime • Specific Implementation of memcpy To be continued…

  7. Face Control

  8. Face Control Issue XStream(xstream-1.1.3.jar) throws com.thoughtworks.xstream.converters.reflection. ObjectAccessException: Invalid final field xmltest.Main.theValue

  9. Face Control Reason private boolean canUseSun14ReflectionProvider(){   return (isSun() ||isApple() ||isHPUX() ||isIBM() ||isBlackdown()) && is14() &&loadClass("sun.misc.Unsafe") != null; } No Oracle & Excelsior in the “white list“

  10. Face Control Resolution Values for java.vm.vendor: Sun Microsystems (Oracle HotSpot for Java SE 6) Sun-Oracle Java SE licensee Excelsior LLC (Excelsior JET)

  11. Sun  Oracle Renaming • Issue: Eclipse just STOPs working with OutOfMemoryError. • Reason: COMPANY_NAME field in java.dll changed to, “Oracle Corporation”.

  12. Mysterious JVM Crash (Continued)

  13. Mysterious JVM Crash Dig Into the Hotspot Log File Stack: [0xb0c00000,0xb0c80000],  sp=0xb0c7c890,  free space=498k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C  [libc_psr.so.1+0x700]  memcpy+0x2f8 C  [libzip.so+0xd19c] C  [libzip.so+0x2380]  ZIP_GetEntry+0xe4 C  [libzip.so+0x2800]  Java_java_util_zip_ZipFile_getEntry+0xc4 j  java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0 j  java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0 j java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+31 j  java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2 j  java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2 ...

  14. Mysterious JVM Crash The situation looks weird • Could this be an issue with libzip.so? • HotSpot log stack trace shows java.util.jar.JarFileusage • The user reported “no jar usage”, but JVM crashed • No one performed “jar” operations from the Java program • Why the interpreted code shows “jar” and “zip”? To be continued…

  15. JNI Issues

  16. JNI Crashes Any SIGFAULT in JNI code looks like JVM Crash int* p = 0; … (*p) = 0; -> # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f096d096942, pid=12102, tid=139678234564352 #

  17. JNI Misuses • Incorrect usage of JNI: • CallObjectMethod instead of CallIntMethod • Improper arguments types or/and their count • JNI local reference avoidness (loosing Java objects) • AttachCurrentThread/DetachCurrentThreadpairness • … Thumb rule: launch with –Xcheck:jni

  18. Mysterious JVM Crash (Continued)

  19. Mysterious JVM Crash Root Cause On Solaris and Linux platforms an application might crash in java.util.zip.ZipFile'snative code if a in-use zip file is being overwritten by other part of the application and mmap is used to map the zipfile'scentral directory into the memory.

  20. Mysterious JVM Crash Observations • This kind of use scenario (overwrite your own file is till being used by yourself) definitely is a programming error. • One of the solutions is to always make a defensive copy before open the zip/jar file or always to check the availability of the zip/jar file before each and every access. To be continued…

  21. Multithreading Issues

  22. Multithreading Issues public static boolean changed = false; What’s wrong with this program? Does “Thread 1” stop?

  23. Multithreading Issues public static volatile boolean changed = false; And never forget about JMM!

  24. Deadlocks • Faster JVM can reveal (potential) deadlocks

  25. Mysterious JVM Crash (Continued)

  26. Mysterious JVM Crash What really happened? • The user scenario was to replace jars in a JVM classpath when that JVM is still running. • This situation caused the JVM crash

  27. Mysterious JVM Crash Recommendations • Do not upgrade Java when JVM is still running • Restart the applications for all updates to .jar files, even if the particular update doesn't touch any class actually used by the application. • When replacing the jar files try to remove them first and the copy new files to that place. • The property sun.zip.disableMemoryMapping can be used to disable the mmapping of the central directory.

  28. Java Specification Ignoring Issues

  29. Order of class members • Class.getDeclaredFields, Class.getDeclaredMethods, • Class.getDeclaredConstructors • Java specification: “…The elements in the array returned are not sorted and are not in any particular order.”

  30. Order of class members • Who ever ignored that rule: • JNA • JBoss • Eclipse

  31. JRE shape dependence • JVM specification does not define the JRE shape • It can be no jre/bin/java at all!

  32. Summary • There are funny stories around JVM with technical aspects. • This session demonstrated some typical cases, which look like bugs in JVM, but are actually not. • Java support teams and users might use this knowledge in order to save time working with future customer issues.

  33. Graphic Section Divider

More Related