From christian.thalinger at gmail.com Fri Jan 2 06:53:23 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Fri, 02 Jan 2009 15:53:23 +0100 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: <49567F99.4000003@sun.com> References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> <49567F99.4000003@sun.com> Message-ID: <1230908003.2728.1.camel@localhost.localdomain> On Sat, 2008-12-27 at 14:18 -0500, James Melvin wrote: > Hi Christian, > > Hotspot productization is largely date-driven to align with other > software deliveries or hardware launches. Thus, such milestones can't be > public. Hotspot features are mostly on a train model... when ready, they > get picked up and delivered in the next release, or in some cases > 'turned on'. > > At the moment, HS15 is open for business, but is not yet fully planned. > It's a great time to integrate features and higher risk bugfixes that > require more extended bake time to fully stabilize. January will be a > good time to assess the progress of various projects and determine which > might align best with HS15. The challenge is the endgame is currently > undefined and depends on several moving targets several months into > 2009. Java is a pretty big ecosystem with Hotspot at the center. > > Although not definitive, I hope this helps provide some additional > context for Hotspot releases and how things are basically managed. > Going forward, we hope to externalize more of the process to the extent > it's possible and there is sufficient bandwidth to manage things. This > will help improve both transparency and participation. Thanks for the information. This is indeed helpful. - Christian From doko at ubuntu.com Sun Jan 4 13:59:32 2009 From: doko at ubuntu.com (Matthias Klose) Date: Sun, 04 Jan 2009 22:59:32 +0100 Subject: how to build without precompiled headers? Message-ID: <49613144.90706@ubuntu.com> Trying to track down an ICE (internal compiler error), I need to build hotspot without precompiled header files. There is a macro USE_PRECOMPILED_HEADER defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just removing the conditional around this definition still builds using precompiled header files. How can you build without precompiled header files (even if it's a hack)? Matthias From xinweix at cse.unsw.edu.au Sun Jan 4 21:32:58 2009 From: xinweix at cse.unsw.edu.au (xinweix at cse.unsw.edu.au) Date: Mon, 5 Jan 2009 13:32:58 +0800 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. Message-ID: Hi Volker, Happy New Year. Sorry to bother you. Thank you for your attention. I found your email about Hotspot build instruction from the hotspot-dev maillist and your blog. I do appreciate your great help. However, I still can't quite understand the mechanism of the interpreter in hotspot. May I ask you some questions? 1) I used ddd, a graphic based client of gdb, to set up some breakpoints and stepped into the hotspot jvm. I can find how exactly the bytecode is executed, just like the following maillist: http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results .Do you have some idea about that? BTW, I successfully step into to breakpoint of StubRountes::call_stub while using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to see what is going in the Interpreter. However, it even generates a great amount of bytecodes when it is initializing and load the system class. I don't know when the interpreter runtime is initialized. 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', aiming at stopping at a specific bytecode when I can inspect the runtime datastructure. Unfortunately I failed. I don't understand why '-XX:StopInterpreterAt=1' doesn't work. The question is how to configure it correctly that I can stop where exactly I want. 3) My object is to get some information, especially about the lock and thread information when threads concurrently access a shared variant or try to lock before access using monitorenter. Can you give me some advise how and where I can start? Is it related to the InterpreterRuntime::monitorenter? I am looking forward to hearing from you. Regards, Alex Xie, University of New South Wales, Australia. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090105/ea00fe6e/attachment.html From volker.simonis at gmail.com Mon Jan 5 05:50:33 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Jan 2009 14:50:33 +0100 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. In-Reply-To: References: Message-ID: Hi Alex, there are some things to consider if you want to debug the HotSpot interpreter: - gdb should work fairy well, however for some historic reasons, the debug version of HotSpot on Linux/x86 is built with "-gstabs". To get a better debugging experience, you should change this to "-g" at the end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild the VM with these new settings. - in general, the "java" launcher will "execv()" itself to ensure it has the right LD_LIBRARY_PATH settings but this "execv()" can confuse gdb. To avoid it, you can either use the "gamma" launcher as explained in my blog ("gamma" does not execv, because the user is responsible to set the right LD_LIBRARY_PATH before calling "gamma"). The other possibility is to set the LD_LIBRARY_PATH manually before running "java" such that it begins with the prefix expected by the the launcher. In this case the launcher does not need to do an "execv()". To achieve this, you can set a breakpoint in "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris is no typo here!!!) and check the path the launcher expects to see for LD_LIBRARY_PATH (look for the value of "newpath"). - even if you followed the two points above, you can not easily set a breakpoint in the interpreter, because the interpreter is generated at startup. This means that there are no C-sources for the interpretation of a bytecode (instead there's C-code which generates code which will execute a bytecode). You can display the generated interpreter and the various stubs with the options "-XX:+PrintInterpreter" and "-XX:+PrintStubCode". You should use this together with "-XX:+PrintAssembly" to get a disassembly of the generated templates and stubs. (Notice that you need to compile and use the additional library "disassembler.so" for this to work. More information on the disassembler library can be found under: http://wikis.sun.com/display/HotSpotInternals/PrintAssembly). - I suggest you run the VM once with "-XX:+PrintAssembly -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a file. You should do this in the debugger, such that the addresses of the generated code are the same like in the actual debug run. During a debugging session, you can then always cross check in which generated part of the interpreter you are. For a HotSpot debug build, you can also call the global "help()" function right from the debuger prompt. This will list some global helper functions from within libjvm.so which can be used during debugging (among them "find(
" which can be used to print out some information about an address which belongs to the VM (e.g. a compiled method, an interpreter template, a stub and s.o.)). - the "-XX:StopInterpreterAt=" is implemented in such a way, that every generated Java bytecode template first of all increments a global bytecode counter and then checks its value against the argument of "StopInterpreterAt". If the two numbers are equal, the global function "breakpoint()" will be called. "breakpoint()" is an empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If you want to stop at the execution of a certain Java bytecode, you should first of all run your program with "-XX:+TraceBytecodes" to determine the exact position of the bytecode you're interested in (hopefully this won't take to long, because indeed the VM already executes about half a million bytecodes before even arriving to your program's "main()" method - this is all class loading and initialization stuff). Then start the VM again with the appropriate "StopInterpreterAt" option AND set a breakpoint for the global "breakpoint()" function. The VM will now stop just before the execution of the bytecode you're interested in, but it will stop in the "breakpoint()" function. Issuing a "finish" command in gdb, will return you to the code template you're interested in (you should be able to verify this by looking up the current address within the file which contains the generated interpreter that we've created in the previous step). Notice that at this point, all you can do in gdb is stepping at assembler level ("stepi", "nexti") because you're in generated code now and there is no associated symbolic information for this code ("next" and "step" won't work). - certain, complex functionality of some bytecodes isn't handled directly in the generated code. Instead, some helper methods implemented in C++ in the VM are called. This is the case for example for InterpreterRuntime::monitorenter. You can check the bytecode generators, to see where there are calls into the runtime. Hope this helps. Regards, Volker On Mon, Jan 5, 2009 at 6:32 AM, wrote: > Hi Volker, > > Happy New Year. > Sorry to bother you. Thank you for your attention. > > I found your email about Hotspot build instruction from the hotspot-dev > maillist and your blog. I do appreciate your great help. However, I still > can't quite understand the mechanism of the interpreter in hotspot. May I > ask you some questions? > > 1) I used ddd, a graphic based client of gdb, to set up some breakpoints and > stepped into the hotspot jvm. I can find how exactly the bytecode is > executed, just like the following maillist: > http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results .Do > you have some idea about that? > > BTW, I successfully step into to breakpoint of StubRountes::call_stub while > using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to see > what is going in the Interpreter. However, it even generates a great > amount of bytecodes when it is initializing and load the system class. I > don't know when the interpreter runtime is initialized. > > > 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', > aiming at stopping at a specific bytecode when I can inspect the runtime > datastructure. Unfortunately I failed. I don't understand why > '-XX:StopInterpreterAt=1' doesn't work. The question is how to configure it > correctly that I can stop where exactly I want. > > 3) My object is to get some information, especially about the lock and > thread information when threads concurrently access a shared variant or try > to lock before access using monitorenter. Can you give me some advise how > and where I can start? Is it related to the > InterpreterRuntime::monitorenter? > > I am looking forward to hearing from you. > > Regards, > > Alex Xie, > University of New South Wales, Australia. From gbenson at redhat.com Mon Jan 5 07:25:46 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 5 Jan 2009 15:25:46 +0000 Subject: The Interpreter Mechanism? In-Reply-To: <1fc4689f0812301357w5b7b6563w3405f4c0e2fd7941@mail.gmail.com> References: <1fc4689f0812301357w5b7b6563w3405f4c0e2fd7941@mail.gmail.com> Message-ID: <20090105152546.GD3233@redhat.com> xenway wrote: > Can you please guide me to the part of the code where interpreter > works when I use '-Xint' option corresponding to a bytecode > operation. I can't figure out how and where it is executed in the > interpreter mode. hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp Cheers, Gary -- http://gbenson.net/ From christian.thalinger at gmail.com Mon Jan 5 09:26:30 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Mon, 05 Jan 2009 18:26:30 +0100 Subject: The Interpreter Mechanism? In-Reply-To: <20090105152546.GD3233@redhat.com> References: <1fc4689f0812301357w5b7b6563w3405f4c0e2fd7941@mail.gmail.com> <20090105152546.GD3233@redhat.com> Message-ID: <1231176390.4001.209.camel@localhost.localdomain> On Mon, 2009-01-05 at 15:25 +0000, Gary Benson wrote: > xenway wrote: > > Can you please guide me to the part of the code where interpreter > > works when I use '-Xint' option corresponding to a bytecode > > operation. I can't figure out how and where it is executed in the > > interpreter mode. > > hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp But this is the C++ interpreter, not the template interpreter actually used by HotSpot's mixed mode. - Christian From Coleen.Phillimore at Sun.COM Mon Jan 5 09:27:04 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Mon, 05 Jan 2009 12:27:04 -0500 Subject: how to build without precompiled headers? In-Reply-To: <49613144.90706@ubuntu.com> References: <49613144.90706@ubuntu.com> Message-ID: <496242E8.10509@sun.com> I tried this on my new 8.10 ubuntu system at home and commenting out USE_PRECOMPILED_HEADER didn't use the precompiled header. The file _precompiled.incl is still produced but it's empty. I believe you have to do a make clean before your gcc.make change is used. The version of gcc that I used was very picky about inlined functions not being defined in places where the other platforms were happy, so there were multiple warnings with this message. I have a patch file that resolves this, if you want it. Also, on my 8.10 ubuntu, gcc version 4.1.forgot, I got an error building fastdebug (server compiler) which I haven't resolved. /home/coleenp/hotspot/src/share/vm/libadt/port.hpp:40: error: 'void bcopy(const void*, void*, size_t)' redeclared inline without 'gnu_inline' attribute If you're trying to track down a compiler error building hotspot, try getting a preprocessed output file to narrow it down. cd linux*/ make .i Hope this helps. Coleen On 01/04/09 16:59, Matthias Klose wrote: > Trying to track down an ICE (internal compiler error), I need to build hotspot > without precompiled header files. There is a macro USE_PRECOMPILED_HEADER > defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just removing the > conditional around this definition still builds using precompiled header files. > How can you build without precompiled header files (even if it's a hack)? > > Matthias > From Thomas.Rodriguez at Sun.COM Mon Jan 5 11:39:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 05 Jan 2009 11:39:15 -0800 Subject: SuperWord optimization In-Reply-To: <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> Message-ID: I have a workspace that combines Ross's initial work supporting arbitrary ALU operations for vectorization with some work I did for adding a new RegQ type for 128-bit vector operations. It was limping along when I stopped looking at it but I could post a webrev of it if there is interest. It's not something I'm working on but I'd wanted to bring the parts forward so they didn't get completely lost. All the code generation pieces were working and the main remaining piece is fixing the loop alignment code to support aligning to 128 bit boundaries. The heap is only aligned to 64-bits so the alignment code that superword uses needs to switch to a pointer alignment calculation instead of using index alignment. Once we add 128 bit vectors we'll need some policy work to choose vector sizes based on the code we see. Currently the code assumes there is only one vector register size. tom On Dec 31, 2008, at 8:01 PM, John Rose wrote: > On Dec 31, 2008, at 10:32 AM, James Walsh wrote: > >> Is there some documentation of hdl used in x86_32.ad? How would I >> describe a XMM register as a whole in that language? > > The AD file describes machine registers in terms of 32-bit chunks. > Each (named) chunk corresponds to a bit position in the register > allocator's bitmasks. Stack frame slots are numbered also in the > same uniform scheme, so it doesn't make sense to have some chunks be > 128 bits, etc. That is why the AD file talks about parts [abcd] of > the 128-bit XMM regs. > > The upside of this decision to standardize on a 32-bit unit is the > spill and memory allocation logic (always a tricky part of register > allocation) is simplified. Stack slots do not need to be typed; > they are just 32-bit words. Another upside is that multi-purpose > machine registers (e.g., two-floats-in-a-double or a long-in-two- > ints) can also be represented readily. > > The downside of this is that 64-bit entities must be represented > using (contiguous, aligned) register pairs. The register allocation > logic is somewhat complicated by the need to work with such register > pairs. Generalizing the code further to 128-bit entities is a > moderately tricky problem, but I think that's what has to be done. > > The register allocation has an "ideal reg" query on each node which > discloses what kind of register to allocate. The upshot of this > query is (a) a mask of possible hardware register resources where > the result has to live, and (b) whether the ultimate allocation is a > single 32-bit unit or a (contiguous, aligned) pair. To cope with > vectors, the system needs at least one new "ideal reg" type per > vector size, perhaps an RegV4 (for XMM) or RegV8 (for YMM). The > RegL probably will continue to serve well as a RegV2. > >> Obviously >> MOVAPS, ADDPS, etc and the like will need to reserve a whole XMM >> register, not just XMM0a etc. Looking at the description of the XMM >> double register definitions I could probably guess but if there is >> some >> official docs it would be nice to take a look at them. > > Happy New Year! > -- John From groundskeeperwiley at yahoo.com Mon Jan 5 12:33:42 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Mon, 5 Jan 2009 12:33:42 -0800 (PST) Subject: SuperWord optimization References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> Message-ID: <883711.45756.qm@web30008.mail.mud.yahoo.com> I'd certainly like to see the code. Hotspot is huge and I'm feeling a bit overwhelmed at the moment. From Thomas.Rodriguez at Sun.COM Mon Jan 5 12:43:25 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 05 Jan 2009 12:43:25 -0800 Subject: SuperWord optimization In-Reply-To: <883711.45756.qm@web30008.mail.mud.yahoo.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> <883711.45756.qm@web30008.mail.mud.yahoo.com> Message-ID: <5789C33E-1109-484E-8EEC-2A9C7CE1672B@Sun.COM> I'll clean it up and send it out as soon as I get a chance. tom On Jan 5, 2009, at 12:33 PM, James Walsh wrote: > I'd certainly like to see the code. Hotspot is huge and I'm feeling > a bit overwhelmed at the moment. > > > > From John.Rose at Sun.COM Mon Jan 5 12:57:31 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 05 Jan 2009 12:57:31 -0800 Subject: SuperWord optimization In-Reply-To: References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> Message-ID: <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> I'd love to see that webrev. (You've got some great back-burner stuff, Tom!) An alternative to adding pointer alignment logic (in the compiler and also the hand-tuned assembly code) is allocating all arrays above some fixed length (e.g., 10 words) with an additional alignment constraint. This has the advantage of making any pair of large-enough arrays mutually aligned, if their access indexes are aligned. The compiler and assembly stubs already have special paths for very short arrays; these cut-outs could be adapted to take into account the strong alignment size. Or we could just unswitch the the whole loop (or predicate it with an uncommon trap, given the right length profile data). -- John P.S. In general, if there's an optimization that makes sense mainly for large arrays, the JVM has the option of allocating large arrays with special tactics (alignment, chunking, multianewarray layout, cache line coloring, CPU affinity for work-stealing, etc., etc.). This option is not yet exercised, except in the simple case of slow- pathing truly huge arrays, bigger than FastAllocateSizeLimit. This class of optimizations gets more valuable as CPU-to-memory distances increase, but it is still waiting for the right PhD student to come along. On Jan 5, 2009, at 11:39 AM, Tom Rodriguez wrote: > I have a workspace that combines Ross's initial work supporting > arbitrary ALU operations for vectorization with some work I did for > adding a new RegQ type for 128-bit vector operations. It was > limping along when I stopped looking at it but I could post a > webrev of it if there is interest. It's not something I'm working > on but I'd wanted to bring the parts forward so they didn't get > completely lost. All the code generation pieces were working and > the main remaining piece is fixing the loop alignment code to > support aligning to 128 bit boundaries. The heap is only aligned > to 64-bits so the alignment code that superword uses needs to > switch to a pointer alignment calculation instead of using index > alignment. > > Once we add 128 bit vectors we'll need some policy work to choose > vector sizes based on the code we see. Currently the code assumes > there is only one vector register size. From xinweix at cse.unsw.edu.au Mon Jan 5 22:48:15 2009 From: xinweix at cse.unsw.edu.au (xinweix at cse.unsw.edu.au) Date: Tue, 6 Jan 2009 14:48:15 +0800 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. References: Message-ID: <859EDD5ABE474E40B4A54504A7EE4E4A@PC200808102152> Hi Volker, Thanks very much for your great help. I'd like to discuss with you the following questions: 1. I've followed your advise of using '-XX:+TraceBytecodes' and identify the specific bytecode instruction. However, I encountered the problem of SEGV fault when it is executing in 'monitorenter' bytecode. I tried several times, but failed all the same. 2. If I follow the option of '-Xint', is the mechanism of JIT compiler working there? If not, is it in the mixed mode? How can it be activated? Are there some entry points? I found some compiler introductions and optimizations published in some papers, such as HIR(Highlevel Intermediate Representation), LIR and SSA forms, etc. The IR is another type of bytecode. If I want to instrument bytecode, such as 'monitorenter', 'monitorexit', is it feasible to work on the IR? 3. I tried to use '-XX:+PrintAssembly' option to get some ouputs, that are composed of the assembly codes with respect to each bytecode. Is it that each bunch of assembly codes will be executed when 'Interpreter' executes each bytecode? 4. Is it that the function InterpreterRuntime::monitor is the entry with respect to 'monitorenter' so that I can do something here? Regards, Alex Xie -------------------------------------------------- From: "Volker Simonis" Sent: Monday, January 05, 2009 9:50 PM To: Cc: Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. > Hi Alex, > > there are some things to consider if you want to debug the HotSpot > interpreter: > > - gdb should work fairy well, however for some historic reasons, the > debug version of HotSpot on Linux/x86 is built with "-gstabs". To get > a better debugging experience, you should change this to "-g" at the > end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild > the VM with these new settings. > > - in general, the "java" launcher will "execv()" itself to ensure it > has the right LD_LIBRARY_PATH settings but this "execv()" can confuse > gdb. To avoid it, you can either use the "gamma" launcher as explained > in my blog ("gamma" does not execv, because the user is responsible to > set the right LD_LIBRARY_PATH before calling "gamma"). The other > possibility is to set the LD_LIBRARY_PATH manually before running > "java" such that it begins with the prefix expected by the the > launcher. In this case the launcher does not need to do an "execv()". > To achieve this, you can set a breakpoint in > "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris > is no typo here!!!) and check the path the launcher expects to see for > LD_LIBRARY_PATH (look for the value of "newpath"). > > - even if you followed the two points above, you can not easily set a > breakpoint in the interpreter, because the interpreter is generated at > startup. This means that there are no C-sources for the interpretation > of a bytecode (instead there's C-code which generates code which will > execute a bytecode). You can display the generated interpreter and the > various stubs with the options "-XX:+PrintInterpreter" and > "-XX:+PrintStubCode". You should use this together with > "-XX:+PrintAssembly" to get a disassembly of the generated templates > and stubs. (Notice that you need to compile and use the additional > library "disassembler.so" for this to work. More information on the > disassembler library can be found under: > http://wikis.sun.com/display/HotSpotInternals/PrintAssembly). > > - I suggest you run the VM once with "-XX:+PrintAssembly > -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a > file. You should do this in the debugger, such that the addresses of > the generated code are the same like in the actual debug run. During a > debugging session, you can then always cross check in which generated > part of the interpreter you are. For a HotSpot debug build, you can > also call the global "help()" function right from the debuger prompt. > This will list some global helper functions from within libjvm.so > which can be used during debugging (among them "find(
" which > can be used to print out some information about an address which > belongs to the VM (e.g. a compiled method, an interpreter template, a > stub and s.o.)). > > - the "-XX:StopInterpreterAt=" is implemented in such > a way, that every generated Java bytecode template first of all > increments a global bytecode counter and then checks its value against > the argument of "StopInterpreterAt". If the two numbers are equal, the > global function "breakpoint()" will be called. "breakpoint()" is an > empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If > you want to stop at the execution of a certain Java bytecode, you > should first of all run your program with "-XX:+TraceBytecodes" to > determine the exact position of the bytecode you're interested in > (hopefully this won't take to long, because indeed the VM already > executes about half a million bytecodes before even arriving to your > program's "main()" method - this is all class loading and > initialization stuff). Then start the VM again with the appropriate > "StopInterpreterAt" option AND set a breakpoint for the global > "breakpoint()" function. The VM will now stop just before the > execution of the bytecode you're interested in, but it will stop in > the "breakpoint()" function. Issuing a "finish" command in gdb, will > return you to the code template you're interested in (you should be > able to verify this by looking up the current address within the file > which contains the generated interpreter that we've created in the > previous step). Notice that at this point, all you can do in gdb is > stepping at assembler level ("stepi", "nexti") because you're in > generated code now and there is no associated symbolic information for > this code ("next" and "step" won't work). > > > - certain, complex functionality of some bytecodes isn't handled > directly in the generated code. Instead, some helper methods > implemented in C++ in the VM are called. This is the case for example > for InterpreterRuntime::monitorenter. You can check the bytecode > generators, to see where there are calls into the runtime. > > Hope this helps. > Regards, > Volker > > On Mon, Jan 5, 2009 at 6:32 AM, wrote: >> Hi Volker, >> >> Happy New Year. >> Sorry to bother you. Thank you for your attention. >> >> I found your email about Hotspot build instruction from the hotspot-dev >> maillist and your blog. I do appreciate your great help. However, I still >> can't quite understand the mechanism of the interpreter in hotspot. May I >> ask you some questions? >> >> 1) I used ddd, a graphic based client of gdb, to set up some breakpoints >> and >> stepped into the hotspot jvm. I can find how exactly the bytecode is >> executed, just like the following maillist: >> http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results >> .Do >> you have some idea about that? >> >> BTW, I successfully step into to breakpoint of StubRountes::call_stub >> while >> using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to see >> what is going in the Interpreter. However, it even generates a great >> amount of bytecodes when it is initializing and load the system class. I >> don't know when the interpreter runtime is initialized. >> >> >> 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', >> aiming at stopping at a specific bytecode when I can inspect the runtime >> datastructure. Unfortunately I failed. I don't understand why >> '-XX:StopInterpreterAt=1' doesn't work. The question is how to configure >> it >> correctly that I can stop where exactly I want. >> >> 3) My object is to get some information, especially about the lock and >> thread information when threads concurrently access a shared variant or >> try >> to lock before access using monitorenter. Can you give me some advise how >> and where I can start? Is it related to the >> InterpreterRuntime::monitorenter? >> >> I am looking forward to hearing from you. >> >> Regards, >> >> Alex Xie, >> University of New South Wales, Australia. > From David.Holmes at Sun.COM Mon Jan 5 23:08:20 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 06 Jan 2009 17:08:20 +1000 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. In-Reply-To: <859EDD5ABE474E40B4A54504A7EE4E4A@PC200808102152> References: <859EDD5ABE474E40B4A54504A7EE4E4A@PC200808102152> Message-ID: <49630364.9050406@sun.com> Alex, -Xint runs only the interpreter, the JIT compiler is disabled. InterpreterRuntime::monitorentry is the slow-path entry point for monitor acquisition. If you look in bytecodeInterpreter.cpp you will see the fast-path code that is used - see line 612 for method calls for example. If you search for the calls to InterpreterRuntime::monitorentry you will see the fast-path code for the different cases preceding it. Note that there are two different fast-paths depending on whether biased-locking is enabled or not. If you want to track all monitor acquisitions then you will need to modify the interpreter itself to add your tracking code. Hope this helps. David Holmes xinweix at cse.unsw.edu.au said the following on 01/06/09 16:48: > Hi Volker, > > Thanks very much for your great help. I'd like to discuss with you the > following questions: > > 1. I've followed your advise of using '-XX:+TraceBytecodes' and identify > the specific bytecode instruction. However, I encountered the problem of > SEGV fault when it is executing in 'monitorenter' bytecode. I tried > several times, but failed all the same. > > 2. If I follow the option of '-Xint', is the mechanism of JIT compiler > working there? If not, is it in the mixed mode? How can it be activated? > Are there some entry points? I found some compiler introductions and > optimizations published in some papers, such as HIR(Highlevel > Intermediate Representation), LIR and SSA forms, etc. The IR is another > type of bytecode. If I want to instrument bytecode, such as > 'monitorenter', 'monitorexit', is it feasible to work on the IR? > > 3. I tried to use '-XX:+PrintAssembly' option to get some ouputs, that > are composed of the assembly codes with respect to each bytecode. Is it > that each bunch of assembly codes will be executed when 'Interpreter' > executes each bytecode? > > 4. Is it that the function InterpreterRuntime::monitor is the entry with > respect to 'monitorenter' so that I can do something here? > > Regards, > > Alex Xie > > -------------------------------------------------- > From: "Volker Simonis" > Sent: Monday, January 05, 2009 9:50 PM > To: > Cc: > Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question > about hotspot of openjdk. > >> Hi Alex, >> >> there are some things to consider if you want to debug the HotSpot >> interpreter: >> >> - gdb should work fairy well, however for some historic reasons, the >> debug version of HotSpot on Linux/x86 is built with "-gstabs". To get >> a better debugging experience, you should change this to "-g" at the >> end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild >> the VM with these new settings. >> >> - in general, the "java" launcher will "execv()" itself to ensure it >> has the right LD_LIBRARY_PATH settings but this "execv()" can confuse >> gdb. To avoid it, you can either use the "gamma" launcher as explained >> in my blog ("gamma" does not execv, because the user is responsible to >> set the right LD_LIBRARY_PATH before calling "gamma"). The other >> possibility is to set the LD_LIBRARY_PATH manually before running >> "java" such that it begins with the prefix expected by the the >> launcher. In this case the launcher does not need to do an "execv()". >> To achieve this, you can set a breakpoint in >> "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris >> is no typo here!!!) and check the path the launcher expects to see for >> LD_LIBRARY_PATH (look for the value of "newpath"). >> >> - even if you followed the two points above, you can not easily set a >> breakpoint in the interpreter, because the interpreter is generated at >> startup. This means that there are no C-sources for the interpretation >> of a bytecode (instead there's C-code which generates code which will >> execute a bytecode). You can display the generated interpreter and the >> various stubs with the options "-XX:+PrintInterpreter" and >> "-XX:+PrintStubCode". You should use this together with >> "-XX:+PrintAssembly" to get a disassembly of the generated templates >> and stubs. (Notice that you need to compile and use the additional >> library "disassembler.so" for this to work. More information on the >> disassembler library can be found under: >> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly). >> >> - I suggest you run the VM once with "-XX:+PrintAssembly >> -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a >> file. You should do this in the debugger, such that the addresses of >> the generated code are the same like in the actual debug run. During a >> debugging session, you can then always cross check in which generated >> part of the interpreter you are. For a HotSpot debug build, you can >> also call the global "help()" function right from the debuger prompt. >> This will list some global helper functions from within libjvm.so >> which can be used during debugging (among them "find(
" which >> can be used to print out some information about an address which >> belongs to the VM (e.g. a compiled method, an interpreter template, a >> stub and s.o.)). >> >> - the "-XX:StopInterpreterAt=" is implemented in such >> a way, that every generated Java bytecode template first of all >> increments a global bytecode counter and then checks its value against >> the argument of "StopInterpreterAt". If the two numbers are equal, the >> global function "breakpoint()" will be called. "breakpoint()" is an >> empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If >> you want to stop at the execution of a certain Java bytecode, you >> should first of all run your program with "-XX:+TraceBytecodes" to >> determine the exact position of the bytecode you're interested in >> (hopefully this won't take to long, because indeed the VM already >> executes about half a million bytecodes before even arriving to your >> program's "main()" method - this is all class loading and >> initialization stuff). Then start the VM again with the appropriate >> "StopInterpreterAt" option AND set a breakpoint for the global >> "breakpoint()" function. The VM will now stop just before the >> execution of the bytecode you're interested in, but it will stop in >> the "breakpoint()" function. Issuing a "finish" command in gdb, will >> return you to the code template you're interested in (you should be >> able to verify this by looking up the current address within the file >> which contains the generated interpreter that we've created in the >> previous step). Notice that at this point, all you can do in gdb is >> stepping at assembler level ("stepi", "nexti") because you're in >> generated code now and there is no associated symbolic information for >> this code ("next" and "step" won't work). >> >> >> - certain, complex functionality of some bytecodes isn't handled >> directly in the generated code. Instead, some helper methods >> implemented in C++ in the VM are called. This is the case for example >> for InterpreterRuntime::monitorenter. You can check the bytecode >> generators, to see where there are calls into the runtime. >> >> Hope this helps. >> Regards, >> Volker >> >> On Mon, Jan 5, 2009 at 6:32 AM, wrote: >>> Hi Volker, >>> >>> Happy New Year. >>> Sorry to bother you. Thank you for your attention. >>> >>> I found your email about Hotspot build instruction from the hotspot-dev >>> maillist and your blog. I do appreciate your great help. However, I >>> still >>> can't quite understand the mechanism of the interpreter in hotspot. >>> May I >>> ask you some questions? >>> >>> 1) I used ddd, a graphic based client of gdb, to set up some >>> breakpoints and >>> stepped into the hotspot jvm. I can find how exactly the bytecode is >>> executed, just like the following maillist: >>> http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results >>> .Do >>> you have some idea about that? >>> >>> BTW, I successfully step into to breakpoint of StubRountes::call_stub >>> while >>> using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to >>> see >>> what is going in the Interpreter. However, it even generates a great >>> amount of bytecodes when it is initializing and load the system class. I >>> don't know when the interpreter runtime is initialized. >>> >>> >>> 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', >>> aiming at stopping at a specific bytecode when I can inspect the runtime >>> datastructure. Unfortunately I failed. I don't understand why >>> '-XX:StopInterpreterAt=1' doesn't work. The question is how to >>> configure it >>> correctly that I can stop where exactly I want. >>> >>> 3) My object is to get some information, especially about the lock and >>> thread information when threads concurrently access a shared variant >>> or try >>> to lock before access using monitorenter. Can you give me some advise >>> how >>> and where I can start? Is it related to the >>> InterpreterRuntime::monitorenter? >>> >>> I am looking forward to hearing from you. >>> >>> Regards, >>> >>> Alex Xie, >>> University of New South Wales, Australia. >> From gbenson at redhat.com Tue Jan 6 01:38:47 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 6 Jan 2009 09:38:47 +0000 Subject: The Interpreter Mechanism? In-Reply-To: <1231176390.4001.209.camel@localhost.localdomain> References: <1fc4689f0812301357w5b7b6563w3405f4c0e2fd7941@mail.gmail.com> <20090105152546.GD3233@redhat.com> <1231176390.4001.209.camel@localhost.localdomain> Message-ID: <20090106093847.GA3238@redhat.com> Christian Thalinger wrote: > On Mon, 2009-01-05 at 15:25 +0000, Gary Benson wrote: > > xenway wrote: > > > Can you please guide me to the part of the code where interpreter > > > works when I use '-Xint' option corresponding to a bytecode > > > operation. I can't figure out how and where it is executed in the > > > interpreter mode. > > > > hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp > > But this is the C++ interpreter, not the template interpreter > actually used by HotSpot's mixed mode. Ah, he did say "bytecode interpreter", maybe I was taking that too literally :) Cheers, Gary -- http://gbenson.net/ From xinweix at cse.unsw.edu.au Tue Jan 6 03:04:53 2009 From: xinweix at cse.unsw.edu.au (xinweix at cse.unsw.edu.au) Date: Tue, 6 Jan 2009 19:04:53 +0800 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. References: <859EDD5ABE474E40B4A54504A7EE4E4A@PC200808102152> <49630364.9050406@sun.com> Message-ID: <222BDECE3E51450EA8DB52CDC7EE31CF@PC200808102152> Hi David, Thanks for your reply. I've check out the "Hotspot Runtime Overview", which says that slow-path means the lock state is inflated. In other words, it is locked or unlocked but shared and contented. > InterpreterRuntime::monitorentry is the slow-path entry point for monitor > acquisition. Where is the fast-path entry point in the template interpreter, as I need to know all information about each accessing of share variant? Regards, Alex Xie -------------------------------------------------- From: "David Holmes - Sun Microsystems" Sent: Tuesday, January 06, 2009 3:08 PM To: Cc: Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. > Alex, > > -Xint runs only the interpreter, the JIT compiler is disabled. > > InterpreterRuntime::monitorentry is the slow-path entry point for monitor > acquisition. If you look in bytecodeInterpreter.cpp you will see the > fast-path code that is used - see line 612 for method calls for example. > If you search for the calls to InterpreterRuntime::monitorentry you will > see the fast-path code for the different cases preceding it. Note that > there are two different fast-paths depending on whether biased-locking is > enabled or not. > > If you want to track all monitor acquisitions then you will need to modify > the interpreter itself to add your tracking code. > > Hope this helps. > > David Holmes > > > xinweix at cse.unsw.edu.au said the following on 01/06/09 16:48: >> Hi Volker, >> >> Thanks very much for your great help. I'd like to discuss with you the >> following questions: >> >> 1. I've followed your advise of using '-XX:+TraceBytecodes' and identify >> the specific bytecode instruction. However, I encountered the problem of >> SEGV fault when it is executing in 'monitorenter' bytecode. I tried >> several times, but failed all the same. >> >> 2. If I follow the option of '-Xint', is the mechanism of JIT compiler >> working there? If not, is it in the mixed mode? How can it be activated? >> Are there some entry points? I found some compiler introductions and >> optimizations published in some papers, such as HIR(Highlevel >> Intermediate Representation), LIR and SSA forms, etc. The IR is another >> type of bytecode. If I want to instrument bytecode, such as >> 'monitorenter', 'monitorexit', is it feasible to work on the IR? >> >> 3. I tried to use '-XX:+PrintAssembly' option to get some ouputs, that >> are composed of the assembly codes with respect to each bytecode. Is it >> that each bunch of assembly codes will be executed when 'Interpreter' >> executes each bytecode? >> >> 4. Is it that the function InterpreterRuntime::monitor is the entry with >> respect to 'monitorenter' so that I can do something here? >> >> Regards, >> >> Alex Xie >> >> -------------------------------------------------- >> From: "Volker Simonis" >> Sent: Monday, January 05, 2009 9:50 PM >> To: >> Cc: >> Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question >> about hotspot of openjdk. >> >>> Hi Alex, >>> >>> there are some things to consider if you want to debug the HotSpot >>> interpreter: >>> >>> - gdb should work fairy well, however for some historic reasons, the >>> debug version of HotSpot on Linux/x86 is built with "-gstabs". To get >>> a better debugging experience, you should change this to "-g" at the >>> end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild >>> the VM with these new settings. >>> >>> - in general, the "java" launcher will "execv()" itself to ensure it >>> has the right LD_LIBRARY_PATH settings but this "execv()" can confuse >>> gdb. To avoid it, you can either use the "gamma" launcher as explained >>> in my blog ("gamma" does not execv, because the user is responsible to >>> set the right LD_LIBRARY_PATH before calling "gamma"). The other >>> possibility is to set the LD_LIBRARY_PATH manually before running >>> "java" such that it begins with the prefix expected by the the >>> launcher. In this case the launcher does not need to do an "execv()". >>> To achieve this, you can set a breakpoint in >>> "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris >>> is no typo here!!!) and check the path the launcher expects to see for >>> LD_LIBRARY_PATH (look for the value of "newpath"). >>> >>> - even if you followed the two points above, you can not easily set a >>> breakpoint in the interpreter, because the interpreter is generated at >>> startup. This means that there are no C-sources for the interpretation >>> of a bytecode (instead there's C-code which generates code which will >>> execute a bytecode). You can display the generated interpreter and the >>> various stubs with the options "-XX:+PrintInterpreter" and >>> "-XX:+PrintStubCode". You should use this together with >>> "-XX:+PrintAssembly" to get a disassembly of the generated templates >>> and stubs. (Notice that you need to compile and use the additional >>> library "disassembler.so" for this to work. More information on the >>> disassembler library can be found under: >>> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly). >>> >>> - I suggest you run the VM once with "-XX:+PrintAssembly >>> -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a >>> file. You should do this in the debugger, such that the addresses of >>> the generated code are the same like in the actual debug run. During a >>> debugging session, you can then always cross check in which generated >>> part of the interpreter you are. For a HotSpot debug build, you can >>> also call the global "help()" function right from the debuger prompt. >>> This will list some global helper functions from within libjvm.so >>> which can be used during debugging (among them "find(
" which >>> can be used to print out some information about an address which >>> belongs to the VM (e.g. a compiled method, an interpreter template, a >>> stub and s.o.)). >>> >>> - the "-XX:StopInterpreterAt=" is implemented in such >>> a way, that every generated Java bytecode template first of all >>> increments a global bytecode counter and then checks its value against >>> the argument of "StopInterpreterAt". If the two numbers are equal, the >>> global function "breakpoint()" will be called. "breakpoint()" is an >>> empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If >>> you want to stop at the execution of a certain Java bytecode, you >>> should first of all run your program with "-XX:+TraceBytecodes" to >>> determine the exact position of the bytecode you're interested in >>> (hopefully this won't take to long, because indeed the VM already >>> executes about half a million bytecodes before even arriving to your >>> program's "main()" method - this is all class loading and >>> initialization stuff). Then start the VM again with the appropriate >>> "StopInterpreterAt" option AND set a breakpoint for the global >>> "breakpoint()" function. The VM will now stop just before the >>> execution of the bytecode you're interested in, but it will stop in >>> the "breakpoint()" function. Issuing a "finish" command in gdb, will >>> return you to the code template you're interested in (you should be >>> able to verify this by looking up the current address within the file >>> which contains the generated interpreter that we've created in the >>> previous step). Notice that at this point, all you can do in gdb is >>> stepping at assembler level ("stepi", "nexti") because you're in >>> generated code now and there is no associated symbolic information for >>> this code ("next" and "step" won't work). >>> >>> >>> - certain, complex functionality of some bytecodes isn't handled >>> directly in the generated code. Instead, some helper methods >>> implemented in C++ in the VM are called. This is the case for example >>> for InterpreterRuntime::monitorenter. You can check the bytecode >>> generators, to see where there are calls into the runtime. >>> >>> Hope this helps. >>> Regards, >>> Volker >>> >>> On Mon, Jan 5, 2009 at 6:32 AM, wrote: >>>> Hi Volker, >>>> >>>> Happy New Year. >>>> Sorry to bother you. Thank you for your attention. >>>> >>>> I found your email about Hotspot build instruction from the hotspot-dev >>>> maillist and your blog. I do appreciate your great help. However, I >>>> still >>>> can't quite understand the mechanism of the interpreter in hotspot. May >>>> I >>>> ask you some questions? >>>> >>>> 1) I used ddd, a graphic based client of gdb, to set up some >>>> breakpoints and >>>> stepped into the hotspot jvm. I can find how exactly the bytecode is >>>> executed, just like the following maillist: >>>> http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results >>>> .Do >>>> you have some idea about that? >>>> >>>> BTW, I successfully step into to breakpoint of StubRountes::call_stub >>>> while >>>> using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to >>>> see >>>> what is going in the Interpreter. However, it even generates a great >>>> amount of bytecodes when it is initializing and load the system class. >>>> I >>>> don't know when the interpreter runtime is initialized. >>>> >>>> >>>> 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', >>>> aiming at stopping at a specific bytecode when I can inspect the >>>> runtime >>>> datastructure. Unfortunately I failed. I don't understand why >>>> '-XX:StopInterpreterAt=1' doesn't work. The question is how to >>>> configure it >>>> correctly that I can stop where exactly I want. >>>> >>>> 3) My object is to get some information, especially about the lock and >>>> thread information when threads concurrently access a shared variant or >>>> try >>>> to lock before access using monitorenter. Can you give me some advise >>>> how >>>> and where I can start? Is it related to the >>>> InterpreterRuntime::monitorenter? >>>> >>>> I am looking forward to hearing from you. >>>> >>>> Regards, >>>> >>>> Alex Xie, >>>> University of New South Wales, Australia. >>> > From David.Holmes at Sun.COM Tue Jan 6 04:07:48 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 06 Jan 2009 22:07:48 +1000 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. In-Reply-To: <222BDECE3E51450EA8DB52CDC7EE31CF@PC200808102152> References: <859EDD5ABE474E40B4A54504A7EE4E4A@PC200808102152> <49630364.9050406@sun.com> <222BDECE3E51450EA8DB52CDC7EE31CF@PC200808102152> Message-ID: <49634994.8000300@sun.com> Alex, As I said look in bytecodeInterpreter for where InterpreterRuntime::monitorenter gets called as the code preceding that defines the fast-path. eg this is the non-biased-locking case for locking a synchronized method: markOop displaced = rcvr->mark()->set_unlocked(); mon->lock()->set_displaced_header(displaced); if (Atomic::cmpxchg_ptr(mon, rcvr->mark_addr(), displaced) != displaced) { // Is it simple recursive case? if (THREAD->is_lock_owned((address) displaced->clear_lock_bits())) { mon->lock()->set_displaced_header(NULL); } else { CALL_VM(InterpreterRuntime::monitorenter(THREAD, mon), handle_exception); } } the cmpxchg_ptr tries to acquire the lock by updating the header of the object (fast-path), if it finds the object locked by another thread then it invokes InterpreterRuntime::monitorenter (slow-path). Note that here the slow-path is what (may) lead to the monitor being inflated; there is yet another fast-path/slow-path in the ObjectSynchronizer code. David xinweix at cse.unsw.edu.au said the following on 01/06/09 21:04: > Hi David, > Thanks for your reply. > I've check out the "Hotspot Runtime Overview", which says that slow-path > means the lock state is inflated. In other words, it is locked or > unlocked but shared and contented. > >> InterpreterRuntime::monitorentry is the slow-path entry point for >> monitor acquisition. > Where is the fast-path entry point in the template interpreter, as I > need to know all information about each accessing of share variant? > > Regards, > Alex Xie > -------------------------------------------------- > From: "David Holmes - Sun Microsystems" > Sent: Tuesday, January 06, 2009 3:08 PM > To: > Cc: > Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question > about hotspot of openjdk. > >> Alex, >> >> -Xint runs only the interpreter, the JIT compiler is disabled. >> >> InterpreterRuntime::monitorentry is the slow-path entry point for >> monitor acquisition. If you look in bytecodeInterpreter.cpp you will >> see the fast-path code that is used - see line 612 for method calls >> for example. If you search for the calls to >> InterpreterRuntime::monitorentry you will see the fast-path code for >> the different cases preceding it. Note that there are two different >> fast-paths depending on whether biased-locking is enabled or not. >> >> If you want to track all monitor acquisitions then you will need to >> modify the interpreter itself to add your tracking code. >> >> Hope this helps. >> >> David Holmes >> >> >> xinweix at cse.unsw.edu.au said the following on 01/06/09 16:48: >>> Hi Volker, >>> >>> Thanks very much for your great help. I'd like to discuss with you >>> the following questions: >>> >>> 1. I've followed your advise of using '-XX:+TraceBytecodes' and >>> identify the specific bytecode instruction. However, I encountered >>> the problem of SEGV fault when it is executing in 'monitorenter' >>> bytecode. I tried several times, but failed all the same. >>> >>> 2. If I follow the option of '-Xint', is the mechanism of JIT >>> compiler working there? If not, is it in the mixed mode? How can it >>> be activated? Are there some entry points? I found some compiler >>> introductions and optimizations published in some papers, such as >>> HIR(Highlevel Intermediate Representation), LIR and SSA forms, etc. >>> The IR is another type of bytecode. If I want to instrument bytecode, >>> such as 'monitorenter', 'monitorexit', is it feasible to work on the IR? >>> >>> 3. I tried to use '-XX:+PrintAssembly' option to get some ouputs, >>> that are composed of the assembly codes with respect to each >>> bytecode. Is it that each bunch of assembly codes will be executed >>> when 'Interpreter' executes each bytecode? >>> >>> 4. Is it that the function InterpreterRuntime::monitor is the entry >>> with respect to 'monitorenter' so that I can do something here? >>> >>> Regards, >>> >>> Alex Xie >>> >>> -------------------------------------------------- >>> From: "Volker Simonis" >>> Sent: Monday, January 05, 2009 9:50 PM >>> To: >>> Cc: >>> Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question >>> about hotspot of openjdk. >>> >>>> Hi Alex, >>>> >>>> there are some things to consider if you want to debug the HotSpot >>>> interpreter: >>>> >>>> - gdb should work fairy well, however for some historic reasons, the >>>> debug version of HotSpot on Linux/x86 is built with "-gstabs". To get >>>> a better debugging experience, you should change this to "-g" at the >>>> end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild >>>> the VM with these new settings. >>>> >>>> - in general, the "java" launcher will "execv()" itself to ensure it >>>> has the right LD_LIBRARY_PATH settings but this "execv()" can confuse >>>> gdb. To avoid it, you can either use the "gamma" launcher as explained >>>> in my blog ("gamma" does not execv, because the user is responsible to >>>> set the right LD_LIBRARY_PATH before calling "gamma"). The other >>>> possibility is to set the LD_LIBRARY_PATH manually before running >>>> "java" such that it begins with the prefix expected by the the >>>> launcher. In this case the launcher does not need to do an "execv()". >>>> To achieve this, you can set a breakpoint in >>>> "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris >>>> is no typo here!!!) and check the path the launcher expects to see for >>>> LD_LIBRARY_PATH (look for the value of "newpath"). >>>> >>>> - even if you followed the two points above, you can not easily set a >>>> breakpoint in the interpreter, because the interpreter is generated at >>>> startup. This means that there are no C-sources for the interpretation >>>> of a bytecode (instead there's C-code which generates code which will >>>> execute a bytecode). You can display the generated interpreter and the >>>> various stubs with the options "-XX:+PrintInterpreter" and >>>> "-XX:+PrintStubCode". You should use this together with >>>> "-XX:+PrintAssembly" to get a disassembly of the generated templates >>>> and stubs. (Notice that you need to compile and use the additional >>>> library "disassembler.so" for this to work. More information on the >>>> disassembler library can be found under: >>>> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly). >>>> >>>> - I suggest you run the VM once with "-XX:+PrintAssembly >>>> -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a >>>> file. You should do this in the debugger, such that the addresses of >>>> the generated code are the same like in the actual debug run. During a >>>> debugging session, you can then always cross check in which generated >>>> part of the interpreter you are. For a HotSpot debug build, you can >>>> also call the global "help()" function right from the debuger prompt. >>>> This will list some global helper functions from within libjvm.so >>>> which can be used during debugging (among them "find(
" which >>>> can be used to print out some information about an address which >>>> belongs to the VM (e.g. a compiled method, an interpreter template, a >>>> stub and s.o.)). >>>> >>>> - the "-XX:StopInterpreterAt=" is implemented in such >>>> a way, that every generated Java bytecode template first of all >>>> increments a global bytecode counter and then checks its value against >>>> the argument of "StopInterpreterAt". If the two numbers are equal, the >>>> global function "breakpoint()" will be called. "breakpoint()" is an >>>> empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If >>>> you want to stop at the execution of a certain Java bytecode, you >>>> should first of all run your program with "-XX:+TraceBytecodes" to >>>> determine the exact position of the bytecode you're interested in >>>> (hopefully this won't take to long, because indeed the VM already >>>> executes about half a million bytecodes before even arriving to your >>>> program's "main()" method - this is all class loading and >>>> initialization stuff). Then start the VM again with the appropriate >>>> "StopInterpreterAt" option AND set a breakpoint for the global >>>> "breakpoint()" function. The VM will now stop just before the >>>> execution of the bytecode you're interested in, but it will stop in >>>> the "breakpoint()" function. Issuing a "finish" command in gdb, will >>>> return you to the code template you're interested in (you should be >>>> able to verify this by looking up the current address within the file >>>> which contains the generated interpreter that we've created in the >>>> previous step). Notice that at this point, all you can do in gdb is >>>> stepping at assembler level ("stepi", "nexti") because you're in >>>> generated code now and there is no associated symbolic information for >>>> this code ("next" and "step" won't work). >>>> >>>> >>>> - certain, complex functionality of some bytecodes isn't handled >>>> directly in the generated code. Instead, some helper methods >>>> implemented in C++ in the VM are called. This is the case for example >>>> for InterpreterRuntime::monitorenter. You can check the bytecode >>>> generators, to see where there are calls into the runtime. >>>> >>>> Hope this helps. >>>> Regards, >>>> Volker >>>> >>>> On Mon, Jan 5, 2009 at 6:32 AM, wrote: >>>>> Hi Volker, >>>>> >>>>> Happy New Year. >>>>> Sorry to bother you. Thank you for your attention. >>>>> >>>>> I found your email about Hotspot build instruction from the >>>>> hotspot-dev >>>>> maillist and your blog. I do appreciate your great help. However, I >>>>> still >>>>> can't quite understand the mechanism of the interpreter in hotspot. >>>>> May I >>>>> ask you some questions? >>>>> >>>>> 1) I used ddd, a graphic based client of gdb, to set up some >>>>> breakpoints and >>>>> stepped into the hotspot jvm. I can find how exactly the bytecode is >>>>> executed, just like the following maillist: >>>>> http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results >>>>> .Do >>>>> you have some idea about that? >>>>> >>>>> BTW, I successfully step into to breakpoint of >>>>> StubRountes::call_stub while >>>>> using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' >>>>> to see >>>>> what is going in the Interpreter. However, it even generates a great >>>>> amount of bytecodes when it is initializing and load the system >>>>> class. I >>>>> don't know when the interpreter runtime is initialized. >>>>> >>>>> >>>>> 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', >>>>> aiming at stopping at a specific bytecode when I can inspect the >>>>> runtime >>>>> datastructure. Unfortunately I failed. I don't understand why >>>>> '-XX:StopInterpreterAt=1' doesn't work. The question is how to >>>>> configure it >>>>> correctly that I can stop where exactly I want. >>>>> >>>>> 3) My object is to get some information, especially about the lock and >>>>> thread information when threads concurrently access a shared >>>>> variant or try >>>>> to lock before access using monitorenter. Can you give me some >>>>> advise how >>>>> and where I can start? Is it related to the >>>>> InterpreterRuntime::monitorenter? >>>>> >>>>> I am looking forward to hearing from you. >>>>> >>>>> Regards, >>>>> >>>>> Alex Xie, >>>>> University of New South Wales, Australia. >>>> >> From elfarto+hs at elfarto.com Tue Jan 6 05:00:48 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Tue, 6 Jan 2009 05:00:48 -0800 (PST) Subject: A question about bytecodes Message-ID: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> Hi I've been hacking around on the JVM, attempting to add support for unsigned integers. I've managed to add several opcodes (based on baload, bipush, iinc, i2l, saload and sipush) that do zero-extending, rather than sign-extending. However, I came across a limit in the JVM. In bytecodes.cpp, there is this line: assert(number_of_codes <= 256, "too many bytecodes"); My question is, why is the JVM itself limited to 256 bytecodes? I understand the class file is limited due to a bytecode being 1 byte long, but I am confused as to why there is a hard limit like this. The only place I've seen so far which requires the bytecode to be 1 byte, is the C++ interpreter which casts the opcode to a jbyte. Are there any other places that require a bytecode to be 1 byte long? I was hoping to implement unsigned integers by just adding an 'unsigned' opcode, followed by the the opcode to modify (baload, etc) then remap the opcode to a 'virtual' unsigned_baload opcode when loading the class into the JVM. Thanks & Regards Stephen From Ulf.Zibis at gmx.de Tue Jan 6 05:07:10 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 06 Jan 2009 14:07:10 +0100 Subject: A question about bytecodes In-Reply-To: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> References: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> Message-ID: <4963577E.5070004@gmx.de> Very interesting, what you are doing. Good Luck ! I'm also often missing unsigned integers. Unfortunately I can't answer your question. -Ulf Am 06.01.2009 14:00, Stephen Dawkins schrieb: > Hi > > I've been hacking around on the JVM, attempting to add support for > unsigned integers. I've managed to add several opcodes (based on baload, > bipush, iinc, i2l, saload and sipush) that do zero-extending, rather than > sign-extending. > > However, I came across a limit in the JVM. In bytecodes.cpp, there is this > line: > > assert(number_of_codes <= 256, "too many bytecodes"); > > My question is, why is the JVM itself limited to 256 bytecodes? I > understand the class file is limited due to a bytecode being 1 byte long, > but I am confused as to why there is a hard limit like this. > > The only place I've seen so far which requires the bytecode to be 1 byte, > is the C++ interpreter which casts the opcode to a jbyte. Are there any > other places that require a bytecode to be 1 byte long? > > I was hoping to implement unsigned integers by just adding an 'unsigned' > opcode, followed by the the opcode to modify (baload, etc) then remap the > opcode to a 'virtual' unsigned_baload opcode when loading the class into > the JVM. > > Thanks & Regards > Stephen > > > From Coleen.Phillimore at Sun.COM Tue Jan 6 05:11:32 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Tue, 06 Jan 2009 08:11:32 -0500 Subject: Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk. In-Reply-To: <222BDECE3E51450EA8DB52CDC7EE31CF@PC200808102152> References: <859EDD5ABE474E40B4A54504A7EE4E4A@PC200808102152> <49630364.9050406@sun.com> <222BDECE3E51450EA8DB52CDC7EE31CF@PC200808102152> Message-ID: <1231247492.5358.15.camel@phillimores> The fast path monitorenter in the template interpreter is in the generated assembly code. You can find how objects are locked in interp_masm_.cpp in the function "lock_object()". This function is called for the monitorenter bytecode in the template interpreter, and in for synchronized methods for both the template and cpp interpreters. If you look in templateTable_.cpp for the function called monitorenter, that is the code that the template interpreter generates for monitorenter bytecode. If the lock needs to be inflated or cannot go through the fast path it will call the runtime function InterpreterRuntime::monitorenter(). To actually stop in the debugger for the "lock_object" call is tricky since it's generated code. One thing you can do is add 5 nops to the monitorenter bytecode at the beginning of the template function and recompile. Then Start the "gamma" command in gdb/dbx. Set a breakpoint in templateInterpreter right after the PrintInterpreter line. In current hotspot-rt repository that line is 599. Run with -XX:+PrintInterpreter and redirect to a file. Edit the file and find the monitorenter bytecode with your nops. Use stopi at the hex address for the nops. The code before the nops is entry points depending on the type that's on top of stack used by the dispatcher. Continue to breakpoint and stepi into the bytecode. This is not much fun but hope it helps. Coleen On Tue, 2009-01-06 at 19:04 +0800, xinweix at cse.unsw.edu.au wrote: > Hi David, > Thanks for your reply. > I've check out the "Hotspot Runtime Overview", which says that slow-path > means the lock state is inflated. In other words, it is locked or unlocked > but shared and contented. > > > InterpreterRuntime::monitorentry is the slow-path entry point for monitor > > acquisition. > Where is the fast-path entry point in the template interpreter, as I need to > know all information about each accessing of share variant? > > Regards, > Alex Xie > -------------------------------------------------- > From: "David Holmes - Sun Microsystems" > Sent: Tuesday, January 06, 2009 3:08 PM > To: > Cc: > Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question about > hotspot of openjdk. > > > Alex, > > > > -Xint runs only the interpreter, the JIT compiler is disabled. > > > > InterpreterRuntime::monitorentry is the slow-path entry point for monitor > > acquisition. If you look in bytecodeInterpreter.cpp you will see the > > fast-path code that is used - see line 612 for method calls for example. > > If you search for the calls to InterpreterRuntime::monitorentry you will > > see the fast-path code for the different cases preceding it. Note that > > there are two different fast-paths depending on whether biased-locking is > > enabled or not. > > > > If you want to track all monitor acquisitions then you will need to modify > > the interpreter itself to add your tracking code. > > > > Hope this helps. > > > > David Holmes > > > > > > xinweix at cse.unsw.edu.au said the following on 01/06/09 16:48: > >> Hi Volker, > >> > >> Thanks very much for your great help. I'd like to discuss with you the > >> following questions: > >> > >> 1. I've followed your advise of using '-XX:+TraceBytecodes' and identify > >> the specific bytecode instruction. However, I encountered the problem of > >> SEGV fault when it is executing in 'monitorenter' bytecode. I tried > >> several times, but failed all the same. > >> > >> 2. If I follow the option of '-Xint', is the mechanism of JIT compiler > >> working there? If not, is it in the mixed mode? How can it be activated? > >> Are there some entry points? I found some compiler introductions and > >> optimizations published in some papers, such as HIR(Highlevel > >> Intermediate Representation), LIR and SSA forms, etc. The IR is another > >> type of bytecode. If I want to instrument bytecode, such as > >> 'monitorenter', 'monitorexit', is it feasible to work on the IR? > >> > >> 3. I tried to use '-XX:+PrintAssembly' option to get some ouputs, that > >> are composed of the assembly codes with respect to each bytecode. Is it > >> that each bunch of assembly codes will be executed when 'Interpreter' > >> executes each bytecode? > >> > >> 4. Is it that the function InterpreterRuntime::monitor is the entry with > >> respect to 'monitorenter' so that I can do something here? > >> > >> Regards, > >> > >> Alex Xie > >> > >> -------------------------------------------------- > >> From: "Volker Simonis" > >> Sent: Monday, January 05, 2009 9:50 PM > >> To: > >> Cc: > >> Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question > >> about hotspot of openjdk. > >> > >>> Hi Alex, > >>> > >>> there are some things to consider if you want to debug the HotSpot > >>> interpreter: > >>> > >>> - gdb should work fairy well, however for some historic reasons, the > >>> debug version of HotSpot on Linux/x86 is built with "-gstabs". To get > >>> a better debugging experience, you should change this to "-g" at the > >>> end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild > >>> the VM with these new settings. > >>> > >>> - in general, the "java" launcher will "execv()" itself to ensure it > >>> has the right LD_LIBRARY_PATH settings but this "execv()" can confuse > >>> gdb. To avoid it, you can either use the "gamma" launcher as explained > >>> in my blog ("gamma" does not execv, because the user is responsible to > >>> set the right LD_LIBRARY_PATH before calling "gamma"). The other > >>> possibility is to set the LD_LIBRARY_PATH manually before running > >>> "java" such that it begins with the prefix expected by the the > >>> launcher. In this case the launcher does not need to do an "execv()". > >>> To achieve this, you can set a breakpoint in > >>> "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris > >>> is no typo here!!!) and check the path the launcher expects to see for > >>> LD_LIBRARY_PATH (look for the value of "newpath"). > >>> > >>> - even if you followed the two points above, you can not easily set a > >>> breakpoint in the interpreter, because the interpreter is generated at > >>> startup. This means that there are no C-sources for the interpretation > >>> of a bytecode (instead there's C-code which generates code which will > >>> execute a bytecode). You can display the generated interpreter and the > >>> various stubs with the options "-XX:+PrintInterpreter" and > >>> "-XX:+PrintStubCode". You should use this together with > >>> "-XX:+PrintAssembly" to get a disassembly of the generated templates > >>> and stubs. (Notice that you need to compile and use the additional > >>> library "disassembler.so" for this to work. More information on the > >>> disassembler library can be found under: > >>> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly). > >>> > >>> - I suggest you run the VM once with "-XX:+PrintAssembly > >>> -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a > >>> file. You should do this in the debugger, such that the addresses of > >>> the generated code are the same like in the actual debug run. During a > >>> debugging session, you can then always cross check in which generated > >>> part of the interpreter you are. For a HotSpot debug build, you can > >>> also call the global "help()" function right from the debuger prompt. > >>> This will list some global helper functions from within libjvm.so > >>> which can be used during debugging (among them "find(
" which > >>> can be used to print out some information about an address which > >>> belongs to the VM (e.g. a compiled method, an interpreter template, a > >>> stub and s.o.)). > >>> > >>> - the "-XX:StopInterpreterAt=" is implemented in such > >>> a way, that every generated Java bytecode template first of all > >>> increments a global bytecode counter and then checks its value against > >>> the argument of "StopInterpreterAt". If the two numbers are equal, the > >>> global function "breakpoint()" will be called. "breakpoint()" is an > >>> empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If > >>> you want to stop at the execution of a certain Java bytecode, you > >>> should first of all run your program with "-XX:+TraceBytecodes" to > >>> determine the exact position of the bytecode you're interested in > >>> (hopefully this won't take to long, because indeed the VM already > >>> executes about half a million bytecodes before even arriving to your > >>> program's "main()" method - this is all class loading and > >>> initialization stuff). Then start the VM again with the appropriate > >>> "StopInterpreterAt" option AND set a breakpoint for the global > >>> "breakpoint()" function. The VM will now stop just before the > >>> execution of the bytecode you're interested in, but it will stop in > >>> the "breakpoint()" function. Issuing a "finish" command in gdb, will > >>> return you to the code template you're interested in (you should be > >>> able to verify this by looking up the current address within the file > >>> which contains the generated interpreter that we've created in the > >>> previous step). Notice that at this point, all you can do in gdb is > >>> stepping at assembler level ("stepi", "nexti") because you're in > >>> generated code now and there is no associated symbolic information for > >>> this code ("next" and "step" won't work). > >>> > >>> > >>> - certain, complex functionality of some bytecodes isn't handled > >>> directly in the generated code. Instead, some helper methods > >>> implemented in C++ in the VM are called. This is the case for example > >>> for InterpreterRuntime::monitorenter. You can check the bytecode > >>> generators, to see where there are calls into the runtime. > >>> > >>> Hope this helps. > >>> Regards, > >>> Volker > >>> > >>> On Mon, Jan 5, 2009 at 6:32 AM, wrote: > >>>> Hi Volker, > >>>> > >>>> Happy New Year. > >>>> Sorry to bother you. Thank you for your attention. > >>>> > >>>> I found your email about Hotspot build instruction from the hotspot-dev > >>>> maillist and your blog. I do appreciate your great help. However, I > >>>> still > >>>> can't quite understand the mechanism of the interpreter in hotspot. May > >>>> I > >>>> ask you some questions? > >>>> > >>>> 1) I used ddd, a graphic based client of gdb, to set up some > >>>> breakpoints and > >>>> stepped into the hotspot jvm. I can find how exactly the bytecode is > >>>> executed, just like the following maillist: > >>>> http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results > >>>> .Do > >>>> you have some idea about that? > >>>> > >>>> BTW, I successfully step into to breakpoint of StubRountes::call_stub > >>>> while > >>>> using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to > >>>> see > >>>> what is going in the Interpreter. However, it even generates a great > >>>> amount of bytecodes when it is initializing and load the system class. > >>>> I > >>>> don't know when the interpreter runtime is initialized. > >>>> > >>>> > >>>> 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1', > >>>> aiming at stopping at a specific bytecode when I can inspect the > >>>> runtime > >>>> datastructure. Unfortunately I failed. I don't understand why > >>>> '-XX:StopInterpreterAt=1' doesn't work. The question is how to > >>>> configure it > >>>> correctly that I can stop where exactly I want. > >>>> > >>>> 3) My object is to get some information, especially about the lock and > >>>> thread information when threads concurrently access a shared variant or > >>>> try > >>>> to lock before access using monitorenter. Can you give me some advise > >>>> how > >>>> and where I can start? Is it related to the > >>>> InterpreterRuntime::monitorenter? > >>>> > >>>> I am looking forward to hearing from you. > >>>> > >>>> Regards, > >>>> > >>>> Alex Xie, > >>>> University of New South Wales, Australia. > >>> > > From Coleen.Phillimore at Sun.COM Tue Jan 6 06:53:45 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Tue, 06 Jan 2009 09:53:45 -0500 Subject: A question about bytecodes In-Reply-To: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> References: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> Message-ID: <1231253625.5358.32.camel@phillimores> The limit of one byte per bytecode opcode is inherited from the classfile format. When we load classfiles, in classFileParser.cpp we do: if (code_length > 0) { memcpy(m->code_base(), code_start, code_length); } Also, if you are using the template based interpreter, there are several assumptions that the bytecodes are one byte each, see interp_masm_.cpp dispatch_epilog(). The size of the bytecode is also implied by the structure in cpCacheOop.hpp which is the constant pool cache. This is used by both interpreters. Are you rewriting the bytecodes after they are loaded from the class in the rewriter? So there are only certain instances of baload for instance that are unsigned and others are sign extended? If you want all unsigned, just add a switch in globals.hpp. Hope this is helpful. Coleen On Tue, 2009-01-06 at 05:00 -0800, Stephen Dawkins wrote: > Hi > > I've been hacking around on the JVM, attempting to add support for > unsigned integers. I've managed to add several opcodes (based on baload, > bipush, iinc, i2l, saload and sipush) that do zero-extending, rather than > sign-extending. > > However, I came across a limit in the JVM. In bytecodes.cpp, there is this > line: > > assert(number_of_codes <= 256, "too many bytecodes"); > > My question is, why is the JVM itself limited to 256 bytecodes? I > understand the class file is limited due to a bytecode being 1 byte long, > but I am confused as to why there is a hard limit like this. > > The only place I've seen so far which requires the bytecode to be 1 byte, > is the C++ interpreter which casts the opcode to a jbyte. Are there any > other places that require a bytecode to be 1 byte long? > > I was hoping to implement unsigned integers by just adding an 'unsigned' > opcode, followed by the the opcode to modify (baload, etc) then remap the > opcode to a 'virtual' unsigned_baload opcode when loading the class into > the JVM. > > Thanks & Regards > Stephen > From Paul.Hohensee at Sun.COM Tue Jan 6 07:21:53 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 06 Jan 2009 10:21:53 -0500 Subject: A question about bytecodes In-Reply-To: <1231253625.5358.32.camel@phillimores> References: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> <1231253625.5358.32.camel@phillimores> Message-ID: <49637711.9060501@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090106/e33117cd/attachment.html From elfarto+hs at elfarto.com Tue Jan 6 08:44:49 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Tue, 6 Jan 2009 08:44:49 -0800 (PST) Subject: A question about bytecodes In-Reply-To: <49637711.9060501@sun.com> References: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> <1231253625.5358.32.camel@phillimores> <49637711.9060501@sun.com> Message-ID: <7d2a0e5087e41db02836103569677e3a.squirrel@webmail.elfarto.com> Hi Due to the way the the original assert is worded, there is still a limit of 256 entries in the Bytecode::Code enum, so even using another opcode as a prefix things are going to get messy (I'm thinking of the table in templateTable.cpp). 'unsigned' is fine, as it reuses the original set of opcodes and just modifies their meaning, however for anything new, like say SIMD primitives the 2nd opcode will have no relation to the opcodes that currently use 0-202. Prehaps I'm just being naive, but as I don't know much of hotspot (I only got it building a few days ago), how much effort would it be to resize opcodes to 16-bit (or 32-bit, but 65,536 opcodes should be enough for anyone...) through out the VM? (The class file definition wouldn't have to change.) Thanks & Regards Stephen > The template (assembly language) interpreter bytecode dispatch > code assumes > one-byte opcodes. > > If you're willing to accept more overhead, you can overload use of the > 'wide' > opcode. For all practical purposes, it acts like an x86 opcode prefix > byte and > thus adds 256 bytecode operations. Unfortunately, it's already used for > some > of the instructions you want to change, including iinc. In that case, > you can > take one of the currently unused opcodes, name it something like > 'twobyte' > and implement it the same way 'wide' is currently implemented. > > See the method TemplateTable::wide() at the bottom of, e.g., > templateTable_sparc.cpp. > It effectively does a redispatch using an alternate dispatch vector. > > The corresponding code in bytecodeInterpreter.cpp (see 'CASE(_wide)') > does the same > thing. > > Paul > > Coleen Phillimore wrote: The limit of one byte per bytecode opcode is > inherited from the classfile format. When we load classfiles, in > classFileParser.cpp we do: if (code_length > 0) { > memcpy(m->code_base(), code_start, code_length); } Also, if you are > using the template based interpreter, there are several assumptions that > the bytecodes are one byte each, see interp_masm_.cpp dispatch_epilog(). > The size of the bytecode is also implied by the structure in > cpCacheOop.hpp which is the constant pool cache. This is used by both > interpreters. Are you rewriting the bytecodes after they are loaded from > the class in the rewriter? So there are only certain instances of baload > for instance that are unsigned and others are sign extended? If you want > all unsigned, just add a switch in globals.hpp. Hope this is helpful. > Coleen On Tue, 2009-01-06 at 05:00 -0800, Stephen Dawkins wrote: > Hi I've been hacking around on the JVM, attempting to add support for > unsigned integers. I've managed to add several opcodes (based on baload, > bipush, iinc, i2l, saload and sipush) that do zero-extending, rather than > sign-extending. However, I came across a limit in the JVM. In > bytecodes.cpp, there is this line: assert(number_of_codes From elfarto+hs at elfarto.com Tue Jan 6 08:46:02 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Tue, 6 Jan 2009 08:46:02 -0800 (PST) Subject: A question about bytecodes Message-ID: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> (resent to list as I forgot to reply to all) Hi Thank you for your reply, it is very informative. Yes, I am looking to have signed and unsigned versions of the opcodes at the same time, so a global switch is not an option. I am looking to have the 'unsigned' opcode work similarly to the 'wide' opcode in the class file, I just don't really want to add another lookup like wide has in the template interpreter. I believe it would be better to slightly abstract the JVM from the class file definition. The JVM doesn't really care how the bytecodes are represented in the class file, whether it takes 1 or 2 bytes. I want to have 2 seperate opcodes in the class file (like wide does), but transform them into a 'virtual' opcode (like the _fast_getfield and friends) while loading it. I only raise this as even though unsigned integers can be implemented without going over the 256 code limit, I also want to try my hand at adding SSE primitives to Java, and that will certainly push it over. Thanks & Regards Stephen > > The limit of one byte per bytecode opcode is inherited from the > classfile format. When we load classfiles, in classFileParser.cpp we > do: > > if (code_length > 0) { > memcpy(m->code_base(), code_start, code_length); > } > > Also, if you are using the template based interpreter, there are several > assumptions that the bytecodes are one byte each, see > interp_masm_.cpp dispatch_epilog(). > The size of the bytecode is also implied by the structure in > cpCacheOop.hpp which is the constant pool cache. This is used by both > interpreters. > > Are you rewriting the bytecodes after they are loaded from the class in > the rewriter? So there are only certain instances of baload for > instance that are unsigned and others are sign extended? If you want > all unsigned, just add a switch in globals.hpp. > > Hope this is helpful. > Coleen > > On Tue, 2009-01-06 at 05:00 -0800, Stephen Dawkins wrote: >> Hi >> >> I've been hacking around on the JVM, attempting to add support for >> unsigned integers. I've managed to add several opcodes (based on baload, >> bipush, iinc, i2l, saload and sipush) that do zero-extending, rather >> than >> sign-extending. >> >> However, I came across a limit in the JVM. In bytecodes.cpp, there is >> this >> line: >> >> assert(number_of_codes <= 256, "too many bytecodes"); >> >> My question is, why is the JVM itself limited to 256 bytecodes? I >> understand the class file is limited due to a bytecode being 1 byte >> long, >> but I am confused as to why there is a hard limit like this. >> >> The only place I've seen so far which requires the bytecode to be 1 >> byte, >> is the C++ interpreter which casts the opcode to a jbyte. Are there any >> other places that require a bytecode to be 1 byte long? >> >> I was hoping to implement unsigned integers by just adding an 'unsigned' >> opcode, followed by the the opcode to modify (baload, etc) then remap >> the >> opcode to a 'virtual' unsigned_baload opcode when loading the class into >> the JVM. >> >> Thanks & Regards >> Stephen >> > > From Paul.Hohensee at Sun.COM Tue Jan 6 09:09:14 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 06 Jan 2009 12:09:14 -0500 Subject: A question about bytecodes In-Reply-To: <7d2a0e5087e41db02836103569677e3a.squirrel@webmail.elfarto.com> References: <27b194a42b2ed520cc1e598b40c55d42.squirrel@webmail.elfarto.com> <1231253625.5358.32.camel@phillimores> <49637711.9060501@sun.com> <7d2a0e5087e41db02836103569677e3a.squirrel@webmail.elfarto.com> Message-ID: <4963903A.3090302@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090106/6118d6e4/attachment.html From doko at ubuntu.com Tue Jan 6 15:13:37 2009 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 07 Jan 2009 00:13:37 +0100 Subject: how to build without precompiled headers? In-Reply-To: <496242E8.10509@sun.com> References: <49613144.90706@ubuntu.com> <496242E8.10509@sun.com> Message-ID: <4963E5A1.3060605@ubuntu.com> Thanks, please see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38725 looks like current GCC versions accept invalid code: "That's really a duplicate of PR38725: The code contains many lines of the form goto *dispatch_table[opcode]; where dispatch_table[opcode] is of the type uintptr_t which is a typedef to unsigned int. Writing goto *(void*)dispatch_table[opcode]; instead makes the ICE disappear." Coleen Phillimore - Sun Microsystems schrieb: > > I tried this on my new 8.10 ubuntu system at home and commenting out > USE_PRECOMPILED_HEADER didn't use the precompiled header. The file > _precompiled.incl is still produced but it's empty. I believe you have > to do a make clean before your gcc.make change is used. > > The version of gcc that I used was very picky about inlined functions > not being defined in places where the other platforms were happy, so > there were multiple warnings with this message. I have a patch file that > resolves this, if you want it. > Also, on my 8.10 ubuntu, gcc version 4.1.forgot, I got an error building > fastdebug (server compiler) which I haven't resolved. > > /home/coleenp/hotspot/src/share/vm/libadt/port.hpp:40: error: 'void > bcopy(const void*, void*, size_t)' redeclared inline without > 'gnu_inline' attribute > > If you're trying to track down a compiler error building hotspot, try > getting a preprocessed output file to narrow it down. > cd linux*/ > make .i > > Hope this helps. > Coleen > > On 01/04/09 16:59, Matthias Klose wrote: >> Trying to track down an ICE (internal compiler error), I need to build >> hotspot >> without precompiled header files. There is a macro >> USE_PRECOMPILED_HEADER >> defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just >> removing the >> conditional around this definition still builds using precompiled >> header files. >> How can you build without precompiled header files (even if it's a hack)? >> >> Matthias >> From thomas.rodriguez at sun.com Tue Jan 6 19:06:21 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 07 Jan 2009 03:06:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090107030627.6E7EED184@hg.openjdk.java.net> Changeset: 6d8fc951eb25 Author: kvn Date: 2008-12-22 15:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6d8fc951eb25 6778657: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined C++ behaviour Summary: Replaces SharedRuntime::f2i et al with versions that should work Reviewed-by: never Contributed-by: gbenson at redhat.com ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6778657/Test.java Changeset: 9656bebe85a7 Author: kvn Date: 2008-12-22 16:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9656bebe85a7 6778662: fixes 64-bits libraries directory search paths on linux Summary: Fixes 64-bits libraries directory search paths. Reviewed-by: never Contributed-by: langel at redhat.com ! src/os/linux/vm/os_linux.cpp Changeset: 1a767c61ad01 Author: never Date: 2009-01-06 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1a767c61ad01 Merge From xinweix at cse.unsw.EDU.AU Tue Jan 6 21:16:41 2009 From: xinweix at cse.unsw.EDU.AU (Xinwei Xie) Date: Wed, 7 Jan 2009 16:16:41 +1100 Subject: Does anybody know this? Thanks. Message-ID: <20090107051641.GB11212@cse.unsw.EDU.AU> Hi,everybody Does someone know this? Thanks. >> I found some compiler introductions and >> optimizations published in some papers, such as HIR(Highlevel >> Intermediate Representation), LIR and SSA forms, etc. The IR is another >> type of bytecode. If I want to instrument bytecode, such as >> 'monitorenter', 'monitorexit', is it feasible to work on the IR? Regards, Alex Xie University of New South Wales From christian.thalinger at gmail.com Wed Jan 7 00:30:38 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Wed, 07 Jan 2009 09:30:38 +0100 Subject: Does anybody know this? Thanks. In-Reply-To: <20090107051641.GB11212@cse.unsw.EDU.AU> References: <20090107051641.GB11212@cse.unsw.EDU.AU> Message-ID: <1231317038.16494.2.camel@localhost.localdomain> On Wed, 2009-01-07 at 16:16 +1100, Xinwei Xie wrote: > Hi,everybody > > Does someone know this? Thanks. > >> I found some compiler introductions and > >> optimizations published in some papers, such as HIR(Highlevel > >> Intermediate Representation), LIR and SSA forms, etc. The IR is another > >> type of bytecode. If I want to instrument bytecode, such as > >> 'monitorenter', 'monitorexit', is it feasible to work on the IR? It's possible to do this on the IR level, yes. But normally it is much more work than just modifying the functions you want to instrument. It also depends on _what_ information you want to gather. - Christian From Joe.Darcy at Sun.COM Wed Jan 7 15:14:49 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 07 Jan 2009 15:14:49 -0800 Subject: A question about bytecodes In-Reply-To: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> Message-ID: <49653769.5030102@sun.com> Stephen Dawkins wrote: > (resent to list as I forgot to reply to all) > > Hi > > Thank you for your reply, it is very informative. > > Yes, I am looking to have signed and unsigned versions of the opcodes at > the same time, so a global switch is not an option. > > I am looking to have the 'unsigned' opcode work similarly to the 'wide' > opcode in the class file, I just don't really want to add another lookup > like wide has in the template interpreter. I believe it would be better to > slightly abstract the JVM from the class file definition. The JVM doesn't > really care how the bytecodes are represented in the class file, whether > it takes 1 or 2 bytes. > > I want to have 2 seperate opcodes in the class file (like wide does), but > transform them into a 'virtual' opcode (like the _fast_getfield and > friends) while loading it. > > I only raise this as even though unsigned integers can be implemented > without going over the 256 code limit, I also want to try my hand at > adding SSE primitives to Java, and that will certainly push it over. > One of the benefits of using a two's-complement encoding for integral types is that signed and unsigned add, subtract, and multiply give the same bit-wise results. Therefore presumably only conversion, divide, and comparison operations would be needed to explicitly operate on unsigned data. -Joe > Thanks & Regards > Stephen > >> The limit of one byte per bytecode opcode is inherited from the >> classfile format. When we load classfiles, in classFileParser.cpp we >> do: >> >> if (code_length > 0) { >> memcpy(m->code_base(), code_start, code_length); >> } >> >> Also, if you are using the template based interpreter, there are several >> assumptions that the bytecodes are one byte each, see >> interp_masm_.cpp dispatch_epilog(). >> The size of the bytecode is also implied by the structure in >> cpCacheOop.hpp which is the constant pool cache. This is used by both >> interpreters. >> >> Are you rewriting the bytecodes after they are loaded from the class in >> the rewriter? So there are only certain instances of baload for >> instance that are unsigned and others are sign extended? If you want >> all unsigned, just add a switch in globals.hpp. >> >> Hope this is helpful. >> Coleen >> >> On Tue, 2009-01-06 at 05:00 -0800, Stephen Dawkins wrote: >> >>> Hi >>> >>> I've been hacking around on the JVM, attempting to add support for >>> unsigned integers. I've managed to add several opcodes (based on baload, >>> bipush, iinc, i2l, saload and sipush) that do zero-extending, rather >>> than >>> sign-extending. >>> >>> However, I came across a limit in the JVM. In bytecodes.cpp, there is >>> this >>> line: >>> >>> assert(number_of_codes <= 256, "too many bytecodes"); >>> >>> My question is, why is the JVM itself limited to 256 bytecodes? I >>> understand the class file is limited due to a bytecode being 1 byte >>> long, >>> but I am confused as to why there is a hard limit like this. >>> >>> The only place I've seen so far which requires the bytecode to be 1 >>> byte, >>> is the C++ interpreter which casts the opcode to a jbyte. Are there any >>> other places that require a bytecode to be 1 byte long? >>> >>> I was hoping to implement unsigned integers by just adding an 'unsigned' >>> opcode, followed by the the opcode to modify (baload, etc) then remap >>> the >>> opcode to a 'virtual' unsigned_baload opcode when loading the class into >>> the JVM. >>> >>> Thanks & Regards >>> Stephen >>> >>> >> > > > > From Joe.Darcy at Sun.COM Wed Jan 7 15:31:25 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Wed, 07 Jan 2009 15:31:25 -0800 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: References: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM> Message-ID: <49653B4D.2010806@sun.com> Hello. As of OpenJDK 6 build 14, we've upgraded to HotSpot 11 from HotSpot 10: http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-December/000281.html In the near future, we'll be upgrading again from HS 11 to HS 14; so I don't think there is a lot of motivation to take the ported AsyncGetCallTrace patch back to older HotSpot trains at this point. -Joe On 12/31/08 05:34 PM, Hiroshi Yamauchi wrote: > I still hope this patch will be accepted. > > On Fri, Sep 26, 2008 at 12:55 PM, Hiroshi Yamauchi wrote: > >> With the patch, I haven't seen it crash in my experience. >> >> Hiroshi >> >> On Thu, Sep 25, 2008 at 12:29 PM, Tom Rodriguez >> wrote: >> >>>> I'm not sure what you mean by collector. But as far as I can tell >>>> AsyncGetCallTrace >>>> is a lot more stable and shows more stack frames with the patch. If Sun >>>> folks >>>> have tests for it, it'd be great if someone can run them against this >>>> patch. >>>> >>> I was only referring to testing it with a profiling tool and the SunStudio >>> collector is the only one I know of that uses AsyncGetCallTrace. When you >>> say "a lot more stable" do you mean it doesn't crash or it crashes less? >>> >>> tom >>> >>> >>>> Thanks, >>>> Hiroshi >>>> >>>> >>>> >>>>> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote: >>>>> >>>>> >>>>>> Hi, Any comment about the patch itself? >>>>>> >>>>>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy >>>>>> wrote: >>>>>> >>>>>>> Joseph D. Darcy wrote: >>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>>> 2008/9/11 Andrew John Hughes : >>>>>>>>> >>>>>>>>>> 2008/9/11 Daniel D. Daugherty : >>>>>>>>>> >>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>> >>>>>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>>>>>>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>>>>>>>>> not that strange. >>>>>>>>>>> >>>>>>>>>>> JDK7-B24 has the following values: >>>>>>>>>>> >>>>>>>>>>> HS_MAJOR_VER=12 >>>>>>>>>>> HS_MINOR_VER=0 >>>>>>>>>>> HS_BUILD_NUMBER=01 >>>>>>>>>>> >>>>>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>>>>>>>> I see: >>>>>>>>>>> >>>>>>>>>>> HS_MAJOR_VER=10 >>>>>>>>>>> HS_MINOR_VER=0 >>>>>>>>>>> HS_BUILD_NUMBER=23 >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hmmm... >>>>>>>>>> Then either Gary's HotSpot patch doesn't update that file or >>>>>>>>>> OpenJDK6 >>>>>>>>>> is not based on the same as this 1.6.0_07 thing you mention. >>>>>>>>>> I'll try and have a closer look later. >>>>>>>>>> -- >>>>>>>>>> Andrew :-) >>>>>>>>>> >>>>>>>>>> Support Free Java! >>>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>>> http://openjdk.java.net >>>>>>>>>> >>>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> IcedTea6 contains: >>>>>>>>> >>>>>>>>> HS_MAJOR_VER=10 >>>>>>>>> HS_MINOR_VER=0 >>>>>>>>> HS_BUILD_NUMBER=19 >>>>>>>>> >>>>>>>>> IcedTea/b33 contains: >>>>>>>>> >>>>>>>>> HS_MAJOR_VER=14 >>>>>>>>> HS_MINOR_VER=0 >>>>>>>>> HS_BUILD_NUMBER=01 >>>>>>>>> >>>>>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>>>>>>>> make/hotspot_version >>>>>>>>> so it's actually worryingly building a different version of HotSpot >>>>>>>>> from the one it thinks it is. >>>>>>>>> It will actually be 12-0-01 as you state, but will report 10-0-19. >>>>>>>>> >>>>>>>>> Overall, it would be better to always build against the most recent >>>>>>>>> stable HotSpot tree if possible >>>>>>>>> rather than the one provided by the build drop. Do we know what the >>>>>>>>> most stable would be? >>>>>>>>> >>>>>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. >>>>>>>> The >>>>>>>> policy I've implemented, >>>>>>>> >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, >>>>>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update >>>>>>>> releases, >>>>>>>> augmented with some other fixes for license corrections, gcc build >>>>>>>> issues, >>>>>>>> (and the occasional Eclipse crash). The HotSpot in the base OpenJDK 6 >>>>>>>> code >>>>>>>> base is very close to the HotSpot in the currently shipping 6 update >>>>>>>> release. >>>>>>>> >>>>>>> ... and going forward we will have much closer coordination between the >>>>>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same source >>>>>>> for >>>>>>> both; so the version information should be updated consistently, etc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>> >>> From Thomas.Rodriguez at Sun.COM Wed Jan 7 15:37:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 07 Jan 2009 15:37:15 -0800 Subject: A question about bytecodes In-Reply-To: <49653769.5030102@sun.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> Message-ID: >> I only raise this as even though unsigned integers can be implemented >> without going over the 256 code limit, I also want to try my hand at >> adding SSE primitives to Java, and that will certainly push it over. >> > > One of the benefits of using a two's-complement encoding for > integral types is that signed and unsigned add, subtract, and > multiply give the same bit-wise results. Therefore presumably only > conversion, divide, and comparison operations would be needed to > explicitly operate on unsigned data. You'd need to do loads as well unless you wanted to hack it with and'ing to get rid of any sign extension. tom > > > -Joe > >> Thanks & Regards >> Stephen >> >>> The limit of one byte per bytecode opcode is inherited from the >>> classfile format. When we load classfiles, in classFileParser.cpp >>> we >>> do: >>> >>> if (code_length > 0) { >>> memcpy(m->code_base(), code_start, code_length); >>> } >>> >>> Also, if you are using the template based interpreter, there are >>> several >>> assumptions that the bytecodes are one byte each, see >>> interp_masm_.cpp dispatch_epilog(). >>> The size of the bytecode is also implied by the structure in >>> cpCacheOop.hpp which is the constant pool cache. This is used by >>> both >>> interpreters. >>> >>> Are you rewriting the bytecodes after they are loaded from the >>> class in >>> the rewriter? So there are only certain instances of baload for >>> instance that are unsigned and others are sign extended? If you >>> want >>> all unsigned, just add a switch in globals.hpp. >>> >>> Hope this is helpful. >>> Coleen >>> >>> On Tue, 2009-01-06 at 05:00 -0800, Stephen Dawkins wrote: >>> >>>> Hi >>>> >>>> I've been hacking around on the JVM, attempting to add support for >>>> unsigned integers. I've managed to add several opcodes (based on >>>> baload, >>>> bipush, iinc, i2l, saload and sipush) that do zero-extending, >>>> rather >>>> than >>>> sign-extending. >>>> >>>> However, I came across a limit in the JVM. In bytecodes.cpp, >>>> there is >>>> this >>>> line: >>>> >>>> assert(number_of_codes <= 256, "too many bytecodes"); >>>> >>>> My question is, why is the JVM itself limited to 256 bytecodes? I >>>> understand the class file is limited due to a bytecode being 1 byte >>>> long, >>>> but I am confused as to why there is a hard limit like this. >>>> >>>> The only place I've seen so far which requires the bytecode to be 1 >>>> byte, >>>> is the C++ interpreter which casts the opcode to a jbyte. Are >>>> there any >>>> other places that require a bytecode to be 1 byte long? >>>> >>>> I was hoping to implement unsigned integers by just adding an >>>> 'unsigned' >>>> opcode, followed by the the opcode to modify (baload, etc) then >>>> remap >>>> the >>>> opcode to a 'virtual' unsigned_baload opcode when loading the >>>> class into >>>> the JVM. >>>> >>>> Thanks & Regards >>>> Stephen >>>> >>>> >>> >> >> >> >> > From elfarto+hs at elfarto.com Thu Jan 8 06:02:09 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Thu, 8 Jan 2009 06:02:09 -0800 (PST) Subject: A question about bytecodes In-Reply-To: References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> Message-ID: <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> >>> I only raise this as even though unsigned integers can be implemented >>> without going over the 256 code limit, I also want to try my hand at >>> adding SSE primitives to Java, and that will certainly push it over. >>> >> >> One of the benefits of using a two's-complement encoding for >> integral types is that signed and unsigned add, subtract, and >> multiply give the same bit-wise results. Therefore presumably only >> conversion, divide, and comparison operations would be needed to >> explicitly operate on unsigned data. > > You'd need to do loads as well unless you wanted to hack it with > and'ing to get rid of any sign extension. > > tom > baload, saload, i2l, i2b, idiv, ldiv, irem, lrem, i2f, i2d, l2f, l2d if_icmplt, if_icmpge, if_icmpgt, if_icmple, iflt, ifge, ifgt, ifle I believe that's the complete list. bipush, sipush and iinc are possible candidates, but can be achieved via other methods. Regards Stephen From Thomas.Rodriguez at Sun.COM Thu Jan 8 10:12:11 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 08 Jan 2009 10:12:11 -0800 Subject: A question about bytecodes In-Reply-To: <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> Message-ID: <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> You don't really need to do saload since caload is an unsigned 16 bit load. Don't you need to an unsigned version of lcmp? The if?? bytecodes operates on the 3 way result from that so you don't _have_ to add unsigned variants of them I think. They just duplicate the functionality of the if_icmp?? bytecodes with a 0. So since you aren't adding unsigned getfield you must be adding a new type descriptor to the VM signatures to deal with unsigned fields? tom On Jan 8, 2009, at 6:02 AM, Stephen Dawkins wrote: >>>> I only raise this as even though unsigned integers can be >>>> implemented >>>> without going over the 256 code limit, I also want to try my hand >>>> at >>>> adding SSE primitives to Java, and that will certainly push it >>>> over. >>>> >>> >>> One of the benefits of using a two's-complement encoding for >>> integral types is that signed and unsigned add, subtract, and >>> multiply give the same bit-wise results. Therefore presumably only >>> conversion, divide, and comparison operations would be needed to >>> explicitly operate on unsigned data. >> >> You'd need to do loads as well unless you wanted to hack it with >> and'ing to get rid of any sign extension. >> >> tom >> > > baload, saload, i2l, i2b, idiv, ldiv, irem, lrem, i2f, i2d, l2f, l2d > if_icmplt, if_icmpge, if_icmpgt, if_icmple, iflt, ifge, ifgt, ifle > > I believe that's the complete list. > > bipush, sipush and iinc are possible candidates, but can be achieved > via > other methods. > > Regards > Stephen > From elfarto+hs at elfarto.com Thu Jan 8 11:52:24 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Thu, 08 Jan 2009 19:52:24 +0000 Subject: A question about bytecodes In-Reply-To: <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> Message-ID: <49665978.8070206@elfarto.com> Tom Rodriguez wrote: > You don't really need to do saload since caload is an unsigned 16 bit > load. Thats correct. > Don't you need to an unsigned version of lcmp? *sigh*, it seems like everytime I think I've got all of them, another one appears. > The if?? > bytecodes operates on the 3 way result from that so you don't _have_ to > add unsigned variants of them I think. I assume the if?? variants can operate on a regular int aswell? Then we'll need an unsigned ifge and ifgt. iflt and ifle are actually invalid for unsigned numbers. > They just duplicate the > functionality of the if_icmp?? bytecodes with a 0. So since you aren't > adding unsigned getfield you must be adding a new type descriptor to the > VM signatures to deal with unsigned fields? > Ok, it looks like I'll need unsigned versions of them too, and the _fast_* versions. I really don't want to go through the VM adding 3 new primitives in just for unsigned integers. From what I've seen this would be an excessive amount of work. (I should point out, I really don't know what I'm doing yet :)) The one issue I've got is, as I don't want to go add new type signatures how do I decern return types/parameter types? I thought about an annotation @Unsigned. Regards Stephen > tom > > On Jan 8, 2009, at 6:02 AM, Stephen Dawkins wrote: > >>>>> I only raise this as even though unsigned integers can be implemented >>>>> without going over the 256 code limit, I also want to try my hand at >>>>> adding SSE primitives to Java, and that will certainly push it over. >>>>> >>>> >>>> One of the benefits of using a two's-complement encoding for >>>> integral types is that signed and unsigned add, subtract, and >>>> multiply give the same bit-wise results. Therefore presumably only >>>> conversion, divide, and comparison operations would be needed to >>>> explicitly operate on unsigned data. >>> >>> You'd need to do loads as well unless you wanted to hack it with >>> and'ing to get rid of any sign extension. >>> >>> tom >>> >> >> baload, saload, i2l, i2b, idiv, ldiv, irem, lrem, i2f, i2d, l2f, l2d >> if_icmplt, if_icmpge, if_icmpgt, if_icmple, iflt, ifge, ifgt, ifle >> >> I believe that's the complete list. >> >> bipush, sipush and iinc are possible candidates, but can be achieved via >> other methods. >> >> Regards >> Stephen >> > > From doko at ubuntu.com Thu Jan 8 14:30:19 2009 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 08 Jan 2009 23:30:19 +0100 Subject: [patch] missing include file in hotspot 14.0b08 Message-ID: <49667E7B.7010301@ubuntu.com> seen while building without precompiled headers Matthias -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xxxxx.diff Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090108/0250399d/attachment.ksh From Thomas.Rodriguez at Sun.COM Fri Jan 9 13:27:16 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Jan 2009 13:27:16 -0800 Subject: A question about bytecodes In-Reply-To: <49665978.8070206@elfarto.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> Message-ID: <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> >> The if?? bytecodes operates on the 3 way result from that so you >> don't _have_ to add unsigned variants of them I think. > > I assume the if?? variants can operate on a regular int aswell? Then > we'll need an unsigned ifge and ifgt. iflt and ifle are actually > invalid > for unsigned numbers. They can be used with it but they are just a special case encoding of ificmp that's not absolutely necessary for unsigned support. > I really don't want to go through the VM adding 3 new primitives in > just > for unsigned integers. From what I've seen this would be an excessive > amount of work. (I should point out, I really don't know what I'm > doing > yet :)) Indeed it would. One thing I might mention is that there's another approach to adding unsigned which is to do in the form of an API that's expected to be intrinsified by the JVM. The performance of this would/could be exactly the same as a bytecoded version without requiring a change to the JVM specification for adoption, which I think is a largely insurmountable barrier. Any way you slice it, javac would have to be updated to emit something different so either implementation would appear the same from the user standpoint. The only ugly ones from an API perspective are the unsigned byte versions of getstatic/getfield/ baload. Those could simply by fudged by emitting a following & 0xff. I vaguely remember a proposal like this being mooted about a few years ago but I don't know what happened to it. If you go the bytecode route with the expectation of JVM spec support then I think you would need to update the type signatures to include unsigned types. I think a spec change would require more uniformity of implementation. tom > > > The one issue I've got is, as I don't want to go add new type > signatures > how do I decern return types/parameter types? I thought about an > annotation @Unsigned. > > Regards > Stephen > >> tom >> On Jan 8, 2009, at 6:02 AM, Stephen Dawkins wrote: >>>>>> I only raise this as even though unsigned integers can be >>>>>> implemented >>>>>> without going over the 256 code limit, I also want to try my >>>>>> hand at >>>>>> adding SSE primitives to Java, and that will certainly push it >>>>>> over. >>>>>> >>>>> >>>>> One of the benefits of using a two's-complement encoding for >>>>> integral types is that signed and unsigned add, subtract, and >>>>> multiply give the same bit-wise results. Therefore presumably >>>>> only >>>>> conversion, divide, and comparison operations would be needed to >>>>> explicitly operate on unsigned data. >>>> >>>> You'd need to do loads as well unless you wanted to hack it with >>>> and'ing to get rid of any sign extension. >>>> >>>> tom >>>> >>> >>> baload, saload, i2l, i2b, idiv, ldiv, irem, lrem, i2f, i2d, l2f, l2d >>> if_icmplt, if_icmpge, if_icmpgt, if_icmple, iflt, ifge, ifgt, ifle >>> >>> I believe that's the complete list. >>> >>> bipush, sipush and iinc are possible candidates, but can be >>> achieved via >>> other methods. >>> >>> Regards >>> Stephen >>> > From Joe.Darcy at Sun.COM Fri Jan 9 13:43:38 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 09 Jan 2009 13:43:38 -0800 Subject: A question about bytecodes In-Reply-To: <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> Message-ID: <4967C50A.3080805@sun.com> Tom Rodriguez wrote: >>> The if?? bytecodes operates on the 3 way result from that so you >>> don't _have_ to add unsigned variants of them I think. >> >> I assume the if?? variants can operate on a regular int aswell? Then >> we'll need an unsigned ifge and ifgt. iflt and ifle are actually invalid >> for unsigned numbers. > > They can be used with it but they are just a special case encoding of > ificmp that's not absolutely necessary for unsigned support. > >> I really don't want to go through the VM adding 3 new primitives in just >> for unsigned integers. From what I've seen this would be an excessive >> amount of work. (I should point out, I really don't know what I'm doing >> yet :)) > > Indeed it would. > > One thing I might mention is that there's another approach to adding > unsigned which is to do in the form of an API that's expected to be > intrinsified by the JVM. The performance of this would/could be > exactly the same as a bytecoded version without requiring a change to > the JVM specification for adoption, which I think is a largely > insurmountable barrier. Any way you slice it, javac would have to be > updated to emit something different so either implementation would > appear the same from the user standpoint. The only ugly ones from an > API perspective are the unsigned byte versions of > getstatic/getfield/baload. Those could simply by fudged by emitting a > following & 0xff. I vaguely remember a proposal like this being > mooted about a few years ago but I don't know what happened to it. > > If you go the bytecode route with the expectation of JVM spec support > then I think you would need to update the type signatures to include > unsigned types. I think a spec change would require more uniformity > of implementation. > > tom If unsigned support is going to be added to the platform, I agree the most tractable way to do so at this point is through library support without explicit language or JVM changes, 4504839 "Java libraries should provide support for unsigned integer arithmetic." To help track (un)signedness in code and make sure any needed conversions weren't missing, an annotation processing checker from JSR 308 could be used. -Joe From John.Rose at Sun.COM Fri Jan 9 15:17:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Jan 2009 15:17:16 -0800 Subject: A question about bytecodes In-Reply-To: <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> Message-ID: <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> On Jan 9, 2009, at 1:27 PM, Tom Rodriguez wrote: > One thing I might mention is that there's another approach to > adding unsigned which is to do in the form of an API that's > expected to be intrinsified by the JVM. The performance of this > would/could be exactly the same as a bytecoded version without > requiring a change to the JVM specification for adoption, which I > think is a largely insurmountable barrier. That's the material point. Let's be clear: There is almost *never* a reason to add a new bytecode, because an intrinsic method will almost *always* work just as well. Any change to bytecodes requires lots of VM and tool changes by every vendor, which means it had better be really important and with no feasible alternative (such as intrinsic methods). In particular, adding lots of new bytecodes to express something as simple as unsigned operations is a waste of limited bytecode coding space (unless a system of prefixes were invented). Note that compilers tend to optimize expressions like myByteArray[i] & 0xFF into unsigned loads, and packaging this into an intrinsic method would add predicability of compilation (if anybody cares), and the case is not frequent enough to warrant shaving a few bytes off the instruction format. For example, I work on JSR 292, which is adding one bytecode for invokedynamic; every other operation (and it's a much richer API than unsigned arithmetic) can be expressed in terms of existing bytecodes. The invokedynamic operation cannot be emulated in existing bytecodes without an order of magnitude or more of size and speed degradation, and it occurs (will occur) frequently in certain common types of user code (byte-compiled dynamic languages). Even so, it took 10 years to introduce it. Stephen, if you want a project that really does appear to require new bytecodes, but which nobody has attempted yet, I recommend you look at this one: http://blogs.sun.com/jrose/entry/tuples_in_the_vm Best wishes, -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090109/5e4c6ea9/attachment.html From Ulf.Zibis at gmx.de Fri Jan 9 15:44:49 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 10 Jan 2009 00:44:49 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> Message-ID: <4967E171.6070307@gmx.de> Am 10.01.2009 00:17, John Rose schrieb: > > Note that compilers tend to optimize expressions like myByteArray[i] > & 0xFF into unsigned loads, and packaging this into an intrinsic > method would add predicability of compilation (if anybody cares), and > the case is not frequent enough to warrant shaving a few bytes off the > instruction format. > ... but myByte + 0x80 is faster than myByte & 0xFF. For me this is an unintelligible mystery. source see here (line 141..144): http://hg.openjdk.java.net/jdk7/tl/jdk/file/b89ba9a6d9a6/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java How can adding be faster than unsigned load of a byte? -Ulf From Ulf.Zibis at gmx.de Fri Jan 9 15:55:25 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 10 Jan 2009 00:55:25 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <4967E171.6070307@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> Message-ID: <4967E3ED.40409@gmx.de> Also see the regarding bugreport and it's benchmarks in evaluation section: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6642323 -Ulf Am 10.01.2009 00:44, Ulf Zibis schrieb: > Am 10.01.2009 00:17, John Rose schrieb: >> >> Note that compilers tend to optimize expressions like myByteArray[i] >> & 0xFF into unsigned loads, and packaging this into an intrinsic >> method would add predicability of compilation (if anybody cares), and >> the case is not frequent enough to warrant shaving a few bytes off >> the instruction format. >> > ... but myByte + 0x80 is faster than myByte & 0xFF. For me this is an > unintelligible mystery. > source see here (line 141..144): > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/b89ba9a6d9a6/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java > > > How can adding be faster than unsigned load of a byte? > > -Ulf > > From John.Rose at Sun.COM Fri Jan 9 17:05:13 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Jan 2009 17:05:13 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <4967E171.6070307@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> Message-ID: <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> On Jan 9, 2009, at 3:44 PM, Ulf Zibis wrote: > Am 10.01.2009 00:17, John Rose schrieb: >> >> Note that compilers tend to optimize expressions like myByteArray >> [i] & 0xFF into unsigned loads, and packaging this into an >> intrinsic method would add predicability of compilation (if >> anybody cares), and the case is not frequent enough to warrant >> shaving a few bytes off the instruction format. >> > ... but myByte + 0x80 is faster than myByte & 0xFF. For me this is > an unintelligible mystery. > source see here (line 141..144): > http://hg.openjdk.java.net/jdk7/tl/jdk/file/b89ba9a6d9a6/make/ > tools/src/build/tools/charsetmapping/GenerateSBCS.java > > How can adding be faster than unsigned load of a byte? Probably because (1) the bias of 128 can be folded into the address mode of the instruction which implements cc[byte + 128], and (2) the the 0xFF mask would need to be applied immediately when the byte is loaded from memory, in order for the optimizer to fold (AndI 255 (LoadB p)) to (LoadUB p). If the AndI gets separated from the LoadB (perhaps via intervening Phi functions) then the optimizer cannot do the peepholing. But if the AndI/LoadB expression is placed in a getUnsigned intrinsic m method, then the compiler will be able to see both operations within the same small "window". (Regarding (1) you might ask why the +128 does not slow down the range check. That gets into details of range check elimination, but the short answer is that the bias of 128 gets folded into the RCE optimizations also. A little more detail: RCE works by iteration space splitting, into pre/main/post loops usually, and the calculations which govern those are add/subtract/compare/min/max nests, into which the +128 merges nicely without adding much overhead.) Thanks for pointing out the +128 trick. That's a good one! I wish the JIT could do it automagically, but I don't see how, since it probably requires swapping the halves of a table structures, and our optimizer is not nearly that heroic. -- John From Ulf.Zibis at gmx.de Fri Jan 9 18:55:55 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 10 Jan 2009 03:55:55 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> Message-ID: <49680E3B.3000506@gmx.de> Am 10.01.2009 02:05, John Rose schrieb: > > Probably because (1) the bias of 128 can be folded into the address > mode of the instruction which implements cc[byte + 128], and (2) the > the 0xFF mask would need to be applied immediately when the byte is > loaded from memory, in order for the optimizer to fold (AndI 255 > (LoadB p)) to (LoadUB p). If the AndI gets separated from the LoadB > (perhaps via intervening Phi functions) then the optimizer cannot do > the peepholing. But if the AndI/LoadB expression is placed in a > getUnsigned intrinsic m method, then the compiler will be able to see > both operations within the same small "window". > > (Regarding (1) you might ask why the +128 does not slow down the range > check. That gets into details of range check elimination, but the > short answer is that the bias of 128 gets folded into the RCE > optimizations also. A little more detail: RCE works by iteration > space splitting, into pre/main/post loops usually, and the > calculations which govern those are add/subtract/compare/min/max > nests, into which the +128 merges nicely without adding much overhead.) > > Thanks for pointing out the +128 trick. That's a good one! I wish > the JIT could do it automagically, but I don't see how, since it > probably requires swapping the halves of a table structures, and our > optimizer is not nearly that heroic. The code, for which the table swapping is done : byte[] byteBuf; char[] charBuf; int j = offset; for (int i=0; i References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> Message-ID: <49680FF4.1010107@gmx.de> Am 10.01.2009 03:55, Ulf Zibis schrieb: > > The code, for which the table swapping is done : > > byte[] byteBuf; > char[] charBuf; > int j = offset; > for (int i=0; i charBuf[j] = decode(byteBuf[i]); > .... > public char decode(byte inByte) throws > UnmappableCharacterException, MalformedInputException { // maybe > overridden > return b2cMap[inByte + 0x80]; > } > > For ISO-8859-1 the decode is just: public char decode(byte inByte) throws UnmappableCharacterException, MalformedInputException { // maybe overridden return (char)(inByte + 0x80); } I think also here (char)(inByte & 0xFF) should be faster, if JIT would see, that inByte comes out of byte[], because the masking could be saved completely. -Ulf From groundskeeperwiley at yahoo.com Sat Jan 10 08:27:17 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Sat, 10 Jan 2009 08:27:17 -0800 (PST) Subject: SuperWord optimization References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> Message-ID: <214423.48421.qm@web30001.mail.mud.yahoo.com> I am running into the stack not being aligned problem in the register save/restore code. Is there code in here somewhere that maintains the 8byte stack alignment or is it hand coded into the push/pop methods? From francis.andre.kampbell at orange.fr Sat Jan 10 08:49:18 2009 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Sat, 10 Jan 2009 17:49:18 +0100 Subject: A question about bytecodes In-Reply-To: <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> Message-ID: <4968D18E.806@orange.fr> John Rose a ?crit : > On Jan 9, 2009, at 1:27 PM, Tom Rodriguez wrote: > >> One thing I might mention is that there's another approach to adding >> unsigned which is to do in the form of an API that's expected to be >> intrinsified by the JVM. The performance of this would/could be >> exactly the same as a bytecoded version without requiring a change to >> the JVM specification for adoption, which I think is a largely >> insurmountable barrier. >> > > That's the material point. Let's be clear: There is almost *never* a > reason to add a new bytecode, because an intrinsic method will almost > *always* work just as well. There is a good reason to have new bytecodes to support additional data type that the current JVM does not support. While intrinsic method are ok whenthe extra additional operation is needed to be performed on existing JVM data type, adding a new data type like PackedDecimal for example allows to have local temporary variable of this new type on the stack for the evaluation of expression. Using intrinsic method forces to allocate working variable on the head while they are absolutely *temporary* with the scope limited to the expression statement. Moreover, using temporary on the stack never pollute the heap and thus one gain in performance by avoiding unnecessary GC cycles! > > Any change to bytecodes requires lots of VM and tool changes by every > vendor, which means it had better be really important and with no > feasible alternative (such as intrinsic methods). In particular, > adding lots of new bytecodes to express something as simple as > unsigned operations is a waste of limited bytecode coding space > (unless a system of prefixes were invented). Note that compilers tend > to optimize expressions like myByteArray[i] & 0xFF into unsigned > loads, and packaging this into an intrinsic method would add > predicability of compilation (if anybody cares), and the case is not > frequent enough to warrant shaving a few bytes off the instruction format. > > For example, I work on JSR 292, which is adding one bytecode for > invokedynamic; every other operation (and it's a much richer API than > unsigned arithmetic) can be expressed in terms of existing bytecodes. > The invokedynamic operation cannot be emulated in existing bytecodes > without an order of magnitude or more of size and speed degradation, > and it occurs (will occur) frequently in certain common types of user > code (byte-compiled dynamic languages). Even so, it took 10 years to > introduce it. > > Stephen, if you want a project that really does appear to require new > bytecodes, but which nobody has attempted yet, I recommend you look at > this one: > http://blogs.sun.com/jrose/entry/tuples_in_the_vm > > Best wishes, > -- John From John.Rose at Sun.COM Sat Jan 10 10:39:05 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 10 Jan 2009 10:39:05 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <49680E3B.3000506@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> Message-ID: <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> On Jan 9, 2009, at 6:55 PM, Ulf Zibis wrote: > Do you see any chance, that HotSpot optimizer could be enhanced in > that way, because the loop, we are speaking about, is the central > loop in all charset coders of the JVM. It's already in there, to some degree, but hindered somehow by the peepholing problem. See 'instruct loadUB' around line 6406 of: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/ x86/vm/x86_32.ad What that does is, when it is time to "match" (or lower) ideal to machine nodes in the IR graph, if a suitable AndI and LoadB are adjacent, and if the LoadB is unshared, they are coalesced into a loadUB machine node. It would be a detailed debugging exercise to find out why, in the case of your code, that optimization does not appear to kick in. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090110/80082f12/attachment.html From John.Rose at Sun.COM Sat Jan 10 10:55:27 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 10 Jan 2009 10:55:27 -0800 Subject: A question about bytecodes In-Reply-To: <4968D18E.806@orange.fr> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4968D18E.806@orange.fr> Message-ID: <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> On Jan 10, 2009, at 8:49 AM, Francis ANDRE wrote: > There is a good reason to have new bytecodes to support additional > data type that the current JVM does not support. That is the reason I proposed the tuples extension, which uses a few extra bytecodes in order to introduce an unlimited set of new "inline" or "struct" types. But this reasoning does not motivate new bytecodes for unsigned, or for any other single type. Rather, it motivates a (nominal) tuple mechanism, allowing unsigned (and complex and decimal and rational and unicode pair and...) to be represented using a more general tuple mechanism. (A primitive type I have sometimes felt was missing is T_VECTOR, a 128-bit integer. Of course, these will soon become 256 bits. But either of these types could be readily represented as a tuple of T_LONG components.) > Using intrinsic method forces to allocate working variable on the > head while they are absolutely *temporary* with the scope limited > to the expression statement It would be wrong to say that putting things in the heap is always slower than putting them on the stack. The escape analysis optimization (now present in JDK7) scalarizes objects (turns them into tuples) in many common cases, if the optimizer can prove that the object is only referred to locally. In particular, the above statement is not always true, because escape analysis works on such working variables. The only way to tell for certain whether the optimizer has performed escape analysis (or any other desired optimization) is to examine the assembly code. See: http://wikis.sun.com/display/HotSpotInternals/PrintAssembly As I think I said earlier, making a common idiom into an intrinsic increases the chance that the programmer will code the intended operation in a manner that the optimizer will recognize. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090110/a14a7fbd/attachment.html From John.Rose at Sun.COM Sat Jan 10 12:19:53 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 10 Jan 2009 12:19:53 -0800 Subject: SuperWord optimization In-Reply-To: <214423.48421.qm@web30001.mail.mud.yahoo.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> <214423.48421.qm@web30001.mail.mud.yahoo.com> Message-ID: <7CFB2D51-5C71-41CD-AE71-3DA6512864D5@Sun.COM> Did you look at StackAlignmentInBytes? Ideally, that should impose a global invariant on JVM-generated code. Stack alignment is tricky to get right, since there are many places where it can go wrong. -- John On Jan 10, 2009, at 8:27 AM, James Walsh wrote: > I am running into the stack not being aligned problem in the > register save/restore code. Is there code in here somewhere that > maintains the 8byte stack alignment or is it hand coded into the > push/pop methods? > > > From fw at deneb.enyo.de Sat Jan 10 13:00:32 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 10 Jan 2009 22:00:32 +0100 Subject: A question about bytecodes In-Reply-To: <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> (John Rose's message of "Sat, 10 Jan 2009 10:55:27 -0800") References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4968D18E.806@orange.fr> <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> Message-ID: <873afqanbj.fsf@mid.deneb.enyo.de> * John Rose: > The only way to tell for certain whether the optimizer has performed > escape analysis (or any other desired optimization) is to examine the > assembly code. See: > http://wikis.sun.com/display/HotSpotInternals/PrintAssembly Is there a reason why PrintOptoAssembly appears to be deprecated? Doesn't it contain additional type information which might be useful for debugging purposes (or just figuring out what's going on)? From elfarto+hs at elfarto.com Sat Jan 10 13:25:57 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Sat, 10 Jan 2009 21:25:57 +0000 Subject: A question about bytecodes In-Reply-To: <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4968D18E.806@orange.fr> <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> Message-ID: <49691265.9020909@elfarto.com> John Rose wrote: > (A primitive type I have sometimes felt was missing is T_VECTOR, a > 128-bit integer. Of course, these will soon become 256 bits. But > either of these types could be readily represented as a tuple of T_LONG > components.) This was the other idea I had, give Java the ability to use SIMD instructions. After using OpenGL's shader language and throwing around vec4f's, going back to plain old scaler fields is quite tedious. Unfortunetly this change requires a new primitive type AND a whole slew of new bytecodes to take advantage of it (add, sub, mul, div, dot product, cross product, comparisons for vec4f and vec2d) probably blowing the 20 or so remaining opcodes. Plus it means making the JVM allocate these fields on a 16-byte alignment. > > > As I think I said earlier, making a common idiom into an intrinsic > increases the chance that the programmer will code the intended > operation in a manner that the optimizer will recognize. ...because we're stuck with a limited set of bytecodes that can't adequately express what the programmer was intending? It seems silly that we're making do with with this limited bytecode language and losing so much information the programmer could provide for us, allowing the compiler/optimiser todo a much better job, without having to guess that: float a[] = new float[4], b[] = new float[4]; float c = a[0]*b[0] + a[1]*b[1] + a[2]*b[2] + a[3]*b[3]; could be compiled down to: DPPS xmm1, xmm2 on my processor. > -- John Regards Stephen From John.Rose at Sun.COM Sat Jan 10 14:27:58 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 10 Jan 2009 14:27:58 -0800 Subject: A question about bytecodes In-Reply-To: <873afqanbj.fsf@mid.deneb.enyo.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4968D18E.806@orange.fr> <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> <873afqanbj.fsf@mid.deneb.enyo.de> Message-ID: On Jan 10, 2009, at 1:00 PM, Florian Weimer wrote: > * John Rose: > >> The only way to tell for certain whether the optimizer has performed >> escape analysis (or any other desired optimization) is to examine the >> assembly code. See: >> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly > > Is there a reason why PrintOptoAssembly appears to be deprecated? > Doesn't it contain additional type information which might be useful > for debugging purposes (or just figuring out what's going on)? I don't get "appears deprecated". Do you mean that the .hotspot_compiler directive "print" is now called "printOptoAssembly", while "print" uses the PrintAssembly plugin if available? PrintOptoAssembly still works and there are no plans for removing it. It is a useful tool if you want a dump from the late stages of the server compiler. It is not a true disassembler, however. It prints scheduled machine-level graph nodes, not true assembly code. Try PrintAssembly; it prints the real machine code as emitted after the compiler has finished. It includes many interesting annotations, and it would be easy to add more. If there is some type annotation in POA missing from PA, let's add it. Caveat: PrintAssembly requires you to create a separate module, based on Gnu binutils or an equivalent, which Sun people can't build for you, because the OpenJDK has to stay arms-length from any GPL-ed code that Sun do not own the rights to. Some civic-minded non-Sun webmaster could build and host suitable PrintAssembly plugins, but Sun can't. Alternatively, someone could cobble together an implementation of the plugin (for x86) which does not depend on binutils and contribute it to OpenJDK. The plugin interface is beautifully simple, IMHO. But that seems like more trouble than it's worth, given that binutils is freely available. Best, -- John From John.Rose at Sun.COM Sat Jan 10 14:50:04 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 10 Jan 2009 14:50:04 -0800 Subject: A question about bytecodes In-Reply-To: <49691265.9020909@elfarto.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4968D18E.806@orange.fr> <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> <49691265.9020909@elfarto.com> Message-ID: <48DDFB0A-E584-4578-9A8A-943087504849@Sun.COM> On Jan 10, 2009, at 1:25 PM, Stephen Dawkins wrote: > ...because we're stuck with a limited set of bytecodes that can't > adequately express what the programmer was intending? It seems > silly that we're making do with with this limited bytecode language > and losing so much information the programmer could provide for > us, allowing the compiler/optimiser todo a much better job, without > having to guess that: > > float a[] = new float[4], b[] = new float[4]; > float c = a[0]*b[0] + a[1]*b[1] + a[2]*b[2] + a[3]*b[3]; > > could be compiled down to: > > DPPS xmm1, xmm2 Yes, vectors are a hard case. But it is not because the JVM has no way to express all the new operations. Want to add a new operation to the system? That is what methods are for! Vectors are hard because (unlike unsigned) they cannot be represented directly using the existing set of primitive types. They must be boxed into the heap somehow (float[]), which adds extra distraction for both coders and compilers. But, given some way to define multiple value return, your latest example could be expressed as an intrinsic with no special-purpose bytecodes: (float, float, float, float) Math.dpps(float a0, float a1, float a2, float a3, float b0, float b1, float b2, float b3) It is straightforward for a compiler to render such an intrinsic as a a vector operation. I think Linux uses asm statements routinely for such purposes. HotSpot has its own way of doing this; see the type vmIntrinsics::ID, which is the hook for introducing new "instructions". For vectors, the sticking point is not lack of bytecodes, but lack of multiple value return. That's what the tuple proposal is addressing. Given tuple types in Java, it would look much better. struct VectorF4 { // signature {Ljava/math/VectorF4;FFFF} float a0, a1, a2, a3; } // declaration in java.math.VectorMath VectorF4 dpps(VectorF4 a, VectorF4 b); // example Java VectorF4 c = VectorMath.dpps(a, b); // example bytecodes fload 10; fload 11; fload 12; fload 13 fload 20; fload 21; fload 22; fload 23 invokestatic java/math/VectorMath, dpps, ({Ljava/math/VectorF4;FFFF} {Ljava/math/VectorF4;FFFF}){Ljava/math/VectorF4;FFFF} fstore 33; fstore 32; fstore 31; fstore 30 // compiler graph after intrinsic application would be something like VdppsF4(ConvF4(10,11,12,13), ConvF4(20,21,22,23)) -- John From elfarto+hs at elfarto.com Sun Jan 11 03:03:43 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Sun, 11 Jan 2009 11:03:43 +0000 Subject: A question about bytecodes In-Reply-To: <48DDFB0A-E584-4578-9A8A-943087504849@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4968D18E.806@orange.fr> <992342B2-8F08-45A7-8677-F7A4B9AE7335@Sun.COM> <49691265.9020909@elfarto.com> <48DDFB0A-E584-4578-9A8A-943087504849@Sun.COM> Message-ID: <4969D20F.9020507@elfarto.com> John Rose wrote: > On Jan 10, 2009, at 1:25 PM, Stephen Dawkins wrote: > >> ...because we're stuck with a limited set of bytecodes that can't >> adequately express what the programmer was intending? It seems silly >> that we're making do with with this limited bytecode language and >> losing so much information the programmer could provide for us, >> allowing the compiler/optimiser todo a much better job, without having >> to guess that: >> >> float a[] = new float[4], b[] = new float[4]; >> float c = a[0]*b[0] + a[1]*b[1] + a[2]*b[2] + a[3]*b[3]; >> >> could be compiled down to: >> >> DPPS xmm1, xmm2 > > Given tuple types in Java, it would look much better. > > struct VectorF4 { // signature {Ljava/math/VectorF4;FFFF} > float a0, a1, a2, a3; > } > > // declaration in java.math.VectorMath > VectorF4 dpps(VectorF4 a, VectorF4 b); > > // example Java > VectorF4 c = VectorMath.dpps(a, b); > > // example bytecodes > fload 10; fload 11; fload 12; fload 13 > fload 20; fload 21; fload 22; fload 23 > invokestatic java/math/VectorMath, dpps, > ({Ljava/math/VectorF4;FFFF}{Ljava/math/VectorF4;FFFF}){Ljava/math/VectorF4;FFFF} > > fstore 33; fstore 32; fstore 31; fstore 30 > > // compiler graph after intrinsic application would be something like > VdppsF4(ConvF4(10,11,12,13), ConvF4(20,21,22,23)) > > -- John > I'm not sure that would be good enough. One issue with SSE is ensuring that your 128-bit fields are aligned to 16-bytes so you can move all 4 fields in one go. E.g. public class SpaceShip { private Vector4f position; private Vector4f velocity; } How does the VM know to align position and velocity to 16-bytes? It might seem contrived, but unaligned reads (MOVUPS) are not as fast as aligned ones (MOVAPS) and since the whole goal of getting SIMD instructions into Java would be performance we might as well aim for the fastest possible. Also it seems with these tuples, you lose the information about where each field comes from. Your example is having to recreate the vector from 4 individual fields, when it could have just copied it wholesale and been done with it. Regards Stephen From Ulf.Zibis at gmx.de Sun Jan 11 08:19:13 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 11 Jan 2009 17:19:13 +0100 Subject: Question: System.initializeSystemClass() Message-ID: <496A1C01.2070500@gmx.de> Hi, regarding my project https://java-nio-charset-enhanced.dev.java.net/ I am run into a problem: When System.initializeSystemClass() is opening the the standard I/O streams out and err, new PrintStream() creates new StreamEncoder which needs to access Charset.defaultCharset(). At this point I get UnsatisfiedLinkError, because my implementation of FastCharsetProvider class need to load mapping data from file system via getClass().getResourceAsStream(canonicalName+".dat"), and zip library is not loaded at this time: class System { ... static void initializeSystemClass() { ... setIn0(new BufferedInputStream(fdIn)); setOut0(new PrintStream(new BufferedOutputStream(fdOut, 128), true)); setErr0(new PrintStream(new BufferedOutputStream(fdErr, 128), true)); // Load the zip library now in order to keep java.util.zip.ZipFile // from trying to use itself to load this library later. loadLibrary("zip"); ... } ... } MY QUESTION: Is there any risk, to load zip library before opening the standard I/O streams out and err ? class System { ... static void initializeSystemClass() { ... setIn0(new BufferedInputStream(fdIn)); // PrintStream() creates new sun.io.cs.StreamEncoder which // needs to load charset mapping data from rt.jar via // sun.io.cs.FastCharsetProvider#getClass().getResourceAsStream() // So load the zip library now in order to keep java.util.zip.ZipFile // from trying to use itself to load this library later. loadLibrary("zip"); setOut0(new PrintStream(new BufferedOutputStream(fdOut, 128), true)); setErr0(new PrintStream(new BufferedOutputStream(fdErr, 128), true)); ... } ... } The only problem I see is, that if loadLibrary("zip") fails, the exception messages can't be propagated to standard err stream. What you guys do you think? -Ulf From christian.thalinger at gmail.com Sun Jan 11 09:36:49 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Sun, 11 Jan 2009 18:36:49 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <496A1C01.2070500@gmx.de> References: <496A1C01.2070500@gmx.de> Message-ID: <1231695409.18329.11.camel@localhost.localdomain> On Sun, 2009-01-11 at 17:19 +0100, Ulf Zibis wrote: > MY QUESTION: > Is there any risk, to load zip library before opening the standard I/O > streams out and err ? > > The only problem I see is, that if loadLibrary("zip") fails, the > exception messages can't be propagated to standard err stream. > > What you guys do you think? libzip.so is loaded by the VM during startup before System.inializeSystemClass() is called. So the loadLibrary("zip") does not load the library anymore, it already happened. And when the zip library is missing, you get an error message like this: Error occurred during initialization of VM Unable to load ZIP library: /export/home/twisti/projects/openjdk/openjdk-6-src-b14/j2sdk-image/jre/lib/amd64/libzip.so printed by a VM method. And not Java code using err stream. Moving the statement shouldn't matter. It's just there in case (I wonder what case). - Christian From Ulf.Zibis at gmx.de Sun Jan 11 11:09:53 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 11 Jan 2009 20:09:53 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> Message-ID: <496A4401.7040309@gmx.de> Hi John, thanks for your detailed explanation. So I'm asking for any volunteer, who has enough knowledge about hotspot, to check out, why that optimization does not appear to kick in, or respectively can anybody force hotspot to optimize { char c = (char)((byte[])sa[sp] & 0xFF); }, { char c = (char)(inByte & 0xFF); }, { char c = b2cMap[(byte[])sa[sp] & 0xFF]; } and { char c = b2cMap[inByte & 0xFF]; } accordingly ? It should also inline { char c = decode((byte[])sa[sp]); } for (all member variables are final !): public char decode(final byte inByte) { return (char)(inByte & 0xFF); } and public char decode(final byte inByte) { final char c = b2cMap[inByte & 0xFF]; if (c == REPLACE_CHAR) throw UNMAPPABLE_EXCEPTION; return c; } or public char decode(final byte inByte) { if (inByte >= 0) return (char)inByte; final char c = b2cMap[inByte & 0xFF]; if (c == REPLACE_CHAR) throw UNMAPPABLE_EXCEPTION; return c; } For encoders (only most complex example): Execute { byte b = encode((char[])sa[sp]); } for (all member variables are final !): public byte encode(char inChar) throws RuntimeException, UnmappableCharacterException { if (inChar < directEnd) return (byte)inChar; final byte b; if ((inChar -= map1Start) < c2bMap1.length) b = c2bMap1[inChar]; else if ((inChar -= map2Offset) < c2bMap2.length) b = c2bMap2[inChar]; // if calculated index runs out of the map's scope, an accordant RuntimeException is thrown else b = c2bPagedMap[(inChar-=pagedMapOffset) >> shift][inChar & mask]; // TODO: simplify for shift == 0 // If output byte is zero, character is unmappable if (b == 0x00) throw UNMAPPABLE_EXCEPTION; return b; } should be optimized. This would be very nice, because I have to decide weather I choose [inByte + 0x80] or [inByte & 0xFF] in my code for enhancing charset coders. Also I'm wondering, that hotspot doesn't seem to inline the tiny de/encode() method, as I experience performance gain factor 2, if I inline it manually in my source code. See in lines 32 to 123: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteDecoder_new.java?rev=572&view=markup See in lines 67 to 109 to 117: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder_new.java?rev=572&view=markup Am 10.01.2009 19:39, John Rose schrieb: > On Jan 9, 2009, at 6:55 PM, Ulf Zibis wrote: > >> Do you see any chance, that HotSpot optimizer could be enhanced in >> that way, because the loop, we are speaking about, is the central >> loop in all charset coders of the JVM. >> > > It's already in there, to some degree, but hindered somehow by the > peepholing problem. See 'instruct loadUB' around line 6406 of: > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/x86_32.ad > > What that does is, when it is time to "match" (or lower) ideal to > machine nodes in the IR graph, if a suitable AndI and LoadB are > adjacent, and if the LoadB is unshared, they are coalesced into a > loadUB machine node. > > It would be a detailed debugging exercise to find out why, in the case > of your code, that optimization does not appear to kick in. > > -- John From Ulf.Zibis at gmx.de Sun Jan 11 11:26:46 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 11 Jan 2009 20:26:46 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <1231695409.18329.11.camel@localhost.localdomain> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> Message-ID: <496A47F6.7060707@gmx.de> Hi Christian (German?), thanks for your interesting info, and testing the behavior for missing zip library. :-) Regarding preloaded zip library in openJDK-6: Maybe official JDK 6 is little different from openJDK, or in case of Windows So I give this solution a try. -Ulf Am 11.01.2009 18:36, Christian Thalinger schrieb: > On Sun, 2009-01-11 at 17:19 +0100, Ulf Zibis wrote: > >> MY QUESTION: >> Is there any risk, to load zip library before opening the standard I/O >> streams out and err ? >> > > > > >> The only problem I see is, that if loadLibrary("zip") fails, the >> exception messages can't be propagated to standard err stream. >> >> What you guys do you think? >> > > libzip.so is loaded by the VM during startup before > System.inializeSystemClass() is called. So the loadLibrary("zip") does > not load the library anymore, it already happened. > > And when the zip library is missing, you get an error message like this: > > Error occurred during initialization of VM > Unable to load ZIP library: /export/home/twisti/projects/openjdk/openjdk-6-src-b14/j2sdk-image/jre/lib/amd64/libzip.so > > printed by a VM method. And not Java code using err stream. Moving the > statement shouldn't matter. It's just there in case (I wonder what > case). > > - Christian > > > From christian.thalinger at gmail.com Sun Jan 11 13:30:55 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Sun, 11 Jan 2009 22:30:55 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <496A47F6.7060707@gmx.de> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> Message-ID: <1231709455.18329.15.camel@localhost.localdomain> On Sun, 2009-01-11 at 20:26 +0100, Ulf Zibis wrote: > Hi Christian (German?), Almost, Austrian :-) > > thanks for your interesting info, and testing the behavior for missing > zip library. :-) > > Regarding preloaded zip library in openJDK-6: > Maybe official JDK 6 is little different from openJDK, or in case of Windows I don't know the JDK 6 code, but I guess the zip library loading is the same (please correct me if I'm wrong). And I'm very sure it's the same on Windows. > > So I give this solution a try. - Christian From Ulf.Zibis at gmx.de Sun Jan 11 13:38:06 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 11 Jan 2009 22:38:06 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <1231709455.18329.15.camel@localhost.localdomain> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> <1231709455.18329.15.camel@localhost.localdomain> Message-ID: <496A66BE.9030701@gmx.de> Am 11.01.2009 22:30, Christian Thalinger schrieb: > I don't know the JDK 6 code, but I guess the zip library loading is the > same (please correct me if I'm wrong). And I'm very sure it's the same > on Windows. > > > I've compared JDK 6 to latest openJDK 6 sources. You are right, I couldn't find a difference in classes System and ZipFile. So It's a mystery, how zip library can be preloaded on Linux. -Ulf From christian.thalinger at gmail.com Sun Jan 11 13:52:08 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Sun, 11 Jan 2009 22:52:08 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <496A66BE.9030701@gmx.de> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> <1231709455.18329.15.camel@localhost.localdomain> <496A66BE.9030701@gmx.de> Message-ID: <1231710728.18329.17.camel@localhost.localdomain> On Sun, 2009-01-11 at 22:38 +0100, Ulf Zibis wrote: > Am 11.01.2009 22:30, Christian Thalinger schrieb: > > I don't know the JDK 6 code, but I guess the zip library loading is the > > same (please correct me if I'm wrong). And I'm very sure it's the same > > on Windows. > > > > > > > I've compared JDK 6 to latest openJDK 6 sources. > You are right, I couldn't find a difference in classes System and ZipFile. > > So It's a mystery, how zip library can be preloaded on Linux. Eh... well, this happens in HotSpot. Loading libzip.so is done in native code. - Christian From Ulf.Zibis at gmx.de Sun Jan 11 14:12:59 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 11 Jan 2009 23:12:59 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <1231710728.18329.17.camel@localhost.localdomain> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> <1231709455.18329.15.camel@localhost.localdomain> <496A66BE.9030701@gmx.de> <1231710728.18329.17.camel@localhost.localdomain> Message-ID: <496A6EEB.3050406@gmx.de> Am 11.01.2009 22:52, Christian Thalinger schrieb: > On Sun, 2009-01-11 at 22:38 +0100, Ulf Zibis wrote: > >> Am 11.01.2009 22:30, Christian Thalinger schrieb: >> >>> I don't know the JDK 6 code, but I guess the zip library loading is the >>> same (please correct me if I'm wrong). And I'm very sure it's the same >>> on Windows. >>> >>> >>> >>> >> I've compared JDK 6 to latest openJDK 6 sources. >> You are right, I couldn't find a difference in classes System and ZipFile. >> >> So It's a mystery, how zip library can be preloaded on Linux. >> > > Eh... well, this happens in HotSpot. Loading libzip.so is done in > native code. > > - Christian > > I guess, libzip.so is standard component of Linux, but on Windows it (1) has different name (only zip.dll), and (2) is loaded from JAVA_HOME\jre\bin and lazy by java.lang.System.initializeSystemClass(). So it's another mystery, why loadLibrary("zip") in java.lang.System.initializeSystemClass() doesn't thow an exception on Linux, as it is named "libzip.so". -Ulf From martinrb at google.com Sun Jan 11 14:15:27 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 11 Jan 2009 14:15:27 -0800 Subject: Question: System.initializeSystemClass() In-Reply-To: <496A6EEB.3050406@gmx.de> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> <1231709455.18329.15.camel@localhost.localdomain> <496A66BE.9030701@gmx.de> <1231710728.18329.17.camel@localhost.localdomain> <496A6EEB.3050406@gmx.de> Message-ID: <1ccfd1c10901111415t10faa800y8976d8d95c12d39e@mail.gmail.com> On Sun, Jan 11, 2009 at 14:12, Ulf Zibis wrote: > So it's another mystery, why loadLibrary("zip") in > java.lang.System.initializeSystemClass() doesn't thow an exception on > Linux, as it is named "libzip.so". The actual behavior of loadLibrary is system dependent. On Linux, loadLibrary("foo") will look for a disk file named "libfoo.so". This could be better documented. Martin > > -Ulf > > From martinrb at google.com Sun Jan 11 14:20:25 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 11 Jan 2009 14:20:25 -0800 Subject: Question: System.initializeSystemClass() In-Reply-To: <1231710728.18329.17.camel@localhost.localdomain> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> <1231709455.18329.15.camel@localhost.localdomain> <496A66BE.9030701@gmx.de> <1231710728.18329.17.camel@localhost.localdomain> Message-ID: <1ccfd1c10901111420r330fe7c5h3d5c4ee5532dd7c5@mail.gmail.com> On Sun, Jan 11, 2009 at 13:52, Christian Thalinger wrote: > Eh... well, this happens in HotSpot. Loading libzip.so is done in > native code. the boot class loader cannot be written in Java, since then you would have a bootstrap problem. So hotspot includes a native bootstrap class loader, one that does not use libzip.so, but uses the same code, but packaged in a different way, probably linked statically into libjli.so. Later on, after the core java classes are loaded, the same libzip functionality wants to be used by Java code. So libzip is loaded again, but using the Java-level loadLibrary. Martin > > - Christian > > From Coleen.Phillimore at Sun.COM Sun Jan 11 17:27:36 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Sun, 11 Jan 2009 20:27:36 -0500 Subject: [patch] missing include file in hotspot 14.0b08 In-Reply-To: <49667E7B.7010301@ubuntu.com> References: <49667E7B.7010301@ubuntu.com> Message-ID: <1231723656.19677.13.camel@phillimores> What version of gcc were you using? I had a lot more missing undefines and different ones (message about inline function not defined) with gcc version: gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 patchfile attached. Can you try this out? thanks, Coleen On Thu, 2009-01-08 at 23:30 +0100, Matthias Klose wrote: > seen while building without precompiled headers > > Matthias > plain text document attachment (xxxxx.diff) > --- openjdk/hotspot/src/share/vm/includeDB_core.orig 2008-11-21 17:11:18.000000000 -0700 > +++ openjdk/hotspot/src/share/vm/includeDB_core 2009-01-08 14:32:58.000000000 -0700 > @@ -1314,6 +1314,7 @@ > cppInterpreter_.cpp interpreterRuntime.hpp > cppInterpreter_.cpp interpreter.hpp > cppInterpreter_.cpp interpreterGenerator.hpp > +cppInterpreter_.cpp interfaceSupport.hpp > cppInterpreter_.cpp jvmtiExport.hpp > cppInterpreter_.cpp jvmtiThreadState.hpp > cppInterpreter_.cpp methodDataOop.hpp -------------- next part -------------- A non-text attachment was scrubbed... Name: patchfile Type: text/x-patch Size: 6583 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090111/76d655db/attachment.bin From coleen.phillimore at sun.com Sun Jan 11 20:28:37 2009 From: coleen.phillimore at sun.com (coleen.phillimore at sun.com) Date: Mon, 12 Jan 2009 04:28:37 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20090112042849.C6FA0D454@hg.openjdk.java.net> Changeset: dabd8d202164 Author: coleenp Date: 2008-12-23 06:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dabd8d202164 4997835: RFE: crash dump will only be created when running w/ -XX:+ShowMessageBoxOnError Summary: Using UseOSErrorReporting will provide both an hs_err file and a crash dump or debug launch and works better. Reviewed-by: xlu, acorn, poonam ! src/share/vm/utilities/vmError.cpp Changeset: db4caa99ef11 Author: xlu Date: 2008-12-24 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/db4caa99ef11 6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t Summary: Avoid casting between int32_t and intptr_t specifically for MasmAssembler::movptr in 32 bit platforms. Reviewed-by: jrose, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Changeset: 2328d1d3f8cf Author: xlu Date: 2008-12-24 19:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2328d1d3f8cf 6781583: Hotspot build fails on linux 64 bit platform with gcc 4.3.2 Summary: Fixed the wrong cast between types since more restrictions are imposed by gcc 4.3.2 Reviewed-by: jcoomes, acorn, phh, never ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.hpp Changeset: c81d2ef51ca3 Author: acorn Date: 2009-01-05 13:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c81d2ef51ca3 4670071: loadClassInternal is too restrictive. Summary: VM support for deadlock fix. Library fix in 4735126. See API proposal. Reviewed-by: dholmes, blacklion ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: a0401dc51d0b Author: acorn Date: 2009-01-08 16:27 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a0401dc51d0b 6791656: nsk defclass0 asserts handles.hpp Reviewed-by: phh, xlu ! src/share/vm/classfile/systemDictionary.cpp Changeset: fc7ab6287598 Author: coleenp Date: 2009-01-09 14:39 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc7ab6287598 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/oops/constantPoolOop.cpp From Ulf.Zibis at gmx.de Mon Jan 12 01:21:35 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Jan 2009 10:21:35 +0100 Subject: Question: System.initializeSystemClass() In-Reply-To: <1ccfd1c10901111420r330fe7c5h3d5c4ee5532dd7c5@mail.gmail.com> References: <496A1C01.2070500@gmx.de> <1231695409.18329.11.camel@localhost.localdomain> <496A47F6.7060707@gmx.de> <1231709455.18329.15.camel@localhost.localdomain> <496A66BE.9030701@gmx.de> <1231710728.18329.17.camel@localhost.localdomain> <1ccfd1c10901111420r330fe7c5h3d5c4ee5532dd7c5@mail.gmail.com> Message-ID: <496B0B9F.7040306@gmx.de> Martin, thanks for additional explanation. So do you also think, that there is no problem, to load zip library before opening the standard I/O streams out and err, as I explained in my starter question ? Thanks for some short answer. -Ulf Am 11.01.2009 23:20, Martin Buchholz schrieb: > On Sun, Jan 11, 2009 at 13:52, Christian Thalinger > wrote: > > >> Eh... well, this happens in HotSpot. Loading libzip.so is done in >> native code. >> > > the boot class loader cannot be written in Java, > since then you would have a bootstrap problem. > So hotspot includes a native bootstrap class loader, > one that does not use libzip.so, but uses the same > code, but packaged in a different way, > probably linked statically into libjli.so. > > Later on, after the core java classes are loaded, > the same libzip functionality wants to be used by Java code. > So libzip is loaded again, but using the Java-level loadLibrary. > > Martin > >> - Christian >> >> >> > > > From christian.thalinger at gmail.com Mon Jan 12 08:29:40 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Mon, 12 Jan 2009 17:29:40 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> Message-ID: <1231777780.18329.98.camel@localhost.localdomain> On Sat, 2009-01-10 at 10:39 -0800, John Rose wrote: > It's already in there, to some degree, but hindered somehow by the > peepholing problem. See 'instruct loadUB' around line 6406 of: > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/x86_32.ad > > > What that does is, when it is time to "match" (or lower) ideal to > machine nodes in the IR graph, if a suitable AndI and LoadB are > adjacent, and if the LoadB is unshared, they are coalesced into a > loadUB machine node. > > > It would be a detailed debugging exercise to find out why, in the case > of your code, that optimization does not appear to kick in. I tried to take a look at it, but now I'm stuck. The ideal nodes in question are: 129 LoadB === 311 51 127 [[ 141 ]] @byte[int:>=0]:exact+any *, idx=4; #byte !jvms: test::foo @ bci:28 140 ConI === 0 [[ 141 217 268 347 439 441 ]] #int:255 141 AndI === 458 129 140 [[ 164 ]] !orig=[377] !jvms: test::decode @ bci:4 test::foo @ bci:29 So loadUB should match but it does not (and I don't know why, yet). The opto output is: 102 B7: # B6 B8 <- B6 Freq: 2 102 movslq R10, R11 # i2l 105 movq R8, [rsp + #8] # spill 10a movsbl R8, [R8 + #24 + R10] # byte 110 incl R11 # int 113 movzbl R8, R8 # int & 0xFF 117 movw [R9 + #24 + R10 << #1], R8 # char/short 11d cmpl R11, #1 121 jl,s B6 # loop end P=0.500000 C=22950.000000 It seems the increment of the loop variable gets scheduled between LoadB and immI_255 and thus loadUB cannot match. Not sure yet when matching is applied and if I'm right with my assumption above. I'm looking further... -- Christian From Coleen.Phillimore at Sun.COM Mon Jan 12 03:30:37 2009 From: Coleen.Phillimore at Sun.COM (coleenp) Date: Mon, 12 Jan 2009 06:30:37 -0500 Subject: how to build without precompiled headers? In-Reply-To: <4963E5A1.3060605@ubuntu.com> References: <49613144.90706@ubuntu.com> <496242E8.10509@sun.com> <4963E5A1.3060605@ubuntu.com> Message-ID: <496B29DD.7090507@sun.com> I filed a Hotspot bug to change this and also fixed some C++ interpreter compilation errors with gcc 4.3.2 and 4.1.3 both on ubuntu. Please note that the C++ interpreter isn't shipped on Sun's releases so may have bugs in 64 bit mode. It seems to work on 32 bit linux. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791168 Please review this code change: http://webrev.invokedynamic.info/coleenp/6791168 thanks, Coleen Matthias Klose wrote: > Thanks, > > please see > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593 > and > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38725 > > looks like current GCC versions accept invalid code: > > "That's really a duplicate of PR38725: The code contains many lines of the form > > goto *dispatch_table[opcode]; > > where dispatch_table[opcode] is of the type uintptr_t which is a typedef > to unsigned int. Writing > > goto *(void*)dispatch_table[opcode]; > > instead makes the ICE disappear." > > > Coleen Phillimore - Sun Microsystems schrieb: > >> I tried this on my new 8.10 ubuntu system at home and commenting out >> USE_PRECOMPILED_HEADER didn't use the precompiled header. The file >> _precompiled.incl is still produced but it's empty. I believe you have >> to do a make clean before your gcc.make change is used. >> >> The version of gcc that I used was very picky about inlined functions >> not being defined in places where the other platforms were happy, so >> there were multiple warnings with this message. I have a patch file that >> resolves this, if you want it. >> Also, on my 8.10 ubuntu, gcc version 4.1.forgot, I got an error building >> fastdebug (server compiler) which I haven't resolved. >> >> /home/coleenp/hotspot/src/share/vm/libadt/port.hpp:40: error: 'void >> bcopy(const void*, void*, size_t)' redeclared inline without >> 'gnu_inline' attribute >> >> If you're trying to track down a compiler error building hotspot, try >> getting a preprocessed output file to narrow it down. >> cd linux*/ >> make .i >> >> Hope this helps. >> Coleen >> >> On 01/04/09 16:59, Matthias Klose wrote: >> >>> Trying to track down an ICE (internal compiler error), I need to build >>> hotspot >>> without precompiled header files. There is a macro >>> USE_PRECOMPILED_HEADER >>> defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just >>> removing the >>> conditional around this definition still builds using precompiled >>> header files. >>> How can you build without precompiled header files (even if it's a hack)? >>> >>> Matthias >>> >>> > > From aph at redhat.com Mon Jan 12 11:17:06 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Jan 2009 19:17:06 +0000 Subject: Weirdness in TypeFlow Message-ID: <496B9732.6070306@redhat.com> This is the TypeFlow for java.lang.Shutdown::sequence Here's BB 7. Note that local 0 is an Object: ==================================================== #7 rpo#7 [33 - 43) Stored locals: { 0 } State : locals 2, stack 0, monitors 1 local 0 : java/lang/Object local 1 : java/lang/Object Successors : 1 #10 rpo#8 [43 - 46) Exceptions : 1 #8 rpo#12 [46 - 48) -- java/lang/Throwable ==================================================== Now look at the bytecode: 33: iconst_2 34: putstatic 37: getstatic 40: istore_0 41: aload_1 42: monitorexit 43: goto 49 Note Instruction 40, which stores an int in local 0. So, after instruction 40, local 0 contains an int. Here's the exception handler for this block: ==================================================== #8 rpo#12 [46 - 48) Stored locals: { } State : locals 2, stack 1, monitors 1 local 0 : java/lang/Object local 1 : java/lang/Object stack 0 : java/lang/Throwable Successors : 1 #9 rpo#13 [48 - 49) Exceptions : 0 ==================================================== Its incoming local 0 is an Object, not an int. So, what happens if the monitorexit instruction throws a NullPointerException? It seems to me that local 0 at address 46 is both an Object and an int. I suppose this verifies correctly because the handler does not use local 0. Is this TypeFLow legal? Are there cases where the type of a local in the TypeFlow is not correct, but it doesn't matter because no-one reads it? Thanks, Andrew. TypeFlow for sequence 57 bytes ==================================================== #0 rpo#0 [0 - 6) Stored locals: { 0 } State : locals 2, stack 0, monitors 0 local 0 : bottom local 1 : bottom Successors : 1 #1 rpo#1 [6 - 13) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #1 rpo#1 [6 - 13) Stored locals: { } State : locals 2, stack 0, monitors 1 local 0 : java/lang/Object local 1 : bottom Successors : 2 #14 rpo#2 [13 - 15) #4 rpo#4 [16 - 18) Exceptions : 1 #2 rpo#14 [21 - 23) -- java/lang/Throwable ==================================================== -------------------------------------------------------- ==================================================== #14 rpo#2 [13 - 15) Stored locals: { } State : locals 2, stack 0, monitors 1 local 0 : java/lang/Object local 1 : bottom Successors : 1 #15 rpo#3 [15 - 16) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #15 rpo#3 [15 - 16) Stored locals: { } State : locals 2, stack 0, monitors 0 local 0 : java/lang/Object local 1 : bottom Successors : 0 Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #4 rpo#4 [16 - 18) Stored locals: { } State : locals 2, stack 0, monitors 1 local 0 : java/lang/Object local 1 : bottom Successors : 1 #5 rpo#5 [18 - 21) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #5 rpo#5 [18 - 21) Stored locals: { } State : locals 2, stack 0, monitors 0 local 0 : java/lang/Object local 1 : bottom Successors : 1 #6 rpo#6 [24 - 33) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #6 rpo#6 [24 - 33) Stored locals: { 1 } State : locals 2, stack 0, monitors 0 local 0 : java/lang/Object local 1 : bottom Successors : 1 #7 rpo#7 [33 - 43) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #7 rpo#7 [33 - 43) Stored locals: { 0 } State : locals 2, stack 0, monitors 1 local 0 : java/lang/Object local 1 : java/lang/Object Successors : 1 #10 rpo#8 [43 - 46) Exceptions : 1 #8 rpo#12 [46 - 48) -- java/lang/Throwable ==================================================== -------------------------------------------------------- ==================================================== #10 rpo#8 [43 - 46) Stored locals: { } State : locals 2, stack 0, monitors 0 local 0 : int local 1 : java/lang/Object Successors : 1 #11 rpo#9 [49 - 53) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #11 rpo#9 [49 - 53) Stored locals: { } State : locals 2, stack 0, monitors 0 local 0 : int local 1 : java/lang/Object Successors : 2 #13 rpo#10 [53 - 56) #12 rpo#11 [56 - 57) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #13 rpo#10 [53 - 56) Stored locals: { } State : locals 2, stack 0, monitors 0 local 0 : int local 1 : java/lang/Object Successors : 1 #12 rpo#11 [56 - 57) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #12 rpo#11 [56 - 57) Stored locals: { } State : locals 2, stack 0, monitors 0 local 0 : int local 1 : java/lang/Object Successors : 0 Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #8 rpo#12 [46 - 48) Stored locals: { } State : locals 2, stack 1, monitors 1 local 0 : java/lang/Object local 1 : java/lang/Object stack 0 : java/lang/Throwable Successors : 1 #9 rpo#13 [48 - 49) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #9 rpo#13 [48 - 49) Stored locals: { } State : locals 2, stack 1, monitors 0 local 0 : java/lang/Object local 1 : java/lang/Object stack 0 : java/lang/Throwable Successors : 0 Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #2 rpo#14 [21 - 23) Stored locals: { } State : locals 2, stack 1, monitors 1 local 0 : java/lang/Object local 1 : bottom stack 0 : java/lang/Throwable Successors : 1 #3 rpo#15 [23 - 24) Exceptions : 0 ==================================================== -------------------------------------------------------- ==================================================== #3 rpo#15 [23 - 24) Stored locals: { } State : locals 2, stack 1, monitors 0 local 0 : java/lang/Object local 1 : bottom stack 0 : java/lang/Throwable Successors : 0 Exceptions : 0 ==================================================== -------------------------------------------------------- Method name:"sequence" private static Descriptor: ()void Attribute "Code", length:229, max_stack:2, max_locals:2, code_length:57 0: getstatic 3: dup 4: astore_0 5: monitorenter 6: getstatic 9: iconst_1 10: if_icmpeq 16 13: aload_0 14: monitorexit 15: return 16: aload_0 17: monitorexit 18: goto 24 21: aload_0 22: monitorexit 23: athrow 24: invokestatic 27: getstatic 30: dup 31: astore_1 32: monitorenter 33: iconst_2 34: putstatic 37: getstatic 40: istore_0 41: aload_1 42: monitorexit 43: goto 49 46: aload_1 47: monitorexit 48: athrow 49: iload_0 50: ifeq 56 53: invokestatic 56: return Exceptions (count: 5): start: 6, end: 15, handler: 21, type: 0 /* finally */ start: 16, end: 18, handler: 21, type: 0 /* finally */ start: 21, end: 23, handler: 21, type: 0 /* finally */ start: 33, end: 43, handler: 46, type: 0 /* finally */ start: 46, end: 48, handler: 46, type: 0 /* finally */ Attribute "LineNumberTable", length:42, count: 10 line: 144 at pc: 0 line: 148 at pc: 6 line: 144 at pc: 16 line: 150 at pc: 24 line: 152 at pc: 27 line: 153 at pc: 33 line: 154 at pc: 37 line: 152 at pc: 41 line: 156 at pc: 49 line: 157 at pc: 56 Attribute "LocalVariableTable", length:22, count: 2 slot#0: name: rfoe, type: boolean (pc: 41 length: 5) slot#0: name: rfoe, type: boolean (pc: 49 length: 8) Attribute "StackMapTable", length:38 From Ulf.Zibis at gmx.de Mon Jan 12 11:19:13 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Jan 2009 20:19:13 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1231777780.18329.98.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> Message-ID: <496B97B1.5050708@gmx.de> Hi Christian, I must admit, for me this codes are like Chinese letters. But I'm very happy, that you take the time to find out how hotspot could be forced to kick in here. I'm looking further your results, so that { char c = (char)((byte[])sa[sp] & 0xFF) } etc. would be optimised best, and the +128 trick would become superfluous. -Ulf Am 12.01.2009 17:29, Christian Thalinger schrieb: > On Sat, 2009-01-10 at 10:39 -0800, John Rose wrote: > > >> It's already in there, to some degree, but hindered somehow by the >> peepholing problem. See 'instruct loadUB' around line 6406 of: >> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/x86_32.ad >> >> >> What that does is, when it is time to "match" (or lower) ideal to >> machine nodes in the IR graph, if a suitable AndI and LoadB are >> adjacent, and if the LoadB is unshared, they are coalesced into a >> loadUB machine node. >> >> >> It would be a detailed debugging exercise to find out why, in the case >> of your code, that optimization does not appear to kick in. >> > > I tried to take a look at it, but now I'm stuck. > > The ideal nodes in question are: > > 129 LoadB === 311 51 127 [[ 141 ]] @byte[int:>=0]:exact+any *, idx=4; #byte !jvms: test::foo @ bci:28 > 140 ConI === 0 [[ 141 217 268 347 439 441 ]] #int:255 > 141 AndI === 458 129 140 [[ 164 ]] !orig=[377] !jvms: test::decode @ bci:4 test::foo @ bci:29 > > So loadUB should match but it does not (and I don't know why, yet). The > opto output is: > > 102 B7: # B6 B8 <- B6 Freq: 2 > 102 movslq R10, R11 # i2l > 105 movq R8, [rsp + #8] # spill > 10a movsbl R8, [R8 + #24 + R10] # byte > 110 incl R11 # int > 113 movzbl R8, R8 # int & 0xFF > 117 movw [R9 + #24 + R10 << #1], R8 # char/short > 11d cmpl R11, #1 > 121 jl,s B6 # loop end P=0.500000 C=22950.000000 > > It seems the increment of the loop variable gets scheduled between LoadB > and immI_255 and thus loadUB cannot match. > > Not sure yet when matching is applied and if I'm right with my > assumption above. I'm looking further... > > -- Christian > > > From Thomas.Rodriguez at Sun.COM Mon Jan 12 13:32:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 Jan 2009 13:32:57 -0800 Subject: Weirdness in TypeFlow In-Reply-To: <496B9732.6070306@redhat.com> References: <496B9732.6070306@redhat.com> Message-ID: <3CD8D531-0E42-4190-8E4C-9EC4F87B38BD@sun.com> I believe this is because none of the bytecodes after the getstatic itself can actually throw an exception in compiled code, so there's no edge to the exception handler. The monitorexit can't throw an NPE because we verified that the monitor operations are block structured before we compiled so it must be non-null and we must have entered it at least once. Check out the can_trap logic in ciTypeFlow. This controls whether a bytecode has an exceptional edge or not during the dataflow. tom On Jan 12, 2009, at 11:17 AM, Andrew Haley wrote: > This is the TypeFlow for java.lang.Shutdown::sequence > > Here's BB 7. Note that local 0 is an Object: > > ==================================================== > #7 rpo#7 [33 - 43) Stored locals: { 0 } > > State : locals 2, stack 0, monitors 1 > local 0 : java/lang/Object > local 1 : java/lang/Object > Successors : 1 > #10 rpo#8 [43 - 46) > Exceptions : 1 > #8 rpo#12 [46 - 48) -- java/lang/Throwable > ==================================================== > > Now look at the bytecode: > > 33: iconst_2 > 34: putstatic > 37: getstatic > 40: istore_0 > 41: aload_1 > 42: monitorexit > 43: goto 49 > > Note Instruction 40, which stores an int in local 0. So, after > instruction > 40, local 0 contains an int. > > Here's the exception handler for this block: > > ==================================================== > #8 rpo#12 [46 - 48) Stored locals: { } > > State : locals 2, stack 1, monitors 1 > local 0 : java/lang/Object > local 1 : java/lang/Object > stack 0 : java/lang/Throwable > Successors : 1 > #9 rpo#13 [48 - 49) > Exceptions : 0 > ==================================================== > > Its incoming local 0 is an Object, not an int. So, what happens if > the monitorexit instruction throws a NullPointerException? It seems > to me that local 0 at address 46 is both an Object and an int. > > I suppose this verifies correctly because the handler does not > use local 0. Is this TypeFLow legal? Are there cases where the type > of a local in the TypeFlow is not correct, but it doesn't matter > because > no-one reads it? > > Thanks, > Andrew. > > > TypeFlow for sequence 57 bytes > ==================================================== > #0 rpo#0 [0 - 6) Stored locals: { 0 } > > State : locals 2, stack 0, monitors 0 > local 0 : bottom > local 1 : bottom > Successors : 1 > #1 rpo#1 [6 - 13) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #1 rpo#1 [6 - 13) Stored locals: { } > > State : locals 2, stack 0, monitors 1 > local 0 : java/lang/Object > local 1 : bottom > Successors : 2 > #14 rpo#2 [13 - 15) > #4 rpo#4 [16 - 18) > Exceptions : 1 > #2 rpo#14 [21 - 23) -- java/lang/Throwable > ==================================================== > -------------------------------------------------------- > > ==================================================== > #14 rpo#2 [13 - 15) Stored locals: { } > > State : locals 2, stack 0, monitors 1 > local 0 : java/lang/Object > local 1 : bottom > Successors : 1 > #15 rpo#3 [15 - 16) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #15 rpo#3 [15 - 16) Stored locals: { } > > State : locals 2, stack 0, monitors 0 > local 0 : java/lang/Object > local 1 : bottom > Successors : 0 > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #4 rpo#4 [16 - 18) Stored locals: { } > > State : locals 2, stack 0, monitors 1 > local 0 : java/lang/Object > local 1 : bottom > Successors : 1 > #5 rpo#5 [18 - 21) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #5 rpo#5 [18 - 21) Stored locals: { } > > State : locals 2, stack 0, monitors 0 > local 0 : java/lang/Object > local 1 : bottom > Successors : 1 > #6 rpo#6 [24 - 33) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #6 rpo#6 [24 - 33) Stored locals: { 1 } > > State : locals 2, stack 0, monitors 0 > local 0 : java/lang/Object > local 1 : bottom > Successors : 1 > #7 rpo#7 [33 - 43) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #7 rpo#7 [33 - 43) Stored locals: { 0 } > > State : locals 2, stack 0, monitors 1 > local 0 : java/lang/Object > local 1 : java/lang/Object > Successors : 1 > #10 rpo#8 [43 - 46) > Exceptions : 1 > #8 rpo#12 [46 - 48) -- java/lang/Throwable > ==================================================== > -------------------------------------------------------- > > ==================================================== > #10 rpo#8 [43 - 46) Stored locals: { } > > State : locals 2, stack 0, monitors 0 > local 0 : int > local 1 : java/lang/Object > Successors : 1 > #11 rpo#9 [49 - 53) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #11 rpo#9 [49 - 53) Stored locals: { } > > State : locals 2, stack 0, monitors 0 > local 0 : int > local 1 : java/lang/Object > Successors : 2 > #13 rpo#10 [53 - 56) > #12 rpo#11 [56 - 57) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #13 rpo#10 [53 - 56) Stored locals: { } > > State : locals 2, stack 0, monitors 0 > local 0 : int > local 1 : java/lang/Object > Successors : 1 > #12 rpo#11 [56 - 57) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #12 rpo#11 [56 - 57) Stored locals: { } > > State : locals 2, stack 0, monitors 0 > local 0 : int > local 1 : java/lang/Object > Successors : 0 > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #8 rpo#12 [46 - 48) Stored locals: { } > > State : locals 2, stack 1, monitors 1 > local 0 : java/lang/Object > local 1 : java/lang/Object > stack 0 : java/lang/Throwable > Successors : 1 > #9 rpo#13 [48 - 49) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #9 rpo#13 [48 - 49) Stored locals: { } > > State : locals 2, stack 1, monitors 0 > local 0 : java/lang/Object > local 1 : java/lang/Object > stack 0 : java/lang/Throwable > Successors : 0 > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #2 rpo#14 [21 - 23) Stored locals: { } > > State : locals 2, stack 1, monitors 1 > local 0 : java/lang/Object > local 1 : bottom > stack 0 : java/lang/Throwable > Successors : 1 > #3 rpo#15 [23 - 24) > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > ==================================================== > #3 rpo#15 [23 - 24) Stored locals: { } > > State : locals 2, stack 1, monitors 0 > local 0 : java/lang/Object > local 1 : bottom > stack 0 : java/lang/Throwable > Successors : 0 > Exceptions : 0 > ==================================================== > -------------------------------------------------------- > > Method name:"sequence" private static Descriptor: ()void > Attribute "Code", length:229, max_stack:2, max_locals:2, code_length: > 57 > 0: getstatic > 3: dup > 4: astore_0 > 5: monitorenter > 6: getstatic > 9: iconst_1 > 10: if_icmpeq 16 > 13: aload_0 > 14: monitorexit > 15: return > 16: aload_0 > 17: monitorexit > 18: goto 24 > 21: aload_0 > 22: monitorexit > 23: athrow > 24: invokestatic > 27: getstatic > 30: dup > 31: astore_1 > 32: monitorenter > 33: iconst_2 > 34: putstatic > 37: getstatic > 40: istore_0 > 41: aload_1 > 42: monitorexit > 43: goto 49 > 46: aload_1 > 47: monitorexit > 48: athrow > 49: iload_0 > 50: ifeq 56 > 53: invokestatic > 56: return > Exceptions (count: 5): > start: 6, end: 15, handler: 21, type: 0 /* finally */ > start: 16, end: 18, handler: 21, type: 0 /* finally */ > start: 21, end: 23, handler: 21, type: 0 /* finally */ > start: 33, end: 43, handler: 46, type: 0 /* finally */ > start: 46, end: 48, handler: 46, type: 0 /* finally */ > Attribute "LineNumberTable", length:42, count: 10 > line: 144 at pc: 0 > line: 148 at pc: 6 > line: 144 at pc: 16 > line: 150 at pc: 24 > line: 152 at pc: 27 > line: 153 at pc: 33 > line: 154 at pc: 37 > line: 152 at pc: 41 > line: 156 at pc: 49 > line: 157 at pc: 56 > Attribute "LocalVariableTable", length:22, count: 2 > slot#0: name: rfoe, type: boolean (pc: 41 length: 5) > slot#0: name: rfoe, type: boolean (pc: 49 length: 8) > Attribute "StackMapTable", length:38 > From Thomas.Rodriguez at Sun.COM Mon Jan 12 13:52:27 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 Jan 2009 13:52:27 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1231777780.18329.98.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> Message-ID: <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> > I tried to take a look at it, but now I'm stuck. I suspect this is a problem I remember seeing long ago in the logic for breaking match trees with multiple memory edges. When converting the ideal form into the mach form, the matcher has to take the ideal form, which is a DAG, and cut it up into trees. The matcher can only operate on binary trees. Within these binary trees it's possible for multiple ideal nodes to be swallowed into a single mach node. One danger with this is when matching multiple nodes that have memory inputs it might be possible to violate anti-dependence. There's a some cutouts in Matcher::Label_Root that force a break in the match when there are multiple memory inputs in the match tree: // Check for leaves of the State Tree; things that cannot be a part of // the current tree. If it finds any, that value is matched as a // register operand. If not, then the normal matching is used. if( match_into_reg(n, m, control, i, is_shared(m)) || // // Stop recursion if this is LoadNode and the root of this tree is a // StoreNode and the load & store have different memories. ((mem!=(Node*)1) && m->is_Load() && m->in(MemNode::Memory) != mem) || // Can NOT include the match of a subtree when its memory state // is used by any of the other subtrees (input_mem == NodeSentinel) ) { The ideal for the simple example is something like (StoreC mem2 addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above will break the match at the load, forcing the value into a register. It's seem like an excessively strong cutout but I'm not sure how to phrase it better, particularly since I don't know what exactly what problem it designed to eliminate. I believe it's probably the anti-dep issue but without a concrete failure it's hard to know what exactly it should look like. tom > > > The ideal nodes in question are: > > 129 LoadB === 311 51 127 [[ 141 ]] @byte[int:>=0]:exact+any *, > idx=4; #byte !jvms: test::foo @ bci:28 > 140 ConI === 0 [[ 141 217 268 347 439 441 ]] #int:255 > 141 AndI === 458 129 140 [[ 164 ]] !orig=[377] !jvms: > test::decode @ bci:4 test::foo @ bci:29 > > So loadUB should match but it does not (and I don't know why, yet). > The > opto output is: > > 102 B7: # B6 B8 <- B6 Freq: 2 > 102 movslq R10, R11 # i2l > 105 movq R8, [rsp + #8] # spill > 10a movsbl R8, [R8 + #24 + R10] # byte > 110 incl R11 # int > 113 movzbl R8, R8 # int & 0xFF > 117 movw [R9 + #24 + R10 << #1], R8 # char/short > 11d cmpl R11, #1 > 121 jl,s B6 # loop end P=0.500000 C=22950.000000 > > It seems the increment of the loop variable gets scheduled between > LoadB > and immI_255 and thus loadUB cannot match. > > Not sure yet when matching is applied and if I'm right with my > assumption above. I'm looking further... > > -- Christian > From Thomas.Rodriguez at Sun.COM Mon Jan 12 13:57:55 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 Jan 2009 13:57:55 -0800 Subject: SuperWord optimization In-Reply-To: <214423.48421.qm@web30001.mail.mud.yahoo.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> <214423.48421.qm@web30001.mail.mud.yahoo.com> Message-ID: <0D868937-B4A4-470A-9855-19507CC4FB88@Sun.COM> Could you be more specific? tom On Jan 10, 2009, at 8:27 AM, James Walsh wrote: > I am running into the stack not being aligned problem in the > register save/restore code. Is there code in here somewhere that > maintains the 8byte stack alignment or is it hand coded into the > push/pop methods? > > > From Xiaobin.Lu at Sun.COM Mon Jan 12 15:44:46 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 12 Jan 2009 15:44:46 -0800 Subject: review request for 6791815 Message-ID: <496BD5EE.6080309@Sun.COM> 6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms when initializing direct buffer support Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6791815/webrev/ Details: When mutiple threads call NewDirectByteBuffer using JNI, deadlock could occur when thread A triggers the safepoint and thread B is busy waiting for thread A to get finished. However, the current implementation transfers thread B's state to be in VM state due to the fact that os::yield_all call could result into a os::sleep call on Solaris. The side effect of put thread B's state to be in VM state is that the VMThread will wait for thread B to finish before putting all Java threads to sleep. However, thread B is waiting for thread A to finish and thread A is waiting for the VMThread to return. Hence, a deadlock occurs. The fix suggested by Tom is to put the ThreadInVMfromNative statement inside the loop so that there is a Window that thread B could change back its state to native and as a result, the VMThread could proceed to bring all the threads to safepoint. This is based on the fact that VMThread doesn't stop threads in native, the state check only occurs during the state transition. I've tried hard to come up a local test to reproduce the problem, but without much luck. I have contacted the reporter so that I can give him the VM to verify that the problem has been fixed. I am pretty sure it has, but just to be safe. Thanks, -Xiaobin From David.Holmes at Sun.COM Mon Jan 12 17:19:15 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 13 Jan 2009 11:19:15 +1000 Subject: review request for 6791815 In-Reply-To: <496BD5EE.6080309@Sun.COM> References: <496BD5EE.6080309@Sun.COM> Message-ID: <496BEC13.4070500@sun.com> Looks good to me. Thanks, David Xiaobin Lu said the following on 01/13/09 09:44: > 6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms > when initializing direct buffer support > > Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6791815/webrev/ > > Details: > > When mutiple threads call NewDirectByteBuffer using JNI, deadlock could > occur when thread A triggers the safepoint and thread B is busy waiting > for thread A to get finished. However, the current implementation > transfers thread B's state to be in VM state due to the fact that > os::yield_all call could result into a os::sleep call on Solaris. The > side effect of put thread B's state to be in VM state is that the > VMThread will wait for thread B to finish before putting all Java > threads to sleep. However, thread B is waiting for thread A to finish > and thread A is waiting for the VMThread to return. Hence, a deadlock > occurs. > > The fix suggested by Tom is to put the ThreadInVMfromNative statement > inside the loop so that there is a Window that thread B could change > back its state to native and as a result, the VMThread could proceed to > bring all the threads to safepoint. This is based on the fact that > VMThread doesn't stop threads in native, the state check only occurs > during the state transition. > > I've tried hard to come up a local test to reproduce the problem, but > without much luck. I have contacted the reporter so that I can give him > the VM to verify that the problem has been fixed. I am pretty sure it > has, but just to be safe. > > Thanks, > -Xiaobin > From John.Rose at Sun.COM Mon Jan 12 17:39:58 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 12 Jan 2009 17:39:58 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> Message-ID: On Jan 12, 2009, at 1:52 PM, Tom Rodriguez wrote: > The ideal for the simple example is something like (StoreC mem2 > addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above will > break the match at the load, forcing the value into a register. > It's seem like an excessively strong cutout but I'm not sure how to > phrase it better, particularly since I don't know what exactly what > problem it designed to eliminate. I believe it's probably the anti- > dep issue but without a concrete failure it's hard to know what > exactly it should look like. That sounds plausible. In general, if a node has a unique user, it can be pulled into one of the little spanning trees that the matcher places over the ideal DAG. The graph dump Christian sent shows that the LoadB has just one user ([[141]]) which means the matcher should be able to group the LoadB with the AndI (and transform to loadUB), unless there's something else going on, like the anti-deps you mention. -- John From Ulf.Zibis at gmx.de Mon Jan 12 18:08:44 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 13 Jan 2009 03:08:44 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> Message-ID: <496BF7AC.2060500@gmx.de> Wow, these are good news. :-) So is there a chance, to implement this behaviour in trunk, so we could get rid of the +128 trick ? Is it also available for -client VM ? -Ulf Am 13.01.2009 02:39, John Rose schrieb: > On Jan 12, 2009, at 1:52 PM, Tom Rodriguez wrote: > >> The ideal for the simple example is something like (StoreC mem2 addr2 >> (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above will break >> the match at the load, forcing the value into a register. It's seem >> like an excessively strong cutout but I'm not sure how to phrase it >> better, particularly since I don't know what exactly what problem it >> designed to eliminate. I believe it's probably the anti-dep issue >> but without a concrete failure it's hard to know what exactly it >> should look like. > > That sounds plausible. In general, if a node has a unique user, it > can be pulled into one of the little spanning trees that the matcher > places over the ideal DAG. The graph dump Christian sent shows that > the LoadB has just one user ([[141]]) which means the matcher should > be able to group the LoadB with the AndI (and transform to loadUB), > unless there's something else going on, like the anti-deps you mention. > > -- John > > From aph at redhat.com Tue Jan 13 01:17:23 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Jan 2009 09:17:23 +0000 Subject: Weirdness in TypeFlow In-Reply-To: <3CD8D531-0E42-4190-8E4C-9EC4F87B38BD@sun.com> References: <496B9732.6070306@redhat.com> <3CD8D531-0E42-4190-8E4C-9EC4F87B38BD@sun.com> Message-ID: <496C5C23.5060502@redhat.com> Tom Rodriguez wrote: > I believe this is because none of the bytecodes after the getstatic > itself can actually throw an exception in compiled code, so there's no > edge to the exception handler. The monitorexit can't throw an NPE > because we verified that the monitor operations are block structured > before we compiled Ahh, that's the part I didn't get. > so it must be non-null and we must have entered it at > least once. Check out the can_trap logic in ciTypeFlow. This controls > whether a bytecode has an exceptional edge or not during the dataflow. OK, so I simply call ciTypeFlow::can_trap. Thanks! Andrew. From doko at ubuntu.com Tue Jan 13 03:19:59 2009 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 13 Jan 2009 12:19:59 +0100 Subject: [patch] missing include file in hotspot 14.0b08 In-Reply-To: <1231723656.19677.13.camel@phillimores> References: <49667E7B.7010301@ubuntu.com> <1231723656.19677.13.camel@phillimores> Message-ID: <496C78DF.20108@ubuntu.com> Coleen Phillimore schrieb: > What version of gcc were you using? I had a lot more missing undefines > and different ones (message about inline function not defined) with gcc > version: > gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 I only built the zero port, not using the hotspot runtime. the compiler used was current trunk (GCC-4.4), as found in the gcc-snapshot package on Ubuntu jaunty. > patchfile attached. Can you try this out? yes, sucessfully built on ix86 without precompiled headers. Note that the patch in your email doesn't contain my fix. Matthias From doko at ubuntu.com Tue Jan 13 03:23:21 2009 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 13 Jan 2009 12:23:21 +0100 Subject: how to build without precompiled headers? In-Reply-To: <496B29DD.7090507@sun.com> References: <49613144.90706@ubuntu.com> <496242E8.10509@sun.com> <4963E5A1.3060605@ubuntu.com> <496B29DD.7090507@sun.com> Message-ID: <496C79A9.3020307@ubuntu.com> coleenp schrieb: > > I filed a Hotspot bug to change this and also fixed some C++ interpreter > compilation errors with gcc 4.3.2 and 4.1.3 both on ubuntu. Please note > that the C++ interpreter isn't shipped on Sun's releases so may have > bugs in 64 bit mode. It seems to work on 32 bit linux. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791168 > > Please review this code change: > > http://webrev.invokedynamic.info/coleenp/6791168 Tested with a IcedTea build, showing no regressions in the jtreg testsuite. Checking this into IcedTea. Matthias From christian.thalinger at gmail.com Tue Jan 13 04:36:19 2009 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Tue, 13 Jan 2009 13:36:19 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> Message-ID: <1231850179.23038.6.camel@localhost.localdomain> On Mon, 2009-01-12 at 13:52 -0800, Tom Rodriguez wrote: > The ideal for the simple example is something like (StoreC mem2 addr2 > (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above will break the > match at the load, forcing the value into a register. It's seem like > an excessively strong cutout but I'm not sure how to phrase it better, > particularly since I don't know what exactly what problem it designed > to eliminate. I believe it's probably the anti-dep issue but without > a concrete failure it's hard to know what exactly it should look like. Is it possible to track down the change in your TeamWare repositories? Maybe there is some comment or bug# in the commit message. -- Christian From Ulf.Zibis at gmx.de Tue Jan 13 04:49:11 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 13 Jan 2009 13:49:11 +0100 Subject: Performance of "instanceof" Message-ID: <496C8DC7.7000900@gmx.de> Hi, I'm just interested, how "instanceof" works behind the scenes. Does it simply string-compare the names of the classes, and in fail, do the same with the super class in loop, or is there some sophisticated algorithm. I'm asking, because I want to know, which is faster: - obj instanceof mypackage.MyClass - obj.getClass() == mypackage.MyClass.class - obj.name().equals(objOfMyClass.name()) (assuming, each MyClass has it's own name, as it is the fact for Charset subclasses.) - Ulf From John.Rose at Sun.COM Tue Jan 13 01:44:17 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 13 Jan 2009 01:44:17 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <496BF7AC.2060500@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <496BF7AC.2060500@gmx.de> Message-ID: On Jan 12, 2009, at 6:08 PM, Ulf Zibis wrote: > Wow, these are good news. :-) Not good unless/until we can relax the tricky anti-deps without breaking other code. It's one of the more fearsome parts of the compiler; you have to really work into that code before trying to change it. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090113/65089ac7/attachment.html From Xiaobin.Lu at Sun.COM Tue Jan 13 12:02:09 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 13 Jan 2009 12:02:09 -0800 Subject: review request for 6792301 Message-ID: <496CF341.8080902@Sun.COM> 6792301: StackAlignmentInBytes not honored for compiled native methods Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6792301/webrev/ Details: Crashes have been observed using SoyLatte and the BSD port of OpenJDK on Mac OS X with applications involving many native calls, specifically graphical programs. Various parties have identified the reason as misalignment of the stack; Mac OS X requires 16-byte alignment of stack frames even on 32-bit platforms. While StackAlignmentInBytes is defined as 16 in 32-bit x86 HotSpot, the compiled native wrappers for frequently invoked JNI methods are not appropriately rounding up the frame size. It appears that this is the only place in the VM where the stack alignment is not being obeyed. The fix is quite straightforward as indicated in generate_native_wrapper method. Verified by: The crashes previously seen on Mac OS using Soylatte are gone. runThese full server Thanks, -Xiaobin From Thomas.Rodriguez at Sun.COM Tue Jan 13 13:57:46 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 13 Jan 2009 13:57:46 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <496BF7AC.2060500@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <496BF7AC.2060500@gmx.de> Message-ID: <46E50E1E-883A-4BA1-BBBE-E35391D5A8F3@Sun.COM> The client VM doesn't have any optimizations around folding unsigned idioms into unsigned loads. They wouldn't be that hard for someone to add. tom On Jan 12, 2009, at 6:08 PM, Ulf Zibis wrote: > Wow, these are good news. :-) > > So is there a chance, to implement this behaviour in trunk, so we > could get rid of the +128 trick ? > Is it also available for -client VM ? > > -Ulf > > > Am 13.01.2009 02:39, John Rose schrieb: >> On Jan 12, 2009, at 1:52 PM, Tom Rodriguez wrote: >> >>> The ideal for the simple example is something like (StoreC mem2 >>> addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above will >>> break the match at the load, forcing the value into a register. >>> It's seem like an excessively strong cutout but I'm not sure how >>> to phrase it better, particularly since I don't know what exactly >>> what problem it designed to eliminate. I believe it's probably >>> the anti-dep issue but without a concrete failure it's hard to >>> know what exactly it should look like. >> >> That sounds plausible. In general, if a node has a unique user, it >> can be pulled into one of the little spanning trees that the >> matcher places over the ideal DAG. The graph dump Christian sent >> shows that the LoadB has just one user ([[141]]) which means the >> matcher should be able to group the LoadB with the AndI (and >> transform to loadUB), unless there's something else going on, like >> the anti-deps you mention. >> >> -- John >> >> > From groundskeeperwiley at yahoo.com Tue Jan 13 14:26:02 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Tue, 13 Jan 2009 14:26:02 -0800 (PST) Subject: SuperWord optimization References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> <214423.48421.qm@web30001.mail.mud.yahoo.com> <0D868937-B4A4-470A-9855-19507CC4FB88@Sun.COM> Message-ID: <861151.69717.qm@web30006.mail.mud.yahoo.com> I think the alignment issue was of my own making. I'm still not making it all the way through the Queens test but I think I'm getting closer. ----- Original Message ---- From: Tom Rodriguez To: James Walsh Cc: John Rose ; hotspot-dev at openjdk.java.net Sent: Tuesday, January 13, 2009 3:57:55 PM Subject: Re: SuperWord optimization Could you be more specific? tom From Xiaobin.Lu at Sun.COM Tue Jan 13 16:17:05 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 13 Jan 2009 16:17:05 -0800 Subject: A question on the stack alignment on 64 bit arch Message-ID: <496D2F01.6050705@Sun.COM> Hi folks, While I am fixing the stack alignment bug (6792301), I noticed that on 64 bit implementation of generate_native_wrapper, currently we actually align the stack frame with 32 bytes (line 1289 & 1290 in sharedRuntime_x86_64.cpp). If we want to consider StackAlignmentInBytes, we probably want to align the frame with 16 bytes. Will this have any bad effects? I have run a few tests with 16 bytes aligned stack frame and it seemed running fine. Thanks, -Xiaobin From Thomas.Rodriguez at Sun.COM Tue Jan 13 16:28:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 13 Jan 2009 16:28:06 -0800 Subject: A question on the stack alignment on 64 bit arch In-Reply-To: <496D2F01.6050705@Sun.COM> References: <496D2F01.6050705@Sun.COM> Message-ID: <69AC92EE-AF20-477D-BA9E-042A04F2186C@sun.com> I think the intent of the code was probably to align to 16 but it didn't properly account for the wordSize. Having it align to StackAlignmentInBytes seems to be the right thing to me. tom On Jan 13, 2009, at 4:17 PM, Xiaobin Lu wrote: > Hi folks, > > While I am fixing the stack alignment bug (6792301), I noticed that > on 64 bit implementation of generate_native_wrapper, currently we > actually align the stack frame with 32 bytes (line 1289 & 1290 in > sharedRuntime_x86_64.cpp). If we want to consider > StackAlignmentInBytes, we probably want to align the frame with 16 > bytes. Will this have any bad effects? I have run a few tests with > 16 bytes aligned stack frame and it seemed running fine. > > Thanks, > -Xiaobin From elfarto+hs at elfarto.com Wed Jan 14 01:55:24 2009 From: elfarto+hs at elfarto.com (Stephen Dawkins) Date: Wed, 14 Jan 2009 01:55:24 -0800 (PST) Subject: BasicType enum Message-ID: <588ac807602fb6a748b57eef9358b48d.squirrel@webmail.elfarto.com> Hi A quick question about the BasicType enum in globalDefinitions.hpp. enum BasicType { T_BOOLEAN = 4, T_CHAR = 5, T_FLOAT = 6, T_DOUBLE = 7, T_BYTE = 8, T_SHORT = 9, T_INT = 10, T_LONG = 11, T_OBJECT = 12, T_ARRAY = 13, T_VOID = 14, T_ADDRESS = 15, T_NARROWOOP= 16, T_CONFLICT = 17, T_ILLEGAL = 99 }; Why are 0, 1, 2 and 3 missing? Regards Stephen From Coleen.Phillimore at Sun.COM Wed Jan 14 11:28:21 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Wed, 14 Jan 2009 14:28:21 -0500 Subject: [patch] missing include file in hotspot 14.0b08 In-Reply-To: <200901141426.40429.kurt@intricatesoftware.com> References: <49667E7B.7010301@ubuntu.com> <1231723656.19677.13.camel@phillimores> <200901141426.40429.kurt@intricatesoftware.com> Message-ID: <496E3CD5.6030001@sun.com> Okay, I'll add in the missing define that Matthias had and push it up. Coleen On 01/14/09 14:26, Kurt Miller wrote: > Hi Coleen, > > On Sunday 11 January 2009 8:27:36 pm Coleen Phillimore wrote: > >> What version of gcc were you using? I had a lot more missing undefines >> and different ones (message about inline function not defined) with gcc >> version: >> gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 >> patchfile attached. Can you try this out? >> > > Your patch works well with gcc 3.3.5 on OpenBSD (gcc 3.3 doesn't > support precompiled headers). It would be great if your diff made > it into the tree. > > Regards, > -Kurt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090114/036cb7cc/attachment.html From Thomas.Rodriguez at Sun.COM Wed Jan 14 12:04:10 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Jan 2009 12:04:10 -0800 Subject: BasicType enum In-Reply-To: <588ac807602fb6a748b57eef9358b48d.squirrel@webmail.elfarto.com> References: <588ac807602fb6a748b57eef9358b48d.squirrel@webmail.elfarto.com> Message-ID: <9E8C680A-7FE5-4DA5-9794-845C7CF19578@sun.com> I believe it's purely historical. I suspect Oak had a few more types down there. tom On Jan 14, 2009, at 1:55 AM, Stephen Dawkins wrote: > Hi > > A quick question about the BasicType enum in globalDefinitions.hpp. > > enum BasicType { > T_BOOLEAN = 4, > T_CHAR = 5, > T_FLOAT = 6, > T_DOUBLE = 7, > T_BYTE = 8, > T_SHORT = 9, > T_INT = 10, > T_LONG = 11, > T_OBJECT = 12, > T_ARRAY = 13, > T_VOID = 14, > T_ADDRESS = 15, > T_NARROWOOP= 16, > T_CONFLICT = 17, > T_ILLEGAL = 99 > }; > > Why are 0, 1, 2 and 3 missing? > > Regards > Stephen > From kurt at intricatesoftware.com Wed Jan 14 11:26:40 2009 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 14 Jan 2009 14:26:40 -0500 Subject: [patch] missing include file in hotspot 14.0b08 In-Reply-To: <1231723656.19677.13.camel@phillimores> References: <49667E7B.7010301@ubuntu.com> <1231723656.19677.13.camel@phillimores> Message-ID: <200901141426.40429.kurt@intricatesoftware.com> Hi Coleen, On Sunday 11 January 2009 8:27:36 pm Coleen Phillimore wrote: > > What version of gcc were you using? I had a lot more missing undefines > and different ones (message about inline function not defined) with gcc > version: > gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 > patchfile attached. Can you try this out? Your patch works well with gcc 3.3.5 on OpenBSD (gcc 3.3 doesn't support precompiled headers). It would be great if your diff made it into the tree. Regards, -Kurt From tom.deneau at amd.com Wed Jan 14 12:25:15 2009 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 14 Jan 2009 14:25:15 -0600 Subject: checkcast elimination Message-ID: <79EA8F06AD30D941BA943303010EAD0220E6FD@sausexmb6.amd.com> In the following method foo, an entry is being pulled from a Collection class, in this case an ArrayList, and then being passed to another method which takes an Object. The programmer stores the ArrayList return in a myClass reference but never really uses it as a myClass object. The javac compiler generates a "checkcast" bytecode and the HotSpot JVM generates code for the checkcast. Question: is it legal for the JVM to eliminate this cast check or is the semantics of this code such that the JVM is required to generate an exception if the cast fails (even though the reference is never really used as a myClass) ? -- Tom ================= ArrayList aList; void foo(int i) { myClass myc = aList.get(i); bar(myc); } void bar(Object x) { ... } From Ulf.Zibis at gmx.de Wed Jan 14 14:00:56 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 14 Jan 2009 23:00:56 +0100 Subject: BasicType enum In-Reply-To: <9E8C680A-7FE5-4DA5-9794-845C7CF19578@sun.com> References: <588ac807602fb6a748b57eef9358b48d.squirrel@webmail.elfarto.com> <9E8C680A-7FE5-4DA5-9794-845C7CF19578@sun.com> Message-ID: <496E6098.6010509@gmx.de> Maybe that had been the beloved unsigned types. ;-) -Ulf Am 14.01.2009 21:04, Tom Rodriguez schrieb: > I believe it's purely historical. I suspect Oak had a few more types > down there. > > tom > > On Jan 14, 2009, at 1:55 AM, Stephen Dawkins wrote: > >> Hi >> >> A quick question about the BasicType enum in globalDefinitions.hpp. >> >> enum BasicType { >> T_BOOLEAN = 4, >> T_CHAR = 5, >> T_FLOAT = 6, >> T_DOUBLE = 7, >> T_BYTE = 8, >> T_SHORT = 9, >> T_INT = 10, >> T_LONG = 11, >> T_OBJECT = 12, >> T_ARRAY = 13, >> T_VOID = 14, >> T_ADDRESS = 15, >> T_NARROWOOP= 16, >> T_CONFLICT = 17, >> T_ILLEGAL = 99 >> }; >> >> Why are 0, 1, 2 and 3 missing? >> >> Regards >> Stephen >> > > From kurt at intricatesoftware.com Wed Jan 14 14:08:11 2009 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 14 Jan 2009 17:08:11 -0500 Subject: [patch] missing include file in hotspot 14.0b08 In-Reply-To: <496E3CD5.6030001@sun.com> References: <49667E7B.7010301@ubuntu.com> <1231723656.19677.13.camel@phillimores> <200901141426.40429.kurt@intricatesoftware.com> <496E3CD5.6030001@sun.com> Message-ID: <496E624B.70003@intricatesoftware.com> Great, thank you. Coleen Phillimore - Sun Microsystems wrote: > > Okay, I'll add in the missing define that Matthias had and push it up. > Coleen > > On 01/14/09 14:26, Kurt Miller wrote: >> Hi Coleen, >> >> On Sunday 11 January 2009 8:27:36 pm Coleen Phillimore wrote: >> >>> What version of gcc were you using? I had a lot more missing undefines >>> and different ones (message about inline function not defined) with gcc >>> version: >>> gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 >>> patchfile attached. Can you try this out? >>> >> >> Your patch works well with gcc 3.3.5 on OpenBSD (gcc 3.3 doesn't >> support precompiled headers). It would be great if your diff made >> it into the tree. >> >> Regards, >> -Kurt >> From Thomas.Rodriguez at Sun.COM Wed Jan 14 14:08:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Jan 2009 14:08:36 -0800 Subject: checkcast elimination In-Reply-To: <79EA8F06AD30D941BA943303010EAD0220E6FD@sausexmb6.amd.com> References: <79EA8F06AD30D941BA943303010EAD0220E6FD@sausexmb6.amd.com> Message-ID: <109DDF3D-EC39-43C5-9667-6886CCDB47EB@sun.com> It's never ok to elide work that throws an exception unless you can prove that it won't occur. The general rule for optimization in hotspot is that the JVM can do anything it wants as long as you can't write a program that can detect the difference, other than performance or limits. In the case below a very clever JVM might able prove that only myClass'es were ever inserted into aList but because generics are based on type erasure we can't assume it's true. tom On Jan 14, 2009, at 12:25 PM, Deneau, Tom wrote: > In the following method foo, an entry is being pulled from a > Collection > class, in this case an ArrayList, and then being passed to another > method which takes an Object. The programmer stores the ArrayList > return in a myClass reference but never really uses it as a myClass > object. The javac compiler generates a "checkcast" bytecode and the > HotSpot JVM generates code for the checkcast. > > Question: is it legal for the JVM to eliminate this cast check or is > the > semantics of this code such that the JVM is required to generate an > exception if the cast fails (even though the reference is never really > used as a myClass) ? > > -- Tom > > ================= > ArrayList aList; > > void foo(int i) { > myClass myc = aList.get(i); > bar(myc); > } > > void bar(Object x) { > ... > } > From Ulf.Zibis at gmx.de Wed Jan 14 15:17:03 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 15 Jan 2009 00:17:03 +0100 Subject: A question about bytecodes + unsigned load ./. add performace In-Reply-To: <46E50E1E-883A-4BA1-BBBE-E35391D5A8F3@Sun.COM> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <496BF7AC.2060500@gmx.de> <46E50E1E-883A-4BA1-BBBE-E35391D5A8F3@Sun.COM> Message-ID: <496E726F.9050605@gmx.de> Tom, thanks for your answer. Hm, that would mean, (inByte & 0xFF) would be good for server VM, and bad for client VM. For client VM (inByte + 0x80) would be better. Which to give the precedence ? -Ulf Am 13.01.2009 22:57, Tom Rodriguez schrieb: > The client VM doesn't have any optimizations around folding unsigned > idioms into unsigned loads. They wouldn't be that hard for someone to > add. > > tom > > On Jan 12, 2009, at 6:08 PM, Ulf Zibis wrote: > >> Wow, these are good news. :-) >> >> So is there a chance, to implement this behaviour in trunk, so we >> could get rid of the +128 trick ? >> Is it also available for -client VM ? >> >> -Ulf >> >> >> Am 13.01.2009 02:39, John Rose schrieb: >>> On Jan 12, 2009, at 1:52 PM, Tom Rodriguez wrote: >>> >>>> The ideal for the simple example is something like (StoreC mem2 >>>> addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above will >>>> break the match at the load, forcing the value into a register. >>>> It's seem like an excessively strong cutout but I'm not sure how to >>>> phrase it better, particularly since I don't know what exactly what >>>> problem it designed to eliminate. I believe it's probably the >>>> anti-dep issue but without a concrete failure it's hard to know >>>> what exactly it should look like. >>> >>> That sounds plausible. In general, if a node has a unique user, it >>> can be pulled into one of the little spanning trees that the matcher >>> places over the ideal DAG. The graph dump Christian sent shows that >>> the LoadB has just one user ([[141]]) which means the matcher should >>> be able to group the LoadB with the AndI (and transform to loadUB), >>> unless there's something else going on, like the anti-deps you mention. >>> >>> -- John >>> >>> >> > > From Thomas.Rodriguez at Sun.COM Wed Jan 14 16:11:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Jan 2009 16:11:49 -0800 Subject: A question about bytecodes + unsigned load ./. add performace In-Reply-To: <496E726F.9050605@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <496BF7AC.2060500@gmx.de> <46E50E1E-883A-4BA1-BBBE-E35391D5A8F3@Sun.COM> <496E726F.9050605@gmx.de> Message-ID: <229984D5-9DFC-4EE1-8C1B-3E39F79C65DA@Sun.COM> On Jan 14, 2009, at 3:17 PM, Ulf Zibis wrote: > Tom, thanks for your answer. > > Hm, that would mean, (inByte & 0xFF) would be good for server VM, > and bad for client VM. For client VM (inByte + 0x80) would be better. > Which to give the precedence ? Unfortunately neither works with client, which leads to a simple answer to your question. The usage of addressing modes isn't exposed in the IR so there's no constant folding between constants in the code and constants in the address. Client started its life as a simple template like JIT and it's come a long way since then but the high level and low level IR could use some revisiting. tom > > > -Ulf > > > Am 13.01.2009 22:57, Tom Rodriguez schrieb: >> The client VM doesn't have any optimizations around folding >> unsigned idioms into unsigned loads. They wouldn't be that hard >> for someone to add. >> >> tom >> >> On Jan 12, 2009, at 6:08 PM, Ulf Zibis wrote: >> >>> Wow, these are good news. :-) >>> >>> So is there a chance, to implement this behaviour in trunk, so we >>> could get rid of the +128 trick ? >>> Is it also available for -client VM ? >>> >>> -Ulf >>> >>> >>> Am 13.01.2009 02:39, John Rose schrieb: >>>> On Jan 12, 2009, at 1:52 PM, Tom Rodriguez wrote: >>>> >>>>> The ideal for the simple example is something like (StoreC mem2 >>>>> addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))). The code above >>>>> will break the match at the load, forcing the value into a >>>>> register. It's seem like an excessively strong cutout but I'm >>>>> not sure how to phrase it better, particularly since I don't >>>>> know what exactly what problem it designed to eliminate. I >>>>> believe it's probably the anti-dep issue but without a concrete >>>>> failure it's hard to know what exactly it should look like. >>>> >>>> That sounds plausible. In general, if a node has a unique user, >>>> it can be pulled into one of the little spanning trees that the >>>> matcher places over the ideal DAG. The graph dump Christian sent >>>> shows that the LoadB has just one user ([[141]]) which means the >>>> matcher should be able to group the LoadB with the AndI (and >>>> transform to loadUB), unless there's something else going on, >>>> like the anti-deps you mention. >>>> >>>> -- John >>>> >>>> >>> >> >> > From David.Holmes at Sun.COM Wed Jan 14 17:18:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 15 Jan 2009 11:18:08 +1000 Subject: checkcast elimination In-Reply-To: <109DDF3D-EC39-43C5-9667-6886CCDB47EB@sun.com> References: <79EA8F06AD30D941BA943303010EAD0220E6FD@sausexmb6.amd.com> <109DDF3D-EC39-43C5-9667-6886CCDB47EB@sun.com> Message-ID: <496E8ED0.9070203@sun.com> But in this case I think Tom D. is hoping for something the other way around. As bar takes an Object and whatever comes back from get(i) is an Object then there's no need to check if it is a myClass. In short the code could be treated as: bar(aList.get(i)); and the type of the actual object is immaterial. Now javac won't do this itself, but could the JIT? Cheers, David Holmes Tom Rodriguez said the following on 01/15/09 08:08: > It's never ok to elide work that throws an exception unless you can > prove that it won't occur. The general rule for optimization in hotspot > is that the JVM can do anything it wants as long as you can't write a > program that can detect the difference, other than performance or > limits. In the case below a very clever JVM might able prove that only > myClass'es were ever inserted into aList but because generics are based > on type erasure we can't assume it's true. > > tom > > On Jan 14, 2009, at 12:25 PM, Deneau, Tom wrote: > >> In the following method foo, an entry is being pulled from a Collection >> class, in this case an ArrayList, and then being passed to another >> method which takes an Object. The programmer stores the ArrayList >> return in a myClass reference but never really uses it as a myClass >> object. The javac compiler generates a "checkcast" bytecode and the >> HotSpot JVM generates code for the checkcast. >> >> Question: is it legal for the JVM to eliminate this cast check or is the >> semantics of this code such that the JVM is required to generate an >> exception if the cast fails (even though the reference is never really >> used as a myClass) ? >> >> -- Tom >> >> ================= >> ArrayList aList; >> >> void foo(int i) { >> myClass myc = aList.get(i); >> bar(myc); >> } >> >> void bar(Object x) { >> ... >> } >> > From Thomas.Rodriguez at Sun.COM Wed Jan 14 17:38:08 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Jan 2009 17:38:08 -0800 Subject: checkcast elimination In-Reply-To: <496E8ED0.9070203@sun.com> References: <79EA8F06AD30D941BA943303010EAD0220E6FD@sausexmb6.amd.com> <109DDF3D-EC39-43C5-9667-6886CCDB47EB@sun.com> <496E8ED0.9070203@sun.com> Message-ID: <203E20E1-74F8-4F5F-9925-2C2F58D1EC6A@Sun.COM> On Jan 14, 2009, at 5:18 PM, David Holmes - Sun Microsystems wrote: > But in this case I think Tom D. is hoping for something the other > way around. As bar takes an Object and whatever comes back from > get(i) is an Object then there's no need to check if it is a > myClass. In short the code could be treated as: > > bar(aList.get(i)); > > and the type of the actual object is immaterial. Now javac won't do > this itself, but could the JIT? No, because that's not what the bytecodes say. They say bar((myClass)aList.get(i)). There's no way for the JIT to distinguish between javac inserted casts and user inserted casts, nor would we want to I think. If it's legal to leave it out under those conditions out then javac should be doing it. tom > > > Cheers, > David Holmes > > Tom Rodriguez said the following on 01/15/09 08:08: >> It's never ok to elide work that throws an exception unless you can >> prove that it won't occur. The general rule for optimization in >> hotspot is that the JVM can do anything it wants as long as you >> can't write a program that can detect the difference, other than >> performance or limits. In the case below a very clever JVM might >> able prove that only myClass'es were ever inserted into aList but >> because generics are based on type erasure we can't assume it's true. >> tom >> On Jan 14, 2009, at 12:25 PM, Deneau, Tom wrote: >>> In the following method foo, an entry is being pulled from a >>> Collection >>> class, in this case an ArrayList, and then being passed to another >>> method which takes an Object. The programmer stores the ArrayList >>> return in a myClass reference but never really uses it as a myClass >>> object. The javac compiler generates a "checkcast" bytecode and the >>> HotSpot JVM generates code for the checkcast. >>> >>> Question: is it legal for the JVM to eliminate this cast check or >>> is the >>> semantics of this code such that the JVM is required to generate an >>> exception if the cast fails (even though the reference is never >>> really >>> used as a myClass) ? >>> >>> -- Tom >>> >>> ================= >>> ArrayList aList; >>> >>> void foo(int i) { >>> myClass myc = aList.get(i); >>> bar(myc); >>> } >>> >>> void bar(Object x) { >>> ... >>> } >>> From Thomas.Rodriguez at Sun.COM Wed Jan 14 18:19:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Jan 2009 18:19:37 -0800 Subject: Performance of "instanceof" In-Reply-To: <496C8DC7.7000900@gmx.de> References: <496C8DC7.7000900@gmx.de> Message-ID: instanceof is the fastest way of asking the question it's designed to ask. The three code patterns below aren't necessarily asking the same question though. If MyClass has no subclasses then instanceof devolves into obj.klass == MyClass.klass, so a load and pointer compare against an embedded constant. If it has subclasses then our fast subtype check should trigger which is roughly a couple loads and a compare, unless the hierarchy is deep or MyClass is an interface. obj.getClass() == mypackage.MyClass.class will produce something relatively efficient. It should be something like obj.klass.klass_mirror == MyClass. obj.name().equals(objOfMyClass.name()) would be better with == which you could rely on if you either explicitly interned the name or used a constant string for the name so those are automatically interned for you. If you have to call .equals it's probably the worst. All of this should be true for client and server, with server producing at least slightly tighter code and maybe an extra trick or two. tom On Jan 13, 2009, at 4:49 AM, Ulf Zibis wrote: > Hi, > > I'm just interested, how "instanceof" works behind the scenes. Does > it simply string-compare the names of the classes, and in fail, do > the same with the super class in loop, or is there some > sophisticated algorithm. > > I'm asking, because I want to know, which is faster: > - obj instanceof mypackage.MyClass > - obj.getClass() == mypackage.MyClass.class > - obj.name().equals(objOfMyClass.name()) (assuming, each MyClass > has it's own name, as it is the fact for Charset subclasses.) > > - Ulf > > From john.coomes at sun.com Wed Jan 14 18:58:07 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Thu, 15 Jan 2009 02:58:07 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090115025813.E27BBD813@hg.openjdk.java.net> Changeset: e9be0e04635a Author: jmasa Date: 2009-01-06 07:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e9be0e04635a 6689653: JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off Summary: Added safe_object_iterate() for use by JMapPerm. Reviewed-by: tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 0af8b0718fc9 Author: jmasa Date: 2009-01-11 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0af8b0718fc9 6692899: CMS: many vm.parallel_class_loading tests fail with assert "missing Printezis mark" Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 65de26b5ea82 Author: jcoomes Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/65de26b5ea82 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp From Ulf.Zibis at gmx.de Thu Jan 15 03:21:41 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 15 Jan 2009 12:21:41 +0100 Subject: Performance of "instanceof" In-Reply-To: References: <496C8DC7.7000900@gmx.de> Message-ID: <496F1C45.6080001@gmx.de> Thanks Tom, I was asking because of my RFE 8 in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6790402. So I can be sure, that my proposed shortcut is much faster than the saved HashMap lookup, and hopefully HotSpot remembers the result of "instanceof", so following cast to String could be skipped. I was in doubt, how the right part of "instanceof" would retrieve a reference pointer to the Class class from the given class name. So as I understand you right, MyClass.klass is static final available from bytecode. -Ulf Am 15.01.2009 03:19, Tom Rodriguez schrieb: > instanceof is the fastest way of asking the question it's designed to > ask. The three code patterns below aren't necessarily asking the same > question though. If MyClass has no subclasses then instanceof > devolves into obj.klass == MyClass.klass, so a load and pointer > compare against an embedded constant. If it has subclasses then our > fast subtype check should trigger which is roughly a couple loads and > a compare, unless the hierarchy is deep or MyClass is an interface. > obj.getClass() == mypackage.MyClass.class will produce something > relatively efficient. It should be something like > obj.klass.klass_mirror == MyClass. > obj.name().equals(objOfMyClass.name()) would be better with == which > you could rely on if you either explicitly interned the name or used a > constant string for the name so those are automatically interned for > you. If you have to call .equals it's probably the worst. All of > this should be true for client and server, with server producing at > least slightly tighter code and maybe an extra trick or two. > > tom > > On Jan 13, 2009, at 4:49 AM, Ulf Zibis wrote: > >> Hi, >> >> I'm just interested, how "instanceof" works behind the scenes. Does >> it simply string-compare the names of the classes, and in fail, do >> the same with the super class in loop, or is there some >> sophisticated algorithm. >> >> I'm asking, because I want to know, which is faster: >> - obj instanceof mypackage.MyClass >> - obj.getClass() == mypackage.MyClass.class >> - obj.name().equals(objOfMyClass.name()) (assuming, each MyClass >> has it's own name, as it is the fact for Charset subclasses.) >> >> - Ulf >> >> > > From John.Rose at Sun.COM Thu Jan 15 08:09:43 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Jan 2009 08:09:43 -0800 Subject: Performance of "instanceof" In-Reply-To: <496F1C45.6080001@gmx.de> References: <496C8DC7.7000900@gmx.de> <496F1C45.6080001@gmx.de> Message-ID: <9901DB6E-BA08-42C3-931E-8455C02C3585@sun.com> It would be a good idea for some of us to make a page on instanceof here: http://wikis.sun.com/display/HotSpotInternals (If someone else starts it I will contribute.) HotSpot has a 1-1 relation between java.lang.Class instances and Java types; any array, instance class, or interface also has an internal meta-data object called a Klass. It is a single indirection to get from either to its sibling, so things like foo.class.isAssignableFrom (bar.getClass()) tend to cook down to the right things. The server compiler knows how to optimize away things like aConstantClass.klass and foo.klass.Class.klass (=> foo.klass). To observe the optimizations which handle this, look in the source code for uses of java_lang_Class::klass_offset_in_bytes() and Klass::java_mirror_offset_in_bytes(). But, in order to see if your use case is getting helped, there is no substitute for examining the code: http://wikis.sun.com/display/HotSpotInternals/PrintAssembly HTH -- John On Jan 15, 2009, at 3:21 AM, Ulf Zibis wrote: > Thanks Tom, > > I was asking because of my RFE 8 in http://bugs.sun.com/bugdatabase/ > view_bug.do?bug_id=6790402. > So I can be sure, that my proposed shortcut is much faster than the > saved HashMap lookup, and hopefully HotSpot remembers the result of > "instanceof", so following cast to String could be skipped. > I was in doubt, how the right part of "instanceof" would retrieve a > reference pointer to the Class class from the given class name. So > as I understand you right, MyClass.klass is static final available > from bytecode. > > -Ulf > > > Am 15.01.2009 03:19, Tom Rodriguez schrieb: >> instanceof is the fastest way of asking the question it's designed >> to ask. From coleen.phillimore at sun.com Thu Jan 15 14:37:57 2009 From: coleen.phillimore at sun.com (coleen.phillimore at sun.com) Date: Thu, 15 Jan 2009 22:37:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20090115223808.F31BED8C7@hg.openjdk.java.net> Changeset: 52a431267315 Author: coleenp Date: 2009-01-13 14:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/52a431267315 6791168: Fix invalid code in bytecodeInterpreter that can cause gcc ICE Summary: Fix compilation errors from latest gcc in CC_INTERP including offending missing void* cast. Reviewed-by: xlu ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 4db4e58c16bd Author: xlu Date: 2009-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4db4e58c16bd 6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms when initializing direct buffer support Summary: Place the state transition inside the loop so that the VMThread could proceed for safepoint Reviewed-by: dholmes, never, acorn ! src/share/vm/prims/jni.cpp Changeset: 9250583801d2 Author: xlu Date: 2009-01-13 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9250583801d2 Merge Changeset: 2ddbaf7b8e1c Author: xlu Date: 2009-01-13 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2ddbaf7b8e1c Merge Changeset: c9004fe53695 Author: xlu Date: 2009-01-13 17:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c9004fe53695 6792301: StackAlignmentInBytes not honored for compiled native methods Summary: Fixed the stack misalignment when generate_native_wrapper is called. Reviewed-by: never, kamg, kvn, phh ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: f6c0827e5919 Author: coleenp Date: 2009-01-15 12:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f6c0827e5919 Merge From john.coomes at sun.com Thu Jan 15 23:33:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 07:33:26 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b43 for changeset 848e684279d2 Message-ID: <20090116073326.CE5DEDA06@hg.openjdk.java.net> Changeset: a395e3aac474 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/a395e3aac474 Added tag jdk7-b43 for changeset 848e684279d2 ! .hgtags From john.coomes at sun.com Thu Jan 15 23:35:32 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 07:35:32 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b43 for changeset 9cd740d48a48 Message-ID: <20090116073534.54EF3DA0B@hg.openjdk.java.net> Changeset: 9803dac72540 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/9803dac72540 Added tag jdk7-b43 for changeset 9cd740d48a48 ! .hgtags From john.coomes at sun.com Thu Jan 15 23:42:01 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 07:42:01 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b43 for changeset 96fe28d4a913 Message-ID: <20090116074204.0CE0BDA11@hg.openjdk.java.net> Changeset: b203df0741af Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/b203df0741af Added tag jdk7-b43 for changeset 96fe28d4a913 ! .hgtags From john.coomes at sun.com Thu Jan 15 23:44:10 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 07:44:10 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b43 for changeset 1ad2f51564db Message-ID: <20090116074412.88E95DA42@hg.openjdk.java.net> Changeset: 344485a03674 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/344485a03674 Added tag jdk7-b43 for changeset 1ad2f51564db ! .hgtags From john.coomes at sun.com Thu Jan 15 23:49:00 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 07:49:00 +0000 Subject: hg: jdk7/hotspot/jdk: 53 new changesets Message-ID: <20090116075926.E2BF9DA47@hg.openjdk.java.net> Changeset: 4e0e690373fc Author: wetmore Date: 2008-12-02 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4e0e690373fc 6778613: Update javax.crypto.Cipher.getMaxAllowedKeyLength to point to proper Appendix after doc reorg Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: a99a2d2f3249 Author: dfuchs Date: 2008-12-04 17:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a99a2d2f3249 6319823: new mbean register/unregister notification for groups of mbeans 6779698: Merge error caused duplicate example code in MBeanServerNotification Reviewed-by: emcmanus ! src/share/classes/javax/management/MBeanServerNotification.java Changeset: 87170fc5a587 Author: mchung Date: 2008-12-05 10:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/87170fc5a587 6764062: Revise usage of java.io.*.close Summary: Handle closing multiple open I/O streams in case close() throws IOException Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/servicetag/Util.java ! src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java Changeset: baa10242c544 Author: mchung Date: 2008-12-05 10:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/baa10242c544 6750389: The cpuManufactorer does not correctly recognized for Solaris 10 Summary: Fix the correct SMBIOS type (4) to obtain CPU manufacturer Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java Changeset: ea43ec07a878 Author: tbell Date: 2008-12-05 21:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ea43ec07a878 Merge Changeset: b4bf1806ee66 Author: emcmanus Date: 2008-12-09 12:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b4bf1806ee66 6774918: @NotificationInfo is ineffective on MBeans that cannot send notifications Reviewed-by: jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/NotificationInfo.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java Changeset: 95f828533592 Author: jfdenise Date: 2008-12-09 14:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/95f828533592 6501362: DescriptorSupport(String) could recognize "name=value" as well as XML format Reviewed-by: emcmanus ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java + test/javax/management/descriptor/DescriptorConstructorTest.java Changeset: 8d7117d71fc7 Author: jfdenise Date: 2008-12-09 15:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8d7117d71fc7 6250014: MBeanOperationInfo Descriptor field for exceptions Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java + test/javax/management/Introspector/ExceptionsDescriptorTest.java Changeset: f8c2f3b5c0ff Author: jfdenise Date: 2008-12-09 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8c2f3b5c0ff 6675526: Define an Annotation to name registered MBeans Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java + src/share/classes/javax/management/ObjectNameTemplate.java + test/javax/management/Introspector/ObjectNameTemplateTest.java Changeset: ab4d12886aaf Author: jfdenise Date: 2008-12-09 16:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ab4d12886aaf 6450834: RFE: allow StandardMBean to call MBeanRegistration methods on its wrapped resource 6373143: MonitorNotification should have a public constructor Reviewed-by: emcmanus ! src/share/classes/javax/management/StandardMBean.java ! src/share/classes/javax/management/monitor/MonitorNotification.java + test/javax/management/monitor/InstantiateMonitorNotificationTest.java + test/javax/management/standardmbean/RegistrationTest.java Changeset: 3d822c99e3ab Author: jfdenise Date: 2008-12-09 16:26 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3d822c99e3ab 6287328: Add methods to StandardMBean to retrieve a method based on MBean{Attribute|Operation}Info Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/StandardMBean.java + test/javax/management/standardmbean/FindMethodTest.java Changeset: 6eec8be80bfe Author: sjiang Date: 2008-12-09 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6eec8be80bfe 6405891: MLet: could be improved to load a native lib Reviewed-by: emcmanus ! src/share/classes/javax/management/loading/MLet.java Changeset: 30239cf868b0 Author: sjiang Date: 2008-12-09 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/30239cf868b0 Merge Changeset: 0b1c7f982cc0 Author: emcmanus Date: 2008-12-09 18:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0b1c7f982cc0 6780803: Wrong parameter name in description of EventClient::addListeners() 6470295: Misleading exception message says context classloader when it isn't 6714954: Description of MBeanPermission checking in MBeanServer javadoc is inaccurate 6732037: Event Service spec needs more detail about Executor use 6740900: Specify that listeners invoked via SendNotification should not block 6778436: Typo in @NotificationInfos spec Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/javax/management/MBeanRegistration.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/FetchingEventRelay.java Changeset: 23738109351f Author: sjiang Date: 2008-12-09 18:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/23738109351f 6760712: Provide a connector server option that causes it not to prevent the VM from exiting Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java + test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java Changeset: 0dc9fc01e5d6 Author: sjiang Date: 2008-12-09 18:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0dc9fc01e5d6 Merge Changeset: 4951fee90769 Author: sjiang Date: 2008-12-09 19:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4951fee90769 6332907: Add ability for connector server to close individual connections Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/JMXConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java + test/javax/management/remote/mandatory/connectorServer/CloseConnectionTest.java Changeset: 61e73bc43e72 Author: dfuchs Date: 2008-12-09 20:20 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/61e73bc43e72 6768935: Clarify the behaviour of ObjectName pattern matching with regards to namespaces Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java ! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java ! src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/namespace/JMXDomain.java ! src/share/classes/javax/management/namespace/JMXNamespacePermission.java ! src/share/classes/javax/management/namespace/JMXNamespaces.java ! src/share/classes/javax/management/namespace/package-info.java ! test/javax/management/namespace/LeadingSeparatorsTest.java ! test/javax/management/namespace/NullDomainObjectNameTest.java ! test/javax/management/namespace/NullObjectNameTest.java ! test/javax/management/namespace/QueryNamesTest.java Changeset: 7aa035fdd97d Author: sjiang Date: 2008-12-09 20:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7aa035fdd97d 6336980: NotificationBroadcasterSupport: to tell whether there are listeners and to do clear Reviewed-by: emcmanus ! src/share/classes/javax/management/NotificationBroadcasterSupport.java + test/javax/management/notification/SupportClearTest.java Changeset: 3f226f477d56 Author: sjiang Date: 2008-12-09 20:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3f226f477d56 Merge Changeset: c8db1ddbdba4 Author: emcmanus Date: 2008-12-10 11:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c8db1ddbdba4 6456269: Add a GenericMBeanException so clients don't have to have server's exception classes present Reviewed-by: jfdenise, dfuchs ! src/share/classes/javax/management/Descriptor.java + src/share/classes/javax/management/GenericMBeanException.java ! src/share/classes/javax/management/MBeanException.java + test/javax/management/interop/MBeanExceptionInteropTest.java + test/javax/management/openmbean/GenericMBeanExceptionTest.java Changeset: b89ba9a6d9a6 Author: sherman Date: 2008-12-10 14:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b89ba9a6d9a6 6642323: Speeding up Single Byte Decoders 6642328: Speeding up Single Byte Encoders Summary: re-implementation of mapping based sbcs charts Reviewed-by: alanb ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/IBM037.c2b + make/tools/CharsetMapping/IBM037.map + make/tools/CharsetMapping/IBM037.nr + make/tools/CharsetMapping/IBM1006.map + make/tools/CharsetMapping/IBM1025.c2b + make/tools/CharsetMapping/IBM1025.map + make/tools/CharsetMapping/IBM1025.nr + make/tools/CharsetMapping/IBM1026.c2b + make/tools/CharsetMapping/IBM1026.map + make/tools/CharsetMapping/IBM1026.nr + make/tools/CharsetMapping/IBM1046.map + make/tools/CharsetMapping/IBM1047.map + make/tools/CharsetMapping/IBM1097.map + make/tools/CharsetMapping/IBM1098.map + make/tools/CharsetMapping/IBM1112.c2b + make/tools/CharsetMapping/IBM1112.map + make/tools/CharsetMapping/IBM1112.nr + make/tools/CharsetMapping/IBM1122.c2b + make/tools/CharsetMapping/IBM1122.map + make/tools/CharsetMapping/IBM1122.nr + make/tools/CharsetMapping/IBM1123.c2b + make/tools/CharsetMapping/IBM1123.map + make/tools/CharsetMapping/IBM1123.nr + make/tools/CharsetMapping/IBM1124.map + make/tools/CharsetMapping/IBM1140.c2b + make/tools/CharsetMapping/IBM1140.map + make/tools/CharsetMapping/IBM1141.c2b + make/tools/CharsetMapping/IBM1141.map + make/tools/CharsetMapping/IBM1142.c2b + make/tools/CharsetMapping/IBM1142.map + make/tools/CharsetMapping/IBM1143.c2b + make/tools/CharsetMapping/IBM1143.map + make/tools/CharsetMapping/IBM1144.c2b + make/tools/CharsetMapping/IBM1144.map + make/tools/CharsetMapping/IBM1145.c2b + make/tools/CharsetMapping/IBM1145.map + make/tools/CharsetMapping/IBM1146.c2b + make/tools/CharsetMapping/IBM1146.map + make/tools/CharsetMapping/IBM1147.c2b + make/tools/CharsetMapping/IBM1147.map + make/tools/CharsetMapping/IBM1148.c2b + make/tools/CharsetMapping/IBM1148.map + make/tools/CharsetMapping/IBM1149.c2b + make/tools/CharsetMapping/IBM1149.map + make/tools/CharsetMapping/IBM273.c2b + make/tools/CharsetMapping/IBM273.map + make/tools/CharsetMapping/IBM273.nr + make/tools/CharsetMapping/IBM277.c2b + make/tools/CharsetMapping/IBM277.map + make/tools/CharsetMapping/IBM277.nr + make/tools/CharsetMapping/IBM278.c2b + make/tools/CharsetMapping/IBM278.map + make/tools/CharsetMapping/IBM278.nr + make/tools/CharsetMapping/IBM280.c2b + make/tools/CharsetMapping/IBM280.map + make/tools/CharsetMapping/IBM280.nr + make/tools/CharsetMapping/IBM284.c2b + make/tools/CharsetMapping/IBM284.map + make/tools/CharsetMapping/IBM284.nr + make/tools/CharsetMapping/IBM285.c2b + make/tools/CharsetMapping/IBM285.map + make/tools/CharsetMapping/IBM285.nr + make/tools/CharsetMapping/IBM297.c2b + make/tools/CharsetMapping/IBM297.map + make/tools/CharsetMapping/IBM297.nr + make/tools/CharsetMapping/IBM420.c2b + make/tools/CharsetMapping/IBM420.map + make/tools/CharsetMapping/IBM420.nr + make/tools/CharsetMapping/IBM424.c2b + make/tools/CharsetMapping/IBM424.map + make/tools/CharsetMapping/IBM424.nr + make/tools/CharsetMapping/IBM437.map + make/tools/CharsetMapping/IBM500.c2b + make/tools/CharsetMapping/IBM500.map + make/tools/CharsetMapping/IBM500.nr + make/tools/CharsetMapping/IBM737.map + make/tools/CharsetMapping/IBM775.map + make/tools/CharsetMapping/IBM838.c2b + make/tools/CharsetMapping/IBM838.map + make/tools/CharsetMapping/IBM838.nr + make/tools/CharsetMapping/IBM850.map + make/tools/CharsetMapping/IBM852.map + make/tools/CharsetMapping/IBM855.map + make/tools/CharsetMapping/IBM856.map + make/tools/CharsetMapping/IBM857.map + make/tools/CharsetMapping/IBM858.map + make/tools/CharsetMapping/IBM860.map + make/tools/CharsetMapping/IBM861.map + make/tools/CharsetMapping/IBM862.map + make/tools/CharsetMapping/IBM863.map + make/tools/CharsetMapping/IBM864.map + make/tools/CharsetMapping/IBM865.map + make/tools/CharsetMapping/IBM866.map + make/tools/CharsetMapping/IBM868.map + make/tools/CharsetMapping/IBM869.map + make/tools/CharsetMapping/IBM870.c2b + make/tools/CharsetMapping/IBM870.map + make/tools/CharsetMapping/IBM870.nr + make/tools/CharsetMapping/IBM871.c2b + make/tools/CharsetMapping/IBM871.map + make/tools/CharsetMapping/IBM871.nr + make/tools/CharsetMapping/IBM874.map + make/tools/CharsetMapping/IBM874.nr + make/tools/CharsetMapping/IBM875.c2b + make/tools/CharsetMapping/IBM875.map + make/tools/CharsetMapping/IBM875.nr + make/tools/CharsetMapping/IBM918.c2b + make/tools/CharsetMapping/IBM918.map + make/tools/CharsetMapping/IBM918.nr + make/tools/CharsetMapping/IBM921.map + make/tools/CharsetMapping/IBM922.map + make/tools/CharsetMapping/ISO_8859_11.map + make/tools/CharsetMapping/ISO_8859_13.map + make/tools/CharsetMapping/ISO_8859_15.map + make/tools/CharsetMapping/ISO_8859_2.map + make/tools/CharsetMapping/ISO_8859_3.map + make/tools/CharsetMapping/ISO_8859_4.map + make/tools/CharsetMapping/ISO_8859_5.map + make/tools/CharsetMapping/ISO_8859_6.map + make/tools/CharsetMapping/ISO_8859_7.map + make/tools/CharsetMapping/ISO_8859_8.map + make/tools/CharsetMapping/ISO_8859_9.map + make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/KOI8_R.map + make/tools/CharsetMapping/KOI8_U.map + make/tools/CharsetMapping/MS1250.map + make/tools/CharsetMapping/MS1251.map + make/tools/CharsetMapping/MS1252.map + make/tools/CharsetMapping/MS1253.map + make/tools/CharsetMapping/MS1254.map + make/tools/CharsetMapping/MS1255.map + make/tools/CharsetMapping/MS1256.map + make/tools/CharsetMapping/MS1257.map + make/tools/CharsetMapping/MS1258.map + make/tools/CharsetMapping/MS874.map + make/tools/CharsetMapping/MacArabic.map + make/tools/CharsetMapping/MacCentralEurope.map + make/tools/CharsetMapping/MacCroatian.map + make/tools/CharsetMapping/MacCyrillic.map + make/tools/CharsetMapping/MacDingbat.map + make/tools/CharsetMapping/MacGreek.map + make/tools/CharsetMapping/MacHebrew.map + make/tools/CharsetMapping/MacIceland.map + make/tools/CharsetMapping/MacRoman.map + make/tools/CharsetMapping/MacRomania.map + make/tools/CharsetMapping/MacSymbol.map + make/tools/CharsetMapping/MacThai.map + make/tools/CharsetMapping/MacTurkish.map + make/tools/CharsetMapping/MacUkraine.map + make/tools/CharsetMapping/SingleByte-X.java + make/tools/CharsetMapping/TIS_620.map + make/tools/CharsetMapping/extsbcs + make/tools/CharsetMapping/sbcs ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java + make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/sun/io/ByteToCharCp850.java ! src/share/classes/sun/io/CharToByteJIS0201.java ! src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java + src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: 18ab3173fcec Author: tbell Date: 2008-12-19 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/18ab3173fcec Merge ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java Changeset: 94bcd3503668 Author: bae Date: 2008-07-25 14:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/94bcd3503668 6687968: PNGImageReader leaks native memory through an Inflater. Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java Changeset: e62bc7b05b8a Author: igor Date: 2008-08-04 18:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e62bc7b05b8a 4356282: RFE: T2K should be used to rasterize CID/CFF fonts Reviewed-by: bae, prr ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/windows/native/sun/font/fontpath.c Changeset: a56641c1f54e Author: tdv Date: 2008-08-04 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a56641c1f54e 6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque destination Reviewed-by: campbell ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java Changeset: b2413144d908 Author: tdv Date: 2008-08-04 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b2413144d908 6717988: D3D: rendering problems with JConsole on [Nvidia FX 5200] Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 06a02adcba4e Author: tdv Date: 2008-08-05 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/06a02adcba4e 6733718: test /java/awt/FullScreen/UninitializedDisplayModeChangeTest/ fails Reviewed-by: igor + test/java/awt/FullScreen/UninitializedDisplayModeChangeTest/DisplayModeChanger.java Changeset: 15be3e891e97 Author: jgodinez Date: 2008-08-07 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/15be3e891e97 6731937: javax/print/CheckDupFlavor.java fails Reviewed-by: campbell, tdv ! src/solaris/classes/sun/print/IPPPrintService.java + test/javax/print/CheckDupFlavor.java Changeset: 3c4561f955f3 Author: lana Date: 2008-08-07 22:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3c4561f955f3 Merge - make/tools/winver/Makefile - make/tools/winver/bin/winver.exe - make/tools/winver/src/StdAfx.cpp - make/tools/winver/src/StdAfx.h - make/tools/winver/src/winver.cpp - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java - src/share/classes/javax/management/ToQueryString.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/solaris/classes/sun/print/IPPPrintService.java - test/javax/management/Introspector/LegacyIntrospectorTest.java Changeset: 3d3ef4073bdd Author: jgodinez Date: 2008-08-19 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3d3ef4073bdd 6731826: race condition in UnixPrintServiceLookup Reviewed-by: campbell, tdv ! src/solaris/classes/sun/print/IPPPrintService.java + test/javax/print/TestRaceCond.java Changeset: cd88b4ad7f25 Author: tdv Date: 2008-08-28 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cd88b4ad7f25 6739267: D3D/OGL: add missing ThreeByteBgr to texture upload blit loop Reviewed-by: campbell, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h Changeset: b8f91ea2fb33 Author: tdv Date: 2008-09-12 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b8f91ea2fb33 6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal Reviewed-by: prr, tdv Contributed-by: rkennke at kennke.org ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: 41ff3f84cd96 Author: prr Date: 2008-09-24 11:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/41ff3f84cd96 6751621: TextLayout.getBounds() doesn't account for strike through Reviewed-by: igor, dougfelt ! src/share/classes/sun/font/Decoration.java ! src/share/classes/sun/font/Underline.java + test/java/awt/font/TextLayout/DecorationBoundsTest.java Changeset: 3bc4d79d8123 Author: tdv Date: 2008-10-09 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3bc4d79d8123 6749060: LCD AA text rendered incorrectly when destination is non opaque (sw pipeline only) Reviewed-by: campbell, prr ! src/share/classes/sun/java2d/SurfaceData.java ! test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java Changeset: 9a6094d65d28 Author: jgodinez Date: 2008-10-13 15:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9a6094d65d28 6732647: isAttributeValueSupported() is not consistant with getSupportedValues() for Copies, TEXT flavor Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintService.java ! test/javax/print/attribute/PSCopiesFlavorTest.java Changeset: 22d965ed3b93 Author: prr Date: 2008-10-16 06:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/22d965ed3b93 6751616: outline for underline in TextLayout with underline is off rasterized underline Reviewed-by: dougfelt, igor ! src/share/classes/sun/font/Decoration.java + test/java/awt/font/TextLayout/UnderlinePositionTest.java Changeset: 665850610378 Author: lana Date: 2008-10-20 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/665850610378 Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README - make/java/nio/spp.sh - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java - src/share/classes/java/nio/channels/package.html - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions ! src/share/classes/sun/swing/SwingUtilities2.java - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/javavm/include/typedefs_md.h - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c - src/windows/javavm/include/typedefs_md.h - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: 452c58b2f533 Author: tdv Date: 2008-10-21 08:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/452c58b2f533 6755274: 6u10b33 2d tests fails on sles10x64 with jvm crash Reviewed-by: campbell ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java Changeset: c739feb28074 Author: prr Date: 2008-10-28 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c739feb28074 6764543: SIGSEGV in libfontconfig.so starting from jdk7b33 Reviewed-by: campbell, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: 594c52582b21 Author: tdv Date: 2008-10-28 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/594c52582b21 6764257: D3D/OGL: color is not reset properly after save/restoreState() [RSL] Reviewed-by: campbell ! src/share/classes/sun/java2d/pipe/BufferedContext.java + test/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java Changeset: 9cdababf6179 Author: igor Date: 2008-10-29 01:52 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9cdababf6179 6761856: OpenJDK: vertical text metrics may be significanly different from those returned by Sun JDK Reviewed-by: bae, prr ! src/share/native/sun/font/freetypeScaler.c ! test/java/awt/font/TextLayout/TextLayoutBounds.java Changeset: 3a9d06af8830 Author: bae Date: 2008-11-01 20:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3a9d06af8830 6541476: PNG imageio plugin incorrectly handles iTXt chunk Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/ITXtTest.java Changeset: 8eb24fc88242 Author: tdv Date: 2008-11-18 17:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8eb24fc88242 6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage Reviewed-by: campbell, flar ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp + test/sun/java2d/DirectX/OpaqueImageToSurfaceBlitTest/OpaqueImageToSurfaceBlitTest.java Changeset: 3fea7e660a8f Author: tdv Date: 2008-11-18 18:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3fea7e660a8f 6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp ! src/windows/native/sun/java2d/d3d/D3DContext.cpp Changeset: be363ea85cb4 Author: jgodinez Date: 2008-11-25 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/be363ea85cb4 6653384: Variable "initialized" in class CUPSPrinter is static by mistake Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PrinterJob/GetMediasTest.java Changeset: c8eea39734e8 Author: jgodinez Date: 2008-12-04 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c8eea39734e8 6587245: Import declaration not used in sun.print.* Reviewed-by: tdv, prr ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDocPrintService.java ! src/share/classes/javax/print/PrintServiceLookup.java ! src/share/classes/javax/print/attribute/URISyntax.java ! src/share/classes/javax/print/event/PrintServiceAttributeEvent.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PrintJobAttributeException.java ! src/share/classes/sun/print/SunMinMaxPage.java ! src/share/classes/sun/print/SunPageSelection.java Changeset: 15435c60c751 Author: tdv Date: 2008-12-04 11:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/15435c60c751 6708580: Java applications slow when EXA enabled Reviewed-by: prr, tdv Contributed-by: ceisserer ! make/sun/awt/mapfile-mawt-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: b0c446712fae Author: jgodinez Date: 2008-12-08 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b0c446712fae 6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown Reviewed-by: tdv, prr ! src/share/classes/java/awt/print/PrinterJob.java Changeset: b163d898f83f Author: tdv Date: 2008-12-08 17:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b163d898f83f 6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: bf5dd3128c6a Author: lana Date: 2008-12-08 19:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bf5dd3128c6a Merge Changeset: 50c67678b0d1 Author: lana Date: 2009-01-06 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/50c67678b0d1 Merge ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 8dcc06d43798 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8dcc06d43798 Added tag jdk7-b43 for changeset 50c67678b0d1 ! .hgtags From john.coomes at sun.com Fri Jan 16 00:08:19 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:08:19 +0000 Subject: hg: jdk7/hotspot/langtools: 4 new changesets Message-ID: <20090116080827.8B51FDA4C@hg.openjdk.java.net> Changeset: 8db0c5fd6e99 Author: jjg Date: 2008-12-02 14:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8db0c5fd6e99 6778638: javadoc regression tests require tabs Reviewed-by: darcy ! test/com/sun/javadoc/testSourceTab/DoubleTab/C.java ! test/com/sun/javadoc/testSourceTab/SingleTab/C.java ! test/com/sun/javadoc/testSourceTab/TestSourceTab.java Changeset: 4efd44aa85ff Author: tbell Date: 2008-12-05 21:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4efd44aa85ff Merge Changeset: e2f8f6daee9d Author: tbell Date: 2008-12-19 10:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e2f8f6daee9d Merge Changeset: 05b47447cbcf Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/05b47447cbcf Added tag jdk7-b43 for changeset e2f8f6daee9d ! .hgtags From kurt at intricatesoftware.com Fri Jan 16 08:06:21 2009 From: kurt at intricatesoftware.com (Kurt Miller) Date: Fri, 16 Jan 2009 11:06:21 -0500 Subject: [patch] missing include file in hotspot 14.0b08 In-Reply-To: <496E3CD5.6030001@sun.com> References: <49667E7B.7010301@ubuntu.com> <200901141426.40429.kurt@intricatesoftware.com> <496E3CD5.6030001@sun.com> Message-ID: <200901161106.22624.kurt@intricatesoftware.com> Hmm. I spoke a bit too soon. The amd64 build found one more missing include: g++ ... openjdk/hotspot/src/share/vm/memory/cardTableModRefBS.cpp openjdk/hotspot/src/share/vm/memory/space.hpp:852: warning: inline function `void ContiguousSpace::set_concurrent_iteration_safe_limit(HeapWord*)' used but never defined Adding the following change to the existing set of changes fixed it for me. --- hotspot/src/share/vm/includeDB_core.orig Fri Dec 19 03:42:10 2008 +++ hotspot/src/share/vm/includeDB_core Fri Jan 16 09:38:20 2009 @@ -473,7 +473,7 @@ cardTableModRefBS.cpp cardTableRS.hp cardTableModRefBS.cpp java.hpp cardTableModRefBS.cpp mutexLocker.hpp cardTableModRefBS.cpp sharedHeap.hpp -cardTableModRefBS.cpp space.hpp +cardTableModRefBS.cpp space.inline.hpp cardTableModRefBS.cpp universe.hpp cardTableModRefBS.cpp virtualspace.hpp On Wednesday 14 January 2009 2:28:21 pm Coleen Phillimore - Sun Microsystems wrote: > > Okay, I'll add in the missing define that Matthias had and push it up. > Coleen > > On 01/14/09 14:26, Kurt Miller wrote: > > Hi Coleen, > > > > On Sunday 11 January 2009 8:27:36 pm Coleen Phillimore wrote: > > > >> What version of gcc were you using? I had a lot more missing undefines > >> and different ones (message about inline function not defined) with gcc > >> version: > >> gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 > >> patchfile attached. Can you try this out? > >> > > > > Your patch works well with gcc 3.3.5 on OpenBSD (gcc 3.3 doesn't > > support precompiled headers). It would be great if your diff made > > it into the tree. > > > > Regards, > > -Kurt > > > From Christian.Thalinger at Sun.COM Sat Jan 17 08:48:43 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 17 Jan 2009 17:48:43 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <496BF7AC.2060500@gmx.de> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <496BF7AC.2060500@gmx.de> Message-ID: <1232210923.7455.7.camel@localhost.localdomain> On Tue, 2009-01-13 at 03:08 +0100, Ulf Zibis wrote: > Wow, these are good news. :-) > > So is there a chance, to implement this behaviour in trunk, so we could > get rid of the +128 trick ? > Is it also available for -client VM ? Hi Ulf! I already have code that seems to work as it should and I also took a look at CR6642323. To you have some standalone benchmarks that you could send me? Btw. the thread was moved (accidentally?) to hotspot-compiler-dev. You can follow the ongoing discussion there. -- Christian From Ulf.Zibis at gmx.de Sat Jan 17 09:39:00 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Jan 2009 18:39:00 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] Message-ID: <497217B4.3000307@gmx.de> Hi Christian, here I send you some benchmark, which was written by Sherman, the inventor ? of the +128 trick. I didn't try it yet. You also can refer to: Cr #6785335 https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/SpeedTest.java?rev=&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/bin/ For the latter, I'm afraid, you have to setup my project https://java-nio-charset-enhanced.dev.java.net/ by help of NetBeans. -Ulf -------- Original-Nachricht -------- Betreff: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... Datum: Mon, 15 Dec 2008 15:39:05 -0800 Von: Xueming Shen An: Ulf Zibis CC: core-libs-dev at openjdk.java.net Referenzen: <20081210221115.6881DD5DA at hg.openjdk.java.net> <4946C475.6080609 at gmx.de> <4946C762.8010003 at gmx.de> <4946D7EA.2060902 at sun.com> <4946DF38.9030007 at gmx.de> Ulf, this is a simple benchmark test case I was using for the singlebyte stuff, you can benchmark lots of things with simple tweak. It's a simple version from Martin's more complicated/sophisticated benchmark. Sherman Ulf Zibis wrote: > one more question, just for interest: > Can you see any performance difference between > sp != sl > and > sp < sl > ? > > -Ulf > > > Am 15.12.2008 23:19, Xueming Shen schrieb: >> >> The gain from doing >> >> int sr = src.remaining(); >> int dr = dst.remaining(); >> >> Ulf, thanks for looking into the changes. >> >> It might not be a good idea to skip the temporary variable c in the >> loop, I'm not sure >> it's a good idea to put an "un-mappable" char into the output buffer >> in case we have >> a un-mappable though yes we don't not change the buffer position. >> This actually is >> all most all the gain come from in -server vm case when I run my >> benchmark. >> >> However in "client" vm case, interestingly I do see some performance >> gain with >> your proposed change, though I'm not sure why the loop gets faster >> with a quick >> look. So I have created a new Cr #6785335 to keep trace this issue. >> Will consider >> put this one into 7 later. >> >> Thanks again! >> >> Sherman >> >> >> Ulf Zibis wrote: >>> Maybe: >>> for (int sl = sp + (sr <= dr ? sr : dr); sp != sl; sp++, dp++) >>> is little more faster than: >>> for (int sl = sp + (sr <= dr ? sr : dr); sp < sl; sp++, dp++) >>> >>> -Ulf >>> >>> >>> Am 15.12.2008 21:56, Ulf Zibis schrieb: >>>> Maybe little faster, especially for short strings: >>>> >>>> private CoderResult decodeArrayLoop(ByteBuffer src, >>>> CharBuffer dst) { >>>> byte[] sa = src.array(); >>>> int sp = src.arrayOffset() + src.position(); >>>> int sr = src.remaining(); // faster than ... >>>> src.arrayOffset() + src.limit() >>>> >>>> char[] da = dst.array(); >>>> int dp = dst.arrayOffset() + dst.position(); >>>> int dr = dst.remaining(); // dl is never used >>>> >>>> for (int sl = sp + (sr <= dr ? sr : dr); sp < sl; sp++, >>>> dp++) >>>> if ((da[dp] = decode(sa[sp])) == UNMAPPABLE_DECODING) >>>> return >>>> withResult(CoderResult.unmappableForLength(1), src, sp, dst, dp); >>>> return withResult(sr <= dr ? CoderResult.UNDERFLOW : >>>> CoderResult.OVERFLOW, src, sp, dst, dp); >>>> } >>>> >>>> Regards, >>>> Ulf >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090117/c4a0d832/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: NIOCodingMicroBenchmark.java Type: text/x-java Size: 7956 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090117/c4a0d832/attachment.bin From Ulf.Zibis at gmx.de Sat Jan 17 10:00:58 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Jan 2009 19:00:58 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232210923.7455.7.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <496BF7AC.2060500@gmx.de> <1232210923.7455.7.camel@localhost.localdomain> Message-ID: <49721CDA.8080201@gmx.de> Am 17.01.2009 17:48, Christian Thalinger schrieb: > Hi Ulf! > I already have code that seems to work as it should and I also took a > look at CR6642323. To you have some standalone benchmarks that you > could send me? > > Btw. the thread was moved (accidentally?) to . You > can follow the ongoing discussion there. > > -- Christian > > > Hi Christian, the news are getting better. :-) Thanks for your hint about hotspot-compiler-dev. I've just subsribed. -Ulf From Christian.Thalinger at Sun.COM Sat Jan 17 10:51:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 17 Jan 2009 19:51:37 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <497217B4.3000307@gmx.de> References: <497217B4.3000307@gmx.de> Message-ID: <1232218297.7455.9.camel@localhost.localdomain> On Sat, 2009-01-17 at 18:39 +0100, Ulf Zibis wrote: > Hi Christian, > > here I send you some benchmark, which was written by Sherman, the > inventor ? of the +128 trick. > I didn't try it yet. > > You also can refer to: > Cr #6785335 > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/SpeedTest.java?rev=&view=markup > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/bin/ > > For the latter, I'm afraid, you have to setup my project > https://java-nio-charset-enhanced.dev.java.net/ by help of NetBeans. Thanks for the benchmark, but it seems it does not use any unsigned byte loads. Can you point me to a place in the JDK where this +128 trick is used? -- Christian From Ulf.Zibis at gmx.de Sat Jan 17 11:23:51 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Jan 2009 20:23:51 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <1232218297.7455.9.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> Message-ID: <49723047.9000206@gmx.de> Hi Christian, In JDK 6 it's in sun.nio.cs.SingleByteDecoder, method decode(). In JDK 7 it's also in sun.nio.cs.SingleByte$Decoder, method decode(). Here you can see, how I've played around with different byte loading techniques: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/array_io_string/src/sun/nio/cs/SingleByteFastDecoder.java?rev=&view=markup Most up-to-date are: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteMapDecoder.java?rev=&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunc/src/sun/nio/cs/SingleByteDirtyMapDecoder.java?rev=&view=markup To run my project's classes after checkout, you first have to run once make\src\build\tools\charsetmapping\GenerateMappingData by using configuration "GenerateMappingData" in NetBeans IDE. Good luck, -Ulf Am 17.01.2009 19:51, Christian Thalinger schrieb: > > Thanks for the benchmark, but it seems it does not use any unsigned byte > loads. Can you point me to a place in the JDK where this +128 trick is > used? > > -- Christian > > > From Christian.Thalinger at Sun.COM Sat Jan 17 12:09:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 17 Jan 2009 21:09:58 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <49723047.9000206@gmx.de> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> Message-ID: <1232222998.7455.20.camel@localhost.localdomain> On Sat, 2009-01-17 at 20:23 +0100, Ulf Zibis wrote: > Hi Christian, > > In JDK 6 it's in sun.nio.cs.SingleByteDecoder, method decode(). > In JDK 7 it's also in sun.nio.cs.SingleByte$Decoder, method decode(). > > Here you can see, how I've played around with different byte loading > techniques: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/array_io_string/src/sun/nio/cs/SingleByteFastDecoder.java?rev=&view=markup > > Most up-to-date are: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteMapDecoder.java?rev=&view=markup > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunc/src/sun/nio/cs/SingleByteDirtyMapDecoder.java?rev=&view=markup > > To run my project's classes after checkout, you first have to run once > make\src\build\tools\charsetmapping\GenerateMappingData by using > configuration "GenerateMappingData" in NetBeans IDE. I decided to write my own, very simple micro-benchmark. In the following benchmark I get a speedup of about 0.9%: void foo() { byte[] ba = new byte[255]; char[] ca = new char[255]; for (int i = 0; i < 10000000; i++) { bar(ba, ca); } } void bar(byte[] ba, char[] ca) { for (int i = 0; i < ba.length; i++) { ca[i] = decode(ba[i]); } } public char decode(byte a) { return (char) (a & 0xFF); } That speedup is quite OK but I doubt you will get as much in your tests. But still, there's some room left for other optimizations. Maybe I can look into them too. -- Christian From Christian.Thalinger at Sun.COM Sat Jan 17 12:57:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 17 Jan 2009 21:57:25 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <1232222998.7455.20.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> Message-ID: <1232225845.7455.23.camel@localhost.localdomain> On Sat, 2009-01-17 at 21:09 +0100, Christian Thalinger wrote: > I decided to write my own, very simple micro-benchmark. In the > following benchmark I get a speedup of about 0.9%: Yeah, but when I change the array size to 250k elements I get a slowdown of 10%. Still investigating... -- Christian From Ulf.Zibis at gmx.de Sat Jan 17 13:18:57 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Jan 2009 22:18:57 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <1232222998.7455.20.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> Message-ID: <49724B41.6070104@gmx.de> Am 17.01.2009 21:09, Christian Thalinger schrieb: > I decided to write my own, very simple micro-benchmark. In the > following benchmark I get a speedup of about 0.9%: > > void foo() { > byte[] ba = new byte[255]; > char[] ca = new char[255]; > for (int i = 0; i < 10000000; i++) { > bar(ba, ca); > } > } > > void bar(byte[] ba, char[] ca) { > for (int i = 0; i < ba.length; i++) { > ca[i] = decode(ba[i]); > } > } > > public char decode(byte a) { > return (char) (a & 0xFF); > } > > That speedup is quite OK but I doubt you will get as much in your tests. > But still, there's some room left for other optimizations. Maybe I can > look into them too. > > -- Christian > > > Hi, do you mean 0.9 % against +128 trick. This would be good result, because then we could get rid of this trick, and the maps must not be swapped before. Maybe there is more difference if buffer's are longer? Why you choose byte[255] against byte[256] ? What's about filling the buffers with values before?: for (int i=0; i References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <1232225845.7455.23.camel@localhost.localdomain> Message-ID: <49724D74.4090503@gmx.de> OK, let's see. BTW: the +128 trick is only used in case of decoding by map. If values are only passed through (charset ISO-8859-1), the +128 trick doesn't work. -Ulf Am 17.01.2009 21:57, Christian Thalinger schrieb: > On Sat, 2009-01-17 at 21:09 +0100, Christian Thalinger wrote: > >> I decided to write my own, very simple micro-benchmark. In the >> following benchmark I get a speedup of about 0.9%: >> > > Yeah, but when I change the array size to 250k elements I get a slowdown > of 10%. Still investigating... > > -- Christian > > > ... also copy for the list :-) From Ulf.Zibis at gmx.de Sat Jan 17 13:35:32 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Jan 2009 22:35:32 +0100 Subject: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... In-Reply-To: <49724D74.4090503@gmx.de> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <1232225845.7455.23.camel@localhost.localdomain> <49724D74.4090503@gmx.de> Message-ID: <49724F24.7010602@gmx.de> + the map should be defined final. -Ulf Am 17.01.2009 22:28, Ulf Zibis schrieb: > OK, let's see. > > BTW: the +128 trick is only used in case of decoding by map. If values > are only passed through (charset ISO-8859-1), the +128 trick doesn't > work. > > -Ulf > > > Am 17.01.2009 21:57, Christian Thalinger schrieb: >> On Sat, 2009-01-17 at 21:09 +0100, Christian Thalinger wrote: >> >>> I decided to write my own, very simple micro-benchmark. In the >>> following benchmark I get a speedup of about 0.9%: >>> >> >> Yeah, but when I change the array size to 250k elements I get a slowdown >> of 10%. Still investigating... >> >> -- Christian >> >> >> > > ... also copy for the list :-) > > > From Ulf.Zibis at gmx.de Sat Jan 17 13:48:34 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 17 Jan 2009 22:48:34 +0100 Subject: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... In-Reply-To: <49724D74.4090503@gmx.de> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <1232225845.7455.23.camel@localhost.localdomain> <49724D74.4090503@gmx.de> Message-ID: <49725232.5060609@gmx.de> Maybe mix up the map a little: for (int i=0; i OK, let's see. > > BTW: the +128 trick is only used in case of decoding by map. If values > are only passed through (charset ISO-8859-1), the +128 trick doesn't > work. > > -Ulf > > > Am 17.01.2009 21:57, Christian Thalinger schrieb: >> On Sat, 2009-01-17 at 21:09 +0100, Christian Thalinger wrote: >> >>> I decided to write my own, very simple micro-benchmark. In the >>> following benchmark I get a speedup of about 0.9%: >>> >> >> Yeah, but when I change the array size to 250k elements I get a slowdown >> of 10%. Still investigating... >> >> -- Christian >> >> >> > > ... also copy for the list :-) > > > From Christian.Thalinger at Sun.COM Sat Jan 17 14:48:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 17 Jan 2009 23:48:11 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <49724B41.6070104@gmx.de> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <49724B41.6070104@gmx.de> Message-ID: <1232232491.7455.26.camel@localhost.localdomain> On Sat, 2009-01-17 at 22:18 +0100, Ulf Zibis wrote: > Hi, > > do you mean 0.9 % against +128 trick. This would be good result, because > then we could get rid of this trick, and the maps must not be swapped > before. > > Maybe there is more difference if buffer's are longer? > Why you choose byte[255] against byte[256] ? > What's about filling the buffers with values before?: > > for (int i=0; i map[i] = (char)i; > for (int i=0; i src[i] = (byte)i; Filling the buffers should not change the runtime. > > Can you also try with map ?: > > char[] map = new char[256]; > void foo() { > byte[] src = new byte[16384]; > char[] dst = new char[16384]; > for (int i=0; i<1000000; i++) { > bar(src, dst); > } > } > > void bar(byte[] src, char[] dst) { > for (int i=0; i dst[i] = decode(src[i]); > } > } > > public char decode(byte a) { > return map[a & 0xFF]; > } > > > Is there any difference, if you inline the decode method into the for loop? I tried that one and it's slightly slower with my new version (unsigned byte loads). Btw. I ran the benchmarks on an Intel Core 2 Duo. -- Christian From Ulf.Zibis at gmx.de Sat Jan 17 16:03:05 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 18 Jan 2009 01:03:05 +0100 Subject: [Fwd: Re: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...] In-Reply-To: <1232225845.7455.23.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <1232225845.7455.23.camel@localhost.localdomain> Message-ID: <497271B9.9040009@gmx.de> Am 17.01.2009 21:57, Christian Thalinger schrieb: > > Yeah, but when I change the array size to 250k elements I get a slowdown > of 10%. Still investigating... > > -- Christian > > Maybe there is some limit by cpu cache 32k / 64k / 128k ? -Ulf From Ulf.Zibis at gmx.de Sat Jan 17 18:01:33 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 18 Jan 2009 03:01:33 +0100 Subject: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... In-Reply-To: <1232232491.7455.26.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <49724B41.6070104@gmx.de> <1232232491.7455.26.camel@localhost.localdomain> Message-ID: <49728D7D.9050009@gmx.de> Am 17.01.2009 23:48, Christian Thalinger schrieb: > > I tried that one and it's slightly slower with my new version (unsigned > byte loads). Btw. I ran the benchmarks on an Intel Core 2 Duo. > > -- Christian > > Hi Christian, I have Intel Pentium M, 2 GHz, FSB 533 MHz (notebook). I experienced, that CPU will clock down after some time because of overheating, so comparing absolute times became nonsense. Will you please check your HotSpot optimizations with this code: /** * * @author Ulf Zibis */ public class DecoderBenchmark { public static void main(String[] args) { foo(); } static final char[] map = new char[256]; static final byte[] src = new byte[16384]; // be aware of exceeding CPU cache static final char[] dst = new char[16384]; // be aware of exceeding CPU cache static void foo() { // fill arrays, to force real memory load and prohibit HotSpot from just incrementing // (maybe candidate for sophisticated HotSpot optimization ;-) ) for (int i=0; i References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <49724B41.6070104@gmx.de> <1232232491.7455.26.camel@localhost.localdomain> <49728D7D.9050009@gmx.de> Message-ID: <49729156.8030006@gmx.de> My results by JDK 1.6.0_03 (-server mode): time for 1st warm up: 1467 ms time for 2nd warm up: 1377 ms time for map[a & 0xFF]: 5195 ms time for map[a + 0x80]: 3588 ms time for inlined map[a & 0xFF]: 6046 ms time for inlined map[a + 0x80]: 3595 ms I don't really understand, why inlined code is slower ?????????? -Ulf From John.Rose at Sun.COM Sat Jan 17 18:58:06 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 17 Jan 2009 18:58:06 -0800 Subject: side note on static array constants and final fields In-Reply-To: <49724F24.7010602@gmx.de> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <1232225845.7455.23.camel@localhost.localdomain> <49724D74.4090503@gmx.de> <49724F24.7010602@gmx.de> Message-ID: <597D8BDA-E461-425B-AA8A-FDBBB101BC07@Sun.COM> A side note on the unsigned-byte conversation: Static finals are treated by the JIT as constants, and a few of their built-in immutable fields are (recursively) compile time constants. The oop _klass and array _length fields are both compile-time constants, whenever the enclosing object reference is constant. This is why you get benefit from making static arrays final; their range checks fold up. Some day we'll extend this treatment to user-written final instance fields, so whole nests of objects can be folded more aggressively in the JIT. It's tricky, though, since user-written finals are not truly immutable: According to the verifier, they can be written and even rewritten in their own constructors. -- John On Jan 17, 2009, at 1:35 PM, Ulf Zibis wrote: > + the map should be defined final. > From Ulf.Zibis at gmx.de Sun Jan 18 12:50:47 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 18 Jan 2009 21:50:47 +0100 Subject: side note on static array constants and final fields In-Reply-To: <597D8BDA-E461-425B-AA8A-FDBBB101BC07@Sun.COM> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <1232225845.7455.23.camel@localhost.localdomain> <49724D74.4090503@gmx.de> <49724F24.7010602@gmx.de> <597D8BDA-E461-425B-AA8A-FDBBB101BC07@Sun.COM> Message-ID: <49739627.3000302@gmx.de> Hi John, thanks for your interesting additional info. Just for interest, I run my benchmark with non-final arrays. The warmup and the +128 trick became much slower, but surprise, the inlined version for map[a & 0xFF] became faster, so there is not anymore a difference between inlined and non-inlined version. Anybody understand this? My results by JDK 1.6.0_03 (-server mode, arrays non-final): time for 1st warm up: 1827 ms time for 2nd warm up: 1782 ms time for map[a & 0xFF]: 5188 ms time for map[a + 0x80]: 4943 ms time for inlined map[a & 0xFF]: 5133 ms time for inlined map[a + 0x80]: 4928 ms In client mode, surprisingly the run became faster with non-final arrays. My results by JDK 1.6.0_03 (arrays non-final): time for 1st warm up: 2906 ms time for 2nd warm up: 2940 ms time for map[a & 0xFF]: 7276 ms time for map[a + 0x80]: 7270 ms time for inlined map[a & 0xFF]: 7291 ms time for inlined map[a + 0x80]: 7278 ms -Ulf Am 18.01.2009 03:58, John Rose schrieb: > A side note on the unsigned-byte conversation: > > Static finals are treated by the JIT as constants, and a few of their > built-in immutable fields are (recursively) compile time constants. > > The oop _klass and array _length fields are both compile-time > constants, whenever the enclosing object reference is constant. This > is why you get benefit from making static arrays final; their range > checks fold up. > > Some day we'll extend this treatment to user-written final instance > fields, so whole nests of objects can be folded more aggressively in > the JIT. It's tricky, though, since user-written finals are not truly > immutable: According to the verifier, they can be written and even > rewritten in their own constructors. > > -- John > > On Jan 17, 2009, at 1:35 PM, Ulf Zibis wrote: > >> + the map should be defined final. >> > > From Christian.Thalinger at Sun.COM Mon Jan 19 03:05:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Jan 2009 12:05:56 +0100 Subject: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... In-Reply-To: <49728D7D.9050009@gmx.de> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <49724B41.6070104@gmx.de> <1232232491.7455.26.camel@localhost.localdomain> <49728D7D.9050009@gmx.de> Message-ID: <1232363156.18371.176.camel@localhost.localdomain> On Sun, 2009-01-18 at 03:01 +0100, Ulf Zibis wrote: > My results by JDK 1.7.0 ea b43 : > > time for 1st warm up: 3091 ms > time for 2nd warm up: 3100 ms > time for map[a & 0xFF]: 7207 ms > time for map[a + 0x80]: 7225 ms > time for inlined map[a & 0xFF]: 8100 ms > time for inlined map[a + 0x80]: 8084 ms Vanilla HotSpot: time for 1st warm up: 622 ms time for 2nd warm up: 586 ms time for map[a & 0xFF]: 1460 ms time for map[a + 0x80]: 1456 ms time for inlined map[a & 0xFF]: 1461 ms time for inlined map[a + 0x80]: 1454 ms Hotspot w/ unsigned-byte loads: time for 1st warm up: 680 ms time for 2nd warm up: 641 ms time for map[a & 0xFF]: 1537 ms time for map[a + 0x80]: 1468 ms time for inlined map[a & 0xFF]: 1525 ms time for inlined map[a + 0x80]: 1462 ms For technical details I will reply on hotspot-compiler-dev. -- Christian From Ulf.Zibis at gmx.de Mon Jan 19 06:41:49 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 19 Jan 2009 15:41:49 +0100 Subject: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... In-Reply-To: <1232363156.18371.176.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <49724B41.6070104@gmx.de> <1232232491.7455.26.camel@localhost.localdomain> <49728D7D.9050009@gmx.de> <1232363156.18371.176.camel@localhost.localdomain> Message-ID: <4974912D.5030904@gmx.de> Hi Christian, thanks for your numbers from your tests. The magic inlining deceleration disapeared on your machine. Do you have used -client mode, because my values, you have taken for compare have been from -client mode. O:-) I also played around with warm up: time for warm up 1: 3539 ms time for warm up 2: 3110 ms time for warm up 3: 2697 ms time for warm up 4: 2703 ms time for map[a & 0xFF]: 3561 ms time for map[a + 0x80]: 3510 ms time for inlined map[a & 0xFF]: 3563 ms time for inlined map[a + 0x80]: 3470 ms test loops ./. warm up: 1.3042054 *Surprise*: testloops are much slower than warm up. Maybe it's the overheating effect on my mobile CPU. Can you check on your system? See my updated benchmark code at the end of mail ... -Ulf Am 19.01.2009 12:05, Christian Thalinger schrieb: > On Sun, 2009-01-18 at 03:01 +0100, Ulf Zibis wrote: > >> My results by JDK 1.7.0 ea b43 : >> >> time for 1st warm up: 3091 ms >> time for 2nd warm up: 3100 ms >> time for map[a & 0xFF]: 7207 ms >> time for map[a + 0x80]: 7225 ms >> time for inlined map[a & 0xFF]: 8100 ms >> time for inlined map[a + 0x80]: 8084 ms >> > > Vanilla HotSpot: > > time for 1st warm up: 622 ms > time for 2nd warm up: 586 ms > time for map[a & 0xFF]: 1460 ms > time for map[a + 0x80]: 1456 ms > time for inlined map[a & 0xFF]: 1461 ms > time for inlined map[a + 0x80]: 1454 ms > > Hotspot w/ unsigned-byte loads: > > time for 1st warm up: 680 ms > time for 2nd warm up: 641 ms > time for map[a & 0xFF]: 1537 ms > time for map[a + 0x80]: 1468 ms > time for inlined map[a & 0xFF]: 1525 ms > time for inlined map[a + 0x80]: 1462 ms > > For technical details I will reply on hotspot-compiler-dev. > > -- Christian > > > package build.tools.charsetmapping; /** * * @author Ulf Zibis */ public class DecoderBenchmark { public static void main(String[] args) { foo(); } static final char[] map = new char[256]; static final byte[] src = new byte[16384]; // be aware of exceeding CPU cache static final char[] dst = new char[16384]; // be aware of exceeding CPU cache static final int LOOPS = 100; static final int OUTER_LOOPS = 1000; static final int WARMUP_LOOPS = 4; static final float WARMUP_RATIO = 0.25f; static void foo() { // fill arrays, to force real memory load and prohibit HotSpot from just incrementing // (maybe candidate for sophisticated HotSpot optimization ;-) ) for (int i=0; i What would be the best way of allocating the arrays on the proper boundry? Would it be better to add an alignment flag or just assume that any array of (sizebytes%16-bytes==0) and any array of greater than 64bytes should be aligned? I'm guessing I would then need to adjust the klass header to align it to the boundry too. Then with garbage collection I assume I would have to make sure the new location is also aligned. From John.Rose at Sun.COM Wed Jan 21 17:36:06 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 21 Jan 2009 17:36:06 -0800 Subject: Superword - Aligning arrays In-Reply-To: <90121.96359.qm@web30002.mail.mud.yahoo.com> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> Message-ID: The simplest way is to make alignment strength depend only on size with no extra header bits. When allocating an array (this includes GC relocation) if the size is large enough, allocate a dummy object just before (a byte array, e.g.). Size the dummy so that the first element of your array will be strongly aligned. Seems pretty simple to me. -- John (on my iPhone) On Jan 21, 2009, at 4:57 PM, James Walsh wrote: > What would be the best way of allocating the arrays on the proper > boundry? Would it be better to add an alignment flag or just assume > that any array of (sizebytes%16-bytes==0) and any array of greater > than 64bytes should be aligned? I'm guessing I would then need to > adjust the klass header to align it to the boundry too. Then with > garbage collection I assume I would have to make sure the new > location is also aligned. > > > > From john.coomes at sun.com Thu Jan 22 13:16:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Thu, 22 Jan 2009 21:16:36 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090122211640.36C9BDDEE@hg.openjdk.java.net> Changeset: 818efdefcc99 Author: tonyp Date: 2009-01-16 13:02 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/818efdefcc99 6484956: G1: improve evacuation pause efficiency Summary: A bunch of performance optimizations to decrease GC pause times in G1. Reviewed-by: apetrusenko, jmasa, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared Changeset: 2b1de1db9a9d Author: jcoomes Date: 2009-01-21 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2b1de1db9a9d Merge From john.coomes at sun.com Thu Jan 22 20:33:40 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 04:33:40 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b44 for changeset a395e3aac474 Message-ID: <20090123043340.DCE80DEBD@hg.openjdk.java.net> Changeset: 99846f001ca2 Author: xdono Date: 2009-01-22 14:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/99846f001ca2 Added tag jdk7-b44 for changeset a395e3aac474 ! .hgtags From john.coomes at sun.com Thu Jan 22 20:35:51 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 04:35:51 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b44 for changeset 9803dac72540 Message-ID: <20090123043553.5791EDEC2@hg.openjdk.java.net> Changeset: 68814aa5b44b Author: xdono Date: 2009-01-22 14:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/68814aa5b44b Added tag jdk7-b44 for changeset 9803dac72540 ! .hgtags From john.coomes at sun.com Thu Jan 22 20:40:27 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 04:40:27 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b44 for changeset b203df0741af Message-ID: <20090123044030.22D43DEC7@hg.openjdk.java.net> Changeset: 0f113667880d Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/0f113667880d Added tag jdk7-b44 for changeset b203df0741af ! .hgtags From john.coomes at sun.com Thu Jan 22 20:42:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 04:42:42 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b44 for changeset 344485a03674 Message-ID: <20090123044244.80A0FDECC@hg.openjdk.java.net> Changeset: dea7753d7139 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/dea7753d7139 Added tag jdk7-b44 for changeset 344485a03674 ! .hgtags From john.coomes at sun.com Thu Jan 22 20:45:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 04:45:28 +0000 Subject: hg: jdk7/hotspot/jdk: 17 new changesets Message-ID: <20090123044843.EEE18DED6@hg.openjdk.java.net> Changeset: 57dc40ece164 Author: sherman Date: 2008-12-17 22:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/57dc40ece164 6496274: jar seems to use more CPU than it should Summary: boost jar creating performance especially for the large jar file Reviewed-by: martin ! src/share/classes/sun/tools/jar/Main.java Changeset: 85fe3cd9d6f9 Author: wetmore Date: 2008-12-19 10:35 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/85fe3cd9d6f9 6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider Summary: This is the JSSE portion of the fix. Main part is in PKCS11. Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 850d381fa9aa Author: tbell Date: 2008-12-19 22:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/850d381fa9aa Merge Changeset: 3d09cc6c4ea9 Author: alanb Date: 2008-12-22 19:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3d09cc6c4ea9 6787009: (attach) Stub injection potentially unsafe on windows-x64 Reviewed-by: mchung ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Changeset: 37a9442e3203 Author: tbell Date: 2009-01-09 21:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/37a9442e3203 Merge Changeset: 0bd360988b3a Author: thurka Date: 2009-01-07 14:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0bd360988b3a 6790467: Add test for setInterval() for local MonitoredHost and local MonitoredVm Summary: test for MonitoredHost.setInterval() and MonitoredVm.setInterval() added Reviewed-by: swamyv + test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java Changeset: ff572b4f1ca4 Author: martin Date: 2009-01-07 11:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ff572b4f1ca4 6788196: (porting) Bounds checks in io_util.c rely on undefined behaviour Reviewed-by: alanb Contributed-by: gbenson at redhat.com ! src/share/native/java/io/io_util.c ! test/java/io/readBytes/ReadBytesBounds.java Changeset: 0272e442cc5b Author: martin Date: 2009-01-08 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0272e442cc5b 6791458: FileInputStream/RandomAccessFile.read leaks memory if invoked on closed stream with len > 8k Reviewed-by: alanb Contributed-by: jeremymanson at google.com ! src/share/native/java/io/io_util.c + test/java/io/readBytes/MemoryLeak.java Changeset: f6c105e60186 Author: bpatel Date: 2009-01-07 16:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f6c105e60186 6790217: Javadoc HTML WCAG 2.0 accessibility issues in jdk docs makefile - Bold tags should be strong Reviewed-by: jjg ! make/docs/Makefile Changeset: 71a6cd33d365 Author: bpatel Date: 2009-01-08 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/71a6cd33d365 Merge Changeset: f5062c0ae8d5 Author: bpatel Date: 2009-01-08 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f5062c0ae8d5 Merge Changeset: 961ea5a46a0c Author: martin Date: 2009-01-09 16:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/961ea5a46a0c 6792066: src/share/native/java/io/io_util.c clean-ups Reviewed-by: alanb ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h Changeset: 5c39d920b488 Author: tbell Date: 2009-01-09 22:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5c39d920b488 Merge Changeset: 4dab1a24dca2 Author: tbell Date: 2009-01-16 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4dab1a24dca2 Merge Changeset: 6dce6ac0929e Author: tbell Date: 2009-01-14 21:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6dce6ac0929e 6754862: jdk/src/windows/bin/java_md.c: hardcoded reference to msvcr71.dll 6779412: VS2008 errors compiling jdk sources Summary: Update Makefiles to tolerate newer Visual Studio releases and runtimes. Reviewed-by: ohair ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/redist/Makefile ! src/share/bin/main.c ! src/windows/bin/java_md.c Changeset: d8eb2738db6b Author: xdono Date: 2009-01-20 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d8eb2738db6b Merge - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: 527b426497a2 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/527b426497a2 Added tag jdk7-b44 for changeset d8eb2738db6b ! .hgtags From john.coomes at sun.com Thu Jan 22 20:54:01 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 04:54:01 +0000 Subject: hg: jdk7/hotspot/langtools: 9 new changesets Message-ID: <20090123045416.8C05FDEDB@hg.openjdk.java.net> Changeset: 7a595d92e252 Author: jjg Date: 2009-01-07 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7a595d92e252 6512707: "incompatible types" after (unrelated) annotation processing Reviewed-by: darcy Contributed-by: prunge at velocitynet.com.au ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java + test/tools/javac/processing/6512707/T6512707.java + test/tools/javac/processing/6512707/TestAnnotation.java + test/tools/javac/processing/6512707/TestEnum.java Changeset: 47a62d8d98b4 Author: bpatel Date: 2009-01-08 16:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/47a62d8d98b4 6786028: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Bold tags should be strong Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java ! test/com/sun/javadoc/testHref/TestHref.java + test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java + test/com/sun/javadoc/testHtmlStrongTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlStrongTag/pkg2/C2.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java Changeset: dbe9e82f9d25 Author: bpatel Date: 2009-01-08 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dbe9e82f9d25 Merge ! test/com/sun/javadoc/AuthorDD/AuthorDD.java Changeset: 905e151a185a Author: mcimadamore Date: 2009-01-13 13:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/905e151a185a 6765045: Remove rawtypes warnings from langtools Summary: Removed all occurrences of rawtypes warnings from langtools Reviewed-by: jjg, bpatel ! make/build.properties ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/sun/tools/javap/FieldData.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/MethodData.java Changeset: d57378c34fdb Author: mcimadamore Date: 2009-01-13 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d57378c34fdb 6665356: Cast not allowed when both qualifying type and inner class are parameterized Summary: Fixed parser and cats conversion in order to allow cast between generic inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/cast/6665356/T6665356.java + test/tools/javac/cast/6665356/T6665356.out + test/tools/javac/generics/rare/6665356/T6665356.java + test/tools/javac/generics/rare/6665356/T6665356.out Changeset: 09eb1acc9610 Author: mcimadamore Date: 2009-01-13 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/09eb1acc9610 6723444: javac fails to substitute type variables into a constructor's throws clause Summary: Added constructor's actual type info to NewClass AST node Reviewed-by: jjg Contributed-by: mark at twistedbanana.demon.co.uk ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/generics/6723444/T6723444.java + test/tools/javac/generics/6723444/T6723444.out Changeset: e157bd68dfc5 Author: mcimadamore Date: 2009-01-13 13:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e157bd68dfc5 6558559: Extra "unchecked" diagnostic Summary: Fixed Types.sideCast in order to suppress redundant unchecked warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6558559/T6558559a.java + test/tools/javac/cast/6558559/T6558559b.java Changeset: 28f0b10d6c1a Author: tbell Date: 2009-01-16 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/28f0b10d6c1a Merge Changeset: 30db5e0aaf83 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/30db5e0aaf83 Added tag jdk7-b44 for changeset 28f0b10d6c1a ! .hgtags From coleen.phillimore at sun.com Fri Jan 23 10:24:52 2009 From: coleen.phillimore at sun.com (coleen.phillimore at sun.com) Date: Fri, 23 Jan 2009 18:24:52 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20090123182502.BA683DFF9@hg.openjdk.java.net> Changeset: 37b3ca071522 Author: coleenp Date: 2009-01-14 20:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/37b3ca071522 6793825: Missing include dependancies for GCC without predefined headers Summary: With predefined headers off for gcc, some .inline.hpp files aren't included to make definition visible for inline functions Reviewed-by: jcoomes, xlu ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features Changeset: 8db2b3e46c38 Author: swamyv Date: 2009-01-14 19:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8db2b3e46c38 6786948: SA on core file fails on solaris-amd64 if vm started with -XX:+StartAttachListener Reviewed-by: jjh, dcubed ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp Changeset: fc14734c5aec Author: swamyv Date: 2009-01-15 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc14734c5aec Merge Changeset: 40ee984935b9 Author: phh Date: 2009-01-21 11:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/40ee984935b9 6792705: Add JAR file to bootclasspath when using AggressiveOpts Summary: During argument processing, add alt-rt.jar to the bootclasspath between bootclasspath/p and default elements. Reviewed-by: xlu, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 99c597293e35 Author: coleenp Date: 2009-01-23 10:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/99c597293e35 Merge ! src/share/vm/gc_implementation/includeDB_gc_g1 From Xiaobin.Lu at Sun.COM Sun Jan 25 12:50:33 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Sun, 25 Jan 2009 12:50:33 -0800 Subject: review request for 6795913 Message-ID: <497CD099.2070502@Sun.COM> 6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS. Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6795913/webrev/ Details: This bug fix is to fix a few remaining wrong casts in order to build hotspot on Mac OS X. I accidentally left out a few places I supposed to fix as part of 6787106. The problem is again due to different definition of type intptr_t and int32_t on Mac OS. Verified by: Build on Mac OS X 10.5.5. Thanks in advance! -Xiaobin From coleen.phillimore at sun.com Thu Jan 29 14:04:04 2009 From: coleen.phillimore at sun.com (coleen.phillimore at sun.com) Date: Thu, 29 Jan 2009 22:04:04 +0000 Subject: hg: jdk7/hotspot/hotspot: 6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS. Message-ID: <20090129220406.AC325E404@hg.openjdk.java.net> Changeset: dc3ad84615cf Author: xlu Date: 2009-01-26 12:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dc3ad84615cf 6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS. Summary: Use NULL_WORD in the places where intptr_t is expected due to incompatible types between intptr_t & int32_t Reviewed-by: phh, coleenp, never ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp From john.coomes at sun.com Thu Jan 29 20:35:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 04:35:36 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b45 for changeset 99846f001ca2 Message-ID: <20090130043537.30D34E48D@hg.openjdk.java.net> Changeset: e8a2a4d18777 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e8a2a4d18777 Added tag jdk7-b45 for changeset 99846f001ca2 ! .hgtags From john.coomes at sun.com Thu Jan 29 20:37:55 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 04:37:55 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b45 for changeset 68814aa5b44b Message-ID: <20090130043756.71E43E492@hg.openjdk.java.net> Changeset: 1691dbfc08f8 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/1691dbfc08f8 Added tag jdk7-b45 for changeset 68814aa5b44b ! .hgtags From john.coomes at sun.com Thu Jan 29 20:43:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 04:43:26 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b45 for changeset 0f113667880d Message-ID: <20090130044328.D5598E497@hg.openjdk.java.net> Changeset: b2271877894a Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/b2271877894a Added tag jdk7-b45 for changeset 0f113667880d ! .hgtags From john.coomes at sun.com Thu Jan 29 20:45:48 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 04:45:48 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b45 for changeset dea7753d7139 Message-ID: <20090130044549.EB7F0E49E@hg.openjdk.java.net> Changeset: af4a3eeb7812 Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/af4a3eeb7812 Added tag jdk7-b45 for changeset dea7753d7139 ! .hgtags From john.coomes at sun.com Thu Jan 29 20:48:11 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 04:48:11 +0000 Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b45 for changeset 527b426497a2 Message-ID: <20090130044827.31346E4A5@hg.openjdk.java.net> Changeset: 997c6403bf2e Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/997c6403bf2e Added tag jdk7-b45 for changeset 527b426497a2 ! .hgtags From john.coomes at sun.com Thu Jan 29 20:54:56 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 04:54:56 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b45 for changeset 30db5e0aaf83 Message-ID: <20090130045459.BA143E4B4@hg.openjdk.java.net> Changeset: d957ceba29f9 Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d957ceba29f9 Added tag jdk7-b45 for changeset 30db5e0aaf83 ! .hgtags From y.s.ramakrishna at sun.com Fri Jan 30 02:16:25 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Fri, 30 Jan 2009 10:16:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090130101631.0C9B4E59D@hg.openjdk.java.net> Changeset: 5cfd8d19e546 Author: ysr Date: 2009-01-26 12:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5cfd8d19e546 6786503: Overflow list performance can be improved Summary: Avoid overflow list walk in CMS & ParNew when it is unnecessary. Fix a couple of correctness issues, including a C-heap leak, in ParNew at the intersection of promotion failure, work queue overflow and object array chunking. Add stress testing option and related assertion checking. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e400c36026f Author: iveresov Date: 2009-01-27 18:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4e400c36026f 6783381: NUMA allocator: don't pretouch eden space with UseNUMA Summary: Moved pretouching to MutableSpace. Also MutableSpace now turns on page interleaving for the region it covers. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp Changeset: 5b39c489c39d Author: ysr Date: 2009-01-29 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5b39c489c39d Merge ! src/share/vm/gc_implementation/includeDB_gc_parNew From Xiaobin.Lu at Sun.COM Fri Jan 30 10:42:29 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 30 Jan 2009 10:42:29 -0800 Subject: question regarding the java.lang.String design In-Reply-To: <498348B3.4000302@Sun.COM> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> Message-ID: <49834A15.8080102@Sun.COM> Resend the email to hotspot-dev at openjdk.java.net. -Xiaobin Xiaobin Lu wrote: > Hi folks, > > While I am looking at the java.lang.String implementation, I noticed > that it has "offset" and "count" field in java.lang.String. For the > offset field, I only found two places which set that field, but I > believe they can be got rid of too. The two places are > String(StringBuffer buffer) & String(StringBuilder builder). > > My question is that if String is immutable, why do we need to carry > these two fields? String could be more compacted without these two > fields. The equals to method can be more efficiently implemented as > just calling java.util.Array.equals(v1, v2) which is intrinsified on > x86 at least. > > Another crazy thought is that we can compact the character array to a > byte array if we don't have any characters other than ASCII (which we > might use a boolean flag to indicate that). > > I'd appreciate your insight on this. > > -Xiaobin > > > From wimmer at ssw.jku.at Fri Jan 30 12:47:32 2009 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Fri, 30 Jan 2009 12:47:32 -0800 Subject: question regarding the java.lang.String design In-Reply-To: <49834A15.8080102@Sun.COM> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> <49834A15.8080102@Sun.COM> Message-ID: <610527A1-3182-4451-8665-049F9CE17A52@ssw.jku.at> Hi, >> While I am looking at the java.lang.String implementation, I >> noticed that it has "offset" and "count" field in java.lang.String. >> For the offset field, I only found two places which set that field, >> but I believe they can be got rid of too. The two places are >> String(StringBuffer buffer) & String(StringBuilder builder). >> >> My question is that if String is immutable, why do we need to carry >> these two fields? String could be more compacted without these two >> fields. The equals to method can be more efficiently implemented as >> just calling java.util.Array.equals(v1, v2) which is intrinsified >> on x86 at least. You might want to look at a research project we had in the last years where this was the first step. You find the references on this page in the section "Optimization of Strings": http://wikis.sun.com/display/HotSpotInternals/Publications+JKU Just eliminating the offset field without other changes is not really beneficial, because you loose the optimization of e.g. the method "substring", which needs to do an arraycopy when you don't have the offset field. >> Another crazy thought is that we can compact the character array to >> a byte array if we don't have any characters other than ASCII >> (which we might use a boolean flag to indicate that). That's a thing we only thought about but never tried, so it would be interesting to try it out. The only problem is that prototyping such changes is really time-consuming. Christian From martinrb at google.com Fri Jan 30 14:34:57 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 30 Jan 2009 14:34:57 -0800 Subject: question regarding the java.lang.String design In-Reply-To: <49834A15.8080102@Sun.COM> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> <49834A15.8080102@Sun.COM> Message-ID: <1ccfd1c10901301434m15970160n6085179c6861e840@mail.gmail.com> Lots of people have tried to hack on String representation optimizations. Ken Russell is one of them IIRC. It's a very hard problem. My favorite hack would be to always use the "substring optimization", but the GC has to know about it, and occasionally it would reorg the internal string representations to avoid "memory leaks" from small substrings causing large backing arrays to be retained. Also, compressing String contents is near and dear to my heart. Any large String that hasn't been accessed for a while could even be zlib-compressed transparently to the application. Difficult to make fast and correct. In principle, it should be similar to the "thin lock" optimization that expands intrinsic object locks only when needed. Martin (not a hotspot engineer) On Fri, Jan 30, 2009 at 10:42, Xiaobin Lu wrote: > Resend the email to hotspot-dev at openjdk.java.net. > -Xiaobin > > Xiaobin Lu wrote: > >> Hi folks, >> >> While I am looking at the java.lang.String implementation, I noticed that >> it has "offset" and "count" field in java.lang.String. For the offset field, >> I only found two places which set that field, but I believe they can be got >> rid of too. The two places are String(StringBuffer buffer) & >> String(StringBuilder builder). >> >> My question is that if String is immutable, why do we need to carry these >> two fields? String could be more compacted without these two fields. The >> equals to method can be more efficiently implemented as just calling >> java.util.Array.equals(v1, v2) which is intrinsified on x86 at least. >> >> Another crazy thought is that we can compact the character array to a byte >> array if we don't have any characters other than ASCII (which we might use a >> boolean flag to indicate that). >> >> I'd appreciate your insight on this. >> >> -Xiaobin >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090130/3fbb7e7b/attachment.html From David.Holmes at Sun.COM Fri Jan 30 22:13:09 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 31 Jan 2009 16:13:09 +1000 Subject: question regarding the java.lang.String design In-Reply-To: <49834A15.8080102@Sun.COM> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> <49834A15.8080102@Sun.COM> Message-ID: <4983EBF5.2070507@sun.com> Hi Xiaobin, As you've probably gleaned by now the count and offset fields are to allow sharing of the underlying char[] - which is a safe thing to do exactly because a string is immutable. I've often thought this particular optimization was under-utilized. As others have said optimization of strings has been a recurring theme for many years now - there was even a paper on it at last year's ACM OOPSLA conference. IBM Research's Tokyo labs do a lot in this area - see for example "RT0750 A Quantitative Analysis of Space Waste from Java Strings and its Elimination at GC Time". I've occasionally thought that with all the duplicate strings that readily occur in Java it might be an option to have a few large tables of "text" containing all the characters, and then to define a String as one or more pairs of indices into these tables. But that's as far as I've thought about it :) Cheers, David Holmes Xiaobin Lu said the following on 01/31/09 04:42: > Resend the email to hotspot-dev at openjdk.java.net. > -Xiaobin > > Xiaobin Lu wrote: >> Hi folks, >> >> While I am looking at the java.lang.String implementation, I noticed >> that it has "offset" and "count" field in java.lang.String. For the >> offset field, I only found two places which set that field, but I >> believe they can be got rid of too. The two places are >> String(StringBuffer buffer) & String(StringBuilder builder). >> >> My question is that if String is immutable, why do we need to carry >> these two fields? String could be more compacted without these two >> fields. The equals to method can be more efficiently implemented as >> just calling java.util.Array.equals(v1, v2) which is intrinsified on >> x86 at least. >> >> Another crazy thought is that we can compact the character array to a >> byte array if we don't have any characters other than ASCII (which we >> might use a boolean flag to indicate that). >> >> I'd appreciate your insight on this. >> >> -Xiaobin >> >> >> > From Xiaobin.Lu at Sun.COM Fri Jan 30 22:20:06 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 30 Jan 2009 22:20:06 -0800 Subject: question regarding the java.lang.String design In-Reply-To: <4983EBF5.2070507@sun.com> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> <49834A15.8080102@Sun.COM> <4983EBF5.2070507@sun.com> Message-ID: <4983ED96.1030809@Sun.COM> Hi David, I was ignoring the fact that substring could use the offset & count for sharing purpose. I am thinking whether we should have a flag like "isCharArrayShared" which will be set to true only for those string returned from substring call. That way, for many other methods in String, we could ignore loading offset & count fields which are mostly set to 0 and val.length anyways (val is the character array). Regards, -Xiaobin David Holmes - Sun Microsystems wrote: > Hi Xiaobin, > > As you've probably gleaned by now the count and offset fields are to > allow sharing of the underlying char[] - which is a safe thing to do > exactly because a string is immutable. I've often thought this > particular optimization was under-utilized. > > As others have said optimization of strings has been a recurring theme > for many years now - there was even a paper on it at last year's ACM > OOPSLA conference. IBM Research's Tokyo labs do a lot in this area - > see for example "RT0750 A Quantitative Analysis of Space Waste from > Java Strings and its Elimination at GC Time". > > I've occasionally thought that with all the duplicate strings that > readily occur in Java it might be an option to have a few large tables > of "text" containing all the characters, and then to define a String > as one or more pairs of indices into these tables. But that's as far > as I've thought about it :) > > Cheers, > David Holmes > > > Xiaobin Lu said the following on 01/31/09 04:42: >> Resend the email to hotspot-dev at openjdk.java.net. >> -Xiaobin >> >> Xiaobin Lu wrote: >>> Hi folks, >>> >>> While I am looking at the java.lang.String implementation, I noticed >>> that it has "offset" and "count" field in java.lang.String. For the >>> offset field, I only found two places which set that field, but I >>> believe they can be got rid of too. The two places are >>> String(StringBuffer buffer) & String(StringBuilder builder). >>> >>> My question is that if String is immutable, why do we need to carry >>> these two fields? String could be more compacted without these two >>> fields. The equals to method can be more efficiently implemented as >>> just calling java.util.Array.equals(v1, v2) which is intrinsified on >>> x86 at least. >>> >>> Another crazy thought is that we can compact the character array to >>> a byte array if we don't have any characters other than ASCII (which >>> we might use a boolean flag to indicate that). >>> >>> I'd appreciate your insight on this. >>> >>> -Xiaobin >>> >>> >>> >> From erik.trimble at sun.com Fri Jan 30 22:41:09 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Sat, 31 Jan 2009 06:41:09 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20090131064117.8A18DE677@hg.openjdk.java.net> Changeset: 809e899c638b Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/809e899c638b Added tag jdk7-b43 for changeset fc6a5ae3fef5 ! .hgtags Changeset: 945bf7540697 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/945bf7540697 Added tag jdk7-b44 for changeset 809e899c638b ! .hgtags Changeset: 16bb38eeda35 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/16bb38eeda35 Added tag jdk7-b45 for changeset 945bf7540697 ! .hgtags Changeset: 3f844a28c5f4 Author: trims Date: 2009-01-30 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f844a28c5f4 Merge From John.Rose at Sun.COM Fri Jan 30 23:30:21 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 30 Jan 2009 23:30:21 -0800 Subject: question regarding the java.lang.String design In-Reply-To: <4983ED96.1030809@Sun.COM> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> <49834A15.8080102@Sun.COM> <4983EBF5.2070507@sun.com> <4983ED96.1030809@Sun.COM> Message-ID: <9F3133CF-C85C-4E16-9EE2-F8AD8E099CB9@sun.com> I wouldn't add a new field but (in the interests of keeping bloat under control) would look for ways to encode corner cases in existing fields. E.g. if the length field is zero then disregard offset and go straight to the value array. Or, with a type test on the value array allow it to be UTF8 byte[] array. Martin's idea of representation swapping could be gates by a type test on the value field alone. We've also discussed GC support in the VM group over the years. My favorite idea is Unsafe.chopArray, which would be used in StringBuffer.toString to tease apart the used and unused parts of the buffer in O(1) instructions, leaving the unused part for reuse as a slightly shorter buffer. Lots of ideas floating around... As Christian says the hard part is prototyping, and then characterizing the result requires insightful choice of benchmarks. . -- John (on my iPhone) On Jan 30, 2009, at 10:20 PM, Xiaobin Lu wrote: > Hi David, > > I was ignoring the fact that substring could use the offset & count > for sharing purpose. I am thinking whether we should have a flag > like "isCharArrayShared" which will be set to true only for those > string returned from substring call. That way, for many other > methods in String, we could ignore loading offset & count fields > which are mostly set to 0 and val.length anyways (val is the > character array). > > Regards, > -Xiaobin > > David Holmes - Sun Microsystems wrote: >> Hi Xiaobin, >> >> As you've probably gleaned by now the count and offset fields are >> to allow sharing of the underlying char[] - which is a safe thing >> to do exactly because a string is immutable. I've often thought >> this particular optimization was under-utilized. >> >> As others have said optimization of strings has been a recurring >> theme for many years now - there was even a paper on it at last >> year's ACM OOPSLA conference. IBM Research's Tokyo labs do a lot in >> this area - see for example "RT0750 A Quantitative Analysis of >> Space Waste from Java Strings and its Elimination at GC Time". >> >> I've occasionally thought that with all the duplicate strings that >> readily occur in Java it might be an option to have a few large >> tables of "text" containing all the characters, and then to define >> a String as one or more pairs of indices into these tables. But >> that's as far as I've thought about it :) >> >> Cheers, >> David Holmes >> >> >> Xiaobin Lu said the following on 01/31/09 04:42: >>> Resend the email to hotspot-dev at openjdk.java.net. >>> -Xiaobin >>> >>> Xiaobin Lu wrote: >>>> Hi folks, >>>> >>>> While I am looking at the java.lang.String implementation, I >>>> noticed that it has "offset" and "count" field in >>>> java.lang.String. For the offset field, I only found two places >>>> which set that field, but I believe they can be got rid of too. >>>> The two places are String(StringBuffer buffer) & >>>> String(StringBuilder builder). >>>> >>>> My question is that if String is immutable, why do we need to >>>> carry these two fields? String could be more compacted without >>>> these two fields. The equals to method can be more efficiently >>>> implemented as just calling java.util.Array.equals(v1, v2) which >>>> is intrinsified on x86 at least. >>>> >>>> Another crazy thought is that we can compact the character array >>>> to a byte array if we don't have any characters other than ASCII >>>> (which we might use a boolean flag to indicate that). >>>> >>>> I'd appreciate your insight on this. >>>> >>>> -Xiaobin >>>> >>>> >>>> >>> >