JVM crash logining BufferBlob :: Interpreter nima degani?

Men JVM ning halokatga uchrashini tekshirib ko'raman. Hs_err fayli qulashi haqida quyidagi ma'lumotlarni o'z ichiga oladi.

#  SIGSEGV (0xb) at pc=0x065e68f4, pid=20208, tid=570166160
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86)

...

# Problematic frame:
# V  [libjvm.so+0x5e68f4]

...

Current thread (0x099ea800):  JavaThread "Thread-315" daemon [_thread_in_vm, id=25782, stack(0x21fa3000,0x21fc1000)]

...

vm_info: Java HotSpot(TM) Server VM (10.0-b23) for linux-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:20:15 by "java_re" with gcc 3.2.1-7a (J2SE release)

Ya'ni, JVM ba'zi Java kodlarini ishlayotganda segfaultni urganini aytadi. Xato jurnali shuningdek, ish zarrachasining zarbasi haqida ma'lumotlarni o'z ichiga oladi.

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5e68f4]
V  [libjvm.so+0x1c054f]
V  [libjvm.so+0x1bfef2]
V  [libjvm.so+0x1bf57f]
V  [libjvm.so+0x592495]
V  [libjvm.so+0x365c4e]
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
J  org.myapp.AppClass.getBytes()Lorg/myapp/ByteHolder;

Jadvaldagi yadro faylga ulanish uchun GDB dan foydalandim va stack haqida batafsil ma'lumotga ega bo'ldim. Bu menga quyidagi chiqishni beradi.

#5  
#6  0x065e68f4 in interpretedVFrame::monitors() const ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#7  0x061c054f in get_or_compute_monitor_info(JavaThread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#8  0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#9  0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) ()
   from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so

Bu asl xato hisobotida ko'rsatilgan oltita libjvm.so ramkalari Java qulfini olish bilan bog'liqligini ko'rsatadi. Biroq, har qanday qulfni ishlatadigan org.myapp.AppClass.getBytes() ichida hech qanday kodni topa olmayapman.

Yig'indagi BufferBlob :: Interpreter chiziqlari nimani anglatadi? Ushbu Java biriktiruvchi ramkalari bormi? JVM stack ramkalarmi? Ushbu stack ramkalarida chaqirilayotgan narsalarni ishlab chiqish mumkinmi?

QAYD: Iltimos, yangi "Hotspot JVM" ga o'tishni tavsiya qilmang. CMS kollektoriga tayanaman va yaqinda V1.6 Hotspot JVM-larning hech biri CMS kollektori bilan etarli darajada barqaror emas.

EKRAN: Ushbu hujjat (http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf) "v" kvadratining "VM yaratilgan qoralama ramkasi" deb ta'kidlaydi. Buning ma'nosi qanday?

EDIT2: org.myapp.AppClass.getBytes() DataInputStream-dan o'qiydi. Bu quyidagi ketma-ketlikni o'z ichiga olishi mumkin:

AppClass.getBytes()
AppClass.readByte()
DataInputStream.readByte()
SocketInputStream.read()
SocketInputStream.read(byte[],int,int)
PlainSocketImpl.aquireFD()

Ushbu yakuniy usul qulfni qamrab oladi. Bu yuqorida sanab o'tilgan JVM kodiga yakuniy qo'ng'iroqning manbai bo'lishi mumkin. Yuqoridagi bu birikma getBytes() ning ostidagi 5 ta Java stack kvadratiga ega bo'lgan qulay xususiyatga ega. "BufferBlob :: Interpreter" ning "Java ramkalari" ro'yxatida 5 satr bilan mos kelishi mumkin.

Bu bir necha yangi savol tug'diradi:

  • "Mahalliy ramkalar" da joylashgan "BufferBlob :: Interpreter" ning 5 ta satri bo'lishi mumkinmi? "Java ramkalar" bo'limida bir xil satrlarni faqat dublikatlari bormi?
  • Nima uchun xato log bu 5 ta sonli ramkalar uchun tafsilotlarni ko'rsatmaydi?

EDIT3 - This Oracle bug looks likely to be the same/similar bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6676175

Ko'rsatilgan steka izi bir xil emas, lekin u 6u14da belgilangan revoke_and_rebiaslarda noyob poyga holatini eslatib o'tadi.

EDIT4 - Baxt xabarlari "Hotspot ilovasi bilan tanish" deb aytishi kerak

7

2 javoblar

VM generated stub frame just means that the code that is executing has been generated by the JVM.

