From fw at deneb.enyo.de Fri Aug 3 01:18:09 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 03 Aug 2007 10:18:09 +0200 Subject: amd64 register names used in the i486 tree in b17 Message-ID: <87ir7x116m.fsf@mid.deneb.enyo.de> Someone has run s/eax/rax et al. on the i486 part of the source tree, which seems incorrect: diff --git a/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp b/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp index 29e95a3..f9df8be 100644 --- a/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp +++ b/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp [...] @@ -31,7 +31,7 @@ int C1_MacroAssembler::lock_object(Register hdr, Register obj, Register disp_hdr, Register scratch, Label& slow_case) { const int aligned_mask = 3; const int hdr_offset = oopDesc::mark_offset_in_bytes(); - assert(hdr == eax, "hdr must be eax for the cmpxchg instruction"); + assert(hdr == rax, "hdr must be rax, for the cmpxchg instruction"); assert(hdr != obj && hdr != disp_hdr && obj != disp_hdr, "registers must be different"); assert(BytesPerWord == 4, "adjust aligned_mask and code"); Label done; @@ -70,16 +70,16 @@ int C1_MacroAssembler::lock_object(Register hdr, Register obj, Register disp_hdr // => test if it is a stack pointer into the same stack (recursive locking), i.e.: // // 1) (hdr & aligned_mask) == 0 - // 2) esp <= hdr - // 3) hdr <= esp + page_size + // 2) rsp <= hdr + // 3) hdr <= rsp + page_size // // these 3 tests can be done by evaluating the following expression: // - // (hdr - esp) & (aligned_mask - page_size) + // (hdr - rsp) & (aligned_mask - page_size) // // assuming both the stack pointer and page_size have their least // significant 2 bits cleared and page_size is a power of 2 - subl(hdr, esp); + subl(hdr, rsp); andl(hdr, aligned_mask - os::vm_page_size()); // for recursive locking, the result is zero => save it in the displaced header // location (NULL in the displaced hdr location indicates recursive locking) [...] From Paul.Hohensee at Sun.COM Fri Aug 3 11:24:06 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE) Date: Fri, 03 Aug 2007 14:24:06 -0400 Subject: amd64 register names used in the i486 tree in b17 In-Reply-To: <87ir7x116m.fsf@mid.deneb.enyo.de> References: <87ir7x116m.fsf@mid.deneb.enyo.de> Message-ID: <46B372C6.1050102@sun.com> We're in the process of merging the i486 and amd64 directories into a single directory, in a way similar to sparc and sparcv9. Lots of code is identical or close to it in the i486 and amd64 directories, so merging them should reduce maintenance costs. Renaming the 32-bit registers is part of that process. Paul Florian Weimer wrote: > Someone has run s/eax/rax et al. on the i486 part of the source tree, > which seems incorrect: > > diff --git a/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp b/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp > index 29e95a3..f9df8be 100644 > --- a/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp > +++ b/hotspot/src/cpu/i486/vm/c1_MacroAssembler_i486.cpp > [...] > @@ -31,7 +31,7 @@ > int C1_MacroAssembler::lock_object(Register hdr, Register obj, Register disp_hdr, Register scratch, Label& slow_case) { > const int aligned_mask = 3; > const int hdr_offset = oopDesc::mark_offset_in_bytes(); > - assert(hdr == eax, "hdr must be eax for the cmpxchg instruction"); > + assert(hdr == rax, "hdr must be rax, for the cmpxchg instruction"); > assert(hdr != obj && hdr != disp_hdr && obj != disp_hdr, "registers must be different"); > assert(BytesPerWord == 4, "adjust aligned_mask and code"); > Label done; > @@ -70,16 +70,16 @@ int C1_MacroAssembler::lock_object(Register hdr, Register obj, Register disp_hdr > // => test if it is a stack pointer into the same stack (recursive locking), i.e.: > // > // 1) (hdr & aligned_mask) == 0 > - // 2) esp <= hdr > - // 3) hdr <= esp + page_size > + // 2) rsp <= hdr > + // 3) hdr <= rsp + page_size > // > // these 3 tests can be done by evaluating the following expression: > // > - // (hdr - esp) & (aligned_mask - page_size) > + // (hdr - rsp) & (aligned_mask - page_size) > // > // assuming both the stack pointer and page_size have their least > // significant 2 bits cleared and page_size is a power of 2 > - subl(hdr, esp); > + subl(hdr, rsp); > andl(hdr, aligned_mask - os::vm_page_size()); > // for recursive locking, the result is zero => save it in the displaced header > // location (NULL in the displaced hdr location indicates recursive locking) > [...] > From Steve.Goldman at Sun.COM Fri Aug 3 13:17:34 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Fri, 03 Aug 2007 16:17:34 -0400 Subject: amd64 register names used in the i486 tree in b17 In-Reply-To: <87ir7x116m.fsf@mid.deneb.enyo.de> References: <87ir7x116m.fsf@mid.deneb.enyo.de> Message-ID: <46B38D5E.40508@sun.com> Florian Weimer wrote: > Someone has run s/eax/rax et al. on the i486 part of the source tree, > which seems incorrect: It's hard when you can't see the putback messages. The i486/amd64 directories are going to be merged into a single x86 directory soon. This is just one of the steps to get there. We had to choose a common naming convention and the "r"'s won. Eventually this will get us a 64bit c1 and 64bit tiered compilation. -- Steve From chenj at lemote.com Tue Aug 7 03:05:05 2007 From: chenj at lemote.com (chenjie) Date: Tue, 07 Aug 2007 18:05:05 +0800 Subject: Can anybody help me with this porting problem? Message-ID: <46B843D1.9090605@lemote.com> Can anybody help me with this porting problem? I am now porting JVM6 to mips archtecture, But meet a big problem . I have already spended 1 week on it, but still can not solve it.can anybody do me a favor giving me some advices? I currently use the JDK5 enviroment except "libjvm.so". when run Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But when run it with mixed mode, It happened a strange crash, this is the error report: # # An unexpected error has been detected by Java Runtime Environment: # # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) # Problematic frame: # j sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 Registers: i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc Top of Stack: (sp=0x7efc4624) 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 0x7efc4624: 7efc4624 32592600 32592850 00000000 0x7efc4634: 32592648 7efc4654 00000000 7efc464c 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 0x7efc4654: 2e037878 7efc4658 32412576 32412830 0x7efc4664: 00000000 32412588 7efc4688 7efc464c 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 Instructions: (pc=0x2bf8c718) 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 j java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 v ~StubRoutines::call_stub V [libjvm.so+0x437fe0] C 0x7efc4a80 --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=20204] 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] Other Threads: 0x10063c00 VMThread [id=20199] 0x100ae400 WatcherThread [id=20207] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, 0x2e490000) eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, 0x31fb0000) the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, 0x35fb0000) the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) No shared spaces configured. VM Arguments: jvm_args: -XX:+PrintCompilation java_command: Java2Demo.jar Launcher Type: generic Environment Variables: JAVA_HOME=/usr/lib/jvm/sun-java CLASSPATH=.:/usr/lib/jvm/sun-java/lib PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin USERNAME=loongson LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 SHELL=/bin/bash DISPLAY=:0.0 Signal Handlers: SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 --------------- S Y S T E M --------------- OS:4.0 uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity load average:0.98 0.82 0.60 CPU:total 1 , has_16k_page Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) when Run it in gdb, it stop at "invokevirtual_helper" at "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv is "0xfefefefe", which is sure error, the recv is assigned in "prepare_invoke" as follow: if (load_receiver) { __ andi(AT, flags, 0xff); __ shl(AT, Interpreter::stackElementScale()); __ add(AT, SP, AT); __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); __ verify_oop(recv); } the value of recv is the return value of "currentThread"function, which was compiled and excuted through i2c adapt just now.the return vaule of "currentThread" is normal as before,So I think the SP is wrong , but SP did not change during invoking "currentThread".So I am confused.do any body get some advices? the funtions compiled before crash is as follows: 1 java.lang.String::equals (89 bytes) 2 ! sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (698 bytes) 3 java.lang.String::hashCode (60 bytes) 4 java.lang.String::charAt (33 bytes) 5 java.lang.String::lastIndexOf (156 bytes) 6 java.lang.Math::max (11 bytes) 7 java.lang.String::indexOf (151 bytes) 8 java.util.jar.JarFile::hasClassPathAttribute (197 bytes) 9 java.io.UnixFileSystem::normalize (75 bytes) 10 java.lang.Object:: (1 bytes) 11 sun.reflect.ClassFileAssembler::emitByte (11 bytes) 12 sun.reflect.ByteVectorImpl::add (38 bytes) 13 java.util.Properties$LineReader::readLine (383 bytes) --- n java.lang.System::arraycopy (static) 14 ! sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (1814 bytes) 15 java.lang.AbstractStringBuilder::append (40 bytes) 16 java.lang.String::indexOf (166 bytes) 17 java.io.StreamTokenizer::read (38 bytes) 18 ! java.io.BufferedReader::read (104 bytes) 19 java.io.BufferedReader::ensureOpen (18 bytes) 20 java.io.StreamTokenizer::nextToken (1295 bytes) 21 java.lang.Character::charCount (12 bytes) 22 java.lang.String::codePointAt (44 bytes) 23 java.lang.Character::codePointAtImpl (41 bytes) 24 java.lang.Character::isHighSurrogate (18 bytes) 25 java.lang.CharacterDataLatin1::getProperties (11 bytes) 26 java.lang.String::toLowerCase (322 bytes) 27 java.lang.Character::toLowerCase (162 bytes) 28 java.lang.CharacterDataLatin1::toLowerCase (36 bytes) 29 java.nio.Buffer::position (43 bytes) 30 java.lang.String::startsWith (78 bytes) 31 java.util.Properties::loadConvert (505 bytes) 32 java.util.HashMap::indexFor (6 bytes) 33 java.util.HashMap::maskNull (12 bytes) 34 java.util.HashMap::hash (36 bytes) 35 sun.awt.X11GraphicsEnvironment::specificFontIDForName (140 bytes) 36 java.util.HashMap::put (113 bytes) 37 java.lang.String::getChars (66 bytes) 38 java.lang.AbstractStringBuilder::append (60 bytes) 39 s java.util.Hashtable::put (167 bytes) 40 java.util.HashMap$Entry:: (26 bytes) 41 java.util.HashMap::transfer (83 bytes) 42 java.util.HashMap::get (74 bytes) 43 java.util.HashMap::addEntry (58 bytes) 44 java.util.Hashtable::rehash (122 bytes) 45 javax.swing.UIDefaults::putDefaults (58 bytes) 46 java.lang.String::replace (142 bytes) 47 java.util.HashMap$HashIterator::nextEntry (96 bytes) 48 java.lang.StringBuilder::append (8 bytes) 49 s java.util.Hashtable::get (69 bytes) 50 java.util.Arrays::mergeSort (235 bytes) 51 sun.java2d.loops.GraphicsPrimitiveMgr$1::compare (39 bytes) 52 java.util.Arrays::binarySearch (87 bytes) 53 sun.java2d.loops.GraphicsPrimitiveMgr$2::compare (39 bytes) 54 java.lang.Class::searchFields (45 bytes) 55 java.lang.String:: (20 bytes) 56 java.lang.Class::searchMethods (90 bytes) 57 sun.reflect.ClassFileAssembler::emitConstantPoolUTF8 (50 bytes) 58 ! sun.reflect.UTF8::encode (189 bytes) 59 sun.reflect.UTF8::utf8Length (81 bytes) 60 java.nio.HeapByteBuffer::_get (7 bytes) 61 java.nio.Buffer::nextGetIndex (31 bytes) 62 java.nio.Bits::getCharB (18 bytes) 63 java.nio.Bits::makeChar (12 bytes) 64 java.nio.ByteBufferAsCharBufferB::get (16 bytes) 65 java.nio.ByteBufferAsCharBufferB::ix (9 bytes) --- n java.lang.Thread::currentThread (static) From Steve.Goldman at Sun.COM Tue Aug 7 06:44:41 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Tue, 07 Aug 2007 09:44:41 -0400 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B843D1.9090605@lemote.com> References: <46B843D1.9090605@lemote.com> Message-ID: <46B87749.5000609@sun.com> chenjie wrote: > Can anybody help me with this porting problem? > > I am now porting JVM6 to mips archtecture, But meet a big problem . I > have already spended 1 week on it, but still can not solve it.can > anybody do me a favor giving me some advices? > > I currently use the JDK5 enviroment except "libjvm.so". when run > Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But > when run it with mixed mode, It happened a strange crash, this is the > error report: > > > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 > # > # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) > # Problematic frame: > # j > sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] > > siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 > > Registers: > i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 > i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 > i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 > i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 > i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 > i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 > i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 > i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc > > Top of Stack: (sp=0x7efc4624) > 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 > 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 > 0x7efc4624: 7efc4624 32592600 32592850 00000000 > 0x7efc4634: 32592648 7efc4654 00000000 7efc464c > 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 > 0x7efc4654: 2e037878 7efc4658 32412576 32412830 > 0x7efc4664: 00000000 32412588 7efc4688 7efc464c > 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 > 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf > 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 > > Instructions: (pc=0x2bf8c718) > 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c > 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 > > > Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > j > sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 > j > sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 > j > java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 > j > java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 > j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 > j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 > j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 > v ~StubRoutines::call_stub > V [libjvm.so+0x437fe0] > C 0x7efc4a80 > > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] > 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] > 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] > 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, > id=20204] > 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] > 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] > 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] > 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] > =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] > > Other Threads: > 0x10063c00 VMThread [id=20199] > 0x100ae400 WatcherThread [id=20207] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap > def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, > 0x2e490000) > eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) > from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) > to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) > tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, > 0x31fb0000) > the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) > compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, > 0x35fb0000) > the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) > No shared spaces configured. > > > VM Arguments: > jvm_args: -XX:+PrintCompilation > java_command: Java2Demo.jar > Launcher Type: generic > > Environment Variables: > JAVA_HOME=/usr/lib/jvm/sun-java > CLASSPATH=.:/usr/lib/jvm/sun-java/lib > PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin > USERNAME=loongson > LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 > SHELL=/bin/bash > DISPLAY=:0.0 > > Signal Handlers: > SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 > SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 > SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 > > > --------------- S Y S T E M --------------- > > OS:4.0 > > uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 > libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) > rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity > load average:0.98 0.82 0.60 > > CPU:total 1 , has_16k_page > > Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) > > vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, > built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 > (prerelease) (Debian 4.1.1-19) > > > > > when Run it in gdb, it stop at "invokevirtual_helper" at > "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv > is "0xfefefefe", which is sure error, the recv is assigned in > "prepare_invoke" > as follow: > if (load_receiver) { > __ andi(AT, flags, 0xff); > __ shl(AT, Interpreter::stackElementScale()); > __ add(AT, SP, AT); > __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); > __ verify_oop(recv); > } > the value of recv is the return value of "currentThread"function, which > was compiled and excuted through i2c adapt just now.the return vaule of > "currentThread" is normal as before,So I think the SP is wrong , but SP > did not > change during invoking "currentThread".So I am confused.do any body get > some advices? So on return from a compiled code the execution will pass thru the code produced by generate_return_entry_for(). This code will restore the stack pointer to the value it was when currentThread() was called eliminating any adjustment that the i2c might have done. It would also convert the return value from compiled convention to interpreter convention for the TosState for the particular return type. Is the compiled return location for oop (atos) the same as what the interpreter use? If it isn't then when the next argument is pushed the result that is pushed is will be trash. In any case I suspect that your problem is an incompatibility between compiled/interpreted that isn't properly accounted for in generate_return_entry_for(). -- Steve From chenj at lemote.com Tue Aug 7 07:10:51 2007 From: chenj at lemote.com (chenjie) Date: Tue, 07 Aug 2007 22:10:51 +0800 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B87749.5000609@sun.com> References: <46B843D1.9090605@lemote.com> <46B87749.5000609@sun.com> Message-ID: <46B87D6B.9030108@lemote.com> steve goldman ????: > chenjie wrote: > >> Can anybody help me with this porting problem? >> >> I am now porting JVM6 to mips archtecture, But meet a big problem . I >> have already spended 1 week on it, but still can not solve it.can >> anybody do me a favor giving me some advices? >> >> I currently use the JDK5 enviroment except "libjvm.so". when run >> Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But >> when run it with mixed mode, It happened a strange crash, this is the >> error report: >> >> >> >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 >> # >> # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) >> # Problematic frame: >> # j >> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] >> >> siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 >> >> Registers: >> i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 >> i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 >> i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 >> i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 >> i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 >> i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 >> i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 >> i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc >> >> Top of Stack: (sp=0x7efc4624) >> 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 >> 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 >> 0x7efc4624: 7efc4624 32592600 32592850 00000000 >> 0x7efc4634: 32592648 7efc4654 00000000 7efc464c >> 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 >> 0x7efc4654: 2e037878 7efc4658 32412576 32412830 >> 0x7efc4664: 00000000 32412588 7efc4688 7efc464c >> 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 >> 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf >> 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 >> >> Instructions: (pc=0x2bf8c718) >> 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c >> 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 >> >> >> Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> j >> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >> j >> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >> j >> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 >> j >> java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 >> j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 >> j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 >> j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x437fe0] >> C 0x7efc4a80 >> >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] >> 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] >> 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] >> 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, >> id=20204] >> 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] >> 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] >> 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] >> 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] >> =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] >> >> Other Threads: >> 0x10063c00 VMThread [id=20199] >> 0x100ae400 WatcherThread [id=20207] >> >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap >> def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, >> 0x2e490000) >> eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) >> from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) >> to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) >> tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, >> 0x31fb0000) >> the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) >> compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, >> 0x35fb0000) >> the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) >> No shared spaces configured. >> >> >> VM Arguments: >> jvm_args: -XX:+PrintCompilation >> java_command: Java2Demo.jar >> Launcher Type: generic >> >> Environment Variables: >> JAVA_HOME=/usr/lib/jvm/sun-java >> CLASSPATH=.:/usr/lib/jvm/sun-java/lib >> PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin >> USERNAME=loongson >> LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 >> SHELL=/bin/bash >> DISPLAY=:0.0 >> >> Signal Handlers: >> SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >> SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >> >> >> --------------- S Y S T E M --------------- >> >> OS:4.0 >> >> uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 >> libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) >> rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity >> load average:0.98 0.82 0.60 >> >> CPU:total 1 , has_16k_page >> >> Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) >> >> vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, >> built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 >> (prerelease) (Debian 4.1.1-19) >> >> >> >> >> when Run it in gdb, it stop at "invokevirtual_helper" at >> "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv >> is "0xfefefefe", which is sure error, the recv is assigned in >> "prepare_invoke" >> as follow: >> if (load_receiver) { >> __ andi(AT, flags, 0xff); >> __ shl(AT, Interpreter::stackElementScale()); >> __ add(AT, SP, AT); >> __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); >> __ verify_oop(recv); >> } >> the value of recv is the return value of "currentThread"function, which >> was compiled and excuted through i2c adapt just now.the return vaule of >> "currentThread" is normal as before,So I think the SP is wrong , but SP >> did not >> change during invoking "currentThread".So I am confused.do any body get >> some advices? >> > > So on return from a compiled code the execution will pass thru the code > produced by generate_return_entry_for(). This code will restore the > stack pointer to the value it was when currentThread() was called > eliminating any adjustment that the i2c might have done. It would also > convert the return value from compiled convention to interpreter > convention for the TosState for the particular return type. Is the > compiled return location for oop (atos) the same as what the interpreter > use? If it isn't then when the next argument is pushed the result that > is pushed is will be trash. In any case I suspect that your problem is > an incompatibility between compiled/interpreted that isn't properly > accounted for in generate_return_entry_for(). > > actually , I have checked for this, when execution in compiled code returned, 1)It went to"__ bind(interpreter_entry)", because there is no fpu stack. 2)SP,BCP , LVP(local variable pointer)restored to the right value which saved in "jump_from_interpretered"; 3)then it saved the result register in "set_vtos_entry_points"; 4) it went to "invokevirtual", the function be invoked have 1 parameter,but the jvm picked the "recv" from the location which the result value from "currentThread" saved in. So , I guess there are problems in other place,but I can not locate it. From Thomas.Rodriguez at Sun.COM Tue Aug 7 08:52:12 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 07 Aug 2007 08:52:12 -0700 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B87D6B.9030108@lemote.com> References: <46B843D1.9090605@lemote.com> <46B87749.5000609@sun.com> <46B87D6B.9030108@lemote.com> Message-ID: <46B8952C.3030609@sun.com> The general strategy for debugging compiler related problems is to narrow down what gets compiled using -XX:CompileOnly so that as little compiled code as possible is involved. I'd probably try it with just -XX:CompileOnly=java/lang/Thread.current and see whether it works or not. You might have to widen the number of things which get compiled if the problem is an interaction between multiple pieces of code. Also it's useful to test with -Xcomp since this forces the generation of compiled code for everything early so it makes for a more repeatable debugging experience. Once you've done that you probably want to figure out whether it happens the first time it's called or not. If it happens the first time then I think you want to trace through the whole execution of the invoke to see how it goes wrong. Since we haven't open sourced the disassembler yet PrintNMethods and PrintNativeNMethods won't give you disassembly but they will print out the bounds of the generated code that you can use to set breakpoints in generated code. Setting breakpoints before printing in nmethod.cpp would allow you to find the pc in the generated code you want to set your breakpoint at. Since you're bringing up a system from scratch it might be worth writing a little test case which tests returning all types of values from both normal Java methods and native methods and possibly with different permutations of arguments that verifies that the expected values are passed or returned. You'd probably want to run it with -XX:-Inline to make sure you're really testing returning of values and not just testing inlining. I've written this before but I don't think I kept it and I don't think we have a standard version of this in our tests either. Even if we didn't we haven't open sourced the tests yet so it wouldn't help. tom chenjie wrote: > steve goldman ????: >> chenjie wrote: >> >>> Can anybody help me with this porting problem? >>> >>> I am now porting JVM6 to mips archtecture, But meet a big problem . I >>> have already spended 1 week on it, but still can not solve it.can >>> anybody do me a favor giving me some advices? >>> >>> I currently use the JDK5 enviroment except "libjvm.so". when run >>> Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But >>> when run it with mixed mode, It happened a strange crash, this is the >>> error report: >>> >>> >>> >>> # >>> # An unexpected error has been detected by Java Runtime Environment: >>> # >>> # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 >>> # >>> # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) >>> # Problematic frame: >>> # j >>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://java.sun.com/webapps/bugreport/crash.jsp >>> # >>> >>> --------------- T H R E A D --------------- >>> >>> Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] >>> >>> siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 >>> >>> Registers: >>> i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 >>> i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 >>> i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 >>> i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 >>> i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 >>> i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 >>> i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 >>> i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc >>> >>> Top of Stack: (sp=0x7efc4624) >>> 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 >>> 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 >>> 0x7efc4624: 7efc4624 32592600 32592850 00000000 >>> 0x7efc4634: 32592648 7efc4654 00000000 7efc464c >>> 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 >>> 0x7efc4654: 2e037878 7efc4658 32412576 32412830 >>> 0x7efc4664: 00000000 32412588 7efc4688 7efc464c >>> 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 >>> 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf >>> 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 >>> >>> Instructions: (pc=0x2bf8c718) >>> 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c >>> 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 >>> >>> >>> Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> C=native code) >>> j >>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>> j >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >>> j >>> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 >>> j >>> java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 >>> j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 >>> j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 >>> j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x437fe0] >>> C 0x7efc4a80 >>> >>> >>> --------------- P R O C E S S --------------- >>> >>> Java Threads: ( => current thread ) >>> 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] >>> 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] >>> 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] >>> 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, >>> id=20204] >>> 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] >>> 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] >>> 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] >>> 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] >>> =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] >>> >>> Other Threads: >>> 0x10063c00 VMThread [id=20199] >>> 0x100ae400 WatcherThread [id=20207] >>> >>> VM state:not at safepoint (normal execution) >>> >>> VM Mutex/Monitor currently owned by a thread: None >>> >>> Heap >>> def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, >>> 0x2e490000) >>> eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) >>> from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) >>> to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) >>> tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, >>> 0x31fb0000) >>> the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) >>> compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, >>> 0x35fb0000) >>> the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) >>> No shared spaces configured. >>> >>> >>> VM Arguments: >>> jvm_args: -XX:+PrintCompilation >>> java_command: Java2Demo.jar >>> Launcher Type: generic >>> >>> Environment Variables: >>> JAVA_HOME=/usr/lib/jvm/sun-java >>> CLASSPATH=.:/usr/lib/jvm/sun-java/lib >>> PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin >>> USERNAME=loongson >>> LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 >>> SHELL=/bin/bash >>> DISPLAY=:0.0 >>> >>> Signal Handlers: >>> SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>> SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>> >>> >>> --------------- S Y S T E M --------------- >>> >>> OS:4.0 >>> >>> uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 >>> libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) >>> rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity >>> load average:0.98 0.82 0.60 >>> >>> CPU:total 1 , has_16k_page >>> >>> Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) >>> >>> vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, >>> built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 >>> (prerelease) (Debian 4.1.1-19) >>> >>> >>> >>> >>> when Run it in gdb, it stop at "invokevirtual_helper" at >>> "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv >>> is "0xfefefefe", which is sure error, the recv is assigned in >>> "prepare_invoke" >>> as follow: >>> if (load_receiver) { >>> __ andi(AT, flags, 0xff); >>> __ shl(AT, Interpreter::stackElementScale()); >>> __ add(AT, SP, AT); >>> __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); >>> __ verify_oop(recv); >>> } >>> the value of recv is the return value of "currentThread"function, which >>> was compiled and excuted through i2c adapt just now.the return vaule of >>> "currentThread" is normal as before,So I think the SP is wrong , but SP >>> did not >>> change during invoking "currentThread".So I am confused.do any body get >>> some advices? >>> >> So on return from a compiled code the execution will pass thru the code >> produced by generate_return_entry_for(). This code will restore the >> stack pointer to the value it was when currentThread() was called >> eliminating any adjustment that the i2c might have done. It would also >> convert the return value from compiled convention to interpreter >> convention for the TosState for the particular return type. Is the >> compiled return location for oop (atos) the same as what the interpreter >> use? If it isn't then when the next argument is pushed the result that >> is pushed is will be trash. In any case I suspect that your problem is >> an incompatibility between compiled/interpreted that isn't properly >> accounted for in generate_return_entry_for(). >> >> > > actually , I have checked for this, when execution in compiled code > returned, > 1)It went to"__ bind(interpreter_entry)", because there is no fpu stack. > 2)SP,BCP , LVP(local variable pointer)restored to the right value which > saved in "jump_from_interpretered"; > 3)then it saved the result register in "set_vtos_entry_points"; > 4) it went to "invokevirtual", the function be invoked have 1 > parameter,but the jvm picked the "recv" from the location which the > result value from "currentThread" saved in. > > So , I guess there are problems in other place,but I can not locate it. > From chenj at lemote.com Tue Aug 7 17:47:51 2007 From: chenj at lemote.com (chenjie) Date: Wed, 08 Aug 2007 08:47:51 +0800 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B8952C.3030609@sun.com> References: <46B843D1.9090605@lemote.com> <46B87749.5000609@sun.com> <46B87D6B.9030108@lemote.com> <46B8952C.3030609@sun.com> Message-ID: <46B912B7.2050502@lemote.com> Tom, Steve: Thank you very much, your advice are very valuable to me,I will try it later. Tom Rodriguez ????: > The general strategy for debugging compiler related problems is to > narrow down what gets compiled using -XX:CompileOnly so that as little > compiled code as possible is involved. I'd probably try it with just > -XX:CompileOnly=java/lang/Thread.current and see whether it works or > not. You might have to widen the number of things which get compiled if > the problem is an interaction between multiple pieces of code. Also > it's useful to test with -Xcomp since this forces the generation of > compiled code for everything early so it makes for a more repeatable > debugging experience. Once you've done that you probably want to figure > out whether it happens the first time it's called or not. If it happens > the first time then I think you want to trace through the whole > execution of the invoke to see how it goes wrong. Since we haven't open > sourced the disassembler yet PrintNMethods and PrintNativeNMethods won't > give you disassembly but they will print out the bounds of the generated > code that you can use to set breakpoints in generated code. Setting > breakpoints before printing in nmethod.cpp would allow you to find the > pc in the generated code you want to set your breakpoint at. > > Since you're bringing up a system from scratch it might be worth writing > a little test case which tests returning all types of values from both > normal Java methods and native methods and possibly with different > permutations of arguments that verifies that the expected values are > passed or returned. You'd probably want to run it with -XX:-Inline to > make sure you're really testing returning of values and not just testing > inlining. I've written this before but I don't think I kept it and I > don't think we have a standard version of this in our tests either. > Even if we didn't we haven't open sourced the tests yet so it wouldn't help. > > tom > > chenjie wrote: > >> steve goldman ????: >> >>> chenjie wrote: >>> >>> >>>> Can anybody help me with this porting problem? >>>> >>>> I am now porting JVM6 to mips archtecture, But meet a big problem . I >>>> have already spended 1 week on it, but still can not solve it.can >>>> anybody do me a favor giving me some advices? >>>> >>>> I currently use the JDK5 enviroment except "libjvm.so". when run >>>> Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But >>>> when run it with mixed mode, It happened a strange crash, this is the >>>> error report: >>>> >>>> >>>> >>>> # >>>> # An unexpected error has been detected by Java Runtime Environment: >>>> # >>>> # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 >>>> # >>>> # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) >>>> # Problematic frame: >>>> # j >>>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>> # >>>> >>>> --------------- T H R E A D --------------- >>>> >>>> Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] >>>> >>>> siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 >>>> >>>> Registers: >>>> i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 >>>> i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 >>>> i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 >>>> i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 >>>> i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 >>>> i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 >>>> i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 >>>> i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc >>>> >>>> Top of Stack: (sp=0x7efc4624) >>>> 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 >>>> 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 >>>> 0x7efc4624: 7efc4624 32592600 32592850 00000000 >>>> 0x7efc4634: 32592648 7efc4654 00000000 7efc464c >>>> 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 >>>> 0x7efc4654: 2e037878 7efc4658 32412576 32412830 >>>> 0x7efc4664: 00000000 32412588 7efc4688 7efc464c >>>> 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 >>>> 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf >>>> 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 >>>> >>>> Instructions: (pc=0x2bf8c718) >>>> 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c >>>> 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 >>>> >>>> >>>> Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>> C=native code) >>>> j >>>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>>> j >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >>>> j >>>> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 >>>> j >>>> java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 >>>> j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 >>>> j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 >>>> j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 >>>> v ~StubRoutines::call_stub >>>> V [libjvm.so+0x437fe0] >>>> C 0x7efc4a80 >>>> >>>> >>>> --------------- P R O C E S S --------------- >>>> >>>> Java Threads: ( => current thread ) >>>> 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] >>>> 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] >>>> 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] >>>> 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, >>>> id=20204] >>>> 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] >>>> 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] >>>> 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] >>>> 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] >>>> =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] >>>> >>>> Other Threads: >>>> 0x10063c00 VMThread [id=20199] >>>> 0x100ae400 WatcherThread [id=20207] >>>> >>>> VM state:not at safepoint (normal execution) >>>> >>>> VM Mutex/Monitor currently owned by a thread: None >>>> >>>> Heap >>>> def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, >>>> 0x2e490000) >>>> eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) >>>> from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) >>>> to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) >>>> tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, >>>> 0x31fb0000) >>>> the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) >>>> compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, >>>> 0x35fb0000) >>>> the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) >>>> No shared spaces configured. >>>> >>>> >>>> VM Arguments: >>>> jvm_args: -XX:+PrintCompilation >>>> java_command: Java2Demo.jar >>>> Launcher Type: generic >>>> >>>> Environment Variables: >>>> JAVA_HOME=/usr/lib/jvm/sun-java >>>> CLASSPATH=.:/usr/lib/jvm/sun-java/lib >>>> PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin >>>> USERNAME=loongson >>>> LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 >>>> SHELL=/bin/bash >>>> DISPLAY=:0.0 >>>> >>>> Signal Handlers: >>>> SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >>>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>>> SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>>> >>>> >>>> --------------- S Y S T E M --------------- >>>> >>>> OS:4.0 >>>> >>>> uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 >>>> libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) >>>> rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity >>>> load average:0.98 0.82 0.60 >>>> >>>> CPU:total 1 , has_16k_page >>>> >>>> Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) >>>> >>>> vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, >>>> built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 >>>> (prerelease) (Debian 4.1.1-19) >>>> >>>> >>>> >>>> >>>> when Run it in gdb, it stop at "invokevirtual_helper" at >>>> "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv >>>> is "0xfefefefe", which is sure error, the recv is assigned in >>>> "prepare_invoke" >>>> as follow: >>>> if (load_receiver) { >>>> __ andi(AT, flags, 0xff); >>>> __ shl(AT, Interpreter::stackElementScale()); >>>> __ add(AT, SP, AT); >>>> __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); >>>> __ verify_oop(recv); >>>> } >>>> the value of recv is the return value of "currentThread"function, which >>>> was compiled and excuted through i2c adapt just now.the return vaule of >>>> "currentThread" is normal as before,So I think the SP is wrong , but SP >>>> did not >>>> change during invoking "currentThread".So I am confused.do any body get >>>> some advices? >>>> >>>> >>> So on return from a compiled code the execution will pass thru the code >>> produced by generate_return_entry_for(). This code will restore the >>> stack pointer to the value it was when currentThread() was called >>> eliminating any adjustment that the i2c might have done. It would also >>> convert the return value from compiled convention to interpreter >>> convention for the TosState for the particular return type. Is the >>> compiled return location for oop (atos) the same as what the interpreter >>> use? If it isn't then when the next argument is pushed the result that >>> is pushed is will be trash. In any case I suspect that your problem is >>> an incompatibility between compiled/interpreted that isn't properly >>> accounted for in generate_return_entry_for(). >>> >>> >>> >> actually , I have checked for this, when execution in compiled code >> returned, >> 1)It went to"__ bind(interpreter_entry)", because there is no fpu stack. >> 2)SP,BCP , LVP(local variable pointer)restored to the right value which >> saved in "jump_from_interpretered"; >> 3)then it saved the result register in "set_vtos_entry_points"; >> 4) it went to "invokevirtual", the function be invoked have 1 >> parameter,but the jvm picked the "recv" from the location which the >> result value from "currentThread" saved in. >> >> So , I guess there are problems in other place,but I can not locate it. >> >> > > > From markus.karg at gmx.net Wed Aug 8 04:37:22 2007 From: markus.karg at gmx.net (Markus KARG) Date: Wed, 08 Aug 2007 13:37:22 +0200 Subject: AttachCurrentThread Crash Message-ID: <46B9AAF2.9030206@gmx.net> Hello Hotspot Community, I experienced a problem when using JNI and since nobody else was able to help me since months, and since it looks like a bug in the jvm.dll, you are my last chance. :-) In fact I am an experienced JNI user so my question is not about JNI itself but about a very complex case that makes jvm.dll crash down. So I want to discuss with you how we can solve it -- either by working around it in my code, or by adding a fix to the Hotspot VM (which seems to be the cause of the problems). I am writing a DLL in Windows XP that itself is a plugin to the desktop, a.k.a "Shell Extension". The DLL itself runs really stable (in fact I have drilled down so far that it actually does nothing anymore now, so I am pretty sure there is no bug in it since there is no more "real" code in it besides creating the Java VM). explorer.exe (i. e. the desktop process of Windows) loads the DLL, executes my code, and unloads the DLL then. So far, so good, works pretty well. But the same Windows process then loads my DLL once more, and executes it again (just as it did before). My DLL, you can imagine, is using JNI to call some Java code. Certainly I was clever enough not to create a VM twice, since I certainly know that both is impossible, either creating two VMs in the same process, or to try to create a VM after the previous VM was deleted (which I think is a bug, but anyways, that is not the point here). So I am checking first wheter there is a VM already using JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer to the JavaVM. Great. That works pretty well. But if I now try to call AttachCurrentThread to get a pointer to the Env, then the desktop totally crashs down, telling me that I tried to execute code that actually is data (I switched off Data Execution Prevention then, but now it crashs down without ANY further note, so it is not a real help). So why did that happen? I looked at the source code of the JVM and it seems as if it uses global variables very heavily in the JNI source files. I could imagine that in fact one of those pointers now (after explorer unloaded and reloaded my DLL in the same process) point to a memory page that is marked as "data" but not as "code", so when using the function pointer, windows crashs down (since the memory pointed to is presumably no more part of the process's memory map). Please help me. I do not have any idea how to fix that. As a workaround I told Windows not to ever unload my DLL (what is working), but that certainly is just a bad hack. The real solution must be to convince jvm.dll to attach the thread without crashing down. If needed, I can provide an "at most simple" project that proofs the behaviour on any Windows machine (without seriously damaging it). Thanks! Markus -- http://www.xing.com/go/invita/58469 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3505 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070808/7c71c953/attachment.bin From gbenson at redhat.com Wed Aug 8 05:07:08 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 8 Aug 2007 13:07:08 +0100 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B843D1.9090605@lemote.com> References: <46B843D1.9090605@lemote.com> Message-ID: <20070808120708.GA3742@redhat.com> chenjie wrote: > I am now porting JVM6 to mips archtecture, But meet a big problem. > I have already spended 1 week on it, but still can not solve it. > can anybody do me a favor giving me some advices? Out of interest, why JVM6 and not OpenJDK? Cheers, Gary From chenj at lemote.com Wed Aug 8 07:31:30 2007 From: chenj at lemote.com (chenjie) Date: Wed, 08 Aug 2007 22:31:30 +0800 Subject: Can anybody help me with this porting problem? In-Reply-To: <20070808120708.GA3742@redhat.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> Message-ID: <46B9D3C2.9060401@lemote.com> OpenJDK is in the plan. Gary Benson ??: > chenjie wrote: > >> I am now porting JVM6 to mips archtecture, But meet a big problem. >> I have already spended 1 week on it, but still can not solve it. >> can anybody do me a favor giving me some advices? >> > > Out of interest, why JVM6 and not OpenJDK? > > Cheers, > Gary > > > From Stephen.Bohne at Sun.COM Wed Aug 8 07:38:13 2007 From: Stephen.Bohne at Sun.COM (Steve Bohne) Date: Wed, 08 Aug 2007 10:38:13 -0400 Subject: AttachCurrentThread Crash In-Reply-To: <46B9AAF2.9030206@gmx.net> References: <46B9AAF2.9030206@gmx.net> Message-ID: <46B9D555.6060503@sun.com> Markus, Very interesting project. When your DLL gets unloaded, does jvm.dll also get unloaded? As you mentioned, if jvm.dll is getting loaded twice, even sequentially, this might cause problems. (Yes, it's a known limitation of embedding a JVM in another application. Don't know of any current activity to work on a solution for this issue, but submitted patches will be carefully considered. :)) Did you try using explicit linking (use LoadLibrary, GetProcAddress, etc) for jvm.dll so it won't automatically get unloaded when your DLL does? Are you able to catch the crash in a debugger and provide a symbolic stack trace? I have a feeling it will reflect the limitation mentioned above, so it may not lead to a solution, but it might be educational. Steve P.S. Be careful embedding Java (or any single instance runtime) in a shell extension: http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx. Many of the limitations mentioned here for CLR will also apply to Java. Markus KARG wrote: > Hello Hotspot Community, > > I experienced a problem when using JNI and since nobody else was able > to help me since months, and since it looks like a bug in the jvm.dll, > you are my last chance. :-) > > In fact I am an experienced JNI user so my question is not about JNI > itself but about a very complex case that makes jvm.dll crash down. So > I want to discuss with you how we can solve it -- either by working > around it in my code, or by adding a fix to the Hotspot VM (which > seems to be the cause of the problems). > > I am writing a DLL in Windows XP that itself is a plugin to the > desktop, a.k.a "Shell Extension". The DLL itself runs really stable > (in fact I have drilled down so far that it actually does nothing > anymore now, so I am pretty sure there is no bug in it since there is > no more "real" code in it besides creating the Java VM). explorer.exe > (i. e. the desktop process of Windows) loads the DLL, executes my > code, and unloads the DLL then. So far, so good, works pretty well. > > But the same Windows process then loads my DLL once more, and executes > it again (just as it did before). My DLL, you can imagine, is using > JNI to call some Java code. Certainly I was clever enough not to > create a VM twice, since I certainly know that both is impossible, > either creating two VMs in the same process, or to try to create a VM > after the previous VM was deleted (which I think is a bug, but > anyways, that is not the point here). > > So I am checking first wheter there is a VM already using > JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer to > the JavaVM. Great. That works pretty well. But if I now try to call > AttachCurrentThread to get a pointer to the Env, then the desktop > totally crashs down, telling me that I tried to execute code that > actually is data (I switched off Data Execution Prevention then, but > now it crashs down without ANY further note, so it is not a real > help). So why did that happen? > > I looked at the source code of the JVM and it seems as if it uses > global variables very heavily in the JNI source files. I could imagine > that in fact one of those pointers now (after explorer unloaded and > reloaded my DLL in the same process) point to a memory page that is > marked as "data" but not as "code", so when using the function > pointer, windows crashs down (since the memory pointed to is > presumably no more part of the process's memory map). > > Please help me. I do not have any idea how to fix that. As a > workaround I told Windows not to ever unload my DLL (what is working), > but that certainly is just a bad hack. The real solution must be to > convince jvm.dll to attach the thread without crashing down. > > If needed, I can provide an "at most simple" project that proofs the > behaviour on any Windows machine (without seriously damaging it). > > Thanks! > Markus > From gbenson at redhat.com Wed Aug 8 07:57:32 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 8 Aug 2007 15:57:32 +0100 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B9D3C2.9060401@lemote.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> Message-ID: <20070808145732.GB3742@redhat.com> How long have you been working at it? I'm nosy, I'm working on PPC myself, but you're obviously much further along than me. Cheers, Gary chenjie wrote: > OpenJDK is in the plan. > > Gary Benson ??: > > chenjie wrote: > > > I am now porting JVM6 to mips archtecture, But meet a big > > > problem. I have already spended 1 week on it, but still can > > > not solve it. can anybody do me a favor giving me some > > > advices? > > > > Out of interest, why JVM6 and not OpenJDK? > > > > Cheers, > > Gary From James.Melvin at Sun.COM Wed Aug 8 14:14:20 2007 From: James.Melvin at Sun.COM (James.Melvin at Sun.COM) Date: Wed, 08 Aug 2007 17:14:20 -0400 Subject: Port coordination? In-Reply-To: <46B9D3C2.9060401@lemote.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> Message-ID: <46BA322C.2060703@Sun.COM> Hi, From this forum and others, I can see there are a number of people working on the same port of HotSpot? Would it make sense to coordinate these efforts to reduce duplication, speed up time-to-market, and increase quality? Is this happening already, perhaps beyond my visibility? Can I see a show of hands from anyone working on the following ports... PPC MIPS Linux on SPARC ARM MacOSX Other? Perhaps this email can seed a more common, dedicated area somewhere on the OpenJDK website. Would this be helpful? Thanks, Jim From twisti at complang.tuwien.ac.at Wed Aug 8 14:10:21 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 08 Aug 2007 23:10:21 +0200 Subject: Port coordination? In-Reply-To: <46BA322C.2060703@Sun.COM> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> Message-ID: <1186607421.29156.11.camel@localhost.localdomain> On Wed, 2007-08-08 at 17:14 -0400, James.Melvin at Sun.COM wrote: > Hi, > > From this forum and others, I can see there are a number of people > working on the same port of HotSpot? Would it make sense to coordinate > these efforts to reduce duplication, speed up time-to-market, and > increase quality? Is this happening already, perhaps beyond my > visibility? Can I see a show of hands from anyone working on the > following ports... > > PPC > MIPS > Linux on SPARC > ARM > MacOSX > > Other? > > Perhaps this email can seed a more common, dedicated area somewhere on > the OpenJDK website. Would this be helpful? Hi! I think that is a good idea. I'm personally not porting HotSpot, but trying to use j2se as core library for CACAO on the architectures you listed above (and others too). I think this will help a lot in porting HotSpot when you know the library works. I try to write a HOWTO here: https://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK - twisti From wmeissner at gmail.com Wed Aug 8 14:20:55 2007 From: wmeissner at gmail.com (Wayne Meissner) Date: Thu, 09 Aug 2007 07:20:55 +1000 Subject: Port coordination? In-Reply-To: <46BA322C.2060703@Sun.COM> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> Message-ID: <46BA33B7.7070003@gmail.com> James.Melvin at Sun.COM wrote: > Hi, > > From this forum and others, I can see there are a number of people > working on the same port of HotSpot? Would it make sense to coordinate > these efforts to reduce duplication, speed up time-to-market, and > increase quality? Is this happening already, perhaps beyond my > visibility? Can I see a show of hands from anyone working on the > following ports... > > PPC > MIPS > Linux on SPARC > ARM > MacOSX I was doing some work on a MacOSX port with Marius Seritan - but progress has stalled on that due to a lack of time to work on it. > > Other? > > Perhaps this email can seed a more common, dedicated area somewhere on > the OpenJDK website. Would this be helpful? Yes, it would be probably be useful to have a separate area, so people know where to post questions specifically related to porting. From chenj at lemote.com Wed Aug 8 17:40:41 2007 From: chenj at lemote.com (chenjie) Date: Thu, 09 Aug 2007 08:40:41 +0800 Subject: Can anybody help me with this porting problem? In-Reply-To: <20070808145732.GB3742@redhat.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <20070808145732.GB3742@redhat.com> Message-ID: <46BA6289.3050008@lemote.com> Hi Benson, Nice to meet you , I have been working at it for 1 year, only myself too. Maybe we can help each other. ChenJie Gary Benson ??: > How long have you been working at it? I'm nosy, I'm working on > PPC myself, but you're obviously much further along than me. > > Cheers, > Gary > > chenjie wrote: > >> OpenJDK is in the plan. >> >> Gary Benson ??: >> >>> chenjie wrote: >>> >>>> I am now porting JVM6 to mips archtecture, But meet a big >>>> problem. I have already spended 1 week on it, but still can >>>> not solve it. can anybody do me a favor giving me some >>>> advices? >>>> >>> Out of interest, why JVM6 and not OpenJDK? >>> >>> Cheers, >>> Gary >>> > > > From chenj at lemote.com Wed Aug 8 17:43:55 2007 From: chenj at lemote.com (chenjie) Date: Thu, 09 Aug 2007 08:43:55 +0800 Subject: Port coordination? In-Reply-To: <46BA322C.2060703@Sun.COM> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> Message-ID: <46BA634B.3000107@lemote.com> If some one set up a project for porting coordination, I will join it. James.Melvin at Sun.COM ??: > Hi, > > From this forum and others, I can see there are a number of people > working on the same port of HotSpot? Would it make sense to coordinate > these efforts to reduce duplication, speed up time-to-market, and > increase quality? Is this happening already, perhaps beyond my > visibility? Can I see a show of hands from anyone working on the > following ports... > > PPC > MIPS > Linux on SPARC > ARM > MacOSX > > Other? > > Perhaps this email can seed a more common, dedicated area somewhere on > the OpenJDK website. Would this be helpful? > > > Thanks, > > Jim > > From chenj at lemote.com Wed Aug 8 18:45:11 2007 From: chenj at lemote.com (chenjie) Date: Thu, 09 Aug 2007 09:45:11 +0800 Subject: Can anybody help me with this porting problem? In-Reply-To: <46B912B7.2050502@lemote.com> References: <46B843D1.9090605@lemote.com> <46B87749.5000609@sun.com> <46B87D6B.9030108@lemote.com> <46B8952C.3030609@sun.com> <46B912B7.2050502@lemote.com> Message-ID: <46BA71A7.8050803@lemote.com> Thank you everybody, I have find the reason, it is really a stupid error. when return from native in native_wrapper, if the return value is a oop type, it is really the oop 's handle (address), So it needs to load the real oop from the oop addr, I forget to load it but use the return value as a oop directly . -XX:CompileOnly is quit useful, it is a pity I ignore it before. chenjie ????: > Tom, Steve: > Thank you very much, your advice are very valuable to me,I will try it > later. > > Tom Rodriguez ????: > >> The general strategy for debugging compiler related problems is to >> narrow down what gets compiled using -XX:CompileOnly so that as little >> compiled code as possible is involved. I'd probably try it with just >> -XX:CompileOnly=java/lang/Thread.current and see whether it works or >> not. You might have to widen the number of things which get compiled if >> the problem is an interaction between multiple pieces of code. Also >> it's useful to test with -Xcomp since this forces the generation of >> compiled code for everything early so it makes for a more repeatable >> debugging experience. Once you've done that you probably want to figure >> out whether it happens the first time it's called or not. If it happens >> the first time then I think you want to trace through the whole >> execution of the invoke to see how it goes wrong. Since we haven't open >> sourced the disassembler yet PrintNMethods and PrintNativeNMethods won't >> give you disassembly but they will print out the bounds of the generated >> code that you can use to set breakpoints in generated code. Setting >> breakpoints before printing in nmethod.cpp would allow you to find the >> pc in the generated code you want to set your breakpoint at. >> >> Since you're bringing up a system from scratch it might be worth writing >> a little test case which tests returning all types of values from both >> normal Java methods and native methods and possibly with different >> permutations of arguments that verifies that the expected values are >> passed or returned. You'd probably want to run it with -XX:-Inline to >> make sure you're really testing returning of values and not just testing >> inlining. I've written this before but I don't think I kept it and I >> don't think we have a standard version of this in our tests either. >> Even if we didn't we haven't open sourced the tests yet so it wouldn't help. >> >> tom >> >> chenjie wrote: >> >> >>> steve goldman ????: >>> >>> >>>> chenjie wrote: >>>> >>>> >>>> >>>>> Can anybody help me with this porting problem? >>>>> >>>>> I am now porting JVM6 to mips archtecture, But meet a big problem . I >>>>> have already spended 1 week on it, but still can not solve it.can >>>>> anybody do me a favor giving me some advices? >>>>> >>>>> I currently use the JDK5 enviroment except "libjvm.so". when run >>>>> Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But >>>>> when run it with mixed mode, It happened a strange crash, this is the >>>>> error report: >>>>> >>>>> >>>>> >>>>> # >>>>> # An unexpected error has been detected by Java Runtime Environment: >>>>> # >>>>> # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 >>>>> # >>>>> # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) >>>>> # Problematic frame: >>>>> # j >>>>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>> # >>>>> >>>>> --------------- T H R E A D --------------- >>>>> >>>>> Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] >>>>> >>>>> siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 >>>>> >>>>> Registers: >>>>> i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 >>>>> i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 >>>>> i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 >>>>> i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 >>>>> i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 >>>>> i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 >>>>> i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 >>>>> i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc >>>>> >>>>> Top of Stack: (sp=0x7efc4624) >>>>> 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 >>>>> 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 >>>>> 0x7efc4624: 7efc4624 32592600 32592850 00000000 >>>>> 0x7efc4634: 32592648 7efc4654 00000000 7efc464c >>>>> 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 >>>>> 0x7efc4654: 2e037878 7efc4658 32412576 32412830 >>>>> 0x7efc4664: 00000000 32412588 7efc4688 7efc464c >>>>> 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 >>>>> 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf >>>>> 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 >>>>> >>>>> Instructions: (pc=0x2bf8c718) >>>>> 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c >>>>> 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 >>>>> >>>>> >>>>> Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>> C=native code) >>>>> j >>>>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>>>> j >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >>>>> j >>>>> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 >>>>> j >>>>> java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 >>>>> j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 >>>>> j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 >>>>> j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 >>>>> v ~StubRoutines::call_stub >>>>> V [libjvm.so+0x437fe0] >>>>> C 0x7efc4a80 >>>>> >>>>> >>>>> --------------- P R O C E S S --------------- >>>>> >>>>> Java Threads: ( => current thread ) >>>>> 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] >>>>> 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] >>>>> 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] >>>>> 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, >>>>> id=20204] >>>>> 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] >>>>> 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] >>>>> 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] >>>>> 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] >>>>> =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] >>>>> >>>>> Other Threads: >>>>> 0x10063c00 VMThread [id=20199] >>>>> 0x100ae400 WatcherThread [id=20207] >>>>> >>>>> VM state:not at safepoint (normal execution) >>>>> >>>>> VM Mutex/Monitor currently owned by a thread: None >>>>> >>>>> Heap >>>>> def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, >>>>> 0x2e490000) >>>>> eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) >>>>> from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) >>>>> to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) >>>>> tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, >>>>> 0x31fb0000) >>>>> the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) >>>>> compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, >>>>> 0x35fb0000) >>>>> the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) >>>>> No shared spaces configured. >>>>> >>>>> >>>>> VM Arguments: >>>>> jvm_args: -XX:+PrintCompilation >>>>> java_command: Java2Demo.jar >>>>> Launcher Type: generic >>>>> >>>>> Environment Variables: >>>>> JAVA_HOME=/usr/lib/jvm/sun-java >>>>> CLASSPATH=.:/usr/lib/jvm/sun-java/lib >>>>> PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin >>>>> USERNAME=loongson >>>>> LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 >>>>> SHELL=/bin/bash >>>>> DISPLAY=:0.0 >>>>> >>>>> Signal Handlers: >>>>> SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >>>>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>>>> SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>>>> >>>>> >>>>> --------------- S Y S T E M --------------- >>>>> >>>>> OS:4.0 >>>>> >>>>> uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 >>>>> libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) >>>>> rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity >>>>> load average:0.98 0.82 0.60 >>>>> >>>>> CPU:total 1 , has_16k_page >>>>> >>>>> Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) >>>>> >>>>> vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, >>>>> built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 >>>>> (prerelease) (Debian 4.1.1-19) >>>>> >>>>> >>>>> >>>>> >>>>> when Run it in gdb, it stop at "invokevirtual_helper" at >>>>> "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv >>>>> is "0xfefefefe", which is sure error, the recv is assigned in >>>>> "prepare_invoke" >>>>> as follow: >>>>> if (load_receiver) { >>>>> __ andi(AT, flags, 0xff); >>>>> __ shl(AT, Interpreter::stackElementScale()); >>>>> __ add(AT, SP, AT); >>>>> __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); >>>>> __ verify_oop(recv); >>>>> } >>>>> the value of recv is the return value of "currentThread"function, which >>>>> was compiled and excuted through i2c adapt just now.the return vaule of >>>>> "currentThread" is normal as before,So I think the SP is wrong , but SP >>>>> did not >>>>> change during invoking "currentThread".So I am confused.do any body get >>>>> some advices? >>>>> >>>>> >>>>> >>>> So on return from a compiled code the execution will pass thru the code >>>> produced by generate_return_entry_for(). This code will restore the >>>> stack pointer to the value it was when currentThread() was called >>>> eliminating any adjustment that the i2c might have done. It would also >>>> convert the return value from compiled convention to interpreter >>>> convention for the TosState for the particular return type. Is the >>>> compiled return location for oop (atos) the same as what the interpreter >>>> use? If it isn't then when the next argument is pushed the result that >>>> is pushed is will be trash. In any case I suspect that your problem is >>>> an incompatibility between compiled/interpreted that isn't properly >>>> accounted for in generate_return_entry_for(). >>>> >>>> >>>> >>>> >>> actually , I have checked for this, when execution in compiled code >>> returned, >>> 1)It went to"__ bind(interpreter_entry)", because there is no fpu stack. >>> 2)SP,BCP , LVP(local variable pointer)restored to the right value which >>> saved in "jump_from_interpretered"; >>> 3)then it saved the result register in "set_vtos_entry_points"; >>> 4) it went to "invokevirtual", the function be invoked have 1 >>> parameter,but the jvm picked the "recv" from the location which the >>> result value from "currentThread" saved in. >>> >>> So , I guess there are problems in other place,but I can not locate it. >>> >>> >>> >> >> > > > > From chenj at lemote.com Wed Aug 8 19:04:02 2007 From: chenj at lemote.com (chenjie) Date: Thu, 09 Aug 2007 10:04:02 +0800 Subject: Can anybody help me with this porting problem? In-Reply-To: <46BA71A7.8050803@lemote.com> References: <46B843D1.9090605@lemote.com> <46B87749.5000609@sun.com> <46B87D6B.9030108@lemote.com> <46B8952C.3030609@sun.com> <46B912B7.2050502@lemote.com> <46BA71A7.8050803@lemote.com> Message-ID: <46BA7612.7000904@lemote.com> Now My porting JVM6 can run Java2Demo.jar! chenjie ????: > Thank you everybody, I have find the reason, it is really a stupid > error. when return from > native in native_wrapper, if the return value is a oop type, it is > really the oop 's handle > (address), So it needs to load the real oop from the oop addr, I forget > to load it but use the > return value as a oop directly . > > -XX:CompileOnly is quit useful, it is a pity I ignore it before. > > > > chenjie ????: > >> Tom, Steve: >> Thank you very much, your advice are very valuable to me,I will try it >> later. >> >> Tom Rodriguez ????: >> >> >>> The general strategy for debugging compiler related problems is to >>> narrow down what gets compiled using -XX:CompileOnly so that as little >>> compiled code as possible is involved. I'd probably try it with just >>> -XX:CompileOnly=java/lang/Thread.current and see whether it works or >>> not. You might have to widen the number of things which get compiled if >>> the problem is an interaction between multiple pieces of code. Also >>> it's useful to test with -Xcomp since this forces the generation of >>> compiled code for everything early so it makes for a more repeatable >>> debugging experience. Once you've done that you probably want to figure >>> out whether it happens the first time it's called or not. If it happens >>> the first time then I think you want to trace through the whole >>> execution of the invoke to see how it goes wrong. Since we haven't open >>> sourced the disassembler yet PrintNMethods and PrintNativeNMethods won't >>> give you disassembly but they will print out the bounds of the generated >>> code that you can use to set breakpoints in generated code. Setting >>> breakpoints before printing in nmethod.cpp would allow you to find the >>> pc in the generated code you want to set your breakpoint at. >>> >>> Since you're bringing up a system from scratch it might be worth writing >>> a little test case which tests returning all types of values from both >>> normal Java methods and native methods and possibly with different >>> permutations of arguments that verifies that the expected values are >>> passed or returned. You'd probably want to run it with -XX:-Inline to >>> make sure you're really testing returning of values and not just testing >>> inlining. I've written this before but I don't think I kept it and I >>> don't think we have a standard version of this in our tests either. >>> Even if we didn't we haven't open sourced the tests yet so it wouldn't help. >>> >>> tom >>> >>> chenjie wrote: >>> >>> >>> >>>> steve goldman ????: >>>> >>>> >>>> >>>>> chenjie wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Can anybody help me with this porting problem? >>>>>> >>>>>> I am now porting JVM6 to mips archtecture, But meet a big problem . I >>>>>> have already spended 1 week on it, but still can not solve it.can >>>>>> anybody do me a favor giving me some advices? >>>>>> >>>>>> I currently use the JDK5 enviroment except "libjvm.so". when run >>>>>> Java2Demo.jar of JDK5 demo with "-Xint" mode,It is quit regular, But >>>>>> when run it with mixed mode, It happened a strange crash, this is the >>>>>> error report: >>>>>> >>>>>> >>>>>> >>>>>> # >>>>>> # An unexpected error has been detected by Java Runtime Environment: >>>>>> # >>>>>> # SIGUSR1 (0xa) at pc=0x2bf8c718, pid=20197, tid=16384 >>>>>> # >>>>>> # Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b104-debug mixed mode) >>>>>> # Problematic frame: >>>>>> # j >>>>>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>>>>> # >>>>>> # If you would like to submit a bug report, please visit: >>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>> # >>>>>> >>>>>> --------------- T H R E A D --------------- >>>>>> >>>>>> Current thread (0x10020400): JavaThread "main" [_thread_in_Java, id=20197] >>>>>> >>>>>> siginfo:si_signo=10, si_errno=0, si_code=128, si_addr=0x00000000 >>>>>> >>>>>> Registers: >>>>>> i0=0x00000000, i1=0xfefeff1e, i2=0x10070354, i3=0x00000000 >>>>>> i4=0x10020ca8, i5=0x0000005a, i6=0x00000004, i7=0x10020400 >>>>>> i8=0x10020400, i9=0x00000007, i10=0xfefefefe, i11=0x32592268 >>>>>> i12=0x31fe0f38, i13=0x00000020, i14=0xfffffffe, i15=0x000000c0 >>>>>> i16=0x3259260d, i17=0x000053be, i18=0x2e034d70, i19=0x00000000 >>>>>> i20=0x00000000, i21=0x7efc46ac, i22=0x10020400, i23=0x7efc4654 >>>>>> i24=0x7efc4658, i25=0x2b18eae0, i26=0x2aac4000, i27=0x00000000 >>>>>> i28=0x2b909250, i29=0x7efc4624, i30=0x7efc4644, i31=0x2bf3cbfc >>>>>> >>>>>> Top of Stack: (sp=0x7efc4624) >>>>>> 0x7efc4604: 2ac2a968 2ab0be88 2ad69530 2b909250 >>>>>> 0x7efc4614: 00000000 10020ce8 10020400 31fb5c70 >>>>>> 0x7efc4624: 7efc4624 32592600 32592850 00000000 >>>>>> 0x7efc4634: 32592648 7efc4654 00000000 7efc464c >>>>>> 0x7efc4644: 7efc4678 2bf3cbfc 2e042080 10070354 >>>>>> 0x7efc4654: 2e037878 7efc4658 32412576 32412830 >>>>>> 0x7efc4664: 00000000 32412588 7efc4688 7efc464c >>>>>> 0x7efc4674: 7efc4680 7efc46ac 2bf416cc 2e042080 >>>>>> 0x7efc4684: 10070354 2e0338d8 7efc468c 31ff0bbf >>>>>> 0x7efc4694: 32023648 00000000 31ff0be0 7efc46c4 >>>>>> >>>>>> Instructions: (pc=0x2bf8c718) >>>>>> 0x2bf8c708: 04 00 4a 8c 10 00 8d 8d 20 08 4d 01 00 00 2e 8c >>>>>> 0x2bf8c718: 17 00 cc 11 00 00 00 00 14 00 0e 24 10 00 cd 15 >>>>>> >>>>>> >>>>>> Stack: [0x7ef78000,0x7efc8000), sp=0x7efc4624, free space=305k >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>> C=native code) >>>>>> j >>>>>> sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >>>>>> j >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >>>>>> j >>>>>> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+111 >>>>>> j >>>>>> java.nio.channels.spi.AbstractInterruptibleChannel.blockedOn(Lsun/nio/ch/Interruptible;)V+23 >>>>>> j java.nio.channels.spi.AbstractInterruptibleChannel.end(Z)V+1 >>>>>> j sun.nio.ch.FileChannelImpl.position(J)Ljava/nio/channels/FileChannel;+164 >>>>>> j sun.font.TrueTypeFont.readBlock(Ljava/nio/ByteBuffer;II)I+76 >>>>>> v ~StubRoutines::call_stub >>>>>> V [libjvm.so+0x437fe0] >>>>>> C 0x7efc4a80 >>>>>> >>>>>> >>>>>> --------------- P R O C E S S --------------- >>>>>> >>>>>> Java Threads: ( => current thread ) >>>>>> 0x101a7400 JavaThread "AWT-Shutdown" [_thread_blocked, id=20212] >>>>>> 0x10629c00 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=20211] >>>>>> 0x10602c00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=20208] >>>>>> 0x10089400 JavaThread "Low Memory Detector" daemon [_thread_blocked, >>>>>> id=20204] >>>>>> 0x10087000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=20203] >>>>>> 0x10085400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=20202] >>>>>> 0x10072000 JavaThread "Finalizer" daemon [_thread_blocked, id=20201] >>>>>> 0x10070c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=20200] >>>>>> =>0x10020400 JavaThread "main" [_thread_in_Java, id=20197] >>>>>> >>>>>> Other Threads: >>>>>> 0x10063c00 VMThread [id=20199] >>>>>> 0x100ae400 WatcherThread [id=20207] >>>>>> >>>>>> VM state:not at safepoint (normal execution) >>>>>> >>>>>> VM Mutex/Monitor currently owned by a thread: None >>>>>> >>>>>> Heap >>>>>> def new generation total 960K, used 652K [0x2dfb0000, 0x2e0b0000, >>>>>> 0x2e490000) >>>>>> eden space 896K, 65% used [0x2dfb0000, 0x2e0430f8, 0x2e090000) >>>>>> from space 64K, 100% used [0x2e0a0000, 0x2e0b0000, 0x2e0b0000) >>>>>> to space 64K, 0% used [0x2e090000, 0x2e090000, 0x2e0a0000) >>>>>> tenured generation total 4096K, used 203K [0x2e490000, 0x2e890000, >>>>>> 0x31fb0000) >>>>>> the space 4096K, 4% used [0x2e490000, 0x2e4c2c80, 0x2e4c2e00, 0x2e890000) >>>>>> compacting perm gen total 12288K, used 6098K [0x31fb0000, 0x32bb0000, >>>>>> 0x35fb0000) >>>>>> the space 12288K, 49% used [0x31fb0000, 0x325a4a18, 0x325a4c00, 0x32bb0000) >>>>>> No shared spaces configured. >>>>>> >>>>>> >>>>>> VM Arguments: >>>>>> jvm_args: -XX:+PrintCompilation >>>>>> java_command: Java2Demo.jar >>>>>> Launcher Type: generic >>>>>> >>>>>> Environment Variables: >>>>>> JAVA_HOME=/usr/lib/jvm/sun-java >>>>>> CLASSPATH=.:/usr/lib/jvm/sun-java/lib >>>>>> PATH=/usr/lib/jvm/sun-java/bin:/usr/local/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/bin >>>>>> USERNAME=loongson >>>>>> LD_LIBRARY_PATH=/usr/lib/jvm/sun-java/lib/mips32/client:/usr/lib/jvm/sun-java/lib/mips32:/usr/lib/jvm/sun-java/../lib/mips32 >>>>>> SHELL=/bin/bash >>>>>> DISPLAY=:0.0 >>>>>> >>>>>> Signal Handlers: >>>>>> SIGSEGV: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGUSR1: [libjvm.so+0x9ebf60], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGFPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGPIPE: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGILL: [libjvm.so+0x7e2b5c], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGSTKFLT: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 >>>>>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>>>>> SIGHUP: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGINT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGQUIT: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGTERM: [libjvm.so+0x7e40d4], sa_mask[0]=0xffbffeff, sa_flags=0x10000008 >>>>>> SIGCHLD: [libjvm.so+0x7ea1c0], sa_mask[0]=0x80000000, sa_flags=0x10000008 >>>>>> >>>>>> >>>>>> --------------- S Y S T E M --------------- >>>>>> >>>>>> OS:4.0 >>>>>> >>>>>> uname:Linux 2.6.18.1lemote64 #15 Tue Mar 6 08:51:02 CST 2007 mips64 >>>>>> libc:glibc 2.3.6 linuxthreads-0.10 (fixed stack) >>>>>> rlimit: STACK 2032k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity >>>>>> load average:0.98 0.82 0.60 >>>>>> >>>>>> CPU:total 1 , has_16k_page >>>>>> >>>>>> Memory: 16k page, physical 514768k(8896k free), swap 977888k(958704k free) >>>>>> >>>>>> vm_info: Java HotSpot(TM) Client VM (1.6.0-rc-b104) for linux-mips, >>>>>> built on Aug 7 2007 17:23:13 by "root" with gcc 4.1.2 20061028 >>>>>> (prerelease) (Debian 4.1.1-19) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> when Run it in gdb, it stop at "invokevirtual_helper" at >>>>>> "templateTable_mips.cpp", the "oopDesc::klass_offset_in_bytes()"of recv >>>>>> is "0xfefefefe", which is sure error, the recv is assigned in >>>>>> "prepare_invoke" >>>>>> as follow: >>>>>> if (load_receiver) { >>>>>> __ andi(AT, flags, 0xff); >>>>>> __ shl(AT, Interpreter::stackElementScale()); >>>>>> __ add(AT, SP, AT); >>>>>> __ lw(recv, AT, - Interpreter::expr_offset_in_bytes(1)); >>>>>> __ verify_oop(recv); >>>>>> } >>>>>> the value of recv is the return value of "currentThread"function, which >>>>>> was compiled and excuted through i2c adapt just now.the return vaule of >>>>>> "currentThread" is normal as before,So I think the SP is wrong , but SP >>>>>> did not >>>>>> change during invoking "currentThread".So I am confused.do any body get >>>>>> some advices? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> So on return from a compiled code the execution will pass thru the code >>>>> produced by generate_return_entry_for(). This code will restore the >>>>> stack pointer to the value it was when currentThread() was called >>>>> eliminating any adjustment that the i2c might have done. It would also >>>>> convert the return value from compiled convention to interpreter >>>>> convention for the TosState for the particular return type. Is the >>>>> compiled return location for oop (atos) the same as what the interpreter >>>>> use? If it isn't then when the next argument is pushed the result that >>>>> is pushed is will be trash. In any case I suspect that your problem is >>>>> an incompatibility between compiled/interpreted that isn't properly >>>>> accounted for in generate_return_entry_for(). >>>>> >>>>> >>>>> >>>>> >>>>> >>>> actually , I have checked for this, when execution in compiled code >>>> returned, >>>> 1)It went to"__ bind(interpreter_entry)", because there is no fpu stack. >>>> 2)SP,BCP , LVP(local variable pointer)restored to the right value which >>>> saved in "jump_from_interpretered"; >>>> 3)then it saved the result register in "set_vtos_entry_points"; >>>> 4) it went to "invokevirtual", the function be invoked have 1 >>>> parameter,but the jvm picked the "recv" from the location which the >>>> result value from "currentThread" saved in. >>>> >>>> So , I guess there are problems in other place,but I can not locate it. >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > From samkraju.java at gmail.com Wed Aug 8 19:39:10 2007 From: samkraju.java at gmail.com (Sam K. Raju) Date: Thu, 9 Aug 2007 08:09:10 +0530 Subject: Problem while building the Hotspot Compiler Message-ID: Hi All, Hi made this post to build-dev mailing list earlier but didn't got nay reply. So I am posting it here. Here is my problem. I downloaded the compiler source 'compiler-7-ea-src-b17-02_aug_2007.zip' from the download site and tried to build it in Netbeans but it showed an error message that their is no version-template.java file in the 'compiler\src\share\classes\com\sun\tools\javac\resources' directory. I had an old subversion of compiler and it had the version-template.java file. Now I want to know whether the file is intentionally removed from the bundle or by mistake. And if it is intentionally, then how can I build the source. Thanks, -- Sam K. Raju Software Engineer Mobile +919871984108 Email samkraju.java at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070809/3c53962d/attachment.html From markus.karg at gmx.net Thu Aug 9 02:12:51 2007 From: markus.karg at gmx.net (Markus KARG) Date: Thu, 09 Aug 2007 11:12:51 +0200 Subject: AttachCurrentThread Crash In-Reply-To: <46B9D555.6060503@sun.com> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> Message-ID: <46BADA93.70103@gmx.net> Steve Bohne wrote: > Very interesting project. Thank you. In fact, the target of the project is to provide a general solution that allows to write Shell Extensions in pure Java (without further knowledge of the native desktop API), and add it to either JDIC and / or OpenJDK. The Java peer of that shall be a simple API that can not only be implemented for Windows (as I do it right now) but hopefully will be implemented by others (or Sun?) for KDE, Gnome, MacOS etc. Integrating Java deeply into the desktop is one of my key interests and I wonder why there is not yet something like that already. > When your DLL gets unloaded, does jvm.dll also get unloaded? As you > mentioned, if jvm.dll is getting loaded twice, even sequentially, this > might cause problems. (Yes, it's a known limitation of embedding a > JVM in another application. Don't know of any current activity to work > on a solution for this issue, but submitted patches will be carefully > considered. :)) Unfortunately I am not understanding the jvm.dll source code well enough to provide a patch, but that limitation really is a huge problem for embedding projects like this one (which, BTW, are needed for better acceptance of Java by the end users of the applications). I tried three things: (a) Keep the JavaVM* pointer and do not load a second time, (b) Always LoadLibrary but never unload, (c) Always LoadLibrary and FreeLibrary even in the same single method. In fact, all three ways of handling procude the same problem: Everything works well (since Windows kindly maps the DLL to the same memory region ever as it seems), but AttachCurrentThread crashs down. > Did you try using explicit linking (use LoadLibrary, GetProcAddress, > etc) for jvm.dll so it won't automatically get unloaded when your DLL > does? Yes, see above. > Are you able to catch the crash in a debugger and provide a symbolic > stack trace? I have a feeling it will reflect the limitation mentioned > above, so it may not lead to a solution, but it might be educational. Unfortunately I do not know how. I have no full C++ development environment but just work with the free Microsoft Compiler plus a text editor. > Steve > > P.S. Be careful embedding Java (or any single instance runtime) in a > shell extension: > http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx. Many of > the limitations mentioned here for CLR will also apply to Java. Yes I thought about that right from the start. Maybe I will change my architecture to not use JNI in the Shell Extension, but to instead call an out-of-process COM server implementation (a server EXE) that drives JNI instead, but I did not yet do it because I feared for the performance penalties of crossing process borders. It is really a pity that JNI does not allow to create more than one VM actually, and I think a lot of JNI users would be really happy when fixing that. Maybe one day some kind programmer provides that. :-) Thanks a lot Markus > > Markus KARG wrote: > >> Hello Hotspot Community, >> >> I experienced a problem when using JNI and since nobody else was able >> to help me since months, and since it looks like a bug in the >> jvm.dll, you are my last chance. :-) >> >> In fact I am an experienced JNI user so my question is not about JNI >> itself but about a very complex case that makes jvm.dll crash down. >> So I want to discuss with you how we can solve it -- either by >> working around it in my code, or by adding a fix to the Hotspot VM >> (which seems to be the cause of the problems). >> >> I am writing a DLL in Windows XP that itself is a plugin to the >> desktop, a.k.a "Shell Extension". The DLL itself runs really stable >> (in fact I have drilled down so far that it actually does nothing >> anymore now, so I am pretty sure there is no bug in it since there is >> no more "real" code in it besides creating the Java VM). explorer.exe >> (i. e. the desktop process of Windows) loads the DLL, executes my >> code, and unloads the DLL then. So far, so good, works pretty well. >> >> But the same Windows process then loads my DLL once more, and >> executes it again (just as it did before). My DLL, you can imagine, >> is using JNI to call some Java code. Certainly I was clever enough >> not to create a VM twice, since I certainly know that both is >> impossible, either creating two VMs in the same process, or to try to >> create a VM after the previous VM was deleted (which I think is a >> bug, but anyways, that is not the point here). >> >> So I am checking first wheter there is a VM already using >> JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer to >> the JavaVM. Great. That works pretty well. But if I now try to call >> AttachCurrentThread to get a pointer to the Env, then the desktop >> totally crashs down, telling me that I tried to execute code that >> actually is data (I switched off Data Execution Prevention then, but >> now it crashs down without ANY further note, so it is not a real >> help). So why did that happen? >> >> I looked at the source code of the JVM and it seems as if it uses >> global variables very heavily in the JNI source files. I could >> imagine that in fact one of those pointers now (after explorer >> unloaded and reloaded my DLL in the same process) point to a memory >> page that is marked as "data" but not as "code", so when using the >> function pointer, windows crashs down (since the memory pointed to is >> presumably no more part of the process's memory map). >> >> Please help me. I do not have any idea how to fix that. As a >> workaround I told Windows not to ever unload my DLL (what is >> working), but that certainly is just a bad hack. The real solution >> must be to convince jvm.dll to attach the thread without crashing down. >> >> If needed, I can provide an "at most simple" project that proofs the >> behaviour on any Windows machine (without seriously damaging it). >> >> Thanks! >> Markus >> > -- http://www.xing.com/go/invita/58469 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3505 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070809/8fdd9010/attachment.bin From David.Holmes at Sun.COM Thu Aug 9 04:02:08 2007 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 09 Aug 2007 21:02:08 +1000 Subject: AttachCurrentThread Crash In-Reply-To: <46BADA93.70103@gmx.net> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> <46BADA93.70103@gmx.net> Message-ID: <46BAF430.7070201@sun.com> Markus, There was past on work on hosting multiple VM's within a single VM (with both in process and out-of-process variants). This was based around Isolates and the experimental MVM system. http://java.sun.com/developer/technicalArticles/Programming/mvm/ I don't know the end result of this work, nor whether some aspect of it is still being developed. (The sunlabs site seems to be having problems right now.) Regards, David Holmes Markus KARG said the following on 9/08/07 07:12 PM: > Steve Bohne wrote: >> Very interesting project. > Thank you. In fact, the target of the project is to provide a general > solution that allows to write Shell Extensions in pure Java (without > further knowledge of the native desktop API), and add it to either JDIC > and / or OpenJDK. The Java peer of that shall be a simple API that can > not only be implemented for Windows (as I do it right now) but hopefully > will be implemented by others (or Sun?) for KDE, Gnome, MacOS etc. > Integrating Java deeply into the desktop is one of my key interests and > I wonder why there is not yet something like that already. >> When your DLL gets unloaded, does jvm.dll also get unloaded? As you >> mentioned, if jvm.dll is getting loaded twice, even sequentially, this >> might cause problems. (Yes, it's a known limitation of embedding a >> JVM in another application. Don't know of any current activity to work >> on a solution for this issue, but submitted patches will be carefully >> considered. :)) > Unfortunately I am not understanding the jvm.dll source code well enough > to provide a patch, but that limitation really is a huge problem for > embedding projects like this one (which, BTW, are needed for better > acceptance of Java by the end users of the applications). > > I tried three things: (a) Keep the JavaVM* pointer and do not load a > second time, (b) Always LoadLibrary but never unload, (c) Always > LoadLibrary and FreeLibrary even in the same single method. In fact, all > three ways of handling procude the same problem: Everything works well > (since Windows kindly maps the DLL to the same memory region ever as it > seems), but AttachCurrentThread crashs down. >> Did you try using explicit linking (use LoadLibrary, GetProcAddress, >> etc) for jvm.dll so it won't automatically get unloaded when your DLL >> does? > Yes, see above. >> Are you able to catch the crash in a debugger and provide a symbolic >> stack trace? I have a feeling it will reflect the limitation mentioned >> above, so it may not lead to a solution, but it might be educational. > Unfortunately I do not know how. I have no full C++ development > environment but just work with the free Microsoft Compiler plus a text > editor. >> Steve >> >> P.S. Be careful embedding Java (or any single instance runtime) in a >> shell extension: >> http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx. Many of >> the limitations mentioned here for CLR will also apply to Java. > Yes I thought about that right from the start. Maybe I will change my > architecture to not use JNI in the Shell Extension, but to instead call > an out-of-process COM server implementation (a server EXE) that drives > JNI instead, but I did not yet do it because I feared for the > performance penalties of crossing process borders. > > It is really a pity that JNI does not allow to create more than one VM > actually, and I think a lot of JNI users would be really happy when > fixing that. Maybe one day some kind programmer provides that. :-) > > Thanks a lot > Markus >> >> Markus KARG wrote: >> >>> Hello Hotspot Community, >>> >>> I experienced a problem when using JNI and since nobody else was able >>> to help me since months, and since it looks like a bug in the >>> jvm.dll, you are my last chance. :-) >>> >>> In fact I am an experienced JNI user so my question is not about JNI >>> itself but about a very complex case that makes jvm.dll crash down. >>> So I want to discuss with you how we can solve it -- either by >>> working around it in my code, or by adding a fix to the Hotspot VM >>> (which seems to be the cause of the problems). >>> >>> I am writing a DLL in Windows XP that itself is a plugin to the >>> desktop, a.k.a "Shell Extension". The DLL itself runs really stable >>> (in fact I have drilled down so far that it actually does nothing >>> anymore now, so I am pretty sure there is no bug in it since there is >>> no more "real" code in it besides creating the Java VM). explorer.exe >>> (i. e. the desktop process of Windows) loads the DLL, executes my >>> code, and unloads the DLL then. So far, so good, works pretty well. >>> >>> But the same Windows process then loads my DLL once more, and >>> executes it again (just as it did before). My DLL, you can imagine, >>> is using JNI to call some Java code. Certainly I was clever enough >>> not to create a VM twice, since I certainly know that both is >>> impossible, either creating two VMs in the same process, or to try to >>> create a VM after the previous VM was deleted (which I think is a >>> bug, but anyways, that is not the point here). >>> >>> So I am checking first wheter there is a VM already using >>> JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer to >>> the JavaVM. Great. That works pretty well. But if I now try to call >>> AttachCurrentThread to get a pointer to the Env, then the desktop >>> totally crashs down, telling me that I tried to execute code that >>> actually is data (I switched off Data Execution Prevention then, but >>> now it crashs down without ANY further note, so it is not a real >>> help). So why did that happen? >>> >>> I looked at the source code of the JVM and it seems as if it uses >>> global variables very heavily in the JNI source files. I could >>> imagine that in fact one of those pointers now (after explorer >>> unloaded and reloaded my DLL in the same process) point to a memory >>> page that is marked as "data" but not as "code", so when using the >>> function pointer, windows crashs down (since the memory pointed to is >>> presumably no more part of the process's memory map). >>> >>> Please help me. I do not have any idea how to fix that. As a >>> workaround I told Windows not to ever unload my DLL (what is >>> working), but that certainly is just a bad hack. The real solution >>> must be to convince jvm.dll to attach the thread without crashing down. >>> >>> If needed, I can provide an "at most simple" project that proofs the >>> behaviour on any Windows machine (without seriously damaging it). >>> >>> Thanks! >>> Markus >>> >> > > From gbenson at redhat.com Thu Aug 9 05:45:17 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 9 Aug 2007 13:45:17 +0100 Subject: Port coordination? In-Reply-To: <46BA322C.2060703@Sun.COM> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> Message-ID: <20070809124517.GB3643@redhat.com> James.Melvin at Sun.COM wrote: > From this forum and others, I can see there are a number of people > working on the same port of HotSpot? Would it make sense to > coordinate these efforts to reduce duplication, speed up time-to- > market, and increase quality? Is this happening already, perhaps > beyond my visibility? Can I see a show of hands from anyone working > on the following ports... I'm working on getting the C++ interpreter working, initially on ppc but with a view to having it on ppc64, s390, s390x and ia64 eventually. Cheers, Gary From Steve.Goldman at Sun.COM Thu Aug 9 05:58:14 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Thu, 09 Aug 2007 08:58:14 -0400 Subject: Can anybody help me with this porting problem? In-Reply-To: <46BA71A7.8050803@lemote.com> References: <46B843D1.9090605@lemote.com> <46B87749.5000609@sun.com> <46B87D6B.9030108@lemote.com> <46B8952C.3030609@sun.com> <46B912B7.2050502@lemote.com> <46BA71A7.8050803@lemote.com> Message-ID: <46BB0F66.2010305@sun.com> chenjie wrote: > Thank you everybody, I have find the reason, it is really a stupid > error. when return from > native in native_wrapper, if the return value is a oop type, it is > really the oop 's handle > (address), So it needs to load the real oop from the oop addr, I forget > to load it but use the > return value as a oop directly Be sure not to unbox the handle until after you've checked for a pending safepoint or completed any other entry to the vm or you'll be chasing an intermittent gc failure. Not that I'm speaking from experience or anything. :-) -- Steve From gbenson at redhat.com Thu Aug 9 06:02:01 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 9 Aug 2007 14:02:01 +0100 Subject: Can anybody help me with this porting problem? In-Reply-To: <46BA6289.3050008@lemote.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <20070808145732.GB3742@redhat.com> <46BA6289.3050008@lemote.com> Message-ID: <20070809130201.GC3643@redhat.com> A year? Ouch! Ok, I feel less bad about my own slow progress now :) chenjie wrote: > Hi Benson, > Nice to meet you , I have been working at it for 1 year, only > myself too. Maybe we can help each other. > ChenJie > > Gary Benson ??: > > How long have you been working at it? I'm nosy, I'm working > > on PPC myself, but you're obviously much further along than > > me. > > > > Cheers, > > Gary From Steve.Goldman at Sun.COM Thu Aug 9 06:03:00 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Thu, 09 Aug 2007 09:03:00 -0400 Subject: Problem while building the Hotspot Compiler In-Reply-To: References: Message-ID: <46BB1084.9070600@sun.com> Sam K. Raju wrote: > Hi All, > Hi made this post to build-dev mailing list earlier but didn't got nay > reply. So I am posting it here. Here is my problem. > > I downloaded the compiler source 'compiler-7-ea-src-b17-02_aug_2007.zip' > from the download site and tried to build it in Netbeans but it showed an > error message that their is no version-template.java file in the > 'compiler\src\share\classes\com\sun\tools\javac\resources' directory. I had > an old subversion of compiler and it had the version-template.java file. > Now I want to know whether the file is intentionally removed from the > bundle or by mistake. And if it is intentionally, then how can I build the > source. You are going to have to try yet another mailing list as this one only covers the hotspot jvm. The list I think you want is at: compiler-dev at openjdk.java.net Now if you were talking about the jits and not javac this would be the place. I think most of the jvm developers are quite illiterate about building javac, I certainly am. -- Steve From twisti at complang.tuwien.ac.at Thu Aug 9 06:11:07 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 09 Aug 2007 15:11:07 +0200 Subject: Can anybody help me with this porting problem? In-Reply-To: <20070809130201.GC3643@redhat.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <20070808145732.GB3742@redhat.com> <46BA6289.3050008@lemote.com> <20070809130201.GC3643@redhat.com> Message-ID: <1186665067.25648.10.camel@c1.complang.tuwien.ac.at> On Thu, 2007-08-09 at 14:02 +0100, Gary Benson wrote: > A year? Ouch! Ok, I feel less bad about my own slow progress > now :) > > chenjie wrote: > > Hi Benson, > > Nice to meet you , I have been working at it for 1 year, only > > myself too. Maybe we can help each other. One year is rather quick for a HotSpot port, I'd say. Doing a CACAO JIT compiler port takes about half a year. And HotSpot is much more complex... - twisti From markus.karg at gmx.net Thu Aug 9 07:28:01 2007 From: markus.karg at gmx.net (Markus KARG) Date: Thu, 09 Aug 2007 16:28:01 +0200 Subject: MVM (Was: AttachCurrentThread Crash) In-Reply-To: <46BAF430.7070201@sun.com> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> <46BADA93.70103@gmx.net> <46BAF430.7070201@sun.com> Message-ID: <46BB2471.2030108@gmx.net> David Holmes - Sun Microsystems wrote: > Markus, > > There was past on work on hosting multiple VM's within a single VM > (with both in process and out-of-process variants). This was based > around Isolates and the experimental MVM system. > > http://java.sun.com/developer/technicalArticles/Programming/mvm/ > > I don't know the end result of this work, nor whether some aspect of > it is still being developed. (The sunlabs site seems to be having > problems right now.) Yes, I know about MVM quite well, but I also know that the project was stopped by Sun. I will not further speculate about the circumstances since actually it is off-topic, but since you (as a Sun employee) started this thread, here is what it looks like to me (as a non-Sun employee and Senior Architect). As ever, I mixed the facts with pure fantasy (in lack of Sun telling the truth about it), irony and sarcasm. :-) * Some Sun PhDs of Sun Labs, including Dr. Grzegorz Czajkowski (http://research.sun.com/people/czajk/), after several years finally did the unbelievable and found the holy desktop grail -- and where naive enough to tell the world about it, despite better knowing of that it will make the Java Pontifex really, really angry (For what shall someone need Solaris if the JVM becomes an OS, and what to tell Bill Gates now that finally there is that secret contract between the Windows Company and Sun, which I think could read like: "We give you money for not making Java better than dotnet"?). (http://java.sun.com/developer/technicalArticles/Programming/mvm/ ) * So the Java Church sent its best secret agent, Chet Haase, to convince the peoples of the world that Doc Greg did not really find the holy desktop grail but in fact is just a heretic and his ideas are all just blasphemous lies (http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html). * But People didn't believe Agent Chet. They still (and even more) trusted in Doc Greg. Actually they started to lapidate Agent Chet in his own blog (See Comments section on http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html). * Since the people still wanted to have the holy desktop grail getting added as a new essential part of the next release of the Java Bible (http://www.jcp.org/en/jsr/detail?id=121 and http://www.jcp.org/en/jsr/detail?id=284), the pope wrote a bull of excommunication: Doc Greg had to leave the church and now works for some Java sect, called "The Googleans". * Will the same happen to Project Looking Glass (http://www.sun.com/software/looking_glass), since it is a possible thread to the Solaris Desktop and Microsoft's Areo...? Maybe that is the reason why we didn't hear about Looking Glass for so long...? * Also I now fear for my own life, since I want to reanimate the JDIC project (that seems to be some kind of dead, see the "Is this project dead?" discussion thread in the JDIC mailing list) with some essential contributions like this one, which might be a thorn in the eyes of some Java Cardinals... * Actually now that the revolution by the Java community was successful and Java is open sourced finally, and all power is by the democratic organization of JCP.org., it keeps beeing a thrilling item how this story ends. But back to truth, in fact the Isolation API would be a wonderful solution to my problem. But since there is no Isolation API in the JRE right now, and it is not even planned to be part of JDK 7 or 8 (at least I did not read about that somewhere), it is not helping me much. Either I have to change my product to be no more in-process, or some hotspot programmers fix that ugly bug. So, we are where we still had been. :-) Have Fun Markus > > Regards, > David Holmes > > Markus KARG said the following on 9/08/07 07:12 PM: >> Steve Bohne wrote: >>> Very interesting project. >> Thank you. In fact, the target of the project is to provide a general >> solution that allows to write Shell Extensions in pure Java (without >> further knowledge of the native desktop API), and add it to either >> JDIC and / or OpenJDK. The Java peer of that shall be a simple API >> that can not only be implemented for Windows (as I do it right now) >> but hopefully will be implemented by others (or Sun?) for KDE, Gnome, >> MacOS etc. Integrating Java deeply into the desktop is one of my key >> interests and I wonder why there is not yet something like that already. >>> When your DLL gets unloaded, does jvm.dll also get unloaded? As you >>> mentioned, if jvm.dll is getting loaded twice, even sequentially, >>> this might cause problems. (Yes, it's a known limitation of >>> embedding a JVM in another application. Don't know of any current >>> activity to work on a solution for this issue, but submitted patches >>> will be carefully considered. :)) >> Unfortunately I am not understanding the jvm.dll source code well >> enough to provide a patch, but that limitation really is a huge >> problem for embedding projects like this one (which, BTW, are needed >> for better acceptance of Java by the end users of the applications). >> >> I tried three things: (a) Keep the JavaVM* pointer and do not load a >> second time, (b) Always LoadLibrary but never unload, (c) Always >> LoadLibrary and FreeLibrary even in the same single method. In fact, >> all three ways of handling procude the same problem: Everything works >> well (since Windows kindly maps the DLL to the same memory region >> ever as it seems), but AttachCurrentThread crashs down. >>> Did you try using explicit linking (use LoadLibrary, GetProcAddress, >>> etc) for jvm.dll so it won't automatically get unloaded when your >>> DLL does? >> Yes, see above. >>> Are you able to catch the crash in a debugger and provide a symbolic >>> stack trace? I have a feeling it will reflect the limitation >>> mentioned above, so it may not lead to a solution, but it might be >>> educational. >> Unfortunately I do not know how. I have no full C++ development >> environment but just work with the free Microsoft Compiler plus a >> text editor. >>> Steve >>> >>> P.S. Be careful embedding Java (or any single instance runtime) in a >>> shell extension: >>> http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx. Many >>> of the limitations mentioned here for CLR will also apply to Java. >> Yes I thought about that right from the start. Maybe I will change my >> architecture to not use JNI in the Shell Extension, but to instead >> call an out-of-process COM server implementation (a server EXE) that >> drives JNI instead, but I did not yet do it because I feared for the >> performance penalties of crossing process borders. >> >> It is really a pity that JNI does not allow to create more than one >> VM actually, and I think a lot of JNI users would be really happy >> when fixing that. Maybe one day some kind programmer provides that. :-) >> >> Thanks a lot >> Markus >>> >>> Markus KARG wrote: >>> >>>> Hello Hotspot Community, >>>> >>>> I experienced a problem when using JNI and since nobody else was >>>> able to help me since months, and since it looks like a bug in the >>>> jvm.dll, you are my last chance. :-) >>>> >>>> In fact I am an experienced JNI user so my question is not about >>>> JNI itself but about a very complex case that makes jvm.dll crash >>>> down. So I want to discuss with you how we can solve it -- either >>>> by working around it in my code, or by adding a fix to the Hotspot >>>> VM (which seems to be the cause of the problems). >>>> >>>> I am writing a DLL in Windows XP that itself is a plugin to the >>>> desktop, a.k.a "Shell Extension". The DLL itself runs really stable >>>> (in fact I have drilled down so far that it actually does nothing >>>> anymore now, so I am pretty sure there is no bug in it since there >>>> is no more "real" code in it besides creating the Java VM). >>>> explorer.exe (i. e. the desktop process of Windows) loads the DLL, >>>> executes my code, and unloads the DLL then. So far, so good, works >>>> pretty well. >>>> >>>> But the same Windows process then loads my DLL once more, and >>>> executes it again (just as it did before). My DLL, you can imagine, >>>> is using JNI to call some Java code. Certainly I was clever enough >>>> not to create a VM twice, since I certainly know that both is >>>> impossible, either creating two VMs in the same process, or to try >>>> to create a VM after the previous VM was deleted (which I think is >>>> a bug, but anyways, that is not the point here). >>>> >>>> So I am checking first wheter there is a VM already using >>>> JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer >>>> to the JavaVM. Great. That works pretty well. But if I now try to >>>> call AttachCurrentThread to get a pointer to the Env, then the >>>> desktop totally crashs down, telling me that I tried to execute >>>> code that actually is data (I switched off Data Execution >>>> Prevention then, but now it crashs down without ANY further note, >>>> so it is not a real help). So why did that happen? >>>> >>>> I looked at the source code of the JVM and it seems as if it uses >>>> global variables very heavily in the JNI source files. I could >>>> imagine that in fact one of those pointers now (after explorer >>>> unloaded and reloaded my DLL in the same process) point to a memory >>>> page that is marked as "data" but not as "code", so when using the >>>> function pointer, windows crashs down (since the memory pointed to >>>> is presumably no more part of the process's memory map). >>>> >>>> Please help me. I do not have any idea how to fix that. As a >>>> workaround I told Windows not to ever unload my DLL (what is >>>> working), but that certainly is just a bad hack. The real solution >>>> must be to convince jvm.dll to attach the thread without crashing >>>> down. >>>> >>>> If needed, I can provide an "at most simple" project that proofs >>>> the behaviour on any Windows machine (without seriously damaging it). >>>> >>>> Thanks! >>>> Markus >>>> >>> >> >> > -- http://www.xing.com/go/invita/58469 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3505 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070809/c742f205/attachment.bin From Tim.Bell at Sun.COM Thu Aug 9 09:33:29 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 09 Aug 2007 09:33:29 -0700 Subject: MVM (Was: AttachCurrentThread Crash) In-Reply-To: <46BB2471.2030108@gmx.net> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> <46BADA93.70103@gmx.net> <46BAF430.7070201@sun.com> <46BB2471.2030108@gmx.net> Message-ID: <46BB41D9.3070900@sun.com> > David Holmes - Sun Microsystems wrote: >> Markus, >> >> There was past on work on hosting multiple VM's within a single VM >> (with both in process and out-of-process variants). This was based >> around Isolates and the experimental MVM system. >> >> http://java.sun.com/developer/technicalArticles/Programming/mvm/ >> >> I don't know the end result of this work, nor whether some aspect of >> it is still being developed. (The sunlabs site seems to be having >> problems right now.) Markus KARG wrote: > Yes, I know about MVM quite well, Here is the MVM site, FWIW: https://mvm.dev.java.net/ Tim From shai.almog at gmail.com Thu Aug 9 09:45:34 2007 From: shai.almog at gmail.com (Shai Almog) Date: Thu, 9 Aug 2007 19:45:34 +0300 Subject: MVM (Was: AttachCurrentThread Crash) In-Reply-To: <46BB41D9.3070900@sun.com> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> <46BADA93.70103@gmx.net> <46BAF430.7070201@sun.com> <46BB2471.2030108@gmx.net> <46BB41D9.3070900@sun.com> Message-ID: <8ed301ba0708090945s10d778e2q11c56a76a04930b7@mail.gmail.com> > https://mvm.dev.java.net/ Downloaded it myself ;-) And while the theory is somewhat amusing the real reasons Sun didn't go with MVM are: 1. At the time desktop Java wasn't emphasized and MVM was perceived (incorrectly) as desktop oriented (as opposed to server technology). 2. It required rewriting AWT - Since Java2D was rewritten anyway to use a separate thread for the rendering pipeline and AWT can be rewritten on Swing this is no longer a problem. 3. It was a research project with very little political movers in Sun. To get something done at Sun you need someone in management pushing the idea (not an employee of Sun myself but I do lots of contracting for Sun). 4. There were many complexities especially in getting process level stability when invoking JNI code. This is possible by spawning a process for native code but this is hard to do in Windows and current code only works for Solaris Sparc. 5. Due to the above minor user experience issues start cropping up such as processes appearing correctly in the task manager and dying properly when killed... All of these are solvable in the long run and with current changes to AWT they are the exact direction for the VM. Problem is that there is no one within Sun that is pushing for this, I would love to do it myself and downloaded the code in the past but I'm just WAY too busy so unless someone wants to sponsor my work... well ;-) -- Shai Almog vPrise http://www.vprise.com/ From springer at reservoir.com Thu Aug 9 12:01:25 2007 From: springer at reservoir.com (Jonathan Springer) Date: Thu, 09 Aug 2007 14:01:25 -0500 Subject: Port coordination? In-Reply-To: <46BA322C.2060703@Sun.COM> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> Message-ID: <46BB6485.3070406@reservoir.com> James.Melvin at Sun.COM wrote: > Hi, > > From this forum and others, I can see there are a number of people > working on the same port of HotSpot? Would it make sense to coordinate > these efforts to reduce duplication, speed up time-to-market, and > increase quality? Is this happening already, perhaps beyond my > visibility? Can I see a show of hands from anyone working on the > following ports... > > PPC > MIPS > Linux on SPARC > ARM > MacOSX > > Other? Hi Jim, Reservoir Labs is working on a MIPS port of OpenJDK. Specifically, we are targeting MIPS64 right now, but we're interested in generalizing to other MIPS variants too, especially MIPS32. We are also interested in other possible architecture ports. > Perhaps this email can seed a more common, dedicated area somewhere on > the OpenJDK website. Would this be helpful? Yes, something like this sounds useful as an organizational tool. -Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From markus.karg at gmx.net Fri Aug 10 00:55:44 2007 From: markus.karg at gmx.net (Markus KARG) Date: Fri, 10 Aug 2007 09:55:44 +0200 Subject: MVM (Was: AttachCurrentThread Crash) In-Reply-To: <46BB41D9.3070900@sun.com> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> <46BADA93.70103@gmx.net> <46BAF430.7070201@sun.com> <46BB2471.2030108@gmx.net> <46BB41D9.3070900@sun.com> Message-ID: <46BC1A00.2000603@gmx.net> Tim, >> Yes, I know about MVM quite well, > Here is the MVM site, FWIW: https://mvm.dev.java.net/ Yes, and as everybody can see on that page, the latest news is older than one year... Have Fun Markus -- http://www.xing.com/go/invita/58469 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3505 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070810/b5a89de3/attachment.bin From markus.karg at gmx.net Fri Aug 10 01:06:29 2007 From: markus.karg at gmx.net (Markus KARG) Date: Fri, 10 Aug 2007 10:06:29 +0200 Subject: AttachCurrentThread Crash In-Reply-To: <46BB4D1B.6000706@Sun.COM> References: <46BA4632.9060404@Sun.COM> <46BB076C.10107@gmx.net> <46BB4D1B.6000706@Sun.COM> Message-ID: <46BC1C85.6030106@gmx.net> Xiaobin Lu schrieb: > Please refer to this http://bugs.sun.com/services/bugreport/index.jsp > for filing a bug. > > -Xiaobin You should have received the source code yesterday. I sent it to you by direct email with a ZIP attachment. Also I followed Xiaobin's directions and filed a bug report. In fact, Nelson DaCosta from Sun reacted and asked for the source code, too, so I sent it to him. Incident Review ID: 1025881 Thanks a lot Markus > > Markus KARG wrote: >> Xiaobin Lu schrieb: >>> Hi Markus, >>> >>> I am a hotspot VM developer. Could you make a test case to reproduce >>> the crash you saw? >>> >>> Thanks, >>> -Xiaobin >>> >> If you like I can send you a CPP project that produces the problem. >> Shall I send it directly to your email address as a ZIP file? >> >> Thanks >> Markus >> > -- http://www.xing.com/go/invita/58469 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3505 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070810/542a80fe/attachment.bin From shai.almog at gmail.com Fri Aug 10 01:09:05 2007 From: shai.almog at gmail.com (Shai Almog) Date: Fri, 10 Aug 2007 11:09:05 +0300 Subject: MVM (Was: AttachCurrentThread Crash) In-Reply-To: <46BC1A00.2000603@gmx.net> References: <46B9AAF2.9030206@gmx.net> <46B9D555.6060503@sun.com> <46BADA93.70103@gmx.net> <46BAF430.7070201@sun.com> <46BB2471.2030108@gmx.net> <46BB41D9.3070900@sun.com> <46BC1A00.2000603@gmx.net> Message-ID: <8ed301ba0708100109l21eb8dfen12e28eae80059d22@mail.gmail.com> > > Here is the MVM site, FWIW: https://mvm.dev.java.net/ > Yes, and as everybody can see on that page, the latest news is older > than one year... The MVM team members moved on for the most part, the only MVM work at Sun (thats public knowledge at least) is in the Java ME world where MVM is really doing well. You can see a great set of comments from the MVM team in Chet Hass's block when he wrote a disparaging post on MVM some of the MVM team commented there. Sun is reasonably open about its internal conflicts in that sense ;-) Just google for that blog and you can see both sides and some newer posts by people both for an against (my blogs for MVM also appear there). -- Shai Almog vPrise http://www.vprise.com/ From twisti at complang.tuwien.ac.at Tue Aug 21 14:07:22 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 21 Aug 2007 23:07:22 +0200 Subject: magic reflection access checks Message-ID: <1187730442.24351.13.camel@localhost.localdomain> Hi! While implementing the HotSpot interface (jvm.cpp) in CACAO and getting the tricks used in HotSpot (damn, that is a hard job), I'm now stuck at the magic access checks, like in: Reflection::verify_class_access The problem comes with reflection. The generated accessor classes, like sun/reflect/GeneratedConstructorAccessor1, get loaded and are a sub-class of sun/reflect/MagicAccessorImpl. Thus the access checks grant them access to everything: // New (1.4) reflection implementation. Allow all accesses from // sun/reflect/MagicAccessorImpl subclasses to succeed trivially. The problem I now have in CACAO is, I have to check if the currently loaded class is a sub-class of sun.reflect.MagicAccessorImpl. This check can only be done when the super-classes get resolved. But when resolving the super-classes, the access-check functions of CACAO are called (obiously, otherwise this would be a security hole) and these do: if (class_issubclass(referer, class_sun_reflect_MagicAccessorImpl)) return true; I can't do sub-class tests without the class being resolved doing the check on. My question is now, how does HotSpot handle this case? How can HotSpot do sub-class tests with a not-resolved class? - twisti From Thomas.Rodriguez at Sun.COM Tue Aug 21 14:30:01 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Aug 2007 14:30:01 -0700 Subject: magic reflection access checks In-Reply-To: <1187730442.24351.13.camel@localhost.localdomain> References: <1187730442.24351.13.camel@localhost.localdomain> Message-ID: <46CB5959.8050006@sun.com> MagicAccessorImpl is loaded as part of our bootstrap in SystemDictionary::initialize_preloaded_classes. verify_class_access will only try to use MagicAccessorImpl if this test fails: 445 if ((current_class == NULL) || 446 (current_class == new_class) || 447 (instanceKlass::cast(new_class)->is_public()) || 448 is_same_class_package(current_class, new_class)) { 449 return true; 450 } This test should never fail for any classes on the boot classpath so by the time any code needs a non null value we have it. Do you have logic equivalent to this? tom Christian Thalinger wrote: > Hi! > > While implementing the HotSpot interface (jvm.cpp) in CACAO and getting > the tricks used in HotSpot (damn, that is a hard job), I'm now stuck at > the magic access checks, like in: > > Reflection::verify_class_access > > The problem comes with reflection. The generated accessor classes, like > sun/reflect/GeneratedConstructorAccessor1, get loaded and are a > sub-class of sun/reflect/MagicAccessorImpl. Thus the access checks > grant them access to everything: > > // New (1.4) reflection implementation. Allow all accesses from > // sun/reflect/MagicAccessorImpl subclasses to succeed trivially. > > The problem I now have in CACAO is, I have to check if the currently > loaded class is a sub-class of sun.reflect.MagicAccessorImpl. This > check can only be done when the super-classes get resolved. But when > resolving the super-classes, the access-check functions of CACAO are > called (obiously, otherwise this would be a security hole) and these do: > > if (class_issubclass(referer, class_sun_reflect_MagicAccessorImpl)) > return true; > > I can't do sub-class tests without the class being resolved doing the > check on. > > My question is now, how does HotSpot handle this case? How can HotSpot > do sub-class tests with a not-resolved class? > > - twisti From twisti at complang.tuwien.ac.at Tue Aug 21 14:55:19 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 21 Aug 2007 23:55:19 +0200 Subject: magic reflection access checks In-Reply-To: <46CB5959.8050006@sun.com> References: <1187730442.24351.13.camel@localhost.localdomain> <46CB5959.8050006@sun.com> Message-ID: <1187733319.24351.19.camel@localhost.localdomain> On Tue, 2007-08-21 at 14:30 -0700, Tom Rodriguez wrote: > MagicAccessorImpl is loaded as part of our bootstrap in > SystemDictionary::initialize_preloaded_classes. verify_class_access will only > try to use MagicAccessorImpl if this test fails: > > 445 if ((current_class == NULL) || > 446 (current_class == new_class) || > 447 (instanceKlass::cast(new_class)->is_public()) || > 448 is_same_class_package(current_class, new_class)) { > 449 return true; > 450 } > > This test should never fail for any classes on the boot classpath so by the time > any code needs a non null value we have it. Do you have logic equivalent to this? Hmm, sorry, I don't see why this test should always be true for the boot classpath. Could you explain a bit more? - twisti From Thomas.Rodriguez at Sun.COM Tue Aug 21 15:10:09 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Aug 2007 15:10:09 -0700 Subject: magic reflection access checks In-Reply-To: <1187733319.24351.19.camel@localhost.localdomain> References: <1187730442.24351.13.camel@localhost.localdomain> <46CB5959.8050006@sun.com> <1187733319.24351.19.camel@localhost.localdomain> Message-ID: <46CB62C1.4060801@sun.com> I agree that wasn't clear. We are only loading these classes at this point so the access checks are only performed for supers and interfaces. Access checks for those should always pass these tests, i.e we shouldn't be inheriting from non public classes unless we are in the same package. There is a later section of verify_class_access that checks for some other special cases that I guess you could get on the bootclasspath but I think those deal with access checks for inner classes which I don't think come in to play during our bootstrap. tom Christian Thalinger wrote: > On Tue, 2007-08-21 at 14:30 -0700, Tom Rodriguez wrote: >> MagicAccessorImpl is loaded as part of our bootstrap in >> SystemDictionary::initialize_preloaded_classes. verify_class_access will only >> try to use MagicAccessorImpl if this test fails: >> >> 445 if ((current_class == NULL) || >> 446 (current_class == new_class) || >> 447 (instanceKlass::cast(new_class)->is_public()) || >> 448 is_same_class_package(current_class, new_class)) { >> 449 return true; >> 450 } >> >> This test should never fail for any classes on the boot classpath so by the time >> any code needs a non null value we have it. Do you have logic equivalent to this? > > Hmm, sorry, I don't see why this test should always be true for the boot > classpath. Could you explain a bit more? > > - twisti From twisti at complang.tuwien.ac.at Tue Aug 21 15:19:56 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 22 Aug 2007 00:19:56 +0200 Subject: magic reflection access checks In-Reply-To: <46CB62C1.4060801@sun.com> References: <1187730442.24351.13.camel@localhost.localdomain> <46CB5959.8050006@sun.com> <1187733319.24351.19.camel@localhost.localdomain> <46CB62C1.4060801@sun.com> Message-ID: <1187734796.24351.29.camel@localhost.localdomain> On Tue, 2007-08-21 at 15:10 -0700, Tom Rodriguez wrote: > I agree that wasn't clear. We are only loading these classes at this point so > the access checks are only performed for supers and interfaces. Access checks > for those should always pass these tests, i.e we shouldn't be inheriting from > non public classes unless we are in the same package. Yes, we are in the same package, but the classloader is different: (gdb) p *cls->name $3 = {hashlink = 0x0, blength = 35, text = 0xa40f60 "sun/reflect/ConstructorAccessorImpl"} (gdb) p cls->classloader $4 = (classloader *) 0x0 (gdb) p *referer->name $5 = {hashlink = 0xf6cf20, blength = 41, text = 0x10520d0 "sun/reflect/GeneratedConstructorAccessor1"} (gdb) p referer->classloader $6 = (classloader *) 0x787c00 So the is_same_class_package-check can't be true. - twisti From Thomas.Rodriguez at Sun.COM Tue Aug 21 16:05:00 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Aug 2007 16:05:00 -0700 Subject: magic reflection access checks In-Reply-To: <1187734796.24351.29.camel@localhost.localdomain> References: <1187730442.24351.13.camel@localhost.localdomain> <46CB5959.8050006@sun.com> <1187733319.24351.19.camel@localhost.localdomain> <46CB62C1.4060801@sun.com> <1187734796.24351.29.camel@localhost.localdomain> Message-ID: <46CB6F9C.90003@sun.com> I'm talking about during our bootstrap before we've generated any reflection classes that it must be true so we never try to do the MagicAccessorImpl subclass test. Once we're done with bootstrap MagicAccessorImpl is loaded so the subclass tests work fine. You originally asked how we performed access checks if MagicAccessorImpl wasn't loaded and the answer is that there's a very small window during bootstrap where it isn't loaded and during that window it isn't needed. tom Christian Thalinger wrote: > On Tue, 2007-08-21 at 15:10 -0700, Tom Rodriguez wrote: >> I agree that wasn't clear. We are only loading these classes at this point so >> the access checks are only performed for supers and interfaces. Access checks >> for those should always pass these tests, i.e we shouldn't be inheriting from >> non public classes unless we are in the same package. > > Yes, we are in the same package, but the classloader is different: > > (gdb) p *cls->name > $3 = {hashlink = 0x0, blength = 35, text = 0xa40f60 "sun/reflect/ConstructorAccessorImpl"} > (gdb) p cls->classloader > $4 = (classloader *) 0x0 > (gdb) p *referer->name > $5 = {hashlink = 0xf6cf20, blength = 41, text = 0x10520d0 "sun/reflect/GeneratedConstructorAccessor1"} > (gdb) p referer->classloader > $6 = (classloader *) 0x787c00 > > So the is_same_class_package-check can't be true. > > - twisti From twisti at complang.tuwien.ac.at Tue Aug 21 16:18:00 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 22 Aug 2007 01:18:00 +0200 Subject: magic reflection access checks In-Reply-To: <46CB6F9C.90003@sun.com> References: <1187730442.24351.13.camel@localhost.localdomain> <46CB5959.8050006@sun.com> <1187733319.24351.19.camel@localhost.localdomain> <46CB62C1.4060801@sun.com> <1187734796.24351.29.camel@localhost.localdomain> <46CB6F9C.90003@sun.com> Message-ID: <1187738280.24351.35.camel@localhost.localdomain> On Tue, 2007-08-21 at 16:05 -0700, Tom Rodriguez wrote: > I'm talking about during our bootstrap before we've generated any reflection > classes that it must be true so we never try to do the MagicAccessorImpl > subclass test. Once we're done with bootstrap MagicAccessorImpl is loaded so > the subclass tests work fine. You originally asked how we performed access > checks if MagicAccessorImpl wasn't loaded and the answer is that there's a very > small window during bootstrap where it isn't loaded and during that window it > isn't needed. Ahh, sorry, then I wasn't clear enough. I didn't mean sun/reflect/MagicAccessorImpl is not loaded, but e.g. sun/reflect/GeneratedConstructorAccessor1 isn't resolved when the access-checks happen and the sub-class test on sun/reflect/GeneratedConstructorAccessor1 does not work. But when trying to resolve sun/reflect/GeneratedConstructorAccessor1, obviously access-checks have to happen and these try to do _again_ sub-class tests on sun/reflect/GeneratedConstructorAccessor1. See the problem? And I wonder how HotSpot can do that? - twisti From Thomas.Rodriguez at Sun.COM Tue Aug 21 16:31:59 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Aug 2007 16:31:59 -0700 Subject: magic reflection access checks In-Reply-To: <1187738280.24351.35.camel@localhost.localdomain> References: <1187730442.24351.13.camel@localhost.localdomain> <46CB5959.8050006@sun.com> <1187733319.24351.19.camel@localhost.localdomain> <46CB62C1.4060801@sun.com> <1187734796.24351.29.camel@localhost.localdomain> <46CB6F9C.90003@sun.com> <1187738280.24351.35.camel@localhost.localdomain> Message-ID: <46CB75EF.30206@sun.com> > Ahh, sorry, then I wasn't clear enough. I didn't mean > sun/reflect/MagicAccessorImpl is not loaded, but e.g. > sun/reflect/GeneratedConstructorAccessor1 isn't resolved when the > access-checks happen and the sub-class test on > sun/reflect/GeneratedConstructorAccessor1 does not work. > > But when trying to resolve sun/reflect/GeneratedConstructorAccessor1, > obviously access-checks have to happen and these try to do _again_ > sub-class tests on sun/reflect/GeneratedConstructorAccessor1. > > See the problem? And I wonder how HotSpot can do that? Sorry I misunderstood. During class loading we connect up the super before we perform the access checks so the class is already in the hierarchy when we ask the question. Are you unable to ask questions like that until class loading has fully completed? tom