From pratik.patel at einfochips.com Wed Jan 2 07:40:34 2008 From: pratik.patel at einfochips.com (Pratik Patel) Date: Wed, 2 Jan 2008 21:10:34 +0530 Subject: HotSpot Porting on MIPS Message-ID: <20080102153312.3A53F3897@mail.openjdk.java.net> Hi, I have downloaded latest OpenJDK source code from OpenJDK site. I want to port JVM HotSpot on MIPS 24KE processor. I have some question regarding porting HotSpot on MIPS, I found some mails exchanges on this issue in group. 1) Where to Start porting. I mean, is there specific approach to start porting hotspot. 2) Description of HotSpot directories - I didn't find enough documentation regarding Open source HotSpot. I want to know regarding specific directories in HotSpot i.e. asm, opto, runtime, adlc, prims etc in src/share/vm. 3) I found INTEL and SPARC specific implementation in HotSpot. I would like to know what is better, porting from INTEL to MIPS or porting from SPARC to MIPS ? 4) One more thing I want to know is standard steps to port JVM for different platform. i.e. which are the new files I have to create except in cpu, os, os_cpu folders. 5) Any major Roadblock or things to take care for porting JVM on MIPS. Thanks in advance for reply. Pratik Patel -- eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose,distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated.Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc(?eInfochips?) unless sent with that express intent and with due authority of eInfochips.EInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080102/f69d0c22/attachment.html From pratik.patel at einfochips.com Thu Jan 3 07:09:52 2008 From: pratik.patel at einfochips.com (Pratik Patel) Date: Thu, 3 Jan 2008 20:39:52 +0530 Subject: HotSpot Porting on MIPS - BootStrap Loader Message-ID: <20080103150228.78F9D109B2E0@mail.openjdk.java.net> Hi, One more question on HotSpot porting on MIPS. Hotspot FAQ ( http://openjdk.java.net/groups/hotspot/faq.html ) mentions that to build HotSpot , bootstrap JDK and a JDK source is required. I was able to compile hotspot with JDK-1.5.0 as Bootstrap JDK on my Linux system. Bootstrap JDK ( jdk-6u10-ea-bin-b09-linux-i586-19_dec_2007.bin ) is available in .bin format for Linux system. Now if I want bootstrap jdk for MIPS, than from where can I get bootstrap or I have to develop it from scratch. Thanks Pratik Patel -- eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose,distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated.Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc(?eInfochips?) unless sent with that express intent and with due authority of eInfochips.EInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080103/31cbda55/attachment.html From devel.sjanki at gmail.com Thu Jan 3 07:46:24 2008 From: devel.sjanki at gmail.com (Sunil Amitkumar Janki) Date: Thu, 3 Jan 2008 16:46:24 +0100 Subject: HotSpot Porting on MIPS - BootStrap Loader In-Reply-To: <477cfa9f.40e2220a.7712.fffff9c7SMTPIN_ADDED@mx.google.com> References: <477cfa9f.40e2220a.7712.fffff9c7SMTPIN_ADDED@mx.google.com> Message-ID: <767364c50801030746s41c0f199u92be2e1c195f3b39@mail.gmail.com> On Jan 3, 2008 4:09 PM, Pratik Patel wrote: > > > > > Hi, > > > > One more question on HotSpot porting on MIPS. > > > > Hotspot FAQ ( http://openjdk.java.net/groups/hotspot/faq.html ) mentions > that to build HotSpot , bootstrap JDK and a JDK source is required. I was > able to compile hotspot with JDK-1.5.0 as Bootstrap JDK on my Linux system. > Bootstrap JDK ( jdk-6u10-ea-bin-b09-linux-i586-19_dec_2007.bin ) is > available in .bin format for Linux system. Now if I want bootstrap jdk for > MIPS, than from where can I get bootstrap or I have to develop it from > scratch. > > > > Thanks > > Pratik Patel > -- > > eInfochips Business Disclaimer: > > > > This message may contain confidential, proprietary or legally Privileged > > information. In case you are not the original intended Recipient of the > > message, you must not, directly or indirectly, use, Disclose,distribute, > > print, or copy any part of this message and you are requested to delete > > it and inform the sender. Any views expressed in this message are those > > of the individual sender unless otherwise stated.Nothing contained in > > this message shall be construed as an offer or acceptance of any offer > > by eInfochips Limited and/or eInfochips Inc("eInfochips") unless sent > > with that express intent and with due authority of eInfochips.EInfochips > > has taken enough precautions to prevent the spread of viruses. However > > the company accepts no liability for any damage caused by any virus > > transmitted by this email. > > Hi, I think all that's necessary is ecj (Eclipse compiler for Java), which is available from the Debian repositories. Then you can bootstrap an (older) IcedTea build, since newer builds require an installed IcedTea. I actually have a Debian mipsel chroot on my system and will try to see how well that works for bootstrapping an IcedTea build. I still think much missing functionality will have to be supplied, though. Regards, Sunil From bccheng at google.com Mon Jan 7 11:29:08 2008 From: bccheng at google.com (Ben Cheng) Date: Mon, 7 Jan 2008 11:29:08 -0800 Subject: weird loop formation Message-ID: Hi Everyone, Happy New Year! In addition I'd like to greet you with a C2 question. :-) Recently I found a sub-optimal loop produced by the compiler. I can reproduce the problem with the following simple toy program on X86_64: public class SimpleLoop { public SimpleLoop() { } private int incTripCount(int v) { return 1; } void loopGood(int len) { for (int i = 0; i < len;) { i += incTripCount(i); } } void loopBad(int len) { for (int i = 0; i < len;) { i += incTripCount(0); } } public static void main(String argv[]) { SimpleLoop sl = new SimpleLoop(); for (int i = 0; i < 1024*1024; i++) { sl.loopGood(1024); sl.loopBad(1024); } } } The difference between loopGood and loopBad is register pressure, where loopBad has spilled code but the other doesn't. For simplicity reasons I have disabled inlining in the command line. For loopGood, the inner loop is all good and clean (B4 branches back to B3 with jlt): 030 B3: # B6 B4 <- B2 B4 Loop: B3-B4 inner Freq: 754005 030 movq RSI, [rsp + #0] # spill 034 movl RDX, RBP # spill 036 nop # 1 bytes pad for loops and calls 037 call,static SimpleLoop::incTripCount # SimpleLoop::loopGood @ bci:10 L[0]=rsp + #0 L[1]=rsp + #8 L[2]=_ STK[0]=RBP # AllocatedObj(0x0000000040803880) 03c 03c B4: # B3 B5 <- B3 Freq: 753990 # Block is sole successor of call 03c addl RBP, RAX # int 03e cmpl RBP, [RSP + #8 (32-bit)] 042 jlt,s B3 P=0.999024 C=863065.000000 For loopBad, however, the loop body contains one more block where a simple jlt is split into an jge and jmp: 030 B3: # B7 B4 <- B2 B5 Loop: B3-B5 inner Freq: 31512.2 030 movl [rsp + #8], RDX # spill 034 movq RSI, [rsp + #0] # spill 038 xorl RDX, RDX # int 03a nop # 1 bytes pad for loops and calls 03b call,static SimpleLoop::incTripCount # SimpleLoop::loopBad @ bci:10 L[0]=rsp + #0 L[1]=rsp + #8 L[2]=_ STK[0]=RBP # AllocatedObj(0x0000000040803780) 040 040 B4: # B6 B5 <- B3 Freq: 31511.6 # Block is sole successor of call 040 addl RBP, RAX # int 042 cmpl RBP, [RSP + #8 (32-bit)] 046 jge,s B6 P=0.000973 C=133514.000000 046 048 B5: # B3 <- B4 Freq: 31480.9 048 movl RDX, [rsp + #8] # spill 04c jmp,s B3 04e B6: # N70 <- B4 B1 Freq: 30.6849 04e addq rsp, 80 # Destroy frame popq rbp testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC 059 ret I traced the compiler internals a bit and it seems that the problem is caused by poor interaction between loop construction and register allocation. In the loopGood case, B5 is also created at the first place. Since there is no spilling the dead block optimizer is able to coalesce B4/B5 into a single one. However, for loopBad the instruction at pseudo PC 048 is the result of refilling value into RDX. Its existence makes B5 non-dead thus cannot be merged with B4. It seems to me that when the loop is constructed it should avoid using a branch-over followed by a unconditional branch to begin with. In that way even with spilled code the loop will still look natural and won't use two branches to loop back. Are there any historical reasons that it is more beneficial to form the loop this way? If not, I think we want to fix it to save a couple cycles for each loop. Thanks, -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080107/b5683ad0/attachment.html From harryyale at gmail.com Mon Jan 7 15:55:21 2008 From: harryyale at gmail.com (Harry Yale) Date: Mon, 7 Jan 2008 15:55:21 -0800 Subject: Capturing the first invocation of a method Message-ID: Hi, How can I capture the moment of the very first invocation of every Java method? I have tried the following approach: In InterpreterGenerator::generate_counter_incr(), I look for the counter value 1 (actually 8 (1 << 3) because the lowest 3 bits are used for other purposes) and if so jump to a function in InterpreterRuntime (like InterpreterRuntime::frequency_counter_overflow()) which prints the name of the method. but I haven't been able to see the first invocation of non-native Java methods. Non-native Java methods seem to have a much larger counter value by the time I capture them in the above function. Am I missing another invocation path or is there a better approach? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080107/893caafd/attachment.html From volker.simonis at gmail.com Tue Jan 8 01:48:19 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Jan 2008 10:48:19 +0100 Subject: Capturing the first invocation of a method In-Reply-To: References: Message-ID: Hi Harry, you can use the option "-XX:+TraceBytecodes" which is however available in a debug build only. This will you give on output as follows: [5158714] static void java.lang.Object.() [5158714] 1 0 invokestatic 9 <()V> [5158714] 2 3 return [5158714] static void java.lang.String.() [5158714] 3 0 iconst_0 [5158714] 4 1 anewarray java/io/ObjectStreamField [5158714] 5 4 putstatic 84 [5158714] 6 7 new 105 [5158714] 7 10 dup [5158714] 8 11 aconst_null [5158714] 9 12 invokespecial 85 <> <(Ljava/lang/String$1;)V> [5158714] virtual void java.lang.String$CaseInsensitiveComparator.(jobject) [5158714] 10 0 aload_0 [5158714] 11 1 invokespecial 0 <> <()V> Now you can grep the output for the first invocation of the method you're interested in. Once you know the bytecodeindex, you can use '-XX:TraceBytecodesAt=' to start the Bytecodetrace at the given index or '-XX:StopInterpreterAt=' to stop at the given ByteCode (this only works inside a debugger!). If you want to stop at the first invocation of a compiled method, you can use the '.hotspot_compiler' file or the '-XX:CompileCommand=break,class/name.methodName' command line option (e.g. '-XX:CompileCommand=break,java/lang/StringBuffer.append' - see hotspot/src/share/vm/compiler/CompilerOracle.cpp for more details.) Hope this helps, Volker On 1/8/08, Harry Yale wrote: > Hi, > > How can I capture the moment of the very first invocation of every Java > method? > > I have tried the following approach: > > > In InterpreterGenerator::generate_counter_incr(), I look > for the counter value 1 (actually 8 (1 << 3) because the lowest 3 bits are > used for other purposes) > and if so jump to a function in InterpreterRuntime (like > InterpreterRuntime::frequency_counter_overflow()) which > prints the name of the method. > > but I haven't been able to see the first invocation of non-native Java > methods. Non-native Java methods seem to have a much larger counter value by > the time I capture them in the above function. > > Am I missing another invocation path or is there a better approach? > > Thanks. > > From harryyale at gmail.com Tue Jan 8 13:51:08 2008 From: harryyale at gmail.com (Harry Yale) Date: Tue, 8 Jan 2008 13:51:08 -0800 Subject: Capturing the first invocation of a method In-Reply-To: References: Message-ID: Hi Volker, It sure would help in another context. But I need to capture first invocations of methods on-the-fly internally in the VM code rather than externally from the debugger or after-the-fast in the log. Sorry about that if my intention wasn't clear. Thanks, Harry On Jan 8, 2008 1:48 AM, Volker Simonis wrote: > Hi Harry, > > you can use the option "-XX:+TraceBytecodes" which is however > available in a debug build only. This will you give on output as > follows: > > [5158714] static void java.lang.Object.() > [5158714] 1 0 invokestatic 9 <()V> > [5158714] 2 3 return > > [5158714] static void java.lang.String.() > [5158714] 3 0 iconst_0 > [5158714] 4 1 anewarray java/io/ObjectStreamField > [5158714] 5 4 putstatic 84 > [5158714] 6 7 new 105 > [5158714] 7 10 dup > [5158714] 8 11 aconst_null > [5158714] 9 12 invokespecial 85 <> <(Ljava/lang/String$1;)V> > > [5158714] virtual void > java.lang.String$CaseInsensitiveComparator.(jobject) > [5158714] 10 0 aload_0 > [5158714] 11 1 invokespecial 0 <> <()V> > > Now you can grep the output for the first invocation of the method > you're interested in. Once you know the bytecodeindex, you can use > '-XX:TraceBytecodesAt=' to start the Bytecodetrace at > the given index or '-XX:StopInterpreterAt=' to stop at > the given ByteCode (this only works inside a debugger!). > > If you want to stop at the first invocation of a compiled method, you > can use the '.hotspot_compiler' file or the > '-XX:CompileCommand=break,class/name.methodName' command line option > (e.g. '-XX:CompileCommand=break,java/lang/StringBuffer.append' - see > hotspot/src/share/vm/compiler/CompilerOracle.cpp for more details.) > > Hope this helps, > Volker > > > On 1/8/08, Harry Yale wrote: > > Hi, > > > > How can I capture the moment of the very first invocation of every Java > > method? > > > > I have tried the following approach: > > > > > > In InterpreterGenerator::generate_counter_incr(), I look > > for the counter value 1 (actually 8 (1 << 3) because the lowest 3 bits are > > used for other purposes) > > and if so jump to a function in InterpreterRuntime (like > > InterpreterRuntime::frequency_counter_overflow()) which > > prints the name of the method. > > > > but I haven't been able to see the first invocation of non-native Java > > methods. Non-native Java methods seem to have a much larger counter value by > > the time I capture them in the above function. > > > > Am I missing another invocation path or is there a better approach? > > > > Thanks. > > > > > From Tim.Bell at Sun.COM Tue Jan 8 14:33:23 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 08 Jan 2008 14:33:23 -0800 Subject: Capturing the first invocation of a method In-Reply-To: References: Message-ID: <4783FA33.9070102@sun.com> Harry Yale wrote: > [...] I need to capture first > invocations of methods > on-the-fly internally in the VM code rather than externally from the > debugger or after-the-fast in the log. I'm not sure writing a JVM TI agent would qualify as 'in the VM'. I hope so. It would be running in the same address space. Take a look here: http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/ Search for 'ClassFileLoadHook', 'BCI', 'java_crw_demo' HTH - Tim From Chuck.Rasbold at Sun.COM Tue Jan 8 16:04:28 2008 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Tue, 08 Jan 2008 16:04:28 -0800 Subject: weird loop formation In-Reply-To: References: Message-ID: <47840F8C.2@Sun.COM> Ben - Thanks for your comment, and we've shared your concern for a while. While I don't have the perspective to give the full historical background, the strategy within C2 has been first to fully populate the Ideal graph with all regions. Loop construction/optimization occurs in the Ideal graph, then after code generation, the CFG is formed and all MachNodes are assigned to basic blocks. This is a little different than other, more traditional compilers that I'm familiar with. As for your specific example, we see the path to code improvement in cases like this one in two steps: - Teach the register spiller to be more disinclined to placing spills along the back branches. This is part of a bigger effort in the near term to improving C2's spilling decisions. - Augment the the dead-block optimizer with a block layout pass in addition to the dead-block and peephole tweeks that you've observed. In the case where spill code is placed along the backbranch, the block layout pass would rotate the loop such that basic blocks that end in an unconditional branch would be moved to the top, eliminating the branch-over on each iteration. Of course, the compiler is likely to generate a branch-over at loop entry in this case, but that is a one-time cost. This work is in progress. For example, for loopBad, even with the extra spill, we'd want the code to come out more like this: B3: # B4 <- B5 Loop: B3-B5 inner Freq: 31480.9 movl RDX, [rsp + #8] # spill B4: # B7 B5 <- B2 B3 Freq: 31512.2 movl [rsp + #8], RDX # spill movq RSI, [rsp + #0] # spill xorl RDX, RDX # int nop # 1 bytes pad for loops and calls call,static SimpleLoop::incTripCount # SimpleLoop::loopBad @ bci:10 L[0]=rsp + #0 L[1]=rsp + #8 L[2]=_ STK[0]=RBP # AllocatedObj(0x0000000040803780) B5: # B6 B3 <- B4 Freq: 31511.6 # Block is sole successor of call addl RBP, RAX # int cmpl RBP, [RSP + #8 (32-bit)] jlt,s B5 P=0.000973 C=133514.000000 -- Chuck (We probably should move any further discussion to hotspot-compiler-dev) Ben Cheng wrote: > Hi Everyone, > > Happy New Year! In addition I'd like to greet you with a C2 question. :-) > > Recently I found a sub-optimal loop produced by the compiler. I can > reproduce the problem with the following simple toy program on X86_64: > > public class SimpleLoop { > > public SimpleLoop() { > } > > private int incTripCount(int v) { > return 1; > } > > void loopGood(int len) { > for (int i = 0; i < len;) { > i += incTripCount(i); > } > } > > void loopBad(int len) { > for (int i = 0; i < len;) { > i += incTripCount(0); > } > } > > public static void main(String argv[]) { > SimpleLoop sl = new SimpleLoop(); > for (int i = 0; i < 1024*1024; i++) { > sl.loopGood(1024); > sl.loopBad(1024); > } > } > } > > The difference between loopGood and loopBad is register pressure, where > loopBad has spilled code but the other doesn't. For simplicity reasons I > have disabled inlining in the command line. > > For loopGood, the inner loop is all good and clean (B4 branches back to > B3 with jlt): > > > 030 B3: # B6 B4 <- B2 B4 Loop: B3-B4 inner Freq: 754005 > 030 movq RSI, [rsp + #0] # spill > 034 movl RDX, RBP # spill > 036 nop # 1 bytes pad for loops and calls > 037 call,static SimpleLoop::incTripCount > # SimpleLoop::loopGood @ bci:10 L[0]=rsp + #0 L[1]=rsp + #8 > L[2]=_ STK[0]=RBP > # AllocatedObj(0x0000000040803880) > > 03c > 03c B4: # B3 B5 <- B3 Freq: 753990 > # Block is sole successor of call > 03c addl RBP, RAX # int > 03e cmpl RBP, [RSP + #8 (32-bit)] > 042 jlt,s B3 P=0.999024 C=863065.000000 > > For loopBad, however, the loop body contains one more block where a > simple jlt is split into an jge and jmp: > > 030 B3: # B7 B4 <- B2 B5 Loop: B3-B5 inner Freq: 31512.2 > 030 movl [rsp + #8], RDX # spill > 034 movq RSI, [rsp + #0] # spill > 038 xorl RDX, RDX # int > 03a nop # 1 bytes pad for loops and calls > 03b call,static SimpleLoop::incTripCount > # SimpleLoop::loopBad @ bci:10 L[0]=rsp + #0 L[1]=rsp + #8 > L[2]=_ STK[0]=RBP > # AllocatedObj(0x0000000040803780) > > 040 > 040 B4: # B6 B5 <- B3 Freq: 31511.6 > # Block is sole successor of call > 040 addl RBP, RAX # int > 042 cmpl RBP, [RSP + #8 (32-bit)] > 046 jge,s B6 P=0.000973 C=133514.000000 > 046 > 048 B5: # B3 <- B4 Freq: 31480.9 > 048 movl RDX, [rsp + #8] # spill > 04c jmp,s B3 > > 04e B6: # N70 <- B4 B1 Freq: 30.6849 > 04e addq rsp, 80 # Destroy frame > popq rbp > testl rax, [rip + #offset_to_poll_page] # Safepoint: > poll for GC > > 059 ret > > I traced the compiler internals a bit and it seems that the problem is > caused by poor interaction between loop construction and register > allocation. In the loopGood case, B5 is also created at the first place. > Since there is no spilling the dead block optimizer is able to coalesce > B4/B5 into a single one. However, for loopBad the instruction at pseudo > PC 048 is the result of refilling value into RDX. Its existence makes B5 > non-dead thus cannot be merged with B4. > > It seems to me that when the loop is constructed it should avoid using a > branch-over followed by a unconditional branch to begin with. In that > way even with spilled code the loop will still look natural and won't > use two branches to loop back. Are there any historical reasons that it > is more beneficial to form the loop this way? If not, I think we want to > fix it to save a couple cycles for each loop. > > Thanks, > -Ben From harryyale at gmail.com Wed Jan 9 15:48:00 2008 From: harryyale at gmail.com (Harry Yale) Date: Wed, 9 Jan 2008 15:48:00 -0800 Subject: Capturing the first invocation of a method In-Reply-To: <4783FA33.9070102@sun.com> References: <4783FA33.9070102@sun.com> Message-ID: After all, I was able to make it work in my original way :) I was overlooking that fact that flag "ProfileInterpreter" being true caused my code to skipped over for non-native methods. JVMTI might be an option though I'm not sure I can access the C++ Hotspot code from the JVMTI native code, which I need to do. Thanks, Tim and Tom. On Jan 8, 2008 2:33 PM, Tim Bell wrote: > Harry Yale wrote: > > > [...] I need to capture first > > invocations of methods > > on-the-fly internally in the VM code rather than externally from the > > debugger or after-the-fast in the log. > > I'm not sure writing a JVM TI agent would qualify as 'in the VM'. I hope so. It would be > running in the same address space. Take a look here: > > http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/ > > Search for 'ClassFileLoadHook', 'BCI', 'java_crw_demo' > > HTH - Tim > -- Harry From jackieict at gmail.com Fri Jan 11 18:16:16 2008 From: jackieict at gmail.com (zhang Jackie) Date: Sat, 12 Jan 2008 10:16:16 +0800 Subject: the connection between JVM buffer and java heap? Message-ID: <13432ab00801111816g23f3c3f5x16bdd5bc4b06627f@mail.gmail.com> hi are these two the same,or different? When sending data from Java , the data is copied from java heap to JVM buffer and then give it to OS . is this right? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080112/0abae725/attachment.html From Alan.Bateman at Sun.COM Sat Jan 12 03:44:13 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 12 Jan 2008 11:44:13 +0000 Subject: the connection between JVM buffer and java heap? In-Reply-To: <13432ab00801111816g23f3c3f5x16bdd5bc4b06627f@mail.gmail.com> References: <13432ab00801111816g23f3c3f5x16bdd5bc4b06627f@mail.gmail.com> Message-ID: <4788A80D.6070606@sun.com> zhang Jackie wrote: > hi > are these two the same,or different? When sending data from Java , > the data is copied from java heap to JVM buffer and then give it to OS > . is this right? > > Thanks When you say "JVM buffer" do you mean a byte array or java.nio.ByteBuffer used for I/O? If so, then it depends on the API/library. For the stream-based APIs (java.io or java.net) the buffers are byte arrays in the java heap. I/O is done using a temporary stack-allocated or malloc'ed buffer so it is necessary to copy to or from the byte array in the java heap. For NIO it depends on if the byte buffer is direct or non-direct. Direct buffers reside outside of the garbage collected heap and they can be used directly for I/O (no coping to/from temporary buffers). Non-direct buffers have a backing array in the heap and are copied to/from a temporary direct buffers when doing I/O. -Alan. From Stephen.Bohne at Sun.COM Thu Jan 31 08:05:25 2008 From: Stephen.Bohne at Sun.COM (Steve Bohne) Date: Thu, 31 Jan 2008 11:05:25 -0500 Subject: Review request (XXXS) 6598190: JPRT tests fail when run with -XX:+CheckUnhandledOops Message-ID: <47A1F1C5.6030506@sun.com> Any review is appreciated, should be an easy one. Fixed 6598190: JPRT tests fail when run with -XX:+CheckUnhandledOops http://j2se.east/~sbohne/webrev/6598190/ Due to Sun Studio 11 C++ compiler bug 6629277, there is a missing destructor call for a temporary object in the case statement in DepChange::ContextStream::next() in dependencies.cpp. This causes the oop referred to by the temp object to not get unregistered, resulting in failed assert in UnhandledOops::clear_unhandled_oops(). The fix is to work around the compiler bug by adding curly brackets around the affected clause in the case statement. Reviewed by: Fix verified (y/n): y Verification testing: PRT fastdebug w/ -XX:+CheckUnhandledOops Other testing: JPRT Thanks, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 6598190.diff.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080131/72aa989b/attachment.txt From prasad1310 at hotmail.com Thu Jan 31 08:17:50 2008 From: prasad1310 at hotmail.com (Prasad Kulkarni) Date: Thu, 31 Jan 2008 11:17:50 -0500 Subject: hotspot build instructions Message-ID: Hi, I am attempting to install hotspot, and use it for some of our research. Although I have downloaded all the source files, the link to the "instructions for building Hotspot VM" does not seem to work for me. I am trying to open the link from the FAQ page at: http://openjdk.java.net/groups/hotspot/faq.html The link for instructions for linux points to: http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 I will greatly appreciate if it could be possible to fix the link, or for some one to send me their copy of the build instructions. thank you, Prasad _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan From volker.simonis at gmail.com Thu Jan 31 08:35:31 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 31 Jan 2008 17:35:31 +0100 Subject: hotspot build instructions In-Reply-To: References: Message-ID: Hi Prasad, for me the link works, but http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 is a small shell script. I've never used it and I don't now if it can be helpfull, but you may want to follow: http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html Regards, Volker On 1/31/08, Prasad Kulkarni wrote: > > Hi, > > I am attempting to install hotspot, and use it for some of our research. > Although I have downloaded all the source files, the link to the "instructions > for building Hotspot VM" does not seem to work for me. I am trying to open the > link from the FAQ page at: > http://openjdk.java.net/groups/hotspot/faq.html > > The link for instructions for linux points to: > http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 > > I will greatly appreciate if it could be possible to fix the link, or for some > one to send me their copy of the build instructions. > > thank you, > Prasad > > _________________________________________________________________ > Climb to the top of the charts! Play the word scramble challenge with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan From Stephen.Bohne at Sun.COM Thu Jan 31 11:44:04 2008 From: Stephen.Bohne at Sun.COM (Steve Bohne) Date: Thu, 31 Jan 2008 14:44:04 -0500 Subject: Review request again -- 6655385 Disable frame pointer omission in jvm.dll on Windows Message-ID: <47A22504.9020609@sun.com> Comments welcome. Fixed 6655385: Disable frame pointer omission in jvm.dll on Windows for better crash logs http://j2se.east/~sbohne/webrev/6655385 The C++ compiler option /Oy- is now used when building jvm.dll on Windows. This has the effect of better quality crash logs involving jvm.dll. Previously, only the youngest jvm.dll frame could be displayed, now we'll get a full stack trace. The idea is that this should help quite a bit in diagnosing Windows crashes where only the crash log (and no crash dump) is available, as is frequently the case with Windows bug reports. Although Alacrity and other performance testing results were reasonable, there is a small performance risk associated with this change. Since ebp is no longer used as a general register by the C++ compiler, there is an effect on generated (C++) code. As mentioned above, Alacrity results were unremarkable (see bug comments for links to results). Reference workload server testing on Intel and AMD machines showed a few intermittent blips on jvm98, although these were not consistently reproducible. PrintGCStats showed <5% increase in total GC time in a few cases, although in these cases the overall benchmark score was not affected. More detail can be found in the bug report comments. In summary, the performance results aren't perfect, but they are acceptable. Reviewed by: Fix verified (y/n): y Verification testing: Crashing testcase generated full stack trace in hs_err_pid.log Other testing: JPRT Alacrity refWorkload jvm98/jbb2000/jbb2005 on Win32/64 Thanks, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 6655385.diff.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080131/ec1ae1a2/attachment.txt From feng.xian at gmail.com Thu Jan 31 12:22:49 2008 From: feng.xian at gmail.com (Feng Xian) Date: Thu, 31 Jan 2008 14:22:49 -0600 Subject: hotspot build instructions In-Reply-To: References: Message-ID: <610b3d450801311222r1fff0453i114a765df2a8d04b@mail.gmail.com> I also wrote a short article which gives some resources related to openjdk build. http://docs.google.com/View?docid=dfpvmx4v_4fv5z7h If you build openjdk in 64-bit machine, you might run into some problems that Volker didnt mention. On 1/31/08, Volker Simonis wrote: > > Hi Prasad, > > for me the link works, but > http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 is a > small shell script. I've never used it and I don't now if it can be > helpfull, but you may want to follow: > > http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html > > Regards, > Volker > > On 1/31/08, Prasad Kulkarni wrote: > > > > Hi, > > > > I am attempting to install hotspot, and use it for some of our research. > > Although I have downloaded all the source files, the link to the > "instructions > > for building Hotspot VM" does not seem to work for me. I am trying to > open the > > link from the FAQ page at: > > http://openjdk.java.net/groups/hotspot/faq.html > > > > The link for instructions for linux points to: > > http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 > > > > I will greatly appreciate if it could be possible to fix the link, or > for some > > one to send me their copy of the build instructions. > > > > thank you, > > Prasad > > > > _________________________________________________________________ > > Climb to the top of the charts! Play the word scramble challenge with > star power. > > > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan > -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080131/adee8446/attachment.html From Peter.Kessler at Sun.COM Thu Jan 31 22:23:34 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 31 Jan 2008 22:23:34 -0800 Subject: hotspot build instructions In-Reply-To: References: Message-ID: <47A2BAE6.50106@Sun.COM> I wrote osse-build-linux-i586 back when all we had out in the open was the HotSpot source code. It's been superseded by all the good work people have done making it easy (possible) to build HotSpot as part of building the whole OpenJDK. Do you want to build just HotSpot (the JVM, no class libraries) or do you want to build the whole JDK? If so, you might want to post questions on build-dev at openjdk.java.net. I'll take a note to clean up old http://openjdk.java.net/groups/hotspot web pages, but it won't make it to the top of my stack soon. ... peter Prasad Kulkarni wrote: > Hi, > > I am attempting to install hotspot, and use it for some of our research. > Although I have downloaded all the source files, the link to the "instructions > for building Hotspot VM" does not seem to work for me. I am trying to open the > link from the FAQ page at: > http://openjdk.java.net/groups/hotspot/faq.html > > The link for instructions for linux points to: > http://openjdk.java.net/groups/hotspot/osse-build-linux-i586 > > I will greatly appreciate if it could be possible to fix the link, or for some > one to send me their copy of the build instructions. > > thank you, > Prasad