Stackning o'zi (gdb-dan) VM xavfsizlik nuqtai nazariga erishishga harakat qilayotganligini ko'rsatadi, chunki u blokirovka kilitishni bekor qiladi. Ushbu blogda yoniq qulflash haqida ma'lumot olishingiz mumkin. Bu shuni anglatadiki, bir nechta monitor bu monitorni ushbu ish zarrachasiga qarshi qo'yadigan monitorni sotib oldi. Keyinchalik, ba'zi bir boshqa iplar blokirovka qilishni talab qiladi, shuning uchun u xavfsiz nuqtaga ega bo'lishni talab qiladigan tanqidni bekor qilishi kerak (ya'ni, hech qanday nuqta byte kodi bajarilmayapti va dunyo to'xtatiladi).

Sizning xatolaringiz JVM ning ba'zi usullarning deoptimisatsiyalash vaqtida shikastlanishidan dalolat beradi. Ya'ni, JVM ba'zi usullarni optimallashtirishni (kompilyatsiya) olganini, ammo keyinchalik olingan usulni endi bekor qilishni talab qiladigan kod yo'lini urganini bildiradi. Buning uchun JVMni yangilashsiz tuzatish mumkin.

Siz sinab ko'rmoqchi bo'lgan 2 vaqtinchalik echim bor

  1. if it's driven by biased locking, turn it off (-XX:-UseBiasedLocking)
  2. if it's driven by deoptimisation, find the offending method and tell hotspot not to compile it in the first place, instructions on how to do this on this link

Ikkala yondashuv ham tashqi ta'sirga ega bo'lishi mumkin.

NB bu muammoni ishonchli tarzda qayta ishlab chiqaradigan test stsenariysi ishlab chiqilsa, bu sizni xafa qiladi.

4
qo'shib qo'ydi
"JVM tomonidan ishlab chiqarilgan kod, ya'ni olingan (optimallashtirilgan) kod ishlab chiqarilgan degan ma'noni anglatadi" - JVM kompilyatsiya qilingan usulga qaramasdan "org.myapp.AppClass.getBytes ()" nomini boshqaradi "J"). JVM ba'zan bajarilayotgan usulni nomlay olmaydimi? Yoki "BufferBlob :: Interpreter" satrlari JVM dasturiga kiritilgan yopiq ishlarning bitlarini nazarda tutadimi?
qo'shib qo'ydi muallif mchr, manba
Hmmm, bu menimcha, stack (org.myapp.AppClass.getBytes ()) da hech qanday qulflash qilmasligiga ishonchim komil. Shu sababli, buferni ochish uchun "BufferBlob :: Interpreter" yo'nalishida qo'shimcha usul chaqiruvlarini taqdim etishim lozim edi. Bu mumkinmi? Men GC va JIT o'z ishlarida sodir bo'lgan deb o'yladim.
qo'shib qo'ydi muallif mchr, manba
Men bularni bir chetga surib qo'ydim, chunki aytmoqchi bo'lgan narsa emas. Oddiy kompilyatsiya qilingan usul hali bilganimdek, J sifatida paydo bo'ladi. Interpreter liniyalari JVM yaratgan kodni nazarda tutadi. JVM ko'p narsalarni qilmoqda (GC, optimallashtirish).
qo'shib qo'ydi muallif Matt, manba
bu maqolada qanday qilib deoptizatsiya yuz berishi haqida ba'zi ma'lumotlar mavjud - cs.princeton.edu/ Picasso/paspaslar/HotspotOverview.pdf - bu erda noto'g'ri bekor qilishning qisqacha bayoni - http://www.oracle.com/technetwork/java/javase/tech/otherlocklock-oopsla2006-preso-150106 .pdf "rel =" nofollow noreferrer "> oracle.com/technetwork/java/javase/tech/… - har ikkisi ham xavfsiz nuqtani olishni talab qiladi, bu esa iplarni to'xtatishga majbur qiladi. Men tarjimon ishi tushirilgan ramkalarni nazarda tutadi, shuning uchun kompilyatsiya qilingan usuldan deoptizimlangan versiyaga o'tishi mumkin. -XX: + PrintCompilation dan foydalanishga moyil bo'laman.
qo'shib qo'ydi muallif Matt, manba

Bu savolga Tom Xodrigez "Hotspot-runtime-dev mailing list" da javob berdi.

http://mail.openjdk.java.net /pipermail/hotspot-runtime-dev/2011-November/002592.html

1
qo'shib qo'ydi